아날로그 인시던트 이스케이프 룸: 실제로 터지기 전에 장애를 팀이 함께 푸는 현장 퍼즐로 바꾸기

어느 팀에나 한 번쯤은 크게 망가진 장애 대응의 공포 스토리가 있습니다. 모니터링 알람은 사방에서 터지고, 슬랙 채널은 폭발하고, 서로의 일을 방해하며 우왕좌왕하고, 누구도 다음에 뭘 해야 할지 확신이 없는 상황 말이죠. 끝나고 나서는 늘 “드릴을 더 자주 하자”, “인시던트 대응 프로세스를 개선하자”라고 다짐하지만, 다음 실제 장애가 오면 여전히 혼란스럽습니다.

그렇다면, 이런 혼돈 그 자체를 실제 시스템에 피해를 주지 않는 저위험·고재미 아날로그 방식으로, 미리 리허설할 수 있다면 어떨까요?

이게 바로 **아날로그 인시던트 이스케이프 룸(Analog Incident Escape Room)**의 아이디어입니다. 실제 서비스 장애를, 팀이 함께 푸는 이스케이프 룸 스타일의 테이블탑(탐탁) 시뮬레이션으로 설계하는 것이죠. 이렇게 하면, 원래는 스트레스 높은 고위험 시나리오를 재미있고 협업적인 연습 게임으로 바꿔, 실제 장애가 터지기 훨씬 전부터 팀의 절차·커뮤니케이션·자신감을 튼튼하게 만들 수 있습니다.

왜 아날로그인가? (그리고 왜 잘 통하는가)

현대 시스템에서 디지털 혼란은 당연한 일처럼 느껴지지만, 아날로그 방식의 연습에는 의외의 강점이 있습니다.

• 저위험: 연습에서 하는 어떤 행동도 실제 프로덕션을 망가뜨리지 않습니다.
• 높은 몰입도: 실제 종이 문서, 프린트 물, “단서”들이 교육이 아니라 게임처럼 느껴집니다.
• 집중의 공유: 모두가 같은 화이트보드, 출력물, 단서를 보고 있을 때 협업이 더 자연스럽게 이뤄집니다.
• 심리적 안전감: 전부 가짜 상황이라는 걸 알기 때문에, 질문을 하거나 실수하는 데 부담이 덜합니다.

목표는 종이나 소품으로 관측/모니터링 스택을 완벽하게 복제하는 것이 아닙니다. 연습하고 싶은 것은 **“팀이 어떻게 반응하는가”**입니다. 팀이 어떻게 커뮤니케이션하고, 어떻게 시끄러운 신호를 해석하고, 언제 에스컬레이션하고, 시간 압박 속에서 어떻게 결정을 내리는지를 연습하는 것이죠.

이걸 다음 두 가지의 하이브리드라고 생각해보세요.

• 이스케이프 룸 – 제한된 시간, 단서 기반, 협력형 퍼즐
• 테이블탑 인시던트 대응 연습 – 가이드가 있고, 현실적인 시나리오를 기반으로 한 훈련

1단계: 현실적이고 우리 팀에 맞는 시나리오부터 만들기

가장 효과적인 아날로그 인시던트 이스케이프 룸은, 여러분 조직 입장에서 불편할 만큼 현실적인 느낌이 나야 합니다.

시나리오는 실제 여러분의 환경을 최대한 반영해야 합니다. 예를 들어:

• 시스템과 아키텍처 – 마이크로서비스, 모놀리스, 큐, 캐시, 써드파티 API 등
• 위협 환경(Threat Landscape) – DDoS, 크리덴셜 탈취, 설정 오류, noisy neighbor, 의존성 장애 등
• 고장 패턴(Failure modes) – 자주 나오는 버그, 알려진 병목, 취약한 컴포넌트, 아슬아슬하게 넘어갔던 과거 장애 직전 상황들

시나리오 아이디어 예시

• 평범한 설정 변경 하나가, 핵심 API에서 간헐적인 500 오류를 발생시키는 경우
• 데이터베이스 인덱스가 실수로 삭제되어, 쿼리가 느려지고 타임아웃이 속출하는 경우
• 잘못 설정된 피처 플래그로 인해, 성능에 부담이 큰 기능이 한 번에 전체 사용자에게 롤아웃되는 경우
• 써드파티 인증 서비스에 부분 장애가 나서 로그인 실패가 늘어나는 경우

