연필 한 자루로 끝내는 포스트모텀 회전목마: A4 한 장으로 만드는 비난 없는 사고 회고 의식

운영 환경에서 뭔가가 터지면, 우리는 결국 서비스를 복구하고, 한숨 돌리고… 그다음엔 뭘 할까? 대부분은 거기서 이야기가 끝난다. 팀은 다음 업무로 넘어가고, 교훈은 흐릿해지고, 비슷한 유형의 장애가 조용히 다시 나타날 타이밍만 기다린다.

여기서 빠지는 퍼즐 조각은 거의 항상 같다. 일관되고, 가볍고, 비난 없는 사고 후 리뷰(포스트모텀) 의식이다. 12페이지짜리 문서도, 교육이 필요한 복잡한 도구도 아니다. 그저 날것의 혼란을 구체적인 학습으로 바꾸는 단순하고 반복 가능한 방법이다.

여기서 등장하는 것이 **“연필-전용 포스트모텀 회전목마(Pencil-Only Postmortem Carousel)”**이다. 종이 한 장짜리 템플릿, 연필 한 자루, 그리고 사고가 있을 때마다 팀이 꺼내 쓸 수 있는 짧고 구조화된 대화.

포스트모텀이 생각보다 더 중요한 이유

장애 대응은 보통 세 단계로 나뉜다.

1. 트라이애지 & 완화(Triage & Mitigation) – 피를 멈춘다. (즉, 피해 확산을 막는다.)
2. 복구 & 안정화(Recovery & Stabilization) – 서비스를 복구하고 신뢰를 되찾는다.
3. 사고 후 리뷰(Post-incident review) – 벌어진 일을 지속 가능한 개선으로 전환한다.

팀은 보통 1, 2단계는 잘하지만, 특히 바쁠수록 3단계를 조용히 건너뛴다. 하지만 사고 후 리뷰는 마지막에 반드시 필요한 핵심 단계다. 이 단계만이 미래에 레버리지를 만들어 준다.

이 단계가 없으면, 장애는 그냥 비싼 스트레스 이벤트일 뿐이다. 하지만 이 단계가 있으면, 장애는 다음과 같은 투자가 된다.

• 숨겨진 실패 모드와 잠복 버그를 드러낸다.
• 런북(runbook), 도구, 온콜(on-call) 운영 방식을 개선한다.
• 다음 장애의 탐지 시간(TTD)과 복구 시간(TTR)을 줄인다.
• 여러 팀 간의 공통 이해와 공유된 맥락을 만든다.

문제는 이거다. 사람들은 포스트모텀이 쉽고, 빠르고, 감정적으로 안전할 때만 꾸준히 한다.

포스트모텀의 두 가지 핵심 구성 요소

효과적인 장애 회고(incident retrospective)는 대부분 비슷한 기본 구조를 가진다.

1. 사전에 준비된 문서 아티팩트(artifact)

   • 무엇/언제/왜를 구조적으로 담는다.
   • 회의가 타임라인 복원이 아니라 토론과 학습 중심이 되게 만든다.

2. 협업 기반 리뷰 미팅

   • 서로 다른 관점을 한자리에 모은다.
   • 맥락, 트레이드오프, 시스템 차원의 이슈를 드러낸다.
   • 명확한 후속 조치와 책임자를 정리하며 끝낸다.

연필-전용 포스트모텀 회전목마는 이 구조는 유지하되, 오버헤드를 극단적으로 줄인다. 문서 아티팩트는 종이 한 장, 미팅은 **짧고 반복 가능한 의식(ritual)**이다.

왜 종이 한 장이 화려한 도구보다 나은가

복잡한 포스트모텀 도구들은 높은 수준의 엄격함을 약속하지만, 정작 시작하는 장벽을 높여 버리곤 한다.

• "작은" 장애에는 굳이 도구를 열기 망설여진다.
• 템플릿이 위압적으로 느껴져서 작성이 미뤄진다.
• 숙련된 퍼실리테이터가 필요해, 결국 잘 열리지 않는다.

반대로, 가벼운 아티팩트 하나는 상황을 뒤집는다.

• 누구나 종이 한 장 집어 들고 바로 시작할 수 있다.
• 사소해 보이는 장애도 부담 없이 기록할 수 있다.
• 인쇄, 공유, 사진 촬영, 이후 전자 문서화 모두 쉽다.
• 셋업 비용이 없다. 그저 연필과 몇 분이면 충분하다.

무엇보다도, 단순함이 일관성을 가능하게 한다. 포스트모텀의 가치는, 대형 사고뿐 아니라 의미 있는 모든 장애 후에 꾸준히 하는 데서 나온다. 한 페이지짜리 템플릿은 그걸 지속 가능한 수준으로 만들어 준다.

연필-전용 포스트모텀 템플릿

종이 한 장을 네 개의 사분면으로 접거나 나눈다. 그리고 다음과 같이 라벨을 붙인다.

