유스케이스와 UML

요구사항을 사용자의 말로 다시 쓰기

9장과 10장에서 책마루의 데이터 구조와 클래스를 설계했다. 하지만 이 작업은 대부분 개발자와 분석가의 시선에서 이루어졌다 — "결제 클래스는 이런 속성과 동작을 가진다"는 식이다. 정작 이 시스템을 쓸 손님과 직원 입장에서는 "나는 이 시스템으로 무엇을 할 수 있는가"가 더 궁금하다.

유스케이스(use case) 기법은 이 질문에 답하기 위한 도구다. 시스템을 사용하는 외부 주체(액터)가 시스템에 대해 갖는 각각의 용도를 유스케이스로 식별하고, 그 상호작용을 시나리오로 풀어 쓴다. 이렇게 만든 유스케이스는 네 가지 역할을 한다.

• 합의 문서: 개발사와 고객(책마루 사장님) 사이에 "이 기능이 원래 범위에 있었는가"를 확인하는 근거가 된다. 4장에서 다룬 프로젝트 헌장이 프로젝트 전체의 범위를 정한다면, 유스케이스는 그 범위를 기능 단위로 훨씬 구체화한다.
• 범위 추정의 단위: 유스케이스 개수와 복잡도를 보면 시스템의 규모가 가늠되고, 이는 일정과 예산을 추정하는 실질적인 근거가 된다.
• 요구사항 추적의 고리: 하나의 요구사항이 어느 유스케이스에서 다뤄지는지 연결해두면, 나중에 "이 요구사항이 실제로 구현되었는가"를 유스케이스 단위로 추적할 수 있다.
• 인수 시험의 기준: 1장에서 다룬 시험의 네 층위 중 인수 시험은 결국 "각 유스케이스가 명세서대로 동작하는가"를 사장님이 직접 확인하는 과정이다.

이해관계자의 활발한 참여가 중요한 이유도 여기에 있다. 유스케이스를 분석가 혼자 상상으로 채우면 실제 사용 패턴과 어긋난 시나리오가 만들어지기 쉽고, 그 오차는 프로젝트 후반에 가서야 드러난다.

이해관계자에서 액터로

4장에서 책마루 프로젝트의 이해관계자를 사장님(스폰서), 매장 직원(현업 사용자), 손님(고객), 결제대행사·택배사(외부 이해관계자)로 정리했다. 유스케이스 다이어그램의 **액터(actor)**는 이 이해관계자 중에서도 시스템과 직접 상호작용하는 외부 주체만을 가리킨다. 모든 이해관계자가 액터가 되는 것은 아니다 — 사장님은 프로젝트의 스폰서이지만, 일상적으로 시스템을 직접 조작하는 주체는 아니므로 액터 목록에서는 빠지거나, 매장 직원과 같은 계정을 공유하는 것으로 단순화할 수 있다. 책마루처럼 작은 조직에서는 사장님도 필요하면 직원 계정으로 시스템을 쓰는 경우가 흔하다 — 굳이 "사장님" 액터를 별도로 만들 필요는 없다.

책마루 온라인 주문 시스템의 액터를 정리하면 이렇다.

여기서 회원은 비회원의 기능을 전부 포함하면서 추가 기능을 갖는다 — 이 관계는 액터 사이에도 일반화로 표현할 수 있다. 유스케이스 다이어그램에서는 비회원에서 회원으로 화살표를 그어(회원이 비회원을 일반화) 이 상속 관계를 나타낸다.

책마루 유스케이스 다이어그램을 텍스트로 그려보기

실제 다이어그램은 액터를 막대 인간 기호로, 유스케이스를 타원으로 그리고 그 사이를 선으로 잇지만, 여기서는 그 구조를 문장으로 풀어 설명한다.

비회원은 "상품목록조회"와 "상품검색" 두 유스케이스와 연결된다. 회원은 비회원을 일반화하므로 이 둘을 그대로 이어받고, 추가로 "장바구니담기", "주문하기", "회원정보수정"과 연결된다. 매장직원은 "재고등록", "재고수정", "주문확인", "포장처리", "배달상태갱신"과 연결된다.

유스케이스 사이에는 두 가지 특수한 관계가 등장한다.

• 포함관계(include): "주문하기"는 반드시 "결제하기"를 거쳐야 완료된다. 이럴 때 "주문하기"에서 "결제하기"로 점선 화살표를 긋고 «포함»이라고 표시한다 — 포함관계는 한 유스케이스가 다른 유스케이스를 반드시 수행해야 할 때 쓴다.
• 확장관계(extend): "상품목록조회" 중에 손님이 특정 상품을 클릭하면 "상품상세조회"로 넘어갈 수 있다. 이건 항상 일어나는 일이 아니라 특정 조건에서만 선택적으로 일어나므로, "상품상세조회"에서 "상품목록조회"로 점선 화살표를 긋고 «확장»이라고 표시한다.

