아날로그 장애 스토리 철도 야드 섀도우박스: 종이로 만드는 미니어처 시스템 복제본으로 안전하게 장애 재현하기

디지털 시스템의 장애는 생각보다 매우 ‘물리적’입니다. 장애가 도미노처럼 번지고, 경로가 막히고, 막다른 길이 생기고, 평소엔 보이지 않던 이상한 우회 경로가 갑자기 나타나기도 합니다. 그런데 우리가 장애를 분석할 때 쓰는 도구는 대부분 추상적인 대시보드, 빽빽한 로그, 복잡한 다이어그램입니다.

그렇다면, 시스템 전체를 테이블 위에 **미니어처 종이 철도 야드(trainyard)**처럼 펼쳐 놓고 — 레일(의존성), 기차(요청), 그리고 스위치(라우팅 규칙)를 모두 포함한 — 그 위에서 손으로 장애 시나리오를 직접 움직이며 볼 수 있다면 어떨까요?

이게 바로 아날로그 장애 스토리 철도 야드 섀도우박스의 아이디어입니다. 프로덕션 시스템을 종이로 만든 미니어처 복제본으로 구현해, 실제 장애를 안전하게 재현하되 라이브 인프라는 전혀 건드리지 않는 방식이죠.

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

섀도우박스가 무엇이고 왜 효과적인지
단순한 “연결성 중심 토폴로지”로 시스템을 모델링하는 방법
나만의 종이 장애 철도 야드를 만드는 방법
실제 장애를 재생하고 이를 복원력 개선에 활용하는 방법

“장애 스토리 철도 야드 섀도우박스”란 무엇인가?

**섀도우박스(Shadowbox)**는 복잡한 시스템을 물리적으로 단순화한 표현입니다. 시스템이 스트레스를 받을 때 어떤 식으로 동작하는지 보여주는 3D 스토리보드라고 생각하면 됩니다. 이 맥락에서 섀도우박스는 종이 카드, 실, 자석 같은 간단한 재료로 만드는, 테이블 위 프로덕션 환경 모델입니다.

장애 스토리 철도 야드라는 비유는 철도 네트워크에서 가져왔습니다.

레일(트랙): 서비스 간 의존성
스위치: 라우팅 로직이나 기능 플래그(feature flag)
기차: 시스템을 통과하는 사용자 요청, 메시지, 잡(job)
역과 철도 야드: 서비스, 데이터베이스, 캐시, 큐 등

이걸 물리적으로 펼쳐 놓으면 다음과 같은 일이 가능해집니다.

실제 장애를 한 단계씩 스토리처럼 따라가며 재현할 수 있고
레일(의존성)을 바꿔 보면서 장애가 어떻게 전파되는지 살펴볼 수 있으며
병목, 단일 장애 지점(SPOF), 복원력의 빈틈을 눈으로 시각화할 수 있습니다.

이 모든 건 오프라인에서 일어납니다. 프로덕션에서 실험하지 않고, 고객에게 아무런 위험도 주지 않으면서도, 실제 장애 데이터와 실제 시스템 토폴로지를 그대로 활용합니다.

왜 디지털 대신 물리적으로 해야 할까?

겉으로 보면 조금 장난 같아 보일 수 있지만, 설계 철학은 매우 진지합니다. 이 접근법은 다음 두 가지를 결합합니다.

실험 설계(Experimental design) – “만약 이런 일이 생기면?”을 안전하게 탐색할 수 있는 통제된 환경을 만드는 것
카오스 엔지니어링(Chaos Engineering) – 시스템이 장애 모드에서 어떻게 동작하는지 탐구하되, 저위험·시뮬레이션 형태로 수행하는 것

여기에 물리적 모델이 더해지면, 순수 디지털 도구로는 얻기 어려운 장점들이 생깁니다.

1. 참여 장벽이 낮아진다

위키에 있는 복잡한 아키텍처 다이어그램은 보는 순간 진이 빠집니다. 반면, 색깔 있는 카드와 실로 만든 테이블 위 모델은 부담 없이 다가갈 수 있습니다.

비기술 직군도 문제 지점이 눈에 보이기 때문에 이해하기 쉽습니다.
신규 엔지니어는 수천 줄의 YAML을 읽지 않고도 시스템의 ‘형태’를 익힐 수 있습니다.
프로덕트, 고객지원, 운영 등 다양한 역할이 공유된 물리적 아티팩트를 두고 함께 논의할 수 있습니다.

