아날로그 장애 스토리 조차장 설계도: 손으로 복잡한 장애를 디버깅하는 테이블탑 철도 만들기

요즘 장애는 한 대의 열차가 한 줄기 선로에서 탈선하는 모습과는 거리가 멉니다. 더 자주 보게 되는 건 전체 철도망이 삐끗거리는 상황입니다. 전환기가 잘못 설정되고, 열차가 지연되고, 신호가 서로 충돌하고, 누구도 예상하지 못했던 연쇄적인 영향이 계속해서 터져 나오는 그런 모습이죠.

디지털 도구는 분명 큰 도움이 되지만, 그것만으로는 충분하지 않습니다. 대시보드, 분산 트레이싱, 모델 체커 같은 도구가 실패가 어떻게 전파되는지, 그리고 팀이 혼돈 속에서 어떻게 함께 사고해야 하는지에 대한 이해를 완전히 대신할 수는 없습니다.

여기서 등장하는 것이 바로 아날로그 장애 스토리 조차장(story trainyard) 입니다. 테이블 위에서 복잡한 장애를 실제로 손으로 움직일 수 있는 스토리보드로 바꾸는 연습 세션입니다. 선로, 열차, 신호를 직접 배치하고 옮기면서 인시던트를 리허설하고, 런북을 다듬고, 실제 위기를 덜 두렵게 만들어주는 공유 직관을 기르는 매우 강력한 방법입니다.

이 글은 여러분 팀을 위한 스토리 조차장을 직접 만들고 운영할 수 있도록 돕는 청사진(블루프린트) 입니다.

왜 복잡한 장애 디버깅에 아날로그를 써야 할까?

시스템이 가장 혼란스러울 때, 모니터 화면은 노이즈 덩어리가 되기 쉽습니다. 아날로그 테이블탑 연습은 전혀 다른 걸 해 줍니다.

생각하는 속도를 약간 늦춰서, 평소라면 놓쳤을 관계를 보게 합니다.
모두가 같은 모델을, 같은 시간에, 같은 공간에서 바라보게 만듭니다.
위험 부담을 낮춰서, 사람들이 더 자유롭게 실험하고, 질문하고, 빈틈을 드러낼 수 있게 합니다.

로그를 노려보는 대신, 여러분은 인시던트의 물리적 모델을 바라봅니다. 서비스, 이벤트, 신호를 나타내는 카드, 선, 토큰, 포스트잇이 놓여 있고, 그것들을 움직이며 타임라인을 분기하고, 분기점마다 다른 선택지를 따라가 보며 ‘너의 선택은?’ 책처럼 여러 경로를 탐색합니다.

이건 단순한 향수 놀이가 아닙니다. 아주 현실적이고 비용도 거의 들지 않는 방식으로 다음을 할 수 있습니다.

인시던트 대응과 온콜 핸드오프를 리허설한다.
런북을 실제로 필요하기 전에 미리 시험하고 다듬는다.
커뮤니케이션과 의사결정 과정의 빈틈을 드러낸다.
분산 시스템이 실제로 어떻게 동작하는지에 대한 공유된 멘탈 모델을 만든다.

핵심 비유: “스토리 조차장(Story Trainyard)”

자신의 시스템을 하나의 조차장(trainyard) 으로 떠올려 보세요.

선로(Tracks) = 컴포넌트 간의 실행 경로와 의존성
열차(Trains) = 시스템을 흐르는 요청, 잡, 메시지
전환기(Switches) = 라우팅 결정, 기능 플래그, 재시도, 페일오버 로직
신호(Signals) = 알림(alert), 로그, 메트릭, 헬스 체크

장애 스토리는 하나의 철도 이야기가 됩니다.

한 대의 “열차”가 출발합니다. (사용자 요청 또는 배치 작업 시작)
여러 “역(station)”을 통과합니다. (API, 큐, 데이터베이스, 서드파티 서비스 등)
어느 “전환기”가 잘못 설정되었거나, 지연되었거나, 과부하가 걸립니다.
열차들이 밀리고, 엉뚱한 선로로 빠지고, 선로 위에 멈춰 섭니다.
신호가 울리거나(혹은 울리지 않거나), 운영자가 대응합니다.

이 이야기는 여러 선로 위에서 동시에 펼쳐집니다. 실제 분산 인시던트와 똑같죠. 이걸 분기하는 내러티브로 다루면 이런 가정(what if?) 을 마음껏 시도해 볼 수 있습니다.

재시도 정책이 달랐다면 어떻게 됐을까?
알림이 5분 더 빨리(혹은 아예) 울렸다면?
다른 엔지니어가 인시던트 코디네이터를 맡았다면?

그 결과 팀 전체가 손으로 직접 조작하고 이해할 수 있는, 풍부하고 시각적인 인과 관계 모델이 만들어집니다.

테이블 위 조차장, 이렇게 만든다

특별한 소품이 필요하지 않습니다. 작게 시작해서 계속 개선하세요.

준비물

큰 화이트보드 또는 포스터용 종이
다양한 색상의 포스트잇(스티키 노트)
인덱스 카드
줄 혹은 마스킹 테이프(선로용)
토큰(동전, 미플, 작은 물건 아무거나) – 열차와 신호 표현용
최소 3색 이상의 마커

기본 범례(팀에 맞게 커스터마이즈)

파란 포스트잇: 서비스 / 컴포넌트
초록 포스트잇: 외부 의존성 (결제, 인증 제공자 등)
빨간 포스트잇: 장애 지점 / 에러 상태
노란 포스트잇: 사람의 행동(배포, 설정 변경, 런북 단계 등)
줄/테이프: 실행 경로 / 의존성(선로)
토큰: 개별 요청, 잡, 메시지(열차)
작은 깃발/점 스티커: 알림 또는 핵심 신호

보드 한 켠에 범례(legend) 를 적어 두어 모두가 같은 단어와 표기법을 쓰도록 합니다.

단계별: 스토리 조차장 연습 세션 진행법

1. 시나리오를 고른다

다음 중 하나를 선택합니다.

분석하고 싶은 실제 인시던트
그럴듯한 최악의 경우 시나리오
예: “Primary 리전 네트워크 분할 + 서드파티 부분 장애 동시 발생”
기존 인시던트의 What-if 변형
예: “같은 버그지만 트래픽 피크 시간에 터졌다면?”

시작 조건과, 처음 온콜을 받은 것처럼 보이는 증상을 상황 방송 하듯 말해 줍니다.

“지금은 새벽 02:13. 페이지: ‘us-east-1 리전에서 5분 동안 Checkout 에러율 > 10%.’
레이턴시 차트는 멀쩡해 보입니다. 이제 어떻게 할까요?”

2. 선로를 깐다 (시스템 토폴로지)

주요 데이터 흐름을 선로처럼 그리거나 테이프로 붙입니다.

Ingress → API Gateway → 코어 서비스 → 데이터베이스
비동기 워커와 큐
서드파티 연동 경로

이 선로 위에 컴포넌트 카드를(포스트잇) 배치합니다. 화살표로 흐르는 방향과 의존성을 표시합니다.

이게 곧 여러분의 그래프 모델 입니다. Oddity, ShiVis 같은 도구를 아날로그로 옮겨 놓은 버전이라 보면 됩니다. 특히 병렬 실행 경로와 그 교차점을 드러내는 데 초점을 두세요.

3. 열차를 올린다 (요청 & 잡)

입구 지점에 토큰을 놓습니다.

일반적인 사용자 요청을 나타내는 토큰 몇 개
백그라운드 잡이나 스케줄된 작업을 나타내는 토큰 몇 개

이제 시간의 흐름에 따라 진행합니다.

각 토큰을 선로를 따라 컴포넌트를 거치며 한 칸씩 움직입니다.
각 컴포넌트에서 볼 수 있는 신호(로그, 메트릭, 트레이스, 알림)를 표시합니다.
분기점 이 있으면 적어 둡니다. 재시도, 타임아웃, 폴백, 다른 샤드/리전으로의 라우팅 등.

