---
id: design-thinking
title: "Design Thinking"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["HDD", "Hypothesis-Driven Design"]
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"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Thoughtworks Legacy System Project", "Airline Inc. Cost Reduction", "Retail Sales Decline Case"]
github_commit: ""
---

# [[Design Thinking]]

## 🎯 한 줄 통찰 (One-line insight)
사용자 공감을 바탕으로 명시적인 가설을 설정하고, 반복적인 실험과 데이터 검증을 통해 불확실성을 혁신으로 전환하는 인간 중심의 문제 해결 프레임워크 [1-3].

## 🧠 핵심 개념 (Core concepts)
- **공감 기반 혁신 (Empathise to Innovate):** 사용자의 고통 지점(pain point)과 잠재적 요구를 깊이 이해하여 문제의 본질에 접근하고 가치를 창출함 [1, 4].
- **가설 기반 설계 (Hypothesis-Driven Design, HDD):** 제품 결정을 단순한 가정이나 직관이 아닌, 검증 가능한 예측(Falsifiable statement)을 바탕으로 진행함 [2, 5, 6].
- **학습 및 반복 (Learn & Iterate):** '구축 후 출시' 모델에서 벗어나, 소규모 실험을 통해 데이터를 수집하고 이를 바탕으로 솔루션을 지속적으로 개선하는 루프를 형성함 [7, 8].
- **공동 설계 및 협업 (Co-design):** 전문가의 단독 결정을 지양하고, 이해관계자와 사용자가 함께 솔루션을 모색하는 협업적 참여를 중시함 [9-11].

## 🧩 추출된 패턴 (Extracted patterns)
- **HDD 4단계 순업 프로세스:** 가정 식별(Assumptions) → 가설 변환(Hypotheses) → 연구 및 테스트(Research) → 설계 및 구축(Design & Build)의 순환 구조를 가짐 [5, 12].
- **검증 계층 구조 (Validation Hierarchy):** 초기 단계의 사용자 인터뷰/설문에서 시작하여 클릭 가능한 프로토타입을 거쳐, 최종적으로 MVP 및 A/B 테스트로 투자 수준과 신뢰도를 높여감 [13, 14].
- **가설 문장 표준 구문 (Standardized Syntax):** "만약 우리가 [특정 변경]을 실행한다면, [측정 가능한 결과]가 나타날 것이다. 왜냐하면 [근거/이유] 때문이다."라는 구조를 통해 사고의 명확성을 확보함 [7, 15].

## 📖 세부 내용 (Details)
- **문제 정의의 우선순위:** 솔루션에 뛰어들기 전에 사용자가 직면한 실제 문제를 정의하는 것이 필수적이며, 이는 종종 현재 상태(R1)와 목표 상태(R2) 사이의 격차로 정의됨 [4, 16].
- **가설의 4가지 구성 요소:** 구체적인 변경 사항(Specific change), 예측된 결과(Predicted outcome), 영향을 받는 사용자 세그먼트(User segment), 그리고 사전에 정의된 성공 기준(Success criteria)이 포함되어야 함 [17, 18].
- **데이터 중심의 가설 개발 (DDHD):** 복잡하고 이해도가 낮은 시스템(예: 레거시 시스템)의 문제를 해결할 때, 데이터를 나침반 삼아 가장 짧은 해결 경로를 찾고 부적절한 솔루션을 조기에 제거하는 데 활용됨 [19-21].
- **실패의 가치:** 설계 과정에서 가설이 기각되는 것은 시간과 자원의 낭비를 방지한 '학습'으로 간주되며, 이를 통해 더 나은 의사결정을 내릴 수 있는 기반이 마련됨 [22-24].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **효율성 vs 협업:** 민토 피라미드(Minto Pyramid)와 같은 전통적인 하향식 의사소통 방식은 의사결정권자에게 효율적이지만, 공동 설계(Co-design)와 같은 협력적 참여를 저해할 수 있는 한계가 있음 [9, 10].
- **데이터의 환상:** 분석 데이터는 '무엇(What)'이 일어났는지는 보여주지만 '왜(Why)' 일어났는지는 설명하지 못하므로, 정량적 분석과 함께 질적인 사용자 연구가 반드시 병행되어야 함 [25-27].

## 🛠️ 적용 사례 (Applied in summary)
- **Thoughtworks 레거시 시스템 개선:** 가시성이 낮고 방치된 레거시 아키텍처에 대해 DDHD(Data-Driven Hypothesis Development)를 적용하여 점진적으로 가치를 전달하고 도메인 지식을 재구축함 [23, 28, 29].
- **데이터 임포트 프로세스 UX 단순화:** 기존의 3단계 위저드 방식을 단일 페이지로 재설계하는 가설을 설정하고, 임포트 완료율 85% 달성과 지원 티켓 60% 감소를 목표로 검증을 진행함 [30, 31].
- **오피스 빌딩 커피 주문 시스템:** "주문 대기 시간이 줄어들면 고객 이탈이 방지될 것"이라는 가정을 모바일 주문 앱 도입 가설로 변환하여 실무에 적용함 [15, 32, 33].
- **A/B 테스트를 통한 가격 실험:** 소규모 비즈니스 대상 플랫 요금제 도입 가설을 설정하여 전환율 18% 증가 여부를 통계적으로 검증함 [34, 35].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례가 보고되었으나, 일반화된 프레임워크 수준임)
- **출처 신뢰도:** B (Thoughtworks, Centercode, McKinsey 등 전문 컨설팅 및 제품 관리 방법론에 기반함)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념
#### [관계 유형: 프레임워크/방법론]
- [[Hypothesis-Driven Thinking]]
  - 연결 이유: 디자인 씽킹의 핵심 동력인 가설 설정과 검증의 근간이 되는 사고 방식임 [36, 37].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 직관적 추측을 과학적 실험으로 전환하는 논리적 구조 [38].
- [[Scientific Method]]
  - 연결 이유: 디자인 씽킹은 과학적 방법론을 비즈니스와 제품 설계 영역에 적용한 형태임 [39, 40].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 가설 수립 및 refutation(반증)의 철학적 원리 [41].

#### [관계 유형: 구현/구조화 도구]
- [[MECE]]
  - 연결 이유: 문제 공간을 중복 없이 포괄적으로 분석하여 가설을 수립할 때 필수적인 원칙임 [42, 43].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 문제 분해의 논리적 완결성 확보 방법 [44].
- [[Minimum Viable Product (MVP)]]
  - 연결 이유: 수립된 제품 가설을 가장 저렴하고 빠르게 검증하기 위한 물리적 구현체임 [14, 45].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 학습을 위한 최소한의 실행 단위 설정 [8].

### 심층 후속 질문 (Deeper Research Questions)
- 디자인 씽킹의 '공감' 단계에서 수집된 질적 데이터는 어떻게 정량적인 '측정 가능한 가설'로 치환되는가? [27, 46]
- 민토 피라미드의 '하향식 의사소통'과 디자인 씽킹의 '상향식 실험' 사이의 전략적 충돌을 어떻게 조화시킬 것인가? [10, 47]
- 가설 기반 설계(HDD)에서 '성공 임계값(Threshold)'을 설정할 때 발생할 수 있는 편향을 어떻게 방지하는가? [48, 49]
- 레거시 시스템 현대화 과정에서 DDHD가 도메인 지식 손실을 복구하는 구체적인 메커니즘은 무엇인가? [21, 29]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 제품 백로그의 모든 아이디어를 "If... then... because" 형식의 가설로 변환하여 기록함 [50].
- **System Design:** 사용자의 작업 완료 시간(Task completion time)을 주요 지표로 설정하여 UX 변경 가설을 검증함 [31, 51].
- **Operation / Maintenance:** 레거시 시스템의 모니터링 및 관측성(Observability)을 강화하여 성능 개선 가설의 피드백 루프를 구축함 [52].
- **Learning Path:** 소규모 실험을 통해 얻은 교훈을 '가설 포스트모템(Hypothesis postmortem)'을 통해 조직 전체와 공유함 [24].

### 인접 주변 주제 (Adjacent Topics)
- [[Cognitive Biases]]
  - 확장 방향: 가설 검증 과정에서 발생하기 쉬운 확증 편향(Confirmation bias)과 고착 편향(Anchoring bias)을 인지하고 방어함 [53, 54].

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