2. “공유 대시보드”가 아니라 “공유 사고 모델”을 만든다

여러 사람이 함께 기차(요청)를 레일(경로) 위로 움직이다 보면, 자연스럽게 공통 언어와 공통 추론 방식을 쓰게 됩니다.

“이 캐시가 죽으면, 요청은 이제 어디로 가죠?”
“누가 제일 먼저 눈치채나요? 어떤 알람이 울리죠?”
“백로그는 어디에 쌓이나요?”

이런 대화를 함께 해 나가면서, 각자 대시보드를 따로 보는 것보다 훨씬 빠르게 인식과 정렬이 맞춰집니다.

3. 가볍고, 업데이트가 쉽다

풀스택 시뮬레이션 환경은 구축비도 크고 유지보수는 더 어렵습니다. 반면, 연결성에만 집중한 단순 모델은 다음 두 가지만 표현합니다.

누가 누구에게 의존하는지(서비스 의존성 그래프)
각 컴포넌트가 얼마나 많은 인스턴스/노드로 구성되는지

이 정도 정보만으로도 많은 장애 관련 질문에 충분히 답할 수 있습니다.

이 페일오버 경로는 실제로 존재하는가?
이 컴포넌트는 단일 장애 지점(SPOF)인가?
여기가 죽으면, 다음으로 어디가 과부하를 받는가?

모델이 일부러 거칠게(coarse-grained) 설계되어 있기 때문에, 아키텍처가 바뀌어도 큰 힘 들이지 않고 최신 상태로 유지할 수 있습니다.

최소 모델: 연결성(Connectivity)과 복제 개수(Replica Count)

시스템의 모든 디테일을 미니어처로 옮길 필요는 없습니다. 사실, 그러면 안 됩니다.

미니멀 토폴로지 모델은 다음 세 가지에만 초점을 맞춥니다.

서비스 노드 – 주요 서비스, 데이터 스토어, 큐, 서드파티 의존성 등
엣지(Edges) – 누가 누구를 호출하거나, 누구에게 의존하는지 나타내는 화살표
복제 개수(Replica counts) – 해당 서비스가 단일 인스턴스인지, N개 인스턴스인지, 다중 리전으로 배포되었는지

이게 전부입니다. 패킷 레벨 시뮬레이션도, CPU 그래프도 필요 없습니다.

이 정도면 충분한 이유는 다음과 같습니다.

영향이 큰 장애 대부분은 의존성 실패나 용량 한계에서 비롯되지, 희귀한 저수준 이슈에서 비롯되지 않습니다.
그래프의 형태와 노드의 개수만으로도 복원력과 블라스트 레디우스(Blast Radius, 피해 범위)에 대한 통찰을 많이 얻을 수 있습니다.
테이블탑 재현에서는 정확한 타이밍보다 인과 구조(“이게 깨지면, 그다음에 저게 깨진다”)를 이해하는 것이 중요합니다.

이 모델은 생각하고(study), 스토리텔링하는 도구이지, 부하 테스트 툴을 대체하기 위한 것이 아닙니다.

섀도우박스 철도 야드 만드는 법

처음부터 완벽하게 만들 필요는 없습니다. 작게 시작해서 점점 발전시키면 됩니다. 기본적인 구성 방법은 다음과 같습니다.

준비물

인덱스 카드 또는 포스트잇(서비스 카드용)
색깔 실 또는 얇은 테이프(의존성 표현용)
작은 토큰(요청/메시지 표현용): 포커 칩, 종이 원, 레고 조각 등
스티커나 색깔 점(복제 개수, 리전, 역할 표시용)
큰 보드, 화이트보드, 또는 넓은 테이블

1단계: 범위 정하기

먼저 범위가 분명한 시스템 일부를 선택합니다.

중요한 사용자 여정 (예: 결제 플로우)
특정 바운디드 컨텍스트 (예: 결제 플랫폼)
최근에 있었던 큰 장애에 관련된 서비스 집합

회사 전체 시스템을 한 번에 모델링하려고 하면, 거의 확실하게 시작도 못 하고 멈춰버립니다.

2단계: 서비스 카드 만들기

범위에 포함된 각 서비스마다 카드를 하나씩 만들고, 여기에 다음 정보를 적습니다.

