아날로그 장애 열차 모델 워크숍: 실패 경로로 이루어진 탁상 위 철도 만들기

시스템이 다운됐을 때, 장애 대응 계획이 아무도 제대로 검증해 보지 않은 이론 문서로만 남아 있기를 바라진 않을 것입니다. 그때 필요한 것은 함께, 압박 속에서, 실제로 연습해 본 팀입니다. 여기서 아날로그 장애 열차 모델(Analog Outage Train Model) 이 등장합니다. 종이로 만든 선로(paper tracks) 와 나무 블록(wooden blocks) 을 사용해, 탁상 위에서 복잡한 실패 경로를 시뮬레이션하는 로우테크이지만 임팩트 높은 워크숍입니다.

겉으로 보기엔 장난감 놀이처럼 보일지 모릅니다. 하지만 실제로는 정반대입니다. 장난감 기차 같은 겉모습 뒤에는 정책, 프로세스, 사람을 실제로 스트레스 테스트할 수 있는 강력한 기법이 숨겨져 있습니다.

이 글에서는 아날로그 장애 열차 모델이 무엇인지, 어떻게 진행되는지, 그리고 이런 탁상 훈련(tabletop exercise)을 운영하면 실제 장애 대응이 어떻게 극적으로 개선되는지 살펴보겠습니다.

아날로그 장애 열차 모델이란 무엇인가?

아날로그 장애 열차 모델은 다음과 같이 구성된 탁상형 장애 대응 연습 포맷입니다.

• 종이 선로: 시스템, 서비스, 의존성 경로를 표현합니다.
• 분기기와 교차점(스위치, junction): 의사결정 지점, 에스컬레이션 포인트, 분기되는 인시던트 경로를 나타냅니다.
• 나무 블록 또는 기차 칸: 이벤트, 장애, 알림(alert), 티켓, 작업 항목을 표현합니다.
• 역(station)과 차량 기지(depot): 팀, 도구, 혹은 핵심 인프라 컴포넌트를 나타냅니다.

대시보드나 아키텍처 다이어그램만 바라보는 대신, 참가자들은 블록을 손으로 옮기며, 장애의 흐름 — 탐지(detection), 트라이아지(triage), 커뮤니케이션, 복구 작업(remediation), 회복(recovery) — 을 실제 선로 위에서 따라가게 됩니다.

이 워크숍은 의도적으로 아날로그입니다. 특별한 소프트웨어도, 복잡한 시뮬레이션 엔진도 없습니다. 대신, 평소에는 눈에 잘 보이지 않는 장애 대응의 요소들을 눈앞에 드러내는 물리적 모델 하나만 공유합니다.

왜 장애 시뮬레이션을 아날로그로 하는가?

조직은 보통 장애 대응을 준비할 때 추상화된 산출물에 많이 의존합니다.

• ER 다이어그램과 아키텍처 다이어그램
• RACI 차트와 조직도(org chart)
• 런북(runbook)과 플레이북(playbook)
• 티켓 워크플로우와 프로세스 문서

이 모든 것은 분명 유용합니다. 하지만 대개 이상적인(world-as-designed) 세상을 설명합니다. 실제 인시던트에서는 설계도대로 흘러가는 경우가 거의 없습니다.

아날로그 장애 열차 모델은 이런 추상화에 실질적 보완재 역할을 합니다. 덕분에 다음을 몸소 따라가게 만들죠.

• 구체적인 이벤트: “이 API가 장애 난다. 이 알림이 뜬다. 이 고객이 전화를 건다.”
• 실제 의사결정: “누가 페이저를 받는가? 누가 이 변경을 승인하는가? 누가 CEO와 이야기하는가?”
• 실제 워크플로우: “어떤 도구를 쓰는가? 압박 상황에서 어떤 단계를 생략하는가?”

가설을 두고 말싸움을 벌이는 대신, 실제 시나리오를 연기(play out) 해 보면서, 문서에 적힌 계획이 물리적인 흐름으로 바뀌었을 때 어떻게 작동하는지 직접 확인하게 됩니다.

워크숍 내부 들여다보기: 어떻게 진행되는가

조직마다 형태를 자유롭게 바꿀 수 있지만, 전형적인 아날로그 장애 열차 모델 워크숍은 다음과 같은 패턴을 따릅니다.

1. 시스템을 철도로 그려내기

