아날로그 인시던트 스토리 캐비닛: 작가실처럼 장애 스토리 플롯 짜기

어떤 엔지니어링 팀이든 자기만의 전쟁 이야기가 있습니다. 새벽 3시의 페이저 알림, 도미노처럼 무너진 장애, “도대체 이게 어떻게 가능하지?” 싶은 버그들. 대부분 이런 이야기들은 어딘가에 반쯤만 적힌 문서, 흩어진 채팅 로그, 혹은 그때 현장에 있던 사람들의 머릿속에만 남아 있습니다.

그런데 이런 인시던트를 연속 드라마의 에피소드처럼 다룬다면 어떨까요? 장애 리뷰 시간이 마치 고급 드라마 작가실처럼 느껴진다면요? 구조와 캐릭터 아크, 그리고 주제가 모두 맞물려서, 여러분의 시스템과 팀이 실제로 어떻게 작동하는지 강력한 이야기를 들려주는 시간 말입니다.

여기에 **아날로그 인시던트 스토리 캐비닛(Analog Incident Story Cabinet)**이라는 관점을 소개합니다. 인시던트를 의도적으로 만들고, 큐레이션하고, 다시 꺼내보는 이야기로 다루어, 복잡한 시스템에 대한 공유 이해와 팀으로서의 성장 과정을 쌓아가는 방법입니다.

왜 스토리텔링이 엔지니어링에 필요한가

스토리텔링 워크숍이라고 하면, 마케팅이나 프로덕트 팀을 떠올리기 쉽지 SRE나 플랫폼 엔지니어링 팀을 떠올리진 않을 겁니다. 하지만 성숙한 기술 조직에서는 스토리텔링이 핵심적인 학습·정렬 도구입니다.

잘 설계된 스토리텔링 워크숍은 다음을 도와줍니다.

성과를 돌아보기: 무엇이 깨졌는지만이 아니라, 무엇을 고쳤고, 어디서 좋은 판단을 했고, 무엇이 좋아졌는지까지.
타인의 경험에서 배우기: 극소수만 겪어 본 인시던트도, 암묵지를 드러내 모두가 학습하게 만들기.
팀 연결 강화하기: 힘들었던 순간을 구조화된, 안전한 방식으로 공유하면서 심리적 안전감을 쌓기.

여기에 인시던트와 장애를 중심으로 스토리텔링 워크숍을 설계하면, 팀워크의 힘이 훨씬 선명하게 드러납니다. 동시에 인시던트 리뷰를 형식적인 컴플라이언스 문서가 아니라, 사람들이 실제로 읽고 싶어 하고, 기억하게 되는 공유 서사로 바꿔낼 수 있습니다.

블레임리스 포스트모템을 ‘이야기의 골격’으로 보기

블레임리스 포스트모템(blameless post-mortem) 자체가 이미 일종의 스토리입니다. 보통 이렇게 구성되지요.

타임라인을 복원하고
원인과 기여 요인을 식별하고
영향과 대응·복구를 정리하고
교훈을 적어둡니다.

하지만 실제로는 **“연대기 + 교훈 한 줄”**에서 그치는 경우가 많습니다.

이때 이런 일이 있었고, 여기서 이런 문제가 있었고, 다음부터는 이렇게 하겠습니다.

여기서 한 걸음 더 나가려면, 포스트모템을 **완성된 글이 아니라 ‘이야기의 골격’(skeleton)**으로 취급해야 합니다. 이 이야기의 핵심은 “누가 실수했다”도 아니고 “이 컴포넌트가 고장났다”도 아닙니다. 진짜 이야기는 복잡한 시스템과 사람들 한 무리가 압박 속에서 어떻게 상호작용했는지, 그리고 그 결과 무엇이 달라졌는지입니다.

관점을 이렇게 바꿔보세요.

인시던트는 하나의 독립된 사건이 아니라, 계속 진화하는 시스템을 다룬 장기 시리즈의 한 에피소드다.

