아날로그 인시던트 섀도우박스: 일어나기 전에 다음 장애를 종이 디오라마로 만들어 보기

현대의 시스템은 아주 현대적인 방식으로 실패합니다. 분산돼 있고, 불투명하며, 엄청난 속도로 망가집니다. 그런데 이런 실패를 이해하는 데 가장 강력한 도구 중 하나는 놀라울 만큼 저기술입니다. 종이, 마커, 테이프, 그리고 사람들로 가득 찬 방이 전부입니다.

이 글에서는 **“아날로그 인시던트 섀도우박스(analog incident shadowbox)”**라는 아이디어를 소개합니다. 아직 일어나지 않은 가상의 장애를 미리 종이 디오라마 형태의 물리적인 보드로 만들어 보는 것입니다. 이를 **프리모텀(pre‑mortem)**과 **테이블탑 시뮬레이션(tabletop simulation)**과 함께 사용하면, 팀이 실제 인시던트를 예측·방지·대응하는 수준을 극적으로 끌어올릴 수 있습니다.

프리모텀(pre‑mortem)이란? (그리고 왜 포스트모텀만으로는 부족한가)

대부분의 팀은 **포스트모텀(post‑mortem)**에 익숙합니다. 인시던트가 발생하고, 모두가 불을 끄느라 분투한 뒤, 사후에 무엇이 잘못됐는지 분석하는 방식입니다. 필수적이지만, 어디까지나 사후 대응입니다. 이미 대가를 치른 뒤에야 배우게 되니까요.

**프리모텀(pre‑mortem)**은 이 순서를 뒤집습니다.

가까운 미래에 큰 장애가 이미 발생했다고 가정합니다.
(예: “지금으로부터 3개월 뒤, 우리의 주요 데이터센터가 12시간째 완전히 다운돼 있다.”)
그리고 그 지점에서 거꾸로 거슬러 올라가며 묻습니다.
“어떤 일들이 벌어졌기에 우리가 이런 상황에 처했을까?”

이런 전향적인 분석을 통해 팀은 다음을 할 수 있습니다.

일상 업무에서는 잘 보이지 않는 위협과 취약점을 선제적으로 식별
아키텍처와 프로세스 속에 숨어 있는 숨은 의존성과 취약 지점을 드러냄
“당연히 페일오버는 잘 될 거야” 같은 과도한 낙관·가정을 도전하며 계획을 날카롭게 다듬음

프리모텀만으로도 충분히 강력하지만, 여기에 물리적인 형태를 더하면 훨씬 더 생생하고 오래 기억에 남습니다.

화이트보드에서 섀도우박스로: 왜 굳이 물리적으로 만들까?

우리는 시스템을 그릴 때 보통 화이트보드나 Miro, Lucidchart 같은 도구를 씁니다. 유용하지만, 종종 너무 추상적인 수준에 머무릅니다. 인시던트 섀도우박스는 가상의 장애를 눈앞에서 보고, 손으로 직접 옮겨 볼 수 있는 것으로 바꿉니다.

이걸 **“다음 장애의 종이 디오라마”**라고 생각해 보세요.

각 서비스, 시스템, 외부 의존성은 카드나 종이 조각으로 표현합니다.
화살표나 실(끈)로 데이터 플로우, 신뢰 관계, 장애 전파 경로를 나타냅니다.
스티키 노트에는 시간에 따라 발생하는 이벤트, 결정, 결과를 적어 붙입니다.

이 방식이 특히 잘 작동하는 이유:

손에 잡히면 복잡성이 드러난다
모든 컴포넌트를 직접 배치해 보면, 어디가 밀집돼 있고, 취약하며, 모호한지 금방 보입니다.
스토리가 생기면 명료해진다
단순한 시스템 다이어그램이 아니라 실패의 이야기를 만듭니다.
누가 가장 먼저 이상을 감지하는지, 무엇이 다음에 깨지는지, 블라스트 레이디어스(피해 반경)가 어디로 번지는지를 따라갑니다.
공유된 멘탈 모델
물리적인 섀도우박스는 엔지니어, 보안, 운영, 프로덕트, 고객 지원, 리더십 모두에게 직관적입니다.
모두가 같은 것을, 정말로 손가락으로 가리키며 이야기할 수 있습니다.
로우테크지만 시그널은 높게
종이·테이프·마커는 적당한 수준의 불편함과 마찰을 만들어, 더 의도적으로 생각하게 만듭니다.
또 다른 레이어나 드롭다운 뒤에 복잡성을 숨겨 버릴 수 없습니다.

아날로그 인시던트 섀도우박스 만드는 법

필요한 건 많지 않습니다.

넓은 벽이나 화이트보드
인덱스 카드 또는 종이 조각
마커, 실(끈), 테이프, 스티키 노트

이제 간단한 프로세스를 따라가면 됩니다.

1. 가상의 재난 시나리오 정하기

먼저 명확하고 생생한 시나리오를 하나 고릅니다. 예를 들면:

