소개

대부분의 팀은 무언가 이미 불타고 있을 때에서야 인시던트 대응 계획을 제대로 마주하게 됩니다.

문서는 있습니다. 런북도 있습니다. 대시보드도 있습니다. 하지만 많은 사람들이 이 모든 걸 처음으로 한꺼번에 경험하는 순간은 새벽 3시, 고객 영향은 커지고 모두의 신경은 곤두서 있는 때입니다.

이걸 바꾸는 방법이 바로 테이블탑 장애 훈련입니다.

이 글에서는 **“아날로그 인시던트 컴퍼스 트레인세트(Analog Incident Compass Trainset)”**라는 아이디어를 살펴봅니다. 프로덕션 환경을 종이(또는 화이트보드) 위에 그대로 옮겨 놓은 시뮬레이션으로, 실제와 유사한 인시던트를 연습하면서도 프로덕션은 전혀 건드리지 않는 방식입니다. 장애를 위한 모형 철도 세트라고 생각하면 됩니다. 실제처럼 동작하는 작고 안전한 세계에서, 기차(서비스)를 절벽 아래로 몰아가고, 탈선시키고, 그 잔해를 통해 배우는 공간입니다.

이 글에서 다룰 내용은 다음과 같습니다.

• 또 하나의 인시던트 문서보다 테이블탑 훈련이 더 중요한 이유
• 아날로그 인시던트 컴퍼스 트레인세트 같은 **시리어스 게임(serious game)**이 온콜 스킬과 자신감을 키워주는 방식
• 현실감 있는 아티팩트와 분기형 내러티브를 갖춘 시나리오 설계 방법
• 팀의 발전을 추적하기 위한 간단한 분석/계측을 시뮬레이션에 심는 방법

왜 ‘정적인 플레이북’보다 테이블탑 장애 훈련이 유용한가

문서로 된 인시던트 계획은 필수지만, 충분하지는 않습니다. 어떤 프로세스에 대해 알고 있는 것과, 실제 압박 상황에서 돌려볼 수 있는 것은 전혀 다릅니다.

**테이블탑 장애 훈련(Tabletop outage drill)**은 정적인 계획을 실제 준비 태세로 바꿔 줍니다. 그 방식은 다음과 같습니다.

• 압박 속 의사결정 연습: 누가 인시던트를 선언하나요? 언제 다른 팀을 페이징하나요? 롤백을 할까요, 롤 포워드를 할까요?
• 조율 능력 연습: 온콜, 인시던트 커맨더(IC), 커뮤니케이션 담당, 이해관계자들이 서로 엇갈리지 않고 어떻게 발을 맞추며 움직이게 할까요?
• 커뮤니케이션 개선: 고객, 경영진, 내부 팀에게 무엇을 언제 말해야 할까요?
• 갭 노출: 누군가 “이거 보는 대시보드는 어디 있어요?”, “이 서비스 오너가 도대체 누구죠?”라고 묻는 순간, 고객이 발견하기 전에 우리가 먼저 찾은 귀중한 구멍입니다.

이 모든 걸 위험이 거의 없고, 실제 영향도 없는 환경에서 할 수 있습니다. 이것이 바로 아날로그 인시던트 컴퍼스 트레인세트의 핵심입니다. 현실적인 스트레스, 하지만 프로덕션 리스크는 0.

‘Wheel of Misfortune’에서 아날로그 인시던트 컴퍼스 트레인세트까지

이 트레인세트는 신뢰성(Reiliability)과 인시던트 대응을 위한 시리어스 게임(serious game) 계열에 속하는 도구입니다.

이미 들어봤을 만한 것들로는:

• Wheel of Misfortune – 랜덤으로 뽑힌 장애 시나리오를 팀이 함께 풀어 나가는 SRE 연습 방식
• 게임데이(Game Day) / 카오스 드릴(Chaos Drill) – 스테이징이나 프로덕션에 의도적으로 장애를 주입해(Chaos Engineering) 복원력과 대응 능력을 검증하는 훈련

아날로그 인시던트 컴퍼스 트레인세트는 이들에서 영감을 받았지만, 다음과 같은 점을 특히 강조합니다.

