아날로그 사고(事故) 스토리 트레인: 런북 리허설을 위한 종이 컨트롤 야드 만들기

디지털 시스템의 실패는 늘 복잡하고 인간적인 방식으로 나타난다. 하지만 대부분의 팀은 실제 사고가 사람들의 수면 시간과 고객 신뢰를 태워 없앤 한참 뒤에야 슬라이드, 상태 페이지, 회고 문서 속에서 실패를 “연습”한다.

더 나은 방식이 있다. 사고 연습을 **모형 철도 조차장(model railway yard)**처럼 다루는 것이다.

사람들이 “알아서 잘하겠지”라고 기대하는 대신, 아날로그 사고 스토리 트레인을 만들어 보자. 손으로 만질 수 있는 종이 기반 컨트롤 야드를 만들어, 팀이 테이블탑(tabletop) 연습을 하고, 알람과 의사결정을 한 단계씩 따라가며, 실제로 런북을 사용해 보는 리허설을 하는 것이다.

이 글에서는 실제 시스템을 기반으로 이런 연습을 어떻게 설계하고, 구조화된 시뮬레이션으로 어떻게 진행하며, 거기서 배운 것을 조직 전체의 사고 대응 역량 개선으로 어떻게 연결할 수 있는지 살펴본다.

왜 테이블탑 연습이 사고 전략에 반드시 포함되어야 할까

**테이블탑 연습(tabletop exercise)**은 사고 상황을 구조화된 방식으로, 낮은 위험으로 시뮬레이션하는 활동이다. 참가자들은 실제 프로덕션에는 손대지 않은 채, 무엇을 어떤 순서로, 어떤 도구와 런북을 사용해 할지를 말로 풀어가며 진행한다.

이렇게 생각할 수 있다.

• SRE와 개발자를 위한 비행 시뮬레이터
• 시험이 아니라 리허설 — 통과/실패가 목적이 아니라 학습이 목적이다
• 문제가 생겼을 때 시스템이 어떻게 움직이는지 함께 스토리를 만들어 가는 세션

잘 설계된 테이블탑 연습은 다음과 같은 효과가 있다.

• 대응자와 인시던트 커맨더(incident commander)의 근육 기억을 만든다
• 문서, 도구, 런북의 빈틈과 구멍을 드러낸다
• 실제 비상 상황 전에 역할과 기대치를 명확하게 한다
• 커뮤니케이션과 의사결정을 안전하게 연습해 볼 수 있는 공간을 제공한다

여기서의 핵심 포인트는 테이블탑을 **아날로그 컨트롤 야드(조차장)**처럼 다루는 것이다. 즉, 사고 대응 프로세스를 물리적으로 모델링한 손에 잡히는 모형으로 만드는 것이다.

“종이 컨트롤 야드” 메타포

철도 조차장(control yard)은 동시에 여러 대의 열차, 다양한 노선, 여러 시간표를 조율한다. 사고 대응도 마찬가지다. 수많은 알람이 터지고, 여러 팀이 협업하며, 결정의 갈래가 계속 생긴다.

**종이 컨트롤 야드(paper control yard)**는 이 복잡함을 물리적인 형태로 옮겨 놓는 것이다.

• 출력한 알람(alert) 카드를 “본선(main line)”으로 계속 들어오는 카드처럼 사용
• 런북 단계를, 따라가거나 건너뛸 수도 있고 분기할 수도 있는 선로(track) 조각처럼 배치
• 역할(인시던트 커맨더, 커뮤니케이션 담당, 온콜 엔지니어 등)을 각기 다른 노선을 관리하는 오퍼레이터로 설정
• 타임라인 마커를 두어 각 액션이 언제 일어나는지 표시

종이 조각들을 테이블 위에서 옮기면서, 대응자들은 사고의 흐름을 눈으로 직접 볼 수 있게 된다.

• 어떤 알람이 가장 먼저 왔는지
• 누가 처음으로 반응했는지
• 어떤 의사결정 경로를 택했는지
• 어디에서 막히거나 헷갈렸는지

이 접근 방식은 연습을 추상적인 말장난에서 구체적이고 관찰 가능한 협업 행동으로 바꿔 준다.

실제 시스템에서 시작하라: 개발 관점에 초점을 둔 사고 시나리오 설계

많은 테이블탑 시나리오는 너무 피상적이다. “API가 죽었다”라든지 “데이터베이스가 느려졌다” 같은 식이다. 하지만 실제 시스템은 그렇게 단순하게 망가지지 않는다.

대신, 여러분의 소프트웨어와 인프라가 실제로 실패하는 방식을 닮은, 개발 중심의 장애 시나리오를 설계하라.

• 모니터링 시스템이 보내는 것과 **똑같은 알람 이름과 심각도(severity)**를 사용한다
• 실제 종속성(dependency) 구조를 반영한다 (예: “Feature Flag 서비스가 부분적으로 장애 → 가입 플로우에 연쇄 영향”)
• 사람들이 실제로 보게 될 실제 대시보드나 스크린샷을 포함한다

개발 관점의 사고 시나리오 예시:

• 특정 서비스에서 500 에러가 급증하는데, 그 원인이 Feature Flag 롤아웃이다
• 잘못 설정된 CI/CD 파이프라인이 특정 리전에만 잘못된 설정(config)을 배포한다
• 스테이징에서는 잘 되던 스키마 마이그레이션이 프로덕션 부하에서는 데드락을 일으킨다
• 서드파티 API 제공자가 미묘하게 성능 저하를 겪는데, 우리 헬스 체크는 이를 깔끔히 구분해 내지 못한다

시나리오를 이런 현실에 앵커링(anchoring)하면 다음과 같은 장점이 있다.

• 팀에 바로 도움이 되는 내용이 된다
• 실제 시스템과 프로세스에 대한 학습에 집중할 수 있다
• 아무도 대비할 수 없는 “영화 속 재난”식 시나리오를 피할 수 있다

이미 가지고 있는 아티팩트에서 직접 연습을 뽑아내기

가장 빠르게 가치 있는 테이블탑 연습을 만드는 방법은 이미 가지고 있는 것들을 재활용하는 것이다.

1. 알람(Alerts)

   • 모니터링/오브저버빌리티(Observability) 스택에서 대표적인 알람을 내보내거나 스크린샷으로 캡처한다.
   • 요약(summary), 영향 받는 컴포넌트, 심각도(severity), 타임스탬프를 넣어 실물 카드로 만든다.

2. 런북(Runbooks)

   • 관련 런북 전체 또는 핵심 부분을 인쇄한다.
   • 의사결정 분기점에 하이라이트를 친다. ("X이면 Y를, X가 아니면 Z를 하라" 같은 부분)

3. 플랫폼 & 도구(Platforms & Tools)

   • 대시보드, 로그 화면, 티켓 시스템, 인시던트 채널(필요하다면 마스킹/익명화) 등을 출력해 둔다.
   • 연습 중 참가자들이 “조회”를 요청할 수 있는 뷰(view) 역할을 하게 된다.

4. 역할 & 프로세스(Roles & Processes)

   • 인시던트 역할 정의(IC, 서기/스크라이브(scribe), 커뮤니케이션 담당, 기술 리드 등)를 가져온다.
   • 인시던트 커맨드 프레임워크를 사용한다면, 한 페이지짜리 요약본을 준비해 둔다.

현재 사용 중인 알람, 플랫폼, 런북을 그대로 기반으로 연습을 만들면, 새로운 프로세스를 발명하는 것이 아니라, 지금 쓰고 있는 프로세스가 의도대로 작동하는지 검증하게 되는 것이다.

스토리 트레인을 운행하기: 단계별 테이블탑 포맷

다음은 아날로그 사고 컨트롤 야드를 운영하는 간단한 진행 포맷이다.

1. 무대를 세팅한다

• **범위(scope)**를 정한다. (하나의 서비스인가? 한 리전인가? 여러 시스템에 걸친 장애인가?)
• 역할을 배정한다. (IC, 온콜 엔지니어, 옵서버, 스크라이브 등)
• 규칙을 설명한다. 프로덕션에는 어떤 변경도 하지 않으며, 모든 일은 종이 위에서만 이뤄지고, 도구는 실제 프로덕션과 동일하게 동작한다고 가정한다.

2. 첫 번째 알람을 소개한다