“주요 데이터베이스 클러스터가 새벽 2시에 복구 불가능한 손상을 입었다.”
“도난된 OAuth 토큰으로 인해 대규모 데이터 유출 사고가 발생했다.”
“라우팅 설정 오류로 EU 리전이 6시간 동안 고립됐다.”

이 시나리오는 이미 일어난 일처럼 프레이밍합니다.

“오늘은 9월 15일이다. 우리는 10시간째 완전 장애 상태다. 고객들은 분노하고 있고, 규제 기관은 질문을 쏟아내고 있다. 도대체 무슨 일이 있었던 걸까?”

2. 시스템을 카드와 플로우로 매핑하기

먼저 핵심 컴포넌트를 카드로 만들어 벽에 배치합니다.

코어 서비스 (API Gateway, Auth Service, Payment Processor 등)
데이터스토어와 캐시
써드파티 의존성 (CDN, Identity Provider, Payment Gateway 등)
모니터링·로깅·알림 시스템
사람과 역할 (온콜 엔지니어, 인시던트 커맨더, 보안 리드, 고객 지원 등)

그리고 화살표나 실로 다음을 표현합니다.

데이터 플로우: 누가 누구와 통신하는지
트러스트 바운더리(trust boundary): 보안 가정이 달라지는 경계
싱글 포인트 오브 페일리어(SPOF): 모든 흐름이 한 카드에 집중되는 지점

3. 섀도우박스를 통해 프리모텀 수행하기

이제 시나리오를 시간 순서대로 따라가며 걸어 봅니다.

트리거(Trigger): 맨 처음 무엇이 잘못되나요?
해당 카드를 뒤집거나 이동시키며 장애를 표현합니다.
전파(Propagation): 그로 인해 무엇이 연쇄적으로 장애를 일으키나요?
화살표를 끊고, 새 에러를 스티키 노트로 추가합니다.
탐지(Detection): 누가 가장 먼저 눈치채나요?
첫 알림은 어디에서 발생하나요? (혹은 아예 발생하지 않나요?)
대응(Response): 온콜 엔지니어는 무엇을 하나요?
어디를 먼저 살펴보고, 어떤 툴이 예상과 다르게 동작하나요?
에스컬레이션(Escalation): 누가 추가로 투입되나요?
어떤 팀들이 이제 이 스토리에 합류하나요?
고객 영향(Customer impact): 외부에서는 장애가 어떻게 드러나나요?
API 에러? 느려진 대시보드? 데이터 불일치?

각 단계마다 섀도우박스에 스티키 노트로 주석을 남깁니다.

가정(Assumptions)
(예: “세컨더리 리전은 5분 이내 자동 승격된다고 가정한다.”)
질문(Questions)
(예: “이 페일오버 경로에 대한 런북(runbook)이 있는가?”)
갭(Gaps)
(예: “이 이벤트는 중앙에서 수집되는 로그가 없다.”)

지금 하는 일은 단순히 인시던트를 “해결하는 것”이 아니라,
그 인시던트가 도대체 어떻게 해서 가능해지는지 발견하는 과정입니다.

이를 테이블탑 시뮬레이션으로 확장하기

디오라마가 완성됐다면 이제 테이블탑(Tabletop) 스타일 연습을 할 준비가 된 겁니다.
테이블탑 연습은 보안과 인시던트 대응에서 흔히 쓰이는 방식으로, 위험이 없는 환경에서 시나리오를 시뮬레이션하며 실제로 어떻게 반응할지 연습합니다.

섀도우박스를 이 테이블탑 연습의 ‘보드’로 사용합니다.

퍼실리테이터(Facilitator): 시나리오를 이끌며 새로운 이벤트를 드러냅니다.
(예: “조사 결과, 백업도 손상되어 있다는 사실을 알아냅니다.”)
참여자(Participants): 온콜 엔지니어, SRE, 보안팀, 프로덕트, 고객 지원, 관련 리더십 등
아티팩트(Artifacts): 실제로 사용할 런북, 대시보드, 에스컬레이션 경로, 인시던트 관리 도구 등

섀도우박스 기반 테이블탑의 장점

안전한 연습, 현실적인 압박감
실제 고객에게 피해를 주지 않고도 긴장감과 불확실성을 체험하며 실수해 볼 수 있습니다.
보안·탄력성(Resilience) 갭을 드러냄
다음과 같은 것들이 드러나게 됩니다.
- 빠진 알림과 부재한 런북
- 모니터링되지 않는 중요 경로
- 특정 개인에게 과도하게 의존하는 구조
  (예: “그냥 Alex 부르면 돼요. 로그 위치는 항상 Alex가 알아요.”)
크로스펑셔널 협업 개선
여러 조직이 함께 참여하면 다음이 보입니다.
- 보안과 운영이 서로 다른 가정을 하고 있는 지점
- 프로덕트·고객 지원팀이 적시에, 명확한 정보를 받지 못하는 구간
- 리더십이 너무 일찍 혹은 너무 늦게 개입하는 패턴
필요해지기 전에 절차를 정교하게
모두가 시뮬레이션 내용을 생생히 기억하고 있을 때,
인시던트 런북, 에스컬레이션 트리, 커뮤니케이션 템플릿을 바로 업데이트할 수 있습니다.

대시보드에서는 보이지 않는 것들을 배우게 된다

섀도우박스 연습은 보통 조용하지만 위험한 현실을 수면 위로 끌어올립니다.

알려지지 않은 싱글 포인트 오브 페일리어
특정 큐, 서비스, 혹은 한 사람에게만 의존하고 있는 구조
숨은 결합(Hidden coupling)
“관련 없다”고 생각했던 두 시스템이, 시나리오상 항상 함께 망가지는 관계
부족한 가시성(Observability)
로그도, 메트릭도, 알림도 없는 전체 플로우
취약한 프로세스
누군가의 머릿속이나 잊혀진 내부 문서에만 존재하는 핵심 단계
커뮤니케이션 병목
채널이 너무 시끄러워지거나, 필요한 사람에게 정보가 끝내 전달되지 않는 구조

이런 인사이트는 실제 장애가 나기 전에 발견해 고치는 편이 훨씬 쉽고 비용도 적게 듭니다.

가상의 실패를 실제 개선으로 바꾸기

이 모든 작업의 목적은 예쁜 아트 프로젝트를 만드는 것이 아닙니다.
궁극적으로는 구체적인 변화를 이끌어 내기 위한 것입니다. 세션이 끝나면 다음을 정리하고 우선순위를 매기세요.

설계·아키텍처 개선
- 진짜 싱글 포인트 오브 페일리어에 대한 이중화·Redundancy 추가
- 과하게 밀접하게 결합된 서비스를 단순화하거나 디커플링(decoupling)
- 트러스트 바운더리와 최소 권한(Least Privilege) 모델 재검토
프로세스·문서 업그레이드
- 이번에 다룬 시나리오에 대한 런북 생성·업데이트
- 인시던트 커맨드 구조와 에스컬레이션 규칙 정교화
- 고객 및 내부 이해관계를 위한 커뮤니케이션 템플릿 개선
툴링·가시성(Observability) 강화
- 시나리오의 조기 신호를 포착할 알림 추가·개선
- 실패 스토리와 정렬된 대시보드·로그 체계 개선
- 연습 과정에서 드러난 반복적이거나 느린 수동 작업을 자동화
교육·준비도 향상
- 다양한 사람이 인시던트 커맨더 역할을 돌아가며 맡아보게 하기
- 결과를 바탕으로 온콜 트레이닝을 가장 위험한 영역에 집중
- 다른 개연성 높은 재난 시나리오로 섀도우박스 연습 반복

시간이 지날수록, 이런 변화는 실제 인시던트의 발생 가능성과 영향도를 모두 줄여 줍니다.

일회성이 아니라 습관으로 만드는 방법

이 관행을 팀 문화에 녹이려면 다음을 고려해 보세요.

주요 릴리스나 마이그레이션 이전에 섀도우박스 기반 프리모텀을 수행
가장 큰 리스크 시나리오에 대해 분기별 테이블탑 시뮬레이션을 정례화
신규·주니어 팀원도 돌아가며 참여시켜 경험과 자신감을 높이기
잘 만든 섀도우박스는 사진을 찍거나 일부를 남겨 두어
온보딩용 교육 자료로 활용

투입되는 것은 보통 몇 시간과 간단한 문구류 정도지만,
그에 비해 탄력성(resilience)과 협업 능력 향상 효과는 매우 큽니다.

결론: 더 빠르게 달리기 전에, 먼저 ‘충돌’을 그려 보라

성능이 뛰어난 팀은 단지 인시던트를 잘 수습하는 팀이 아닙니다.
다가오는 인시던트를 미리 보는 능력이 뛰어난 팀입니다.
아날로그 인시던트 섀도우박스는 추상적인 리스크를 조직 전체가 이해할 수 있는, 공유된 구체적 이야기로 바꿔 줍니다.

다음 세 가지를 결합하면:

이미 실패가 일어났다고 가정하는 프리모텀,
연쇄적인 영향을 눈으로 보여 주는 종이 디오라마,
팀이 안전하게 연습할 수 있는 테이블탑 시뮬레이션,

실제 고객에게 피해가 가기 전에, 시스템과 프로세스의 약점을 찾아내고 고칠 수 있습니다.

복잡한 디지털 실패를 이해하는 가장 강력한 방법이,
어쩌면 여전히 벽에 종이를 잔뜩 붙이고 사람들을 모아 이렇게 묻는 것일 수 있습니다.

“만약 이게 정말 최악으로 망가진다면, 그 이야기는 어떻게 흘러갈까?”

그다음 가위와 테이프를 들고, 그 이야기를 끝까지 만들어 보세요.
단, 이번에는 마지막 결말을 바꿀 수 있을 때까지 만들어 가는 것이 목표입니다.