프리모템(Pre-Mortem)

프리모템은 제품 개발에서 가장 저렴한 보험이다

실패한 모든 제품 출시는 비슷한 순간을 거칩니다. 보통 출시 후 2주쯤 지나 누군가가 말하죠. "그거 문제 될 줄 알았어요." 프리모템은 그 지식을 비싼 교훈이 되기 전에 끌어올리기 위해 존재합니다.

심리학자 Gary Klein이 만든 프리모템은 전통적인 포스트모템(post-mortem)을 뒤집습니다. 실패 후에 무엇이 잘못됐는지를 분석하는 대신, 이렇게 묻습니다. 이 프로젝트는 이미 실패했다. 무엇이 그 실패를 만들었는가? Harvard Business Review에 소개된 연구에 따르면, 미래의 일이 이미 일어났다고 상상하는 prospective hindsight는 미래 결과의 원인을 찾아내는 능력을 30% 높여줍니다.

문제

제품 팀은 구조적으로 낙관 편향(optimism bias)을 갖습니다. Kahneman과 Tversky가 정리한 planning fallacy에 따르면, 사람들은 평균적으로 완료 시간을 25-50% 정도 과소추정합니다. 비슷한 프로젝트 경험이 있어도 그렇습니다. 이 낙관은 일정뿐 아니라 리스크 평가에도 퍼집니다. 팀은 기술 복잡도, 시장 저항, 조직 내 마찰을 실제보다 낮게 봅니다.

제품 팀의 사회적 역학은 이 문제를 더 키웁니다. 계획 회의에서 우려를 제기하는 일은 비관적으로 보이기 쉽습니다. 누구도 분위기에 찬물을 끼얹는 사람이 되고 싶어 하지 않죠. 그래서 리스크는 말해지지 않고, 가정은 검증되지 않은 채로 남고, 팀은 여러 사람이 이미 예감했던 실패를 향해 걸어갑니다.

Standish Group의 CHAOS Report에 따르면 소프트웨어 프로젝트 중 제시간, 예산 내, 요구사항 충족까지 포함해 성공으로 간주되는 비율은 31%에 불과합니다. 나머지는 일정이 밀리거나 중단됩니다.

이 프롬프트의 작동 방식

프리모템(Pre-Mortem) 프롬프트는 우려를 제기하는 데 붙는 사회적 낙인을 줄이고, 구조화된 리스크 식별 워크숍을 만듭니다. 시작은 생생한 실패 시나리오입니다. 프로젝트는 이미 출시됐고, 크게 실패했습니다. 그 다음 실패 카테고리를 체계적으로 훑습니다.

이 프롬프트는 기술 리스크, 시장 리스크, 조직 리스크, 타이밍 리스크를 차례로 점검합니다. 각 카테고리마다 프로젝트 맥락에 맞는 구체적 실패 시나리오를 생성하고, 각 시나리오의 발생 가능성과 영향도를 평가하게 해 우선순위가 매겨진 리스크 레지스터(risk register)를 만듭니다.

마지막으로, 가장 중요한 리스크에 대한 완화 전략(mitigation strategy)과 실행 중 추적할 조기 경고 지표(early warning indicator)까지 도출합니다.

언제 사용할까

• 2주 이상 걸리는 프로젝트를 시작하기 전 킥오프(kickoff) 단계에서
• 대형 출시 전 되돌리기 비용이 크고 stakes가 높을 때
• 새로운 scope change 이후 팀이 아직 소화하지 못한 리스크가 추가됐을 때
• 팀이 과도하게 자신감에 차 있을 때 가정을 스트레스 테스트(stress-test)할 구조가 필요할 때

흔한 함정

형식적으로만 진행하기. 체크박스용 프리모템은 아무 쓸모가 없습니다. 팀이 실패 시나리오를 진지하게 다뤄야 합니다.

기술 리스크만 보는 것. 가장 큰 제품 실패는 대개 기술 때문이 아닙니다. 시장 적합성(market fit), 조직 정렬(alignment), 경쟁 타이밍, 규제 이슈가 더 흔한 킬러입니다.

결과물을 행동으로 옮기지 않기. 아무도 다시 보지 않는 문서 속 리스크 레지스터는 없는 것보다 더 나쁩니다. 상위 3개 리스크에는 반드시 owner와 모니터링 주기를 붙이세요.

참고 자료

• Performing a Project Pre-Mortem - Harvard Business Review
• CHAOS Report - Standish Group
• The Planning Fallacy - Daniel Kahneman