포스트모템이란? 장애가 끝난 뒤 원인과 재발 방지 대책을 정리하는 방법 쉽게 이해하기
포스트모템은 장애가 끝난 뒤 원인·영향·대응·재발 방지를 정리하는 사후 분석입니다. 타임라인·Root Cause·5 Whys·Blameless·Action Item·MTTD/MTTR·상태 페이지까지 초보 기준으로 정리합니다.
결제 중단·서버 다운·배포 후 500 급증처럼 장애가 나면 먼저 서비스를 정상화합니다. 롤백·복구로 사용자가 다시 쓸 수 있게 만든 뒤에도 「왜 발생했나」「왜 미리 못 잡았나」「다음에 무엇을 바꿀까」가 남습니다. 포스트모템(Postmortem)은 장애가 끝난 뒤 원인·영향·대응·재발 방지 대책을 정리하는 사후 분석입니다.
쉽게 말하면 — 장애가 끝난 뒤 쓰는 ‘사고 분석 보고서’입니다.
언제 쓰나 · 복구가 먼저
전체 접속 불가·결제·로그인·데이터 유실·잘못된 배포 중단처럼 영향이 큰 장애 뒤에 작성합니다. 작은 장애까지 남기기도 서비스마다 기준을 정하면 됩니다. 장애가 진행 중일 때는 포스트모템보다 서비스 정상화가 우선입니다. 장애 중에는 복구, 장애 후에는 분석입니다.
서버를 재시작해 끝났다고 두면 며칠 뒤 같은 문제가 날 수 있습니다. 「재시작으로 해결」이 아니라 「왜 재시작까지 가야 했는가」를 보는 것이 포스트모템입니다.
무엇을 적을까 · 타임라인 · 영향
요약·발생 시간·사용자 영향·시간별 사건(타임라인)·직접 원인·근본 원인·대응·잘된 점·부족했던 점·재발 방지 조치를 담습니다. 처음 읽는 사람이 「무슨 장애였는지」를 바로 알도록 한두 문장으로 요약합니다. 타임라인은 기억보다 로그·모니터링·배포 기록이 정확합니다.
관리자 화면 5분 장애와 결제 5분 실패는 지속시간이 같아도 영향이 다릅니다. 몇 명·어떤 기능·주문·결제·데이터 손실 여부를 적습니다. 운영자가 발견한 시각이 곧 시작 시각은 아닙니다. 실제 오류 시작 시각을 로그로 맞춥니다.
직접 원인 · 근본 원인 · 5 Whys
직접 원인은 마지막으로 넘어진 도미노(예: 메모리 소진으로 앱 종료)이고, 근본 원인(Root Cause)은 그렇게 될 수 있었던 조건(누수 버그·테스트·알림 부재)입니다. 5 Whys는 「왜?」를 반복해 표면에서 멈추지 않는 방법입니다. 디스크 가득 참 → 로그 폭증 → 오류 폭주 → 디스크 모니터링 없음 → 체크리스트 누락처럼 구조 문제로 이어질 수 있습니다.
원인을 「개발자 A의 실수」로만 끝내지 않습니다. 왜 한 사람의 실수가 운영 장애까지 갔는지 — 자동 검증·리뷰·Staging·배포 방식·알림 — 를 봅니다. Blameless Postmortem은 사람을 공격하기보다 시스템이 실수를 막지 못한 이유를 중심합니다. 고의·반복 부주의는 별도이지만, 비난 문화는 장애 은폐로 이어질 수 있습니다.
증거 · MTTD · MTTR · Action Item
분산 추적으로 어느 서비스가 느렸는지, 에러 트래킹으로 배포 직후 오류 급증을 확인할 수 있습니다. 오류율·응답시간 그래프도 유용합니다. MTTD는 발생 후 발견까지 시간, MTTR은 복구까지 시간에 가깝게 쓰입니다. 짧아도 결제처럼 영향이 크면 분석 대상이 됩니다. SEV1~4처럼 등급을 나누면 호출·알림·포스트모템 여부를 맞출 수 있습니다.
「앞으로 주의」만으로는 부족합니다. Pipeline에서 환경 변수 자동 검증처럼 시스템·절차를 바꿉니다. Action Item은 담당·기한·우선순위(즉시·단기·장기)를 적고 완료까지 추적합니다. 문서만 남기고 작업이 안 되면 같은 장애가 반복됩니다. 잘된 점(빠른 감지·빠른 롤백)과 부족했던 점(문의로 처음 인지·롤백 지식 편중)도 함께 적습니다.
장애 공지 · Status Page · 작은 사이트
장애 공지는 「지금 무슨 일인지」를 알리는 것이고, 포스트모템은 종료 후 원인·재발 방지 분석입니다. Status Page(상태 페이지)는 서비스별 상태를 사용자에게 보여 줍니다. 본 서비스와 같은 서버에만 두면 함께 다운될 수 있어, 중요 서비스는 별도 인프라에 두기도 합니다. 1인 운영이라면 「문제·원인·복구·재발 방지」 몇 줄만 남겨도 도움이 됩니다.
포스트모템이 같은 장애를 영원히 막지는 못하지만, 개선으로 이어지면 반복 가능성을 줄입니다. 기록이 쌓이면 배포·DB·외부 API처럼 패턴을 보고 투자 우선순위를 정할 수 있고, 신규 직원에게도 운영 지식이 됩니다. SEO 기술이 아니라 서비스 신뢰·운영 품질을 높이는 방법입니다.
간단한 예시
요약 — 배포 후 DB 연결 수 급증으로 약 12분간 일부 500 오류.
영향 — 마이페이지·주문 조회 일부 실패.
직접 원인 — 연결이 반환되지 않는 코드 배포.
근본 원인 — 부하 테스트·연결 수 경고 부재.
대응 — 이전 버전 롤백 · Action — 자동 테스트·알림·Canary 검토.
자주 묻는 질문
포스트모템이란?
장애 종료 후 원인·영향·대응·재발 방지를 정리하는 사후 분석입니다.
장애 중에도 바로 쓰나?
아닙니다. 복구가 우선이고, 정상화 뒤에 작성하는 것이 일반적입니다.
롤백과의 차이는?
롤백은 장애 중 이전 정상 상태로 되돌리는 작업이고, 포스트모템은 종료 후 원인·재발 방지 분석입니다.
쓰면 같은 장애가 안 나나?
보장할 수 없습니다. Action Item까지 실행하면 같은 종류 장애의 반복 가능성을 줄이는 데 도움이 됩니다.
정리
장애 대응 = 불 끄기 · 포스트모템 = 왜 났는지 조사 · Action Item = 다시 안 나게 실제로 바꾸기
좋은 포스트모템은 「누가 실수했나」에서 끝나지 않고, 왜 장애로 이어졌는지·왜 발견·복구가 늦었는지를 봅니다. 사용자는 「지금 장애인가」「언제 복구되나」를 알고 싶어 하므로, 서비스 상태를 알리는 상태 페이지(Status Page)도 함께 고려할 수 있습니다.