10장에서 만든 결제 클래스의 일반화 구조는 유스케이스에서도 그대로 반복된다. "결제하기" 유스케이스가 상위에 있고, "카드결제하기"와 "계좌이체하기"가 그 하위 유스케이스로 일반화 관계를 맺는다 — 회원이 결제 수단을 고르면 그에 맞는 하위 유스케이스가 실행되는 식이다.

이 관계들을 모아 유스케이스 식별자 목록으로 정리하면 다음과 같다.

유스케이스 명세서 작성법

유스케이스 다이어그램은 "무엇이 있는가"의 목록일 뿐, "그 유스케이스가 정확히 어떻게 진행되는가"는 담지 못한다. 이 세부 흐름을 문서로 풀어낸 것이 유스케이스 명세서다. 정해진 국제 표준 양식은 없지만, 실무에서 널리 쓰이는 구성은 이렇다.

• 개요: 이 유스케이스가 무엇을 하는지 한두 문장으로 요약
• 행위자: 이 유스케이스를 시작하는 주 행위자와 관련 행위자
• 선행조건: 이 유스케이스가 시작되기 전에 이미 만족돼 있어야 하는 상태
• 후행조건: 유스케이스가 정상적으로 끝난 뒤의 상태
• 기본흐름: 가장 일반적인 경로로 처리되는 사건의 순서
• 대안흐름: 기본흐름과는 다르지만 여전히 정상적으로 처리되는 경로
• 예외흐름: 오류나 실패로 인해 기본흐름을 벗어나는 경로

명세서를 쓸 때 가장 흔히 저지르는 실수는 "어떻게(how) 구현할 것인가"까지 적어버리는 것이다. "결제 승인번호를 저장한다"까지는 무엇을 하는지에 대한 서술이지만, "승인번호를 VARCHAR(20) 컬럼에 저장한다"는 구현 방법이다. 유스케이스 명세서는 6장에서 강조한 "무엇과 어떻게의 분리" 원칙을 그대로 따른다 — 이 단계에서는 시스템이 무엇을 하는지만 적고, 어떻게 구현할지는 설계 단계(12장 이후)로 미룬다.

두 번째로 흔한 실수는 서술의 세밀함을 잘못 조절하는 것이다. 유스케이스 시나리오는 자세할수록 무조건 좋은 게 아니라, 고객이 읽고 이해할 수 있는 수준으로 쓰는 것이 중요하다. 책마루 사장님에게 "화면 왼쪽 상단의 드롭다운 메뉴를 클릭하면"까지 적힌 명세서를 보여주면 정작 "이 기능이 우리가 원했던 게 맞는지"를 판단하기보다 화면 배치를 두고 이야기가 흘러가 버린다. 화면 요소나 배치는 15장에서 다룰 사용자 인터페이스 설계의 영역이고, 유스케이스 명세서는 그보다 한 단계 위에서 "어떤 정보를 주고받는가"에 집중해야 한다.

책마루 "포장처리" 유스케이스 명세서 예시

두 번째 예시로 매장직원이 사용하는 유스케이스를 살펴보자. 손님 관점의 "주문하기"와 달리, 이번에는 매장 내부 업무를 담당하는 액터의 시나리오다.

개요: 매장직원이 결제완료 상태의 주문을 확인하고, 상품을 포장한 뒤 배달 또는 택배 발송 준비를 완료한다.

행위자: 매장직원 (주 행위자)

선행조건: 주문이 "결제완료" 상태이며, 아직 포장 담당 직원이 배정되지 않았다.

후행조건: 주문 상태가 "포장완료"로 바뀌고, 배달방법에 따라 배달 대기 목록 또는 택배 발송 목록에 등록된다.

기본흐름

1. 매장직원이 매장 태블릿에서 결제완료 상태의 주문 목록을 확인한다.
2. 매장직원이 포장할 주문을 선택하면, 시스템은 해당 주문에 자신을 담당 직원으로 배정한다.
3. 시스템이 주문에 담긴 상품 목록과 각 수량을 보여준다.
4. 매장직원이 상품을 실제로 포장하고, 포장이 끝난 상품을 하나씩 시스템에서 확인 처리한다.
5. 모든 상품의 포장 확인이 끝나면, 시스템은 주문 상태를 "포장완료"로 바꾼다.
6. 배달방법이 도보 배달이면 배달 대기 목록에, 택배 발송이면 택배 발송 목록에 해당 주문을 등록한다.

대안흐름

• A1. 여러 매장직원이 동시에 일하는 경우: 2단계에서 이미 다른 직원이 배정한 주문은 목록에서 "배정됨"으로 표시되어 중복 배정을 막는다.

예외흐름

• E1. 4단계에서 포장하려는 상품의 실제 재고가 시스템 수량과 맞지 않는 경우: 시스템은 불일치를 기록하고 매장직원이 사유(품절, 파손 등)를 선택하도록 안내한다. 이 경우 해당 주문은 사장님 확인이 필요한 상태로 표시된다.

이 명세서는 "주문하기"와 짝을 이루면서 하나의 주문이 손님의 관점(주문하기 → 결제하기)에서 시작해 직원의 관점(포장처리)으로 넘어가는 전체 흐름을 보여준다. 유스케이스를 액터별로 따로 작성하더라도, 이렇게 주문 상태(9장의 "주문상태" 속성, 10장의 상태 전환)를 기준으로 서로 이어보면 시스템 전체의 흐름이 끊기지 않는지 점검할 수 있다.

책마루 "주문하기" 유스케이스 명세서 예시

개요: 회원이 장바구니에 담긴 상품 중 일부 또는 전부를 선택해 주문을 확정한다.

행위자: 회원 (주 행위자)

선행조건: 회원으로 로그인한 상태이며, 장바구니에 상품이 한 개 이상 담겨 있다.

후행조건: 새 주문이 "결제대기" 상태로 생성되고, 결제하기 유스케이스로 이어진다.

기본흐름

1. 시스템이 회원의 장바구니에 담긴 상품 목록과 각 상품의 수량, 가격을 보여준다.
2. 회원이 주문할 상품을 선택한다.
3. 회원이 배송지 정보(도보 배달 가능 지역이면 자동으로 안내)를 확인하거나 입력한다.
4. 시스템이 선택된 상품의 재고를 확인한다.
5. 시스템이 예상 결제 금액(상품 금액 + 배송비)을 보여준다.
6. 회원이 주문을 확정하면, 시스템은 주문을 "결제대기" 상태로 생성하고 결제하기 유스케이스를 포함관계로 실행한다.

대안흐름

• A1. 회원이 장바구니에서 일부 상품만 선택해 주문하는 경우: 선택되지 않은 상품은 장바구니에 그대로 남는다.

예외흐름

• E1. 4단계에서 선택한 상품 중 재고가 부족한 상품이 있는 경우: 시스템은 해당 상품과 부족 수량을 보여주고, 회원이 수량을 조정하거나 해당 상품을 제외하고 진행하도록 안내한다.
• E2. 3단계에서 입력한 배송지가 책마루의 배달 가능 지역 밖인 경우: 시스템은 택배 배송으로 전환하고 예상 배송비를 다시 계산해 5단계로 돌아간다.

이 명세서 하나만 봐도 여러 장에서 다룬 개념이 자연스럽게 모여드는 걸 볼 수 있다. 재고 확인은 9장의 "상품" 엔티티, 배송지 판단은 1장에서 예로 든 "배달 가능 지역 자동 확인" 요구사항, 결제하기로의 포함관계는 이번 장 앞부분에서 정의한 유스케이스 관계, 그리고 뒤이어 실행되는 결제하기 유스케이스는 10장에서 설계한 결제 클래스 구조와 맞닿아 있다.

핵심 정리

• 유스케이스는 시스템과 직접 상호작용하는 외부 주체(액터)의 관점에서 시스템의 용도를 식별하는 기법이며, 개발자와 고객 사이의 합의 문서이자 인수 시험의 기준이 된다.
• 모든 이해관계자가 액터가 되지는 않는다 — 액터는 시스템과 직접 상호작용하는 주체로 한정된다.
• 유스케이스 사이의 관계는 포함관계(반드시 수행), 확장관계(조건부로 선택 수행), 일반화(공통 유스케이스를 하위 유스케이스가 구체화)로 표현한다.
• 유스케이스 명세서는 개요·행위자·선행조건·후행조건·기본흐름·대안흐름·예외흐름으로 구성되며, "무엇을 하는가"만 적고 "어떻게 구현하는가"는 설계 단계로 미룬다.
• 유스케이스 명세서는 앞서 만든 정보 모델과 객체 모델을 사용자 관점의 시나리오로 다시 엮어내는 역할을 한다.

다음 장(12장, 소프트웨어 설계)에서는 지금까지 요구사항 분석 단계(6~11장)에서 만든 정보 모델·객체 모델·유스케이스를 실제로 구현 가능한 구조로 바꾸는 설계 단계로 넘어간다. 책마루 시스템을 어떤 하위 구성요소로 나누고, 각 구성요소가 어떻게 통신할지가 이제부터의 주제다.