유스 케이스 (usecase)

도입

유스 케이스는 화면 목록이나 기능 목록이 아니라, 액터가 목표를 달성하기 위해 시스템과 상호작용하는 흐름을 바깥에서 설명하는 요구사항 모델이다.

개발을 시작할 때 가장 자주 생기는 문제 중 하나는 시스템이 무엇을 해야 하는지와, 내부적으로 어떻게 만들 것인지를 너무 일찍 섞어 생각한다는 점입니다.

유스 케이스는 이 혼선을 줄이기 위해 시스템을 사용하는 외부 역할과 그 목표를 기준으로 요구사항을 정리합니다. 즉 사용자나 외부 시스템이 무엇을 원하고, 시스템은 어떤 관찰 가능한 결과를 제공해야 하는지를 먼저 구조화합니다.

그래서 유스 케이스를 이해한다는 것은 단순히 UML 타원을 그리는 법을 아는 것이 아니라, 요구사항을 사용자 목표 중심으로 모델링하는 관점을 이해하는 일에 가깝습니다.

필요성

요구사항이 커질수록 기능을 안쪽 구현 기준으로 나누는 것보다, 외부 액터의 목표와 시스템 경계를 기준으로 정리하는 편이 범위와 책임을 훨씬 선명하게 만든다

실무에서 요구사항이 흔들리는 가장 큰 이유는 “무엇을 만들 것인가”보다 “누가 왜 이 기능을 쓰는가”가 먼저 정리되지 않기 때문입니다. 이 상태에서는 화면, API, DB 테이블, 내부 서비스 단위가 뒤섞여 전체 시스템 범위가 흐려지기 쉽습니다.

유스 케이스는 요구사항을 액터와 목표 중심으로 재배치합니다. 그래서 프로젝트 초기에 시스템 범위를 맞추고, 분석 단계에서는 필요한 도메인 개념과 책임을 찾고, 이후 테스트 단계에서는 시나리오 기반 검증 포인트를 도출하는 데까지 자연스럽게 연결됩니다.

즉 유스 케이스의 강점은 다이어그램이 예뻐 보이는 데 있지 않고, 기능을 외부 관점에서 정리해 팀 전체가 같은 시스템 경계를 공유하게 만든다는 점에 있습니다.

유스 케이스가 특히 유용한 지점

• 시스템 범위와 외부 액터를 명확히 구분하기 좋음
• 기능 요구사항을 사용자 목표 중심으로 구조화하기 쉬움
• 기본 흐름과 예외 흐름을 요구사항 단계에서 분리하기 좋음
• 테스트 시나리오와 인수 기준으로 연결하기 쉬움

정의

유스 케이스는 시스템이 수행하는 일련의 행동 중 액터에게 가치 있는 관찰 가능한 결과를 제공하는 하나의 기능 흐름을 뜻한다

유스 케이스는 보통 “사용자가 무엇을 할 수 있다”를 설명하는 단위처럼 보이지만, 더 정확히는 시스템이 외부 액터와 상호작용하면서 어떤 결과를 제공하는지를 설명하는 기능 단위입니다.

중요한 점은 이 설명이 내부 구현이 아니라 외부 관찰 가능한 행위 기준이라는 것입니다. 따라서 유스 케이스는 시스템이 무엇을 해야 하는지를 보여주지만, 어떤 클래스가 호출되고 어떤 알고리즘을 쓰는지는 직접 설명하지 않습니다.

또 유스 케이스는 다이어그램 안의 타원 하나로 끝나는 것이 아니라, 실제로는 텍스트 명세와 함께 써야 의미가 살아납니다. 즉 다이어그램은 범위와 관계를 보여주고, 명세는 흐름과 조건을 설명합니다.

핵심 메시지

"좋은 유스 케이스는 기능을 나열하는 문서가 아니라

액터의 목표와 시스템의 책임을 바깥에서 맞춰 주는 요구사항 모델에 가깝습니다."

핵심 원리

유스 케이스의 핵심은 시스템을 안에서 분해하는 것이 아니라, 바깥의 액터가 어떤 목표를 달성하려는지와 시스템이 그 목표에 어떻게 응답하는지를 흐름으로 잡아내는 데 있다

따라서 유스 케이스는 화면 설계서나 API 명세서와 시선이 다릅니다. 유스 케이스는 먼저 “누가”, “무엇을 달성하려 하는가”, “시스템은 어떤 결과를 돌려주는가”를 봅니다.

이 관점을 지키면 요구사항 초기에 화면 이름, 버튼 위치, 테이블 구조 같은 내부 결정이 너무 빨리 들어오는 것을 막을 수 있습니다. 대신 기본 흐름과 예외 흐름, 선행 조건과 종료 상태를 더 선명하게 정리할 수 있습니다.