이때 블레임리스는 단지 “누구도 탓하지 말자” 수준을 넘어, 호기심 중심의 스토리텔링이 됩니다. 사람·프로세스·컴포넌트라는 앙상블이 어떻게 이런 결과를 함께 만들어냈는지를 따라가는 이야기 말입니다.

서사 구조에서 빌려오기: 도입, 갈등, 해결, 성장

작가들이 공통된 서사 구조를 사용하는 이유는 그것이 기억에 잘 남고, 의미를 잘 전달하기 때문입니다. 장애에도 똑같이 적용할 수 있습니다. 인시던트 서사를 다음 네 가지 비트로 구성해 보세요.

1. 도입(Setup): 사건 이전의 세계

먼저 “정상(normal)”이 무엇이었는지를 그립니다. 예를 들면:

시스템 상태: 트래픽 수준, 최근 배포나 변경, 이미 인지하고 있던 리스크
팀의 컨텍스트: 온콜 로테이션, 경험 수준, 최근에 있었던 다른 인시던트들
앞으로 중요해질 잠복 요소(일종의 “체호프의 권총”): 부서지기 쉬운 통합 지점, 계속 미뤄둔 TODO, 시끄러워서 무시하게 된 알람 등

목표는 **인시던트 이전에 모두가 ‘당연하다고 믿고 있던 것’**이 무엇이었는지, 나중에 읽는 사람이 이해하게 만드는 것입니다.

2. 갈등(Conflict): 인시던트의 전개

이제 사건이 벌어집니다. 그렇다고 분당 타임스탬프가 찍힌 로그 나열로 채우려 하진 마세요. 대신 이런 것들에 집중합니다.

시그널: 모니터링, 로그, 사용자들이 무엇을 알려줬고, 또 무엇은 알려주지 못했나?
결정: 팀이 왜 특정 가설이나 완화 조치를 선택했나?
놀람: 현실이 기존의 멘탈 모델과 어디서 어긋났나?

인시던트는 단순히 “시스템이 고장났다”가 아닙니다. 복잡한 시스템 안에서, 불완전한 정보를 갖고, 시간 압박 속에 판단하고 움직이는 사람들의 이야기입니다. 이 긴장이 곧 갈등입니다.

3. 해결(Resolution): 안정화와 복구

시스템이 어떻게 복구됐는지뿐 아니라, 왜 그 조치들이 통했는지 보여줍니다.

어떤 완화(mitigation)가 시스템을 안정시켰고, 그 과정에서 어떤 트레이드오프를 감수했나?
인시던트 도중에 무엇을 새로 배우게 되어, 방향을 바꾸게 됐나?
컴플라이언스, 고객, 외부 의존성 같은 제약이 어떤 선택지를 좁혔나?

여기서는 **인과 관계의 명확함(causal clarity)**이 핵심입니다. 개별 복구 단계가 어떤 메커니즘을 건드렸고, 그게 어떻게 전체 상황에 영향을 미쳤는지 선명하게 연결해 두면, 나중에 읽는 사람이 “퍼즐 조각이 어떻게 맞춰지는지” 볼 수 있습니다.

4. 성장(Growth): 이 일로 무엇이 바뀌었는가

많이 빠지는 네 번째 막입니다.

어떤 새로운 역량을 만들었나? (런북, 관측성/Observability 개선, 자동화 등)
멘탈 모델이 어떻게 바뀌었나? ("예전엔 X라고 생각했는데, 이제는 Y라고 안다")
팀의 행동·문화가 어떻게 진화했나? (알람 설계 방식, 리뷰 관행, 에스컬레이션 패턴 등)

이 “성장” 섹션 덕분에, 장애 서사는 단순한 인시던트 리포트가 아니라 캐릭터 중심의 학습 산출물이 됩니다.

캐릭터 아크: 사람과 팀을 주인공으로 보기

장애 이야기는 군상극(앙상블 드라마)에 가깝습니다. 블레임리스 문화에서는 영웅도 악당도 없지만, 각자의 관점이 중요한 캐릭터들은 분명 존재합니다.