각 시나리오는 실제 여러분 환경에서 충분히 일어날 수 있는 일이어야 합니다. 다만, 재미를 위해 약간 드라마를 과장하는 정도는 괜찮습니다.

2단계: 테이블탑 인시던트 연습처럼 설계하기

잘 만든 이스케이프 룸은 겉으로 보기엔 자연스럽지만, 실제로는 아주 치밀하게 설계되어 있습니다. 아날로그 인시던트도 마찬가지로 접근해야 합니다.

진행 전에, 아래 질문에 먼저 답해보세요.

1. 목표(Objectives): 무엇을 테스트하거나 연습하고 싶은가?

   • 특정 서비스에 대한 온콜(ON-CALL) 트리아지?
   • 1차 지원(고객지원/CS)에서 SRE로의 핸드오프?
   • 개발·운영·보안 팀 간의 협업/조율?

2. 범위(Scope): 이 인시던트의 스케일은 어느 정도인가?

   • 단일 서비스 성능 저하 vs 전체 시스템 마비
   • 한 팀만 대응 vs 여러 조직이 엮인 크로스펑셔널 대응

3. 역할(Roles): 누가 어떤 역할을 맡는가?

   • 인시던트 커맨더(Incident Commander, IC)
   • 커뮤니케이션 리드(상태 공지/아웃리지 업데이트 담당)
   • 주요 시스템의 테크 리드(Tech Lead)
   • 옵저버/퍼실리테이터(진행자, 당신)

4. 서사(Narrative arc): 시간이 지나면서 인시던트는 어떻게 전개되는가?

   • 초기 증상은 무엇인가?
   • 중간에 잘못된 방향으로 이끄는 단서는 무엇인가?
   • 나중에 어떤 새로운 정보(예: 벤더 이메일)가 등장하는가?

그럴듯한 스토리로 타임라인 짜기

인시던트를 간단한 타임라인으로 스크립트처럼 작성해 보세요.

• T + 0: 모니터링 알람 + 사용자 문의/제보 발생
• T + 5: 대시보드에서 평소와 다른 메트릭 변화 감지
• T + 10: 에러 로그가 특정 방향을 암시 (하지만 완전한 해답은 아님)
• T + 20: 핵심 단서 등장 (예: 변경 이력, 벤더 인시던트 공지 등)
• T + 30+: 루트 원인을 발견할 수 있고, 완화/복구 조치를 적용할 수 있는 상태

각 단계는 다음과 같은 형태로 표현할 수 있습니다.

• 봉투에 넣은 단서
• 출력된 스크린샷
• 로그 조각(log snippet)
• “티켓”이나 이메일 형태의 카드

이것들을 시간 경과에 따라 혹은 참가자가 적절한 질문을 했을 때 순차적으로 건네주면 됩니다.

3단계: 연습을 ‘퍼즐’로 설계하기

이스케이프 룸 느낌을 살리려면, 참가자가 단서를 발견하고 추론해야만 다음으로 진행되도록 만들어야 합니다. 그냥 자료를 한 번에 전부 던져주는 방식이 아니어야 합니다.

핵심 퍼즐 요소

• 단서(Clues): 다음 같은 형태의 인쇄물

  • 시계열 그래프가 있는 가짜 대시보드
  • 단순화된 로그 발췌본
  • 변경 요청서 / Git diff 출력물
  • 일부 내용이 비어 있거나 애매하게 작성된 런북 페이지
  • 벤더 상태 페이지(상태 페이지) 스크린샷

• 잠금 장치(Locks): 참가자의 추론이나 협업을 통해서만 풀 수 있는 제약

  • 누군가 “DB는 어떤 상태지?”라고 구체적으로 물어보기 전까지는, “DB 로그”를 볼 수 없음
  • 누군가 “최근에 뭐가 바뀌었지?”라고 질문해야만 열리는, 봉인된 변경 이력 봉투
  • 중요한 런북 페이지가 종이 퍼즐처럼 잘려 있어서, 조각을 맞춰야 전체 내용을 볼 수 있게 하기

• 시간 압박: 눈에 잘 보이는 타이머(프로젝터, 스마트폰, 주방 타이머 등)를 사용해 45–60분 정도의, 현실적이지만 약간 빠듯한 제한 시간을 둡니다.

• 게이미피케이션(Gamification):

  • 좋은 행동에 점수를 부여 (IC를 명확히 선언, 커뮤니케이션 주기 설정, 고객 영향 질문 등)
  • 점수나 시간을 소모해서만 얻을 수 있는 “보너스 단서” 추가

이 구조는 팀이 단순히 정답지를 읽는 것이 아니라, 실제처럼 정보 수집, 우선순위 판단, 가설 수립과 검증을 연습하도록 만듭니다.

4단계: 기술 스킬만이 아니라, 절차와 커뮤니케이션을 검증하기

목표는 누가 로그를 가장 빨리 해석하는지 겨루는 것이 아닙니다. 스트레스 상황에서 우리 조직의 프로세스와 커뮤니케이션 경로가 실제로 작동하는지 확인하는 게 핵심입니다.

연습 설계 시, 다음과 같은 질문이 자연스럽게 드러나도록 만들어 보세요.

• 사람들이 누가 IC를 맡는지, 그리고 그 역할이 무엇인지 알고 있는가?
• 단일 커뮤니케이션 채널을 설정하는가? (예: 전용 슬랙 채널, 한 명의 기록 담당자)
• **인시던트 심각도(Severity)**를 선언하고, 그에 따라 행동을 조정하는가?
• 기존 런북을 따르는가? 어느 부분이 없거나 헷갈리는가?
• 단순히 에러율만 보는 것이 아니라, 고객 영향과 비즈니스 리스크도 고려하는가?

참가자에게는 이렇게 분명히 말해줄 수 있습니다.

“우리는 개인의 지식 수준을 평가하는 게 아니라, 프로세스를 점검하는 중입니다. 모르는 티를 내도 괜찮고, 그게 바로 시스템을 개선하는 출발점입니다.”

5단계: 토론 중심과 운영 중심 요소를 섞어서 구성하기

대화만 하다 보면 논의가 산으로 갈 수 있습니다. 반대로, 퍼즐만 풀다 보면 전략적 의사결정 연습이 부족해질 수 있습니다. 두 가지를 적절히 섞는 것이 좋습니다.

토론(Discussion) 중심 요소

• IC에게 주요 결정을 소리 내어 설명하게 합니다.
  • “왜 Y보다 X를 먼저 확인하기로 했나요?”
• 중요한 포인트마다 잠시 멈추고 질문합니다.
  • “지금 시점에서 고객에게 어떤 메시지를 전달하겠습니까?”
  • “현재 생각하고 있는 롤백 또는 완화(미티게이션) 계획은 무엇입니까?”
  • “지금 가설이 틀렸다면, 어떤 다른 리스크가 있을까요?”

운영(Operational) 중심 요소 – 종이 위에서 구현하기

• 팀에게 화이트보드에 간단한 인시던트 타임라인을 직접 작성하게 합니다.
• 상태 공지(Status Update) 템플릿(내부용/외부용)을 제공하고, 실제로 내용을 채워보게 합니다.
• 일부러 중간 단계가 빠져 있는 런북을 제공하여, 참가자가
  • 빠진 단계를 눈치채고
  • 그대로 진행할지, 수정할지, 에스컬레이션할지 스스로 결정하도록 유도합니다.

이렇게 하면, 의사결정과 기술적 트리아지(진단/조사) 두 능력을 동시에 연습하게 됩니다.

6단계: 구조화된 회고(디브리프)를 진행하기 – 진짜 가치는 여기서 나온다

이 연습의 마법은 게임 그 자체보다, 끝나고 나서의 되돌아보기에 더 많이 담겨 있습니다.

연습이 끝나면, 바로 30–45분 정도의 구조화된 디브리프를 진행하세요.

1. 사실(Facts)부터 정리하기

• 시나리오에서 실제로 어떤 일이 발생했는가?
• 팀은 이에 어떻게 대응했는가? 단계별로 정리해 보기

2. 잘된 점(What Worked Well)

• 어떤 부분에서 커뮤니케이션이 매끄럽게 흘렀는가?
• 어떤 절차나 런북이 실제로 도움이 되었는가?
• 특히 효과적이었던 결정은 무엇이었는가?

3. 문제점/한계(Where Things Broke Down)

• 헷갈리거나 빠져 있었던 런북 단계
• 불명확했던 책임 구분이나 에스컬레이션 경로
• 연습을 통해 드러난 툴링/관측성(Observability) 부족

4. 구체적인 개선 사항(Concrete Improvements)

인사이트를 실제 행동 계획으로 전환합니다.