1. 사전 상황 & 컨텍스트(Lead-Up & Context)
2. 사고 타임라인(Incident Timeline)
3. 영향 & 탐지(Impact & Detection)
4. 교훈 & 개선 사항(Lessons Learned & Improvements)

각 영역에 무엇을 적는지 살펴보자.

1. 사전 상황 & 컨텍스트 (왼쪽 위)

여기에는 장애가 나기 이전의 상태를 적는다.

• 최근 변경 사항 (배포, 설정 변경, 마이그레이션 등)
• 관련 시스템 특성 (트래픽 패턴, 의존 서비스 등)
• 해당 영역에 대해 이미 알고 있던 리스크나 열린 이슈들

목표는 추락 지점만 보는 것이 아니라 이륙 활주로를 복원하는 것이다. 많은 심각한 장애는, 오랜 시간 쌓여 온 여러 가지 미검출 상태의 조건들이 한 번에 겹치면서 발생한다.

사전 상황을 기록하면:

• 조용히 존재하던 잠복 버그나 리스크를 찾는 데 도움이 된다.
• 마지막 트리거 이벤트 하나에만 집착하는 것을 막아 준다.
• 테스트 부재, 소유권 불분명 등 시스템적인 빈틈을 드러낸다.

길게 쓰지 말고, 짧은 불릿 포인트 위주로 적는다.

2. 사고 타임라인 (오른쪽 위)

다음으로, 사건의 흐름을 시간 순서대로 정리한다.

• 첫 증상이 언제 나타났는가?
• 언제, 어떤 방식으로 장애를 감지했는가?
• 누가, 어떤 액션을 어떤 순서로 취했는가?
• 언제 영향이 완화되었고, 언제 완전 복구가 이루어졌는가?

단순하게 적는다.

• 타임스탬프와 짧은 설명을 사용한다.
• 핵심 의사결정 지점을 표시한다. (예: "롤백 vs 핫픽스 중 롤백 선택")

명확한 타임라인은 매우 중요하다. 왜냐하면:

• 탐지 지연과 커뮤니케이션 갭이 눈에 보이게 드러난다.
• 도구나 런북이 대응자를 제대로 지원하지 못한 지점을 파악할 수 있다.
• 회고 대화를, 개인의 기억이나 서사 대신 팩트에 기반하게 만든다.

3. 영향 & 탐지 (왼쪽 아래)

여기서는 두 가지 질문에 답한다.

• 누가, 무엇이, 어느 정도로 영향을 받았는가?
• 우리가 실제로 어떻게 이 문제를 알아차렸는가?

다음을 포함한다.

• 영향을 받은 고객, 서비스, 리전(region)
• 장애나 성능 저하의 지속 시간과 심각도
• 데이터 손실, SLA 위반, 재무적 비용(알고 있다면)
• 처음 문제가 감지된 신호 (알림, 고객 문의, 대시보드 지표 등)

이 섹션은 향후 모니터링과 알림 개선에 직접 연결된다. 고객 제보로 먼저 알게 되었다면, 탐지 체계에 큰 개선 여지가 있다는 강력한 신호다.

4. 교훈 & 개선 사항 (오른쪽 아래)

여기가 하이라이트다. 지금까지의 내용을 실질적인 변화로 바꾼다.

• 장애 대응 중 어떤 점이 우리를 놀라게 했는가?
• 무엇이 잘 작동해서 다시 활용할 가치가 있는가?
• 무엇이 우리를 느리게 만들거나 상황을 악화시켰는가?
• 재발 가능성을 줄이거나 영향을 줄이기 위해, 시스템/도구/프로세스 차원에서 무엇을 바꿀 수 있는가?

포인트는 사람이 아니라 시스템과 프로세스에 초점을 맞추는 것이다.

• "온콜이 로그를 직접 grep 해야 했다" → 로그 검색 기능 개선
• "아무도 런북 위치를 몰랐다" → 런북을 중앙화하고 알림에 링크 연결
• "롤백에 25분이 걸렸다" → 배포 및 롤백 도구를 간소화

가능하다면, 교훈을 다음과 같이 구체화한다.

• 오너와 기한이 지정된 구체적인 액션 아이템
• 런북, 대시보드, 알림 설정의 업데이트
• 테스트, 코드 리뷰, 피처 플래그 등 개발 관행의 변경

회전목마를 설계 단계에서부터 비난 없이 만드는 방법

포스트모텀이 서로를 탓하는 자리가 되어버리면, 한 번은 열릴 수 있어도 두 번째는 없다. 비난 없는(blameless) 문화는 선택이 아니라 필수다.

이 의식을 안전하고 솔직하게 유지하려면:

1. 미팅 초반에 기준(norm)을 명시적으로 선언한다.

   • "우리의 목표는 이 장애를 초래하도록 시스템과 프로세스가 어떻게 설계되어 있었는지 이해하는 것이지, 개인의 잘못을 찾는 게 아닙니다."