즉 유스 케이스는 “어떻게 구현할까”보다 “시스템이 어떤 책임을 져야 하는가”를 먼저 확정하는 도구라고 보는 편이 맞습니다.

그래서 좋은 유스 케이스는 내부 구조가 아니라 사용자 목표와 시스템 경계를 안정적으로 보여 줍니다.

Outside-In Requirement View
1) 액터가 목표를 가진다
2) 액터가 시스템에 행동을 요청한다
3) 시스템이 응답한다
4) 기본 흐름과 대안 흐름이 드러난다
5) 최종적으로 관찰 가능한 결과가 남는다

구성 요소

유스 케이스를 제대로 읽으려면 액터, 유스 케이스, 관계, 시스템 경계가 각각 무엇을 뜻하는지 구분해서 봐야 한다

요소	역할	실무 해석
Actor	시스템과 상호작용하는 외부 역할	사람 한 명이 아니라 역할이며, 인간·조직·기계·외부 시스템도 가능
Use Case	액터 목표를 달성하기 위한 시스템의 기능 흐름	관찰 가능한 결과와 가치가 있어야 함
Association	액터와 유스 케이스의 상호작용 연결	누가 어떤 기능을 사용하거나 참여하는지 표현
Include	한 유스 케이스가 다른 유스 케이스의 기능을 포함	공통 행동 재사용에 적합
Extend	기본 유스 케이스의 행동을 선택적·조건부로 확장	옵션 흐름이나 특정 조건에서만 붙는 행동을 표현
Generalization	더 구체적인 액터 또는 유스 케이스가 상위 것을 특수화	역할 계층이나 기능 특수화가 있을 때 사용
System Boundary	시스템 내부 유스 케이스와 외부 액터를 구분하는 경계	자주 쓰이지만 본질적으로는 시각적 보조 요소에 가깝다

특히 액터를 “회원 A”처럼 특정 개인으로 적는 경우가 많은데, 유스 케이스의 액터는 개별 인물이 아니라 시스템과 상호작용하는 역할입니다. 그래서 “고객”, “관리자”, “결제 시스템”처럼 역할과 외부 주체 관점으로 잡는 편이 더 정확합니다.

기본 구조

좋은 유스 케이스 모델은 다이어그램 하나로 끝나지 않고, 다이어그램과 텍스트 명세가 서로 보완하는 구조를 가진다

유스 케이스 다이어그램은 시스템 범위와 액터, 주요 기능, 기능 간 관계를 빠르게 보여 주는 데 강합니다. 하지만 다이어그램만으로는 실제 흐름과 예외를 충분히 담기 어렵습니다.

그래서 실무에서는 다이어그램 옆에 텍스트 명세를 붙입니다. 보통 유스 케이스 이름, 간단 설명, 기본 흐름, 대안 흐름, 특수 요구사항, 선행 조건, 후행 조건, 확장 지점을 함께 기술합니다.

또 시스템 boundary 박스는 자주 그리지만, 그것 자체가 모델의 본질을 바꾸는 것은 아닙니다. 중요한 것은 박스를 그렸는지가 아니라, 무엇이 시스템 안이고 무엇이 바깥인지 팀이 명확히 합의했는지입니다.

Use Case Model
├── Use Case Diagram
│   ├── Actor
│   ├── Use Case
│   ├── Association / Include / Extend / Generalization
│   └── System Boundary
└── Use Case Specification
    ├── Use case name
    ├── Brief description
    ├── Basic flow
    ├── Alternative flows
    ├── Special requirements
    ├── Preconditions
    ├── Postconditions
    └── Extension points

기본 작성

유스 케이스를 가장 빠르게 이해하는 방법은 액터 목표 하나를 잡고, 기본 흐름과 대안 흐름이 어떻게 분리되는지 실제 명세 형태로 보는 것이다

Use Case Name
주문하기

Primary Actor
고객

Brief Description
고객이 상품을 선택하고 주문을 생성한다.

Preconditions
- 고객이 로그인한 상태다
- 장바구니에 주문 가능한 상품이 있다

Basic Flow
1. 고객이 주문하기를 요청한다
2. 시스템이 주문 요약 정보를 보여준다
3. 고객이 배송지와 결제 수단을 입력한다
4. 시스템이 재고와 결제 가능 여부를 확인한다
5. 시스템이 주문을 생성한다
6. 시스템이 주문 번호와 결과를 보여준다

Alternative Flows
A1. 재고가 부족하다
- 시스템이 부족한 상품을 알려주고 수량 수정을 요청한다

A2. 결제가 실패한다
- 시스템이 실패 사유를 보여주고 재시도를 허용한다

Special Requirements
- 주문 확정 응답은 3초 이내여야 한다
- 주문 생성 시 감사 로그를 남겨야 한다

Postconditions
- 주문이 저장된다
- 주문 번호가 발급된다

실전 포인트

