아날로그 인시던트 샌드테이블: 종이와 펜으로 다시 보는 프로덕션 장애

디지털 시스템, 불이 난 듯 긴박한 프로덕션 인시던트, 복잡한 마이크로서비스… 그런데 그걸 종이 건물과 손으로 그린 화살표만으로 해결하려고 한다면 어떨까요?

이게 바로 아날로그 인시던트 샌드테이블(Analog Incident Sandtable) 의 핵심 아이디어입니다. 의도적으로 저(低)기술에 머무른 채, 실제 장애를 다시 재생(replay)하고, 의존성을 탐색하며, 안전하고 반복 가능한 환경에서 조직적인 인시던트 대응을 연습하는 물리적 시뮬레이터입니다.

쿠버네티스 클러스터도, 관측(Observability) 대시보드도 없습니다. 필요한 건 펜, 종이, 테이프, 그리고 사람들뿐입니다.

이 글에서는 아날로그 인시던트 샌드테이블이 무엇인지, 어떻게 운영하는지, 그리고 이 deceptively simple(겉보기엔 단순한)한 기법이 다운타임 예방, 회복 탄력성, 인시던트 대비 문화에 어떤 큰 영향을 줄 수 있는지 살펴보겠습니다.

아날로그 인시던트 샌드테이블이란?

아날로그 인시던트 샌드테이블은 말 그대로 여러분의 프로덕션 환경을 위한 테이블탑(Tabletop) 시뮬레이터입니다.

군사 지도 위에 부대와 지형을 올려놓는 대신, 여러분은 다음과 같은 것들을 만듭니다.

주요 시스템과 서비스를 나타내는 종이 건물
(예: “Payments API”, “User Service”, “DB Cluster”, “Third‑Party Auth”)
컴포넌트 간 데이터가 어떻게 흐르는지를 보여주는 손으로 그린 트래픽 흐름(마커나 실 등)
알림, 사용자 제보, 로그, 상태 페이지 업데이트 등을 나타내는 포스트잇 같은 물리적 아티팩트

그다음 실제로 있었던 인시던트(또는 현실성 있는 시나리오)를 시간 순서대로 재생합니다.

무엇이 가장 먼저 실패했는가?
우리는 무엇을, 언제 알아챘는가?
누가 페이저를 받았는가?
어떤 액션들이 어떤 순서로 수행되었는가?
그 액션들이 시스템 상태와 블라스트 레디우스(영향 범위)를 어떻게 바꾸었는가?

목표는 모든 기술적 세부 정보를 1:1로 복원하는 것이 아닙니다. 대신 장애 상황에서의 원인과 결과, 그리고 사람 간 조정(coordination) 방식에 대한 공유된 멘탈 모델을 만드는 데 있습니다.

왜 하이테크 세상에서 로우테크를 택할까?

종이와 마커로 하는 연습은, 정교한 카오스 엔지니어링 도구나 풀 스테이징 환경에 비하면 원시적으로 보일 수 있습니다. 하지만 아날로그 형식에는 강력한 장점이 있습니다.

1. 놀라울 만큼 낮은 진입 장벽

누구나 참여할 수 있습니다. 엔지니어, 고객지원, PM, SRE, 온콜 리드, 심지어 임원까지.

프로덕션 접근 권한이나 특수한 툴이 필요 없습니다. 필요한 건:

테이블이나 화이트보드
종이/카드지
마커와 포스트잇

이렇게 하면 대화의 초점이 툴이 아니라, 시스템과 사람에게 맞춰집니다.

2. 속도를 늦춰 만드는 ‘공유 이해’

현실의 인시던트는 지저분하고 빠르게 전개됩니다. 라이브 인시던트 중에는 이런 질문을 할 여유가 거의 없습니다.

“잠깐, 이 백엔드랑 통신하는 서비스가 뭐고, 이 큐가 꽉 차면 정확히 무슨 일이 일어나지?”

샌드테이블은 여러분에게 속도를 늦출 수 있는 권한을 줍니다. 다음이 가능합니다.

언제든지 “잠깐만” 하고 멈추기
초보적인 질문을 마음껏 던지기
컴포넌트 위치를 옮겨 보기
상태 변화에 맞춰 흐름도를 다시 그려 보기

이 과정을 통해 사람들 머릿속에 흩어져 있던 멘탈 모델이 보이는 형태로 드러나고, 함께 토론할 수 있는 것이 됩니다.

3. 실패를 안전하게 탐색하기

실제 프로덕션에서 인시던트 중 실험을 하는 것은 매우 위험합니다.

하지만 샌드테이블에서는 이런 것들을 안전하게 탐색할 수 있습니다.

“만약 이 서비스가 가장 먼저 실패했다면?”
“이 알림이 10분 먼저 떴다면?”
“여기에 레이트 리밋이 걸려 있었다면?”

