---
title: "20장. 모델로 표현하는 요구사항"
description: "컨텍스트·상태·시퀀스·데이터·결정 모델을 목적에 맞게 선택하고 모델 사이의 모순과 미결정 정책을 찾는다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
복잡한 요구를 문장만으로 검토하면 상태 변화와 시간 순서, 데이터 관계, 결정 규칙의 모순을 놓치기 쉽다. 모든 내용을 하나의 거대한 그림에 담으려 해도 독자가 필요한 질문에 답하기 어렵다. 모델은 현실을 장식하는 그림이 아니라 특정 불확실성을 검사하는 관점이다.
이 장에서는 컨텍스트·상태·시퀀스·데이터·결정 모델을 질문에 맞춰 선택하는 기준을 설명한다. 수강신청 사례를 여러 모델로 표현하고 모델 사이의 일관성을 대조해, 숨은 요구와 미결정 정책, 인터페이스 책임을 발견하는 과정을 살펴본다.
### 1. 컨텍스트 모델
자연어 요구는 한 의무를 읽기 쉽게 하고, 유스케이스는 한 목표의 흐름을 묶으며, 스토리 지도는 전달 순서를 보여 줬다. 그러나 시스템 경계, 상태 전이, 데이터 관계, 규칙 조합처럼 여러 요소의 관계를 한꺼번에 대조하려면 모델이 유용하다. 모델은 현실의 일부를 특정 질문에 답하도록 의도적으로 단순화한 표현이다. 현실 전체를 한 그림에 담으려 하면 읽을 수 없는 종합도가 된다.
컨텍스트 모델은 관심 시스템의 경계와 외부 사람·시스템·환경, 주고받는 책임을 보여 준다. 첫 질문은 “무엇을 만들 것인가”보다 “무엇이 우리 책임 안이고 밖인가”다.
이 모델에서 화살표는 구현 프로토콜이 아니라 교환되는 업무 책임과 정보의 방향을 나타낸다. 규칙 서비스가 제품 내부라면 경계 안으로 옮겨야 한다. 학사 정책은 문서일 수도, 정책 결정 조직일 수도 있으므로 구체적인 권한 출처와 제공 방식을 별도 기록한다.
컨텍스트 모델로 다음 결함을 찾는다.
- `ASM-002`: 규칙 서비스가 `DR-001`에 필요한 규칙 버전을 실제 제공하는가?
- 통지 실패 때 학생이 결과를 조회할 책임은 어느 경계에 남는가?
- 교무 운영 담당자가 보류·정정할 권한과 감사 책임을 갖는가?
- 학생의 학적 데이터는 어디가 원천이며 누가 정정하는가?
- 외부 연계를 사용할 수 없어도 시스템이 지켜야 할 최소 보장은 무엇인가?
모델 선택의 기준을 먼저 정리한다.
| 알고 싶은 질문 | 우선 모델 | 잘 보이지 않는 정보 |
|---|---|---|
| 경계 밖의 누구와 무엇을 주고받는가 | 컨텍스트 | 내부 순서·상태 |
| 누가 어떤 업무를 어떤 순서로 하는가 | 프로세스·BPMN | 데이터 구조·세부 규칙 |
| 정보가 어디서 와서 어떻게 변하는가 | 데이터 흐름 | 시간 순서·상태 생명주기 |
| 어떤 상태와 전이가 허용되는가 | 상태 | 참여자별 메시지 순서 |
| 한 시나리오의 상호작용 순서는 무엇인가 | 시퀀스 | 모든 규칙 조합 |
| 어떤 정보가 어떤 관계와 제약을 갖는가 | 데이터·도메인 | 동적 행동 |
| 조건 조합이 어느 결과를 만드는가 | 결정표·결정 트리 | 사용자 목표·복구 흐름 |
| 역할별 무엇을 할 수 있는가 | 권한 행렬 | 업무 단계·화면 이동 |
| 사용자가 어느 화면으로 이동하는가 | 화면 흐름 | 업무 규칙·시스템 경계 |
한 모델이 다른 모델을 대체하지 않는다. 모델 간 같은 개념·상태·규칙 ID를 연결해 모순을 찾는 데 가치가 있다.
### 2. 업무 프로세스 모델
업무 프로세스 모델은 목표를 이루기 위해 사람과 시스템이 수행하는 활동, 책임, 분기와 시작·종료를 보여 준다. 현재 업무를 이해하는 `As-Is`와 바뀔 업무를 합의하는 `To-Be`를 구분한다. 둘을 섞으면 기존 수동 보완을 새 시스템 책임으로 착각하거나, 개선하려던 낭비를 그대로 자동화할 수 있다.
수강신청의 To-Be 후보를 책임별로 펼친다.
이 흐름은 18장의 `UC-REG-01`과 비슷해 보이지만 관점이 다르다. 유스케이스는 학생 목표와 시스템 반응에 집중하고, 프로세스 모델은 조직 간 책임과 업무 인계를 보여 준다. 보류가 발생했을 때 운영 담당자가 실제로 받는 작업 목록, 처리 기한, 에스컬레이션과 학생 안내가 있는지 질문할 수 있다.
각 활동에는 입력·출력·수행 역할·적용 규칙·완료 기준을 붙인다. “신청 처리”처럼 넓은 상자는 규칙 평가, 결과 기록, 상태 제공으로 나누되 내부 코드 함수까지 내려가지 않는다. 자동화 전후의 시간·대기·재작업을 측정하면 `BR-001`의 수동 재처리 감소 가설을 검증할 기준도 마련된다.
### 3. BPMN
BPMN(Business Process Model and Notation)은 이벤트, 활동, 게이트웨이, 흐름, 참여자 풀·레인으로 업무 프로세스를 표현하는 표준 표기다. [OMG BPMN 2.0.2](https://www.omg.org/spec/BPMN/2.0.2/)가 2026년 현재 OMG 카탈로그의 공식 판본이다. 모든 기호를 쓰기보다 이해관계자가 검토할 질문에 필요한 최소 집합을 사용한다.
수강신청 흐름을 BPMN 개념으로 텍스트화하면 다음과 같다.
게이트웨이의 질문은 분기 조건을 완전하고 상호 배타적으로 정의해야 한다. `판정 불가`를 `규칙 미통과`와 같은 아니오로 합치면 보류가 거절로 사라진다. 승인·정원 반영·기록이 하나의 트랜잭션처럼 그려졌어도 실제 원자성과 실패 복구는 별도 요구·설계로 확인해야 한다.
참여자 사이의 메시지 흐름과 한 참여자 내부의 순서 흐름도 구분한다. 규칙 서비스 응답은 메시지이며 학생의 신청 상태 전이는 수강신청 시스템 내부 업무 결과다. 표기 정확성에 집착해 도메인 검토자가 읽지 못한다면 단순 프로세스 그림과 함께 제공한다.
### 4. 데이터 흐름
데이터 흐름 모델은 외부 주체, 처리, 데이터 저장소와 그 사이를 이동하는 정보에 초점을 둔다. BPMN이 누가 언제 무엇을 하는지 묻는다면 데이터 흐름은 “어떤 정보가 어디서 와서 어떤 결과로 바뀌는가”를 묻는다.
데이터 흐름마다 의미·형식·기준 시점·품질·보호 수준을 정의한다. `학적·이수`가 현재 값인지 신청 시점 스냅샷인지, `규칙·버전`이 실제 발효된 정책을 식별하는지, 상태·사유에서 다른 학생 정보가 제거되는지 확인한다.
이 모델은 `DR-001`의 기록 필드를 도출하지만 상태 전이 순서를 보여 주지는 않는다. 저장소를 그렸다고 데이터베이스 제품을 선택한 것도 아니다. 논리적 정보 보존 책임을 표현하며, 구현 저장 구조는 설계에서 결정한다. 또한 처리 1번을 거대한 상자로 남기지 않고 입력이 결과로 변하는 규칙을 결정표·상태 모델과 연결한다.
### 5. 상태 모델
상태 모델은 한 대상의 생명주기와 허용된 전이를 표현한다. 수강신청에서는 화면 상태가 아니라 `신청`이라는 업무 객체를 중심으로 한다. 상태는 진입 후 지켜야 할 불변식과 밖으로 나가는 사건이 달라질 때 구분할 가치가 있다.
이 모델만으로도 빠진 정책이 보인다. 보류의 종료 상태, 재평가 트리거, 취소 허용 여부가 미결정이다. `ASM-003`에 따라 보류가 좌석을 점유한다면 승인·취소·기한 만료 전이의 정원 효과가 모두 달라진다. 상태 이름을 확정하기 전에 정책을 확인한다.
상태별 불변식 후보를 둔다.
| 상태 | 반드시 참이어야 할 후보 | 금지할 결과 |
|---|---|---|
| 접수 | 요청 식별자와 수신 시각 존재 | 확정 승인으로 표시 |
| 판정 중 | 적용 기준을 결정 중 | 규칙 없이 승인 |
| 보류 | 원인과 재평가 가능성 기록 | 자동 승인, 근거 없는 종료 |
| 승인 | 일관된 좌석 반영과 판정 기록 | 정책상 정원 초과, 복수 최종 상태 |
| 거절 | 적용 사유와 비승인 결과 | 승인 좌석 점유 |
| 취소 | 취소 시각·주체·이전 상태 추적 | 허용되지 않은 재활성화 |
`판정 중`을 외부 사용자에게 보여 줄 업무 상태로 유지할지 아주 짧은 내부 처리 단계로 볼지도 결정해야 한다. 모델의 상태 수는 코드 enum 수가 아니라 업무 의미와 관찰 필요에 따라 정한다. [OMG SysML의 행동 모델 설명](https://www.omg.org/sysml/sysmlv1/)에서도 상태 기계는 객체의 생명주기와 사건에 따른 전이를 표현하는 행동 다이어그램으로 다룬다.
### 6. 시퀀스 모델
시퀀스 모델은 한 시나리오에서 참여자 사이 메시지와 시간 순서를 위에서 아래로 보여 준다. 유스케이스의 한 흐름을 상호작용 관점으로 확대하는 데 알맞다. 모든 가능한 조합을 한 그림에 넣지 말고 정상·핵심 예외를 나눈다.
두 모델을 비교하면 `IR-001`의 안전 결과와 정보 순서가 보인다. 학생에게 승인 결과를 보내기 전에 상태·정원·결정 기록이 어느 수준까지 일관되어야 하는지 질문할 수 있다. 기록 저장이 실패하면 승인을 되돌릴지, 별도 복구 상태로 둘지 아직 정해야 한다.
시퀀스의 화살표는 특정 API 호출을 확정하는 데 쓰지 않는다. 논리적 책임과 필수 순서를 먼저 합의하고 동기·비동기, 재시도, 타임아웃 구현은 품질·인터페이스 제약에 따라 설계한다. 여러 반복·대안이 많아지면 그림보다 유스케이스 분기와 결정표가 읽기 쉽다.
### 7. 데이터 모델
데이터 모델은 시스템이 관리해야 할 정보 구조, 식별자, 관계, 수량성과 무결성 규칙을 표현한다. `신청 결과를 기록한다`는 문장만으로 무엇을 한 묶음으로 유지해야 하는지 알 수 없을 때 유용하다.
이것은 논리 모델이다. 테이블 수나 저장소 제품을 정하지 않는다. `DR-001`의 학생·강좌 식별자, 요청 시각, 결과·사유, 규칙 버전, 최종 상태 변경이 어떤 관계로 보존되는지 확인한다. 하나의 신청에 여러 규칙 판정과 상태 변경이 있을 수 있어야 재평가를 재현할 수 있다.
무결성 후보는 다음과 같다.
- 신청은 정확히 한 학생과 한 강좌개설을 참조한다.
- 판정 결과는 사용한 규칙과 버전을 식별한다. `ASM-002` 확인 전에는 구현 확정이 아니다.
- 현재 상태는 상태 변경 이력과 모순되지 않는다.
- 동일 학생·강좌·학기의 유효 승인 중복은 정책이 허용하지 않는 범위에서 생성되지 않는다.
- 삭제·정정은 이력과 권한·보존 정책을 훼손하지 않는다.
데이터 모델은 사유 공개 범위나 업무 용어의 풍부한 의미를 모두 담지 못한다. 개인정보 등급, 원천, 보존 기간, 정정 책임과 함께 관리한다.
### 8. 도메인 모델
도메인 모델은 업무에서 중요한 개념과 관계·규칙을 기술 독립적인 언어로 정리한다. 데이터 모델이 저장·식별·수량성에 무게를 둔다면 도메인 모델은 사람들이 같은 말을 같은 뜻으로 쓰게 하는 데 무게를 둔다.
`강좌`와 `강좌개설`을 구분하면 같은 과목이 학기·분반별 정원과 일정이 다르다는 점을 표현할 수 있다. `요청`, `신청`, `승인`, `수강등록`도 동의어가 아닐 수 있다. 요청은 제출 사건, 신청은 생명주기 객체, 승인은 판정 결과, 수강등록은 학사 원장의 후속 상태일 수 있다. 실제 업무에서 확인해 용어집과 일치시킨다.
도메인 모델은 데이터베이스 스키마가 아니다. 모든 개념을 영속화하거나 클래스 하나로 구현할 필요가 없다. 반대로 구현에 이미 있는 테이블 이름을 그대로 옮기면 현행 설계의 오류와 약어가 업무 언어를 지배한다. 정책 담당자·학생 지원·개발·시험이 사례를 같은 개념으로 설명할 수 있는지 검토한다.
### 9. 결정표
결정표는 여러 조건 조합과 그 결과를 행·열로 나란히 놓아 누락·중복·모순을 찾는다. 수강신청처럼 선수과목, 학점, 시간 충돌, 정원, 우선순위가 함께 판정에 영향을 주면 자연어 `if` 문장보다 효과적이다.
먼저 단순화한 후보를 만든다. `Y`는 조건 충족, `N`은 미충족, `–`는 그 규칙에서 결과에 영향을 주지 않음을 뜻한다.
| 규칙 열 | `R1` | `R2` | `R3` | `R4` | `R5` | `R6` |
|---|---:|---:|---:|---:|---:|---:|
| 요청·기간 유효 | N | Y | Y | Y | Y | Y |
| 규칙 판정 가능 | – | N | Y | Y | Y | Y |
| 선수·학점·시간 규칙 모두 통과 | – | – | N | Y | Y | Y |
| 일반 가용 좌석 있음 | – | – | – | N | N | Y |
| 우선순위·별도 배정 조건 충족 | – | – | – | N | Y | – |
| **결과** | 비승인 | 보류 | 거절 | 거절/대기 미결정 | 승인 여부 미결정 | 승인 |
| **기록** | 입력·기간 사유 | 실패 원인·버전 상태 | 거절 규칙 | 정원 사유 | 배정 근거 | 승인 근거 |
`R4`와 `R5`는 일부러 미결정으로 남겼다. `RULE-005`가 예약 정원인지 배정 순서인지, `RULE-004`의 적용 정원을 바꿀 권한인지 확인되지 않았고 `ISS-001`이 열려 있기 때문이다. 결정표의 빈칸은 문서 결함이 아니라 필요한 정책 결정을 정직하게 표시한다. 임의로 `승인`을 채우면 모델이 잘못된 확실성을 만든다.
실제 표는 복수 실패 사유, 학생 유형, 예외 승인, 동률, 기준 시점까지 커질 수 있다. 조건을 독립적인 업무 사실로 정규화하고, 불가능한 조합을 표시하며, 각 열이 적어도 하나의 검증 사례로 이어지게 한다. 표가 폭발하면 정책을 계층화하거나 별도 결정 서비스 설계를 검토하되 추적성을 유지한다.
[OMG DMN 1.5](https://www.omg.org/spec/DMN/1.5/)는 2026년 현재 OMG 카탈로그의 공식 Decision Model and Notation 판이다. 모든 프로젝트가 DMN 도구를 쓸 필요는 없지만 조건·결론·적중 정책의 의미를 명시하는 원칙은 유용하다.
### 10. 결정 트리
결정 트리는 질문을 따라가며 하나의 결과에 도달하는 경로를 보여 준다. 상담·설명처럼 사람이 순차 질문을 따라야 할 때 읽기 쉽다.
같은 내용을 결정표와 트리로 모두 유지하면 중복 불일치가 생길 수 있다. 표를 기준 규칙 집합으로 두고 트리를 설명용 보기로 생성하거나, 어느 산출물을 기준으로 삼을지 정한다. 트리는 공통 조건이 여러 갈래에 반복되고 모든 조합이 있는지 확인하기 어렵다. 표는 완전성 검토에 강하고 트리는 한 사례를 설명하는 데 강하다.
학생에게 거절 사유를 설명할 때 내부 트리 순서를 그대로 노출하지 않는다. 공개 가능한 정책 언어와 다음 행동을 제공해야 하며, 복수 사유를 어느 범위까지 보여 줄지 승인한다. 결정 경로는 `DR-001`과 연결해 사후 재현이 가능해야 한다.
### 11. 권한 행렬
권한 행렬은 역할별로 어떤 대상에 어떤 행동을 어느 조건에서 할 수 있는지 대조한다. “관리자는 모든 것을 관리한다”는 문장을 분해하고 최소 권한·업무 분리·감사를 검토하게 한다.
| 역할 | 자신의 신청 조회 | 신청 제출 | 승인 신청 취소 | 보류 조사 | 판정 정정 | 규칙 변경 | 감사 이력 조회 |
|---|---|---|---|---|---|---|---|
| 학생 | 허용 | 기간·상태 조건부 | 정책 조건부 | 불가 | 불가 | 불가 | 자신의 공개 범위만 |
| 학생 지원 담당자 | 업무 범위 조건부 | 대리 신청 미결정 | 미결정 | 제한적 조회 | 불가 | 불가 | 마스킹된 범위 |
| 교무 운영 담당자 | 업무 범위 조건부 | 예외 권한 미결정 | 정책 조건부 | 허용 후보 | 이중 통제 후보 | 불가 | 담당 범위 |
| 정책 관리자 | 사례 조회 제한 | 불가 | 불가 | 정책 분석 범위 | 불가 또는 별도 승인 | 승인 절차 조건부 | 변경 관련 이력 |
| 감사 역할 | 읽기 전용 | 불가 | 불가 | 읽기 전용 | 불가 | 불가 | 승인된 전체 범위 |
`허용`만 적지 않고 데이터 범위, 객체 상태, 기간, 목적, 추가 승인과 기록 의무를 붙인다. 특히 판정 정정과 규칙 변경을 한 역할이 임의로 수행하면 사후 조작 위험이 있다. 실제 조직의 책임과 법·정책을 확인해 업무 분리와 이중 승인을 결정한다.
행렬은 인증 방법이나 화면 버튼을 정하지 않는다. 각 셀은 접근 제어 요구, 기록 요구와 오용 사례로 이어진다. 사용자가 자기 신청만 조회해야 한다는 데이터 범위는 ID를 바꾼 요청, 대리 역할, 지원 업무 사례로 검증한다.
### 12. 화면 흐름
화면 흐름은 사용자가 화면·페이지·대화 상태 사이를 이동하는 경로를 보여 준다. 정보 구조와 탐색 누락을 검토하는 데 유용하지만 업무 프로세스나 상태 모델을 대신하지 않는다. 화면에서 “승인” 페이지를 봤다고 승인 상태의 원자성과 규칙 판정이 증명되는 것은 아니다.
이 흐름은 19장의 스토리 지도와 닮았지만 화면을 중심으로 한다. 한 화면에서 여러 사용자 과업을 수행할 수도 있고, 채널에 따라 화면이 없을 수도 있다. 따라서 “검색→장바구니→신청”을 업무 규칙으로 고정하지 않는다. 장바구니에 넣는 것이 좌석 예약인지 단순 선택 목록인지도 모델 밖 정책으로 확인한다.
화면별로 사용자 목표, 필요한 정보, 가능한 행동, 진입·이탈 조건, 오류·빈 상태, 접근성과 권한을 연결한다. 결과 화면은 승인·거절·보류를 색만으로 구분하지 않고 상태 이름, 사유, 신청 식별자와 다음 행동을 인지 가능하게 제공해야 한다. 외부 알림의 링크로 진입해도 다른 학생의 신청을 열 수 없어야 한다.
6부의 네 장은 같은 수강신청 요구를 다른 질문으로 표현했다.
| 형식 | 가장 잘 답하는 질문 | 이 사례에서 드러낸 결함 | 단독 사용 시 잃는 정보 |
|---|---|---|---|
| 자연어 패턴 | 어느 조건에서 누가 무엇을 해야 하는가 | 모호한 기간·중복·실패 결과 | 전체 흐름·관계 |
| 유스케이스 | 목표가 어떻게 정상·대안·예외로 끝나는가 | 보류 복구·부분 실패·사후조건 | 복합 규칙·데이터 구조 |
| 스토리·백로그 | 무엇을 작은 가치 단위로 언제 전달할까 | 위험한 수평 분할·운영 가치 누락 | 상태 완전성·권한 |
| 모델 | 경계·순서·상태·데이터·결정은 어떻게 연결되는가 | `ASM-002`, `ASM-003`, `ISS-001`, 종료 상태 빈칸 | 목표 근거·상세 설명 |
중복되는 정보는 복사본으로 관리하지 않는다. `신청`, `보류`, `승인`의 정의는 도메인 용어집을 기준으로 하고, 상태 전이는 상태 모델, 조건 조합은 승인된 결정표, 의무·품질 기준은 요구 ID, 사용자 흐름은 유스케이스와 스토리 지도에 둔다. 각 산출물은 기준이 되는 정보를 참조하고 변경 시 영향 링크로 함께 검토한다.
[OMG 명세 카탈로그](https://www.omg.org/spec)는 UML 2.5.1, BPMN 2.0.2, DMN 1.5의 공식 상태와 판본을 확인할 수 있는 기준이다. [IREB Requirements Modeling 자료](https://cpre.ireb.org/en/downloads-and-resources/downloads)는 정보·기능·행동 관점의 모델을 요구사항 작업 산출물로 선택·결합하는 방법을 다룬다. 표준 기호를 정확히 쓰는 것은 중요하지만, 모델의 성공 기준은 이해관계자가 경계·누락·모순을 발견하고 승인된 요구·검증으로 연결할 수 있는가다.
이 장에서 정리한 결과는 모델 선택표, 컨텍스트와 업무 흐름, BPMN 개념 모델, 데이터 흐름, 상태·시퀀스·데이터·도메인 모델, 결정표·결정 트리, 권한 행렬과 화면 흐름이다. 이 모델들은 `RULE-004`, `RULE-005`와 `ISS-001`, 보류 생명주기와 `ASM-003`, 규칙 버전 `ASM-002`를 해결하지 않고 눈에 보이는 결정 대상으로 남겼다. 다음 부에서는 이렇게 표현한 요구를 우선순위·변경·추적·형상 관점에서 지속적으로 관리한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 20장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
컨텍스트·상태·시퀀스·데이터·결정 모델을 목적에 맞게 선택하고 모델 사이의 모순과 미결정 정책을 찾는다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.