20장. 모델로 표현하는 요구사항

컨텍스트·상태·시퀀스·데이터·결정 모델을 목적에 맞게 선택하고 모델 사이의 모순과 미결정 정책을 찾는다.

이번 장에서 해결할 질문

학습 목표

• “경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

복잡한 요구를 문장만으로 검토하면 상태 변화와 시간 순서, 데이터 관계, 결정 규칙의 모순을 놓치기 쉽다. 모든 내용을 하나의 거대한 그림에 담으려 해도 독자가 필요한 질문에 답하기 어렵다. 모델은 현실을 장식하는 그림이 아니라 특정 불확실성을 검사하는 관점이다.

이 장에서는 컨텍스트·상태·시퀀스·데이터·결정 모델을 질문에 맞춰 선택하는 기준을 설명한다. 수강신청 사례를 여러 모델로 표현하고 모델 사이의 일관성을 대조해, 숨은 요구와 미결정 정책, 인터페이스 책임을 발견하는 과정을 살펴본다.

1. 컨텍스트 모델

자연어 요구는 한 의무를 읽기 쉽게 하고, 유스케이스는 한 목표의 흐름을 묶으며, 스토리 지도는 전달 순서를 보여 줬다. 그러나 시스템 경계, 상태 전이, 데이터 관계, 규칙 조합처럼 여러 요소의 관계를 한꺼번에 대조하려면 모델이 유용하다. 모델은 현실의 일부를 특정 질문에 답하도록 의도적으로 단순화한 표현이다. 현실 전체를 한 그림에 담으려 하면 읽을 수 없는 종합도가 된다.

컨텍스트 모델컨텍스트 모델관심 대상의 경계와 외부 요소·관계를 표현해 책임 범위를 확인하는 모델이다.은 관심 시스템의 경계와 외부 사람·시스템·환경, 주고받는 책임을 보여 준다. 첫 질문은 “무엇을 만들 것인가”보다 “무엇이 우리 책임 안이고 밖인가”다.

이 모델에서 화살표는 구현 프로토콜이 아니라 교환되는 업무 책임과 정보의 방향을 나타낸다. 규칙 서비스가 제품 내부라면 경계 안으로 옮겨야 한다. 학사 정책은 문서일 수도, 정책 결정 조직일 수도 있으므로 구체적인 권한 출처와 제공 방식을 별도 기록한다.

컨텍스트 모델로 다음 결함을 찾는다.

• ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.: 규칙 서비스가 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.에 필요한 규칙 버전을 실제 제공하는가?
• 통지 실패 때 학생이 결과를 조회할 책임은 어느 경계에 남는가?
• 교무 운영 담당자가 보류·정정할 권한과 감사 책임을 갖는가?
• 학생의 학적 데이터는 어디가 원천이며 누가 정정하는가?
• 외부 연계를 사용할 수 없어도 시스템이 지켜야 할 최소 보장은 무엇인가?

모델 선택의 기준을 먼저 정리한다.

한 모델이 다른 모델을 대체하지 않는다. 모델 간 같은 개념·상태·규칙 ID를 연결해 모순을 찾는 데 가치가 있다.

2. 업무 프로세스 모델

업무 프로세스 모델은 목표를 이루기 위해 사람과 시스템이 수행하는 활동, 책임, 분기와 시작·종료를 보여 준다. 현재 업무를 이해하는 As-Is와 바뀔 업무를 합의하는 To-Be를 구분한다. 둘을 섞으면 기존 수동 보완을 새 시스템 책임으로 착각하거나, 개선하려던 낭비를 그대로 자동화할 수 있다.

수강신청의 To-Be 후보를 책임별로 펼친다.

이 흐름은 18장18장. 유스케이스와 시나리오사용자 목표와 정상·대안·예외 흐름을 유스케이스로 어떻게 명세하는가?페이지로 이동의 UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다과 비슷해 보이지만 관점이 다르다. 유스케이스는 학생 목표와 시스템 반응에 집중하고, 프로세스 모델은 조직 간 책임과 업무 인계를 보여 준다. 보류가 발생했을 때 운영 담당자가 실제로 받는 작업 목록, 처리 기한, 에스컬레이션과 학생 안내가 있는지 질문할 수 있다.

각 활동에는 입력·출력·수행 역할·적용 규칙·완료 기준을 붙인다. “신청 처리”처럼 넓은 상자는 규칙 평가, 결과 기록, 상태 제공으로 나누되 내부 코드 함수까지 내려가지 않는다. 자동화 전후의 시간·대기·재작업을 측정하면 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 수동 재처리 감소 가설을 검증할 기준도 마련된다.

3. BPMN

