---
title: "4장. 문제를 정의한다"
description: "받은 기능 요청을 곧바로 해법으로 확정하지 않고 관찰된 증상, 문제, 원인 가설과 측정 가능한 목표로 되돌린다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
해결책을 고르기 전에 실제 문제와 성공 기준을 어떻게 정의하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “해결책을 고르기 전에 실제 문제와 성공 기준을 어떻게 정의하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
현장에서 받은 요청은 대개 해결책의 모양을 하고 있다. “신청 화면을 빠르게 바꿔 달라”는 말만 따라가면 정작 사용자가 겪는 손실이 무엇인지, 화면 밖의 정책이나 운영 절차가 원인인지 확인하지 못한 채 설계를 시작하게 된다. 요구사항 활동은 요청을 거절하는 일이 아니라 그 요청이 겨냥한 문제를 더 정확히 찾는 일이다.
이 장에서는 관찰된 증상과 해결해야 할 문제, 아직 확인되지 않은 원인 가설, 측정 가능한 목표를 구분한다. 대학 수강신청 사례를 이용해 반복 제출과 수동 재처리라는 현상을 문제 구조로 바꾸고, 성급한 해법 고정을 피하면서 다음 조사와 의사결정에 필요한 증거를 정리한다.
### 1. 요청받은 기능부터 시작하면 안 되는 이유
“서버를 늘려 주세요.” 수강신청이 시작된 날 접속 지연과 민원이 쏟아지자 가장 먼저 나온 요청이다. 곧바로 서버 수량과 사양을 정하면 일이 분명해 보인다. 그러나 서버 증설은 확인된 요구사항이 아니라 문제를 해결할 수 있다는 **해결 가설**이다. 병목이 외부 학사 규칙 서비스에 있거나, 결과를 기다리지 못한 학생의 반복 클릭이 요청을 증폭시키거나, 정원 조정 절차 때문에 교무 담당자가 신청을 수동으로 되돌리는 것이 핵심이라면 서버만 늘려도 문제는 남는다.
기능 요청에는 제안자의 경험과 이해관계가 압축되어 있다. 그러므로 요청을 무시할 것이 아니라 원문, 제안자, 제안 시각, 기대 효과를 보존한 채 한 단계 뒤로 물러서야 한다. “이 기능이 없다면 누구에게 어떤 바람직하지 않은 결과가 생기는가?”, “그 결과를 보여 주는 기록은 무엇인가?”, “같은 결과를 줄일 다른 방법이 있는가?”를 묻는다. 답이 없으면 기능을 폐기하는 것이 아니라 아직 검증하지 않은 후보로 둔다.
[IIBA의 2025년판 Business Analysis Standard](https://production.iiba.org/globalassets/business-analysis-resources/the-business-analysis-standard/files/the-business-analysis-standard.pdf)는 현행 상태 분석의 목적을 조직이 왜 운영 방식을 바꿔야 하는지와 변화가 어디에 영향을 주는지를 이해하는 데 둔다. 표준이 특정 템플릿을 강제한다는 뜻은 아니다. 이 책에서는 그 취지를 실무 판단으로 바꾸어, 기능 후보보다 문제 증거를 먼저 기록한다.
| 받은 말 | 즉시 확정하지 않을 것 | 먼저 확인할 최소 증거 |
|---|---|---|
| 서버를 두 배로 늘린다 | 서버 수량·구성 | 구간별 응답시간, 자원 사용률, 외부 연계 대기시간 |
| 새로 고침 버튼을 없앤다 | 화면 동작 | 반복 요청 비율, 학생이 재시도한 이유, 처리 상태 표시 |
| 모든 신청을 선착순으로 한다 | 배정 정책 | 학칙, 우선 배정 근거, 정책 소유자, 이의 처리 기록 |
판단 기준은 간단하다. 문장이 구현 대상을 가리키지만 영향을 받는 사람, 바람직하지 않은 결과와 관찰 증거를 설명하지 못하면 문제 정의가 아니라 해결 후보다.
### 2. 문제와 증상의 구분
증상은 관찰된 바람직하지 않은 현상이고, 문제는 그 현상과 목표 사이의 차이를 만들어 내는 상황이다. 원인은 차이를 일으키거나 키우는 요인이다. “첫 10분간 화면이 멈춘다”는 증상이고, “학생이 신청 결과를 알 수 없어 반복 제출하고 교무처가 중복·불명확 상태를 수동 복구한다”는 문제 후보이며, 상태 조회 지연이나 비멱등 요청 처리는 원인 가설이다. 조사 전에 하나를 ‘근본 원인’이라고 부르면 다른 경로를 닫아 버린다.
같은 사실도 분석 수준에 따라 역할이 달라진다. 학생의 반복 클릭은 운영팀에게는 트래픽 증가의 원인이지만 학생에게는 결과가 보이지 않는 문제의 증상이다. 수동 재처리는 잘못된 판정의 결과이면서 업무 규칙과 시스템 상태가 어긋났음을 보여 주는 증상이다. 따라서 문제 기록에는 `관찰 사실`, `해석`, `원인 가설`을 분리한다.
수강신청 사례의 초안은 다음처럼 고친다.
> 나쁜 초안: 접속자가 많아 서버가 느리므로 서버를 증설해야 한다.
> 수정한 문제 후보: 수강신청 시작 직후 일부 학생은 신청 처리 상태와 거절 이유를 정해진 시간 안에 확인하지 못한다. 그 결과 반복 제출과 문의가 발생하고, 교무 담당자는 중복 또는 미확정 신청을 수동으로 판별·재처리한다. 발생 규모와 원인별 기여도는 운영 기록으로 확인한다.
수정문은 원인을 단정하지 않으면서 대상, 상황, 관찰 결과와 영향을 담는다. `QR-001`의 2초 기준은 목표 후보이지 현행 사실이 아니고, `BR-001`의 50% 감소 역시 이 책의 관통 사례를 위한 가정값이다. 실제 프로젝트에서는 직전 학기의 로그·민원·정정 기록이 기준선을 뒷받침해야 한다.
### 3. 현재 상태 분석
현재 상태는 “낡은 시스템” 같은 평가가 아니라 변화 직전의 업무가 실제로 어떻게 수행되고 어떤 성과를 내는지에 대한 근거 있는 설명이다. 입력은 운영 지표, 장애 기록, 문의와 정정 내역, 학칙과 업무 지침, 화면·인터페이스 동작, 담당자와 학생의 경험이다. 한 번의 인터뷰만으로 현행을 확정하지 않고 기록과 관찰을 교차 확인한다.
분석 순서는 네 단계면 충분하다. 첫째, 관찰 기간과 경계를 정한다. 이 사례에서는 본 신청 첫 30분과 이후 수동 복구 완료까지를 우선 본다. 둘째, 정상 흐름과 예외 흐름을 시간순으로 그린다. 셋째, 각 단계의 처리량·대기시간·오류·인계·수동 작업을 붙인다. 넷째, 사실의 출처와 확인 상태를 표시한다. 뒤에서 다룰 업무 프로세스도는 이 기록을 더 정교하게 만드는 수단이지 현재 상태 그 자체는 아니다.
| 관찰 항목 | 현재 상태 기록 예 | 상태 |
|---|---|---|
| 신청 결과 확인 | 처리 중 표시 없이 동일 화면에 머문다는 제보가 있음 | 학생 관찰 필요 |
| 반복 요청 | 동일 학생·강좌 조합의 단시간 요청 수 | 로그 집계 필요 |
| 수동 재처리 | 첫 30분 발생 건수와 건당 처리시간 | 교무 기록 확인 필요 |
| 규칙 연계 실패 | 응답 지연·오류·재시도·최종 상태 | 연계 로그 확인 필요 |
여기서 아직 모르는 값을 임의의 숫자로 채우지 않는다. “자료 없음”도 중요한 분석 결과다. 측정할 수 없다는 사실은 관측성 요구나 업무 기록 개선의 후보가 된다. 현재 상태 분석이 끝났다고 판단하려면 문제 진술의 각 표현을 뒷받침할 출처가 있고, 정상뿐 아니라 예외와 수작업이 보이며, 이해관계자가 이 설명을 현실과 대조할 수 있어야 한다.
### 4. 목표 상태 정의
목표 상태는 새 화면의 모습이 아니라 문제가 충분히 해소된 뒤 조직과 사용자가 경험해야 할 조건이다. [IIBA 표준의 미래 상태 정의](https://www.iiba.org/knowledgehub/the-business-analysis-standard/)는 비즈니스 필요를 충족하는 데 필요한 조건과 예상 가치를 밝히는 활동으로 제시된다. 따라서 “클라우드로 이전한다”보다 “신청 결과를 신뢰할 수 있고 수동 복구가 줄어든다”가 먼저 온다.
수강신청의 목표 상태를 관찰 가능한 말로 적으면 다음과 같다.
- 학생은 같은 신청을 반복하지 않고도 접수 여부, 처리 상태, 승인·거절·보류 결과와 이유를 확인한다.
- 교무 담당자는 판정에 사용한 규칙 버전과 사유를 조회하여 문의와 예외를 일관되게 처리한다.
- 학사 규칙 서비스가 제때 응답하지 않을 때 임의 승인하지 않고 보류와 복구 절차가 작동한다.
- 대학은 신청 첫 30분의 수동 재처리 규모가 기준선보다 의미 있게 줄었는지 확인할 수 있다.
첫째와 둘째는 `UR-001`과 `DR-001`, 셋째는 `IR-001`, 넷째는 `BR-001`로 이어진다. 그러나 API 구조, 데이터베이스 종류, 서버 대수는 아직 목표 상태에 넣지 않는다. 그것들은 목표를 달성하는 대안을 비교한 뒤 정할 설계다. 목표 상태의 완료 기준은 각 조건이 누구에게 가치를 주는지, 어떤 지표로 관찰할지, 현행과 무엇이 달라지는지 설명되는가이다.
### 5. 문제 정의
문제 정의서는 길기보다 검토 가능해야 한다. 이 책에서는 `대상과 상황 → 현재의 차이 → 영향 → 증거 → 미확정 원인` 순서를 권한다. 이는 저자의 실무 템플릿이지 표준 양식을 옮긴 것이 아니다. 해결책을 쓰고 싶다면 별도의 ‘해결 후보’ 칸에 둔다.
> **문제 정의 0.1**
> 수강신청 시작 직후 신청을 제출한 학생과 이를 지원하는 교무 담당자는 처리 상태와 판정 근거가 충분히 드러나지 않아 반복 요청, 문의, 수동 확인·재처리를 겪는다. 이 차이는 신청 첫 30분의 요청·상태 전이 로그, 문의 기록과 수동 정정 내역으로 규모를 확인한다. 집중 요청, 상태 표시, 업무 규칙, 외부 학사 연계와 운영 절차가 각각 얼마나 기여하는지는 아직 가설이다.
이 문장은 “학생들이 편하게 수강신청할 수 있어야 한다”는 최초 요청보다 좁고 분명하지만 최종 확정본은 아니다. 대상에서 교수나 학과 사무실이 빠졌는지, ‘충분히’가 어떤 기준인지, 수동 재처리가 정말 핵심 성과인지 5장과 6장에서 검토해야 한다. 좋은 문제 정의는 모든 답을 담는 문서가 아니라 조사해야 할 빈칸을 숨기지 않는 문서다.
검토자는 세 가지를 묻는다. 관찰 사실과 추정 원인이 구분되는가? 영향을 받는 주체와 결과가 드러나는가? 특정 해결책을 선택하지 않고도 여러 대안을 비교할 수 있는가? 하나라도 아니면 문제 문장을 다시 연다.
### 6. 목표 정의
목표는 문제와 목표 상태 사이에 방향과 우선순위를 세운다. “성능 개선”처럼 활동만 쓰면 무엇을 위해 어느 정도까지 바꿀지 알 수 없고, “응답시간 2초”만 쓰면 상위 가치가 사라진다. 목표는 보통 `대상 성과 + 변화 방향 + 기간 또는 판단 시점`으로 쓰고, 성공 기준이 수치를 담당하게 한다.
> **목표 `G-01`** 다음 학기 본 신청 운영에서 학생이 신청 결과를 알지 못해 발생하는 반복 제출과 교무처의 수동 재처리를 줄이고, 판정 결과를 설명하고 복구할 수 있는 운영 상태를 만든다.
`G-01`은 `BR-001`이 필요한 이유를 설명한다. `BR-001`은 “수강신청 시작 후 30분 동안 발생하는 수동 재처리 건수를 직전 학기 같은 기간 대비 50% 줄인다”는 비즈니스 요구사항 후보다. 반복 제출 감소가 수동 재처리 감소에 실제로 기여하는지, 50%가 현실적이며 가치가 있는지는 아직 검증해야 한다.
목표와 요구사항도 구분한다. 목표는 도달하려는 결과이고, `FR-001`처럼 “소프트웨어가 조건을 판정하고 결과를 반환해야 한다”는 문장은 이를 지원하는 시스템 행동이다. 한 기능이 목표에 기여하지 못하면 범위를 의심하고, 목표가 어떤 업무·시스템 변화로도 이어지지 않으면 선언에 그쳤는지 의심한다.
### 7. 성공 기준
성공 기준은 목표 달성 여부를 나중에 판정할 관찰 규칙이다. 출력물이 만들어졌는지가 아니라 문제가 얼마나 해소되었는지를 본다. 지표 이름만 두지 말고 정의, 기준선, 목표값, 관찰 구간, 데이터 출처, 계산법, 책임자와 부작용 방지 지표를 함께 기록한다.
| 기준 | 기준선 | 사례 목표 | 측정 방법과 주의점 |
|---|---|---|---|
| 첫 30분 수동 재처리 건수 | 직전 학기 동일 구간 확정값 | 50% 감소 (`BR-001`) | 재처리의 상태·유형을 먼저 통일한다 |
| 처리 상태 조회 응답시간 | 현행 부하 시험값 | 95백분위 2초 이하 (`QR-001`) | 시험 부하·데이터·측정 지점을 함께 고정한다 |
| 판정 설명 가능 비율 | 현행 기록 완전성 | 목표값 협의 필요 | `DR-001` 필드 완전성과 사유 코드 해석 가능성을 본다 |
| 잘못된 자동 승인 | 장애·예외 기록 | 허용 기준 협의 필요 | 속도 개선 때문에 `IR-001` 안전 원칙이 훼손되지 않는지 본다 |
여기서 50%와 2초는 관통 사례를 위한 **가정된 목표값**이다. 팀은 실제 기준선과 학생 기대, 예산, 운영 위험을 확인해 채택·수정·폐기해야 한다. 평균 응답시간만 좋아졌지만 일부 학생이 계속 오래 기다리는 경우처럼, 하나의 지표는 문제를 가릴 수 있다. 그래서 백분위, 오류율, 재시도율, 문의와 잘못된 승인 등 균형 지표를 함께 본다.
좋은 성공 기준은 특정 기술을 사지 않아도 측정할 수 있고, 목표와 연결되며, 데이터를 얻을 책임자가 있다. 숫자가 정교해 보여도 출처와 계산법이 없으면 합의가 아니라 장식이다.
### 8. 가정과 제약
가정은 참이라고 임시로 믿고 진행하지만 확인 결과에 따라 계획이 바뀔 수 있는 명제다. 제약은 선택 가능한 해법을 제한하는 결정·조건이다. “신청 집중이 주된 병목이다”는 가정이고, “다음 학기 개강 전 정해진 운영 창에 전환해야 한다”는 일정 제약일 수 있다. “기존 학사 규칙 서비스를 반드시 그대로 사용한다”는 말은 계약이나 조직 결정이 확인되면 제약이지만, 단지 익숙해서 나온 말이면 설계 선호다.
| ID | 구분 | 내용 | 근거·소유자 | 다음 조치 |
|---|---|---|---|---|
| `ASM-001` | 가정 | 반복 제출이 수동 재처리 증가에 유의미하게 기여한다 | 운영팀 가설 | 요청·상태 전이 로그 분석 |
| `ASM-004` | 가정 | 직전 학기 첫 30분 자료가 비교 가능한 기준선이다 | 교무처 가설 | 정책·인원·강좌 수 차이 보정 |
| `CON-001` | 제약 후보 | 적용 중인 학칙의 승인·우선순위 규칙을 준수한다 | 교무 규정 소유자 | 조항·시행일 확인 |
| `CON-002` | 제약 후보 | 기존 통합인증과 학사 연계를 사용한다 | IT 책임자 | 계약·변경 가능 범위 확인 |
가정에는 확인 날짜와 틀렸을 때의 영향을, 제약에는 출처·소유자·변경 권한을 붙인다. 확인할 수 없는 제약은 영구 사실처럼 취급하지 않는다. 가정이 틀렸다고 밝혀지는 것은 분석 실패가 아니다. 가정을 기록하지 않아 틀린 전제를 계속 사용하는 것이 실패다.
### 9. 위험
위험은 아직 발생하지 않았지만 목표 달성에 좋지 않은 영향을 줄 수 있는 불확실한 사건이나 조건이다. 이미 발생한 지연은 이슈이고, 다음 학기에 외부 학사 서비스 지연이 반복되어 보류가 급증할 가능성은 위험이다. 원인 가설과도 다르다. 가설은 현상을 설명하려는 명제이고, 위험은 앞으로의 결과와 대응 결정을 다룬다.
[IIBA 표준](https://production.iiba.org/globalassets/business-analysis-resources/the-business-analysis-standard/files/the-business-analysis-standard.pdf)은 미래 상태로 이동하거나 그 상태를 운영할 때 내부·외부 요인이 초래할 바람직하지 않은 결과를 이해하고 대응 경로를 권고하는 활동을 위험 분석으로 설명한다. 이 사례에서는 다음과 같이 기록할 수 있다.
| 위험 사건 | 영향 | 조기 신호 | 대응 방향 | 책임 후보 |
|---|---|---|---|---|
| 학사 규칙 연계가 집중 시간에 지연됨 | 보류 증가, 학생 재시도 | 연계 지연과 보류율 상승 | 임의 승인 금지, 상태 안내·복구 절차 검토 | 학사 연계·운영팀 |
| 규칙 버전이 부서마다 다르게 해석됨 | 판정 불일치, 이의 증가 | 같은 조건의 상이한 결과 | 규칙 소유자와 시행일·버전 단일화 | 교무처 |
| 속도 지표만 최적화함 | 오류 또는 불공정 승인 | 응답 개선과 정정 증가 동시 발생 | 정확성·공정성 방지 지표 병행 | 사업 책임자 |
| 장애학생의 시간 제한·인증 경험을 늦게 발견함 | 신청 기회 불평등 | 보조기술 시험 실패·민원 | 당사자 참여와 접근성 기준 조기 확인 | 지원센터·제품팀 |
확률과 영향을 숫자로 매기는 일보다 사건이 어느 목표와 요구에 영향을 주는지, 누가 감시하고 언제 대응을 결정할지가 먼저다. 위험 목록이 단순 불안 목록이 아니라 범위와 도출 우선순위를 바꾸어야 쓸모가 있다.
### 10. 범위의 시작
범위는 처음부터 완성된 기능 목록이 아니다. 문제와 목표를 해결하기 위해 조사하고 바꿀 수 있는 영역, 외부에 있지만 영향을 주고받는 영역, 이번 변화에서 다루지 않을 영역을 잠정적으로 긋는 일에서 시작한다. [IREB 온라인 용어집](https://cpre.ireb.org/en/downloads-and-resources/glossary)은 시스템 경계와 맥락 경계를 구분하며, 시스템 밖이라도 요구사항 이해에 관련된 환경은 맥락에 포함될 수 있음을 설명한다. 따라서 외부 학사 서비스가 개발 대상이 아니어도 응답·오류·책임 경계는 분석 범위에 들어간다.
수강신청 문제의 초기 범위를 다음처럼 표현할 수 있다.
- **우선 조사·변경 범위:** 강좌 탐색과 신청 제출, 자격·선수과목·시간표·학점·정원·우선순위 판정, 처리 상태와 사유 제공, 판정 기록, 보류와 복구 업무.
- **맥락 및 인터페이스 범위:** 통합인증, 학적·성적·교과 정보, 알림, 교무처·학과의 정원 조정과 예외 승인, 운영 감시와 문의 처리.
- **초기 제외 후보:** 강의계획서 저작 도구, 등록금 결제 전반, 성적 산정 자체. 다만 신청 자격이나 상태에 영향을 주는 접점은 제외하지 않는다.
- **미결정:** 서버 증설, 대기열, 캐시, 화면 구조와 같은 해결 방식.
이 초기 범위는 5장의 업무 분석과 6장의 이해관계자 검토를 거치며 바뀐다. 범위 밖이라고 적은 항목도 근거와 재검토 조건을 남긴다. `BR-001`` → ``UR-001`` → ``SR-001`` → ``FR-001``·``QR-001``·``DR-001``·``IR-001`의 연결이 문제·목표와 맞는지, 빠진 업무 변화가 없는지가 다음 판단 기준이다.
이 장에서 정리한 결과는 문제 정의 0.1, 현행·목표 비교, 성공 기준, 가정·제약·위험 목록과 초기 범위다. 이제 문제를 설명하는 문장만으로는 부족하다. 다음 장에서는 수강편람 등록부터 폐강까지 실제 업무가 어떻게 움직이고, 어떤 규칙·데이터·조직·외부 시스템이 이 문제를 만들거나 해결하는지 확인한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 4장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
받은 기능 요청을 곧바로 해법으로 확정하지 않고 관찰된 증상, 문제, 원인 가설과 측정 가능한 목표로 되돌린다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.