---
id: problem-statement
title: "Problem Statement"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Point-of-View", "POV"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-05-23
updated_at: 2026-05-23
review_reason: ""
merge_history: []
tags: ["research", "design thinking"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Pillpack", "Innova Schools", "Private Sector Bank Loan Case", "IT Services Firm Project Inception"]
github_commit: ""
---

# [[Problem Statement]]

## 🎯 한 줄 통찰 (One-line insight)
**"올바른 문제를 정의(Framing)하는 것이 올바른 해결책을 만드는 유일한 방법이다."** [1, 2]

## 🧠 핵심 개념 (Core concepts)
- **관점(Point-of-View, POV):** 특정 사용자, 그들의 필요(Needs), 그리고 공감 단계에서 발견한 통찰(Insights)을 결합하여 정의한 **의미 있고 실행 가능한 문제 정의서**입니다. [3-5]
- **인간 중심의 프레이밍 (Human-centered Framing):** 문제를 비즈니스 목표(예: 가입률 5% 증가)가 아닌 **인간의 필요(예: 바쁜 부모가 가족에게 건강한 음식을 제공하도록 돕기) 관점**에서 서술하는 것입니다. [5, 6]
- **감각 형성 (Sensemaking):** 공감 단계를 통해 얻은 광범위한 정보를 합성하여 연결 고리와 패턴을 발견하고, 설계 공간에 **명확성과 초점**을 부여하는 과정입니다. [3, 4, 7, 8]
- **합성 (Synthesis):** 파편화된 연구 결과물들을 강력한 통찰로 결합하여 디자인 챌린지를 해결할 수 있는 독보적인 이점을 확보하는 활동입니다. [9, 10]

## 🧩 추출된 패턴 (Extracted patterns)
- **POV 구성 공식:** **[사용자(User)]**는 **[통찰(Insight)]** 때문에 **[니즈(Need)]**가 필요하다는 형태로 세 요소를 결합하여 명확한 문장으로 표현합니다. [9, 10]
- **협소한 초점의 역설:** 문제 정의가 좁고 구체적일수록 아이디어 발산 단계에서 해결책의 **양과 질이 모두 향상**되는 패턴이 발견됩니다. [3, 4]
- **리트머스 시험 (Litmus Test):** 잘 정의된 POV는 자연스럽게 **"어떻게 하면 우리가...?(How-Might-We...?)"**라는 브레인스토밍 주제를 파생시킵니다. [11, 12]
- **패턴 인식 휴리스틱:** 사용자가 말하는 것과 행동하는 것 사이의 **불일치(Disconnect)**나 스스로 만들어낸 **임시방편(Work-around)**을 관찰하여 핵심 문제를 식별합니다. [13, 14]

## 📖 세부 내용 (Details)
**문제 정의(Define) 모드**는 디자인 프로세스에서 가장 비판적인 단계로, 단순히 문제를 나열하는 것이 아니라 **'해결할 가치가 있는 올바른 도전'**을 결정하는 책임이 따릅니다. [3, 4, 7, 8] 이 단계에서는 수집된 데이터(포스트잇, 사진, 인용구 등)를 벽에 시각화하여 공유하는 **'언팩(Unpack)'** 과정을 거치며 지식을 구조화합니다. [15, 16]

효과적인 문제 정의서(POV)가 갖추어야 할 주요 특성은 다음과 같습니다:
- 팀에 **영감**을 주고 독립적인 의사결정을 내릴 수 있는 권한을 부여합니다. [1, 2]
- 상충되는 아이디어를 평가할 수 있는 **기준(Criteria)**을 제공합니다. [1, 2]
- 모든 사람을 만족시키려는 불가능한 시도에서 팀을 보호하며, 문제를 **불연속적이고 구체적**으로 유지합니다. [1, 2]
- 기술적 가능성(Feasibility), 비즈니스 지속 가능성(Viability) 이전에 **사용자의 바람직함(Desirability)**을 우선적으로 고려합니다. [17, 18]

특히 AI 전환과 같은 현대적 맥락에서도 기술적 배포보다 **"중간 관리자가 자신의 업무에 AI를 자신 있게 사용하도록 돕는다"**와 같은 인간 중심의 문제 정의가 성공적인 채택의 핵심으로 작용합니다. [5, 6, 19, 20]

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **비선형적 순환:** 초기 이론은 단계별 진행을 상정했으나, 실제 현장에서는 시제품 제작(Prototype)이나 테스트(Test) 단계에서 얻은 새로운 학습으로 인해 다시 **문제 정의 단계로 루프백(Looping back)**하는 것이 필수적인 과정으로 인식됩니다. [21-23]
- **데이터 vs 통찰:** 대규모 데이터 세트(AI 분석 등)는 문제의 규모(Scale)를 보여줄 수 있지만, 그 안에서 **의미(Meaning)를 선택하고 문제로 정의하는 것은 여전히 팀의 판단**에 달려 있습니다. [24, 25]

## 🛠️ 적용 사례 (Applied in summary)
- **Pillpack:** 온라인 약국 서비스를 스타트업에서 매각 단계까지 성장시키며, 고객이 약국과 상호작용하는 방식을 **인간 중심으로 재정의**하여 산업을 혁신했습니다. [26, 27]
- **Innova Schools:** 페루의 중산층을 위해 학교 네트워크 전체를 바닥부터 설계하며 교육 시스템의 도전을 **새롭게 정의**하여 확장했습니다. [26, 27]
- **인도 대형 민간 은행:** 모바일 대출 신청 중단율 문제를 해결할 때, 처음에는 UI/UX 문제(버튼 배치 등)로 정의했으나 공감 연구를 통해 **'신용 점수 하락에 대한 공포(신뢰 문제)'**로 문제 정의를 수정하여 34%의 완료율 향상을 달성했습니다. [28-33]
- **중견 IT 서비스 기업:** 프로젝트 초기 단계에 **디자인 씽킹 기반의 구조화된 문제 정의 단계**를 도입한 결과, 개발 스프린트 도중 발생하는 범위 변경(Scope changes)이 40% 감소했습니다. [34, 35]

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
- **중복 검사 결과:** 신규 생성 (New discovery)

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