BPMN(Business Process Model and Notation)은 이벤트, 활동, 게이트웨이, 흐름, 참여자 풀·레인으로 업무 프로세스를 표현하는 표준 표기다. OMG BPMN 2.0.2가 2026년 현재 OMG 카탈로그의 공식 판본이다. 모든 기호를 쓰기보다 이해관계자가 검토할 질문에 필요한 최소 집합을 사용한다.

수강신청 흐름을 BPMN 개념으로 텍스트화하면 다음과 같다.

게이트웨이의 질문은 분기 조건을 완전하고 상호 배타적으로 정의해야 한다. 판정 불가를 규칙 미통과와 같은 아니오로 합치면 보류가 거절로 사라진다. 승인·정원 반영·기록이 하나의 트랜잭션처럼 그려졌어도 실제 원자성과 실패 복구는 별도 요구·설계로 확인해야 한다.

참여자 사이의 메시지 흐름과 한 참여자 내부의 순서 흐름도 구분한다. 규칙 서비스 응답은 메시지이며 학생의 신청 상태 전이는 수강신청 시스템 내부 업무 결과다. 표기 정확성에 집착해 도메인 검토자가 읽지 못한다면 단순 프로세스 그림과 함께 제공한다.

4. 데이터 흐름

데이터 흐름 모델은 외부 주체, 처리, 데이터 저장소와 그 사이를 이동하는 정보에 초점을 둔다. BPMN이 누가 언제 무엇을 하는지 묻는다면 데이터 흐름은 “어떤 정보가 어디서 와서 어떤 결과로 바뀌는가”를 묻는다.

데이터 흐름마다 의미·형식·기준 시점·품질·보호 수준을 정의한다. 학적·이수가 현재 값인지 신청 시점 스냅샷인지, 규칙·버전이 실제 발효된 정책을 식별하는지, 상태·사유에서 다른 학생 정보가 제거되는지 확인한다.

이 모델은 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.의 기록 필드를 도출하지만 상태 전이 순서를 보여 주지는 않는다. 저장소를 그렸다고 데이터베이스 제품을 선택한 것도 아니다. 논리적 정보 보존 책임을 표현하며, 구현 저장 구조는 설계에서 결정한다. 또한 처리 1번을 거대한 상자로 남기지 않고 입력이 결과로 변하는 규칙을 결정표·상태 모델과 연결한다.

5. 상태 모델

상태 모델은 한 대상의 생명주기와 허용된 전이를 표현한다. 수강신청에서는 화면 상태가 아니라 신청이라는 업무 객체를 중심으로 한다. 상태는 진입 후 지켜야 할 불변식과 밖으로 나가는 사건이 달라질 때 구분할 가치가 있다.

이 모델만으로도 빠진 정책이 보인다. 보류의 종료 상태, 재평가 트리거, 취소 허용 여부가 미결정이다. ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?에 따라 보류가 좌석을 점유한다면 승인·취소·기한 만료 전이의 정원 효과가 모두 달라진다. 상태 이름을 확정하기 전에 정책을 확인한다.

상태별 불변식 후보를 둔다.

판정 중을 외부 사용자에게 보여 줄 업무 상태로 유지할지 아주 짧은 내부 처리 단계로 볼지도 결정해야 한다. 모델의 상태 수는 코드 enum 수가 아니라 업무 의미와 관찰 필요에 따라 정한다. OMG SysML의 행동 모델 설명에서도 상태 기계는 객체의 생명주기와 사건에 따른 전이를 표현하는 행동 다이어그램으로 다룬다.

6. 시퀀스 모델

시퀀스 모델은 한 시나리오에서 참여자 사이 메시지와 시간 순서를 위에서 아래로 보여 준다. 유스케이스의 한 흐름을 상호작용 관점으로 확대하는 데 알맞다. 모든 가능한 조합을 한 그림에 넣지 말고 정상·핵심 예외를 나눈다.

두 모델을 비교하면 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 안전 결과와 정보 순서가 보인다. 학생에게 승인 결과를 보내기 전에 상태·정원·결정 기록이 어느 수준까지 일관되어야 하는지 질문할 수 있다. 기록 저장이 실패하면 승인을 되돌릴지, 별도 복구 상태로 둘지 아직 정해야 한다.

시퀀스의 화살표는 특정 API 호출을 확정하는 데 쓰지 않는다. 논리적 책임과 필수 순서를 먼저 합의하고 동기·비동기, 재시도, 타임아웃 구현은 품질·인터페이스 제약에 따라 설계한다. 여러 반복·대안이 많아지면 그림보다 유스케이스 분기와 결정표가 읽기 쉽다.

7. 데이터 모델

데이터 모델은 시스템이 관리해야 할 정보 구조, 식별자, 관계, 수량성과 무결성 규칙을 표현한다. 신청 결과를 기록한다는 문장만으로 무엇을 한 묶음으로 유지해야 하는지 알 수 없을 때 유용하다.