• 런북을 업데이트하거나 새로 작성하기
• 인시던트 역할과 책임을 더 명확히 정의하기
• 알림/대시보드를 조정하기
• 이번에 드러난 약점을 겨냥한 향후 드릴 계획 세우기

그리고 결과를 실제 사후 인시던트 리뷰(Post-Incident Review) 문서처럼 기록하세요. 목표는 다음과 같습니다.

다음번에는, 시뮬레이션도 실제 인시던트도 지금보다 훨씬 더 잘 대응할 수 있게 하는 것.

7단계: 재미있고 누구나 참여할 수 있게 만들기

이 연습이 “필수 교육”처럼 느껴지면, 참여도와 기억에 남는 정도가 크게 떨어집니다. 이스케이프 룸 게임의 에너지를 과감하게 끌어오는 편이 좋습니다.

몰입도를 높이는 아이디어들:

• 출력물/소품 활용:

  • 인시던트 “케이스 파일” 폴더
  • 가짜 티켓, 이메일, 상태 페이지 공지
  • 큼직하고 단순화된 메트릭 그래프

• 테마 설정:

  • 연습에 이름 붙이기 (예: “Operation Vanishing Packets”, “사라진 인덱스의 미스터리” 등)
  • 서비스에 재치 있는 코드네임 붙이기

• 시간 기반 챌린지:

  • 미니 마일스톤 지정 (예: “3분 안에 IC를 지정하라”, “10분 안에 첫 내부 공지를 보내라”)

• 포용적인 설계:

  • 비엔지니어도 참여할 수 있는 역할 제공: 고객지원, 제품, 커뮤니케이션, 심지어 리더십까지
  • 특정 한 명만 풀 수 있는, 지나치게 깊고 좁은 기술 퍼즐은 피하기

사람들은 문서나 슬라이드보다 이야기와 게임을 훨씬 더 잘 기억합니다. 경험이 즐거울수록, 팀은 그 안에서 배운 교훈을 더 깊이 내재화하게 됩니다.

시작하기: 가장 단순한 첫 번째 시도 예시

처음부터 거대한 프로젝트를 할 필요는 없습니다. 가벼운 1차 버전은 다음과 같은 형태여도 충분합니다.

1. 과거 실제 장애를 바탕으로, 현실적인 인시던트 시나리오를 하나 고른다.
2. 30–45분 분량의 타임라인을 만들고, 6–8개 정도의 인쇄 가능한 단서를 준비한다.
3. 다양한 직무에서 4–8명을 초대한다.
4. 타이머를 세팅하고, 역할을 할당한 뒤 시뮬레이션을 진행한다.
5. 바로 이어서 디브리프를 진행하고, 개선 사항을 기록한다.

그다음부터는 여기서 배운 것들을 토대로 점차 확장해 나가면 됩니다. 시나리오를 더 복잡하게 만들거나, 여러 팀을 얽히게 하거나, 보안 인시던트에 초점을 맞추는 식으로 조직의 성숙도에 맞춰 발전시킬 수 있습니다.

결론: 진짜 혼돈이 오기 전에, 먼저 혼돈을 연습하라

프로덕션 인시던트는 언젠가 반드시 일어납니다. 하지만, 그때마다 패닉에 빠질 필요는 없습니다.

장애를 아날로그 이스케이프 룸 스타일 시뮬레이션으로 바꾸면, 팀에게 다음을 제공할 수 있습니다.

• 안전한 환경에서의 리허설 기회
• 재미있고 몰입감 있는 방식으로 쌓는 대응 근육(Muscle Memory)
• 실제 고객에게 피해가 가기 전에, 프로세스·툴링·커뮤니케이션의 빈틈을 찾을 수 있는 현실적인 방법

이 세션들을 실제 인시던트만큼이나 진지하게 다루세요.

• 치밀하게 계획하고,
• 정기적으로 실행하고,
• 꼼꼼하게 디브리프하세요.

시간이 지나면 변화를 체감하게 될 것입니다. 인시던트 지표뿐 아니라, 다음 알람이 울렸을 때 팀이 보여주는 침착하고 자신감 있는 대응에서도 말이죠.

그날이 오면, 상황은 예전처럼 완전한 혼돈으로 느껴지기보다는,

팀이 이미 몇 번이나 연습해 본, 풀 줄 아는 퍼즐처럼 느껴질 것입니다.