2. 실수를 성격 문제가 아니라 시스템의 신호로 다룬다.

   • 이렇게 묻는 대신: "왜 X를 확인하지 않고 배포했나요?"
   • 이렇게 묻는다: "그때 X를 확인하지 않고 배포하는 것이 합리적으로 느껴지게 만든 요인이 무엇이었을까요? 다음에는 더 안전한 선택이 기본값이 되게 하려면 무엇을 바꿔야 할까요?"

3. 결과론적 판단(hindsight bias)을 금지한다.

   • 피해야 할 말: "그때는 당연히 알았어야 했죠."
   • 대신: "그 당시 가지고 있던 정보만 놓고 보면, 어떤 옵션들이 보였나요?"

4. 트리거만이 아니라 시스템적 원인을 수집한다.

   • 오해를 부르는 대시보드
   • 모호한 서비스/소유권 경계
   • 빠져 있는 테스트나 세이프가드
   • 부실하게 문서화된 런북

비난 없는 문화는 정확한 데이터를 얻기 위한 전제조건이다. 사람들이 처벌을 두려워하지 않을 때, 실제로 있었던 일뿐 아니라 "아슬아슬하게 비켜간 사고(near-miss)"와 거의 잘못될 뻔한 것까지 솔직하게 공유한다.

연필-전용 회전목마 미팅 운영 방법

시트가 초안 수준으로 작성되면(이상적으로는 주요 대응자나 Incident Commander가 작성), 짧고 집중된 미팅을 연다.

1. 5분 – 시트 전체 훑어보기

   • 발표자가 네 개 사분면을 요약해서 설명한다.
   • 이때는 옆길로 새지 않고, 이해를 위한 질문만 받는다.

2. 10–15분 – 그룹 토론

   • 사전 상황과 타임라인에 빠진 맥락을 보완한다.
   • 도구나 프로세스가 도움이 된 부분과 방해된 부분을 짚는다.
   • 이해관계자들이 영향 범위와 심각도를 공통으로 이해했는지 확인한다.

3. 10–15분 – 개선안 수렴

   • 시스템, 도구, 프로세스, 교육 측면에서 바꿀 수 있는 점을 브레인스토밍한다.
   • 레버리지(효과 대비 비용)가 높은 소수의 항목에 우선순위를 둔다.
   • 각각의 개선안에 대해 오너와 대략적인 일정(기한)을 정한다.

4. 5분 – 마무리 및 클로징

   • 핵심 교훈을 요약한다.
   • 목표는 비난이 아닌 학습이라는 점을 다시 확인한다.
   • 시트를 어디에 보관할지 결정한다. (예: 사진 찍어 공유 드라이브에 업로드, 간단한 디지털 전사 등)

전체 회전목마는 30–40분 안에 충분히 끝낼 수 있다. 그래서 무서운 대형 장애가 아니더라도 모든 의미 있는 사고 이후에 실행하기 훨씬 쉬워진다.

회전목마가 미래의 장애를 어떻게 개선하는가

잘 운영되고 반복 가능한 포스트모텀은 단순한 문서 작업이 아니다. 팀의 장애 대응 방식을 지속적으로 업그레이드하는 피드백 메커니즘이다.

시간이 지날수록, 다음과 같은 변화가 나타난다.

• 더 나은 탐지 – 모니터링과 알림이 개선되면서 고객이 제보하기 전에 우리가 먼저 장애를 알게 된다.
• 더 빠른 대응 – 더 명확한 런북, 더 나은 도구, 더 자신감 있는 온콜 엔지니어.
• 영향 감소 – 더 안전한 배포, 더 나은 격리(아이솔레이션), 더 탄탄한 아키텍처.
• 강한 문화 – 장애를 개인의 실패가 아닌 함께 푸는 퍼즐로 보는 팀 문화.

각각의 종이 한 장은, 시스템이 실제 스트레스 상황에서 어떻게 행동하는지, 그리고 그에 대해 팀이 어떻게 진화해 가는지를 보여 주는 이야기 한 편이 된다.

결론: 종이 한 장과 연필에서 시작하라

사고에서 배우기 위해 꼭 커스텀 툴이나 무거운 프로세스가 필요한 것은 아니다. 필요한 것은 다음 세 가지다.

• 단순하고 반복 가능한 템플릿: 사전 상황, 타임라인, 영향, 교훈.
• 누구나 만들 수 있는 가벼운 아티팩트 한 개.
• 개인이 아닌 시스템에 초점을 맞춘 비난 없는 구조화된 대화.

연필-전용 포스트모텀 회전목마는, 실제로 사용하게 만들기 위해 의도적으로 작게 설계되었다. 마법은 종이가 아니라, 습관에 있다.

다음에 무언가가 망가지면, 고치고 잊어버리지 말자. 종이 한 장을 꺼내 네 개의 칸을 나누고, 연필을 집어 들고, 당신만의 ‘지속적 학습 회전목마’를 돌리기 시작하라.