상충되는 시그널을 보며 트리아지하는 온콜 엔지니어
커뮤니케이션과 의사결정을 동시에 챙기는 인시던트 커맨더
고객 영향과 완화 조치의 리스크 사이에서 줄타기하는 PO/PM
숨겨진 결합도가 있던 컴포넌트를 맡고 있던 팀

좋은 인시던트 서사는 이런 캐릭터들의 반응, 적응, 성장을 따라갑니다.

"과거 인시던트 경험 때문에 처음엔 DB가 병목이라고 가정했다. 새로운 메트릭들을 보고 난 뒤, 가설을 메시지 큐 쪽으로 수정했다."
"초반에는 명확한 인시던트 커맨더가 없었다. 혼선이 생긴 뒤 한 엔지니어가 역할을 명시적으로 맡으면서 커뮤니케이션이 정리됐다."

이런 작은 캐릭터 아크가 모이면, 결국 하나의 팀 아크가 됩니다.

예전에는 인시던트에 어떻게 대응했는가?
지금은 어떻게 행동하는가?
그 사이 어떤 습관, 도구, 규범이 바뀌었는가?

사람들이 자신을 “이 시스템의 이야기 속에서 변화하는 캐릭터”로 볼 수 있게 되면, 인시던트 리뷰를 성장 도구로 받아들이기 훨씬 쉽고, 단순한 관료적 의무로 느끼지 않게 됩니다.

복잡한 시스템을 ‘스토리 유니버스’로 보기

오늘날의 소프트웨어 시스템은 단순한 기계가 아니라 **복잡 적응 시스템(complex adaptive system)**입니다.

수많은 컴포넌트가 서로 상호작용하고
작은 변화가 큰 결과를 불러오는 비선형성이 있고
피드백 루프와 예기치 않은 거동이 끊임없이 나타납니다.

이야기 관점에서 보면, 인시던트는 결코 단일한 함수 하나의 문제나, 단일 의사결정 하나의 문제가 아닙니다. 항상 구조, 계층, 상호작용이 어떤 결과를 만들어내는지를 다루는 이야기입니다.

이를 잘 드러내려면, 서사를 여러 계층으로 나누어 보는 렌즈가 유용합니다.

로컬 계층: 즉각적인 버그나 미스컨피규레이션 (예: 조용히 재시도만 반복하는 루프)
서비스 계층: 의존성, 타임아웃, 백프레셔(backpressure) 등이 어떻게 효과를 전파했는지
조직 계층: 우선순위, 인력 배치, 문서화 수준, 리뷰 관행이 어떤 배경을 만들었는지
에코시스템 계층: 외부 파트너, 서드파티 API, 인프라 제공자, 규제 환경 등

이 계층들을 이야기 속에 함께 엮으면, 인시던트를 **“시스템 전체의 이야기”**로 보여줄 수 있습니다. 그러면:

개인을 탓하고 싶은 유혹이 줄어들고
루트 원인(root cause)이 단일 지점이 아니라 다차원적인 것으로 보이고
진짜로 효과적인 변화 레버리지를 발견하기 쉬워집니다.

여러분의 “스토리 유니버스”는 코드와 인프라만이 아니라, 조직도, 프로세스, 사람까지 포함한 전체 소시오테크니컬 시스템입니다.

인시던트를 위한 스토리텔링 워크숍 운영법

이제 이 아이디어를 실제로 적용해 보겠습니다. 인시던트 리뷰를 작은 작가실처럼 운영해 보세요.

1. 캐스트 모으기

다음 사람들을 초대합니다.

인시던트에 직접 관여했던 사람들 (온콜, 인시던트 커맨더, SME 등)
인시던트 영향권에 있던 인접 팀
당시 상황을 몰랐던 “새 눈(fresh eyes)” 몇 명 — 내용의 명료성과 가정들을 검증하기 위해

2. 스켈레톤에서 시작하기

블레임리스 포스트모템 초안을 “원고 초안”으로 가져옵니다. 그리고 다음을 합니다.

화이트보드나 공유 문서에 도입 / 갈등 / 해결 / 성장 구조로 맵핑하기
지나치게 기술적이거나, 이해하기 어려운 부분에 “?” 표시해 설명 요청하기
빠져 있는 관점을 찾기 ("여기엔 지원/CS나 고객 이야기가 전혀 없다" 등)

