Postmortem / RCA 작성법: 블레임리스 회고 문서로 재발 방지까지 끝내는 구조

장애·사고가 한 번 나면, 조직은 두 갈래로 갈립니다.

(1) 사람을 찾고 끝내는 조직, (2) 원인을 구조로 고치고 다시는 반복하지 않는 조직.

Postmortem / RCA(근본원인분석)는 후자를 만드는 문서입니다.

 

PM에게 이 문서는 단순 “사고 보고서”가 아닙니다. 품질·운영·협업의 구조를 리셋하는 결정 문서입니다.

---

 

Postmortem과 RCA는 무엇이 다른가

• Postmortem: 사건을 “공유 가능한 학습”으로 만들기 위한 전체 문서(요약/타임라인/영향/조치/후속)
• RCA(Root Cause Analysis): 그 중에서도 “근본 원인”을 특정하고 재발 방지 장치를 설계하는 파트

 

실무에서는 보통 Postmortem 안에 RCA를 포함해서 한 번에 끝냅니다.

---

 

왜 ‘Blameless(비난 금지)’가 중요한가

블레임리스는 도덕이 아니라 정보 품질의 문제입니다.

 

• 비난 문화가 있으면: 사람들이 사실을 축소하고 방어합니다 → 원인이 흐려집니다
• 블레임리스가 있으면: 판단/추측/감정 대신 관측 가능한 사실이 모입니다 → 재발 방지가 가능해집니다

 

즉, “누가”가 아니라 “무엇이, 어떤 조건에서, 왜”를 찾는 문서로 만들어야 합니다.

---

 

언제 Postmortem/RCA를 반드시 써야 하나

상황	기준 (추천)	이유
장애/서비스 중단	고객 영향이 있으면 무조건	재발 방지 없이 동일 패턴 반복
데이터/정산 오류	금액/정산/정책 영향이 있으면	신뢰 손실이 누적되면 회복이 더 비쌈
보안/권한 사고	접근/노출 가능성만 있어도	“가능성” 자체가 리스크
배포 후 급격한 지표 악화	KPI 하락이 유의미하면	기능이 아니라 “릴리즈 시스템” 문제일 수 있음
고객 CS 폭증	특정 이슈로 집중 발생하면	운영/모니터링/알림 설계 문제 가능

 

---

 

Postmortem/RCA 문서 표준 구조

아래 목차를 그대로 쓰면 “보고”에서 끝나지 않고 재발 방지까지 연결됩니다.

섹션	목적	반드시 답해야 할 질문
1) Executive Summary	1분 이해	무슨 사건이었고, 고객 영향은 무엇이었나
2) Impact	피해 범위 고정	누가/얼마나/얼마 동안 영향을 받았나
3) Timeline	사실 기반 재구성	언제 무엇이 일어났고, 언제 탐지/완화했나
4) Root Cause	근본 원인	진짜 원인은 무엇이며 증상과 어떻게 다른가
5) Contributing Factors	기여 요인	왜 더 커졌나(프로세스/도구/조직/설계)
6) Detection & Response	탐지/대응 평가	탐지는 왜 늦었나, 대응은 왜 어려웠나
7) Corrective Actions	재발 방지	무엇을 바꾸면 반복이 불가능해지나
8) Lessons Learned	학습	다음에는 무엇을 다르게 할 것인가
9) Appendix	근거 격리	로그/그래프/스크린샷/관련 링크

 

---

 

“증상 vs 원인”을 분리하는 규칙

Postmortem이 망하는 첫 번째 이유는 증상을 원인으로 착각하기 때문입니다.

구분	예시	왜 문제인가
증상	“결제가 실패했다”	결과일 뿐, 다시 반복될 수 있음
표면 원인	“PG 응답이 느렸다”	그럴 수밖에 없었던 조건이 남아있음
근본 원인(RCA)	“타임아웃/리트라이 정책이 없고, 장애 시 페일오버가 없었다”	시스템 설계를 고치면 반복이 어려움

 

---

 

RCA를 뚫는 질문 5개

RCA는 분석 프레임이 아니라 질문 기술입니다. 아래 5개를 순서대로 던지면 대부분 뚫립니다.

 

