Pre-Mortem Skill — Claude로 6개월 뒤 실패를 미리 부검하는 방법
Pre-Mortem Skill — Claude로 6개월 뒤 실패를 미리 부검하는 방법
의사가 환자를 살리려 부검을 하면 이미 늦어요. Pre-Mortem은 살아있을 때 미리 부검하는 일입니다. 비행기가 추락한 뒤 블랙박스를 열어보는 대신, 이륙 전에 "만약 추락한다면 이유가 뭘까?"를 체계적으로 묻는 기법이죠.
2026-05-26, 덴마크 출신 Claude 파워유저 Ole Lehmann(@itsolelehmann)이 이 Pre-Mortem을 Claude Skill로 구현해 공개했어요. "premortem this: [계획]"이라는 트리거 한 줄로, 5개 하위 에이전트가 병렬로 실패 시나리오를 분석해 HTML 리포트를 뱉어냅니다.
이 글에서는 Pre-Mortem의 심리학적 원리부터 Claude Skill 활용법, 그리고 실제 적용 시나리오까지 정리해 드릴게요.
Pre-Mortem이 뭔가요?
Pre-Mortem은 1989년 Mitchell·Russo·Pennington의 연구에서 시작된 의사결정 기법이에요. 핵심 개념은 "미래 회상(prospective hindsight)" 입니다.
일반적으로 우리는 어떤 계획이 실패할 수 있는 이유를 상상하려 하지만, 이미 성공할 거라는 믿음이 앞서면 객관적으로 보기 어렵죠. 그런데 "이 프로젝트는 이미 실패했다. 이유가 뭘까?"라고 틀을 바꾸면 상황이 달라져요.
Pre-Mortem의 핵심 효과: "이미 실패했다"는 가정으로 시작하면, 실패 원인 식별 능력이 약 30% 향상됩니다 (Mitchell·Russo·Pennington, 1989, Wiley DOI: 10.1002/bdm.3960020103).
Gary Klein은 이 연구를 바탕으로 2007년 하버드 비즈니스 리뷰(HBR)에 5단계 Pre-Mortem 프로세스를 발표해 기업 의사결정 분야에서 주목을 받았어요. 노벨 경제학상 수상자 Daniel Kahneman은 Pre-Mortem을 "자신이 아는 가장 가치 있는 단일 의사결정 기법"이라고 평가하기도 했습니다.
왜 지금 Pre-Mortem을 주목해야 할까요?
대부분의 팀은 계획을 세울 때 "잘 될 것"이라는 낙관 편향에 빠지기 쉬워요. 이를 **계획 오류(planning fallacy)**라고 부르는데, 프로젝트 비용 초과·일정 지연의 주요 원인이기도 합니다.
Pre-Mortem은 이 낙관 편향을 의도적으로 깨는 장치예요. 특히 다음 상황에서 위력을 발휘합니다.
- 되돌리기 어려운 큰 결정을 앞뒀을 때 (채용, 계약, 투자)
- 팀원들이 리더의 눈치를 보느라 우려를 말 못 할 때
- 실패했을 때 피해가 클수록
Gary Klein의 5단계 Pre-Mortem 프로세스
HBR 2007 원문을 기반으로 정리한 실전 5단계예요.
1단계: 계획 공유
팀 전원에게 현재 계획의 전체 내용을 공유해요. 참가자들이 계획을 완전히 이해한 상태에서 시작하는 게 핵심이에요.
2단계: 실패 가정
"이 프로젝트는 X개월 후 완전히 실패했습니다"라고 선언해요. 이 순간이 Pre-Mortem의 핵심입니다. "실패할 수 있다"가 아니라 "실패했다"로 사실처럼 가정하는 거예요.
3단계: 원인 목록 작성
각 참가자가 독립적으로 "왜 실패했는지" 이유 목록을 적어요. 개인 작업이라 집단 사고(groupthink)를 피할 수 있어요.
4단계: 원인 공유 및 분류
돌아가며 한 가지씩 발표하고, 중복 제거 후 분류해요. 반복적으로 등장하는 테마가 핵심 리스크예요.
5단계: 계획 수정
도출된 리스크를 바탕으로 계획을 수정해요. 모든 리스크를 없앨 수는 없지만, 가장 치명적인 것들을 선제적으로 다룰 수 있어요.
Ole Lehmann의 Claude Pre-Mortem Skill
2026-05-26 Ole Lehmann이 Claude Code의 Sub-agent 기능을 활용한 Pre-Mortem Skill을 공개했어요. 기존 수작업 Pre-Mortem을 AI로 자동화한 구현체입니다.
사용법은 아주 간단해요.
premortem this: [계획 내용을 붙여넣기]
이 트리거 한 줄을 치면 5개의 Claude Sub-agent가 동시에 병렬로 실행돼요.
5가지 분석 축
각 Sub-agent가 담당하는 영역이에요.
| 에이전트 | 분석 내용 |
|---|---|
| 1번 | 가장 가능성 높은 실패 원인 |
| 2번 | 가장 위험한 실패 시나리오 |
| 3번 | 가장 큰 숨겨진 가정 |
| 4번 | 수정된 계획 제안 |
| 5번 | 런칭 전 체크리스트 |
Sub-agent 병렬 디스패치는 2026-04-24 Anthropic이 공식 출시한 기능이에요. 5개 에이전트가 동시에 분석하니 수작업 팀 워크숍 대비 시간이 크게 단축되죠.
산출물 구성
Skill 실행 결과로 두 가지 파일이 생성돼요.
- HTML 리포트: 브라우저에서 바로 열어보는 시각화 리포트
- 마크다운 트랜스크립트: 에이전트별 분석 전문
Claude Pre-Mortem Skill 핵심: 5개 Sub-agent가 병렬로 실패 시나리오를 분석해 HTML 리포트와 마크다운 트랜스크립트를 생성합니다. "premortem this:" 트리거 한 줄로 30분짜리 팀 워크숍을 대체할 수 있어요.
실제 활용 예시 — 강의 공동 제작 사례
패스트캠퍼스와 AI 강의를 공동 제작한다고 가정해볼게요. Pre-Mortem Skill을 실행하면 5가지 실패 모드가 도출될 수 있어요.
시장 실패: "AI 기초 강의 시장이 이미 포화됐고, 우리 강의는 10~20번째 비슷한 콘텐츠"
제품 실패: "3개월 만에 강의를 완성하려다 퀄리티가 낮아짐. 수강생이 환불 요청"
파트너 실패: "패스트캠퍼스의 마케팅 채널이 우선 대형 강사에 집중돼 노출이 거의 없었음"
기술 실패: "AI 기술 자체가 너무 빠르게 변해서, 출시 시점에 강의 내용이 구버전이 됨"
법적 실패: "수익 배분 조건이 계약서에 모호하게 기술돼 분쟁 발생"
이 5가지를 미리 인식하면 계획에 다음을 추가할 수 있어요. 차별화 포지셔닝 명확화, 퀄리티 게이트 설정, 마케팅 약속 계약서 명시, 모듈형 콘텐츠 설계, 수익 배분 조항 상세화 등이죠.
어떤 상황에서 쓰면 가장 효과적일까요?
모든 결정에 Pre-Mortem이 필요하진 않아요. 다음 기준으로 우선순위를 정하면 좋아요.
| 적용 상황 | 추천 강도 |
|---|---|
| 신제품/서비스 런칭 | ★★★ |
| 핵심 채용 결정 | ★★★ |
| 대규모 리팩토링 | ★★★ |
| 중요 투자 결정 | ★★★ |
| 마케팅 캠페인 기획 | ★★ |
| 파트너십 계약 | ★★ |
| 일상적 업무 계획 | ★ |
비용 대비 효과가 가장 높은 건 되돌리기 어려운 결정이에요. 한번 잘못 채용하면 수습에 수개월이 걸리고, 서비스 런칭 후 구조를 바꾸는 건 처음부터 설계하는 것보다 훨씬 어렵죠.
Pre-Mortem의 한계도 알아야 해요
솔직하게 단점도 짚어볼게요.
시간 비용: Sub-agent 5개를 병렬 실행하면 Claude Sonnet 기준 입력 $3/백만 토큰, 출력 $15/백만 토큰의 비용이 발생해요. 가볍게 쓰기엔 부담될 수 있어요.
퍼실리테이터 의존성: 팀 Pre-Mortem에서는 "부정적 의견도 환영"하는 심리적 안전감이 없으면 표면적인 결과만 나와요. AI가 이 문화적 요소를 대체할 수는 없어요.
도메인 특수성: AI는 업계 관행이나 특정 파트너사의 내부 사정 같은 맥락을 모를 수 있어요. 분석 결과를 도메인 전문가가 검토하는 게 필요해요.
낙관적 계획 편향 재현: 입력된 계획 자체가 이미 장밋빛 전제로 가득하다면, AI도 그 맥락 안에서 분석할 수밖에 없어요.
Pre-Mortem과 다른 리스크 관리 기법 비교
Pre-Mortem을 다른 기법과 어떻게 구분해서 써야 할지 비교해 볼게요.
SWOT 분석은 현재 상태 스냅샷이에요. 전략 방향 설정에 유용하지만, 미래 시나리오 기반의 실패 예측은 약해요.
리스크 레지스터는 알려진 리스크를 사전에 목록화하는 방식이에요. Pre-Mortem이 먼저 리스크를 발굴하는 도구라면, 리스크 레지스터는 발굴된 것들을 관리하는 도구예요. 둘이 상호보완적이죠.
Red Team 검토는 역할을 정해 반론을 제기하는 방식이에요. Pre-Mortem보다 더 깊은 분석이 가능하지만 준비 비용도 훨씬 높아요.
Pre-Mortem은 결정 직전에 빠르게 맹점을 잡는 용도로 가장 효과적이에요.
오늘 당장 시작하는 방법
Claude Pre-Mortem Skill을 써보고 싶다면 다음 순서로 시작하세요.
Claude Code를 설치하고 Ole Lehmann의 Pre-Mortem Skill을 세팅해요 (공식 X 게시물 참조: https://x.com/itsolelehmann/status/2051390134344716705).
Skill이 준비되면 계획을 한 단락으로 정리해서 붙여넣어요.
premortem this: 다음 달 유료 멤버십 서비스를 런칭할 계획입니다.
월 9만 9천 원, 목표 첫 달 50명 전환, 주요 채널은 Threads와 YouTube...
HTML 리포트가 생성되면, 5가지 실패 모드 중 자신이 가장 피하고 싶은 것 1~2개에 집중해 계획을 수정해 보세요.
팀 Pre-Mortem이라면 Skill 결과를 회의 시작 자료로 활용하면 좋아요. AI가 제시한 시나리오 중 팀원들이 각자 가장 현실적이라고 생각하는 것을 고르게 하면, 논의가 훨씬 구체적으로 흘러가요.
마무리
Pre-Mortem은 "실패를 두려워하지 말자"는 막연한 조언이 아니에요. "이미 실패했다고 가정하고, 이유를 찾아라"는 구체적인 방법론이에요.
37년간 연구로 검증된 기법(Mitchell 외, 1989)이 이제 Claude Skill로 접근하기 쉬워졌어요. 다음 중요한 결정 앞에서 "premortem this:"를 한번 입력해 보세요. 보이지 않던 맹점이 눈에 들어올 거예요.
자주 묻는 질문 (FAQ)
Q: Pre-Mortem을 혼자 해도 효과가 있나요?
네, 있어요. 특히 Claude Skill처럼 AI가 여러 관점을 병렬로 분석해주는 환경에서는 1인이어도 팀 워크숍에 가까운 다각도 분석이 가능해요. 다만 AI가 모르는 특수 맥락(회사 내부 사정, 업계 관행)은 직접 보완해야 해요.
Q: Pre-Mortem은 얼마나 자주 해야 할까요?
모든 결정에 Pre-Mortem을 붙일 필요는 없어요. 되돌리기 어렵거나 실패 비용이 큰 결정, 예를 들면 채용·런칭·계약·대규모 리팩토링에만 적용해도 충분한 효과를 얻을 수 있어요. 일상적인 업무 계획에는 과투자예요.
Q: Claude Skill 없이 Pre-Mortem을 하는 방법이 있나요?
있어요. 종이 한 장에 "이 프로젝트가 6개월 후 실패했다. 이유를 10가지 적어라"라고 쓰고 제한 시간 10분 안에 채우는 것으로 시작할 수 있어요. Gary Klein이 HBR에서 소개한 팀 Pre-Mortem도 별도 도구 없이 회의실에서 진행 가능해요.
Q: Pre-Mortem 결과를 어떻게 활용하나요?
도출된 리스크를 심각도(영향도 × 발생 가능성)로 정렬하고, 상위 3~5개에만 대응책을 마련하는 것이 실용적이에요. 모든 리스크를 없애려 하면 계획이 지나치게 복잡해질 수 있거든요.
Q: AI Pre-Mortem과 전통적인 팀 Pre-Mortem, 어느 쪽이 더 나은가요?
용도가 달라요. AI Pre-Mortem은 빠르고 비용이 낮아요. 혼자 또는 소규모로 신속하게 맹점을 확인하는 데 좋아요. 팀 Pre-Mortem은 심리적 안전감을 기반으로 한 집단 인식이 필요한 조직적 결정에 더 적합해요. 두 방법을 병행하면 이상적이에요. AI로 초안 리스크를 잡고, 팀이 그걸 토대로 깊이 논의하는 방식이죠.
참고 자료
- Gary Klein, "Performing a Project Premortem" (HBR, 2007): https://hbr.org/2007/09/performing-a-project-premortem
- Mitchell·Russo·Pennington 1989 연구 원문: https://doi.org/10.1002/bdm.3960020103
- Ole Lehmann Pre-Mortem Skill 공개 게시물 (2026-05-26): https://x.com/itsolelehmann/status/2051390134344716705
- Anthropic Claude Code Sub-agents 공식 문서: https://code.claude.com/docs/en/sub-agents
- Farnam Street — Daniel Kahneman Pre-Mortem 언급: https://fs.blog/kahneman-better-decisions/