잘 굴러가던 서비스가 일요일 저녁에 펑 터졌습니다. 개발자, 인프라팀, PM이 모두 불려 나와 새벽 내내 쌍코피를 흘리며 간신히 불을 껐습니다. 이제 월요일 아침, 대표이사와 전사 직원들이 묻습니다. "도대체 왜 터진 건가요?" 이때 반드시 열려야 하는 중요한 회의가 바로 '사후 분석(Post-Mortem, 포스트모템)'입니다. 하지만 자칫 잘못 진행하면 "백엔드팀 김수석님이 쿼리를 잘못 짜서요" 같은 살벌한 인민재판, 마녀사냥으로 변질되어 조직 분위기가 파탄 납니다. 비난이 아닌 성장을 위한, 오직 재발 방지에 초점을 맞춘 건설적인 포스트모템 회의 소집 기술입니다.
면책특권 부여! 블레임리스 원칙의 건설적 회의 브리프
방어 기제를 허물어 투명한 원인 분석을 유도하는 화법.
안녕하세요 유관부서 당직자 여러분! 주말 간 갑작스럽게 발생했던 메인 DB 로그인 타임아웃 장애 대응하시느라 정말 고생 많으셨습니다. 덕분에 무사히 조기 진화되었습니다. 해당 장애 건에 대해 기억이 생생할 때 사후 분석(Post-mortem) 랩업 회의를 짧고 굵게 가지고자 합니다. - 목적: 이번 장애 현상의 타임라인 복기 및 동일한 '모니터링 알림 부재' 이슈가 재발하지 않기 위한 기술적 방어책(Action Item) 논의 - 필수 방향성: 📌 특정 담당자의 책임이나 비난을 따지는 자리가 절대 아닙니다. (Blameless 원칙) 우리 시스템이 왜 예외를 방어하지 못했는지만 건조하게 팩트 베이스로 다룹니다! - 참석 대상: 당시 대응하셨던 백엔드팀 파트장, 인프라팀, 로그인 관련 PM 무거운 자리 아니니, 다음 배포 때 편하게 발뻗고 자기 위한 예방주사 맞는다 생각하시고 가벼운 마음으로 들어와 주세요! 내일 오후 2시 1차로 캘린더 인바이트 보냈습니다.
📋💡 실전 활용 팁
- 장애 사후 분석(포스트모템) 회의는 장애가 복구된 시점으로부터 기절한 담당자의 휴식이 끝나는 즉시, 무조건 며칠 내에 진행해야 실무 로그나 기억이 유실되지 않습니다.
⚠️ 주의사항
[ "회장님, 이사님, 타 부서장 등 경영진을 메일 참조(CC)에 잔뜩 넣어 판을 키우고 압박 분위기를 조성하면, 개발팀은 자기방어를 위해 기술적인 핑계와 알 수 없는 외계어를 남발하며 헛시간만 쓰게 됩니다. 실무진만으로 컴팩트하게 구성하세요." ]
성공적인 IT 기업의 포스트모템은 전 세계적인 대원칙 '블레임리스(Blameless, 비난 없는 문화)'를 근간으로 합니다. 회의 소집자(보통 리드급이나 PM)는 소집 목적 자체가 특정 담당자를 색출해 징계하려는 것이 아님을 슬랙이나 메일 머리말에 강력하게 천명해야 합니다. 사람의 실수가 발생했다면 그 사람을 비난할 것이 아니라, '그 실수를 시스템과 코드가 왜 사전에 막아주지 못했는가'를 파고들어야 합니다. 각 파트별 팩트 기반 타임라인을 점검하고, 무조건 향후 개선 액션 아이템(Action Item)만을 도출하겠다는 목적을 밝혀야 직원들이 방어 기제를 풀고 당당하게 회의실로 모여듭니다.