---
id: assumption-mapping
title: "Assumption Mapping"
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-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Product Discovery", "Risk Management"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Getup E-commerce App Case Study", "Lokalise Shopify App Discovery", "Back Market Live Chat MVP"]
github_commit: ""
---

# [[Assumption Mapping]]

## 🎯 한 줄 통찰 (One-line insight)
불확실한 '추측'을 '증거' 기반의 실행 가능한 데이터로 전환하기 위해, 비즈니스의 사활을 결정짓는 **가장 위험한 가정(Riskiest Assumptions)**을 시각화하고 우선순위를 정하는 전략적 나침반 [1-3].

## 🧠 핵심 개념 (Core concepts)
- **2x2 우선순위 매트릭스:** 가정을 '중요도(Importance)'와 '증거/불확실성(Evidence/Uncertainty)'이라는 두 축을 기준으로 배치하여 리스크를 구조화함 [4, 5].
- **DVF 프레임워크:** 디자인 씽킹의 세 가지 핵심 차원인 **매력도(Desirability)**, **실행 가능성(Feasibility)**, **수익성(Viability)** 관점에서 가정을 분류함 [6-8].
- **위험한 가정 식별(RAT 연계):** 성공을 위해 반드시 참이어야 하지만 현재 증거가 가장 부족한 '도약의 가정(Leap-of-faith assumptions)'을 찾아내어 실험의 초점을 맞춤 [5, 9, 10].
- **지속적 발견(Continuous Discovery):** 일회성 행사가 아닌, 주간 단위의 리듬으로 제품 로드맵을 실제 고객 문제에 고정시키는 엔진 역할을 수행함 [11, 12].

## 🧩 추출된 패턴 (Extracted patterns)
- **컬러 코딩 시스템:** 워크숍 시 시각적 직관성을 높이기 위해 주황색(매력도), 파란색(실행 가능성), 초록색(수익성) 스티키 노트를 사용함 [8].
- **4분면 전술 (Tactical Quadrants):**
    - **Plan (좌상단):** 중요하고 증거가 충분한 '사실'. 정렬을 위해 논의하되 즉각적인 테스트는 불필요 [5, 13].
    - **Experiment (우상단):** 중요하지만 증거가 없는 '고위험군'. 실험과 검증의 핵심 타겟 [4, 5].
    - **Defer (좌하단):** 중요하지 않고 증거가 있는 영역. 자원 낭비를 막기 위해 작업을 보류 [5, 14].
    - **Discover (우하단):** 중요하지 않지만 불확실한 영역. 숨겨진 문제를 찾기 위한 생성적 연구 대상 [5, 13].
- **역방향 설계 패턴:** '무엇을 만들까'가 아니라 '무엇을 배워야 하는가'에서 시작하여 코드 작성 전 검증을 완료하는 'Learn-Measure-Build' 구조를 지향함 [10, 15].

## 📖 세부 내용 (Details)
**1. 가정 매핑의 이론적 기초와 목적**
- 현대 벤처 디자인과 제품 관리에서 실패의 주원인은 기술적 실행력이 아니라 **시장 수요가 없는 솔루션의 체계적 개발**에 있음 [12].
- 가정 매핑은 팀의 내부에 숨겨진 보이지 않는 전제들을 명시적으로 드러내고, 리소스를 투입하기 전에 비즈니스 모델을 무너뜨릴 수 있는 리스크를 관리하는 도구임 [16, 17].

**2. 워크숍 실행 절차 (Physical/Digital Execution)**
- **준비:** 이해관계자와 도메인 전문가들이 1시간~1시간 30분 동안 모여 진행함 [18, 19].
- **브레인스토밍:** 약 15분 동안 각 구성원이 하나의 스티키 노트에 하나의 정밀하고 테스트 가능한 문장으로 가정을 기록함 [19].
- **배치 및 토론:** 퍼실리테이터의 안내에 따라 가정의 잠재적 영향력과 검증 난이도를 고려하여 2x2 매트릭스 위에 배치함 [8, 20].
- **분류 가이드라인:**
    - **매력도(Desirability):** "사용자가 이것을 원하는가?" (고객 페인포인트, 행동 변화 의지 등) [6, 21].
    - **실행 가능성(Feasibility):** "우리가 이것을 만들 수 있는가?" (기술적 제약, 구현 복잡성 등) [6, 21].
    - **수익성(Viability):** "이것이 경제적으로 지속 가능한가?" (수익 모델, 획득 비용 등) [6, 22].

**3. 리스크 영향도 분류 및 거버넌스 (Governance Guardrails)**
- 매핑된 가정은 리스크 점수($Risk = Probability \times Impact$)에 따라 관리됨 [23].
- **Very High Impact:** 비즈니스 모델을 무효화하거나 규제 준수 실패를 초래할 수 있는 경우, 스케일링을 중단하고 즉시 검증 예산을 할당함 [24].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **MVP vs RAT:** 과거에는 최소 기능 제품(MVP) 구축 자체가 검증의 시작이었으나, 최신 방법론은 Assumption Mapping을 통해 식별된 'Experiment' 영역에만 집중하는 **Riskiest Assumption Testing(RAT)**을 통해 코드 작성 없이도 검증이 가능함을 강조함 [10, 25, 26].
- **시간적 압박 하의 매핑:** 위기 상황(예: 코로나19)에서는 점진적 변화보다 즉각적인 리소스 재배치를 위한 빠른 매핑과 실험이 생존을 결정함 [27, 28].