1. 정상이라면 무엇이 일어나야 했나? (기대 행동 정의)
2. 실제로는 무엇이 일어났나? (관측 사실)
3. 둘의 차이는 무엇이고, 어디서 갈라졌나? (분기점)
4. 그 분기점이 가능했던 조건은 무엇인가? (설계/정책/운영/권한)
5. 그 조건을 제거하려면 무엇을 바꿔야 하나? (재발 방지)

---

 

필수 표 1: 타임라인 표 템플릿

타임라인은 반드시 분 단위로 사실만 적습니다. “느낌”은 금지.

시각	이벤트	관측(로그/지표)	의사결정/조치	담당
10:02	오류율 상승 시작	5xx 0.2%→3.1%	온콜 알림 확인
10:08	탐지	알림 트리거	배포 롤백 결정
10:15	완화	오류율 1% 이하	우회 라우팅 적용
10:40	정상화	KPI 회복	원인 분석 착수

 

---

 

필수 표 2: 원인·기여요인 매트릭스

사고는 보통 “원인 1개”가 아니라 원인 1 + 기여요인 여러 개의 조합입니다.0

분류	항목	증거	왜 재발 가능한가	제거 방법 (병합
Root Cause
Contributing
Contributing

 

Corrective Actions의 핵심: ‘액션아이템’이 아니라 ‘장치’로

재발 방지 조치는 “할 일 목록”이 아니라 장치(Guardrail)여야 합니다.

아래 표처럼 “유형”을 강제하면 액션의 질이 올라갑니다.

액션 유형	예시	좋은 이유
예방(Prevention)	타임아웃/리트라이/회로차단기 적용	실패 자체를 낮춤
탐지(Detection)	알림 기준 재설계, SLO/에러버짓 도입	빨리 발견하면 피해가 줄어듦
완화(Mitigation)	페일오버, 기능 플래그, 롤백 자동화	터져도 확산을 막음
복구(Recovery)	런북/온콜 체계, 복구 스크립트	MTTR 단축
학습(Learning)	릴리즈 체크리스트/리뷰 규칙	같은 실수를 반복하지 않음

 

---

 

필수 표 3: 액션아이템 관리 표(오너십/기한/검증)

“재발 방지”는 완료의 정의가 있어야 합니다. 단순 구현이 아니라 검증까지 포함합니다.

액션	유형	오너	마감	완료 정의 (검증)	상태

작성 팁: “완료 정의”에 테스트/모니터링/롤백 시나리오가 없으면, 실제로는 끝난 게 아닙니다.

 

---

 

PM 관점에서 반드시 넣어야 하는 운영 항목 6개

기술 원인만 쓰면 PM 문서가 아니라 개발팀 회고가 됩니다. PM은 운영·조직을 같이 잠가야 합니다.

항목	질문	문서에 넣는 방식
고객 커뮤니케이션	언제/무엇을 공지했나	공지 타임라인 + 메시지 원칙
CS 대응	문의 폭증 시 플로우는?	대응 시나리오 + 책임팀
재발 감시	다시 발생하면 어떻게 알림?	지표/알림 임계치 명시
릴리즈 프로세스	왜 이 배포가 위험했나	체크리스트/승인 규칙 개선
데이터/정산 영향	금전/정산 영향은?	영향 산정 + 조정 계획
오너십	최종 의사결정자는 누구였나	DRI/오너 명시

 

---

 

실패하는 Postmortem 패턴 4가지

실패 패턴	결과	처방
“누가 실수”로 끝남	재발	원인을 시스템/조건으로 기술
타임라인이 부정확	원인 왜곡	분 단위, 사실/증거 기반
액션이 선언적	다음에도 못 막음	예방/탐지/완화/복구로 분류
완료 정의 없음	영원히 미완	검증 기준(테스트/지표) 명시

 

---

 

결론: Postmortem/RCA의 목적은 ‘기록’이 아니라 ‘반복 불가능화’다

좋은 블레임리스 문서는 사건을 예쁘게 정리하지 않습니다.

재발을 구조적으로 어렵게 만들고, 조직의 운영 체계를 한 단계 올립니다.

 

• 사실을 수집하고
• 증상과 원인을 분리하고
• 기여요인을 드러내고
• 장치 기반으로 재발 방지하고
• 오너십과 검증으로 끝냅니다

 

이 다섯 개가 들어가면, 그 문서는 이미 절반 성공입니다.