Post-mortem(사후 분석) 작성 가이드 — Blameless 장애 회고

Post-mortem은 장애가 끝난 뒤 “같은 일이 반복되지 않도록” 팀이 함께 배우는 과정입니다. 잘 쓴 Post-mortem 하나가 수십 번의 장애를 예방합니다.

Post-mortem의 두 가지 원칙

1. 비난 없는(Blameless) 문화

Post-mortem에서 특정인을 탓하면:

사람들이 정보를 숨기기 시작합니다
“실수한 사람 = 나쁜 사람” 공식이 학습 기회를 파괴합니다
진짜 시스템 문제가 가려집니다

“사람이 실수하기 어려운 시스템”을 만드는 것이 목표입니다.

2. 장애 후 48~72시간 내 작성

기억이 선명할 때 작성해야 정확합니다. 1주일 뒤에는 “아마 그랬을 것”이라는 추측이 섞입니다.

Post-mortem 문서 구조

요약 (Executive Summary)

관리자가 2분 안에 전체 상황을 파악할 수 있어야 합니다.

## 요약

- **발생일시**: 2026-04-03 14:32 ~ 15:20 KST (48분)
- **심각도**: P1
- **영향**: 결제 서비스 완전 중단, 약 2,400건 결제 실패
- **비즈니스 영향**: 예상 매출 손실 약 1,200만원
- **근본 원인**: 배포 전 성능 검증 프로세스 부재로 인한 비효율 쿼리 프로덕션 배포
- **재발 방지**: CI/CD 파이프라인에 부하테스트 게이팅 추가 (04-17 완료 예정)

타임라인

RCA 방법론에서 작성한 타임라인을 그대로 활용합니다. 분(minute) 단위로 기록하고, 각 항목의 출처(로그, 알림, 슬랙 메시지)를 명시합니다.

영향 범위

## 영향 범위

| 항목 | 수치 |
|------|------|
| 장애 지속 시간 | 48분 |
| 영향받은 사용자 | 약 12,000명 |
| 실패한 결제 건수 | 2,412건 |
| 재처리 완료 | 2,109건 (87.5%) |
| 재처리 불가 (환불 처리) | 303건 |
| 예상 매출 손실 | 약 1,200만원 |

원인 분석

5 Whys 또는 피쉬본 결과를 서술합니다. 직접 원인 → 기여 요인 → 근본 원인 순으로 전개합니다.

## 원인 분석

**직접 원인**
payment-api v2.3.1에 포함된 주문 이력 조회 쿼리가
인덱스 없이 전체 테이블 스캔(Full Table Scan)을 수행.
프로덕션 DB(주문 테이블 1,200만 건)에서 쿼리당 평균 28초 소요.
DB 커넥션 풀(max: 50)이 30초 내 고갈되어 신규 요청 처리 불가.

**기여 요인**
- 스테이징 DB에는 약 5,000건만 있어 로컬/스테이징 테스트에서 미탐지
- PR 리뷰에서 쿼리 실행 계획(EXPLAIN ANALYZE) 확인 프로세스 없음

**근본 원인**
배포 파이프라인에 프로덕션 규모 데이터 기준의 성능 검증 단계가 없음.
팀이 빠른 배포 속도를 위해 성능 게이팅을 의도적으로 생략해온 기술 부채.

잘한 점 (What Went Well)

Post-mortem은 문제만 다루지 않습니다. 잘 작동한 것을 명시적으로 기록해야 다음에도 반복됩니다.

## 잘한 점

- 에러율 5% 초과 알림이 장애 시작 6분 만에 발생 → 목표(10분 내) 달성
- 인시던트 리더가 즉시 채널 개설 및 역할 분담 → 혼선 없음
- 런북에 따른 롤백으로 15분 만에 원인 특정 및 조치 완료
- 30분마다 상태 페이지 업데이트로 고객 문의 40% 감소 (CS팀 피드백)

개선 액션

액션	담당	기한	우선순위
CI/CD에 TestForge 부하테스트 게이팅 추가	@platform-team	04-17	P1
PR 체크리스트에 EXPLAIN ANALYZE 첨부 의무화	@tech-lead	04-07	P2
스테이징 DB 데이터 볼륨 프로덕션 10% 수준으로 확대	@dba-team	04-24	P2
결제 API 합성 모니터링 추가 (1분 주기)	@observability	04-10	P1

Post-mortem 회의 진행 방법

문서를 쓰는 것보다 회의를 어떻게 진행하느냐가 더 중요합니다.

진행 순서 (60~90분):
1. 타임라인 리뷰 (15분) — 사실 확인, 기억 오류 수정
2. 원인 분석 (20분) — 5 Whys, 기여 요인 공동 탐색
3. 잘한 점 (10분) — 건너뛰지 말 것
4. 액션 도출 (20분) — 각 항목에 담당자·기한 즉시 지정
5. 공개 범위 결정 (5분) — 팀 내부 / 고객 공개 여부

진행자 역할:

비난성 발언 즉시 중단 (“왜 이런 실수를?” → “어떤 상황이 이 실수를 유발했나?”)
특정인이 대화를 독점하지 않도록 조율
액션 없는 토론이 길어지면 다음 항목으로 이동

Post-mortem 공개 여부

대상	권장 공개 범위
팀 내부	항상 공개 (학습 문화)
전사	P1/P2 장애는 요약본 공유 권장
고객	서비스 약관·SLA 위반 시 공개 의무 검토
외부(기술 블로그)	자발적 투명성 — 장기 신뢰 구축에 효과적

다음 단계

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →