포스트모템

장애가 끝난 뒤 원인을 문서화하고 재발 방지를 추적하는 절차. 라이프사이클의 마지막 단계(Closure)다.

비난하지 않는다 (blameless)

사람을 탓하면

• 다음 장애 때 보고가 늦어진다 (숨긴다)
• 원인이 "부주의" 로 끝나 시스템 문제가 안 고쳐진다
• 결과적으로 같은 장애가 반복된다

개인의 실수로 장애가 날 수 있다는 것 자체가 시스템 결함이다

• "왜 한 사람의 실수가 전체를 무너뜨릴 수 있었나" 로 질문을 바꾼다

두 단계를 분리한다

• ① 보고서 작성 — 무슨 일이 있었나 (타임라인·영향·원인)

• ② 재발 방지 과제 추적 — 담당자·기한을 붙여 완료까지 관리

• ① 만 하고 끝내면 문서만 쌓이고 장애는 반복된다

• 그래서 MTTPM(장애 발생 → 재발 방지 완료) 을 따로 재는 것이다

"왜"를 다섯 번

표면   NullPointerException 이 났다
  ↓    왜 그 값이 null 일 수 있었나?
       외부 API 응답에 필드가 빠져 있었다
  ↓    왜 검증이 없었나?
       응답 스키마를 신뢰하는 코드였다
  ↓    왜 리뷰에서 안 걸렸나?
       외부 연동 코드에 대한 체크리스트가 없었다
  ↓    왜 테스트에서 안 잡혔나?
       외부 API 를 목으로만 테스트해 실제 스키마 변화를 못 봤다

재발 방지 과제가 "null 체크 추가" 가 아니라
"외부 응답 스키마 검증 + 계약 테스트 도입" 이 되어야 한다

보고서에 담을 것

• 타임라인 (발생·인지·First Action·복구 시각)
• 영향 범위 (사용자 수·기능·금액)
• 근본 원인 (표면 원인이 아니라)
• 대응 과정에서 잘 된 것과 안 된 것
• 재발 방지 과제 (담당자·기한)

면접 함정

• ❌ "담당자가 실수했습니다" → 시스템 관점 부재로 읽힌다.
• ❌ 원인을 한 겹만 파기 → "NPE였습니다"에서 멈추면 재발 방지가 안 나온다.

타임라인을 먼저 세운다

• 원인 분석보다 타임라인 복원이 먼저다

  • 누가·언제·무엇을 했는지 사실만 나열한다

• 14:02 — 배포 시작

• 14:07 — p99 레이턴시 상승 시작 (알림 없음)

• 14:23 — 고객 문의 접수 ← 사용자 제보로 인지, MTTD 21분

• 14:31 — 인시던트 채널 개설

• 14:38 — 롤백 실행

• 14:41 — 지표 정상화

• 이 표만으로 "알림이 안 울렸다" 는 개선 과제가 바로 나온다

잘 된 것도 적는다

안 된 것만 적으면 회고가 처벌처럼 느껴진다

잘 된 것 예

• 롤백 절차가 문서화되어 있어 3분 만에 실행됐다

• 인시던트 채널 템플릿 덕에 전파가 빨랐다

• 무엇을 유지해야 하는지도 조직의 자산이다

재발 방지 과제가 실패하는 이유

• 담당자가 '팀' 으로 되어 있다 → 아무도 안 한다

• 기한이 없다 → 우선순위에서 밀린다

• 과제가 너무 크다 ("모니터링 개선") → 착수가 안 된다

• 고치는 법

  • 담당자는 개인 이름, 기한은 날짜, 과제는 한 스프린트 안에 끝날 크기
  • 그리고 완료까지 추적한다 (MTTPM)