2nd/Premium/Thinking & Reasoning/Problem Definition.md

---
id: problem-definition
title: "Problem Definition"
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", "logic tree"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Harley-Davidson Case", "Dangote Cement Case", "NovaCloud Case", "Acme Tools Case"]
github_commit: ""
---

# [[Problem Definition]]

## 🎯 한 줄 통찰 (One-line insight)
문제 정의는 현재의 원치 않는 결과(R1)와 도달하고자 하는 목표 결과(R2) 사이의 격차(Gap)를 명확히 규명함으로써 해결을 위한 논리적 구조를 세우는 필수적인 선행 과정이다 [1, 2].

## 🧠 핵심 개념 (Core concepts)
- **R1 (Undesired Result):** 현재 조직이나 개인이 처해 있는 바람직하지 않은 상태나 결과 [1, 2].
- **R2 (Desired Result):** 문제를 해결함으로써 도달하고자 하는 구체적이고 측정 가능한 목표 상태 [1, 3].
- **격차(Gap):** R1과 R2 사이의 차이로, 이 격차 자체가 해결해야 할 '문제'의 본질이 된다 [2].
- **방해 사건(Disturbing Event):** 안정적이었던 초기 상황을 변화시켜 R1이라는 원치 않는 결과를 초래하게 만든 구체적인 원인이나 변화 [1, 3].
- **SMART 질문:** 문제 정의는 구체적(Specific), 측정 가능(Measurable), 실행 지향적(Action-oriented), 관련성 있는(Relevant), 시간 제한이 있는(Time-bound) 형태의 질문으로 표현되어야 한다 [4].

## 🧩 추출된 패턴 (Extracted patterns)
- **SCQA 매핑 패턴:** 문제 정의 프레임워크의 요소들은 [[SCQA Framework]]와 직접 대응된다. '출발점'은 상황(S), '방해 사건'은 전개/복잡성(C), R1/R2 사이의 격차는 질문(Q), 그리고 분석 결과는 답변(A)이 된다 [5].
- **7가지 표준 문제 상황:** 비즈니스 문제는 주로 ①경로 찾기, ②목표 설정, ③현황 파악, ④원인 규명, ⑤해결책 평가, ⑥실패 분석, ⑦대안 선택 중 하나의 패턴을 따른다 [6].
- **순차적 분석(Sequential Analysis) 패턴:** 문제를 정의한 후에는 '문제가 존재하는가?' → '어디에 있는가?' → '왜 존재하는가?' → '무엇을 할 수 있는가?' → '무엇을 해야 하는가?'의 5단계 질문 과정을 거친다 [7, 8].

## 📖 세부 내용 (Details)
### 1. 문제 정의의 중요성 및 정의
문제 정의는 전체 문제 해결 프로세스에서 가장 중요한 단계이며, 이를 소홀히 하고 바로 해결책으로 뛰어드는 것은 많은 사람들의 공통적인 실수다 [2, 9, 10]. 비즈니스 환경에서 문제는 단순히 '무언가 잘못된 것'이 아니라, 현재 상태(R1)와 미래의 원하는 상태(R2) 사이의 명확한 간극으로 정의된다 [1, 2].

### 2. Minto의 문제 정의 프레임워크 (Problem-Definition Framework)
바바라 민토(Barbara Minto)는 비즈니스 과제를 체계적으로 정의하기 위해 네 가지 구성 요소를 제시한다 [1, 3, 5]:
- **출발점 / 도입 장면 (Starting Point / Opening Scene):** 모든 것이 정상적으로 작동하던 초기 상황이나 안정적인 맥락을 설정한다.
- **방해 사건 (Disturbing Event):** 상황을 변화시키고 격차를 만들어낸 내부 또는 외부의 변화를 식별한다.
- **원치 않는 결과 (R1):** 방해 사건으로 인해 현재 조직이 처해 있는 부정적인 현상을 수치화하여 규명한다.
- **원하는 결과 (R2):** 격차를 해소하기 위해 달성해야 할 구체적인 목표 수치를 설정한다.

### 3. 문제 정의의 구체화 및 정교화
- **구체적인 질문화:** "회사가 왜 힘든가?"와 같은 모호한 질문 대신, "왜 지난 2년간 수익성이 15% 하락했는가?"와 같이 구체적이고 실행 가능한 질문으로 정의해야 한다 [11, 12].
- **이해관계자 합의:** 정의된 문제가 해결해야 할 '옳은 문제'인지 모든 주요 이해관계자와 합의하는 과정이 필수적이다 [10].
- **지속적 재검증:** 비즈니스 환경 변화에 따라 초기 가정이 달라질 수 있으므로, 문제 정의를 정기적으로 재검증하여 팀의 초점을 유지해야 한다 [13].