이름 – 사람 눈에 잘 들어오는, 직관적인 이름
타입 – API, 워커, 캐시, DB, 큐, 서드파티 등
복제 정보 – 예: 1x, 3x, multi-region, active/passive 등

타입별로 색을 나눠도 좋습니다. (예: 서비스는 파란색, 데이터 스토어는 노란색, 큐는 초록색 등)

3단계: 의존성 그래프 배치하기

테이블이나 보드 위에 다음과 같이 배치합니다.

요청 흐름 방향에 맞춰 서비스를 대략적인 순서로 배치합니다. (왼쪽→오른쪽, 또는 위→아래)
호출자에서 피호출자 쪽으로 실이나 화살표를 연결합니다.
필요하다면, 동기 호출과 비동기 호출에 다른 색/패턴을 써도 좋습니다.

예쁘게 만드는 것보다 정확하게 표현하는 것이 중요합니다. 이건 전시용 포스터가 아니라 실제로 사용되는 작업 도구입니다.

4단계: 간단한 장애·용량 표시 추가하기

장애 재현을 위해, 몇 가지 표기 규칙을 정합니다.

서비스가 죽었음을 표시하는 “다운(down) 토큰” – 예: 빨간 X 표시
성능 저하(Degraded) 상태를 표현할 방법 – 예: 노란색 느낌표 스티커로 레이턴시 증가 표시
선택사항: 간단한 용량 표시 – 예: 토큰 1개 = 초당 100rps 처리 가능

5단계: 요청을 움직일 수 있는 토큰으로 표현하기

어떤 토큰을 무엇으로 쓸지 정의합니다.

사용자 요청
잡/메시지
스케줄된 작업

이 토큰들을 그래프 위에서 실제로 움직이며 장애 시나리오를 재현하게 됩니다.

섀도우박스에서 실제 장애 재현하기

철도 야드를 구성했으면, 이제 과거의 장애를 한 단계씩 다시 따라가면서 재생할 수 있습니다.

1. 장애 선택하기

먼저 아래 조건을 만족하는 최근 장애를 하나 고릅니다.

알람·탐지·완화까지의 타임라인이 정리되어 있고
**기여 요인(contributing factors)**이 어느 정도 정리되어 있으며
어떤 의존성들이 관여했는지 감이 잡혀 있는 장애

그래야 모델이 현실과 얼마나 잘 맞는지 검증하기가 수월합니다.

2. 초기 상태 설정하기

시스템의 진입점(예: 웹 프론트엔드, API Gateway)에 요청 토큰 몇 개를 올려 둡니다.
모든 서비스를 “정상” 상태로 설정합니다. (다운 토큰 없음)
가정하고 있는 상태를 소리 내어 말로 정리합니다. (평균 트래픽, 모든 리전 정상 등)

3. 장애를 도입하기

실제 장애가 시작된 시점에서 다음을 수행합니다.

장애가 난 컴포넌트에 다운 토큰을 올립니다.
실제 트리거 요인을 설명합니다. (배포, 설정 변경, 리전 장애, 네트워크 이슈 등)

이제 요청 토큰을 함께 움직이며 다음 질문에 답해 봅니다.

이 컴포넌트가 다운된 상태에서, 요청은 어디로 향하는가?
타임아웃이 나는가? 재시도가 발생하는가? 다른 우회 경로를 타는가?
그 결과 어느 서비스의 부하가 증가하는가?
현재의 모니터링 체계 기준으로 누가 가장 먼저 알람을 받게 될까?

4. 전파와 완화 과정 탐색하기

팀이 토큰과 마커를 움직이는 동안, 다음을 추적합니다.

큐가 어디에서 백업되고, 트래픽이 어디에 쏠리는지
실제로 했던 완화 조치(예: 기능 플래그 끄기, 트래픽 이동)를 그대로 시뮬레이션
그리고 질문합니다. “그때 우리가 할 수 있었던 다른 선택지는 뭐였을까?”

이 과정에서 스토리가 살아납니다. 운영 과정의 디테일, 헷갈렸던 지점, 커뮤니케이션 갭, 암묵적인 전제가 자연스럽게 드러납니다.

5. 인사이트와 개선 아이디어 기록하기

다음 항목을 기록으로 남깁니다.

아무도 인지하지 못하고 있던 의외의 의존성
반드시 이중화해야 할 단일 장애 지점(SPOF)
빠져 있거나 헷갈리게 만드는 알람·대시보드
신규 가드레일, 기능 플래그, 용량 버퍼 등의 후보

