"똑같은 실수를 왜 계속 반복하죠?"
프로젝트가 실패했습니다. 팀은 회고를 했지만, 몇 개월 후 비슷한 문제가 다시 발생했습니다.
"다시는 이런 일이 없도록 하겠습니다."
이 말을 들을 때마다 PM은 한숨을 쉽니다. 같은 실패가 반복되는 것을 보면서, 회고가 형식적으로만 진행되고 있다는 것을 느끼기 때문입니다.
30년 넘게 프로젝트를 관리하면서, 그리고 수많은 실패를 지켜보며 느낀 점은, 제대로 된 포스트모템이 없으면 같은 실패가 계속 반복된다는 것입니다. 제가 직접 경험한 프로젝트에서 회고를 했지만 몇 개월 후 비슷한 문제가 다시 발생한 적이 있습니다. 원인은 형식적인 회고였고, 근본 원인을 찾지 못했고, 액션 아이템을 추적하지 않았기 때문입니다.
하지만 **제대로 된 포스트모템(Post-mortem)**은 실패를 학습으로, 경험을 자산으로 만듭니다. 오늘은 현장에서 검증된 실전 방법들을 공유해드리겠습니다.
포스트모템의 진짜 목적: "누가"가 아닌 "무엇"에 집중하기
잘못된 포스트모템의 함정
많은 팀들이 범인을 찾고, 변명하고, 책임을 회피하고, 문서만 작성하고 끝냅니다. "누가 잘못했나요?"라고 물어보고, "저는 그때 다른 일을 하고 있었어요"라고 변명하고, "다른 팀 문제예요"라고 책임을 회피합니다.
하지만 이런 접근 방식의 결과는 팀 사기가 저하되고, 실패를 숨기는 문화가 형성되고, 같은 실수가 반복되고, 학습이 없다는 것입니다.
제가 여러 팀에서 이런 포스트모템을 목격했는데, 결국 같은 실패가 반복되었습니다.
올바른 포스트모템의 핵심
올바른 포스트모템은 시스템 개선에 집중합니다. "무엇이 문제였나요?"라고 물어보고, "무엇을 배웠나요?"라고 학습하고, "다음엔 어떻게 막을까요?"라고 재발 방지를 계획하고, "다른 팀도 알려주세요"라고 지식을 공유합니다.
결과는 지속적 개선, 학습 문화 형성, 실패 감소, 팀 역량 향상입니다.
Blameless 포스트모템 프레임워크: 비난 없는 학습 문화
핵심 원칙
Blameless 포스트모템의 4가지 원칙은 다음과 같습니다:
인간은 실수한다 - 시스템이 방어해야 한다: 개인 탓이 아닌 시스템 문제로 보고, 방어 메커니즘을 강화해야 합니다.
누가 아닌 무엇이 문제인지 집중: "누가" 대신 "무엇이" 문제인지에 집중하고, 프로세스와 시스템을 개선해야 합니다.
투명한 공유가 재발을 막는다: 모든 정보를 공개하고, 팀 전체가 학습할 수 있게 해야 합니다.
모든 실패는 학습 기회다: 실패를 두려워하지 말고, 실패에서 배워야 합니다.
제가 여러 팀에서 이 원칙을 적용해본 결과, 비난 없는 문화가 형성되면서 팀이 실패에서 제대로 배우기 시작했습니다.
포스트모템 실행 프로세스: 6단계로 실패를 자산으로
Phase 1: 준비 단계 (1-2일)
인시던트 관련자 모두와 다양한 관점의 팀원을 참가자로 선정하고, 필요하면 외부 관찰자도 포함합니다.
데이터를 수집합니다. 시스템 로그, 애플리케이션 로그, 모니터링 데이터, 성능 지표, Slack, 이메일, 회의록, 의사결정 과정 기록을 모두 모읍니다.
회의를 준비합니다. 90분 정도의 충분한 시간을 확보하고, 중립적인 진행자와 상세한 기록을 담당할 기록자를 지정합니다. 기본 규칙은 비난 금지, 사실 중심입니다.
제가 여러 포스트모템을 진행해본 결과, 준비가 잘 되어 있을수록 더 깊이 있는 분석이 가능했습니다.
Phase 2: 타임라인 재구성 (30분)
타임라인을 작성할 때는 시간순으로 정리합니다. 인시던트 시작 시간, 각 이벤트 발생 시간, 대응 시간, 해결 시간을 기록합니다.
이벤트를 분류합니다. 트리거(무엇이 시작했는가?), 에스컬레이션(어떻게 확대되었는가?), 대응(어떻게 대응했는가?), 해결(어떻게 해결했는가?)로 나눕니다.
제가 본 실제 사례에서는 배포 시작 후 15분 만에 첫 에러 알람이 발생했고, 30분 만에 에스컬레이션되어 30% 사용자에게 영향을 미쳤으며, 1시간 만에 롤백을 결정했고, 1시간 30분 만에 서비스가 정상화되었습니다. 이런 타임라인을 작성하면 어디서 문제가 시작되었는지, 어떻게 확대되었는지, 어떻게 대응했는지 명확해집니다.
Phase 3: 근본 원인 분석 (30분)
5 Whys 기법을 사용해서 표면적 원인에서 근본 원인까지 5번 "왜?"를 물어봅니다.
제가 본 실제 사례를 예로 들면, 서비스 에러가 발생했는데 원인은 DB 커넥션 풀 고갈이었습니다. 왜 커넥션 풀 고갈이 발생했나요? 새 코드가 커넥션을 반환하지 않았기 때문입니다. 왜 커넥션 미반환 코드가 배포되었나요? 코드 리뷰에서 놓쳤기 때문입니다. 왜 리뷰에서 놓쳤나요? 리소스 관리 체크 항목이 없었기 때문입니다. 왜 체크리스트가 미비했나요? 이전 유사 사례가 없어서 인지하지 못했기 때문입니다.
근본 원인은 리뷰 프로세스의 체크리스트 부족이었습니다. 이렇게 5번 "왜?"를 물어보면 표면적 원인을 넘어서 근본 원인을 찾을 수 있습니다.
Swiss Cheese Model로 방어층을 분석하면 어느 층에서 구멍이 뚫렸는지 확인할 수 있습니다. Development(코드 리뷰, 테스트, Linting), CI/CD(빌드, 테스트, 보안 스캔), Staging(통합 테스트, UAT, 성능 테스트), Production(카나리 배포, Feature Flag, 모니터링), Response(알림, 롤백, 완화) 각 방어층에서 실패한 컨트롤을 식별하고, 구멍이 겹친 지점을 확인해서 개선 방안을 도출하면 됩니다.
Phase 4: 배운 점 정리 (20분)
잘한 점을 정리합니다. 빠른 롤백 결정(30분 내), 명확한 커뮤니케이션, 사용자 영향 최소화, 팀 협력 등이 있었습니다.
개선할 점도 정리합니다. 모니터링 부족, 테스트 커버리지, 배포 프로세스, 대응 시간 등이 있었습니다.
제가 여러 포스트모템을 진행해본 결과, 잘한 점을 정리하면 팀 사기가 올라가고, 개선할 점을 정리하면 다음에 더 잘할 수 있습니다.
Phase 5: 액션 아이템 도출 (20분)
각 근본 원인에 대해 3가지 액션을 생성합니다. 예방(재발 방지), 탐지(조기 경보), 대응(빠른 복구)입니다.
제가 본 실제 사례에서는 DB 연결 모니터링 추가(Detect, DevOps, 1주, 높음), 리뷰 체크리스트 업데이트(Prevent, 팀 리드, 1주, 높음), 롤백 자동화 개선(Respond, Platform, 2주, 중간), 통합 테스트 추가(Prevent, QA, 2주, 중간) 같은 액션 아이템이 도출되었습니다.
액션 아이템을 추적할 때는 담당자를 명시하고, 기한을 설정하고, 우선순위를 결정하고, 정기적으로 리뷰해야 합니다. 이렇게 하지 않으면 액션 아이템이 실행되지 않고, 같은 실패가 반복됩니다.
💡 Plexo의 AI Task Breakdown 기능을 활용하면, "리뷰 체크리스트 업데이트" 같은 액션 아이템을 입력하는 것만으로 AI가 세부 작업·예상 시간·우선순위를 자동 산정합니다. 포스트모템에서 도출된 개선 사항이 구체적인 실행 계획으로 즉시 변환되어, 액션 아이템이 흐지부지되는 것을 방지할 수 있습니다.
Phase 6: 지식 공유 (10분)
공유 방법:
- 팀 위키에 문서화
- 회사 전체 공유 (선택적)
- 유사 사례와 연결
- 교육 자료 제작
포스트모템 템플릿
표준 템플릿
# 포스트모템: [인시던트 제목]
## 요약
- **날짜**: 2024-01-15
- **지속 시간**: 2시간 15분
- **영향**: 1,500명 사용자, $15,000 손실
- **심각도**: P1 (Critical)
## 타임라인
| 시간 | 이벤트 | 영향 | 대응 |
| ----- | ------------- | ---------- | --------- |
| 14:00 | 배포 시작 | - | 자동 |
| 14:15 | 첫 에러 알람 | 5% 사용자 | 알림 발생 |
| 14:30 | 에스컬레이션 | 30% 사용자 | 온콜 호출 |
| 15:00 | 롤백 결정 | 50% 사용자 | 수동 롤백 |
| 15:30 | 서비스 정상화 | 0% | 확인 완료 |
## 근본 원인 분석
### 직접 원인
- 데이터베이스 연결 풀 고갈
### 근본 원인 (5 Whys)
1. Why? 연결이 반환되지 않음
2. Why? 트랜잭션이 종료되지 않음
3. Why? 예외 처리에서 rollback 누락
4. Why? 코드 리뷰에서 놓침
5. Why? 체크리스트 없음
**근본 원인**: 리뷰 프로세스의 체크리스트 부족
## 배운 점
### 잘한 점
- ✅ 빠른 롤백 결정 (30분 내)
- ✅ 명확한 커뮤니케이션
- ✅ 사용자 영향 최소화
### 개선할 점
- ❌ 모니터링 부족
- ❌ 테스트 커버리지
- ❌ 배포 프로세스
## 액션 아이템
| 액션 | 담당자 | 기한 | 상태 |
| ------------------------ | -------- | ---- | ------ |
| DB 연결 모니터링 추가 | @alice | 1/22 | 진행중 |
| 리뷰 체크리스트 업데이트 | @bob | 1/25 | 시작전 |
| 통합 테스트 추가 | @charlie | 1/30 | 계획중 |
## 재발 방지 메트릭
- 목표: 동일 원인 재발 0회
- 측정: DB 연결 풀 사용률 < 70%
- 알람: 50% 초과시 경고
포스트모템 안티패턴
피해야 할 것들
1. 비난 게임 (Blame Game):
- 개인 실수에 집중
- 해결: 시스템과 프로세스 개선에 집중
2. 표면적 분석 (Shallow Analysis):
- 표면적 원인만 다룸
- 해결: 5 Whys로 근본 원인까지
3. 후속 조치 없음 (No Follow-up):
- 액션 아이템 미실행
- 해결: 담당자, 기한, 추적 체계
4. 손가락질 (Finger Pointing):
- 부서간 책임 공방
- 해결: 공동 책임과 협력
5. 문서만 작성 (Documentation Only):
- 문서만 작성하고 끝
- 해결: 학습 세션과 개선 실행
실전 체크리스트
포스트모템 실행 전:
- 참가자 선정 완료
- 데이터 수집 완료
- 회의 시간 및 장소 확정
- 진행자 및 기록자 지정
- 기본 규칙 공유
포스트모템 실행 중:
- 타임라인 작성 완료
- 근본 원인 분석 완료
- 배운 점 정리 완료
- 액션 아이템 도출 완료
포스트모템 실행 후:
- 문서화 완료
- 팀 공유 완료
- 액션 아이템 추적 시작
- 정기적 리뷰 일정 확정
글을 마치며: 제대로 된 포스트모템은 실패를 자산으로 만듭니다
제대로 된 포스트모템은 실패를 자산으로 만듭니다.
핵심 원칙을 다시 정리하면:
- Blameless: 누가 아닌 무엇에 집중
- 근본 원인: 5 Whys로 깊이 있게 분석
- 액션 아이템: 구체적이고 추적 가능하게
- 지식 공유: 팀 전체가 배울 수 있게
이 원칙을 따르면, 같은 실패는 반복되지 않고, 팀은 계속 성장합니다.
오늘부터 제대로 된 포스트모템을 시작해보세요. 작은 변화가 큰 차이를 만듭니다.
AI Task Breakdown으로 개선 작업을 자동 분해하고, 포스트모템을 체계적으로 관리하는 가장 스마트한 방법, Plexo를 통해 우리 팀의 포스트모템을 점검해 보세요.
AI Task Breakdown으로 포스트모템 액션 아이템을 구체적인 실행 계획으로 자동 변환하고, 추적할 수 있는 도구가 있다면, 실패를 자산으로 만드는 것이 훨씬 쉬워집니다.
댓글 없음:
댓글 쓰기