포스트모템으로 장애 원인을 개선 과제로 연결하는 방법
포스트모템의 목적과 진행 흐름, Lessons Learned와의 차이, 비난 없는 문화가 장애 재발 방지와 품질 개선에 기여하는 방식을 정리합니다.
2026-08-14 · 최초 발행 2026-04-17
장애 복구 이후에 남겨야 할 분석
프로젝트가 끝난 뒤나 중대한 시스템 장애를 복구한 직후에는, 사건을 해결했다는 사실만으로 작업을 끝내기 어렵다. 어떤 일이 일어났고 무엇이 제대로 작동했으며 어디에서 프로세스가 무너졌는지를 정리해야 같은 실패를 줄일 수 있다.
포스트모템(Post Mortem)은 이 시점에 수행하는 공식 검토와 분석 활동이다. 본래 ‘사후 부검’이라는 뜻에서 나온 말로, 소프트웨어 공학에서는 객관적 데이터를 근거로 사건을 검토하고 이후 실행 계획에 반영하는 품질 보증(Quality Assurance) 프로세스를 가리킨다. 책임을 묻는 자리가 아니라 제품과 프로세스의 결함을 찾아 개선하는 데 목적이 있다.
이 활동을 통해 제품 결함과 프로세스의 허점을 확인하고, 장애나 지연의 근본 원인(Root Cause)을 분석해 재발 방지책을 세울 수 있다. 개인이나 한 팀의 경험도 조직 전체가 활용할 수 있는 지식으로 바뀐다. 개방적이고 비난 없는 환경은 팀원 사이의 신뢰와 협업에도 영향을 준다.
분석을 실행으로 이어가는 흐름
포스트모템은 회의 한 번으로 끝나는 작업이 아니다. 사실을 정리하고 원인을 분석한 뒤, 보고서와 개선 활동까지 연결해야 한다.
먼저 장애 발생 시각, 대응 로그, 코드 변경 이력, 당시 모니터링 지표를 모아 시간 순서에 따른 타임라인을 만든다. 이 단계에서는 해석보다 사실 관계를 분명히 하는 일이 우선이다.
회의에서는 관련 관계자가 수집한 자료를 함께 검토하며 사건의 흐름과 원인을 논의한다. ‘왜’ 발생했는지를 반복해 묻는 5 Whys 같은 기법으로, 표면적인 현상 뒤에 있는 시스템 오류나 프로세스 부재를 찾는다. 이때 Blameless Post Mortem 원칙에 따라 특정인의 실수를 비난하는 대신 시스템적 결함에 논의를 집중한다.
분석이 끝나면 요약, 타임라인, 원인 분석, 잘된 점과 잘못된 점, 구체적인 조치 사항(Action Items)을 담은 보고서를 작성한다. 보고서는 조직 안에 투명하게 공유해 다른 팀도 유사한 문제를 예방할 수 있도록 한다.
마지막으로 조치 사항을 운영과 개발 프로세스에 반영한다. ‘주의하자’는 식의 선언보다 자동화 도구 도입, 체크리스트 갱신, 모니터링 알람 설정 변경처럼 실행 가능한 변경이 필요하다. 변경 이후에는 개선 효과를 지속적으로 모니터링하면서 프로세스를 조정한다.
Lessons Learned와 다른 초점
Lessons Learned와 포스트모템은 모두 경험을 남기는 활동이지만, 다루는 범위와 결과물의 성격이 다르다.
| 구분 | Post Mortem | Lessons Learned |
|---|---|---|
| 발생 시점 | 중대한 장애 발생 직후 또는 프로젝트 종료 시 | 프로젝트 수행 중 상시 또는 마일스톤 종료 시 |
| 주요 대상 | 구체적인 실패 사례나 특정 시스템 이벤트 | 프로젝트 전반의 긍정적/부정적 경험 |
| 분석 기법 | 근본 원인 분석(RCA), 타임라인 기반 심층 분석 | 브레인스토밍, 경험적 지식 기록 |
| 주요 목적 | 시스템적 결함 수정 및 재발 방지 | 지식 베이스 구축 및 향후 프로젝트 참고 |
| 결과물 | 구체적인 Action Item이 포함된 분석 보고서 | 지식 저장소 내의 경험 사례 데이터 |
포스트모템은 특정 실패 사건을 분석하고 즉각적인 시스템 변화를 만들기 위한 활동에 가깝다. Lessons Learned는 프로젝트 전반에서 얻은 긍정적·부정적 경험을 축적해 이후 프로젝트가 참고할 수 있게 하는 데 더 큰 비중을 둔다.
비난 없는 문화가 분석의 품질을 좌우한다
포스트모템이 개선 도구로 작동하려면 심리적 안정감과 비난 없는 문화(Blameless Culture)가 필요하다. 사람이 아니라 시스템에 초점을 맞춰야 참여자들이 사실을 숨기지 않고 공유할 수 있다.
회의의 결과는 담당자와 기한이 정해진 구체적인 작업으로 남아야 한다. 실패를 감추지 않고 공개하는 일은 조직 전체가 유사한 위험에 대비하도록 돕는다. 또한 사건의 기억이 왜곡되기 전에 가능한 한 빠르게 분석을 시작해야 정확한 타임라인과 원인을 확보할 수 있다.
포스트모템은 단순한 사후 검토가 아니라, 반복되는 문제를 시스템적으로 해결하기 위한 활동이다. 분석 결과가 실제 변경과 모니터링으로 이어질 때 제품과 프로세스의 품질을 높이고 기술 부채를 줄이는 기반이 된다.
Sources
- Software Engineering Institute (SEI) - Post-Mortem Analysis Guidelines
- Google Site Reliability Engineering (SRE) Book - Postmortem Culture: Learning from Failure
- Project Management Institute (PMI) - Post-project reviews and lessons learned