• 코드·인프라 불필요 – 모든 것이 종이, 인덱스 카드, 그리고 가짜 대시보드가 열린 노트북 위에서만 돌아갑니다.
• 가이드되지만 유연한 내러티브 – 퍼실리테이터가 스토리를 이끌되, 팀의 선택이 실제 전개에 의미 있게 반영되도록 합니다.
• 재현성과 계측 가능성 – 같은 시나리오를 여러 코호트에 반복 실행하고, 성과를 측정·비교합니다.

즉, 당신의 시스템과 조직을 축소해 테이블 위에 올려놓은 모형입니다. 위기 상황에서 이들이 어떻게 행동하는지, 안전하게 실험해 볼 수 있는 장난감이죠.

종이 철도 만들기: 핵심 구성 요소

시작하는 데 필요한 것은 그리 많지 않습니다. 다음과 같이 생각해 보세요.

1. 세계의 지도(Map of the world)
   시스템을 한 페이지에 그린 다이어그램:

   • 핵심 서비스와 그 의존성
   • 외부 제공자(결제 처리, 인증 서비스, CDN 등)
   • 데이터 스토어와 중요한 큐/토픽

   이것이 트레인세트의 **“선로 배치도(track layout)”**입니다.

2. 인시던트 시나리오 카드(Incident scenario cards)
   각 카드는 하나의 탈선을 의미합니다.

   • 과거 실제 인시던트(필요 시 민감 정보 제거)
   • 현실적으로 있을 법한 가상의 장애
   • 외부 인시던트(클라우드 제공자 장애, 인증서 만료, 설정(config) 배포 사고 등)

3. 아티팩트 묶음(Artifacts packet)
   실제처럼 느껴지려면, 팀이 평소에 쓰는 아티팩트를 제공해야 합니다.

   • 모니터링 링크나 스크린샷
   • 시계열 그래프(CPU, 레이턴시, 에러율 등)
   • 로그(민감 정보 제거된 스니펫)
   • 런북 / 플레이북
   • 티켓 스냅샷이나 가짜 Slack 스레드

4. 역할(Role)
   사람들에게 다음 역할을 배정합니다.

   • 인시던트 커맨더(Incident Commander, IC)
   • 1차 온콜 / 테크 리드
   • 커뮤니케이션 리드(고객 및 이해관계자 공지 담당)
   • 서기 / 기록 담당
   • 서포팅 엔지니어 혹은 다른 팀 대표들

5. 퍼실리테이터 & 스크립트(Facilitator & script)
   한 사람이 시뮬레이션을 진행합니다.

   • 시간에 따라 아티팩트를 공개 (“T+5분 시점, 이런 그래프가 보입니다…”)
   • 외부 시스템, 고객, 경영진 역할을 대신 수행
   • 결정과 타임라인을 기록

이 정도면 기본적인 트레인세트가 완성된 것입니다. 세계(월드), 기차(서비스), 선로(아키텍처), 그리고 그것들을 일부러 박살낼 수 있는 방법까지 갖춘 셈입니다.

현실감 있게 팀을 ‘스트레스 테스트’하는 시나리오 설계

진짜 핵심은 시나리오 디자인입니다. 좋은 시나리오는 다음과 같은 특징을 가집니다.

• 실제 리스크에 기반: 잦은 장애 패턴을 모델링합니다. 잘못된 배포, 의존성 타임아웃, DB 포화, 인증서 만료 등.
• 팀 간 상호작용이 필수: 제대로 된 인시던트일수록 여러 서비스와 오너들을 동시에 건드립니다.
• 발견 가능한 정보의 여러 층을 가짐: 초기 단서, 헷갈리는 시그널, 그리고 결국 결정적인 스모킹 건까지.

과거 인시던트와 가상 인시던트 모두 활용하기

둘을 섞어 쓰는 게 좋습니다.

• 과거 인시던트는 이미 드러난 약점을 다시 연습해 보고, 우리가 해 둔 개선(기술적·프로세스적)이 실제로 행동 변화를 이끌어냈는지 검증하게 해줍니다.
• 가상 인시던트는 참가자들이 “예전에 이렇게 했으니까”라며 답을 외워오는 걸 막아주고, 앞으로 일어날 수 있는 신규 리스크·엣지 케이스를 시뮬레이션할 수 있게 해줍니다.

두 경우 모두 목표는 다음과 같습니다.

• 스트레스 상황에서 디버깅 연습
• 인시던트 관리 절차 숙달
• 팀 간 커뮤니케이션 패턴 개선 및 강화

프로덕션과 닮은 아티팩트 포함하기

