[ITSM] 포스트모템 — 장애를 비난이 아니라 학습으로

포스트모템(postmortem, 사후검토)은 장애가 종료된 뒤 모여 "무슨 일이 있었고, 왜 그랬고, 다음에 같은 일을 어떻게 막을지"를 정리하는 활동입니다. 핵심은 두 단어입니다 — 학습과 재발방지.

여기서 가장 흔한 실패는 회의가 '범인 찾기'로 변질되는 것입니다. 그러면 두 가지가 동시에 망가집니다. 첫째, 탓을 듣게 될 사람은 사실을 숨기거나 축소합니다. 그러면 진짜 원인이 드러나지 않습니다. 둘째, "조심하자"는 결심만 남고 시스템은 그대로이므로, 같은 조건이 오면 같은 장애가 다시 납니다.

포스트모템의 가치는 문서를 만드는 데 있지 않습니다. 그 문서에서 나온 액션아이템이 실제로 닫히고, 같은 종류의 불이 다시 나지 않는 데 있습니다.

비난 없는 포스트모템의 핵심 전제는 이렇습니다: 사람은 그 시점에 주어진 정보·도구·압박 안에서 합리적으로 행동했다. 그래서 묻는 질문이 "왜 실수했어?"가 아니라 "왜 그 행동이 그 시점에 자연스러웠을까?" 로 바뀝니다.

예를 들어 "점검을 건너뛰고 배포했다"는 사실이 있을 때:

• 비난형: "왜 점검을 안 했어? 다음부터 꼭 해." → 사람의 의지에 기댄 해결 → 압박받으면 또 건너뜀.
• 비난 없는형: "그 시점에 점검을 건너뛰는 게 왜 자연스러웠지?" → "배포 가이드에 점검 단계가 없고, 스테이징이 죽어 있어 검증할 곳이 없었다" → 가이드에 점검 단계 추가 + 스테이징 헬스체크 자동화 → 의지가 아니라 구조가 막아줌.

이것은 책임 회피가 아닙니다. 사실을 솔직하게 꺼내야만 진짜 원인을 찾을 수 있고, 진짜 원인은 거의 항상 한 사람의 부주의가 아니라 여러 약한 가드레일의 합입니다. 비난을 거두면 사람들은 자기가 한 일을 숨김없이 말하고, 그 정직함이 더 정확한 학습으로 이어집니다. 단, 비난 없음이 곧 '책임 없음'은 아닙니다 — 액션아이템에는 분명한 담당자가 붙습니다. '사람을 탓하지 않는다'와 '아무도 책임지지 않는다'는 다릅니다.

장애마다 포스트모템을 쓰면 형식만 남고 지칩니다. 그래서 조직은 트리거 기준을 정해 둡니다. 대표적인 트리거는 다음과 같습니다.

특히 위기일발을 포스트모템 대상으로 삼는 조직은 성숙도가 높습니다. 실제 사고가 나기 전, 가장 싸게 배울 수 있는 기회이기 때문입니다.

좋은 포스트모템은 정해진 섹션 순서를 따릅니다. 순서 자체가 '감정(누구 탓)'이 아니라 '사실(무슨 일)'에서 시작하도록 설계돼 있습니다.

여기서 종종 빠뜨리는 게 '잘된 점' 입니다. 장애 회고는 부족했던 것에만 집중하기 쉽지만, 이번에 빨리 알아챈 알람·잘 작동한 롤백 같은 강점도 기록해야 그 강점을 다른 곳에도 복제할 수 있습니다.

포스트모템에서 가장 자주 죽는 부분이 액션아이템입니다. 회의에서는 "재발방지 하겠습니다"가 쏟아지지만, 담당과 기한이 없으면 그 문장은 다음 장애 때까지 그대로 방치됩니다. 그래서 액션아이템은 항상 다음 네 가지를 갖춘 표로 관리합니다.

추적의 실전 규칙:

• 티켓으로 연결: 각 액션아이템은 변경/작업 티켓으로 등록해 평소 백로그와 같은 곳에서 추적합니다. 포스트모템 문서 안에만 있으면 잊힙니다.
• 상태를 끝까지 갱신: 대기 → 진행중 → 완료. 완료는 "코드 머지"가 아니라 "다음 장애를 실제로 막는 상태"까지.
• 닫히지 않은 액션아이템 리뷰: 반복 장애의 포스트모템을 열면, 거의 항상 이전 포스트모템의 액션아이템이 안 닫혀 있던 경우입니다. 정기적으로 미완 액션아이템을 점검합니다.

액션아이템에 우선순위를 매겨, 가장 효과 큰 한두 개라도 반드시 끝내는 편이 열 개를 흐지부지 여는 것보다 낫습니다.

좋은 액션아이템은 담당·기한·검증 가능한 완료 기준 세 가지를 갖춘 것이고, 그것을 열림 → 진행 → 검증 → 닫힘 보드 위에서 닫힐 때까지 추적하는 것이 핵심입니다. 여기서 "검증"이 중요합니다 — 완료는 "코드 머지"가 아니라 "그 조치가 실제로 재발을 막는지 확인된" 상태입니다. 정기 점검(예: 주간)으로 보드를 끝까지 닫지 않으면, 아무리 좋은 회의를 해도 시스템은 그대로이고 같은 장애가 몇 달 뒤 똑같이 다시 터집니다.