• 첫 알람 카드를 타임라인에 올려 둔다.
• 온콜 엔지니어에게 묻는다. “당신의 첫 액션은 무엇인가요?”
• 그들이 답할 때, 해당되는 런북이나 도구 카드를 테이블 위로 가져와 배치한다.

3. 시나리오를 진전시킨다

• 시뮬레이션 상 몇 “분”이 지날 때마다, 새로운 알람이나 변화를 추가한다.
  • 두 번째 서비스의 성능이 저하되기 시작한다
  • 고객센터를 통해 고객 문의가 들어온다
  • 대시보드가 이전 가설과 명확히 상반되는 데이터를 보여 준다
• 팀이 이를 어떻게 해석하고, 어떻게 행동할지 스스로 결정하게 둔다.

4. 야드에서 의사결정 경로를 추적한다

• 테이블 위에 선로를 그리거나 카드를 놓아서, 실제 **행동의 경로(path of actions)**를 표현한다.
• 각 의사결정 지점마다 다음을 기록한다.
  • 어떤 정보를 근거로 했는지
  • 어떤 런북 단계를 따랐고, 어떤 단계는 무시했는지
  • 누가 그 결정을 내렸는지

5. 짧은 마이크로 디브리핑(Micro-debrief)을 한다

의미 있는 갈림길마다 1–2분 정도 멈추고 물어본다.

• 관련 런북을 쉽게 찾을 수 있었는가?
• 역할과 책임이 명확하게 느껴졌는가?
• 그 결정을 내리기에 정보가 충분했는가?

6. 해결에 도달한 뒤, 전체를 돌아본다

시뮬레이션 속 사고가 “완화(mitigate)”되면 다음을 수행한다.

• 타임라인과 종이 선로를 함께 복기한다
• 혼란, 지연, 재작업이 발생한 지점을 찾는다
• 후속 작업을 바로 스티커 노트나 카드로 적어 둔다.
  • “런북 X에 사전 점검(prerequisite checks) 섹션이 필요함.”
  • “SRE ↔ 개발팀 간 IC 핸드오프 가이드가 불명확함.”

런북 리허설: 종이 위 연습을 더 나은 문서로 옮기기

이런 연습에서 얻을 수 있는 가장 큰 수확 중 하나는 런북 개선이다.

컨트롤 야드에서 약한 런북은 바로 드러난다.

• 사람들이 런북을 빨리 찾지 못한다
• 단계가 애매하다 (예: “서비스를 재시작한다” — 어느 노드에서? 어떤 커맨드로?)
• 선행 조건과 안전 점검이 빠져 있다
• 여러 팀이 얽힌 복잡한 의존 관계가 문서화되어 있지 않다

종이 위 연습을 **런북 리허설(runbook rehearsal)**로 활용하라.

• 마치 실제로 따라 하는 것처럼, 런북을 소리 내어 한 줄씩 읽어 본다.
• 단계별로 묻는다. “새벽 3시에 잠 덜 깬 엔지니어도 이걸 안전하게 실행할 수 있을까?”
• 불명확하거나 빠진 단계마다 표시를 남긴다.

세션 이후, 이 표시들을 기반으로 구체적인 개선을 한다.

• 다이어그램, 사전 조건, 안전 관련 노트를 추가한다
• 에스컬레이션 경로와 책임 범위를 명확히 한다
• 관련 대시보드와 로그를 이름까지 포함해 명시적으로 링크한다

시간이 지날수록 문서는 **시험된 플레이북(tested playbook)**이 된다. 더 이상 “이러면 좋겠다” 수준의 소망이 아니다.

사고를 넘어: 배운 것을 조직 전체 관행으로 확장하기

테이블탑의 진짜 힘은 단지 장애를 조금 더 잘 다루는 데서 끝나지 않는다. 이를 통해 시스템적 관행이 어디에서 부족한지 보이게 된다.

스토리 트레인 세션에서 반복적으로 등장하는 패턴은 다음 분야를 개선하는 데 활용할 수 있다.

• 용량 계획(Capacity Planning)

  • 특정 의존성에 부담이 계속 몰린다면 → 스케일링 전략을 재검토해야 할 수 있다.
  • “정상 상태가 어떤 모습인지 잘 모르겠다”는 말이 자주 나온다면 → 베이스라인 오브저버빌리티를 개선해야 한다.

