post-mortem 24시간 신화: 나는 왜 항상 실패했나
사후 보고서를 제때 쓰지 못하는 패턴을 3년치 실패로 되짚는다.
선언은 세 번 했다
“장애 종료 후 24시간 안에 post-mortem 작성.” 팀 위키에 이 문장을 박아넣은 게 벌써 세 번째다. 2026년 기준으로 따져봐도 내가 실제로 24시간을 지킨 건 손에 꼽는다. 정확히는 두 번. 둘 다 장애 규모가 작아서 메모 수준으로 끝난 케이스였다.
큰 장애일수록 보고서는 늦는다. 이게 패턴이다.
”복구 먼저” 라는 합리적 핑계
올해 초, 결제 API timeout이 40분간 이어졌다. on-call 이 나였다. 새벽 2시에 PagerDuty가 울렸고, 원인은 DB connection pool이 특정 배치 잡에 먹혀버린 것. pool size 를 임시로 올리고 배치를 kill 하고 서비스가 살아났다.
그 뒤 내가 한 일은 Slack에 “복구 완료” 한 줄이었다.
- 새벽 2시 40분에 보고서를 쓸 기력이 없었다. 솔직히 그땐 당연한 거라 생각했다. 그게 문제였다. 기력이 없을 때 쓰는 게 아니라, 기력이 없어지기 전 — 즉 장애 직후 바로가 유일한 타이밍이다. 나는 그 타이밍에 잠들었다.
- 다음날 오전엔 다른 긴급 배포가 있었다. “오후에 쓰지 뭐”라고 미뤘다. 오후엔 PR 리뷰가 쌓여 있었다. 그날은 그렇게 지나갔다.
- 사흘 뒤 팀장이 “보고서 어떻게 됐어요?” 라고 물었다. 그제야 Slack 스레드와 그래프를 조합해 뭔가 썼는데, 당시 판단 흐름을 40%쯤 이미 잊은 상태였다. “왜 pool size 를 80으로 잡았나” — 기억이 없었다. 그냥 느낌이었던 것 같기도 하고.
기억 감쇠는 생각보다 빠르다
심리학 연구 같은 걸 인용하려는 게 아니다. 그냥 내 경험 얘기다.
장애 대응 중엔 판단이 연속으로 쌓인다. “이 수치가 이상하다 → 여길 먼저 본다 → 아니다 저쪽이다 → 결국 여기서 터졌다.” 이 흐름이 post-mortem 에서 가장 값진 부분인데, 24시간이 지나면 절반은 뭉개진다. 72시간이 지나면 “그냥 connection pool 문제였음” 한 줄로 압축된다.
- 복구 직후 15분이 골든타임이다. 그때 손이 떨려도 메모를 해야 한다. “왜 처음엔 캐시를 의심했나”, “두 번째 재시작은 왜 효과가 없었나” — 이 맥락은 자고 나면 증발한다. 내가 두 번 지킨 24시간 케이스는 모두 그 15분 안에 노션에 덩어리를 던져놓은 덕분이었다.
- 숫자는 남아도 판단은 안 남는다. 그래프는 Datadog에 고스란히 있다. 문제는 “왜 그 그래프를 먼저 열었나” 다. 그게 엔지니어링 직관이고, 그게 팀 학습의 핵심인데, 그 맥락이 사라진다.
- 팀원 증언도 식는다. 함께 대응한 동료가 “그때 내가 이걸 먼저 봤던 이유가…” 를 48시간 뒤엔 “아 그냥 그랬던 것 같아요” 로 답한다. 인터뷰 타이밍을 놓치면 보고서가 1인칭 회고로만 남는다.
포맷 완벽주의가 발목을 잡는다
우리 팀 post-mortem 템플릿은 잘 만들어져 있다. 타임라인, 근본 원인, 5-why, 재발 방지, 담당자 지정. 처음 만들 때 뿌듯했다.
막상 장애 직후 그 템플릿을 열면 숨이 막힌다.
- “5-why 를 지금 다 채워야 한다” 는 강박이 오히려 시작을 막는다. 완성된 보고서를 써야 한다는 압박이 빈 문서를 방치하게 만든다. 24시간 룰을 지키려면 초안이 엉망이어도 괜찮다는 팀 합의가 먼저 필요했다. 나는 그 합의를 이번에야 제대로 했다.
- 최근엔 템플릿을 둘로 쪼갰다. 24시간 이내 “스케치” — 타임라인 + 현재 가설만. 72시간 이내 “확정본” — 5-why + 재발 방지. 이렇게 나누자 스케치는 부담이 줄었고, 실제로 지난달엔 처음으로 팀 전체가 스케치를 24시간 안에 올렸다.
- 단, 확정본을 72시간 안에 쓴다는 새 약속도 이미 한 번 어겼다. 같은 패턴이다.
미루기의 진짜 이유
솔직히 말하면 창피해서다.
보고서를 쓰면 내 판단 실수가 기록으로 남는다. “왜 처음에 캐시를 의심했나” — 틀린 판단이었고, 그게 15분을 낭비했다. 그걸 문서화하기가 싫은 거다. 무의식 수준에서.
- blame-free 문화를 내가 가장 강조해왔는데, 정작 나 자신에게 blame-free 가 안 됐다. 팀원 실수엔 “타임라인에 사실만 쓰면 돼” 라고 하면서, 내 실수는 뭉개거나 “판단 미스” 한 줄로 처리했다.
- 그 결과 보고서가 학습 문서가 아니라 무결한 사후 해설이 된다. “원인은 X였고, Y로 해결했다.” 깔끔하지만 재발 방지엔 쓸모가 없다. 왜 X를 늦게 발견했는지가 빠져 있으니까.
- 이번 달엔 직접 내 오판을 타임라인에 명시했다. “02:17 — 캐시 문제로 오판, 5분 소요.” 그걸 올렸을 때 팀에서 아무도 뭐라 안 했다. 당연한 건데, 혼자 크게 생각한 거였다.
다음 한 가지
장애 종료 직후 15분 — Slack 에 “복구 완료” 치기 전에 노션 스케치 링크를 먼저 붙인다. 순서를 바꾸는 것만으로 충분한지, 다음 글에서 확인한다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.