IT 프로젝트 Post Mortem으로 실패를 조직 지식으로 남기는 법

실패가 끝난 뒤에 남겨야 할 것

프로젝트 실패는 그 자체로 끝나는 사건이 아니다. 계획과 실제 결과 사이의 차이, 문제를 해결한 방식, 성공과 실패를 만든 조건을 남기면 다음 프로젝트의 판단 근거가 된다.

Post Mortem은 프로젝트가 끝난 뒤 전 과정을 되짚는 사후 분석이다. 성공한 프로젝트에도 적용할 수 있지만, 실패한 프로젝트에서는 유사한 문제가 반복되지 않도록 원인을 명확히 기록하는 역할이 특히 크다. 분석 대상에는 계획 대비 실제 진행 상황, 발생한 문제와 대응 방법, 성공·실패 요인, 이후에 적용할 개선점이 포함된다.

자료를 모으고, 원인을 분석하고, 다시 쓰이게 한다

사후 분석은 회의 한 번으로 끝나기보다 흐름을 갖춰야 한다. 먼저 프로젝트 계획서, 진행 보고서, 이슈 로그, 변경 요청서처럼 확인 가능한 자료를 확보한다. 팀원의 경험과 피드백도 수집하되, 솔직한 의견이 필요한 경우 익명성을 보장할 필요가 있다. 고객이나 사용자 피드백 역시 분석에 포함한다.

수집한 내용을 바탕으로 핵심 성공·실패 요인을 가려내고, 근본 원인과 영향도를 분석한다. 그 결과는 표준화된 형식으로 문서화한다. 문서는 비난을 위한 기록이 아니라 학습을 위한 기록이어야 하며, 사실에 근거해 작성한다.

완성된 Post Mortem은 조직의 지식 베이스에 등록하고, 관련 미팅을 통해 주요 교훈을 공유한다. 교훈이 배포에서 끝나지 않고 이후 프로세스 개선으로 이어져야 사후 분석이 실제 가치가 된다.

기록을 남길 때 포함할 항목

다음 템플릿은 프로젝트의 맥락부터 후속 조치까지 한 문서 안에서 연결하는 데 쓸 수 있다.

1. 프로젝트 개요
   - 프로젝트명, 기간, 참여 인원
   - 프로젝트 목표와 기대 성과

2. 타임라인
   - 주요 이벤트와 마일스톤
   - 중요 의사결정 시점

3. 성공 요소
   - 잘 진행된 부분
   - 성공 요인 분석

4. 문제점
   - 발생한 주요 이슈
   - 문제의 영향과 대응 방법

5. 근본 원인 분석
   - 문제의 근본 원인
   - 기술적/프로세스적/조직적 요인 분석

6. 교훈(Lessons Learned)
   - 주요 학습 포인트
   - 향후 적용 가능한 개선책

7. 액션 아이템
   - 구체적인 개선 활동
   - 담당자와 일정

문제의 표면 아래까지 원인을 추적하는 방법

근본 원인 분석은 증상만 기록하는 데서 멈추지 않게 한다. 같은 장애나 일정 지연이 다시 나타나지 않도록 기술, 프로세스, 조직 차원의 원인을 함께 살펴야 한다.

5 Whys로 원인을 연속해서 묻기

5 Whys는 문제에 대해 “왜?”라는 질문을 연속 5번 이상 던져 근본 원인에 도달하는 기법이다. 배포 뒤 시스템이 중단된 사건도 메모리 부족이라는 현상에서 멈추지 않고, 코드 리뷰와 품질 관리 체계까지 원인을 이어서 검토할 수 있다.

⤢✕

어골도로 원인의 범주를 넓히기

어골도(Fishbone Diagram)는 결과에 영향을 준 원인을 범주별로 배치해 관계를 살피는 방법이다. 프로젝트 지연을 분석할 때 인력, 프로세스, 기술, 환경, 자료, 관리처럼 여러 관점에서 원인을 검토할 수 있다.

⤢✕

마이그레이션과 UI 개편에서 드러난 실패 조건

대형 금융기관의 레거시 시스템을 클라우드로 이전한 프로젝트는 일정 지연과 예산 초과로 실패했다. 사후 분석에서는 레거시 시스템의 복잡성과 의존성을 과소평가한 점, 클라우드 전환에 필요한 보안 요구사항을 충분히 파악하지 못한 점, 팀의 클라우드 기술 역량 부족, 이해관계자 관리와 변화 관리 프로세스의 부재가 드러났다.

이 경우 다음 프로젝트에서는 마이그레이션 전에 시스템 의존성을 충분히 매핑하고, 금융 도메인의 보안 요구사항을 선제적으로 확인해야 한다. 핵심 기술에 대한 교육과 역량 확보, 이해관계자별 커뮤니케이션 계획도 함께 준비할 대상이다.

전자상거래 플랫폼의 UI/UX 전면 개편은 사용자 불만 증가로 롤백됐다. 디자인 중심으로 접근하면서 사용자 요구사항을 충분히 반영하지 못했고, 실제 사용자 베타 테스트가 부족했다. 운영 환경에서 응답속도가 저하될 정도로 성능 테스트도 충분하지 않았으며, 개편 이유와 가치에 대한 사용자 교육 및 홍보도 미흡했다.

이 사례에서는 디자인 단계부터 실제 사용자를 참여시키고, 단계적 출시(Phased Rollout) 전략을 적용할 필요가 있다. 실제 사용 패턴을 반영한 성능 테스트와 변화 관리 커뮤니케이션 역시 개편 범위에 포함해야 한다.

비난이 아니라 개선으로 이어지는 조직 운영

Post Mortem이 형식적인 문서로 남지 않으려면 개인보다 시스템과 프로세스에 초점을 맞추는 비난 없는 문화(Blameless Culture)가 필요하다. 팀원이 사실과 의견을 솔직하게 말할 수 있는 심리적 안전감이 전제돼야 원인 분석이 왜곡되지 않는다.

프로젝트 종료 절차에 Post Mortem을 포함하고, 도출한 교훈을 실제 프로세스 개선으로 연결하는 피드백 루프도 마련해야 한다. 경영진이 실패를 학습 기회로 바라보고 지원할 때 이 방식은 조직 전반에 자리 잡을 수 있다.

결과물은 저장과 검색이 가능한 지식 관리 시스템에 축적한다. 새 프로젝트를 시작할 때 관련 Post Mortem을 검토하는 절차를 두면, 이전 경험이 다음 계획에 반영된다.

⤢✕

실행 시 놓치기 쉬운 운영 조건

분석은 프로젝트 종료 직후(1-2주 내)에 진행해야 기억이 생생한 상태에서 중요한 인사이트를 확보할 수 있다. 너무 늦어지면 당시의 맥락이 사라질 위험이 있다.

문서에는 데이터와 사실을 기반으로 한 분석을 담고, 개발·QA·운영·고객 등 여러 관점을 포함한다. 액션 아이템은 실행 가능한 개선 활동으로 작성하며, 책임자와 일정을 명확히 지정해 후속 조치가 이어지도록 한다.

프로젝트 규모와 중요도에 따라 형식도 달라질 수 있다. 대규모 또는 중요한 프로젝트는 공식 문서와 미팅으로 다루고, 소규모 프로젝트는 간소화된 체크리스트 형태로 운영할 수 있다. Post Mortem의 핵심은 실패를 숨기거나 비난하는 데 있지 않다. 경험을 분석하고 축적해 조직이 다음 판단을 더 잘하도록 만드는 데 있다.