이것은 논리 모델이다. 테이블 수나 저장소 제품을 정하지 않는다. DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.의 학생·강좌 식별자, 요청 시각, 결과·사유, 규칙 버전, 최종 상태 변경이 어떤 관계로 보존되는지 확인한다. 하나의 신청에 여러 규칙 판정과 상태 변경이 있을 수 있어야 재평가를 재현할 수 있다.

무결성 후보는 다음과 같다.

• 신청은 정확히 한 학생과 한 강좌개설을 참조한다.
• 판정 결과는 사용한 규칙과 버전을 식별한다. ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인. 확인 전에는 구현 확정이 아니다.
• 현재 상태는 상태 변경 이력과 모순되지 않는다.
• 동일 학생·강좌·학기의 유효 승인 중복은 정책이 허용하지 않는 범위에서 생성되지 않는다.
• 삭제·정정은 이력과 권한·보존 정책을 훼손하지 않는다.

데이터 모델은 사유 공개 범위나 업무 용어의 풍부한 의미를 모두 담지 못한다. 개인정보 등급, 원천, 보존 기간, 정정 책임과 함께 관리한다.

8. 도메인 모델

도메인 모델은 업무에서 중요한 개념과 관계·규칙을 기술 독립적인 언어로 정리한다. 데이터 모델이 저장·식별·수량성에 무게를 둔다면 도메인 모델은 사람들이 같은 말을 같은 뜻으로 쓰게 하는 데 무게를 둔다.

강좌와 강좌개설을 구분하면 같은 과목이 학기·분반별 정원과 일정이 다르다는 점을 표현할 수 있다. 요청, 신청, 승인, 수강등록도 동의어가 아닐 수 있다. 요청은 제출 사건, 신청은 생명주기 객체, 승인은 판정 결과, 수강등록은 학사 원장의 후속 상태일 수 있다. 실제 업무에서 확인해 용어집과 일치시킨다.

도메인 모델은 데이터베이스 스키마가 아니다. 모든 개념을 영속화하거나 클래스 하나로 구현할 필요가 없다. 반대로 구현에 이미 있는 테이블 이름을 그대로 옮기면 현행 설계의 오류와 약어가 업무 언어를 지배한다. 정책 담당자·학생 지원·개발·시험이 사례를 같은 개념으로 설명할 수 있는지 검토한다.

9. 결정표

결정표는 여러 조건 조합과 그 결과를 행·열로 나란히 놓아 누락·중복·모순을 찾는다. 수강신청처럼 선수과목, 학점, 시간 충돌, 정원, 우선순위가 함께 판정에 영향을 주면 자연어 if 문장보다 효과적이다.

먼저 단순화한 후보를 만든다. Y는 조건 충족, N은 미충족, –는 그 규칙에서 결과에 영향을 주지 않음을 뜻한다.

R4R4 · 프로젝트 항목일반 좌석과 우선 조건이 모두 충족되지 않았으나 거절과 대기 중 정책이 미결정인 결정표 규칙 열이다.와 R5R5 · 프로젝트 항목일반 좌석은 없지만 우선 조건을 충족했을 때 승인 여부가 미결정인 결정표 규칙 열이다.는 일부러 미결정으로 남겼다. RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.가 예약 정원인지 배정 순서인지, RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 적용 정원을 바꿀 권한인지 확인되지 않았고 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.이 열려 있기 때문이다. 결정표의 빈칸은 문서 결함이 아니라 필요한 정책 결정을 정직하게 표시한다. 임의로 승인을 채우면 모델이 잘못된 확실성을 만든다.

실제 표는 복수 실패 사유, 학생 유형, 예외 승인, 동률, 기준 시점까지 커질 수 있다. 조건을 독립적인 업무 사실로 정규화하고, 불가능한 조합을 표시하며, 각 열이 적어도 하나의 검증 사례로 이어지게 한다. 표가 폭발하면 정책을 계층화하거나 별도 결정 서비스 설계를 검토하되 추적성을 유지한다.

OMG DMN 1.5는 2026년 현재 OMG 카탈로그의 공식 Decision Model and Notation 판이다. 모든 프로젝트가 DMN 도구를 쓸 필요는 없지만 조건·결론·적중 정책의 의미를 명시하는 원칙은 유용하다.

10. 결정 트리

결정 트리는 질문을 따라가며 하나의 결과에 도달하는 경로를 보여 준다. 상담·설명처럼 사람이 순차 질문을 따라야 할 때 읽기 쉽다.

