유즈케이스(Use Case)의 개념
유즈케이스는 사용자(Actor)가 특정 시스템을 통해 어떤 목표를 달성하기 위한 일련의 시나리오입니다.
기능을 사용자의 입장에서 풀어서 설명하기 때문에 “누가”, “왜”, “어떻게” 시스템을 사용하는지를 구조적으로 표현할 수 있습니다.
개발 시 시스템의 구조와 동작을 시각적으로 표현해야할 때 유즈케이스는 위에 설명한 뜻과 같지만, 문맥에 따라 뜻이 조금씩 달라집니다. 제품을 설명하는 상황인 경우에는 '사용 용도'로 해석되고, 클린 아키텍처에서는 '코드 레벨의 코듈'을 말합니다.
이번에는 개발 시 유즈케이스에 대해 알아보겠습니다.
유즈케이스의 핵심 요소
USE CASE라는 이름에서 알 수 있듯이, 사용자가 어떤 기능을 이용하는 경우를 작성해야 합니다.
사용자가 시스템을 통해 어떤 목표를 달성하기 위한 일련의 시나리오를 작성하기 위해 무엇이 필요할까요?
사용자가 어떤 목표를 달성하려면 기능(USE CASE)를 이용해야 합니다.
각각의 기능은 서로 다른 시스템이 담당할 수 있습니다.
이때, 시스템이 담당하는 범위가 어디까지인지를 명확히 하기 위해 시스템의 경계를 나눕니다.
사용자가 기능을 이용하며 시스템과 상호작용하는 기본적인 흐름과 예외적인 흐름을 일련의 시나리오로 표현할 수 있습니다.
유즈케이스의 핵심 요소를 표로 정리하였습니다.
| 구성 | 요소설명 |
| Actor 사용자 | 시스템과 상호작용하는 사용자 또는 외부 시스템 |
| Use Case 기능 | 사용자의 목표를 달성하기 위한 기능 단위 |
| System Boundary 시스템 경계 | 시스템이 담당하는 기능의 범위 |
| 기본 흐름 | 정상적인 절차의 단계별 흐름 |
| 예외 흐름 | 실패나 예외 상황에서의 흐름 |
유즈케이스 작성 방법
기획자와 디자이너 등 비전공자도 이해하기 쉽게 글로 작성하는 서술형 시나리오 방식과,
행위자와 유즈케이스를 선과 도형으로 표현하고 관계 구조를 시각화한 UML 다이어그램 방식으로 작성할 수 있습니다.
"사용자가 음식을 주문하는 과정"을 유즈케이스로 두 가지 방식 모두 다 작성해보겠습니다.
- 서술형 시나리오 예시:
유즈케이스 핵심 요소인 Use Case의 이름, 액터, 목표, 기본 흐름, 예외 흐름이 모두 포함되도록 적어줍니다.
Use Case: 음식 주문하기 (Order Food)
Actor: 사용자 (User)
목표: 앱을 통해 음식을 선택하고 결제하여 주문을 완료한다.
<기본 흐름 (Main Flow)>
1. 사용자가 앱을 실행
2. 사용자가 음식점을 선택
3. 사용자가 메뉴에서 원하는 음식을 골라 장바구니에 담음
4. 사용자가 결제함
5. 시스템이 주문 정보를 해당 음식점에 전달하고 완료 메시지 표시
<예외 흐름 (Alternative / Exception Flow)>
3-a. 메뉴 수량이 재고보다 많은 경우
: 시스템이 "재고 부족" 메시지 표시
: 사용자가 수량을 줄이거나 다른 메뉴를 선택함
: 조정이 완료되면 다시 결제 진행- UML 유즈케이스 다이어그램 예시:
유즈케이스 다이어그램에 Actor인 User가 왼쪽에 표현되어 있고 Order Food라는 시스템이 담당하는 System Boundary가 오른쪽에 표현되어 있습니다. Order Food의 내부 기능들로 Use Case들이 타원형으로 그려져 있습니다. 기본 흐름은 다이어그램에서 직접적으로 표시되지는 않지만, 특정 조건에서만 실행되는 예외 흐름은 'Make Payment → Display Out-of-Stock Message' 사이에 <extend> 표시로 점선으로 그려져있습니다.
실무에서 활용되는 유즈케이스
- 요구사항 정의서를 만들 때
- 기능 명세서를 작성할 때
- QA 테스트 시나리오를 도출할 때
- 화면 설계 이전 사용자 흐름을 정리할 때
- 팀원들과 의사소통할 때
이렇게 작성한 유즈케이스는 무엇을 어떻게 만들고 테스트하고 설명할지가 나타나있어서 개발 과정에서 광범위하게 활용됩니다.
유즈케이스 다이어그램의 한계와 보완점
유즈케이스 다이어그램에서 User가 Launch App, Select Restaurant, Add to Cart, Make Payment, Display Out-of-Stock Message라는 기능을 수행할 수 있다는 것을 알 수 있습니다. 이를 통해 누가 어떤 기능을 쓰는지는 알 수 있지만, 구체적으로 어떤 객체가 언제 동작하고 어떤 구조로 연결되는지는 알 수 없습니다.
그래서 흐름을 시간 순서대로 정리하는 시퀀스 다이어그램과, 구조(객체, 속성, 관계)를 설계하는 클래스 다이어그램이 필요합니다.
예를 들어 시퀀스 다이어그램에서 유즈케이스 중 하나인 Make Payment의 기능을 만들게 된다면,
[User] → [OrderScreen] → [PaymentModule] → [PaymentAPI]
1. 사용자가 "결제" 버튼을 누름
2. 화면(OrderScreen)이 결제 모듈 호출
3. 결제 모듈이 외부 결제 API 요청
4. 응답 결과에 따라 결제 성공 또는 실패 처리
위와 같이 시간 순서대로 '언제', '누가', '무엇을 호출하는지' 명확히 표시할 수 있습니다.
그 다음에 이를 기반으로 클래스 다이어그램을 만들게 된다면,
클래스 다이어그램에 User, Order, PaymentManager, PaymentAPI라는 객체들이 필요합니다.
User: 주문을 요청
Order: 주문 정보 보유
PaymentManager: 결제 처리 담당
PaymentAPI: 외부 결제 API와 통신
User ────> Order
Order ────> PaymentManager
PaymentManager ────> PaymentAPI
그리고 각각의 객체들이 어디로 연결이 되는지, 어떤 데이터를 갖게 되는지 등의 정적인 구조를 표현할 수 있습니다.