3. 캐릭터와 시스템 아크를 덧입히기

워크숍에서 이런 질문을 던져보세요.

인시던트 중간에 멘탈 모델이 바뀐 지점은 어디인가?
시스템이 예상과 다르게 행동한 순간은 어디인가?
현재 기록에는 잘 드러나지 않지만, 실제로 중요한 역할을 한 팀이나 롤은 누구인가?

각자가 자기 관점에서 이야기를 풀어내도록 독려하고, 그다음에 서로의 시선을 엮어 다층적인 단일 내러티브로 정리합니다.

4. 테마와 재사용 가능한 패턴 뽑아내기

쇼러너(Showrunner)처럼, 여러 인시던트를 두고 반복되는 테마를 찾습니다.

"우리는 크로스 리전 전파 지연(cross-region propagation delay)을 항상 과소평가한다."
"인시던트 커맨더가 누군지 헷갈리는 패턴이 계속 반복된다."
"알람은 자주 울리지만, 빠르게 조치할 만큼의 컨텍스트를 주지 못한다."

이런 패턴에 이름을 붙여 이야기 속에 명시적으로 등장시키세요. 시간이 지나면, 여러분의 인시던트 스토리 캐비닛은 다음과 같은 아키타입들의 라이브러리가 됩니다.

“폭주하는 재시도 스톰”
“빠진 백프레셔”
“구식 설정의 유령”

신입 팀원이 이 아키타입들만 훑어봐도, 시스템과 조직의 약점을 빠르게 감 잡을 수 있게 됩니다.

나만의 아날로그 인시던트 스토리 캐비닛 만들기

여기서 ‘아날로그’는 꼭 종이만 쓰라는 뜻이 아닙니다. 손에 잡히고 둘러볼 수 있고, 사람이 읽기 좋은 형태로 만들라는 의미입니다. 티켓 시스템 어딘가에만 파묻히지 않게요.

실제로 해볼 수 있는 방법들:

인시던트 진(zine) 또는 원페이지 요약: 스토리 중심으로 압축한 요약본에 다이어그램과 핵심 인용구를 곁들입니다.
물리적인 인시던트 월(wall): 인쇄한 요약본을 팀 공간 벽에 붙이고, 테마나 시스템 영역별로 분류해 둡니다.
정기 스토리 회고: 분기마다 2–3개의 인시던트를 골라, 한 시즌의 에피소드처럼 살펴보며 “이번 시즌의 아크와 테마는 무엇이었나?”를 이야기합니다.

목표는 장애 서사를 보이고 공유되는 것으로 만드는 것입니다. 단순히 아카이브에 잠들게 두지 말고요.

맺음말: 실패 로그에서 살아있는 이야기로

복잡한 시스템에서 인시던트와 장애는 필연적입니다. 그러나 헛되이 소비되는 인시던트는 피할 수 있습니다.

인시던트 리뷰를 작가실의 스토리 개발 과정처럼 다루면 다음을 얻을 수 있습니다.

블레임리스 포스트모템을 일관되고 기억에 남는 이야기로 승화시키기
순수한 기술 실패가 아니라 팀워크와 성장에 초점을 맞추기
당시 현장에 없던 사람에게도 복잡한 시스템 상호작용을 이해 가능하게 전달하기
조직 문화와 엔지니어링 의사결정을 형성하는 **공유된 “정전(canon)”**을 쌓기

아날로그 인시던트 스토리 캐비닛의 핵심은, 각 장애가 가진 학습 가치에 대한 존중입니다. 인시던트 하나하나가, 당신의 팀과 시스템이 함께 성장하는 장기 시리즈의 한 에피소드입니다.

그 에피소드를 의도적으로, 구조와 캐릭터 아크, 시스템 관점을 담아 정성껏 빚어내면, 우리는 단지 고장 난 것을 고치는 데서 그치지 않습니다. 더 탄탄하고, 더 정렬되고, 더 인간적인 엔지니어링 조직이 되어 가는 이야기를 쓰게 됩니다.