이 명세에서 중요한 것은 UI 위치나 버튼 색이 아니라, 액터의 목표가 어떤 흐름으로 완료되고 어디서 실패하거나 갈라지는지입니다. 유스 케이스 텍스트는 시스템이 무엇을 해야 하는지를 써야지, 화면을 픽셀 단위로 설명하는 문서가 되어서는 안 됩니다.

패턴 1. 액터와 목표 중심으로 이름 붙이기

좋은 유스 케이스 이름은 메뉴나 화면이 아니라, 액터가 달성하려는 목표나 관찰 가능한 결과를 드러내는 동사 중심 표현에 가깝다

유스 케이스 이름은 단순히 기능 라벨이 아니라 그 유스 케이스의 목적을 가장 짧게 요약하는 문장입니다. 따라서 “회원 화면”, “주문 API”, “결제 모듈” 같은 내부 지향 이름보다 “회원가입”, “주문하기”, “비밀번호 재설정” 같은 목표 지향 이름이 더 자연스럽습니다.

즉 유스 케이스 이름은 시스템 내부 구조보다 액터가 얻고자 하는 결과를 반영해야 합니다. 그래야 이름만 봐도 이 유스 케이스가 왜 존재하는지 바로 드러납니다.

좋은 예
- 회원가입
- 주문하기
- 환불 요청
- 배송 조회

아쉬운 예
- 회원 화면
- 주문 API 호출
- 환불 서비스
- 배송 테이블 조회

패턴 2. 기본 흐름과 대안 흐름을 분리하기

유스 케이스 명세는 정상 시나리오와 예외 시나리오를 한 줄로 뒤섞기보다, 기본 흐름과 대안 흐름으로 나누어 읽히게 만들어야 한다

많은 문서가 읽기 어려워지는 이유는 정상 흐름과 예외 흐름이 한 문단 안에 섞여 있기 때문입니다. 유스 케이스는 흐름을 구조화하려는 문서이므로, 가장 이상적인 기본 흐름을 먼저 잡고 예외나 분기 상황은 alternative flow로 분리하는 편이 좋습니다.

이렇게 하면 구현과 테스트에서도 장점이 큽니다. 기본 흐름은 happy path 테스트로 연결되고, 대안 흐름은 실패 케이스와 경계 조건 테스트로 이어지기 쉽습니다.

Basic Flow
- 정상적으로 끝나는 가장 대표적인 경로

Alternative Flows
- 인증 실패
- 입력값 오류
- 재고 부족
- 외부 시스템 응답 지연
- 권한 없음

패턴 3. include 와 extend 를 무리해서 쓰지 않기

include 는 공통 행동 재사용, extend 는 선택적·조건부 확장에 맞지만, 관계를 남발하면 오히려 기본 흐름보다 관계 해석이 더 어려워진다

include 는 여러 유스 케이스에서 반복되는 공통 행동을 재사용하고 싶을 때 적합합니다. 반대로 extend 는 기본 유스 케이스가 스스로는 완결되지만, 특정 조건이나 옵션에 따라 추가 행동이 붙는 경우에 더 자연스럽습니다.

문제는 이 관계들을 너무 많이 쓰기 시작하면, 정작 독자가 읽어야 할 기본 흐름보다 화살표 해석이 더 어려워진다는 점입니다. 그래서 관계는 꼭 의미가 명확한 경우에만 쓰는 편이 좋습니다.

예시
주문하기 <<include>> 결제하기
주문하기 <<extend>> 선물 포장 요청

해석
- include : 공통 또는 재사용되는 행동
- extend : 특정 조건에서만 붙는 선택적 행동

핵심 포인트

유스 케이스 모델이 복잡해질수록 화살표를 더 추가하기보다, 먼저 기본 유스 케이스 자체가 단독으로 읽히는지부터 확인하는 편이 훨씬 중요합니다. 관계는 구조를 분명하게 만들 때만 써야지, 복잡함을 숨기는 용도로 쓰면 안 됩니다.

한계와 주의점

유스 케이스는 요구사항과 범위를 정리하는 데 강하지만, 내부 설계와 화면 설계와의 경계를 지키지 않으면 금방 애매한 문서가 된다

유스 케이스의 가장 큰 장점은 바깥 관점이라는 점이지만, 동시에 가장 흔한 함정도 같은 지점에 있습니다. 외부 목표를 설명해야 하는 문서에 UI 레이아웃, 데이터베이스 컬럼, 서비스 메서드 이름이 섞이기 시작하면 문서의 성격이 빠르게 흐려집니다.

또 반대로 다이어그램만 그려 놓고 텍스트 흐름을 쓰지 않으면, 요구사항이 너무 추상적으로 남아 실제 개발과 테스트 단계에 도움이 되지 않을 수 있습니다.