같은 내용을 결정표와 트리로 모두 유지하면 중복 불일치가 생길 수 있다. 표를 기준 규칙 집합으로 두고 트리를 설명용 보기로 생성하거나, 어느 산출물을 기준으로 삼을지 정한다. 트리는 공통 조건이 여러 갈래에 반복되고 모든 조합이 있는지 확인하기 어렵다. 표는 완전성 검토에 강하고 트리는 한 사례를 설명하는 데 강하다.

학생에게 거절 사유를 설명할 때 내부 트리 순서를 그대로 노출하지 않는다. 공개 가능한 정책 언어와 다음 행동을 제공해야 하며, 복수 사유를 어느 범위까지 보여 줄지 승인한다. 결정 경로는 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.과 연결해 사후 재현이 가능해야 한다.

11. 권한 행렬

권한 행렬은 역할별로 어떤 대상에 어떤 행동을 어느 조건에서 할 수 있는지 대조한다. “관리자는 모든 것을 관리한다”는 문장을 분해하고 최소 권한·업무 분리·감사를 검토하게 한다.

허용만 적지 않고 데이터 범위, 객체 상태, 기간, 목적, 추가 승인과 기록 의무를 붙인다. 특히 판정 정정과 규칙 변경을 한 역할이 임의로 수행하면 사후 조작 위험이 있다. 실제 조직의 책임과 법·정책을 확인해 업무 분리와 이중 승인을 결정한다.

행렬은 인증 방법이나 화면 버튼을 정하지 않는다. 각 셀은 접근 제어 요구, 기록 요구와 오용 사례로 이어진다. 사용자가 자기 신청만 조회해야 한다는 데이터 범위는 ID를 바꾼 요청, 대리 역할, 지원 업무 사례로 검증한다.

12. 화면 흐름

화면 흐름은 사용자가 화면·페이지·대화 상태 사이를 이동하는 경로를 보여 준다. 정보 구조와 탐색 누락을 검토하는 데 유용하지만 업무 프로세스나 상태 모델을 대신하지 않는다. 화면에서 “승인” 페이지를 봤다고 승인 상태의 원자성과 규칙 판정이 증명되는 것은 아니다.

이 흐름은 19장19장. 사용자 스토리와 백로그가치를 작은 전달 단위로 나누면서 업무 규칙과 품질 요구를 어떻게 잃지 않는가?페이지로 이동의 스토리 지도와 닮았지만 화면을 중심으로 한다. 한 화면에서 여러 사용자 과업을 수행할 수도 있고, 채널에 따라 화면이 없을 수도 있다. 따라서 “검색→장바구니→신청”을 업무 규칙으로 고정하지 않는다. 장바구니에 넣는 것이 좌석 예약인지 단순 선택 목록인지도 모델 밖 정책으로 확인한다.

화면별로 사용자 목표, 필요한 정보, 가능한 행동, 진입·이탈 조건, 오류·빈 상태, 접근성과 권한을 연결한다. 결과 화면은 승인·거절·보류를 색만으로 구분하지 않고 상태 이름, 사유, 신청 식별자와 다음 행동을 인지 가능하게 제공해야 한다. 외부 알림의 링크로 진입해도 다른 학생의 신청을 열 수 없어야 한다.

6부의 네 장은 같은 수강신청 요구를 다른 질문으로 표현했다.

중복되는 정보는 복사본으로 관리하지 않는다. 신청, 보류, 승인의 정의는 도메인 용어집을 기준으로 하고, 상태 전이는 상태 모델, 조건 조합은 승인된 결정표, 의무·품질 기준은 요구 ID, 사용자 흐름은 유스케이스와 스토리 지도에 둔다. 각 산출물은 기준이 되는 정보를 참조하고 변경 시 영향 링크로 함께 검토한다.

OMG 명세 카탈로그는 UML 2.5.1, BPMN 2.0.2, DMN 1.5의 공식 상태와 판본을 확인할 수 있는 기준이다. IREB Requirements Modeling 자료는 정보·기능·행동 관점의 모델을 요구사항 작업 산출물로 선택·결합하는 방법을 다룬다. 표준 기호를 정확히 쓰는 것은 중요하지만, 모델의 성공 기준은 이해관계자가 경계·누락·모순을 발견하고 승인된 요구·검증으로 연결할 수 있는가다.

이 장에서 정리한 결과는 모델 선택표, 컨텍스트와 업무 흐름, BPMN 개념 모델, 데이터 흐름, 상태·시퀀스·데이터·도메인 모델, 결정표·결정 트리, 권한 행렬과 화면 흐름이다. 이 모델들은 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다., RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.와 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다., 보류 생명주기와 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?, 규칙 버전 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.를 해결하지 않고 눈에 보이는 결정 대상으로 남겼다. 다음 부에서는 이렇게 표현한 요구를 우선순위·변경·추적·형상 관점에서 지속적으로 관리한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로