추상적인 퍼즐풀이가 되지 않게, 실제 조사를 최대한 닮게 만드세요.

• 모니터링 & 대시보드: 인쇄된 스크린샷이나 정적인 HTML 익스포트를 제공합니다. 예: “리전별 API 레이턴시”, “엔드포인트별 에러율”, “DB 커넥션 수”.
• 시계열 데이터: T+0, T+5, T+15 시점의 스냅샷을 보여주고, 팀이 필요로 하면 추가 뷰를 요청하게 합니다.
• 런북: 일부 단계가 빠져 있거나 오래되어 틀린 부분이 있는 런북을 포함해, 실제 갭을 드러나게 합니다.
• Slack이나 티켓 발췌: “이 증상이 우리 고객에게 보이는 것 같아요” 같은 고객 문의, “EU 고객도 영향 있나요?”라고 묻는 세일즈 등의 메시지.

연습이 실제 온콜 근무와 비슷하게 느껴질수록, 그 경험은 현업에 더 잘 전이됩니다.

인터랙티브 도구로 ‘분기형 내러티브’ 추가하기

한 걸음 더 나아가, Ink(잉클사 Inkle의 인터랙티브 스토리 엔진) 같은 도구로 분기형(branching) 스토리를 스크립트화해 트레인세트를 확장할 수 있습니다.

왜 그럴까요?

• 서로 다른 선택에는 서로 다른 결과가 있어야 합니다. 인시던트 선언을 늦추면 고객 영향이 커질 수 있고, 롤백은 한 증상을 해결하지만 다른 문제를 드러낼 수도 있습니다.
• 분기형 경로를 통해, 동일한 초기 장애에서 최선·최악·이상한 케이스까지 다양한 전개를 탐색할 수 있습니다.

실제 운영 방식

1. Ink로 스토리 작성
   다음 요소를 정의합니다.

   • 핵심 장애 원인(예: 잘못 설정된 피처 플래그 + 캐시 스탬피드)
   • 의사결정 포인트(인시던트 선언 여부, 롤백/페일오버, 다른 팀 페이징 등)
   • 결과(그래프 변화, 고객의 불만 증가, 의존 서비스의 연쇄 장애 등)

2. 아날로그 방식으로 운영

   • 퍼실리테이터는 Ink 스크립트를 백그라운드용 가이드로 씁니다.
   • 팀이 어떤 행동을 선택하면, 퍼실리테이터는 해당 분기로 점프해 다음 아티팩트를 제시합니다.

3. 경로와 결과 기록

   • 이 팀은 어떤 분기 경로를 탔는가?
   • 어디서 막혔는가?
   • 가장 빠르거나 가장 안전한 해결 경로를 찾았는가?

이제 당신은 가이드되지만 유연한 연습을 손에 넣은 셈입니다. 여러 코호트에 반복해서 실행하면서도, 매번 살아 있는 듯한 전개를 유지할 수 있습니다.

시뮬레이션을 ‘카오스 실험’처럼 다루기

비록 전부 테이블탑에서 벌어지는 일이라 하더라도, 이 훈련은 프로세스와 아키텍처를 대상으로 하는 카오스 스타일의 실험으로 볼 수 있습니다.

이 과정에서 다음과 같은 것들이 드러납니다.

• 조직 차원의 SPOF(Single Point of Failure): “그 배치 잡 재시작 방법은 앨리스만 알아요.”
• 모니터링 블라인드 스팟: “이 큐 깊이(queue depth)를 보는 그래프가 아예 없네요.”
• 런북 부식(runbook decay): 존재하지 않는 도구나 담당자를 가리키는 단계들.
• 에스컬레이션 병목: 누가 롤백 승인권을 갖고 있는지, 누가 고객 공지를 내보낼 수 있는지 헷갈리는 상황.

핵심은 이 훈련을 평가 시험이 아닌 ‘실험’으로 취급하는 것입니다.

• 가설 세우기: “우리는 부분 리전 장애를 15분 안에 진단할 수 있다고 믿는다.”
• 시뮬레이션으로 검증
• 관찰 및 측정
• 문서, 오너십, 아키텍처를 개선

결국 시스템을 강화한다는 것은, 인간과 프로세스 레이어를 단단하게 만드는 일이기도 합니다.

트레인세트 계측하기: 로그, 히트맵, 코호트 비교

