문제 정의 (Problem Definition)
1. 개요
문제 정의란 해결해야 할 대상이 되는 현상의 본질을 명확히 규명하고, 달성하고자 하는 목표 상태를 구체적으로 기술하는 과정이다.
소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle)의 최상위 단계인 요구사항 분석의 출발점으로, '무엇을(What)' 개발할 것인가를 결정하기 전 '왜(Why)' 이 개발이 필요한지를 정의하는 핵심 활동이다.
2. 문제 정의의 필요성 및 목적
명확한 문제 정의 없이 개발에 착수할 경우, 기술적 구현에만 매몰되어 실제 사용자의 고통(Pain Point)을 해결하지 못하는 결과물이 나올 가능성이 높다.
2.1. 정의 부재 시 발생하는 리스크
- 범위 확장(Scope Creep): 문제의 경계가 불분명하여 개발 과정 중 지속적으로 새로운 요구사항이 추가되어 프로젝트 일정이 지연된다.
- 비용 및 자원 낭비: 잘못된 문제 정의로 인해 엉뚱한 기능을 구현하게 되며, 이는 전면적인 재작업(Rework)으로 이어져 비용을 증가시킨다.
- 잘못된 솔루션 도출: 현상이 아닌 증상(Symptom)만을 해결하려 하여, 근본 원인이 제거되지 않은 임시방편적 시스템이 구축된다.
2.2. 기대 효과
- 이해관계자 간 합의: 고객, 기획자, 개발자가 동일한 문제 의식을 공유함으로써 커뮤니케이션 비용을 절감한다.
- 우선순위 설정: 문제의 심각도와 영향도를 분석하여 가장 시급하게 해결해야 할 핵심 기능(Core Feature)을 식별할 수 있다.
- 성공 지표 설정: 문제 정의가 명확하면 솔루션 도입 후 개선 여부를 측정할 수 있는 정량적 지표(KPI) 설정이 가능해진다.
3. 문제 정의 프로세스
문제 정의는 단순히 현상을 기록하는 것이 아니라, 논리적인 추론 과정을 통해 구체화하는 절차를 거친다.
| 단계 |
주요 활동 |
입력물 (Input) |
출력물 (Output) |
| 현상 파악 |
사용자 불만 사항 수집, 로그 분석, 인터뷰 |
VOC, 에러 로그, 시장 조사서 |
현상 기술서 (Observation Log) |
| 근본 원인 분석 |
현상의 배후에 있는 진짜 이유 탐색 |
현상 기술서, 도메인 지식 |
원인 분석 보고서 (Root Cause) |
| 목표 설정 |
해결 후 도달해야 할 이상적인 상태 정의 |
원인 분석 보고서 |
목표 상태 정의서 (To-Be Model) |
| 제약 조건 확인 |
예산, 기간, 기술적 한계, 법적 규제 검토 |
프로젝트 헌장, 인프라 현황 |
제약 사항 목록 (Constraints) |
4. 범위 설정 (Scoping)
문제 정의 단계에서 무엇을 해결할 것인가만큼 중요한 것이 '무엇을 해결하지 않을 것인가'를 명확히 하는 것이다. 이를 통해 프로젝트의 집중도를 높이고 범위 확장(Scope Creep)을 방지할 수 있다.
- In-Scope (해결 범위): 이번 프로젝트를 통해 반드시 해결해야 할 핵심 문제와 기능.
- Out-of-Scope (제외 범위): 관련이 있어 보이지만 이번 단계에서는 다루지 않기로 합의한 사항.
- 예시: '결제 프로세스 이탈률 감소'가 목표일 때
- In-Scope: 결제 단계의 UI/UX 간소화, 결제 오류 메시지 구체화.
- Out-of-Scope: 새로운 결제 수단(예: 가상화폐) 추가, 포인트 적립 시스템 전면 개편.
5. 문제 정의를 위한 분석 기법
문제의 복잡도와 성격에 따라 적절한 분석 도구를 선택하여 사용한다.
5.1. 핵심 분석 기법 및 적용 예시
- 5 Whys: "왜?"라는 질문을 반복하여 표면적인 현상 너머의 근본 원인을 찾는 기법이다.
- 적용 예시: "결제 오류가 발생한다" $\rightarrow$ (왜?) "DB 연결 시간이 초과되었다" $\rightarrow$ (왜?) "쿼리 최적화가 안 되어 있다" $\rightarrow$ (왜?) "대량의 데이터를 풀 스캔(Full Scan)하고 있다" $\rightarrow$ (왜?) "적절한 인덱스 설계가 누락되었다" $\rightarrow$ (왜?) "초기 설계 리뷰 단계가 생략되었다" (근본 원인: 프로세스 부재)
- 로직 트리 (Logic Tree): 문제를 논리적인 계층 구조로 분해하여 전체적인 구조를 파악하고 누락 없이 분석하는 기법이다.
- 적용 예시: '매출 감소'라는 최상위 문제를 [신규 고객 유입 감소], [기존 고객 유지율 하락], [객단가 하락]으로 1차 분해하고, 다시 각 항목을 세부 원인으로 쪼개어 분석한다.
- 피시본 다이어그램 (Ishikawa): 결과(문제)를 머리 부분에 두고, 원인을 카테고리별(사람, 방법, 기계, 재료 등)로 가지를 쳐서 시각화하는 기법이다.
- 적용 예시: '앱 이탈률 증가'라는 문제를 중심에 두고 [UI/UX], [네트워크 성능], [콘텐츠 부족], [마케팅 타겟팅 오류] 등의 가지를 뻗어 원인을 분석할 때 사용한다.
- MECE 원칙 (Mutually Exclusive, Collectively Exhaustive): 항목들이 서로 중복되지 않으면서도 전체적으로 누락이 없는 상태로 분류하는 논리적 사고 방식이다.
- 적용 예시: 사용자 층을 분석할 때 '10대, 20대, 30대...'와 같이 연령별로 나누어 누락과 중복 없이 전체 사용자군을 분석하는 경우이다.
- 사용자 스토리 맵 (User Story Map): 사용자의 여정(Journey)을 시간 순서대로 나열하고, 각 단계에서 겪는 문제와 필요한 기능을 매핑하는 기법이다.
- 적용 예시: 쇼핑몰 앱의 '상품 검색 $\rightarrow$ 장바구니 $\rightarrow$ 결제' 과정 중 어느 지점에서 사용자가 가장 큰 불편을 느끼는지 시각화할 때 사용한다.
6. 문제 정의서 작성 가이드
문제 정의서는 이해관계자 간의 공식적인 합의 문서 역할을 하며, 객관적이고 측정 가능한 언어로 작성되어야 한다.
많은 이들이 두 개념을 혼동하지만, 논리적 선후 관계가 명확히 다르다.
| 구분 |
문제 정의 (Problem Definition) |
요구사항 정의 (Requirement Definition) |
| 관점 |
Why & What (왜 해결해야 하는가?) |
How (어떻게 해결할 것인가?) |
| 초점 |
고통(Pain Point)과 결핍, 비효율성 |
기능(Feature), 성능, 제약 조건 |
| 예시 |
"결제 과정이 너무 복잡해 구매 전환율이 낮다." |
"간편 결제 API를 도입하고 단계를 3단계로 줄인다." |
| 순서 |
선행 단계 (분석의 시작) |
후행 단계 (설계의 기초) |
6.2. 작성 템플릿 및 예시
[문제 정의 문장 템플릿]
"[대상/사용자]는 [특정 상황]에서 [어떤 문제]를 겪고 있으며, 이로 인해 [어떤 부정적 결과]가 발생하고 있다. 이를 해결하기 위해 [목표 상태]가 필요하다."
[As-Is vs To-Be 비교 양식]
### [사례: 사내 근태 관리 시스템 개선]
1. 문제 정의:
인사팀 담당자는 매월 말 수동으로 엑셀 데이터를 취합하여 연차를 계산하고 있으며,
이 과정에서 데이터 입력 오류가 빈번하게 발생하여 급여 지급 지연 리스크가 존재한다.
2. 상태 비교:
| 구분 | As-Is (현재 상태) | To-Be (목표 상태) |
| :--- | :--- | :--- |
| 데이터 수집 | 각 팀별 엑셀 파일 개별 제출 | 시스템 내 실시간 신청 및 승인 |
| 계산 방식 | 담당자가 수식으로 수동 계산 | 시스템 자동 계산 및 검증 |
| 소요 시간 | 매월 말 3영업일 소요 | 실시간 확인 및 1시간 내 마감 |
| 정확도 | 휴먼 에러 발생 가능성 높음 | 데이터 무결성 보장 및 오류 제로화 |
7. 실제 작성 사례 (Case Study)
실무에서 활용 가능한 문제 정의서의 구체적인 사례이다.
[사례: 이커머스 장바구니 이탈률 개선]
* 현상: 장바구니에 상품을 담은 사용자의 60%가 결제 단계로 진입하지 않고 이탈함.
* 분석 (5 Whys):
* 이탈률이 높다 $\rightarrow$ 결제 진입 버튼을 찾기 어렵다 $\rightarrow$ 장바구니 페이지의 정보량이 너무 많아 버튼이 하단에 밀려 있다 $\rightarrow$ 상품 상세 정보와 배송 안내가 과도하게 노출되고 있다 $\rightarrow$ 사용자에게 꼭 필요한 정보의 우선순위 설계가 되어 있지 않다.
* 문제 정의: "구매 의사가 있는 사용자가 장바구니 페이지의 과도한 정보 노출로 인해 결제 버튼을 즉시 찾지 못하고 있으며, 이로 인해 최종 구매 전환율이 저하되고 있다. 따라서 핵심 정보 중심으로 화면을 재구성하여 결제 진입 경로를 최적화해야 한다."
* 범위 설정:
* In-Scope: 장바구니 페이지 레이아웃 개편, 결제 버튼 플로팅(Floating) 처리.
* Out-of-Scope: 결제 수단 추가, 장바구니 상품 추천 알고리즘 개선.
* 성공 지표: 장바구니 $\rightarrow$ 결제 진입 전환율 15% 향상.
8. 좋은 문제 정의의 기준 (Checklist)
작성된 문제 정의가 적절한지 검증하기 위해 다음 체크리스트를 활용한다.
- [ ] 구체성: '시스템이 느리다'와 같은 모호한 표현 대신 '평균 응답 시간이 3초 이상 소요된다'와 같이 구체적으로 기술하였는가?
- [ ] 측정 가능성: 문제 해결 여부를 판단할 수 있는 정량적 지표(KPI)가 포함되어 있는가?
- [ ] 범위의 적절성: 해결 가능한 범위(Scope)로 정의되었는가? (예: '전 세계의 빈곤 해결' $\rightarrow$ '특정 지역의 식량 배급 효율화')
- [ ] 근본 원인 중심: 단순한 증상(Symptom)이 아니라 그 원인이 되는 핵심 문제(Root Cause)를 짚어냈는가?
- [ ] 이해관계자 합의: 해당 정의에 대해 실제 사용자 및 의사결정권자가 동의하였는가?
# 문제 정의 (Problem Definition)
## 1. 개요
> **문제 정의**란 해결해야 할 대상이 되는 현상의 본질을 명확히 규명하고, 달성하고자 하는 목표 상태를 구체적으로 기술하는 과정이다.
소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle)의 최상위 단계인 요구사항 분석의 출발점으로, '무엇을(What)' 개발할 것인가를 결정하기 전 '왜(Why)' 이 개발이 필요한지를 정의하는 핵심 활동이다.
## 2. 문제 정의의 필요성 및 목적
명확한 문제 정의 없이 개발에 착수할 경우, 기술적 구현에만 매몰되어 실제 사용자의 고통(Pain Point)을 해결하지 못하는 결과물이 나올 가능성이 높다.
### 2.1. 정의 부재 시 발생하는 리스크
* **범위 확장(Scope Creep):** 문제의 경계가 불분명하여 개발 과정 중 지속적으로 새로운 요구사항이 추가되어 프로젝트 일정이 지연된다.
* **비용 및 자원 낭비:** 잘못된 문제 정의로 인해 엉뚱한 기능을 구현하게 되며, 이는 전면적인 재작업(Rework)으로 이어져 비용을 증가시킨다.
* **잘못된 솔루션 도출:** 현상이 아닌 증상(Symptom)만을 해결하려 하여, 근본 원인이 제거되지 않은 임시방편적 시스템이 구축된다.
### 2.2. 기대 효과
* **이해관계자 간 합의:** 고객, 기획자, 개발자가 동일한 문제 의식을 공유함으로써 커뮤니케이션 비용을 절감한다.
* **우선순위 설정:** 문제의 심각도와 영향도를 분석하여 가장 시급하게 해결해야 할 핵심 기능(Core Feature)을 식별할 수 있다.
* **성공 지표 설정:** 문제 정의가 명확하면 솔루션 도입 후 개선 여부를 측정할 수 있는 정량적 지표(KPI) 설정이 가능해진다.
## 3. 문제 정의 프로세스
문제 정의는 단순히 현상을 기록하는 것이 아니라, 논리적인 추론 과정을 통해 구체화하는 절차를 거친다.
| 단계 | 주요 활동 | 입력물 (Input) | 출력물 (Output) |
| :--- | :--- | :--- | :--- |
| **현상 파악** | 사용자 불만 사항 수집, 로그 분석, 인터뷰 | VOC, 에러 로그, 시장 조사서 | 현상 기술서 (Observation Log) |
| **근본 원인 분석** | 현상의 배후에 있는 진짜 이유 탐색 | 현상 기술서, 도메인 지식 | 원인 분석 보고서 (Root Cause) |
| **목표 설정** | 해결 후 도달해야 할 이상적인 상태 정의 | 원인 분석 보고서 | 목표 상태 정의서 (To-Be Model) |
| **제약 조건 확인** | 예산, 기간, 기술적 한계, 법적 규제 검토 | 프로젝트 헌장, 인프라 현황 | 제약 사항 목록 (Constraints) |
## 4. 범위 설정 (Scoping)
문제 정의 단계에서 무엇을 해결할 것인가만큼 중요한 것이 **'무엇을 해결하지 않을 것인가'**를 명확히 하는 것이다. 이를 통해 프로젝트의 집중도를 높이고 범위 확장(Scope Creep)을 방지할 수 있다.
* **In-Scope (해결 범위):** 이번 프로젝트를 통해 반드시 해결해야 할 핵심 문제와 기능.
* **Out-of-Scope (제외 범위):** 관련이 있어 보이지만 이번 단계에서는 다루지 않기로 합의한 사항.
* **예시:** '결제 프로세스 이탈률 감소'가 목표일 때
* **In-Scope:** 결제 단계의 UI/UX 간소화, 결제 오류 메시지 구체화.
* **Out-of-Scope:** 새로운 결제 수단(예: 가상화폐) 추가, 포인트 적립 시스템 전면 개편.
## 5. 문제 정의를 위한 분석 기법
문제의 복잡도와 성격에 따라 적절한 분석 도구를 선택하여 사용한다.
### 5.1. 핵심 분석 기법 및 적용 예시
* **5 Whys:** "왜?"라는 질문을 반복하여 표면적인 현상 너머의 근본 원인을 찾는 기법이다.
* *적용 예시:* "결제 오류가 발생한다" $\rightarrow$ (왜?) "DB 연결 시간이 초과되었다" $\rightarrow$ (왜?) "쿼리 최적화가 안 되어 있다" $\rightarrow$ (왜?) "대량의 데이터를 풀 스캔(Full Scan)하고 있다" $\rightarrow$ (왜?) "적절한 인덱스 설계가 누락되었다" $\rightarrow$ (왜?) "초기 설계 리뷰 단계가 생략되었다" (근본 원인: 프로세스 부재)
* **로직 트리 (Logic Tree):** 문제를 논리적인 계층 구조로 분해하여 전체적인 구조를 파악하고 누락 없이 분석하는 기법이다.
* *적용 예시:* '매출 감소'라는 최상위 문제를 [신규 고객 유입 감소], [기존 고객 유지율 하락], [객단가 하락]으로 1차 분해하고, 다시 각 항목을 세부 원인으로 쪼개어 분석한다.
* **피시본 다이어그램 (Ishikawa):** 결과(문제)를 머리 부분에 두고, 원인을 카테고리별(사람, 방법, 기계, 재료 등)로 가지를 쳐서 시각화하는 기법이다.
* *적용 예시:* '앱 이탈률 증가'라는 문제를 중심에 두고 [UI/UX], [네트워크 성능], [콘텐츠 부족], [마케팅 타겟팅 오류] 등의 가지를 뻗어 원인을 분석할 때 사용한다.
* **MECE 원칙 (Mutually Exclusive, Collectively Exhaustive):** 항목들이 서로 중복되지 않으면서도 전체적으로 누락이 없는 상태로 분류하는 논리적 사고 방식이다.
* *적용 예시:* 사용자 층을 분석할 때 '10대, 20대, 30대...'와 같이 연령별로 나누어 누락과 중복 없이 전체 사용자군을 분석하는 경우이다.
* **사용자 스토리 맵 (User Story Map):** 사용자의 여정(Journey)을 시간 순서대로 나열하고, 각 단계에서 겪는 문제와 필요한 기능을 매핑하는 기법이다.
* *적용 예시:* 쇼핑몰 앱의 '상품 검색 $\rightarrow$ 장바구니 $\rightarrow$ 결제' 과정 중 어느 지점에서 사용자가 가장 큰 불편을 느끼는지 시각화할 때 사용한다.
## 6. 문제 정의서 작성 가이드
문제 정의서는 이해관계자 간의 공식적인 합의 문서 역할을 하며, 객관적이고 측정 가능한 언어로 작성되어야 한다.
### 6.1. 문제 정의 vs 요구사항 정의
많은 이들이 두 개념을 혼동하지만, 논리적 선후 관계가 명확히 다르다.
| 구분 | 문제 정의 (Problem Definition) | 요구사항 정의 (Requirement Definition) |
| :--- | :--- | :--- |
| **관점** | **Why & What** (왜 해결해야 하는가?) | **How** (어떻게 해결할 것인가?) |
| **초점** | 고통(Pain Point)과 결핍, 비효율성 | 기능(Feature), 성능, 제약 조건 |
| **예시** | "결제 과정이 너무 복잡해 구매 전환율이 낮다." | "간편 결제 API를 도입하고 단계를 3단계로 줄인다." |
| **순서** | 선행 단계 (분석의 시작) | 후행 단계 (설계의 기초) |
### 6.2. 작성 템플릿 및 예시
**[문제 정의 문장 템플릿]**
> "[대상/사용자]는 [특정 상황]에서 [어떤 문제]를 겪고 있으며, 이로 인해 [어떤 부정적 결과]가 발생하고 있다. 이를 해결하기 위해 [목표 상태]가 필요하다."
**[As-Is vs To-Be 비교 양식]**
```markdown
### [사례: 사내 근태 관리 시스템 개선]
1. 문제 정의:
인사팀 담당자는 매월 말 수동으로 엑셀 데이터를 취합하여 연차를 계산하고 있으며,
이 과정에서 데이터 입력 오류가 빈번하게 발생하여 급여 지급 지연 리스크가 존재한다.
2. 상태 비교:
| 구분 | As-Is (현재 상태) | To-Be (목표 상태) |
| :--- | :--- | :--- |
| 데이터 수집 | 각 팀별 엑셀 파일 개별 제출 | 시스템 내 실시간 신청 및 승인 |
| 계산 방식 | 담당자가 수식으로 수동 계산 | 시스템 자동 계산 및 검증 |
| 소요 시간 | 매월 말 3영업일 소요 | 실시간 확인 및 1시간 내 마감 |
| 정확도 | 휴먼 에러 발생 가능성 높음 | 데이터 무결성 보장 및 오류 제로화 |
```
## 7. 실제 작성 사례 (Case Study)
실무에서 활용 가능한 문제 정의서의 구체적인 사례이다.
**[사례: 이커머스 장바구니 이탈률 개선]**
* **현상:** 장바구니에 상품을 담은 사용자의 60%가 결제 단계로 진입하지 않고 이탈함.
* **분석 (5 Whys):**
* 이탈률이 높다 $\rightarrow$ 결제 진입 버튼을 찾기 어렵다 $\rightarrow$ 장바구니 페이지의 정보량이 너무 많아 버튼이 하단에 밀려 있다 $\rightarrow$ 상품 상세 정보와 배송 안내가 과도하게 노출되고 있다 $\rightarrow$ 사용자에게 꼭 필요한 정보의 우선순위 설계가 되어 있지 않다.
* **문제 정의:** "구매 의사가 있는 사용자가 장바구니 페이지의 과도한 정보 노출로 인해 결제 버튼을 즉시 찾지 못하고 있으며, 이로 인해 최종 구매 전환율이 저하되고 있다. 따라서 핵심 정보 중심으로 화면을 재구성하여 결제 진입 경로를 최적화해야 한다."
* **범위 설정:**
* **In-Scope:** 장바구니 페이지 레이아웃 개편, 결제 버튼 플로팅(Floating) 처리.
* **Out-of-Scope:** 결제 수단 추가, 장바구니 상품 추천 알고리즘 개선.
* **성공 지표:** 장바구니 $\rightarrow$ 결제 진입 전환율 15% 향상.
## 8. 좋은 문제 정의의 기준 (Checklist)
작성된 문제 정의가 적절한지 검증하기 위해 다음 체크리스트를 활용한다.
- [ ] **구체성:** '시스템이 느리다'와 같은 모호한 표현 대신 '평균 응답 시간이 3초 이상 소요된다'와 같이 구체적으로 기술하였는가?
- [ ] **측정 가능성:** 문제 해결 여부를 판단할 수 있는 정량적 지표(KPI)가 포함되어 있는가?
- [ ] **범위의 적절성:** 해결 가능한 범위(Scope)로 정의되었는가? (예: '전 세계의 빈곤 해결' $\rightarrow$ '특정 지역의 식량 배급 효율화')
- [ ] **근본 원인 중심:** 단순한 증상(Symptom)이 아니라 그 원인이 되는 핵심 문제(Root Cause)를 짚어냈는가?
- [ ] **이해관계자 합의:** 해당 정의에 대해 실제 사용자 및 의사결정권자가 동의하였는가?