이는 사실상 카운터팩추얼(counterfactual, ‘그랬다면 어땠을까’) 시뮬레이션을 수행하는 것이고, 그 과정에서 실사용자에게는 아무 영향도 주지 않습니다.

아날로그 인시던트 샌드테이블 세팅하기

큰 예산도, 세밀한 플레이북도 필요 없습니다. 간단하게 시작하세요.

1단계: 실제 인시던트(또는 가치 높은 시나리오) 선정

다음 중 하나에 해당하는 인시던트를 고릅니다.

실제로 사용자에게 영향을 준 장애
복잡하거나 잘 보이지 않던 의존성을 드러낸 사건
팀 간 협업·조정 문제를 노출한 사건

혹은, 이미 알고 있는 리스크를 바탕으로 현실적인 시나리오를 설계해도 좋습니다.

핵심 데이터베이스 장애
주요 서비스의 배포 실패 롤아웃
서드파티 프로바이더(예: 결제, 인증) 장애

2단계: 시스템을 ‘종이 건물’로 매핑

인덱스 카드나 접은 종이에 다음을 적습니다.

코어 서비스
(예: API Gateway, Auth Service, Payments, Search)
데이터 저장소
(User DB, Orders DB, Redis Cache)
외부 의존성
(Payment Processor, Email Provider)

이들을 테이블 위에 올려두고, 실제 아키텍처를 대략적으로 반영하도록 배치합니다.

3단계: 트래픽 흐름 그리기

마커, 실, 화살표 등을 사용해 다음을 표현합니다.

요청 흐름 (web → API → services → DB)
비동기 흐름 (큐, 워커, 이벤트 버스)
중요한 의존 경로
(예: “checkout”이 동작하려면 반드시 살아 있어야 하는 것들)

처음부터 100% 정확도를 고집할 필요는 없습니다. 중요한 것은 눈에 보이는 것과 참여자 간의 합의입니다.

4단계: 시간과 신호를 도입하기

인시던트를 타임라인 형태로 재생합니다.

0분: 무언가가 실패함 (테이블 위에서 해당 요소를 명시적으로 표시)
X분: 첫 알림 발생 (온콜 카드 옆에 포스트잇 부착)
Y분: 고객이 오류를 제보하기 시작 (또 다른 포스트잇)
Z분: 완화 조치나 변경 작업 수행 (컴포넌트를 옮기거나 표시 변경)

시간이 흘러가면서 테이블을 함께 업데이트합니다.

실패한 컴포넌트는 색을 진하게 칠하거나 X 표시
성능 저하 또는 우회된 트래픽을 위해 새 화살표 추가
완화 조치, 롤백, 설정 변경 등을 노트로 추가

이 지점부터 이 테이블은 진짜 테이블탑 시뮬레이터로서 생동감을 갖게 됩니다.

무엇을 배우는가: 의존성, 결정, 그리고 역학

샌드테이블 세션은 단순히 과거를 재현하는 일이 아니라, 시스템과 조직이 실패에 어떻게 반응하는지 탐색하는 과정입니다.

서비스·시스템 의존성 정교화

인시던트를 따라가다 보면 다음과 같은 것들을 발견하게 됩니다.

숨겨진 의존성
“알림(notifications) 서비스가 이 DB에 의존하는 줄 몰랐다.”
묵시적 가정
“이 큐가 다른 워커 그룹으로 흘러가는 줄 알았다.”
취약한 결합
“사소해 보이는 이 기능이 실패하면 실제로는 checkout 전체를 막는다.”

이 인사이트를 바탕으로 이후 인시던트 대응이나 시뮬레이션에서 의존성을 더 정밀하게 반영할 수 있습니다.

더 정확한 런북과 다이어그램
개선된 내부 문서화
팀 간 **소유권 경계(ownership boundary)**를 더 명확히 설정

협업·조정 역학 이해하기

샌드테이블은 장애 상황에서 사람들이 어떻게 협업하고 소통하는지를 드러냅니다.

누가 누구에게, 언제 연락했는가?
의사결정은 어떻게 내려지고 공유되었는가?
어디에서 혼선·핸드오프 지연·모호함이 있었는가?

그리고 자주 다음과 같은 패턴이 보입니다.

두 팀이 같은 서브시스템을 서로 모르게 병렬로 디버깅함
중요한 의존성에 대해 아무도 명확하게 책임지고 있지 않음
“뭐가 실제로 망가졌는지”에 대한 멘탈 모델이 서로 어긋남

이 관찰들은 곧바로 인시던트 커맨드 구조, 커뮤니케이션 채널, 에스컬레이션 경로 개선으로 이어질 수 있습니다.

인사이트를 구체적인 완화책으로 바꾸기

좋은 아날로그 인시던트 샌드테이블 세션은 “재밌었다.”로 끝나지 않습니다. 구체적인 변화로 이어져야 합니다.

팀들은 세션 결과를 바탕으로 다음과 같은 완화책을 제안하고 우선순위를 매깁니다.