“재미있었다”에서 멈추지 않고 측정 가능한 개선으로 이어지게 하려면, 시뮬레이션에 약간의 계측을 더해야 합니다.

복잡한 도구는 필요 없습니다. 다음부터 시작해 보세요.

1. 액션 로그(Action log)
   훈련 중에 다음을 기록합니다.

   • 주요 이벤트의 타임스탬프(인시던트 선언, 첫 번째 완화 조치, 완전 복구 시점)
   • 의사결정(롤백 vs 롤 포워드, 페이징 시점, 어떤 메시지를 누구에게 전했는지)
   • 아티팩트 요청(어떤 데이터를 언제 요청했는지)

2. 스킬 히트맵(Skill heatmap)
   각 연습 후, 가볍게 1~5점 스케일로 평가합니다.

   • 기술적 진단 능력
   • 모니터링/로그 활용도
   • IC 리더십
   • 커뮤니케이션(내부 & 외부)
   • 팀 간 협업

   여러 세션에 걸쳐 시각화하면 스킬 히트맵이 만들어집니다. 이를 통해 다음을 볼 수 있습니다.

   • 특정 개인이 탁월한 영역(미래의 IC 후보나 멘토)
   • 팀 전체가 어려워하는 영역(예: 모두 로그를 거의 활용하지 않음)

3. 코호트 뷰(Cohort view)
   같은 시나리오를 서로 다른 코호트에 반복 실행합니다.

   • 다른 팀(백엔드 vs SRE vs 고객지원 등)
   • 다른 경력 수준(주니어 온콜 vs 시니어 온콜)

   그리고 다음을 비교합니다.

   • 인시던트 선언까지 걸린 시간
   • 루트 코즈(root cause)에 도달하기까지 걸린 시간
   • 첫 고객 커뮤니케이션까지 걸린 시간

이처럼 간단한 분석만으로도 아날로그 인시던트 컴퍼스 트레인세트를 한 번 하고 끝나는 이벤트가 아닌 학습 피드백 루프로 바꿀 수 있습니다.

오래 가져가는 연습으로 만들기: 주기와 문화

실질적인 가치를 내려면, 이런 훈련이 팀의 운영 문화의 일부가 되어야 합니다. 일회성 이벤트로 끝나서는 안 됩니다.

• 정기적으로 운영: 월 1회 또는 분기 1회, 시나리오와 참가자를 바꿔 가며 반복합니다.
• 비난이 아닌 학습을 정상화: 목표는 약점을 드러내고 고치는 것이지, 누구를 망신 주는 것이 아닙니다.
• 결과를 시스템에 반영:
  • 런북과 오너십 문서를 업데이트합니다.
  • 빠져 있던 대시보드나 알림을 추가합니다.
  • 필요하다면 인시던트 대응 정책을 조정합니다.

시간이 지나면 다음과 같은 변화가 보일 것입니다.

• 더 자신감 있는 온콜 엔지니어들
• 실제 인시던트에서의 ‘뜻밖의 놀람’ 감소
• 문제가 생겼을 때 더 빠르고 차분하며 조율된 대응

결론

아날로그 인시던트 컴퍼스 트레인세트의 아이디어는 단순합니다. 프로덕션 세계를 축소한 안전한 모형을 만들고, 거기에 의도적으로 장애를 흘려보내는 것입니다.

테이블탑 장애 훈련, 현실적인 아티팩트, 분기형 내러티브, 가벼운 계측을 결합하면 다음을 이룰 수 있습니다.

• 정적인 인시던트 계획을 실제 **근육 기억(muscle memory)**으로 바꾸기
• 프로덕션을 건드리지 않고 온콜 자신감 키우기
• 고객이 발견하기 전에 조직·기술적 갭을 찾아내기

시작하는 데 화려한 도구는 필요 없습니다. 종이, 사람, 그리고 인시던트를 ‘살아남는 기술’이 아니라 연습해서 단련할 수 있는 스킬로 바라보려는 태도만 있으면 됩니다.

당신만의 트레인세트를 만드세요. 일부러 서비스를 탈선시켜 보세요. 배운 것을 정리하고 반영하세요. 그러다 실제 선로 위의 진짜 열차가 흔들리는 날이 오더라도, 팀은 이미 어느 방향이 ‘북쪽’인지, 나침반이 어디를 가리키는지 잘 알고 있을 것입니다.