아날로그 인시던트 스토리 덱: 과거 장애를 책상 위에서 섞어 쓰는 결정 카드로 바꾸기

대부분의 팀은 인시던트를 “버티고, 문서화하고, 어딘가에 보관해야 할 것”으로만 취급합니다.

포스트모템을 쓰고, 어떤 툴에 기록해 두고, 회고를 조금 하다가, 곧 잊힙니다. 몇 달 후 비슷한 장애가 다시 터지면, 몸으로 익힌 기억은 이미 희미해져 있고, 예전에 했던 실수를 이번에는 더 큰 압박 속에서 되풀이하게 됩니다.

더 나은 방법이 있습니다. 과거 장애를 손으로 집어 들 수 있는 아날로그 스토리 카드로 바꾸는 것입니다. 이 카드는 섞고, 분류하고, 반복해서 사용할 수 있습니다.

이것이 바로 **아날로그 인시던트 스토리 덱(Analog Incident Story Deck)**입니다. 단순하지만 강력한 방식으로, 인시던트를 “한 번 겪고 끝나는 실패”에서 “계속 진화하는 실천형 학습 시스템”으로 바꿔 줍니다.

인시던트는 위키 속이 아니라 책상 위에 있어야 하는 이유

디지털 포스트모템은 중요하지만, 동시에 너무 쉽게 무시됩니다. Confluence, Notion, 티켓 시스템 어딘가에 쌓여 있지만, 누군가가 ‘근본 원인 발굴 작업’을 하지 않는 이상 다시는 열어보지 않습니다.

반면, 실물 카드로 만들면 상황이 달라집니다.

눈에 잘 띕니다 – 책상 위나 팀 공간에 놓여 있으면 항상 시야에 들어오는 상기 도구가 됩니다.
촉감이 있습니다 – 직접 손으로 섞고, 묶고, 순서를 바꿔 볼 수 있습니다.
휴대가 쉽습니다 – 게임데이, 온콜 트레이닝, 기획 세션에 통째로 들고 갈 수 있습니다.

인시던트를 카드로 바꾸면 이렇게 됩니다.

교육용 시나리오로 쉽게 재사용할 수 있고
다양한 연습 형태로 간단히 리믹스할 수 있으며
지속적인 학습의 원천으로 무시하기 어려운 존재가 됩니다.

이제 “작년에 있었던 그 장애”는 추상적인 기억이 아니라, 언제든 꺼내서 플레이하고, 토론하고, 연습할 수 있는 구체적인 오브젝트—스토리 카드가 됩니다.

포스트모템에서 스토리 카드로: 어떤 내용을 담아야 할까

이 덱의 힘은 인시던트를 어떻게 인코딩하느냐에서 나옵니다.

단순히 “무슨 일이 있었는지” 요약하는 것이 아니라, **결정 지점(Decision Point)**을 뽑아내야 합니다.

당시 사람들이 어떤 선택지 앞에 서 있었는지
그때 어떤 정보(혹은 그렇게 믿었던 정보)를 가지고 있었는지
왜 B가 아니라 A를 선택했는지
그 결정이 결과에 어떤 영향을 주었는지 – 좋았든 나빴든

카드 레이아웃 예시

거창한 템플릿이 필요하지 않습니다. 인덱스 카드나 작은 카드용 용지면 충분합니다. 다음과 같은 간단한 구조를 써보세요.

카드 앞면

제목: 짧고 기억에 남는 이름
- 예: 우리 서비스를 다운시킨 캐시 플러시
컨텍스트 스냅샷 (1–2줄)
- 영향받은 시스템, 대략적인 시간대, 임팩트 레벨 등
핵심 결정 지점 #1 (프롬프트 형식)
- “데이터베이스 레이턴시가 급등했고, 대시보드는 CPU 포화처럼 보입니다. 당신은 무엇을 먼저 시도하나요?”

카드 뒷면

실제로 일어난 일 (짧은 내러티브)
중요한 결정과 그 이유
- “대시보드가 I/O가 아닌 CPU 문제처럼 보이게 해서, 우리는 리플리카를 스케일아웃하기로 결정했습니다.”
결과
- 탐지까지 걸린 시간, 완화까지 걸린 시간, 사용자 영향 등
드러난 갭들
- 모니터링의 블라인드 스팟, 런북 공백, 역할 혼선, 위험한 가정 등
연습용 훅(Practice Hooks)
- “게임데이에서 여기서 잠시 멈추고 묻습니다: 여기서 다른 선택지는 무엇이 있을까요?”

핵심은 각 인시던트를 불확실성 속에서 인간이 어떻게 의사결정을 했는가에 대한 이야기로 다루는 것이지, 단순한 “고장 난 시스템”의 목록으로 보지 않는 것입니다.

실제 인시던트 스토리로 게임데이 설계하기

몇 장의 인시던트 카드를 만들고 나면, 실제처럼 느껴지는 게임데이 연습을 설계할 수 있습니다. 그 이유는, 이 시나리오들이 실제로 있었던 일이기 때문입니다.

“데이터베이스가 다운됐다” 같은 인위적인 시나리오 대신, 실제 장애에서 나타나는 불완전하고, 부분적이고, 때로는 잘못된 신호가 섞여 있는 현실을 재현합니다.

1단계: 스토리 카드 선택하기

훈련 목표에 맞는 카드를 고르세요.

신규 온콜 온보딩 → 임팩트는 크지만 이미 충분히 이해된 인시던트
고급 드릴 → 여러 요인이 겹치고, 신호가 헷갈리게 나왔던 미묘한 장애
크로스팀 협업 훈련 → 여러 서비스와 팀의 협력이 필요했던 인시던트

2단계: 스토리를 시나리오 타임라인으로 풀기

인시던트를 여러 비트(Beat) 또는 단계로 나누고, 하나씩 순차적으로 공개할 수 있게 만듭니다.

초기 신호 – 알람 발생, 사용자 제보, 로그에서의 이상 징후 등
첫 해석 – 처음 봤을 때 어떻게 보였는지
초기 액션 – 첫 번째 롤백, 완화 시도, 빠른 패치 등
에스컬레이션과 전환점 – 팀이 ‘뭔가 다른 게 있다’고 깨닫는 지점
해결(Resolution) – 실제로 문제를 고친 방식과 검증 과정
후속 조치(Aftermath) – 배운 점, 바뀐 점, 후속 작업

각 비트마다 프롬프트를 만듭니다.

“결제 API에서 에러 버짓 알람이 울렸습니다. 그래프에는 5xx 스파이크와 레이턴시 증가가 동시에 보입니다. 당신은 무엇을 먼저 확인하나요?”
“방금 마지막 배포를 롤백했지만, 에러는 그대로입니다. 다음으로 무엇을 하시겠습니까?”

3단계: 실제 인시던트처럼 연습 세션 운영하기

게임데이에서:

당시 상황처럼 정보를 단계별로 조금씩 제공합니다.
각 단계마다 참가자에게 “지금이라면 무엇을 하겠는가”를 묻습니다.
실제로 그때 팀이 무엇을 했고, 그 결과 무엇이 일어났는지 공개합니다.
중간 중간 멈춰서 함께 토론합니다.
- 당시 이용 가능한 정보만 놓고 보면 더 나은 선택이 있었을까?
- 어떤 신호가 헷갈리게 만들었고, 어떤 신호가 아예 없었나?
- 그 상황에서 이해관계자(경영진, 고객 지원, 다른 팀)에게 어떻게 커뮤니케이션했어야 할까?

이 시나리오는 다음과 같이 운영할 수 있습니다.

테이블탑(Tabletop) 연습 – 종이와 대화만으로 진행
라이브파이어(Live-fire) 게임데이 – 스테이징이나 프로덕션 세이프 환경에서 실제 장애를 시뮬레이션

어떤 방식을 택하든, 인시던트 카드는 스토리의 뼈대 역할을 합니다.

인시던트는 시스템과 프로세스의 갭을 보여주는 이야기다

“루트 코즈(Root Cause)”만 보고 있으면, 인시던트 스토리의 진짜 가치를 놓치게 됩니다.

각 장애는 곧 갭의 내러티브입니다.

옵저버빌리티(Observability)의 갭: 빠져 있거나 오해를 부르는 메트릭, 로그, 트레이스
프로세스의 갭: 애매한 핸드오프, 없는 런북, 모호한 에스컬레이션 경로
세이프티 메커니즘의 갭: 빠져 있는 레이트 리밋, 위험한 디폴트, 불안전한 설정값
공유 이해(Shared Understanding)의 갭: 팀 간 서로 다른 멘탈 모델과 시스템 이해도

스토리 카드에는 이런 문장들이 살아 있어야 합니다.

“우리는 캐시가 멱등적일 거라고 가정했지만, 실제 인밸리데이션 동작은 위험했다.”
“온콜 엔지니어는 긴급용 피처 플래그가 있다는 사실을 몰랐다.”
“에러율 알람은 있었지만 큐 딥스(Queue Depth)에 대한 알람이 없어, 문제를 늦게 발견했다.”

이렇게 카드를 통해 이런 내용을 코드처럼 박아 두면, 추상적인 “교훈(Lessons Learned)”이 아니라, 언제든 꺼내 쓸 수 있는 구체적인 **학습 오브젝트(Learning Object)**가 됩니다.

‘왜’를 카드에 담아 반복 가능한 연습으로 바꾸기

사후 분석은 종종 “무엇이 깨졌는지(What broke)”에만 집중합니다. 하지만 가장 강력한 학습은, 당시의 결정이 **그때의 관점에서는 왜 합리적으로 보였는지(Why)**를 파고들 때 나옵니다.

각 카드에는 다음을 명시적으로 담아 보세요.

당시 이용 가능했던 정보
팀이 가지고 있던 믿음과 가정
압박과 제약 조건 (시간, 사용자 영향, 경영진 기대 등)

그 다음, 이것을 연습 문제로 바꿉니다.

“이 부분적인 대시보드 스크린샷만 보고, 어떤 가설을 세우겠습니까?”
“10분 안에 서비스를 복구하라는 압박을 받고 있습니다. 롤백을 하겠습니까, 스케일업을 시도하겠습니까? 그리고 그 이유는 무엇입니까?”

