종이만으로 하는 인시던트 캠프파이어: 상태 회의 대신 장애 스토리 들려주기

장애 리뷰 시간이 서로 눈치만 보는 어색한 재판정 같다면, 당신만 그런 게 아니다. 많은 팀이 “포스트모템(postmortem)을 한다”고 말하지만, 실제로는 타임라인과 티켓, 액션 아이템만 양산하는 의식적인 상태 회의로 끝나곤 한다. 진짜 배움은 거의 일어나지 않는다.

여기서 다른 모델이 등장한다. 바로 종이만으로 하는 인시던트 캠프파이어다.

슬라이드에 매달린 딱딱한 상태 회의 대신, 실제로 그 장애를 겪었던 사람들이 원형으로 둘러앉아(오프라인이든 온라인이든) 그 이야기를 들려준다. 스크린도, 대시보드도, JIRA 보드도 없다. 오직 작성된 포스트모템을 출력(또는 공유)해 함께 ‘이야기’처럼 읽고, 그걸 토대로 대화를 나눈다.

SRE 스타일의 포스트모템과 심리적 안전(psychological safety)을 기반으로 한 이 단순한 형식 변화는, 팀이 실패를 바라보는 방식을 완전히 바꿀 수 있다.

왜 전통적인 장애 리뷰는 잘 작동하지 않을까

많은 사후 장애 리뷰(post-incident review)가 예상 가능한 이유로 실패한다.

학습 세션이 아니라 성과 평가처럼 진행된다.
리더가 노골적이든 은근하든 “실수한 사람”을 찾는다는 신호를 보낸다.
참석자들은 실제로 무슨 일이 있었는지를 탐구하기보다, 자신이 옳은 일을 했다는 걸 증명하는 데 집착한다.
대화는 사람들의 의사결정이 아니라, 기술적인 세부사항과 상태 체크 리스트에 의해 지배된다.

이런 환경에서 사람들은:

자신을 부주의해 보이게 만들 수 있는 세부 사항을 숨긴다.
불확실함이나 혼란스러웠던 순간을 언급하지 않으려 한다.
나중에 돌아보며, 당시의 결정을 더 이성적이고 덜 위험해 보이게 스토리를 재구성한다.

결과적으로 인시던트가 실제로 어떻게 흘러갔는지의 복잡하고 혼란스러운 현실은 문서에서 지워지고, 시스템은 다음번에도 별로 더 안전해지지 않는다.

SRE의 기반: 비난 없는, 체계적인 포스트모템

캠프파이어를 이야기하기 전에, 먼저 단단한 연료가 필요하다. 그게 바로 SRE 스타일의 포스트모템이다.

잘 작성된 SRE 포스트모템은 다음을 수행한다.

인시던트를 체계적으로 기록한다: 무엇이, 언제, 누구에 의해, 어떤 사용자 영향 아래, 어떤 변경 이후에 일어났는지.
**복수형의 근본 원인(root causes)**을 밝힌다: 단순한 “버그 하나”가 아니라, 기여한 조건들, 누락된 신호, 프로세스의 빈틈, 잘못 정렬된 인센티브까지 포함해서 본다.
재발 방지를 위한 변화를 설계한다: 기술적 수정, 런북(runbook) 업데이트, 알림 개선, 교육, 프로세스 변경 등.

핵심은 이 모든 것이 비난 없이(blameless) 이루어진다는 점이다.

비난 없다는 말은 “아무도 책임지지 않는다”거나 “명백한 과실을 무시한다”는 뜻이 아니다. 대신 이렇게 정의한다.

사건에 관여한 모든 사람은, 당시 자신에게 주어진 정보·도구·제약 안에서 최선을 다했다고 가정한다.

그래서 “누가 잘못했나?”라고 묻는 대신, 이렇게 묻는다.

무엇이 이 행동을 그 당시에는 합리적으로 보이게 만들었는가?
어떤 정보가 없었거나, 혹은 오해를 부를 만큼 잘못되어 있었는가?
어떤 압박(시간, 트래픽, 기대치 등)이 의사결정에 영향을 주었는가?

이런 프레이밍은 초점을 개인이 아닌 시스템으로 옮기고, 진짜 학습이 가능하게 한다.

상태 회의에서 스토리 서클로

대부분의 장애 리뷰는 슬라이드, 대시보드, 티켓을 중심으로 돌아간다. 캠프파이어 형식은 이걸 완전히 뒤집는다.

“종이만으로 하는 인시던트 캠프파이어”란?

세 가지 핵심 속성을 가진 **내러티브 기반 리뷰 의식(ritual)**이다.

Paper-first(텍스트 우선): SRE 스타일의 포스트모템을 미리 내러티브 형식으로 작성해 공유한다. 캠프파이어 시간에는 이 문서를 함께 읽고 이야기한다. 상태용 슬라이드도, 실시간 로그 파기(spelunking)도 없다.
스토리 서클: 모두가 같은 레벨에서 모인다. (오프라인이라면 의자를 원형으로 배치하고, 온라인이라면 카메라를 켜고, 발언 기회를 균형 있게 나눈다.) 초점은 인시던트의 이야기를 이해하는 데 있다.
발표가 아닌 대화: “무슨 일이 있었는지 발표”하는 자리가 아니라, 특히 인간의 의사결정과 예상치 못한 전개를 중심으로, “어떻게 이런 일이 전개됐는지 탐구”하는 자리다.

캠프파이어는 포스트모템이 단지 드라이브 안의 PDF가 아니라, 모두가 공유하는 학습 아티팩트로 살아나는 순간이다.

내러티브 포스트모템 설계하기

이 형식을 잘 활용하려면, 포스트모템은 체크리스트가 아니라 이야기처럼 읽혀야 한다.

일반적인 SRE 포스트모템 구성 요소는 그대로 포함하되:

요약 및 영향도
사용자에게 보인 증상
이벤트 타임라인
근본 원인과 기여 요인
시정 조치 및 후속 작업

여기에 사람의 의사결정을 중심으로 한 내러티브를 확장한다.

각 단계에서 사람들은 무엇을 보고, 무엇을 믿고 있었는가?
어떤 신호가 헷갈리거나, 모호하거나, 아예 없었는가?
팀은 어떤 트레이드오프(예: 속도 vs. 안전)를 동시에 고민하고 있었나?
어디에서 가정이나 멘탈 모델이 실제와 어긋났는가?

이 내러티브가 바로 캠프파이어를 위한 “대본”이 된다.

캠프파이어 진행 방법: 단계별 가이드

실제로 사용할 수 있는 구조를 하나 제안한다.

1. 프레임을 명확히 여는 것으로 시작하기

퍼실리테이터(보통 SRE나 인시던트 매니저)는 다음을 분명히 선언하며 시작한다.

이 시간은 학습 세션이지, 성과 리뷰가 아니다.
우리는 누구를 탓하기 위해 모인 것이 아니다.
우리가 이해하려는 건 이것이다: “그때는 왜 이게 말이 되었는가?”

또한 이 자리에서 새로운 시정 조치를 즉석에서 할당하지 않는다는 점을 강조하자. 그래야 발언이 곧바로 개인 업무 증가나 책임 추궁으로 이어질지 모른다는 불안을 줄일 수 있다.

2. 스토리를 함께 읽기

보통 인시던트 리드가 포스트모템의 내러티브 부분을 큰 소리로 읽거나, 천천히 짚어가면서:

주요 의사결정 지점
상황이 혼란스러웠던 부분
타임라인이 갑자기 빨라지거나 느려지는 구간

에서 잠시씩 멈춘다.

그리고 당시 참여자들에게 색을 더해 달라고 요청한다.

“그때 화면에는 무엇이 보였나요?”
“그 순간, 무슨 일이 일어나고 있다고 생각했나요?”
“그 시점에서 가장 확신이 없었던 건 뭐였나요?”

목표는 이벤트 로그를 재생하는 게 아니라, 사람들이 실제로 겪었던 경험을 다시 구성하는 것이다.

3. 호기심에서 출발하는 질문 던지기

질문은 판단이 아니라 호기심을 자극하도록 구성한다. 예를 들어, 이렇게 묻는 대신:

“왜 카나리(canary) 없이 서비스를 리스타트했나요?”

이렇게 묻는다.

“당시 리스타트가 최선의 선택이라고 느껴지게 만든 건 무엇이었나요?”
“어떤 신호들이 이게 안전하다고 말해주고 있었나요?”
“타임라인만 봐서는 보이지 않는, 어떤 제약이나 압박이 있었나요?”

이런 언어는, 복잡한 시스템 안에서 합리적인 행동을 기대한다는 메시지이지, 완벽함을 요구하는 것이 아니라는 신호를 준다.

4. 사람을 보지 말고, 시스템을 보기

어떤 “오류”를 발견했을 때 거기서 멈추지 말고, 계속 파고든다.

어떤 교육이 있었다면, 이 의사결정이 달라졌을까?
어떤 문서가 없었거나, 오래되었거나, 찾기 힘들었나?
어떤 툴이 있었다면 위험 신호를 더 일찍 보여줄 수 있었을까?
어떤 문화적 기대(속도에 대한 압박, ‘영웅적’ 대응 문화 등)가 신중함보다 속도로 사람들을 밀어붙였을까?

그리고 이런 통찰을 “다음에는 더 조심하자” 같은 개인 훈계가 아니라, 시스템적 변경으로 번역한다.

5. 대응 프로세스를 검증하고 개선하기

캠프파이어는 장애 자체뿐 아니라 대응 프로세스를 검증하는 시간도 된다.

알림(Alert)은 제때, 적절한 채널로 울렸나?
온콜과 오너십 체계는 기대대로 작동했나?
커뮤니케이션 채널(Slack, Zoom, 인시던트 룸 등)은 효과적이었나?
런북이 실제 상황과 맞았나, 아니면 대부분 즉흥적으로 대응했나?

포스트모템은 인시던트 대응 플랜을 비춰보는 거울이 된다. 사람들이 성공하기 위해 반복적으로 플레이북을 어길 수밖에 없었다면, 고쳐야 하는 건 사람의 태도가 아니라 플레이북 그 자체다.

심리적 안전: 결정적인 요소

형식만 바꾼다고 충분하지 않다.

종이를 나눠 들고 원을 이뤄 앉았는데도, 결국 다음과 같은 상황이 계속될 수 있다.

사람들이 자기검열을 하고,
리더가 미묘하게 불approval(실망)을 드러내며,
엔지니어들이 자신에게 불리한 내용을 최소화하도록 서사를 조정하는 것.

캠프파이어가 제대로 작동하려면, 실패·실수·판단에 대한 보복과 평가에 대한 두려움을 적극적으로 줄여야 한다.

구체적인 방법은 다음과 같다.

리더가 먼저 나선다. 매니저나 시니어 엔지니어가 자신의 실수와 아찔한 순간(near-miss)을 솔직히 공유한다.
“이거 누가 했어요?”라는 질문을 금지한다. 언제나 “어떤 조건들이 이런 결과로 이어지게 했을까?”로 초점을 옮긴다.
무기화(weaponization)를 막는다. 포스트모템 내용이 성과 평가나 인사 결정에 사용되지 않는다고 명시하고, 실제로 그 원칙을 지킨다.
불확실성을 정상화한다. 확신에 찬 행동뿐 아니라, 혼란스럽거나 몰랐던 지점을 솔직히 드러낸 사람도 적극적으로 인정하고 칭찬한다.

시간이 지나면, 실수를 인정하고 기본적인 질문을 하는 것이 안전하고, 당연한 일로 여겨지는 문화가 자라난다.

캠프파이어 스토리를 오래가는 아티팩트로 바꾸기

캠프파이어의 결과는 그저 분위기 좋은 대화로 끝나지 않는다. 조직 전체가 배울 수 있는 다듬어진 아티팩트로 남는다.

세션이 끝난 뒤에는:

토론에서 나온 인사이트를 포스트모템 문서에 반영해 업데이트한다.
놀라웠던 신호, 모호했던 단서, 협업/조정이 어려웠던 순간 등 핵심 내러티브 포인트를 강조해 정리한다.
합의된 시스템적 변경과 그 가설을 명시한다. (예: “이 변경이 탐지 시간을 X만큼 줄일 것이라고 믿는다.”)
이 문서를 사내 지식 베이스, 러닝 뉴스레터, SRE 길드 등에서 조직 전체와 공유한다.

시간이 지나면 이런 내러티브 포스트모템은 다음과 같은 역할을 한다.

신규 엔지니어 온보딩 자료
교육 및 게임데이(Game Day)에서 사용하는 현실적인 사례
신뢰성과 문화가 어떻게 발전해 왔는지를 보여주는 기록

팀에 캠프파이어 도입하기

처음부터 거대한 문화 변화를 선언할 필요는 없다. 다음에 발생하는 의미 있는 인시던트 한 건에만 시도해 보자.

비난 없는, 내러티브 스타일의 포스트모템을 작성한다.
주요 참여자와 이해관계자 모두를 초대해 60분짜리 “인시던트 캠프파이어”를 잡는다.
이 자리가 스토리 서클이자 학습 세션이라는 점을 명시적으로 알린다.
한 번 형식대로 진행한 뒤, 반드시 피드백을 모은다.

그리고 이렇게 물어보자.

정말 있었던 일을 마음 편히 공유할 수 있었다고 느꼈나요?
이전에는 몰랐던 것을 새로 배웠나요?
우리 시스템이나 프로세스를 실제로 개선할 수 있을 것 같은 변화가 나왔나요?

그 피드백을 바탕으로 이 의식을 팀에 맞게 조정하면 된다.

결론: 두려움에서 호기심으로

인시던트는 피할 수 없다. 하지만, 허울뿐인 리뷰와 조용한 비난 속에 낭비되는 인시던트는 선택 사항이다.

종이만으로 하는 인시던트 캠프파이어는 비교적 단순하지만 강력한 방식으로, 다음을 가능하게 한다.

SRE 스타일의 비난 없는 포스트모템을 실천의 중심에 두고,
상태 보고에서 스토리텔링으로 전환하며,
인간의 의사결정을 시스템의 정당한, 분석 가능한 일부로 다루고,
심리적 안전을 구축해 사람들이 실제로 있었던 일을 공유하도록 만들고,
각 장애를 팀과 시스템을 더 강하게 만드는 공유 학습 아티팩트로 전환한다.

원을 이루어 앉아, 가운데 종이를 두고, 함께 이야기를 나누기 시작하면, 질문은 “누가 실패했나?”에서 “우리는 여기서 무엇을 배울 수 있을까?”로 바뀐다.

진짜 신뢰성은 바로 그 지점에서 시작된다.