먼저, 참가자들이 조직의 핵심 환경을 탁상 위에 매핑합니다.

• 선로(Tracks): 주요 서비스와 그 의존성을 표현합니다. (예: 인증(auth), 결제 처리(payment processing), 로깅(logging), 메시징(messaging))
• 분기와 스위치(Branches & switches): 대체 경로를 표현합니다. (예: 페일오버 리전, 백업 시스템, 수동 우회 절차 등)
• 역(Stations): 팀과 도구를 나타냅니다. (예: SRE, 보안 팀, 고객 지원, 인시던트 커맨더, 변경 관리 시스템, 티켓 시스템 등)

모든 마이크로서비스를 다 모델링할 필요는 없습니다. 주요 인시던트에서 진짜 중요한 것들, 즉 자주 문제를 일으키거나, 문제가 나면 영향이 매우 큰 서비스들만 모델링합니다.

2. 열차 배치하기: 장애 시나리오 정의

그 다음, 기차 칸이나 나무 블록으로 표현되는 하나 이상의 장애 시나리오를 만듭니다.

• 데이터베이스 클러스터가 읽기 전용(read‑only)이 된다.
• 인증 프로바이더가 타임아웃을 계속 발생시킨다.
• 배포(deployment) 후 특정 리전에서 체크아웃 플로우가 깨진다.
• 오히려 관측/모니터링(Observability) 도구 자체가 성능 저하를 겪는다.

각 시나리오에는 선로에서의 시작 지점과, 성공적인 복구 혹은 치명적 장애 상태를 나타내는 목표 지점(도착역)이 주어집니다.

3. 인시던트를 실제로 따라가 보기

참가자들은 실제 역할(또는 그에 상응하는 가상의 역할)을 맡습니다.

• 인시던트 커맨더(Incident Commander)
• 온콜 엔지니어(SRE, 플랫폼, 애플리케이션 팀 등)
• 보안(Security)
• 고객 지원/고객 성공(Customer Support & Success)
• 커뮤니케이션/PR
• 제품/비즈니스 이해관계자

퍼실리테이터가 첫 번째 장애 이벤트를 소개하면, 그룹은 다음을 결정해야 합니다.

• 처음에 무슨 일이 일어나는가? 누가 무엇을 먼저 보게 되는가?
• 다음에 열차(블록)는 어느 선로로 이동하는가? (어느 팀, 어느 시스템, 어느 도구로 향하는가?)
• 각 분기점(junction)에서 어떤 의사결정을 내리는가?

모든 결정은 블록이 선로 위를 이동하는 행동으로 표현됩니다. 누군가 “지원 팀이 인시던트 시스템에 티켓을 연다”라고 말하면, 블록은 고객 제보(Customer Reports) 선로에서 인시던트 관리(Incident Management) 역으로 이동합니다.

전체 상황은 압박 속에서 흘러가는 물리적 플로우차트처럼, 한 단계씩 진행됩니다.

4. ‘이상’이 아닌 ‘현실’을 기록하기

가장 중요한 규칙은 이것입니다. 참가자들은 지금 실제로 하고 있는 방식을 말해야 합니다. “그랬으면 좋겠다” 수준의 이상적인 모습을 이야기해서는 안 됩니다. 통찰은 바로 여기에서 나오기 때문입니다.

열차가 움직이는 동안, 퍼실리테이터는 계속 질문합니다.

• “그때 정확히 어떤 도구를 사용하나요?”
• “이 결정은 누가 책임지고 내리나요?”
• “이 내용은 어디에 문서화되어 있나요?”
• “그 사람이 휴가인 경우에는 어떻게 하나요?”

애매함, 지연, 혼란이 드러나는 지점마다 메모합니다. 그룹이 다음으로 어떻게 해야 할지 몰라 멈출 경우, 열차도 탁상 위에서 그대로 멈춥니다. 이는 실제 환경에서도 프로세스가 같은 지점에서 멈출 수 있음을 시각적으로 매우 강하게 보여 줍니다.

스트레스 상황에서 드러나는 것들

아날로그 장애 열차 모델을 반복적으로 운영해 보면, 문서 상으로는 멀쩡해 보이던 것들이 실제 흐름 속에서는 어떻게 무너지는지 자주 발견하게 됩니다.

1. 정책·절차의 붕괴 지점

인시던트 핸드북에는 이렇게 적혀 있을 수 있습니다.