즉 유스 케이스는 모든 걸 설명하는 문서가 아니라, 시스템의 외부 행위와 목표를 정리하는 문서라는 경계를 지켜야 가치가 살아납니다.

주의해야 할 지점

• 유스 케이스를 화면 목록이나 메뉴 구조로 오해하지 않기
• 텍스트 명세 없이 다이어그램만 남겨 두지 않기
• UI 디테일과 내부 구현을 흐름에 과하게 섞지 않기
• include 와 extend 를 관계 자체를 위해 남발하지 않기

자주 하는 실수

유스 케이스를 어렵게 만드는 가장 흔한 원인은 문법보다도, 액터·목표·시스템 경계·흐름을 서로 다른 층위로 분리하지 않는 데 있다

• 액터를 특정 사용자 개인이나 계정 이름으로 적음
• 유스 케이스 이름을 화면명, 메뉴명, API명으로 적음
• 기본 흐름과 예외 흐름을 한 문단에 섞어 버림
• 유스 케이스 안에 UI 위치나 내부 알고리즘을 너무 자세히 씀
• 모든 공통 행동을 억지로 include 로 뽑아 모델을 복잡하게 만듦
• 시스템 boundary 를 명확히 잡지 않아 내부와 외부가 섞임

실무 루틴

유스 케이스를 작성할 때는 먼저 시스템 경계를 정하고, 액터 목표를 뽑은 뒤, 기본 흐름과 대안 흐름을 텍스트로 고정하는 순서가 가장 안전하다

1. 먼저 무엇이 시스템 안이고 밖인지 boundary 를 정한다.
2. 시스템과 상호작용하는 외부 역할을 actor 로 식별한다.
3. 각 액터가 달성하려는 목표를 기준으로 유스 케이스 후보를 뽑는다.
4. 유스 케이스 이름은 화면명보다 목표/결과 중심 동사 표현 으로 정한다.
5. 각 유스 케이스마다 basic flow 와 alternative flows 를 먼저 쓴다.
6. 필요한 경우 preconditions, postconditions, special requirements 를 붙인다.

검토

유스 케이스 문서를 검토할 때는 다이어그램의 예쁨보다, 각 유스 케이스가 정말 가치 있는 결과를 만들고 흐름이 읽히는지부터 확인해야 한다

1

각 유스 케이스가 액터에게 실제로 가치 있는 관찰 가능한 결과를 주는지 본다.

2

액터가 특정 인물이 아니라 외부 역할로 잡혀 있는지 확인한다.

3

기본 흐름이 혼자서도 읽히는지, 예외 흐름이 분리되어 있는지 점검한다.

4

문서가 시스템이 무엇을 하는지를 설명하는지, 아니면 어떻게 구현하는지를 설명하고 있는지 구분한다.

5

include 와 extend 가 정말 관계를 명확히 하는지, 아니면 복잡성만 추가하는지 본다.

점검 체크리스트
- 이 유스 케이스는 누구의 목표를 다루는가
- 시스템 boundary 가 명확한가
- 이름이 목표/결과 중심인가
- basic flow 와 alternative flows 가 분리되었는가
- UI/DB/알고리즘 디테일이 과하게 섞이지 않았는가
- include / extend 사용 이유가 분명한가

요약

유스 케이스의 핵심은 기능을 안쪽 구조가 아니라 액터의 목표와 시스템의 책임 기준으로 정리하고, 다이어그램과 텍스트 명세를 함께 사용해 요구사항을 바깥에서 구조화하는 데 있다

• ✅ 유스 케이스는 액터와 시스템의 상호작용 속에서 가치 있는 결과를 만드는 기능 흐름이다.
• ✅ 유스 케이스 다이어그램은 시스템의 고수준 기능과 범위, 액터와의 상호작용을 보여준다.
• ✅ 다이어그램만으로는 부족하고 텍스트 specification 이 함께 가야 한다.
• ✅ 액터는 특정 개인이 아니라 시스템과 상호작용하는 외부 역할이다.
• ✅ 기본 흐름과 대안 흐름을 나눌수록 구현과 테스트 연결이 쉬워진다.
• ✅ include 는 공통 행동 재사용, extend 는 선택적·조건부 확장에 가깝다.
• ✅ system boundary 는 자주 쓰이지만 본질적으로는 시각적 보조 요소다.
• ✅ 좋은 유스 케이스는 내부 구현이 아니라 시스템이 무엇을 해야 하는지를 바깥에서 보여 준다.

 

RELATED POST

유저 스토리와 유스 케이스는 무엇이 다를까
시퀀스 다이어그램은 유스 케이스와 어떻게 연결될까
기능 요구사항과 비기능 요구사항을 어떻게 나눌까

 

REFERENCE

UML 2.5.1 Specification
Defining use cases
Use-case diagrams
Use case specification outline
Relationships in use-case diagrams
Defining the boundaries of a system