유스케이스 다이어그램으로 요구사항 범위와 시나리오를 모델링하는 법

사용자 목표에서 시스템의 책임선을 긋는다

유스케이스 다이어그램(Use Case Diagram)은 외부 행위자(Actor)가 시스템에서 수행하는 기능(Use Case)과 그 관계를 사용자 관점으로 나타내는 UML 표기법이다. 요구사항을 수집하고 범위를 관리하는 상위 산출물로 쓰이며, 시스템 경계를 명확히 해 이해관계자 사이의 공통 언어를 만든다.

이 다이어그램이 다루는 단위는 사용자가 목표를 달성하는 행동 흐름이다. 클래스나 컴포넌트 같은 내부 설계 세부를 담는 자리는 아니다. 대신 시나리오 기반 명세와 테스트 케이스를 끌어낼 수 있는 기준점을 제공한다.

다이어그램을 이루는 대상과 관계

Actor는 시스템 바깥의 역할 단위다. 사람뿐 아니라 외부 시스템과 다른 서비스도 행위자가 될 수 있다. 한 사용자가 여러 역할을 수행할 수 있으므로, 행위자는 개인이 아니라 역할로 잡고 권한·정책과 연결해 정의하는 편이 낫다.

Use Case는 행위자에게 가치가 있는 기능 단위다. 시작 조건과 종료 조건, 성공 시나리오, 예외 시나리오를 함께 가진다. 기능을 화면 단위로 쪼개기보다 사용자의 목표 달성 단위로 구분해야 과도한 분할을 피할 수 있다.

System Boundary는 시스템에 들어오는 기능의 집합을 보여 주며 외부 책임과 내부 책임을 가른다. 마이크로서비스나 제품 라인처럼 조직적 경계가 있는 경우에는 그 경계와도 맞는지 검토해야 한다.

관계 표기는 공통 흐름과 조건부 흐름을 드러낼 때 사용한다.

Include는 공통 하위 흐름을 반드시 재사용하는 관계다. 중복을 줄이고 일관성을 높이는 데 쓴다.
Extend는 기본 시나리오에 조건부 동작을 붙이는 관계다.
Generalization은 Actor 또는 Use Case의 상속을 표현하며, 공통화와 변형을 모델링한다.

다이어그램은 유스케이스 서술서의 기본·대안·예외 흐름, 사전조건과 사후조건, 비기능 요구사항으로 이어진다. 이 정보는 테스트 케이스, BDD의 Given/When/Then, API 계약서로 전환하기도 쉽다.

요구사항을 산출물로 연결하는 흐름

작성은 비즈니스 목표와 지표, 사용자 페르소나와 권한, 상위 범위 정의(Scope), 용어사전에서 시작한다. 후보 유스케이스를 모아 묶은 뒤 중복과 충돌을 제거하고, 동사+목표 형태의 명명 규칙을 정한다. 이후 시스템 경계와 외부 인터페이스를 식별하고 include, extend, generalization 관계를 설정한다.

각 유스케이스에는 기본·대안·예외 시나리오와 전·후 조건, 연결되는 비기능 요구사항을 기록한다. PO, UX, QA, Dev, SecOps가 참여하는 검토 워크숍에서 요구-ID↔유스케이스↔테스트의 추적성을 매핑한다. 결과물은 다이어그램, 유스케이스 서술서, 추적 매트릭스, 파생 테스트 케이스와 예외 목록이다.

용어가 맞지 않으면 용어사전을 갱신한 뒤 다시 검토한다. 권한이 없는 액터가 기능에 접근하는 흐름이 드러나면 권한 모델과 정책을 다시 설계해야 한다. include와 extend가 지나치게 늘어나 읽기 어려워진 경우에는 시나리오를 병합하거나 정리한다.

⤢✕

관계 표기는 흐름을 설명할 만큼만 쓴다

유스케이스를 너무 세세하게 나누면 읽기 어려워지고, 너무 크게 묶으면 사용자 목표가 흐려진다. 화면 단위가 아니라 목표 단위로 묶고, 다이어그램은 얇게 유지한 뒤 세부 내용은 서술서와 시나리오에 둔다.

Include는 중복을 없애는 공통 흐름에 집중한다. Extend는 조건부 또는 선택적 동작에 한정한다. Generalization 역시 실제 행위와 정책에 공통점이 있을 때만 적용해야 한다.

시스템 경계는 팀과 제품의 경계에 맞추고, 외부 시스템은 반드시 액터로 표현한다. 데이터와 권한의 책임선이 불명확하다면 이벤트 흐름과 거버넌스를 거꾸로 검토해 경계를 확인할 수 있다.

관계	목적	흐름 영향	재사용성	명확성	대표 사용처
Include	공통 하위 절차 강제	기본 흐름에 항상 포함	높음	높음	인증, 로깅, 검증
Extend	조건부 확장	조건 충족 시만 실행	중간	중간	프로모션 적용, 2차 확인
Generalization	공통 행위의 상속	상위 시나리오 준수	중간	중간	관리자/일반 사용자 역할 분화

도메인별로 요구사항과 테스트를 묶는 방법

커머스 주문 도메인에서는 고객, 결제게이트웨이, 재고시스템을 액터로 둘 수 있다. 상품검색, 장바구니관리, 결제하기를 유스케이스로 두고 결제하기에는 인증과 주소확인을 include, 쿠폰적용을 extend로 연결한다. 이 산출물에서는 성공, 한도초과, 재고부족 예외의 테스트 케이스를 파생할 수 있다.

금융 규제 대응에서는 KYC/AML 의무 절차를 include로 표준화하고 감사 로그 요구사항과 추적성을 확보한다. 거래중지와 재심사 같은 예외 처리는 extend로 모델링해 정책 변경의 영향을 줄인다.

마이크로서비스 경계를 설계할 때는 시스템 경계를 서비스 캡슐화 단위와 일치시키고 팀 토폴로지에 매핑한다. API와 이벤트 같은 외부 의존성은 액터로 표현해 인터페이스 계약을 분명히 한다.

QA와 테스트 전략에서는 유스케이스별 시나리오를 BDD로 변환하고 커버리지를 매핑한다. 예외 흐름은 회귀 테스트 세트에 고정 편성한다.

변경 비용과 추적성에 미치는 영향

중복 흐름의 include 표준화를 기준으로 요구 변경 재작업률은 15~~30% 감소할 수 있다. 예외 흐름 식별률을 높이면 결함 누수율은 10~~20% 감소하고, 시나리오 기반 자동화와 연결하면 테스트 케이스 파생 효율은 20~40% 향상될 수 있다.

정량 지표 외에도 이해관계자가 같은 언어로 요구사항을 논의하게 되어 의사결정 속도가 높아진다. 시스템 경계가 선명해지면 책임소재와 운영 거버넌스가 강화되며, 요구-설계-테스트 추적성은 감사 대응에도 도움이 된다.