이 접근법은 다음과 같은 능력을 훈련합니다.

불확실성 하에서의 패턴 인식
빠르게 가설을 세우고 수정하는 능력
생각하고 행동하는 와중에도 명확히 커뮤니케이션하는 능력

이렇게 하면 과거에 겪은 특정 장애만 대비하는 것이 아니라, 인시던트에 대응하는 사고력 자체를 키우게 됩니다.

정기적인 준비 드릴에서 스토리 카드 활용하기

인시던트 스토리 카드 덱은, 일회성 워크숍 도구가 아니라 팀의 정기적인 리듬 속에 녹아들 때 가장 빛납니다.

덱을 팀 리듬에 통합하는 아이디어

주간 또는 격주 ‘인시던트 클럽’
- 카드를 한 장 뽑아서 스토리를 함께 따라가며, 그때의 결정들을 토론합니다.
온콜 워밍업
- 신규 엔지니어의 첫 온콜 전에, 관련된 카드 1–2장을 함께 연습합니다.
크로스팀 정렬 세션
- 여러 서비스를 건드렸던 인시던트를 골라, 각 팀이 자기 관점에서 이야기를 들려줍니다.
출시 전 준비 리뷰(Pre-launch Readiness)
- 덱을 섞어 보면서 묻습니다: “이 새 기능으로 인해, 과거 인시던트 중 어떤 실패 모드가 다시 발생할 수 있을까?”

시간이 지나면서 다음과 같은 개선을 볼 수 있습니다.

팀 간 조율 – 역할이 더 분명해지고, 놓치는 일이 줄어듭니다.
대응 속도 – 탐지 시간이 줄고, 초기 조치가 더 과감하고 정확해집니다.
자신감 – 온콜 엔지니어는 예전에 비슷한 스토리를 여러 번 “봐왔기” 때문에 훨씬 덜 두려워합니다.

학습 루프 닫기: 덱을 계속 진화시키기

아날로그 인시던트 스토리 덱은 완성형 아티팩트가 아닙니다. 새로운 인시던트가 생길 때마다 함께 진화합니다.

각 인시던트 이후에는 다음과 같이 해 보세요.

평소처럼 포스트 인시던트 분석(포스트모템, RCA 등)을 진행합니다.
그중에서 핵심 결정 지점, 주요 갭, 스토리의 흐름을 뽑아냅니다.
새로운 스토리 카드를 만들거나, 기존 카드를 업데이트합니다.
덱에 추가하고, 다가오는 드릴 일정에 반영합니다.
시간이 지나 새로운 관점이 생기면, 이전 카드도 다시 다듬습니다.

이렇게 하면, 손에 쥘 수 있는 형태의 살아 있는 아날로그 플레이북을 구축하게 됩니다.

단순히 런북과 체크리스트를 나열한 정적인 문서가 아니라,
시간이 지날수록 풍부해지는 스토리, 결정, 교훈의 큐레이션 세트가 됩니다.

몇 달, 몇 년이 지나면, 손바닥 안에 쥘 수 있는 조직의 집단 기억이 됩니다.

시작하기: 아주 작은 첫걸음

예산도, 툴도, 경영진의 승인이 없어도 시작할 수 있습니다.

이번 주에 이렇게 해 보세요.

지난 6–12개월 사이에 있었던, 기억에 남는 인시던트 하나를 고릅니다.
그 인시던트의 포스트모템을 출력하거나, 화면에 띄워 둡니다.
인덱스 카드 한 장에 다음을 적습니다.
- 제목과 간단한 컨텍스트
- 프롬프트 형식의 핵심 결정 지점 2–3개
- 드러난 갭 2–3개
이 카드를 가지고 팀과 30분짜리 테이블탑 대화를 해 봅니다.

이 시간이 재미있고 유익했다면, 두 번째 카드를 만드세요. 그 다음에는 세 번째. 그러다 보면 어느새 하나의 덱이 손에 쥐어질 것입니다.

결론: 인시던트를 ‘섞어 쓸 수 있게’ 만들자

인시던트는 그 자체로도 비싸지만, 가장 아까운 낭비는 그것을 “단 한 번 겪고 끝나는 사건”으로 취급하는 것입니다.

장애를 아날로그, 섞어 쓸 수 있는 스토리 카드로 바꾸면, 이렇게 할 수 있습니다.

중요한 교훈을 눈에 보이고, 손에 잡히는 형태로 유지하고
현실적인 제약 속 실제 결정을 두고 팀을 훈련시키며
상상 속이 아닌 실제 사례에 기반한 고충실도(high-fidelity) 게임데이를 설계하고
새로운 스토리가 생길 때마다 인시던트 대응 플레이북을 계속 개선할 수 있습니다.

이미 그 장애에 대한 비용은 치렀습니다. 아날로그 인시던트 스토리 덱은, 그때 들인 비용에서 계속해서 가치를 뽑아내도록 돕는 도구입니다. 카드를 섞고, 나누고, 또 하나의 스토리를 테이블 위에 펼칠 때마다 말이죠.