“Severity‑1 인시던트가 발생하면, 인시던트 커맨더는 대응 팀을 소집하고 커뮤니케이션 프로토콜을 시작한다.”

하지만 워크숍을 진행하다 보면 이렇게 드러날 수 있습니다.

• 특정 도메인에 대해 누가 인시던트 커맨더인지 아무도 모른다.
• 커뮤니케이션 템플릿이 오래됐거나 찾기 어렵다.
• 에스컬레이션 경로가 일부 사람만 접근 가능한 도구를 전제로 설계되어 있다.

이 모델은 문서에 적힌 정책(policy as written) 과 실제로 실행 가능한 정책(policy as executed) 사이의 간극을 적나라하게 드러냅니다.

2. 팀 역할·조정의 숨은 구멍

블록이 움직이는 물리적 동선은 조직상의 문제를 아주 선명하게 보여 줍니다.

• 특정 컴포넌트에 대한 진짜 오너십이 없어, 열차가 두 역 사이를 계속 튕기듯 왕복한다.
• 일부 팀 선로가 항상 과부하 상태인 반면, 다른 선로는 거의 사용되지 않아, 구조적 병목이 눈에 보인다.
• 보안 검토, 법무 승인 같은 크로스펑셔널 단계가 선로 설계에서 완전히 누락되어 있다.

이런 구멍들은 정적인 문서에서는 잘 드러나지 않지만, 실제 시나리오를 실시간으로 흘려 보면 금방 모습을 드러냅니다.

3. 흐름 속에서 나타나는 커뮤니케이션 실패

워크숍을 해 보면 미묘하지만 심각한 커뮤니케이션 문제들이 드러납니다.

• 고객 지원 팀이 장애 중에 기술적인 최신 정보를 빠르게 얻는 방법을 모른다.
• 엔지니어들이 고객에게 어디까지 말해도 되는지 확신하지 못한다.
• 비즈니스 이해관계자는 대응자들을 방해하지 않고 신뢰할 만한 상태 정보를 받을 공식 채널이 없다.

모든 메시지와 에스컬레이션을 선로 위에서의 이동으로 표현하게 만들면, 커뮤니케이션 루프가 느리거나, 중복되거나, 아예 존재하지 않는 지점이 한눈에 보입니다.

4. 취약하거나 비효율적인 복구 도구

이 과정에서 도구(tooling)의 한계도 적나라하게 드러납니다.

• 인시던트 중에는 도저히 읽을 수 없을 정도로 오래됐거나, 불완전하거나, 지나치게 긴 런북.
• 대응자가 실제로 궁금해하는 질문에는 답을 주지 못하는 대시보드.
• 문서 상으로만 존재하고, 실전에선 아무도 믿지 않고 쓰지 않는 자동화(automation).

각 단계에서 “어떤 도구를 쓴다”고 팀이 명시해야 하므로, 부족한 지점이 아주 분명하게 보입니다. 그 결과, 어떤 부분의 툴체인을 고치고, 단순화하고, 업그레이드해야 하는지에 대한 구체적인 액션 아이템이 생깁니다.

통찰을 행동으로: 반복과 하드닝(hardening)

아날로그 장애 열차 모델의 목적은 문제를 드러내는 데서 끝나지 않습니다. 반복(iteration)과 개선(improvement) 이 핵심입니다.

1. 디브리핑과 문서화

시나리오를 한 번 끝까지 돌린 뒤에는 구조화된 디브리핑(debrief)을 진행합니다.

• 우리를 느리게 만든 것은 무엇이었는가?
• 책임과 역할이 모호해진 지점은 어디인가?
• 어떤 도구가 기대에 못 미쳤는가, 혹은 아예 존재하지 않았는가?
• 어떤 결정이 너무 늦게, 혹은 잘못된 사람에 의해 내려졌는가?

이 관찰 결과들은 문서 개선, 팀 오너십 조정, 툴링 강화 등으로 이어지는 우선순위가 매겨진 개선 백로그로 정리됩니다.

2. 선로 다시 그리기

변경 사항에 합의했다면, 이제 모델 자체를 업데이트합니다.

• 오너십이 명확해진 만큼 역을 추가하거나 이름을 바꿉니다.
• 더 나은 페일오버나 수동 프로세스를 위한 새로운 분기선을 만듭니다.
• 더 이상 쓰지 않거나 위험한 경로에는 표시를 해 두어, 향후 피하도록 합니다.

