2nd/10_Wiki/Topics/Thinking & Reasoning/Hypothesis-Driven Design (HDD).md

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

id	title	category	status	verification_status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	created_at	updated_at	review_reason	merge_history	tags	raw_sources	applied_in	github_commit
hypothesis-driven-design-(hdd)	Hypothesis-Driven Design (HDD)	10_Wiki/Topics	draft	conceptual		가설 지시형 디자인 가설 기반 설계		B	0.85	2026-05-24	2026-05-24			research hypothesis-driven thinking product management design methodology	NotebookLM Synthesis	Thoughtworks Legacy Modernization McKinsey Profitability Diagnostic (SnackCo Case) B2B SaaS Churn Reduction Project Retail Chain Margin Analysis

Hypothesis-Driven Design (HDD)

🎯 한 줄 통찰 (One-line insight)

가설 지시형 디자인(HDD)은 검증되지 않은 가정을 과학적 가설로 전환하고, 선제적 리서치를 통해 개발 리스크를 최소화하며 사용자 중심의 솔루션을 구축하는 정밀 설계 프레임워크다 [1-3].

🧠 핵심 개념 (Core concepts)

1. 가정 식별 (Assumption Identification): 문제와 관련된 팀의 내재된 믿음을 명시적으로 추출하고 임팩트와 리스크에 따라 우선순위를 설정함 [4-6].
2. 검증 가능한 가설 (Testable Hypotheses): "만약 [특정 변화]를 도입하면, [측정 가능한 결과]가 발생할 것이다, 왜냐하면 [논리적 근거] 때문이다" 형식의 실행 가능 문법을 사용함 [3, 7-9].
3. 증거 기반 검증 (Evidence-Based Validation): 정성/정량적 리서치(인터뷰, A/B 테스트, 프로토타입)를 통해 가설의 참/거짓 여부를 데이터로 판별함 [10-12].
4. 점진적 설계 및 반복 (Incremental Design & Iteration): 검증된 가설만을 바탕으로 사용자 스토리와 기능을 설계하며, 지속적인 피드백 루프를 통해 제품을 개선함 [13-15].

🧩 추출된 패턴 (Extracted patterns)

• If-Then-Because 구문: 가설의 구성 요소를 명확히 하고 팀 내 공유 언어를 생성하는 표준화된 구조적 패턴 [3, 7, 8].
• 성공 기준 사전 정의 (Pre-defined Success Thresholds): 리서치 실행 전 성공, 부분적 성공, 실패를 판단할 구체적 수치(예: 사용률 40% 이상)를 설정하여 사후 확증 편향을 방지함 [16-18].
• 가설 트리 (Hypothesis Tree): 상위 가설을 MECE(상호 배제 및 전체 포괄) 원칙에 따라 하위 가설로 분해하여 체계적으로 테스트하는 구조 [19-21].
• 실패의 자산화 (Valuing Failed Experiments): 실패한 가설 검증을 매몰 비용이 아닌 '잘못된 경로를 조기에 차단한 지식 습득'으로 정의함 [22-24].

📖 세부 내용 (Details)

HDD는 제품 개발을 단순한 기능 구현(Build)에서 과학적 실험(Experiment)의 과정으로 재정의한다 [25].

• 리스크 감소 전략: 제품 결정이 검증되지 않은 직관이나 HiPPO(가장 높은 급여를 받는 사람의 의견)에 의존할 때 발생하는 리스크를 줄이기 위해, 모든 아이디어를 테스트 가능한 예측으로 변환한다 [1, 26].
• 가설의 4대 구성 요소:
  • 구체적 변화: 어떤 기능을 추가하거나 수정할 것인가? [27, 28]
  • 예상 결과: 어떤 사용자 행동 변화나 지표 상승을 기대하는가? [27, 28]
  • 대상 세그먼트: 어떤 특정 사용자 그룹이 영향을 받는가? [27, 28]
  • 성공 기준: 무엇을 성공으로 정의하며, 언제까지 측정할 것인가? [27, 29]
• 검증 단계 (Hierarchy of Testing):
  • 1단계 (Low investment): 사용자 인터뷰, 설문, 랜딩 페이지 테스트를 통해 방향성을 확인 [12, 30].
  • 2단계 (Medium effort): 클릭 가능한 프로토타입, 가짜 문(fake door) 테스트를 통해 실제 상호작용을 관찰 [12, 31, 32].
  • 3단계 (High investment): MVP 개발, 베타 프로그램, A/B 테스트를 통해 프로덕션 환경에서 인과관계를 증명 [12, 33, 34].
• 문화적 전환: "우리는 이것을 구축해야 한다"는 태도에서 "우리는 만약 이것을 구축하면 X가 일어날 것이라고 믿으며, 이를 위해 Y를 테스트할 것이다"라는 가설 지향적 태도로 조직 문화를 변화시킨다 [35].

⚖️ 모순 및 업데이트 (Contradictions & updates)

• 데이터 중심 vs 가설 중심: 단순히 분석 도구(Analytics)로 과거 지표만 보는 것(데이터 중심 illusion)은 '왜' 그런 일이 일어났는지 설명하지 못함. HDD는 가설을 통해 상관관계와 인과관계를 구분하여 '왜'에 집중함 [36, 37].
• 프레임워크의 한계: 초기에 정보가 극도로 부족한 모호한 상황에서는 가설 수립보다 탐색적 분석(Exploratory Research)이나 문제 맵 작성(Issue Mapping)이 선행되어야 할 수 있음 [38, 39].

🛠️ 적용 사례 (Applied in summary)

• Thoughtworks DDHD 프레임워크: 관리가 소홀했던 레거시 시스템 현대화 과정에서 가설 기반 실험을 통해 도메인 지식을 재구축하고 리스크를 관리함 [15, 40, 41].
• McKinsey 수익성 진단 사례 (SnackCo): 가설 기반 접근법을 사용하여 '가격'과 '거래량' 중 거래량 감소에 집중하고, 다시 '가변비용'에 집중하여 공급망 효율화 가설을 검증함 [42-47].
• B2B SaaS 이탈률 개선: "온보딩 교육 부족이 이탈을 유발한다"는 가설을 세우고 인터랙티브 툴팁 도입을 통해 지표 변화를 측정함 [48-50].
• 항공사 운영비 절감 프로젝트: 함대 최적화 및 조달 프로세스 개선 가설을 수립하고 각각의 임팩트를 정량적으로 분석함 [51].

✅ 검증 상태 및 신뢰도

• 상태: draft
• 검증 단계: conceptual (실제 적용 사례가 소스 내 구체적 시나리오로 다수 발견됨)
• 출처 신뢰도: B (Thoughtworks, McKinsey 관련 전문 분석 및 방법론 가이드 기반)
• 중복 검사 결과: 신규 생성 (New discovery)

📝 변경 이력 (Change history)

• 2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine.