아날로그 장애 스토리 트롤리: 종이로 굴리는 신뢰성 투어, 사무실 복도를 달리다

팀이 PagerDuty가 울릴 때만 장애를 생각한다면, 이미 한 발 늦은 겁니다.

대부분의 조직은 신뢰성을 대시보드, 채팅 알림, 티켓 큐 속에만 존재하는 무언가로 여깁니다. 그런데 그 보이지 않는 시스템들을 복도로 끌어내서, 물리적으로 눈앞에 보이게 만든다면 어떨까요?

여기 **아날로그 장애 스토리 트롤리(Analog Incident Story Trolley)**가 있습니다. 바퀴 달린 카트(또는 이동식 화이트보드)에 종이로 된 자료들을 가득 싣고, 사무실을 돌아다니며 시스템 신뢰성의 이야기를 전하는 저기압, 저기술(로우테크) 이동형 전시입니다.

트롤리 위에는 무엇이 있나요? 인쇄된 장애 대응 플레이북, 칸반 보드, 포스트모템, “블로커” 리스트 등, 신뢰성을 보이게 만들고, 손에 잡히게 하고, 모두가 공유할 수 있게 만들어 주는 것들입니다.

이건 종이에 대한 향수가 아닙니다. 주의와 행동에 대한 이야기입니다. 위키 페이지는 얼마든지 무시할 수 있습니다. 하지만 "오늘 뭐가 터질 수 있을까?(WHAT COULD BREAK TODAY?)"라는 거대한 포스터가 붙은 카트가 책상 옆에 멈춰 서 있으면, 그건 무시하기가 훨씬 어렵습니다.

지금부터, 실제로 장애 대응과 신뢰성 문화를 개선하는 아날로그 장애 스토리 트롤리를 어떻게 만들고, 어떻게 활용할지 단계별로 살펴보겠습니다.

왜 장애에 아날로그를 쓰는가?

의외로 효과적인 이 저기술 아이디어가 통하는 이유는 세 가지입니다.

가시성(Visibility) – 디지털 시스템은 복잡성을 숨깁니다. 인쇄된 아티팩트로 가득 찬 카트는 어디가 취약하고, 미완성이며, 불명확한지 표면 위로 끌어올립니다.
압박 속에서의 집중(Focus) – 실제 장애 상황에서 사람들에게 필요한 건 도구를 더 늘리는 게 아니라, 명확한 단계입니다. 미리 실제로 종이를 보며 함께 플레이북과 흐름을 연습해 보면, 그게 몸에 배게 됩니다.
공유된 이해(Shared Understanding) – 신뢰성은 기능 간 협업의 결과입니다. 물리적인 트롤리는 대화를 초대합니다. 엔지니어, PM, 지원팀, 리더십이 트롤리 주위에 모여 같은 종이를 보며 손가락으로 짚을 수 있습니다.

1단계: 실제 장애 플레이북으로 트롤리를 채우기

트롤리의 심장은 포괄적으로 문서화된 장애 대응 플레이북입니다. 인쇄되어 있고, 탭으로 구분되어 있으며, 누구나 쉽게 넘겨볼 수 있어야 합니다.

각 플레이북에는 최소한 다음 네 가지 핵심 단계가 담겨야 합니다.

탐지(Detection)
- 우리는 어떻게 무언가 잘못되었다는 걸 아는가?
- 어떤 알림, 지표, 고객 신호가 가장 중요한가?
- 누구에게 어떤 시스템을 통해 페이저/알림이 가는가?
진단(Diagnosis)
- 처음에 던져야 할 질문은 무엇인가?
- 어떤 대시보드나 로그를 가장 먼저 열어야 하는가?
- 이 서비스에서 가장 가능성 높은 장애 패턴(실패 모드) 3~5가지는 무엇인가?
해결(Resolution)
- 안전하게 문서화된 완화(mitigation) 단계는 무엇인가?
- 임시 방안과 장기적인 근본 해결책은 무엇이 있는가?
- 언제 이 장애를 종료해도 안전하다고 판단할 수 있는가?
포스트모템(Post-mortem)
- 누가 리뷰를 리드하는가?
- 어떤 템플릿을 사용하는가?
- 후속 액션 아이템이 생성되고, 끝까지 추적되도록 어떻게 보장하는가?

표준화가 중요합니다. 서비스가 달라져도 구조와 용어는 최대한 동일하게 맞춰서, 누구든 어떤 플레이북을 집어 들어도 금방 방향을 잡을 수 있게 하세요. 고스트레스 장애 상황에서, 익숙함은 큰 힘입니다.

트롤리 위에서는 플레이북을 다음 기준으로 정리합니다.

서비스별 탭: “결제(Payments)”, “로그인(Login)”, “알림(Notifications)” 등
장애 유형별: “지연(Latency)”, “완전 중단(Outage)”, “성능 저하(Degradation)”, “데이터 무결성(Data Integrity)”
치트시트(Cheat Sheet): “PagerDuty가 울리면 이렇게 하라” 같은 1페이지짜리 플로우차트

목표는 하나입니다. 압박이 극대화된 순간에 누구도 다음 단계를 추측하지 않도록 만드는 것. 대신, 모두가 차분하고 문서화된 경로를 따라가게 하는 겁니다.

2단계: 표준화된 절차로 패닉 줄이기

압박이 심할수록, 팀은 ‘순간의 기지’가 아니라 준비된 수준까지 내려옵니다.

아날로그 장애 스토리 트롤리는, 누가 온콜이든 상관없이 장애를 처리하는 표준 절차를 눈에 보이는 형태로 담고 있어야 합니다.

다음 항목들을 인쇄해 눈에 잘 띄게 붙이세요.

장애 대응 역할 정의: Incident Commander, 커뮤니케이션 리드, 테크 리드, 서기(Scribe) 등의 역할과 각자의 책임
심각도(Severity) 레벨 정의: Sev0/Sev1/Sev2의 명확한 기준, 예시, 대응 기대 시간/방식
응답 체크리스트: 시간대별로 쪼갠 단계 예시
- 0–5분: 알림 확인, 역할 배정
- 5–15분: 장애 채널 생성, 첫 상태 업데이트
- 15–30분: 서비스 안정화, 완화 전략 정의, 이해관계자 추가 업데이트
- 30분 이후: 지속 작업, 정기적 업데이트

표준화는 세 가지 효과를 냅니다.

팀을 차분하게 만든다 – 아드레날린이 치솟을 때, 익숙한 단계는 인지 부하를 줄여 줍니다.
일관성을 높인다 – 팀이 달라도 Sev1은 Sev1답게 동일한 방식으로 처리됩니다.
온보딩을 단축한다 – 새 엔지니어가 ‘구전 지식’이 아니라, 구체적 참고자료를 갖게 됩니다.

트롤리를 활용해 팀과 이 절차들을 실제로 함께 걸어보세요. 말 그대로, 미니 소방훈련을 시스템 장애 버전으로 한다고 생각하면 됩니다.

3단계: 커뮤니케이션 ‘의식’을 눈에 보이게 만들기

신뢰성 문제는 대부분 처음부터 대형 장애로 터지지 않습니다. 보통 이렇게 시작합니다.

아무도 깊이 파볼 여유가 없는 이상한 로그
늘 “좀 있으면 알아서 괜찮아지더라” 하고 넘어가는 반복 타임아웃
개별적으로는 보이지만, 시스템 문제로 연결해서 보지 못한 지원 티켓 패턴

이런 **초기 신호들을 터지기 전에 끌어올릴 수 있는 정기적인 커뮤니케이션 의식(ritual)**이 필요합니다.

트롤리 위에 이런 의식들을 명확하게 문서화하세요.

데일리 스탠드업 – 고정 질문 하나 추가:
“오늘 우리가 걱정해야 할 신뢰성/장애 리스크가 있나요?”
주간 1:1 – 이런 프롬프트를 더합니다:
“가까운 시일 안에 터질까봐 마음 한구석이 불편한 부분이 있나요?”
격주 리뷰(또는 스프린트 리뷰) – “신뢰성과 장애 트렌드” 전용 세션을 두고,
- 반복 알림 Top N
- 장기적으로 쌓이고 있는 ‘느린 리스크’들 정리

이 질문들을 포스터나 카드 형태로 트롤리에 붙여 두면, 리스크에 대해 이야기하는 게 정기적이고, 기대되고, 안전한 행동이라는 신호를 팀에 줄 수 있습니다.

그리고 트롤리를 소품처럼 활용하세요.

신뢰성에 포커스하는 주간에는 팀 자리 근처로 트롤리를 직접 끌고 가서 스탠드업을 진행합니다.
“Reliability Week”를 선언해, 모든 팀이 최소 한 개 이상의 리스크 또는 가까스로 피한 사고(near miss)를 보드에 추가하도록 해 보세요.

이렇게 아날로그로 존재감을 주면, 신뢰성은 운영팀만의 문제가 아니라 팀 전체의 습관이라는 메시지가 자연스럽게 스며듭니다.

4단계: 공유 “블로커 & 리스크” 코너 만들기

장애가 터지기 전에는 항상 블로커와 마찰 지점이 있습니다. 팀을 느리게 만들거나, 더 깊은 불안정성을 암시하는 요소들입니다.

트롤리의 한 부분을 공유 블로커 & 리스크 채널로 할당하고, 이를 물리적으로 표현하세요.

예시:

“Blockers” 보드를 만들고, 포스트잇에 적어 붙입니다.
- “X를 디버깅할 로그 접근 권한 기다리는 중”
- “Y에 대한 부하 테스트 아직 자동화 안 됨”
- “Z가 단일 장애 지점(SPOF)인데 백업 플랜 없음”
“Near Misses(아슬아슬하게 피한 사고)” 섹션:
- “깨진 설정이 프로드에 배포될 뻔하다 마지막에 잡힘”
- “고객이 우리보다 먼저 버그를 발견했음”

디지털 세계에서는 이게 #blockers-and-risks 같은 Slack/Teams 채널로 연결될 수 있습니다. 하지만 트롤리는 다음과 같은 역할을 합니다.

복도를 지나가던 리더십의 눈에도 들어오게 만듭니다.
“이거, 왜 3주째 그대로죠?” 같은 대화를 자연스럽게 유도합니다.
문제가 커지기 전에 일찍 드러내는 걸 ‘이상한 행동’이 아니라 당연한 문화로 만듭니다.

시간이 지나면 이 코너는 조기 경보 레이더 같은 역할을 하게 됩니다. 장애로 번지기 훨씬 전에 문제를 포착할 수 있는 공간이 되는 겁니다.

5단계: 칸반 보드로 작업을 시각화하기

장애가 발생하면 작업이 생깁니다. 패치, 리팩터링, 모니터링 개선, 문서 업데이트 등. 명확한 시스템 없이 두면, 이런 일들은 금세 백로그의 블랙홀 속으로 사라집니다.

트롤리에 칸반 보드를 설치하고, 모든 신뢰성과 장애 관련 작업을 이 위에서 관리하세요. 최소한 다음과 같은 컬럼을 둡니다.

Backlog – 이미 알고 있는 신뢰성 개선 작업, 포스트모템 액션 아이템, 안정성에 직접 영향을 주는 기술 부채
Ready – 우선순위가 정해졌고, 정의가 명확해 바로 시작할 수 있는 일
In Progress – 현재 진행 중인 작업
Review – 코드 리뷰, 테스트, 검증을 기다리는 작업
Done – 완료된 작업(당분간은 보이게 두어, 팀의 진척 상황을 시각화)

이렇게 하면 두 가지가 가능해집니다.

범위를 눈으로 파악할 수 있다 – 너무 과부하 상태라면, 더 이상 일을 받지 말아야 한다는 신호가 보입니다.
우선순위를 드러낸다 – 가장 중요한 신뢰성 작업이 실제로 손을 타고 있는지, 아니면 방치되고 있는지 한눈에 알 수 있습니다.

칸반 보드를 사용해 WIP(Work In Progress, 진행 중인 작업 수)를 제한하고, 가장 중요한 신뢰성 관련 작업이 실제로 처리되고 있는지 확인하세요.

6단계: 멀티 프로젝트용 고급 칸반으로 확장하기

조직이 성장하면, 신뢰성 관련 작업은 여러 서비스, 여러 팀, 장애 대응의 다양한 단계에 걸쳐 흩어지게 됩니다.

이때는 트롤리의 칸반을 고급 멀티 프로젝트 보드로 발전시키세요.

이 보드는 다음을 표현할 수 있어야 합니다.

여러 개의 프로젝트/이니셔티브: 예) “결제 시스템 탄력성 강화(Payments Resilience)”, “로그인 보안/안정성 고도화(Login Hardening)”, “온콜 체계 개선(On-call Improvements)” 등
작업을 더 세밀한 프로세스 단계로 나누기:
- Discovery → Design → Implementation → Test → Rollout → Verification
**스윔레인(Swimlane)**으로 분리하기:
- 예방적 신뢰성 작업(예: 카오스 테스트, 용량 계획)
- 반응적 작업(장애 후속 조치, 핫픽스)
- 프로세스 개선(더 나은 런북, 알림 개선, 교육/훈련)

각 카드에는 다음 정보들을 적어 두세요.

Owner(담당자) – 누가 이 일을 책임지는가
Incident 링크 또는 포스트모템 ID – 특정 장애에서 파생된 작업이라면 그 연결 고리
우선순위와 신뢰성에 미치는 예상 영향도

장애 모의훈련이나 리뷰를 할 때, 트롤리 주위에 모여 실제로 손가락으로 따라가며 이야기할 수 있습니다.

특정 장애가 어떤 액션 아이템으로 이어졌는지
그 아이템들이 지금 플로우의 어디쯤 와 있는지
누가 무엇을 책임지고 있는지

이 고급 칸반은 트롤리를 단순한 호기심거리를 넘어, 바퀴 달린 신뢰성 커맨드 센터 수준으로 끌어올립니다.

7단계: 트롤리를 ‘스토리텔링 엔진’으로 활용하기

아날로그 장애 스토리 트롤리의 진짜 힘은 프로세스를 넘어서 **‘스토리’**에 있습니다.

다음을 인쇄해 전시하세요.

선별된 포스트모템 – 실패의 디테일보다는, 그로부터의 학습과 후속 조치에 초점을 맞춘 사례
Before/After 스냅샷 – 특정 개선 전후의 장애 빈도나 MTTR(Mean Time To Recovery) 변화
엔지니어와 고객의 실제 코멘트 – 장애가 났을 때, 그리고 잘 복구되었을 때 사람들이 어떻게 느꼈는지 보여주는 인용문

이 이야기들을 활용해:

새 팀원이 입사했을 때, 조직의 신뢰성 역사를 소개하는 온보딩 자료로 쓰고
리더십에게는 과거 어떤 투자가 이미 어떤 성과를 냈는지 상기시키며
“장애는 단지 재난이 아니라, 우리를 가르치는 교사”라는 메시지를 반복해서 각인시킬 수 있습니다.

이 이야기들을 복도 곳곳으로 굴리고 다니면서, 조직에 이런 공통 내러티브를 쌓게 됩니다.

“우리는 장애를 진지하게 다룬다. 우리는 배운다. 우리는 개선한다. 그리고 그 과정을 모두가 볼 수 있다.”

결론: 종이를 ‘실천’으로 바꾸기

아날로그 장애 스토리 트롤리는 의도적으로 단순합니다. 카트 하나, 몇 장의 프린트물, 칸반 보드, 그리고 신뢰성에 대한 대화를 복도로 끌고 나오겠다는 의지.

하지만 그 뒤에는 강력한 패턴이 있습니다.

문서화된 플레이북은 탐지, 진단, 해결, 포스트모템을 안내합니다.
표준화된 절차는 압박 속에서도 차분하고 일관된 대응을 가능하게 합니다.
커뮤니케이션 의식은 신뢰성 리스크를 일찍, 자주 끌어올립니다.
공유 블로커 채널은 문제가 장애로 폭발하기 전에 포착하게 해 줍니다.
칸반 시각화는 가장 중요한 신뢰성 작업이 실제로 우선순위를 받고 끝까지 완수되도록 돕습니다.
고급 보드는 여러 프로젝트와 단계에 걸친 흐름과 책임을 명확히 보여 줍니다.

더 나은 장애 대응을 위해 초대형 새 툴이 꼭 필요한 건 아닙니다. 필요한 것은 공유된 가시성, 명확한 프로세스, 그리고 리스크에 대해 정직하게, 정기적으로 이야기하는 문화입니다.

때로는, 디지털 문제를 해결하는 가장 좋은 방법이, 복도를 굴러다닐 수 있는 아주 물리적인 것에서 출발하는 것일 수 있습니다.

카트를 하나 구하세요. 플레이북을 인쇄하세요. 칸반을 그리세요. 그리고 아날로그 장애 스토리 트롤리가, 지금 당신 조직이 꼭 들어야 할 ‘신뢰성 스토리’를 들려주기 시작하게 하세요.