제품이 망할 수도 있다는 걸, 왜 아무도 말 안 했을까

실패를 미리 설계하는 PM의 기술

PM 취준생 HD님이 좋은 주제를 던져주셨습니다. 성공 요인만큼이나 실패 가능성을 미리 찾아내는 것이 성공률을 높이는 길 아닙니다. 이건 단순한 리스크 관리 이야기가 아닙니다. 왜 똑똑한 팀도 실패 신호를 못 보는가, 그리고 그걸 구조적으로 해결할 수 있는가에 대한 이야기입니다.

15초 요약

핵심 한 줄: 제품이 실패하는 이유는 대부분 몰라서가 아니라, 알면서도 말 안 해서다.

2025년, AI 제품의 68%가 시장에 안착하지 못했습니다. 기술이 부족해서가 아닙니다. 모델은 더 똑똑해졌고, 인프라는 더 안정적이었고, 자본도 충분했어요. 그런데 왜? 대부분의 실패는 '되나?'를 검증하지 않아서가 아니라, '쓰이나?'를 안 물어봐서 일어났습니다. 그리고 더 무서운 건, 그걸 팀 안에서 누군가는 느끼고 있었는데 말을 안 했다는 거예요.

알아두면 좋은 용어

프리모템(Pre-mortem): 프로젝트가 실패했다고 가정하고, 왜 실패했는지를 역추적하는 기법. 사후 부검(Post-mortem)의 반대 개념으로, 출시 전에 수행한다.
Tiger / Paper Tiger / Elephant: Shreyas Doshi(전 Stripe PM)가 만든 위협 분류법. Tiger는 진짜 위협, Paper Tiger는 겁만 큰 것, Elephant는 팀에서 아무도 말 안 하는 진짜 문제.
AI 워싱(AI Washing): AI 기술을 사용한다고 포장하지만 실제로는 수작업이거나 기존 기술에 AI 라벨만 붙인 현상. 2025년 가장 큰 스캔들 중 하나.
Use Case Validation: 기술이 작동하는지가 아니라, 사용자가 실제로 그 기술을 쓸 맥락이 있는지를 검증하는 과정.

Y's Insight

오늘의 Y's Insight는 쿠팡·그린랩스·무신사에서 10년간 PM으로 일하며, 수백 개의 제품을 출시하고 그중 절반 이상은 목표 달성에 실패한 경험을 가진 멘토 율(Yul)님이 작성했습니다.

'성공 전략 먼저'가 함정인 이유

PM이 가장 많이 받는 질문 중 하나가 **이 제품의 성공 요인이 뭐예요?**입니다. 당연히 중요한 질문이에요. 그런데 이 질문만 하다 보면, 자연스럽게 될 수 있는 이유만 모으게 됩니다.

코칭하다 보면 기획서를 검토하면서 느끼는 게 있어요. 시장 분석도 했고, 경쟁사도 봤고, 전략도 나름 탄탄해 보이는데, 이게 안 되는 시나리오에 대한 이야기가 거의 없는 거예요. 리스크 항목이 아예 없거나, 있어도 경쟁사 진입이나 기술적 난이도 같은 교과서적인 항목만 적혀 있습니다.

2025년 통계가 이걸 증명합니다. Simplico의 분석에 따르면 AI 제품의 68%가 시장 안착에 실패했고, 신제품의 80~95%가 출시 1년 내에 사라집니다. 그런데 실패 원인의 대부분은 기술 문제가 아니었어요.

❌ 기술이 부족해서 실패했다

✅ 기술은 됐는데, 사용자의 일상에 안 붙어서 실패했다

AI 모델은 더 강력해졌고, 클라우드 인프라는 더 안정적이었고, 오픈소스 생태계는 더 빠르게 성장했어요. 그런데 역사적으로 높은 실패율을 기록했습니다. 핵심은 실행 실패입니다. 워크플로우에 녹아들지 못하는 혁신은 데모일 뿐이에요.

2025년, 실패가 가르쳐준 3가지

추상적인 이야기 대신, 실제 사례로 풀어볼게요.

사례 1. Humane AI Pin — "스마트폰을 대체하겠다"는 가정을 검증 안 한 대가

$700짜리 AI 디바이스. 화면 없이 AI만으로 소통하는 미래를 팔았습니다. 실제로는? 느리고, 뜨겁고, 기본적인 것도 제대로 안 됐어요. 출시 후 5개월, 이탈율 95%. 2025년 2월 HP에 $116M에 매각되면서 기기 자체가 작동 중단(bricked)됐습니다.

PM 관점에서 핵심 실패 지점