• 변경 및 릴리스 관리(Change & Release Management)

  • 장애의 핵심이 늘 복잡한 롤백에 있다면 → 더 안전한 배포 패턴에 투자할 필요가 있다.
  • “최근에 뭐가 바뀌었는지 아무도 모른다”면 → 변경 로그와 가시성을 훨씬 더 강화해야 한다.

• 카오스 엔지니어링(Chaos Engineering)

  • 테이블탑 시나리오를 기반으로, 안전하고 통제된 카오스 실험을 설계할 수 있다.
  • 카오스 실험에도 테이블탑에서 사용한 동일한 런북과 역할 체계를 그대로 적용해 검증한다.

각 테이블탑 연습은 SRE만의 할 일 목록으로 끝나지 않고, 반드시 조직 간 후속 과제를 만들어 내야 한다.

크로스 펑셔널하게: SRE를 넘어 조직 전체를 참여시키기

실제 사고는 조직도(Org chart)를 존중해 주지 않는다. 시뮬레이션도 그래선 안 된다.

가능하다면 다음과 같은 사람들을 함께 참여시켜라.

• SRE / 플랫폼 팀
• 기능 개발 팀(Feature Dev 팀)
• 고객 지원 및 고객 성공(Customer Support & Success)
• 프로덕트 매니지먼트(Product Management)
• 커뮤니케이션 / 인시던트 커뮤니케이션 / PR (고심각도 시뮬레이션의 경우)

크로스 펑셔널 참여의 이점은 다음과 같다.

• 각자가 하는 일이 사고 대응에 어떤 영향을 주고받는지 직접 보게 된다
• 커뮤니케이션/프로덕트 측에서 기술적 트리아지(triage) 타이밍의 현실을 이해하게 된다
• 엔지니어들이 외부 이해관계자의 압력과 커뮤니케이션 요구를 이해하게 된다
• “온콜 몇 명”이 아니라 조직 전체의 준비도가 올라간다

우리는 몇몇 개인을 시험하는 것이 아니라, 조직 전체를 리허설하는 것이다.

시작을 위한 실용적인 팁

• 작게 시작하라. 45–60분, 한 서비스, 한 가지 대표적인 실패 모드부터.
• 안전한 공간임을 분명히 하라. 이건 학습을 위한 자리이지, 비난을 위한 자리가 아니다.
• 역할을 순환시켜라. 개발자가 인시던트 커맨더를 맡아 보게 하고, SRE가 옵서버를 맡아 보게 하라.
• 정기적으로 일정에 넣어라. 월 1회 또는 분기 1회 정도면 실력을 유지하는 데 충분하다.
• 결과를 반드시 문서화하라. 작은 사고 후 회고처럼, 발견 사항과 액션 아이템을 요약해 남겨 둔다.

처음 몇 번의 세션은 어색하고 느리게 느껴질 수 있다. 괜찮다. 바로 거기에 학습이 있다.

결론: 나만의 아날로그 스토리 트레인을 만들자

사고 대응을 개선하는 데 꼭 새로운 도구가 필요한 것은 아니다. 필요한 것은 연습이다.

실제 알람, 런북, 역할을 그대로 활용한 아날로그 사고 스토리 트레인, 즉 종이 컨트롤 야드를 만들면 다음을 할 수 있다.

• 팀이 실제에 가까운 사고를 낮은 위험으로 리허설할 수 있게 한다
• 지금 쓰고 있는 런북과 프로세스가 실제로 통하는지 검증한다
• 책임과 역할을 명확히 하고, 팀 간 협업을 개선한다
• 문서, 용량 계획, 변경 관리 등 여러 영역에 대한 구체적인 개선점을 도출한다

무엇보다도, “잘 되겠지”라는 희망을 습관과 훈련으로 대체하게 된다. 다음 실제 사고가 찾아왔을 때 대응자는 즉흥적으로 몸을 던지는 것이 아니라, 이미 테이블 위에서 함께 걸어 본 플레이북을 실행하게 될 것이다.

알람을 몇 장 출력하라. 선로를 책상 위에 깔아라. 팀을 초대하라. 현실이 강제하기 전에, 먼저 스토리 트레인을 한 번 달려 보자.