이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Postmortem은 장애 보고와 무엇이 다른가?
- 재발 방지 action item은 어떻게 작성해야 하는가?
- 비난 없는 분석이 실제 품질 개선으로 이어지려면 무엇이 필요한가?
개요
Postmortem은 장애가 끝난 뒤 원인, 영향, 대응, 재발 방지를 정리하는 문서다.
목적은 책임자를 찾는 것이 아니라 시스템이 같은 실패를 덜 반복하도록 만드는 것이다.
좋은 Postmortem은 “누가 실수했다”보다 “왜 그 실수가 장애로 이어졌고 왜 빨리 발견하지 못했는가”를 묻는다.
Spring 백엔드 장애라면 코드 결함뿐 아니라 배포 검증, 테스트 누락, 알림 기준, DB 상태, 외부 의존성, 운영 문서의 빈틈을 함께 본다.
장애 보고와의 차이
장애 중 보고서는 현재 상태와 의사결정을 위한 문서다.
Postmortem은 사고 후 학습과 재발 방지를 위한 문서다.
두 문서는 연결되지만 관점이 다르다.
- 장애 중 보고: 지금 영향은 무엇인가?
- 장애 중 보고: 어떤 조치를 했고 결과는 무엇인가?
- Postmortem: 왜 탐지가 늦었는가?
- Postmortem: 왜 완화가 지연되었는가?
- Postmortem: 어떤 설계나 절차가 같은 실패를 허용했는가?
- Postmortem: 다음에는 무엇을 측정하고 바꿀 것인가?
장애 중 기록이 부실하면 Postmortem은 기억과 추측에 의존하게 된다.
타임라인 작성
타임라인은 Postmortem의 뼈대다.
| 시각 | 사건 | 근거 | 의사결정 |
|---|---|---|---|
| 10:12 | 주문 생성 실패율 증가 탐지 | 알림, 사용자 신고 | SEV-2 선언 |
| 10:18 | 최근 배포와 연관 가능성 확인 | 배포 시각, 오류 시작 시각 | 배포 버전 조사 |
| 10:27 | payment timeout 증가 확인 | application log | retry 설정 확인 |
| 10:35 | 기능 flag로 신규 쿠폰 적용 중지 | 오류율 감소 | 완화 유지 |타임라인에는 사건뿐 아니라 근거와 의사결정이 들어가야 한다.
단순한 로그 모음은 Postmortem이 아니다.
원인 분석
원인 분석은 하나의 root cause로 끝내지 않는다.
대부분의 장애는 여러 조건이 겹쳐 발생한다.
예를 들어 다음 질문을 던진다.
- 코드가 왜 잘못된 입력을 허용했는가?
- 테스트가 왜 이 조합을 잡지 못했는가?
- 배포 전 검증에서 왜 드러나지 않았는가?
- 알림이 왜 늦거나 너무 약했는가?
- 대응자가 왜 필요한 정보를 바로 찾지 못했는가?
- 완화 조치가 왜 늦었는가?
원인을 계층으로 나누면 action item도 더 실질적으로 나온다.
재발 방지 Action Item
좋은 action item은 실행 가능하고 검증 가능하다.
나쁜 예시는 다음과 같다.
- 더 조심한다.
- 리뷰를 강화한다.
- 모니터링을 개선한다.
- 문서를 업데이트한다.
좋은 예시는 다음과 같다.
- 주문 생성 실패율이 5분간 5%를 넘으면 SEV 후보 알림을 보낸다.
- 쿠폰 적용 로직에 결제 승인 후 저장 실패 통합 테스트를 추가한다.
paymentClienttimeout 변경 시 staging 부하 테스트를 checklist에 추가한다.- 장애 보고서 템플릿에 “사용자 영향 범위” 필드를 필수로 만든다.
각 항목에는 소유자, 기한, 검증 방법이 있어야 한다.
Spring 백엔드 관점
Spring 서비스 Postmortem에서는 다음을 확인한다.
- exception이 사용자 영향과 연결되어 기록되었는가?
- transaction 경계가 외부 API 호출과 충돌하지 않았는가?
- retry가 장애를 완화했는가, 증폭했는가?
- connection pool, thread pool, queue 설정이 트래픽에 맞았는가?
- feature flag로 문제가 된 기능을 분리할 수 있었는가?
- 테스트가 운영 데이터 크기와 상태 조합을 반영했는가?
- 배치나 스케줄 작업이 장애 중 어떤 영향을 주었는가?
코드 수정만으로 끝내면 운영상 같은 실패가 다른 기능에서 반복될 수 있다.
운영 체크리스트
- 장애 중 기록한 타임라인을 먼저 모은다.
- 사용자 영향과 내부 기술 원인을 분리해 적는다.
- 탐지 지연, 완화 지연, 커뮤니케이션 혼선을 분석한다.
- action item마다 소유자, 기한, 검증 방법을 둔다.
- 완료된 action item은 실제로 장애 대응 시간을 줄였는지 확인한다.
- Postmortem 결과를 runbook, 알림, 테스트, 배포 checklist에 반영한다.
- 같은 유형의 과거 장애가 있었는지 비교한다.
장애 신호
- Postmortem이 개인 실수 설명으로 끝난다.
- action item이 “주의”나 “공유”처럼 검증 불가능하다.
- 장애 중 타임라인과 사후 기억이 서로 다르다.
- 재발 방지 작업의 소유자와 기한이 없다.
- Postmortem은 작성됐지만 runbook이나 테스트가 바뀌지 않는다.
- 같은 장애가 반복되는데 이전 action item 완료 여부를 모른다.
이 신호는 Postmortem이 학습 문서가 아니라 형식 문서가 되었다는 뜻이다.
안전한 개선 조치
- 개인 이름보다 시스템 조건과 의사결정 정보를 중심으로 쓴다.
- action item을 탐지, 완화, 예방, 문서화로 나눈다.
- 큰 개선은 작은 검증 가능한 작업으로 쪼갠다.
- 알림 추가는 noise를 만들지 않도록 사용자 영향 기준을 포함한다.
- 테스트 추가는 실제 장애 입력과 데이터 상태를 재현한다.
- 다음 장애 훈련에서 Postmortem action item을 검증한다.
하지 말아야 할 대응
- 장애가 끝났다는 이유로 Postmortem을 생략하지 않는다.
- 원인 하나만 찾고 탐지/완화 지연을 분석하지 않는다.
- 소유자 없는 action item을 남기지 않는다.
- 고객 영향이 큰 장애를 내부 기술 용어만으로 설명하지 않는다.
- 완료 여부를 확인하지 못하는 개선안을 재발 방지라고 쓰지 않는다.
인프라 담당자와 공유할 자료
- 장애 타임라인과 주요 의사결정
- 인프라, 애플리케이션, 외부 의존성 신호
- 탐지 지연과 완화 지연의 원인
- 운영 도구나 권한에서 막힌 지점
- 알림, dashboard, runbook 개선 필요 항목
- action item의 소유자와 기한
Postmortem은 애플리케이션 팀과 인프라 팀이 같은 사건을 같은 시간축으로 이해하게 만든다.
확인 질문
확인 질문
- Postmortem이 장애 중 보고와 다른 점은 무엇인가?
- 현재 대응이 아니라 원인 구조, 탐지 지연, 완화 지연, 재발 방지 작업을 정리한다는 점이다.
- 좋은 action item의 조건은 무엇인가?
- 소유자, 기한, 검증 방법이 있고 같은 실패의 탐지나 완화 시간을 줄여야 한다.
- 비난 없는 분석이 필요한 이유는 무엇인가?
- 개인 실수만 탓하면 시스템 조건과 절차의 빈틈이 남아 같은 장애가 반복되기 때문이다.
리뷰 체크포인트
- 타임라인에 근거와 의사결정이 포함되어 있는가?
- 사용자 영향과 기술 원인이 분리되어 있는가?
- action item이 검증 가능한 형태인가?
- 탐지, 완화, 예방 개선이 모두 검토되었는가?
- 이전 유사 장애와 비교했는가?