아날로그 인시던트 스토리 관람차: 과거 장애를 한 칸씩 다시 돌려보기

인시던트는 완전히 사라지지 않는다.

언젠가의 장애는 이렇게 흔적을 남긴다. 지저분한 로그, 깨진 대시보드, 어렴풋이 기억나는 Slack 스레드, 서둘러 작성된 포스트모템 문서들. 대부분의 팀은 이걸 어딘가에 보관만 해 두고, 같은 장애가 또 오지 않기만을 바라며 앞으로 나아간다.

더 나은 방법은 그 인시던트들을 의도적으로 다시 불러오는 것이다. 무작위로 나타나는 유령이 아니라, 당신이 통제하는 관람차의 탑승객으로.

이 비유에서 관람차의 각 **칸(car)**은 하나의 과거 인시던트다. 이 칸들을 통제 가능한, 반복 가능한 루프로 계속 회전시키면서, 매번 새로운 관점과 더 많은 컨텍스트, 더 나은 도구를 가지고 그 사건을 다시 들여다본다. 시간이 지날수록 이 “아날로그 인시던트 관람차”는 탄탄한 복원력(resilience), 교육, 지속적인 개선을 위한 강력한 엔진이 된다.

이 글에서는 아래를 다룬다.

과거 인시던트를 정리하고 재활용하기 위한 관람차 메타포 활용법
숨은 리스크를 드러내기 위한 아날로그 호러 내러티브 중심의 회고 프레이밍
실제로 행동 변화를 이끄는 데이터 기반 인시던트 리뷰 진행 방법
“Wheel of Misfortune(불운의 바퀴)” 롤플레이 연습 운영법
**자동화된 인시던트 관리(AIM)**와 사람 중심의 성찰 사이의 균형 잡기
장애를 건조한 보고서가 아닌 기억에 남는 이야기로 만드는 법
학습, 업데이트, 개선이 끊이지 않는 지속 회전 구조 만들기

인시던트 관람차: 다른 사고방식의 모델

당신의 인시던트 히스토리를 하나의 관람차라고 상상해 보자.

각 칸은 하나의 과거 장애다. 명확히 정의된, 특정한 사건.
관람차는 인시던트 리뷰의 일정과 프로세스를 뜻한다.
회전은 지속적인 개선의 리듬(cadence)이다.

어떤 시점에는 한 칸만 맨 위에 올라와 있다. 그게 지금 집중해서 보는 인시던트다. 하지만 나머지 칸들도 여전히 그 자리에 있고, 다음에 꼭대기로 올라올 차례를 기다리고 있다.

예전처럼

포스트모템을 한 번 쓰고,
모두에게 공유만 한 뒤,
다시는 꺼내보지 않는 게 아니라,

…회전을 스케줄링한다.

2–4주마다 다른 과거 인시던트가 꼭대기로 올라오게 한다.
그때마다 팀은 다음과 함께 인시던트를 다시 본다.
- 새로 쌓인 데이터
- 변경된/확장된 시스템
- 새로 합류한 팀원들
- 새로운 도구와 관점

기억에 의존하지 않는다. 각 칸에 체계적으로 다시 탑승해서, 그 관점에서 바깥을 다시 내려다본다.

이렇게 하면 예전 교훈이 잊히지 않고, 인시던트 히스토리가 단순한 아카이브가 아니라 능동적인 교육 및 설계 자산으로 기능하게 된다.

아날로그 호러를 회고의 렌즈로 활용하기

인시던트 회고를 하나의 아날로그 호러(analog horror) 작품이라고 생각해 보자.

당신은 불길한 **“파운드 푸티지(found footage)”**를 보고 있다. 로그, 메트릭 그래프, 온콜 페이지, 페이저(PagerDuty 등) 이스컬레이션, Slack 메시지가 그 영상이다.
처음 보면 그저 혼돈처럼 보이지만, 되감아 다시 보다 보면 패턴이 드러난다.
공포는 갑툭튀 점프 스케어가 아니라, 그동안 외면해 왔던 시스템적 리스크를 천천히 깨닫는 데서 온다.

이런 프레이밍이 유용한 이유는 다음과 같다.

아티팩트를 중심에 놓게 만든다
로그, 그래프, 알림, 대시보드, 고객 티켓, 트레이스는 부산물이 아니다. 이게 바로 필름이다. 당신은 이를 하나의 현장처럼 걸어 다니며 조사한다.
포렌식(사후 조사) 사고를 유도한다
“이 이상한 메트릭은 언제부터 조금씩 틀어지기 시작했지?”
“왜 아무도 이 알림을 보지 못했지?”
“그때 우리는 어떤 신호를 잘못 해석했지?”
배경에 깔린 불안(ambient dread)을 드러낸다
목표는 팀을 겁주는 게 아니라, 서서히 쌓이는 리스크를 보이게 하는 것이다.
- 지나치게 복잡한 의존성
- 허술하거나 취약한 런북(runbook)
- 사람이나 시스템에 존재하는 단일 장애 지점(Single Point of Failure)

