---
id: problem-validation
title: "Problem Validation"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Problem-Solution Fit", "Desirability Validation"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Dropbox", "Airbnb", "Zappos", "Buffer", "Glovo", "Money", "Taxiapp", "Superstore"]
github_commit: ""
---

# [[Problem Validation]]

## 🎯 한 줄 통찰 (One-line insight)
해결하려는 문제가 실제로 존재하며, 사용자가 해결책을 찾기 위해 적극적으로 노력할 만큼 충분히 고통스러운지 데이터로 입증하는 과정 [1, 2].

## 🧠 핵심 개념 (Core concepts)
- **가망 고객의 갈망 (Desirability):** 사용자가 제품을 필요로 하거나 원하는지, 그리고 해당 문제가 사용자에게 높은 우선순위인지 확인하는 것 [3, 4].
- **고통의 강도 및 구체성 (Pain Intensity):** 사용자가 유도되지 않은 상태에서도 해당 문제를 구체적이고 감정적으로 묘사할 수 있는지 여부 [1].
- **Jobs-to-be-Done (JTBD):** 사용자가 단순히 기능을 요청하는 것을 넘어, 근본적으로 달성하고자 하는 목적(기능적, 감정적, 사회적 목표)을 파악하는 것 [5, 6].
- **과거 행동 기반 검증 (Historical Behavior):** 미래의 사용 의향이 아닌, 과거에 해당 문제를 해결하기 위해 어떤 노력을 했는지(시간/비용 투자)를 기준으로 가설을 검증함 [7, 8].

## 🧩 추출된 패턴 (Extracted patterns)
- **The Mom Test 패턴:** 사람들은 예의를 지키기 위해 거짓말을 하므로, 미래의 의향 대신 과거의 구체적인 행동에 대해 질문하여 편향을 제거하는 인터뷰 기법 [8-10].
- **5 Whys 휴리스틱:** 문제의 표면적 현상이 아닌 근본 원인(Root Cause)에 도달하기 위해 연속적으로 '왜'라고 질문하여 문제를 정의함 [11, 12].
- **문제-해결 정합성 (Problem-Solution Fit):** 타겟 고객을 식별하고 그들의 미충족된 요구를 발견하여 해결책을 만들기 전 단계의 마일스톤 [13, 14].

## 📖 세부 내용 (Details)
- **검증의 위계 (Hierarchy of Validation):** 문제 검증은 솔루션 검증 및 비즈니스 모델 검증보다 선행되어야 하는 가장 기초적인 레이어임 [1, 15]. 문제가 검증되지 않은 상태에서의 비즈니스 모델 검증은 무의미함 [15].
- **검증의 신호 (Key Signals):**
    - 사용자가 문제 해결을 위해 현재 사용 중인 임시 방편(Workarounds)이 존재할 때 [10, 16].
    - 타겟 인터뷰 집단 내에서 고통 지점(Pain Point)의 높은 상관관계가 발견될 때 [17].
    - 온라인 포럼, 검색량, 경쟁사 대안 등에 대한 유기적인 논의가 활발할 때 [17].
- **방법론적 가이드라인:**
    - 최소 50~100명의 잠재 고객과 대화하여 고통 지점을 확인하는 것이 권장됨 [18, 19].
    - 가설은 "최소 X%의 Y가 Z할 것이다"와 같은 위조 가능성(Falsifiable)이 있는 문장으로 작성해야 함 [20, 21].
    - 검증 실패 기준(Kill Criteria)을 미리 설정하여 확증 편향(Confirmation Bias)을 방지함 [8, 10].
- **위험 요소:** '검증 연극(Validation Theater)'을 경계해야 함. 친구나 가족에게만 질문하거나, 가설을 확인하기 위해 유도 질문을 하는 행위는 실제 검증이 아님 [22, 23].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **인터뷰 표본 수:** 일부 소스는 10~20번의 대화로 시작할 것을 권장하지만 [24], 다른 소스에서는 성공적인 스타트업의 68%가 출시 전 광범위한 조사를 수행했으며 최소 50~100명의 잠재 고객 인터뷰를 수행했음을 강조함 [7, 18, 19].
- **AI의 영향:** 2026년 기준, AI 도구를 사용하면 전통적으로 3~6개월 걸리던 시장 분석과 데이터 기반 검증 통찰을 120초 이내에 확보할 수 있게 됨 [18, 25].

## 🛠️ 적용 사례 (Applied in summary)
- **Dropbox:** 실제 코드를 작성하기 전, 파일 동기화라는 문제 해결에 대한 시장의 수요가 있는지 데모 비디오 하나만으로 75,000명의 대기 명단을 확보하여 문제를 검증함 [26-28].
- **Airbnb:** 디자인 컨퍼런스 기간 동안 자신의 아파트에 에어매트리스를 배치하여 '낯선 사람의 집에서 숙박하려는 수요'라는 근본적인 문제 가설을 검증함 [29-31].
- **Zappos:** 신발 재고를 확보하기 전, 동네 신발 가게의 사진을 찍어 웹사이트에 올리는 '위저드 오브 오즈(Wizard of Oz)' 방식으로 사람들이 온라인으로 신발을 구매하고자 하는지 문제를 테스트함 [29, 32-34].
- **Glovo/Taxiapp (COVID-19 사례):** 팬데믹이라는 외부 충격 상황에서 이동 제한으로 발생한 새로운 문제(생필품 배송 필요성)를 파악하기 위해 기존 리소스를 재배치하여 시장의 반응을 즉각적으로 확인하며 피벗함 [35-38].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine.