18장. 유스케이스와 시나리오

사용자의 목표를 기본·대안·예외 흐름으로 나누고 액터·사전조건·종료조건이 있는 유스케이스로 정리한다.

이번 장에서 해결할 질문

학습 목표

• “사용자 목표와 정상·대안·예외 흐름을 유스케이스로 어떻게 명세하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

사용자와 시스템의 상호작용을 기능 목록만으로 설명하면 목표에 이르는 과정이 보이지 않는다. 같은 기능도 시작 조건과 참여자, 대안 흐름, 실패 후 상태에 따라 전혀 다른 책임을 가진다. 유스케이스는 화면 순서를 복사하는 문서가 아니라 목표 달성의 계약을 드러내는 도구다.

이 장에서는 액터액터유스케이스에서 목표를 이루기 위해 시스템과 상호작용하는 사람·역할·외부 시스템이다.와 목표를 정하고 기본·대안·예외 흐름, 사전조건과 종료조건을 갖춘 유스케이스를 작성한다. 수강신청 흐름을 통해 업무 규칙과 품질·데이터·인터페이스 요구를 연결하고, 지나치게 상세한 UI 절차와 필요한 시스템 책임을 구분한다.

1. 액터

17장17장. 자연어 요구사항 명세자연어의 장점을 살리면서 모호성과 과도한 설계 지정을 어떻게 줄이는가?페이지로 이동은 요구 하나의 조건과 결과를 분명히 했다. 그러나 학생이 강좌를 신청해 결과를 확인하기까지는 여러 요구가 이어진다. 유스케이스는 시스템 밖의 존재가 목표를 이루려고 관심 시스템과 주고받는 상호작용을 기본·대안·예외 흐름으로 묶는다. 화면을 클릭하는 순서가 아니라 액터의 목표와 시스템 책임을 처음부터 종료까지 살펴보는 표현이다.

액터는 시스템 밖에서 유스케이스에 참여하는 역할이다. 특정 사람의 이름이나 조직도상의 직급, 화면, 내부 모듈이 아니다. 같은 사람이 학생과 조교 역할로 다른 유스케이스에 참여할 수 있고, 외부 시스템도 정보를 제공하거나 통지를 받는 보조 액터가 될 수 있다.

수강신청 사례의 관심 시스템은 11장11장. 범위를 정의한다제품과 프로젝트가 책임질 범위와 경계 밖의 일을 어떻게 합의하는가?페이지로 이동에서 정한 수강신청 시스템이다. 액터 후보를 다음처럼 구분한다.

규칙 서비스가 수강신청 제품 내부 구성요소라면 액터가 아니다. 경계가 달라지면 다이어그램도 바뀐다. 그래서 액터를 그리기 전에 시스템 경계를 확인해야 한다. 데이터베이스나 신청 판정 모듈처럼 경계 안 요소를 액터로 그리면 설계 구조와 외부 책임이 섞인다.

간단한 유스케이스 맥락은 다음과 같다. 선은 참여 관계이지 데이터 흐름이나 호출 순서를 뜻하지 않는다.

이 그림은 대화 시작점이다. 어느 외부 서비스가 실제 판정 권한을 갖는지, 알림이 필수인지, 보류 처리 권한이 누구에게 있는지는 출처와 책임표로 확인한다.

2. 목표

유스케이스 이름은 액터가 얻으려는 업무 결과를 동사형으로 쓴다. “수강신청 화면”, “신청 API”, “정원 테이블 갱신”은 목표가 아니라 화면·인터페이스·구현 요소다. 이 장의 대표 유스케이스는 UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다 강좌를 신청한다로 둔다.

목표: 학생이 선택한 강좌에 대해 현재 적용되는 학사 규칙과 강좌 상태에 따른 신청 판정을 받고, 승인·거절·보류 중 설명 가능한 결과를 확인한다.

이 목표는 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.의 결과·사유 확인과 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 규칙·강좌 상태 평가를 함께 연결한다. G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.의 불확실성과 반복 제출을 줄이는 데 기여하지만, BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 수동 재처리 50% 감소를 유스케이스 하나가 곧바로 보장하지는 않는다. 운영 지표와 기준선 검증이 별도로 필요하다.

목표 수준이 지나치게 크면 “수강 생활을 관리한다”처럼 여러 사용 시나리오가 섞이고, 지나치게 작으면 “신청 버튼을 누른다”처럼 사용자 가치가 사라진다. 한 번의 업무 사건으로 의미 있는 결과를 얻고 독립적으로 성공·실패를 말할 수 있는 수준을 고른다. 검색, 신청, 결과 조회, 취소는 연결되지만 각각 독립 목표가 될 수 있다.

성공은 승인만 뜻하지 않는다. 학생이 선수과목을 충족하지 못해 거절되더라도 시스템이 권한 있는 규칙으로 판정하고 사유와 다음 행동을 제공했다면 유스케이스는 설명 가능한 종료를 이룬다. 반대로 화면에 “실패”만 보여 주거나 결과를 알 수 없어 반복 제출하게 되면 목표를 충족하지 못한다.

3. 선행조건

선행조건은 유스케이스가 시작되기 전에 참이어야 하며, 이 유스케이스가 만들어 내지 않는 상태다. 선행조건을 만족하지 못하면 흐름을 시작할 수 없거나 다른 유스케이스로 이동한다. 선행조건과 첫 단계를 구분해야 한다.

UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다의 후보 선행조건은 다음과 같다.

• 학생의 신원이 확인되어 있고 자신의 신청을 제출할 권한이 있다.
• 대상 학기와 강좌가 식별되어 있다.
• 수강신청 시스템이 대상 강좌를 신청 후보로 제공할 수 있는 상태다.
• 적용 학사 일정·규칙의 기준 시점과 버전을 판정할 방법이 있다.

“정원이 남아 있다”, “선수과목을 충족한다”는 선행조건으로 두지 않는다. 그것은 시스템이 신청 과정에서 평가하고 대안 결과를 만들어야 할 업무 규칙이다. 선행조건으로 옮기면 실패 경로와 사유 제공 의무가 유스케이스 밖으로 사라진다. 규칙 서비스의 가용성도 절대 선행조건으로 두면 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 보류 예외를 표현할 수 없다.

선행조건은 별도 요구를 대신하지 않는다. 인증·권한 확인, 강좌 식별, 규칙 기준선이 시스템 의무라면 고유 ID와 검증 기준을 가져야 한다. 유스케이스에서는 그 관계를 참조해 흐름의 출발점을 간결하게 만든다.

4. 트리거

트리거는 유스케이스를 시작하게 하는 관찰 가능한 사건이다. UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다에서는 인증된 학생이 대상 학기와 강좌를 지정해 신청을 제출한다가 기본 트리거다. “학생이 신청하고 싶다”는 의도이고, “수강신청 기간이다”는 상태이므로 트리거가 아니다.

트리거를 구체화하면 중복과 경계 질문이 나타난다.

• 제출 사건을 고유하게 식별할 수 있는가?
• 학생이 응답을 받기 전에 재제출하면 같은 사건인가 새 사건인가?
• 마감 직전에 보낸 요청이 경계에 언제 도착한 것으로 판정되는가?
• 앱이 자동 재시도한 요청과 학생이 다시 누른 요청을 구별해야 하는가?

이 질문은 화면 버튼을 정하는 문제가 아니라 신청의 동일성·기간 판정·중복 승인 방지 요구다. 트리거에는 업무 의미를 적고, 전송 방식과 재시도 알고리즘은 인터페이스·설계에서 정한다. 단, 외부 계약이 필수라면 제약 요구로 연결한다.

5. 기본 흐름

기본 흐름은 목표가 가장 일반적으로 달성되는 성공 경로다. 한 단계에는 액터의 의도 있는 행동이나 시스템의 관찰 가능한 반응 하나를 적는다. 화면 필드와 내부 알고리즘을 과도하게 나열하지 않는다.

UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다 강좌를 신청한다 상세 명세

기본 흐름—모든 필수 판정 통과

1. 학생이 대상 강좌의 신청을 제출한다.
2. 수강신청 시스템은 학생·학기·강좌와 요청의 유효성, 신청 가능 기간을 확인한다.
3. 수강신청 시스템은 요청에 적용되는 규칙과 강좌 상태의 기준 시점을 정한다.
4. 수강신청 시스템은 선수과목, 최대 학점, 시간 충돌, 정원과 승인된 우선순위 규칙을 평가한다.
5. 모든 필수 판정이 통과하면 수강신청 시스템은 신청을 승인 상태로 만들고 필요한 정원 반영을 일관되게 수행한다.
6. 수강신청 시스템은 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.에 따라 신청 식별자, 요청 시각, 결과, 사유, 규칙 버전과 최종 상태 변경을 기록한다.
7. 수강신청 시스템은 학생에게 승인 상태와 신청 식별자를 제공한다.

5단계의 “일관되게”는 그대로 검증 기준으로 쓸 수 없다. 승인 상태와 좌석 차감이 하나의 업무 결과인지, 동시 신청에서 정원을 초과하지 않는지, 실패 시 어느 상태로 복구하는지 요구와 모델로 구체화해야 한다. 기본 흐름은 이 결함을 드러내지만 자동으로 해결하지 않는다.

흐름을 검토할 때 각 단계를 입력·책임·관찰 결과로 다시 읽으면 숨은 요구를 찾을 수 있다.

이 표에서 3단계는 특히 중요하다. 신청 처리 중 학적, 정원, 규칙 버전이 변할 수 있으므로 각 입력을 어느 시점의 값으로 일관되게 판정하는지 정해야 한다. “항상 최신 값을 쓴다”는 말만으로는 충분하지 않다. 항목마다 읽은 시점이 달라 서로 존재한 적 없는 조합을 만들 수 있기 때문이다. 스냅샷, 재확인, 충돌 탐지 중 어느 설계를 쓰든 이해관계자가 요구하는 업무 결과와 허용 가능한 재판정 규칙을 먼저 합의한다.

또한 기본 흐름은 모든 규칙을 순서대로 구현하라고 명령하지 않는다. 4단계의 나열 순서는 설명을 위한 것이며 병렬 평가나 최적화가 가능하다. 다만 서로 다른 평가 순서가 학생에게 다른 최종 결과·사유를 만들 수 있다면 사유 우선순위는 업무 규칙으로 승인을 받아야 한다. 유스케이스의 서술 순서와 시스템의 실행 순서를 구분한다.

알림 서비스로 메시지를 보내는 단계는 기본 흐름에서 제외했다. 학생이 시스템 안에서 결과를 확인할 수 있다면 외부 통지는 목표 달성 뒤의 선택적 후속 흐름일 수 있다. 정책상 반드시 전달되어야 한다면 통지 성공 기준과 실패가 신청 결과에 미치는 영향을 별도 요구로 정한다.

6. 대안 흐름

대안 흐름은 시스템이 정상적으로 조건을 평가했지만 기본 흐름과 다른 유효한 결과에 도달하는 경로다. 거절은 기술 장애가 아니라 업무 규칙의 정상 결과다. 각 분기는 기본 흐름의 어느 단계에서 갈라지고 어디서 종료·합류하는지 표시한다.

각 대안은 “오류 메시지를 표시한다”로 끝나지 않는다. 업무 상태, 사유, 기록, 학생의 가능한 다음 행동을 말해야 한다. 여러 거절 규칙이 동시에 성립할 때 하나만 보여 줄지 모두 보여 줄지, 사유 우선순위는 무엇인지도 결정해야 한다. 자연어 목록으로 조합을 관리하기 어려우면 20장20장. 모델로 표현하는 요구사항경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?페이지로 이동의 결정표로 옮긴다.