사람들이 스마트폰 대신 이걸 쓸까?라는 가장 기본적인 질문을 검증하지 않았어요. 기술 데모는 화려했지만, Use Case Validation이 없었습니다. 스마트폰은 단순히 정보를 보여주는 기기가 아니라 습관이자 생태계입니다. 그걸 $700짜리 핀 하나로 대체하겠다는 가정, 이건 Tiger가 아니라 Elephant였어요. 팀 안에서 누군가는 느꼈을 텐데, 아마 말하기 어려웠을 겁니다.

사례 2. Builder.ai — 우리 핵심 역량이 진짜인가?를 안 물었을 때

$1.5B(약 2조 원) 기업가치를 인정받은 AI 앱 개발 플랫폼. Natasha라는 AI가 앱을 자동으로 만들어준다고 했습니다. 실제로는? 700명의 인도 개발자가 수작업으로 만들고 있었어요. 개발자들은 인도식 영어 표현을 쓰지 말라는 지시를 받았고, 영국 업무 시간에만 응답하도록 강요받았습니다. 2024년 매출을 $220M이라고 보고했지만 실제는 $50M. 340%를 부풀렸어요. 2025년 5월 파산.

PM 관점에서 핵심 실패 지점

이건 사기의 문제이기도 하지만, 제품 관점에서 보면 **우리 핵심 역량이 실제로 존재하는가?**라는 가장 근본적인 질문을 안 한 겁니다. 초기에 수작업으로 시작하는 건 스타트업에서 흔한 일이에요. 문제는 그걸 AI라고 포장하면서 검증 자체를 건너뛴 거예요. 2019년에 이미 월스트리트저널이 지적했는데도, 6년간 아무도 내부에서 이걸 문제 삼지 않았습니다.

사례 3. Apple Vision Pro — 기술이 완성돼도 일상에 안 붙으면 끝

애플이 만들었습니다. 기술력은 의심할 여지가 없어요. 디스플레이, 공간 컴퓨팅, 눈 추적 — 모두 업계 최고 수준이었습니다. 그런데 2024년 39만 대 판매 후, 2025년 생산 중단. 마케팅 예산 95% 삭감. 홀리데이 시즌에 겨우 4.5만 대 출하 예상.

PM 관점에서 핵심 실패 지점

$3,499라는 가격도 문제였지만, 더 근본적인 건 킬러 유스케이스의 부재였어요. 이걸로 뭘 하지?에 대한 답이 영화 보기와 업무용 다중 모니터밖에 없었습니다. 기술적으로 가능하냐가 아니라, 매일 쓸 이유가 있냐가 제품의 생사를 가릅니다.

물에 빠진 사람이 자기 위치를 모르는 이유

세 사례에서 공통점이 보이시나요? Humane의 팀도, Builder.ai의 투자자도, 심지어 애플도 — 실패 신호가 있었는데 충분히 대응하지 못했어요. 왜 그럴까요?

1. 확증 편향 — 될 거라는 근거만 모은다

기획서를 쓸 때, 우리는 자연스럽게 이게 왜 되는지를 설명하는 데 집중합니다. 시장 규모, 성장률, 사용자 니즈. 다 될 수 있는 이유예요. 문제는 이 과정에서 안 될 수 있는 이유를 의식적으로 무시하게 된다는 겁니다.

2. 생존자 편향 — 성공 사례만 분석한다

벤치마킹 할 때 우리가 보는 건 성공한 회사들이에요. 토스가 어떻게 했는지, 쿠팡이 어떻게 했는지. 그런데 같은 전략을 쓰고 망한 수백 개의 회사는 분석하지 않습니다. 성공 사례에서 전략을 배우면 '이렇게 하면 된다'는 결론이 나오지만, 실패 사례까지 보면 **이렇게 해도 안 될 수 있다. 그 차이는 뭐지?**라는 더 좋은 질문이 나옵니다.

3. 그룹싱크 — 이거 안 되지 않을까?를 말하기 어려운 구조

이게 핵심이에요. 팀 미팅에서 '저는 이 프로젝트가 실패할 것 같아요'라고 말하는 게 쉬운가요? 대부분의 조직에서 이건 부정적인 사람, 팀 분위기를 깨는 사람으로 낙인찍힐 수 있는 발언입니다.

코칭하면서 자주 듣는 말이 있어요. "사실 저는 그때 이게 안 될 거라고 느꼈어요. 그런데 모두가 흥분해 있으니까 말을 못 했어요." 미팅을 해도 발견 못하는 이유는 능력의 문제가 아니라 구조의 문제입니다. 부정적 신호를 말할 수 있는 구조가 없으면, 아무리 똑똑한 팀이어도 블라인드 스팟은 그대로 남아요.

그래서 뭘 해야 하나 Pre-mortem

여기서 소개할 방법이 프리모템(Pre-mortem)입니다. 심리학자 Gary Klein이 고안하고, Shreyas Doshi(전 Stripe PM, 그 전에 Google·Twitter·Yahoo PM)가 실무용으로 발전시킨 기법이에요.