이 물리적 레이아웃은 인시던트가 현재의 베스트 프랙티스에 따라 어떻게 흘러가야 하는지에 대한 살아 있는 표현이 됩니다.

3. 다시 실행하고 재검증하기

진짜 힘은 시간이 지나며 여러 차례 반복할 때 나옵니다.

• 개선 후에 동일한 시나리오를 다시 돌려, 열차가 더 매끄럽게 움직이는지 확인합니다.
• 동시 장애, 도구 장애, 데이터 무결성 문제 등 새로운 실패 경로를 도입합니다.
• 참가자를 교대·회전시켜, 더 많은 사람이 개선된 프로세스를 체득하게 합니다.

각 반복(iteration)마다 장애 대응 역량은 더욱 단단해집니다. 단지 문서 상으로 더 나은 계획을 쓰는 것이 아니라, 실제 그 계획을 사용하게 될 사람들과 함께, 그 계획이 진짜로 작동함을 검증하는 셈입니다.

응집력 있는 인시던트 대응 팀 만들기

프로세스와 도구를 넘어, 아날로그 장애 열차 모델의 핵심은 결국 사람입니다.

기술적·협업적 근육 기억(muscle memory) 만들기

대응자(responder)들은 다음을 연습합니다.

• 엔지니어링, 지원, 보안, 비즈니스 역할 간의 협업과 조정.
• 제한된 정보와 시간 압박 속에서 의사결정 내리기.
• 실제 장애 상황에서 사용할 커뮤니케이션 채널과 도구를 그대로 사용하는 법.

시간이 지날수록 이는 근육 기억으로 축적됩니다. 단지 “어떤 명령어를 실행할까?” 같은 기술적 기억뿐 아니라, “누구를 언제, 어떤 채널로 호출해야 할까?” 같은 사회적 기억도 함께 자리 잡습니다.

공유된 이해와 신뢰 형성

모두가 같은 선로를 보고, 같은 블록을 움직여 보면서 공유된 멘탈 모델이 만들어집니다.

• 엔지니어는 고객과 브랜드를 보호하기 위해 지원 팀과 PR이 무엇을 필요로 하는지 이해하게 됩니다.
• 지원 팀은 왜 엔지니어가 문제를 해결할 수 있는 여유와 시간을 필요로 하는지 알게 됩니다.
• 리더십은 특정 시점에 왜 그런 트레이드오프가 필요했는지 눈으로 직접 확인할 수 있습니다.

이 공유된 이해는 실제 장애가 발생했을 때 마찰과 비난을 줄여 줍니다. 팀은 각자 silo에 갇힌 기능 조직이 아니라, 하나의 응집된 유닛처럼 움직이게 됩니다.

결론: 단순한 모델이 만들어내는 거대한 효과

아날로그 장애 열차 모델은 겉만 보면 놀라울 만큼 단순해 보입니다. 종이 선로, 나무 블록, 그리고 하나의 탁상. 하지만 실제로는 다음을 가능하게 하는 강력한 방법입니다.

• 실제에 가까운 실패 경로를 안전하게 시뮬레이션하기
• 정책과 절차가 스트레스 상황에서 어떻게 작동하는지 눈으로 확인하기
• 역할 배분, 커뮤니케이션, 조정의 빈틈을 드러내기
• 비효율적인 도구와 부족한 복구 역량을 식별하기
• 추상적 모델을, 구체적이고 이벤트 기반인 실제 워크플로우로 보완하기
• 반복·재검증을 통해 장애 대응 역량을 꾸준히 하드닝(hardening)하기
• 크로스펑셔널 대응 팀을 하나의 응집력 있는 유닛으로 훈련하기

복잡한 도구와 자동화가 넘쳐나는 시대지만, 때로는 시스템과 조직을 제대로 이해하는 가장 효과적인 방법이 속도를 줄이고, 아날로그로 돌아가, 탁상 위에서 기차가 어떻게 움직이는지 지켜보는 것일 수 있습니다.

비즈니스가 디지털 인프라에 의존하고 있다면, 여러분만의 탁상 위 철도를 한 번 만들어 보십시오. 다음 대형 장애가 오기 전에 이런 워크숍에서 얻은 통찰은, 종이 선로와 나무 블록에 쓴 비용보다 훨씬 큰 가치를 가져다줄 수 있습니다.