대안 흐름을 적어 보면 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.의 “신청/거절 결과와 이유”가 실제로 어떤 데이터를 필요로 하는지 드러난다. 선수과목 미충족이면 적용 규칙과 근거 과목, 시간 충돌이면 충돌 대상을 학생이 이해할 수 있어야 할 수 있다. 다만 개인정보·정책 공개 범위를 넘지 않도록 역할과 데이터 범위를 확인한다.

7. 예외 흐름

예외 흐름은 정상 판정을 끝낼 수 없는 상황과 안전한 대체 결과를 다룬다. 외부 서비스 시간 초과, 유효하지 않은 규칙 버전, 판정 기록 실패, 승인과 정원 반영의 부분 실패가 대표적이다.

E1E1 · 프로젝트 항목안전 상태와 미확인 정책.—규칙 판정 불가

1. 기본 흐름 3–4단계에서 규칙 서비스가 정한 시간 안에 유효한 판정과 규칙 버전을 제공하지 못한다.
2. 수강신청 시스템은 신청을 자동 승인하지 않는다.
3. 수강신청 시스템은 요청을 원인 코드가 있는 보류 상태로 기록한다.
4. 수강신청 시스템은 학생에게 현재 상태, 확인 가능한 원인과 다음 행동을 제공한다.
5. 신청은 합의된 사건에 따라 재평가되거나 권한 있는 운영 처리로 연결된다.

5단계의 재평가 사건, 기한, 횟수, 종료 상태와 보류 좌석 점유는 아직 정책 결정이 필요하다. ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.와 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?을 사실처럼 채우지 않는다.

E2E2 · 프로젝트 항목주체·권한을 확인할 수 없음.—상태 변경과 정원 반영의 부분 실패

기본 흐름 5단계에서 승인 상태는 기록됐지만 좌석 반영이 실패하거나 반대 상황이 생기면, 시스템은 학생에게 확정 승인으로 제공하기 전에 모순을 탐지하고 안전 상태로 복구해야 한다. 어떤 보상·재시도 기술을 쓸지는 설계지만 다음 업무 불변식은 요구 후보가 된다.

• 확정 승인 수가 정책상 가용 좌석을 초과해서는 안 된다.
• 하나의 신청에 모순되는 둘 이상의 최종 상태가 존재해서는 안 된다.
• 복구 전 상태를 학생에게 확정 결과로 제공해서는 안 된다.
• 원래 요청, 부분 실패, 복구 행동과 최종 결과를 추적할 수 있어야 한다.

E3E3 · 프로젝트 항목접수 뒤 연결이 끊김.—외부 알림 실패

승인·거절 판정과 기록이 끝난 뒤 외부 알림만 실패했다면 신청 상태를 임의로 되돌리지 않는다. 학생이 시스템에서 결과를 조회할 경로를 유지하고, 통지 실패를 기록하며, 재시도나 운영 조치는 별도 통지 요구에 따른다. 판정 실패와 전달 실패를 섞지 않는 것이 핵심이다.

8. 사후조건

사후조건은 유스케이스가 끝난 뒤 반드시 참이어야 하는 상태다. 성공 사후조건과 최소 보장을 구분하면 중간 실패에서도 지켜야 할 안전성을 확인할 수 있다.

성공 사후조건 후보

• 승인된 신청에는 고유 식별자와 일관된 좌석 반영이 연결되어 있다.
• 정상 거절에는 적용된 사유가 있고 승인 좌석을 점유하지 않는다.
• 학생은 자신의 신청 결과와 허용된 범위의 사유를 조회할 수 있다.
• DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.의 판정 기록이 결과·규칙 버전·상태 변경을 추적한다.

최소 보장 후보