## 🛠️ 적용 사례 (Applied in summary)
- **Getup (이커머스 의류 브랜드):** 신규 모바일 앱 기획 단계에서 가정 매핑을 실시함. 비즈니스 중요도, 기술적 실행 가능성, 고객 중요도의 3가지 기준으로 각 기능을 평가하고 1~5점의 점수를 부여하여 우선순위를 재정렬함. 그 결과 '날씨 기반 코디 추천'보다 '전문 스타일리스트 도움' 기능의 사용자 관심도가 훨씬 높음을 확인하고 전략을 피벗함 [29-31].
- **Lokalise:** Shopify 번역 앱 개발 초기 단계에서 가정 매핑을 통해 Desirability/Feasibility/Viability를 테스트하여 초기 채택을 유도함 [32].
- **Back Market:** 고객 케어를 위한 라이브 채팅 MVP 런칭 시 가정 매핑을 적용함 [32].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 기업들의 적용 사례 [Getup 등]를 통해 방법론의 효용성이 확인됨)
- **출처 신뢰도:** B (David Bland 등 방법론 창시자와 전문 제품 관리 커뮤니티의 자료를 기반으로 함)
- **중복 검사 결과:** 신규 생성 (New discovery)

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

### 상위/유사 개념
#### [시스템 프레임워크]
- [[Assumption Validation Loop]]
  - 연결 이유: Root 주제로서 가정 매핑이 작동하는 전체 순환 구조를 제공함.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 매핑 이후의 검증(Verify) 및 학습(Learn) 단계로의 연결 방식.

#### [검증 방법론]
- [[Riskiest Assumption Testing (RAT)]]
  - 연결 이유: 매핑된 가정 중 'Experiment' 분면에 있는 항목을 처리하는 가장 효율적인 기법.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 제품을 만들지 않고도 신호를 생성하는 'Learn-Measure-Build' 패러다임.
- [[Minimum Viable Product (MVP)]]
  - 연결 이유: 매핑 결과를 바탕으로 어떤 형태의 MVP(Landing Page, Concierge 등)를 구축할지 결정함.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 가설 유형별 최적의 실험 패턴 매칭.

#### [우선순위 모델]
- [[Kano Model]]
  - 연결 이유: 매핑된 기능적 가정이 사용자 만족도에 미치는 영향을 분류하는 상호보완적 도구.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Must-be(당연 기능)와 Delighters(매력 기능)의 구분을 통한 정교한 우선순위 산정.

### 심층 후속 질문 (Deeper Research Questions)
- Assumption Mapping 워크숍에서 이해관계자 간의 '중요도'에 대한 견해 차이가 발생할 때, 이를 객관적으로 중재하는 데이터 기반의 합의 모델은 무엇인가? [20, 33]
- DVF 차원 외에 보안 및 규제 준수가 중요한 산업군에서 추가해야 할 제4의 매핑 차원은 어떻게 설계되어야 하는가? [17, 34]
- AI 기반의 제품 통찰 도구가 Assumption Mapping의 '불확실성' 축을 실시간으로 업데이트하는 데 어떤 역할을 할 수 있는가? [35, 36]
- 매핑된 가정이 실험을 통해 '사실(Fact)'로 이동하는 기준(Threshold)을 설정할 때, 인지 편향을 제거하기 위한 'Devil's Advocate' 프로세스의 설계 방법은? [37, 38]
- 위기 상황에서 리소스가 극도로 제한될 때, Assumption Mapping의 절차를 어떻게 '린(Lean)'하게 압축하여 실행할 수 있는가? [39, 40]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 개발 전 '무엇을 만들지 말아야 할지' 결정하는 스코프 컷(Scope Cut) 도구로 활용 [41].
- **System Design:** 기술적 불확실성이 높은 고난도 아키텍처 도입 전 Feasibility 가정을 검증하기 위한 기술 스파이크(Technical Spike) 설계 [42].
- **Operation / Maintenance:** 운영 중인 기능이 더 이상 가치를 주지 못한다는 의심이 들 때, 기존의 '당연한 사실'을 '검증 대상 가정'으로 재매핑하여 피벗 여부 결정 [43, 44].
- **Learning Path:** 주니어 기획자가 단순한 '기능 나열'에서 벗어나 '리스크 기반 사고'를 체득하게 하는 교육적 프레임워크로 사용 [45, 46].

### 인접 주변 주제
- [[Lean Startup]]
  - 확장 방향: Build-Measure-Learn 루프의 전체 철학적 배경 이해.
- [[User Journey Mapping]]
  - 확장 방향: 고객의 여정 속에서 어느 지점에 리스크가 숨어 있는지 발견하여 가정을 추출하는 소스로 활용 [47, 48].

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