핵심 아이디어는 단순합니다.

"지금부터 6개월 후, 이 프로젝트는 완전히 망했습니다. 왜 망했을까요?"

일반적인 리스크 리뷰와 뭐가 다르냐고요? 결정적인 차이가 있어요.

❌ 일반 리스크 리뷰

뭐가 잘못될 수 있을까요?

→ 낙관 편향이 작동해서 '별로 없을 것 같은데요'가 나옴

✅ Pre-mortem

이미 망했습니다. 왜 망했을까요?

→ 실패가 확정된 전제에서 시작하니, 평소 말 못 했던 우려가 나옴

Shreyas Doshi는 여기에 위협을 3가지로 분류하는 프레임워크를 더했습니다.

Tiger (호랑이): 진짜 위협. 지금 안 잡으면 물린다. → 즉시 액션 필요
Paper Tiger (종이호랑이): 걱정은 되지만 실제로는 큰 문제 아닌 것. → 에너지 낭비를 줄여준다
Elephant (코끼리): 방 안의 코끼리. 모두 느끼고 있지만 아무도 말 안 하는 것. → 이게 제일 위험하다

1시간 워크숍으로 해보기

Shreyas Doshi가 제안하는 Pre-mortem 미팅 구조예요. 출시 1~3개월 전에 하면 가장 효과적입니다.

1단계. 킥오프 (10분)

이 프로젝트가 6개월 후 완전히 실패했다고 가정합시다. 지금부터 왜 실패했는지를 적어주세요.

2단계. 혼자 쓰기 (10분)

각자 실패 이유를 최소 2개 이상 적습니다. 이때 중요한 건 말하지 않고 쓰는 것이에요. 말로 하면 첫 번째 발언자의 프레임에 끌려가거든요. 각 이유를 Tiger, Paper Tiger, Elephant로 분류합니다.

3단계. 공유 & 투표 (30분)

전체가 돌아가며 공유하고, 가장 위험한 항목에 투표합니다. 여기서 Elephant가 나오면 성공이에요. "사실 저도 그게 걱정이었는데..."가 터져 나오는 순간이 이 미팅의 가치입니다.

4단계. 액션 플랜 (10분)

Top 3 위협에 대해 "누가, 언제까지, 뭘 할 건지"를 정합니다.

이 구조가 효과적인 이유는, 부정적 의견을 말하는 걸 격려하는 구조이기 때문이에요. 평소에는 '이거 안 될 것 같은데'가 부정적 발언이지만, Pre-mortem에서는 '이미 망한 이유를 찾아달라'는 요청이니까 오히려 날카로운 지적이 환영받습니다.

혼자서 15분 해보기

팀 전체 워크숍이 부담스러우면, 혼자서 15분만 해보세요.

지금 진행 중인 프로젝트 하나를 고르세요.
이 문장으로 시작하세요.

→ "6개월 후, 이 프로젝트는 완전히 실패했다. 사용자도 안 쓰고, 팀도 지쳤고, 성과도 없다."

실패 이유를 5개 이상 적으세요.

→ 적을 때 규칙이 하나 있어요. 그럴 리 없어를 금지하는 겁니다. 아무리 비현실적으로 느껴져도 일단 적으세요.

각각을 분류하세요.

Tiger: 지금 안 잡으면 진짜 위험한 것
Paper Tiger: 걱정은 되지만 실제론 별거 아닌 것
Elephant: 느끼고 있지만 팀에서 아직 말 안 한 것

Elephant가 하나라도 있다면, 그게 다음 미팅에서 꺼내야 할 대화입니다.

근데 말이죠

Pre-mortem이 만능은 아니에요. 솔직히 말하면, 이 방법의 가장 큰 리스크는 실패할 이유를 찾자가 안 할 이유를 찾자로 변질되는 것입니다. 모든 프로젝트에는 실패할 이유가 있어요. 그걸 다 나열하면 아무것도 못 합니다.

그리고 Elephant를 꺼내는 것도 결국 심리적 안전감이 있는 팀에서만 작동해요. 말해도 괜찮다는 신뢰가 없으면, Pre-mortem 미팅을 해도 다들 Tiger만 적고 Elephant는 여전히 삼킵니다.

그래도 이건 분명합니다. 실패를 두려워하는 게 아니라, 실패의 모양을 미리 그려보는 것. 모든 리스크를 막을 순 없지만, '이건 알고 갔다'와 '몰랐다'의 차이는 큽니다. 결과가 같더라도, 그 차이가 다음 제품에서의 판단력을 바꿔요. 실패를 예방하는 최고의 방법은, 실패를 말할 수 있는 구조를 만드는 것입니다.