• 유효한 규칙 판정이 없으면 신청은 자동 승인되지 않는다.
• 같은 신청에 모순되는 최종 결과가 생성되지 않는다.
• 실패·보류 원인과 요청 식별 정보가 복구 가능한 범위에서 남는다.
• 다른 학생의 신청·판정 정보가 노출되거나 변경되지 않는다.

보류가 좌석을 점유하는지와 재평가 뒤 어떤 기준 시점을 적용하는지는 사후조건에 넣기 전에 정책 합의가 필요하다. 사후조건은 흐름을 요약하는 문장이 아니라 상태 모델·데이터 규칙·검증 사례와 대조할 불변식이다.

9. 유스케이스 관계

유스케이스 관계는 공통 행동과 선택·예외 확장을 정리하는 데 도움을 주지만, 관계 기호가 많다고 분석이 좋아지는 것은 아니다. UML은 액터와 유스케이스, 포함·확장·일반화 관계를 제공한다. OMG UML 2.5.1은 2026년 현재 공식 명세 카탈로그에 등재된 판본이다.

인증한다, 선수과목을 확인한다, 정원을 차감한다를 모두 별도 유스케이스로 만들면 사용자 목표가 내부 함수 목록으로 쪼개질 수 있다. 다른 액터에게 독립적인 가치를 주거나 여러 사용자 목표에서 의미 있게 재사용되는 행동인지 먼저 묻는다. 단순한 구현 재사용은 설계 문제다.

“보류 신청을 처리한다”는 교무 운영 담당자의 별도 목표가 될 수 있다. 이 유스케이스는 UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다 예외에서 시작될 수 있지만, 권한·재평가·정정·감사라는 독립 흐름을 갖는다. 관계를 그리기 전에 실제 운영 책임과 승인 권한을 확인한다.

10. 유스케이스와 요구사항

유스케이스는 여러 요구를 목표와 시나리오로 묶는 산출물이지, 요구 집합 전체의 대체물이 아니다. 기본 흐름 4단계는 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.과 RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.를 연결하지만 각 규칙의 정확한 조건·출처·우선순위를 담지 못한다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 p95 2초, 접근성, 보안, 감사 보존, 외부 인터페이스 계약도 흐름만으로는 충분히 표현되지 않는다.

반대로 원자 요구만 나열하면 시작부터 종료까지 연결이 끊어질 수 있다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 보류 문장이 있어도 학생이 보류를 어떻게 알고, 누가 언제 재평가하며, 끝내 판정할 수 없을 때 어떻게 종료하는지 빠질 수 있다. 유스케이스는 이런 집합 수준의 누락을 찾는다.

두 표현을 다음처럼 추적한다.

같은 내용을 여러 형식에 복사해 붙이지 않는다. 유스케이스에는 이야기의 흐름과 분기 의도를 두고, 요구에는 고유 ID·의무·측정 기준, 규칙 카탈로그에는 판정 논리, 모델에는 상태·관계를 둔다. 변경할 때 어느 산출물을 기준으로 삼을지 정하고 링크를 연결해야 중복 불일치가 줄어든다.

ISO/IEC/IEEE 29148은 요구사항 공학의 프로세스와 정보 항목을 다루며, IREB CPRE Foundation 자료는 자연어·템플릿·모델·유스케이스 등 작업 산출물의 선택과 조합을 다룬다. 유스케이스 표기 자체는 OMG UML을 기준으로 삼되, 표준 기호보다 목표·경계·분기·사후조건의 검토 가능성이 먼저다.

이 장에서 정리한 결과는 유스케이스 맥락도, UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다 상세 명세와 분기표다. 작성 과정에서 복수 거절 사유, 보류 생명주기, 승인과 정원 반영의 원자성, 통지 실패의 경계가 추가 쟁점으로 드러났다. 다음 장에서는 같은 흐름을 작은 가치 단위와 대화·수용 기준으로 바꾸고, 릴리스 순서를 어떻게 구성하는지 살펴본다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로