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

# [[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.