각 회고를 섬뜩하고 불완전한 증거들로부터 사건을 재구성하는 스토리 작업으로 바라보라. 이런 마인드셋은 자연스럽게 더 나은 가시성(observability), 더 명확한 런북, 더 단순한 아키텍처를 향하게 만든다.

데이터 기반 회고: 감상이 아니라 구조로 이끌기

호러 미학은 분위기를 돕지만, 내용은 반드시 데이터 기반이어야 한다. 좋은 인시던트 회고는 세 단계로 나뉜다.

1. 철저한 사전 준비

미팅 전까지 해야 할 일:

아티팩트 수집:
- 로그와 트레이스
- 메트릭과 그래프(인시던트 전후 시간이 포함된 윈도우)
- 알림 타임라인
- 인시던트 채널 대화 기록
- 고객 영향 타임라인
중립적인 타임라인 작성:
- 무엇이 언제 일어났고, 누가 무엇을 했는지
- 책임 추궁은 배제하고, 사건의 순서만 정리
가이드 질문 정의:
- 어디에서 탐지가 늦어졌는가?
- 어디서 커뮤니케이션이 끊어졌는가?
- 어떤 지점에서 툴이나 런북이 도움이 되었고, 어떤 지점에선 방해가 되었는가?

2. 구조화된 퍼실리테이션

세션에서는 일관된 아젠다를 사용한다.

컨텍스트 & 스테이크(대가) – 무엇이 위험에 처했는가? 매출, 신뢰, 안전, SLO?
타임라인 워크스루 – 스크린에 아티팩트를 띄워두고 분 단위로 따라간다.
탐지(detection) 분석 – 알 수 있었던 시점과 실제로 알게 된 시점의 차이를 본다.
의사결정 포인트 – 어떤 선택이 이후 대응을 제한하거나 꼬이게 만들었는가?
시스템적 요인 – 조직 사일로, 불명확한 오너십, 없는/부실한 런북, 취약한 설계 등.
잘 된 점 – 이 부분을 빼먹지 말 것. 팀의 자신감에 핵심이다.
액션 아이템 – 구체적이고 검증 가능한 후속 조치.

3. 오너와 타임라인을 갖춘 후속 조치

후속 조치가 없는 회고는 그저 이야기 시간일 뿐이다.

인사이트를 담당자, 우선순위, 마감일이 있는 티켓으로 전환한다.
티켓에 인시던트 ID를 태깅해, 나중에 같은 인시던트를 다시 볼 때 무엇이 바뀌었는지 추적할 수 있게 한다.
그 칸이 다음에 관람차 꼭대기에 올랐을 때 이 액션들을 다시 점검한다.
- 런북을 실제로 업데이트했는가?
- 이후 더 작은 인시던트들에서 새 알림이 정말 더 일찍 울렸는가?
- 불안정한 의존성을 해결했는가, 아니면 임시 방편만 덧댔는가?

Wheel of Misfortune: 과거를 롤플레이로 재현하기

관람차에 생동감을 불어넣는 가장 효과적인 방법 중 하나가 **Wheel of Misfortune(불운의 바퀴)**다. 실제 과거 인시던트를 팀이 **그대로 재연(role-play)**하는 연습이다.

진행 방식:

과거 인시던트 하나 선택 – 관람차의 한 칸을 고른다.
시작 상태 준비:
- 시뮬레이션된 알림
- 일부만 보이는 대시보드
- 빈(또는 부분적으로 채운) 인시던트 채널
역할 배정:
- 인시던트 커맨더(Incident Commander)
- 커뮤니케이션 담당(내부/외부)
- 도메인별 SME(데이터베이스, 네트워크, SRE, 프로덕트 등)
실시간 시뮬레이션 진행:
- 로그, 증상, 헷갈리는 단서를 점진적으로 공개한다.
- 팀이 직접 디버깅하고, 결정하고, 커뮤니케이션하게 둔다.
- 때때로 “교란 요소”를 주입한다. (예: 상충하는 신호, 이해관계자들의 계속되는 문의 등)

이 연습의 장점:

새로 합류한 엔지니어들이 인시던트의 감각과 흐름에 대한 직관을 쌓는다.
팀은 압박 속에서 역할 수행, 커뮤니케이션, 의사결정을 연습한다.
런북이 헷갈리거나 비어 있는 부분을 안전한 환경에서 발견할 수 있다.
실패를 숨기기보다, 실패를 말하는 문화를 정상화한다.

시간이 지나면, 당신의 관람차는 단순한 스토리 라이브러리를 넘어, 팀이 정기적으로 타는 훈련장이 된다.

자동화 vs 성찰: AIM이 전부는 아니다

요즘 **자동화된 인시던트 관리(AIM: Automated Incident Management)**는 매우 강력하다.

이상 탐지 및 SLO 기반의 자동 탐지
알림의 자동 라우팅 및 인시던트 자동 생성
자동화된 복구(runbook 실행, 롤백 등)
봇 기반 상태 업데이트와 커뮤니케이션 템플릿

이 모든 것은 속도와 신뢰성에 필수적이다. 하지만 이들은 사람이 주도하는 성찰을 대체할 수 없다.

자동화가 잘하는 일:

더 빠른 탐지
더 신속한 완화(mitigation)
반복 업무(toil) 감소

사람이 잘하는 일:

여러 인시던트에 걸쳐 나타나는 모호한 패턴 해석
트레이드오프 판단: 속도 vs 안전, 비용 vs 복원력
더 단순한 시스템, 더 명확한 프로세스 설계
사람 머릿속에 오래 남는 이야기 만들기

관람차는 자동화가 할 수 없는 일을 사람이 수행하는 공간이다.

“어떻게 더 빨리 페이지를 울릴까?”가 아니라, “왜 이런 취약한 의존성이 존재하는가?”를 묻는 곳.
“어떤 알림을 더 추가할까?”가 아니라, “우리가 이 시스템을 이해하고 있는 방식이 왜 이렇게 틀렸던 걸까?”를 고민하는 곳.

자동화는 관람차를 안전하고 매끄럽게 돌게 해 준다. 하지만 관람차를 애초에 이런 구조로 지어야 하는지 판단하는 건 인간의 성찰이다.

장애를 사람들이 기억하는 스토리로 바꾸기

대부분의 포스트모템 문서는 세금 신고서처럼 읽힌다.

대신 각 장애를 다음 요소를 가진 이야기로 다뤄보자.

등장인물 – 온콜 엔지니어, 인시던트 커맨더, 고객, 서드파티 서비스 제공자 등
스테이크(위험) – 돈, 신뢰, 데이터, 평판 등 무엇이 잃을 수 있었는가
발단(inciting incident) – 첫 번째 이상한 알림, 특이한 에러, 고객의 제보 티켓
상승하는 긴장 – 치솟는 그래프, 폭주하는 Slack 채널, 참여하는 경영진
전환점 – 누군가 진짜 원인을 처음 발견한 “아하!”의 순간
해결 – 완화, 복구, 즉각적인 후속 조치
후일담(aftermath) – 시스템과 이해 수준이 이후 어떻게 달라졌는가

이렇게 인시던트를 스토리로 만들면:

기억하기 쉬워지고
새 팀원에게 가르치기 편해지고
겉보기엔 무관해 보이는 인시던트들 사이에서도 연결고리를 찾기 쉬워진다.
(“이거 작년에 겪었던 그 DNS 이슈랑 느낌이 비슷한데…”)

그 인시던트 칸이 다시 관람차 꼭대기에 올랐을 때, 사람들은 메트릭뿐 아니라 그때의 내러티브 흐름까지 떠올린다. 위기 상황에서 바로 이게 필요하다.

지속적 개선: 관람차를 계속 돌리는 법

멈춰 있는 관람차는 그냥 조형물일 뿐이다. 진짜 가치는 정기적인 회전에서 나온다.

회전을 운영에 녹여라.

인시던트 백로그를 유지한다. 다시 볼 과거 인시던트(칸)들을 우선순위에 따라 정리해 둔다.
주기(cadence)를 정한다. 예: 2–4주마다 한 번씩 회고 리프레시 또는 Wheel of Misfortune 세션.
각 회전에서 무엇이 바뀌었는지를 추적한다.
- 런북 업데이트
- 툴링 개선
- 아키텍처 변경
- 새 알림 또는 SLO 도입
- 교육/온보딩 개선
때로는 인시던트 **칸을 퇴역(retire)**시킨다.
- 아키텍처나 프로덕트가 크게 달라져 더 이상 유의미한 사례가 아닐 때.
- 이때는 축하하라. 그 리스크 클래스는 진짜로 해결된 것이다.

이렇게 하면 “인시던트에서 배운다”는 말이 구호가 아니라 리듬을 가진 실제 관행이 된다.

결론: 나만의 아날로그 인시던트 관람차 만들기

인시던트는 피할 수 없다. 하지만 그걸 허비할지 말지는 선택할 수 있다.

각 장애를 하나의 이야기로 다루고, 그것들을 다시 탈 수 있는 관람차의 칸들로 조직하며, 아날로그 호러식 포렌식 시선과 구조화된 데이터 기반 분석을 함께 활용하면, 인시던트 히스토리는 오래가는 경쟁 우위로 바뀐다.

여기에 연습을 위한 Wheel of Misfortune과, AIM이 제공하는 속도와 인간이 제공하는 통찰 사이의 올바른 균형을 더하면, 단순한 안정성(reliability)을 넘어서 배우는 것을 당연하게 여기는 문화를 만들 수 있다.

예전 인시던트가 아카이브 속에서 사라지게 두지 마라.

관람차에 올려라.

회전시켜라.

당신이 정한 규칙으로 다시 태우고, 내려올 때마다 시스템을 조금씩 더 안전하고, 더 똑똑하고, 더 회복력 있게 만들어라.