이렇게 하면 공간 위에 펼쳐진 타임라인 이 만들어집니다. 여러 열차가 동시에 달리고, 현재 시점은 왼쪽에서 오른쪽으로 쓸려가는 스윕라인처럼 표현됩니다.

4. 장애 이벤트를 주입한다

이제 빨간 카드 로 장애 지점을 추가합니다.

데이터베이스 리플리카가 지연되거나 멈춘 경우
서드파티 API가 느려지거나 들쭉날쭉해진 경우
설정 푸시로 라우팅 동작이 바뀐 경우

각 장애에 대해 네 가지를 묻습니다.

그래프 상 어디에서 발생하는가?
어떤 열차가 가장 먼저 영향을 받는가?
어떤 신호(알림, 로그, 메트릭)가 어디서 올라오는가?
올라왔어야 하지만 올라오지 않은 신호는 무엇인가?

이 단계에서 시각적 레이아웃이 빛을 발합니다. 손가락으로 장애 지점을 짚은 뒤, 여러 갈래 하류 경로를 직접 따라가 볼 수 있습니다.

5. 사람의 이야기를 올린다

이제 노란 포스트잇 으로 인간 행동을 표현합니다.

누가 몇 시에 페이지를 받았는가?
가장 먼저 본 쿼리, 대시보드, 런북은 무엇이었는가?
핵심 결정과 실수는 무엇이었는가?

이 노란 포스트잇을 선로 위쪽 에, 시간 순서에 맞춰 대략적으로 붙입니다. 그러면 두 개의 겹친 내러티브가 생깁니다.

선로 위 시스템 스토리: 요청, 컴포넌트, 장애
선로 위쪽 인간 스토리: 알림, 판단, 에스컬레이션, 커뮤니케이션

참여자들에게 소리 내어 설명하게 하세요.

“이 시점에서 저는 DB 문제라고 가정했어요. 왜냐하면…”

이런 내러티브는 각자의 멘탈 모델 을 드러내고, 그 모델들이 어디서 서로 어긋나는지 보여 줍니다.

6. 타임라인을 분기한다 (What-if 시나리오)

실제 인시던트의 경로를 복원했다면, 이제 전환기(switch) 를 만듭니다.

다른 의사결정 경로를 위해 대체 선로 를 그립니다.
예: “여기서 스케일 아웃 대신 롤백을 했다면?”
다른 설정값을 가정해 봅니다.
예: “재시도 횟수를 5회가 아니라 2회로 제한했다면?”
놓쳤던 알림을 상정합니다.
예: “이 SLO burn-rate 알림이 10분 일찍 울렸다면?”

이렇게 하면 3차원 공간에서 하는 반사실(counterfactual) 분석 이 됩니다.

일부 토큰을 복제해서 다른 분기 선로로 보내 봅니다.
각 분기에서 하류 영향 범위를 비교합니다. 어느 쪽이 더 빨리 복구되는지, 어느 쪽이 문제를 더 일찍 드러내는지 살펴봅니다.

이 과정은 엔지니어들이 하나의 직선형 원인–결과 스토리 가 아니라, 분기하는 인과 구조 로 사고하도록 훈련시켜 줍니다.

SRE 관점에서 본 스토리 조차장의 위치

스토리 조차장은 Site Reliability Engineering(SRE) 원칙과 잘 맞아떨어집니다.

온콜 대비 훈련: 신입이든 베테랑이든, 부담 없는 환경에서 인시던트를 리허설할 수 있습니다.
런북 검증: 런북을 한 단계씩 직접 따라가 보며, 모호하거나 오래되었거나 오해의 소지가 있는 부분을 찾습니다.
공유 이해도 향상: 모두가 같은 의존성 그래프를 보며 실시간으로 토론하고, 서로의 오해를 수정할 수 있습니다.
블레이멀리스 학습: 이야기를 ‘열차, 선로, 전환기’ 같은 은유로 풀어내기 때문에, 개인을 탓하지 않고도 결정 과정을 안전하게 이야기할 수 있습니다.