### 4. [[logic tree]]와의 연결성
문제 정의는 논리 트리의 뿌리(Root Node)가 된다 [14, 15]. 명확하게 정의된 핵심 질문은 이후 [[MECE Principle]]에 따라 하위 이슈로 분해되어 분석 가능한 단위로 쪼개진다 [16, 17]. 문제 정의가 모호하면 논리 트리 역시 모호해지고 분석의 범위가 무한정 늘어나는 오류를 범하게 된다 [18, 19].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **정의 vs 해결책의 선후 관계:** 소스에서는 반드시 문제를 먼저 정의한 후 해결책을 제안할 것을 강조하며, 해결책을 가설로 먼저 내세우는 '애완 가설(Pet theory)'의 위험성을 경고한다 [9].
- **완벽한 정의의 함정:** 초기 문제 정의 단계에서 완벽함을 기하기보다는 빠르게 초안을 작성하고 고객과 함께 정교화해 나가는 반복적(Iterative) 접근이 권장된다 [13].

## 🛠️ 적용 사례 (Applied in summary)
- **Harley-Davidson [20]:** '팬데믹 기간 중 마이너스 수익 발생'이라는 현상을 R1으로 정의하고, 수익성 회복 방안을 찾는 과정에서 문제 정의 프레임워크가 적용됨.
- **Dangote Cement [13]:** "어떻게 2027년까지 EBITDA를 500억 나이라 증대시킬 것인가?"라는 SMART한 질문 형태로 문제를 정의함.
- **NovaCloud [21]:** "북미 미드마켓에서 2분기 내에 순매출 유지율(NRR)을 110% 이상으로 회복하려면 무엇을 해야 하는가?"라는 구체적 목표를 설정함.
- **Acme Tools [22]:** '북미 지역 EBITDA 마진 220bp 하락'을 원치 않는 결과(R1)로 정의하고, 12개월 내 18% 이상 회복을 원하는 결과(R2)로 설정함.

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

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

### 상위/유사 개념
#### [아키텍처/기반 기술]
- [[logic tree]]
  - 연결 이유: 문제 정의는 모든 논리 트리의 시작점인 '루트 노드'를 결정하는 핵심 단계임 [14, 15].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 정의된 문제의 범위가 분석 트리의 깊이와 넓이를 결정하는 원리 [18, 23].
- [[SCQA Framework]]
  - 연결 이유: 비즈니스 상황을 스토리 형태로 서술하여 문제의 맥락을 정의하는 데 사용됨 [5].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순한 수치를 넘어 비즈니스 히스토리와 합의점을 찾는 방법 [24, 25].

#### [구현/활용 도구]
- [[MECE Principle]]
  - 연결 이유: 정의된 문제를 중복과 누락 없이 하위 이슈로 분해하기 위한 논리적 규칙임 [26, 27].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 정의된 문제 공간을 빈틈없이 탐색하는 체계적 방법 [28].
- [[Hypothesis-driven Problem Solving]]
  - 연결 이유: 명확한 문제 정의를 바탕으로 잠정적인 답변(가설)을 세우고 이를 검증하는 방식임 [29, 30].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 수집 전 논리적 추론을 통해 분석 효율을 높이는 전략 [31, 32].

### 심층 후속 질문 (Deeper Research Questions)
- Minto의 R1-R2 격차 모델이 [[Opportunity Solution Tree]]의 'Outcome' 설정과 어떻게 연관되는가? [1, 15]
- 문제 정의 단계에서 이해관계자 간의 견해 차이를 [[logic tree]]를 활용해 어떻게 조정할 수 있는가? [33, 34]
- 가설 수립(Hypothesizing) 이전에 수행되는 진단(Diagnosis) 과정에서 문제 정의의 역할은 무엇인가? [8, 35]
- SMART 기준을 충족하지 못한 모호한 문제 정의가 프로젝트의 '범위 산정(Scoping)'에 미치는 구체적인 영향은 무엇인가? [19, 36]
- 7가지 표준 문제 패턴 중 '실패 분석' 상황에서의 문제 정의와 '해결책 평가' 상황에서의 문제 정의는 구조적으로 어떻게 다른가? [6]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 프로젝트 착수 시 '문제 기술서(Problem Statement Worksheet)'를 작성하여 팀 내 목표를 일치시키는 도구로 활용함 [4].
- **System Design:** [[logic tree]] 설계 전, 분석해야 할 '전체 집합(Universe)'을 정의하는 경계 설정 단계로 적용됨 [37, 38].
- **Operation / Maintenance:** 운영 중 발생하는 장애(방해 사건)의 성격을 규명하고, 정상 상태(R2)로의 복구 요건을 정의하는 데 사용됨 [1, 39].
- **Learning Path:** 복잡한 비즈니스 케이스를 접했을 때, 바로 수치 계산에 들어가기 전 상황을 S-C-Q로 정리하는 사고 습관 형성 [5, 24].

### 인접 주변 주제 (Adjacent Topics)
- [[Root Cause Analysis]]
  - 확장 방향: 정의된 문제의 기저에 있는 '진짜 원인'을 파헤치는 심화 분석 기법 탐구 [20, 39].
- [[Decision Tree]]
  - 확장 방향: 정의된 문제에 대한 여러 대안 중 확률과 기댓값을 바탕으로 최적의 선택을 하는 방법론 연구 [40, 41].

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