요구사항 변경
현실적인 장애 양상을 반영해 SLA, 타임아웃, 가용성 목표 등을 조정.
설계 및 아키텍처 개선
서킷 브레이커, 백오프가 있는 재시도, 벌크헤드, 점진적 성능 저하(graceful degradation),
의존성이 실패했을 때의 대체 플로우 등을 도입.
탐지·관측(Observability) 로직 개선
- 새로운(또는 더 잘 튜닝된) 알림 규칙
- 리소스 지표만이 아니라 사용자 영향 중심으로 설계된 대시보드
- 단순 프로세스 살아 있음 여부가 아니라, 실제 기능 동작을 반영하는 헬스 체크
운영 및 유지보수 프로세스 개선
- 고위험 컴포넌트에 대한 변경 관리 강화
- 정기적인 페일오버 테스트 또는 DR(Disaster Recovery) 연습
- 더 나은 런북과 표준 운전 절차(SOP) 정비

각 완화책은 샌드테이블에서 관찰한 구체적인 실패 양상과 지연 지점에 근거합니다.

회복 탄력성과 인시던트 대비 문화를 쌓는 방법

아날로그 인시던트 샌드테이블은 한 번 하고 끝내는 액티비티가 아닙니다.
시간이 지날수록 반복 세션은 더 넓은 조직적 목표를 직접적으로 뒷받침합니다.

1. 다운타임 예방과 더 빠른 복구

실제 인시던트를 반복 연습하면서 팀은 다음을 익힙니다.

다음 장애를 일으킬 수 있는 약한 고리를 미리 발견
대체 완화 경로와 우회 전략에 익숙해짐
“모든 게 불타고 있을 때” 어떤 신호를 먼저 믿어야 하는지 학습

이는 실제 인시던트가 다시 발생했을 때 더 빠르고 조율된 대응으로 이어집니다.

2. 실패를 학습 기회로 ‘정상화’하기

인시던트를 수치스러운 예외적인 사건으로 대하는 대신, 샌드테이블 세션은 그것을 가치 있는 연습 자료로 재구성합니다.

팀은 이렇게 말하게 됩니다.

“장애가 났다. 샌드테이블에 올려서 배우고, 더 나아지자.”

이 방식은 비난을 줄이고 솔직한 회고와 학습을 장려합니다.

3. 교육·지식 격차 드러내기

이 연습은 자연스럽게 어디에 교육이 부족한지 드러냅니다.

코어 시스템 동작 방식을 잘 모르는 사람들
알림 의미나 로그 해석에 대한 혼란
프로덕트·지원·엔지니어링 사이의 모호한 핸드오프

이 정보를 바탕으로, 다음 실제 인시던트가 오기 전에 필요한 교육·온보딩 자료를 타겟팅해서 만들 수 있습니다.

효과적인 세션을 위한 실용 팁

아날로그 인시던트 샌드테이블에서 최대 효과를 얻으려면 다음을 권장합니다.

소규모지만 크로스펑셔널하게: 5–10명 정도, 실제 인시던트를 겪은 사람 1명 이상, 그리고 당시 참여하지 않았던 사람 몇 명을 섞기
시간 제한 두기: 한 인시던트를 깊게 다루는 데 60–90분이면 충분
퍼실리테이터 지정: 타임라인을 이끌고, 시간을 관리하며, 말이 적은 사람의 의견도 이끌어내는 역할
배움을 실시간으로 기록: 별도 보드나 문서에 “발견 사항(Findings)”과 “잠재적 완화책(Potential Mitigations)”을 분리해 적기
마지막엔 우선순위 정하기:
“비슷한 인시던트의 영향을 가장 많이 줄일 2–3가지 변화는 무엇인가?”를 묻고, 각 항목에 대한 오너와 다음 단계를 명확히 기록

결론: 종이가 만들어내는 회복 탄력성 엔진

아날로그 인시던트 샌드테이블은 겉으로 보면 단순합니다.
테이블 위의 종이 건물, 손으로 그린 화살표가 전부니까요.
하지만 그 단순함 속에는 다음을 가능하게 하는 강력한 메커니즘이 숨어 있습니다.

복잡한 시스템을 이해 가능한 형태로 바꾸기
위험 없이 인시던트 대응을 연습하기
의존성과 실패 모드에 대한 모델을 정교하게 가다듬기
실제 장애에서 더 빠르고 조율된 반응을 이끌어내기
회복 탄력성과 대비 문화를 강화하기

새로운 툴을 도입할 필요도 없습니다. 과거 인시던트 하나를 고르고, 팀을 모으고, 테이블을 치우고, 시스템을 그려 보세요.

그리고 그 장애를 다시 재생해 보십시오. 이번에는 언제든지 멈추고, 되감고, 여러분의 시스템과 팀이 진짜 중요한 순간에 어떻게 반응해야 할지를 다시 설계할 수 있는 공간에서 말입니다.