이 연습은 대시보드나 자동화 인시던트 도구를 대체 하려는 게 아닙니다. 그보다는, 다음과 같은 역량을 키워 주는 보완재 입니다.

드물고 복잡한 장애 양상에 대한 더 깊은 직관
스트레스 상황에서 분산 동작을 추론하는 능력
장애 시에도 끊어지지 않는 팀 커뮤니케이션 패턴

자동화 도구 & 모델 체커와 어떻게 맞물리는가

모델 체커, 카오스 엔지니어링, 분산 트레이싱 같은 자동화 도구는 다음에 뛰어납니다.

상태 공간을 체계적으로 나열하고 탐색한다.
불변식(invariant)과 그 위반을 드러낸다.
고해상도 텔레메트리 데이터를 제공한다.

아날로그 스토리 조차장은 전혀 다른 강점을 가집니다.

복잡한 시스템을 한눈에 사람에게 읽기 쉬운 형태 로 만든다.
팀이 서로의 멘탈 모델과 전략을 입 밖으로 꺼내어 토론 하게 만든다.
개발, SRE, 제품, 고객지원 등 크로스 펑셔널 구성원이 함께 인시던트 전개를 이해하도록 돕는다.

둘을 함께 쓰면 이런 시너지를 얻습니다.

모델 기반 시나리오: 포멀 도구가 찾아낸 이슈를 바탕으로 테이블탑 시나리오를 만든다.
가설 정교화: 아날로그 연습을 통해 가설을 만들고, 코드나 스테이징 환경에서 검증한다.
설계 피드백: 관찰성(observability)이나 제어 플레인(control plane)이 부족한 지점을 깨닫고, 시스템 설계에 반영한다.

실제로 굳히는 데 도움이 되는 팁

세션은 타임박스: 60–90분이면 한 번의 시나리오를 충분히 깊게 다룰 수 있습니다.
퍼실리테이터(진행자)를 로테이션: SRE만의 의식이 되지 않게, 기능 개발 팀도 돌아가며 진행을 맡게 하세요.
보드를 반드시 기록: 사진을 찍어 두고, 인시던트 리뷰 시스템이나 사내 문서에 정리합니다.
실제 개선과 연결: 세션 말에는 항상 3–5개의 구체적인 액션 아이템(알림 수정, 런북 업데이트, 설계 제안 등)으로 마무리합니다.
작게 시작: 한 개의 사용자 플로우와 하나의 장애 유형만으로 시작하고, 시간이 지날수록 복잡성을 늘립니다.

맺음말: 더 나은 인시던트 스토리텔러 되기

복잡한 장애는 본질적으로 불확실성 속에서 상호작용하는 시스템과 사람들의 이야기 입니다. 우리는 보통 이런 이야기를 인시던트가 끝난 뒤, 사후 리뷰에서 복원합니다. 하지만 사전에 이 이야기를 리허설 해 보는 경우는 거의 없습니다.

테이블탑 스토리 조차장은 여러분 팀에게 다음을 할 수 있는 방법을 제공합니다.

손으로 복잡한 장애를 디버깅하는 연습을 한다.
신호, 컴포넌트, 사람의 행동이 어떻게 맞물리는지 눈으로 본다.
안전한 환경에서 여러 개의 타임라인과 What-if 분기를 탐색한다.

이를 위해 예산 승인도, 새로운 벤더도, 거창한 프로세스 개편도 필요 없습니다. 필요한 건 방 하나, 마커 몇 개, 그리고 장애를 함께 걸어갈 수 있는 이야기 로 바라보려는 마음가짐입니다.

일단 첫 번째 조차장을 만들고, 하나의 시나리오만 돌려 보세요. 아마도 이번 분기에 도입한 그 어떤 인시던트 도구보다, 화이트보드와 토큰 몇 개가 더 강력한 도구가 될 수 있다는 걸 곧 깨닫게 될 것입니다.