모두가 시스템을 직접 눈으로 보고 있기 때문에, 비용 vs. 복원력, 복잡도 vs. 안전성 같은 트레이드오프를 훨씬 구체적으로 얘기할 수 있습니다.

놀이에서 실천으로: 팀이 얻게 되는 것들

섀도우박스는 장난감이 아니라, 공유 학습 환경입니다.

더 나은 장애 대응 훈련

이 철도 야드를 사용해 **테이블탑 드릴(Tabletop Drill)**을 진행할 수 있습니다.

역할을 나눕니다. (온콜 엔지니어, 인시던트 커맨더, 커뮤니케이션 담당, 프로덕트 오너 등)
장애 탐지, triage(초기 분류), 커뮤니케이션, 완화 조치를 시뮬레이션합니다.
실제 모델에서 벌어지는 일을 기준으로 런북(runbook)을 연습하고 개선합니다.

더 포용적인 크로스 펑셔널 학습

모델이 물리적이고 시각적이기 때문에:

고객지원 팀은 특정 에러가 왜 발생하는지, 고객에게 무엇을 약속하는 것이 현실적인지 이해할 수 있습니다.
프로덕트 매니저는 새로운 기능이나 가용성 목표가 아키텍처에 어떤 비용을 요구하는지 직관적으로 볼 수 있습니다.
리더십은 추상적인 ‘가용성 몇 9(99.9% 등)’나 SLO 그래프가 아니라, 구체적인 복원력 투자 내용을 이해할 수 있습니다.

프로덕션 카오스 실험보다 안전한 탐색

프로덕션에서의 카오스 엔지니어링은 강력하지만, 비용과 리스크가 모두 큽니다. 반면 섀도우박스 접근법은 다음과 같습니다.

운영 비용이 거의 들지 않으며
사용자에게 주는 위험이 전혀 없고
여전히 중요한 복원력의 빈틈과 설계 상의 결함을 드러냅니다.

심지어 프로덕션에서 카오스 실험을 하기 전에, 테이블 위에서 먼저 프로토타입해 볼 수 있습니다. 실제 라이브 환경에서 실험할 가치가 있는지 판단하는 데 도움이 됩니다.

섀도우박스를 오래 유용하게 쓰는 방법

이 모델의 가치는 얼마나 최신 상태인지, 그리고 얼마나 실제 업무에 연결되는지에 달려 있습니다.

중요한 아키텍처 변화가 있을 때마다 업데이트합니다. 새로운 서비스, 제거된 의존성, 리전 마이그레이션 등.
정기적인 의식(ritual)에 포함합니다. 장애 리뷰, 분기별 복원력 리뷰, 신규 입사자 온보딩 등.
최소한으로 유지합니다. 너무 디테일을 많이 넣으면 아무도 업데이트하지 않게 됩니다. 처음에는 의존성과 복제 개수에 집중하고, 여러 번의 장애가 같은 디테일을 요구할 때만 추가합니다.

섀도우박스를 아키텍처 문서와 런북의 살아 있는 동반자로 생각해 보세요. 추상화된 문서들이 현실의 지저분한 상황에서 얼마나 잘 버티는지 물리적으로 검증하는 장소입니다.

결론: 장애를 빛 아래로 끌어내기

장애란, 복잡한 시스템이 실제로 어떻게 동작하는지 보여주는 이야기이지, 우리가 그렇게 되길 바라는 설계서의 이야기가 아닙니다. 물리적인 장애 스토리 철도 야드 섀도우박스를 만들면 다음을 할 수 있습니다.

그 이야기를 눈에 보이고, 손으로 만질 수 있게 만들고
더 많은 사람을 복원력 이해와 개선 과정에 참여시키고
프로덕션을 건드리지 않고도 대응 연습과 설계 트레이드오프 토론을 할 수 있습니다.

연결성에만 초점을 맞춘 단순한 모델 위에 종이로 된 미니어처 시스템 복제본을 구축하면, 실패를 탐구하기 위한 유연하고 저비용의 실험실을 얻게 됩니다. 시간이 지날수록 이 공간에서 실제 장애를 반복 재현해 보는 경험은, 개별적인 위기를 공유 학습 경험으로 바꾸어 줍니다. 그리고 바로 그 지점에서 진짜 복원력이 자라나기 시작합니다.