Antigravity Agent
2a2a1ad3b1
- 10_Wiki/Topics/Thinking & Reasoning/ 다수 신규 토픽 추가 (3C, 4P, 5 Whys, 7S, 80/20 법칙, 인과관계, 디자인 씽킹 변형 등) - Premium/Logic Tree/ 11개 파일 → Thinking & Reasoning 으로 흡수 - Premium/Thinking & Reasoning/ 동기화 갱신 - memory/long_term.json + .DS_Store 자동 갱신 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
92 lines
8.3 KiB
Markdown
92 lines
8.3 KiB
Markdown
---
|
|
id: hypothesis-driven-design
|
|
title: "Hypothesis-Driven Design"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: ["HDD", "가설 중심 설계"]
|
|
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 development"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: ["Office coffee shop mobile ordering system", "B2B SaaS onboarding checklist", "Legacy system modernization (Thoughtworks)"]
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[Hypothesis-Driven Design]]
|
|
|
|
## 🎯 한 줄 통찰 (One-line insight)
|
|
**Hypothesis-Driven Design(HDD)**은 제품 개발을 "구축 후 출시(build and launch)" 모델에서 **"학습 후 반복(learn and iterate)"** 주기로 전환하여, 검증되지 않은 가설로 인한 리소스를 최소화하고 사용자 가치를 극대화하는 과학적 방법론이다 [1, 2].
|
|
|
|
## 🧠 핵심 개념 (Core concepts)
|
|
- **가설로서의 가정 (Assumptions as Guesses)**: 초기 결정을 사실이 아닌 테스트해야 할 가정한 상태로 취급하며, 이를 광범위하게 정의하여 예상치 못한 통찰을 수용한다 [3, 4].
|
|
- **검증 가능한 가설 (Testable Hypotheses)**: "만약 [변경 사항]을 도입하면, [측정 가능한 결과]가 발생할 것인데, 이는 [기저 논리] 때문이다"라는 표준화된 구문을 통해 예측을 구체화한다 [2, 5].
|
|
- **증거 기반 설계 (Evidence-Based Design)**: 연구 결과를 통해 "참", "타당함", "거짓"으로 판명된 가설만을 사용자 스토리와 설계의 기초로 삼는다 [6, 7].
|
|
- **위험 기반 우선순위화 (Risk-Based Prioritization)**: 신뢰도가 가장 낮거나 틀렸을 때의 위험이 가장 큰 가정을 먼저 테스트하여 개발 투자의 불확실성을 제거한다 [5, 8].
|
|
|
|
## 🧩 추출된 패턴 (Extracted patterns)
|
|
- **HDD 4단계 루프**: **가정 정의(Assumptions) -> 가설 변환(Hypotheses) -> 연구 수행(Research) -> 설계 및 구축(Design & Build)**으로 이어지는 반복적인 구조를 가진다 [1, 3].
|
|
- **실패 지표 설정 (Fail-Fast Mechanism)**: 실험 시작 전 성공과 실패의 임계값(Thresholds)을 미리 정의하여 동기 부여된 추론(motivated reasoning)을 방지한다 [9, 10].
|
|
- **연구 계층 구조 (Testing Hierarchy)**: directional signal을 위한 인터뷰(Level 1)부터 통계적 확신을 위한 A/B 테스트 및 베타 프로그램(Level 3)까지 투자 수준에 따른 검증 패턴을 활용한다 [11, 12].
|
|
|
|
## 📖 세부 내용 (Details)
|
|
- **단계별 프로세스 상세**:
|
|
1. **가정(Assumptions)**: 이해관계자 세션을 통해 다양한 관점을 수집하고, 사용자 행동이나 관찰된 문제에 기반한 가정을 문서화한다 [4, 5].
|
|
2. **가설(Hypotheses)**: 식별된 가정을 테스트 가능하고 실행 가능한 형태의 테이블로 구조화한다 [5, 13].
|
|
3. **연구(Research)**: 가설의 성격에 따라 정성적(인터뷰, 사용성 테스트) 및 정량적(설문, 분석 검토) 방법을 선택하여 검증한다 [13, 14].
|
|
4. **설계 및 구축(Design & Build)**: 확인된 가설을 바탕으로 프로토타입을 제작하고, 전체 개발로 넘어가기 전 다시 사용자의 피드백을 수집한다 [6, 7].
|
|
- **가설의 구성 요소**: 좋은 가설은 **구체적인 변경 사항, 예측된 결과, 영향을 받는 사용자 세그먼트, 그리고 사전에 정의된 성공 기준**의 4가지 요소를 포함해야 한다 [15].
|
|
- **데이터 기반 개발(DDHD)과의 연계**: Thoughtworks는 이를 소프트웨어 공학에 적용하여, 복잡한 시스템 문제를 해결하고 레거시 시스템의 도메인 지식을 재구축하는 데 활용한다 [16, 17].
|
|
|
|
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
|
- **가설 대 증거 우선 (Hypothesis vs. Evidence-First)**: HDD는 명시적인 가설로 시작하여 속도를 높일 것을 권장하지만, 일부 비판론자들은 이것이 **앵커링 편향(Anchoring Bias)**과 **확증 편향(Confirmation Bias)**을 강화할 수 있다고 경고하며 가정이 배제된 "증거 우선 문제 해결(Evidence-First Problem Solving)"을 대안으로 제시한다 [18-20].
|
|
- **실행 실패와 가설 실패의 구분**: 테스트 결과가 부정적일 때 가설 자체가 틀린 것인지, 아니면 가설의 구현(Execution)이 잘못된 것인지 구분하는 것이 분석의 핵심 과제이다 [21].
|
|
|
|
## 🛠️ 적용 사례 (Applied in summary)
|
|
- **오피스 빌딩 커피숍 사례**: "모바일 주문을 도입하면 줄 서는 시간이 줄어들어 고객 이탈을 방지할 수 있다"는 가설을 세우고, 인터뷰와 설문을 통해 이를 검증한 뒤 설계를 진행했다 [14, 22].
|
|
- **B2B SaaS 온보딩 최적화**: "4단계 안내 체크리스트를 추가하면 워크스페이스 설정 완료율이 47%에서 65%로 증가할 것이다"라는 가설을 설정하고 30일간의 테스트를 통해 유지율(Retention) 개선을 확인했다 [23, 24].
|
|
- **키보드 단축키 기능 개발**: 파워 유저를 대상으로 단축키가 작업 속도를 20% 향상시킬 것이라 가정했으나, 베타 테스트 결과 발견 가능성(Discoverability)의 문제로 가설이 부분적으로만 검증되어 구현 방식을 수정했다 [25, 26].
|
|
|
|
## ✅ 검증 상태 및 신뢰도
|
|
- **상태:** draft
|
|
- **검증 단계:** conceptual (실제 적용 사례가 다수 소스에 명시됨 [16, 22, 27])
|
|
- **출처 신뢰도:** B (Thoughtworks, Centercode 등 전문 기관의 가이드 및 실무 사례 기반)
|
|
- **중복 검사 결과:** 신규 생성 (New discovery)
|
|
|
|
## 🔗 관련 문서 링크 (Related document links)
|
|
|
|
### 상위/유사 개념
|
|
#### [[Hypothesis-Driven Thinking]] (부모 개념)
|
|
- 연결 이유: HDD는 가설 중심 사고를 제품 설계와 개발 분야에 구체적으로 적용한 하위 방법론임 [2].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 전략적 문제 해결의 철학적 배경과 논리적 구조 [28, 29].
|
|
|
|
#### [[Evidence-First Problem Solving]] (대조 개념)
|
|
- 연결 이유: HDD의 잠재적 편향을 보완하기 위해 제안된 대안적 접근 방식임 [18, 19].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 가설 설정 전 데이터 수집의 중요성과 객관성 확보 방법 [30, 31].
|
|
|
|
### 심층 후속 질문 (Deeper Research Questions)
|
|
- 가설 중심 설계에서 발생하는 **확증 편향**을 방지하기 위한 구조적 '레드팀' 활동의 효과는 무엇인가? [32, 33]
|
|
- 정성적 연구 결과가 정량적 데이터와 충돌할 때, HDD 프로세스 내에서 의사결정 우선순위는 어떻게 결정되는가? [34, 35]
|
|
- AI 기반 프로토타이핑 도구는 HDD의 **검증 계층 구조**를 어떻게 변화시키고 있는가? [36, 37]
|
|
- "실패한 실험"의 가치를 조직의 자산으로 전환하기 위한 **가설 로그(Hypothesis Log)**의 표준화된 형식은 무엇인가? [38, 39]
|
|
- HDD가 레거시 시스템의 도메인 지식 복구에 기여하는 데이터 모델링 방식은 무엇인가? [16, 40]
|
|
|
|
### 실무 적용 맥락 (Practical Application Contexts)
|
|
- **Implementation**: "If-Then-Because" 구문을 사용하여 제품 백로그와 사용자 스토리를 작성함 [2, 6].
|
|
- **System Design**: 검증된 가설만을 바탕으로 시스템 아키텍처와 UI 플로우를 결정하여 재작업 비용을 절감함 [41, 42].
|
|
- **Operation / Maintenance**: 실시간 분석 대시보드를 구축하여 출시된 기능이 가설된 지표를 충족하는지 지속적으로 모니터링함 [43, 44].
|
|
- **Learning Path**: 이해관계자들을 위해 가정 수집부터 결과 도출까지의 과정을 데이터로 스토리텔링하여 신뢰를 구축함 [45, 46].
|
|
|
|
### 인접 주변 주제 (Adjacent Topics)
|
|
- [[MECE Principle]]: 가설 트리 구축 시 중복과 누락을 방지하기 위한 필수 논리 도구 [47].
|
|
- [[Falsification Theory]]: 가설이 과학적이기 위해 갖춰야 할 '반증 가능성'의 철학적 토대 [29, 48].
|
|
- [[A/B Testing]]: HDD 단계 중 연구(Research) 과정에서 가장 강력한 정량적 검증 도구 [49, 50].
|
|
|
|
## 📝 변경 이력 (Change history)
|
|
- 2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine based on synthesized product design sources. |