Use Case란 무엇인가
Use Case는 사용자(Actor)가 시스템과 상호작용하여 가치 있는 목표를 달성하는 시나리오다. "사용자가 사용할 부분"에 대한 고민이 맞지만, UI 설계가 아니라 기능적 목표에 집중한다.
Use Case의 정의
Actor가 시스템과 상호작용하여 측정 가능한 가치 있는 목표를 달성하는 시나리오
핵심 요소
- Actor (행위자): 시스템을 사용하는 주체
- Goal (목표): 달성하려는 가치 있는 결과
- Scenario (시나리오): 목표를 달성하기 위한 상호작용 흐름
Use Case ≠ UI 설계
흔한 오해
많은 사람들이 Use Case를 "화면 설계"나 "사용자 인터페이스 명세"로 착각한다.
잘못된 이해:
"로그인 버튼을 누른다"
"메뉴에서 '구매'를 선택한다"
"텍스트 박스에 수량을 입력한다"
올바른 이해:
"시스템에 인증된 접근을 얻는다"
"상품을 구매한다"
"재고 수량을 조회한다"
Use Case vs UI
| 측면 | Use Case | UI 설계 | | --- | ------------ | --------- | | 초점 | 무엇을 (What) | 어떻게 (How) | | 수준 | 비즈니스 목표 | 인터랙션 디테일 | | 독립성 | 구현 독립적 | 구현 의존적 | | 재사용 | 여러 UI로 구현 가능 | 특정 플랫폼 | | | | |
예시:
Use Case: "상품 구매"
→ 한 가지 비즈니스 목표
이를 구현하는 다양한 UI:
- 웹 브라우저 (React)
- 모바일 앱 (iOS/Android)
- 키오스크
- 음성 주문 (Alexa)
- API 호출 (서버 간 통신)
→ Use Case는 같지만 UI는 다름
목표 중심 (Goal-Oriented)
Use Case는 **"어떻게"가 아니라 "무엇을"**에 집중한다.
잘못된 예 (UI 중심)
❌ Use Case: 로그인
1. 사용자가 로그인 페이지를 연다
2. 사용자가 아이디 입력창에 아이디를 입력한다
3. 사용자가 비밀번호 입력창에 비밀번호를 입력한다
4. 사용자가 "로그인" 버튼을 클릭한다
5. 시스템이 메인 페이지로 리다이렉트한다
문제점:
- UI 구현에 종속적
- "입력창", "버튼"은 구현 세부사항
- 본질적 목표가 무엇인지 불명확
올바른 예 (목표 중심)
✓ Use Case: Authenticate User
Main Success Scenario:
1. 사용자가 인증 정보를 제공한다
2. 시스템이 인증 정보를 검증한다
3. 시스템이 사용자 세션을 생성한다
4. 시스템이 사용자 권한을 로드한다
Extensions:
2a. 인증 정보가 올바르지 않음:
2a1. 시스템이 에러 메시지를 표시한다
2a2. Use Case가 1단계로 돌아간다
장점:
- 구현 독립적
- 본질적 목표가 명확
- 다양한 방식으로 구현 가능 (폼, OAuth, 생체인식 등)
가치 있는 결과 (Valuable Result)
Use Case는 사용자에게 측정 가능한 가치를 제공해야 한다.
Elementary Business Process (EBP)
Ivar Jacobson의 정의:
"한 사람이, 한 장소에서, 한 시간에 수행하여 측정 가능한 비즈니스 가치를 남기는 작업"
가치 판단 기준
질문: "이 작업이 끝나면 무엇이 달라지는가?"
✓ "상품 구매"
→ 고객이 상품을 얻고, 돈을 지불함 (가치 있음)
✓ "환불 처리"
→ 고객이 돈을 돌려받고, 상품을 반환함 (가치 있음)
❌ "커서를 이동한다"
→ 아무것도 달라지지 않음 (가치 없음)
❌ "데이터를 검증한다"
→ 독립적으로 가치 없음 (다른 Use Case의 일부일 뿐)
Use Case의 구조
Use Case는 Actor와 System의 대화(Dialog) 형식으로 작성된다.
기본 구조
Use Case Name: [동사 + 목적어]
Primary Actor: [누가]
Preconditions: [전제 조건]
Main Success Scenario:
1. Actor의 행동
2. System의 반응
3. Actor의 행동
4. System의 반응
...
Extensions (예외 흐름):
[X]a. [조건]:
[X]a1. [처리]
[X]a2. [처리]
실제 예시: Process Sale
Use Case: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: 빠르고 정확한 처리, 에러 최소화
- Customer: 정확한 금액, 빠른 처리
- Company: 정확한 매출 기록
Preconditions:
- Cashier가 인증되고 로그인됨
Success Guarantee (Postconditions):
- Sale이 저장됨
- Tax가 올바르게 계산됨
- 재고가 갱신됨
- 회계 시스템과 동기화됨
Main Success Scenario:
1. Customer가 상품들을 가지고 계산대에 도착한다
2. Cashier가 새 판매를 시작한다
3. Cashier가 상품 식별자를 입력한다
4. System이 상품 정보와 running total을 기록하고 표시한다
Cashier가 3-4를 상품이 남아있는 동안 반복한다
5. System이 tax를 계산하고 total을 표시한다
6. Cashier가 Customer에게 total을 알린다
7. Customer가 결제한다 (현금 또는 카드)
8. System이 결제를 처리한다
9. System이 sale을 완료로 기록한다
10. System이 영수증을 생성한다
11. Cashier가 영수증을 Customer에게 제공한다
Extensions (Alternative Flows):
3a. Invalid item identifier:
3a1. System이 에러를 표시하고 재입력을 요청한다
3b. 상품에 여러 개가 있음:
3b1. Cashier가 수량을 입력한다
3b2. System이 수량만큼 line item을 기록한다
7a. Customer가 카드로 결제:
7a1. System이 Payment Authorization Service와 통신한다
7a2. System이 승인 번호를 받아 기록한다
7b. Customer가 충분한 현금이 없음:
7b1. System이 부족 금액을 표시한다
7b2. Customer가 일부 상품을 제거한다
7b3. Use Case가 3단계로 돌아간다
*a. System이 언제든지 실패할 수 있음:
*a1. Cashier가 시스템을 재시작한다
*a2. System이 sale 상태를 복구한다
*a3. Use Case가 중단된 단계로 돌아간다
Use Case의 수준 (Levels)
Use Case는 추상화 수준에 따라 여러 레벨로 나뉜다.
1. Summary Level (요약 수준)
특징:
- 매우 넓은 범위
- 여러 세션에 걸침
- 여러 User Goal을 포함
예시:
- "온라인 쇼핑을 한다"
- "고객 관계를 관리한다"
- "사업을 운영한다"
사용:
- 시스템 전체 개요
- 컨텍스트 다이어그램
2. User Goal Level (사용자 목표 수준) ⭐
특징:
- 한 세션에서 달성 가능
- Elementary Business Process
- 가장 중요하고 일반적인 수준
예시:
- "상품을 구매한다"
- "환불을 처리한다"
- "재고를 조회한다"
- "회원으로 가입한다"
Larman이 집중하는 수준
3. Subfunction Level (하위 기능 수준)
특징:
- 너무 작음
- 독립적 가치 없음
- User Goal의 일부
예시:
- "신용카드를 검증한다"
- "세금을 계산한다"
- "재고를 차감한다"
사용:
- User Goal Use Case 내부의 step으로 표현
- 별도 Use Case로는 거의 쓰지 않음
수준 선택 가이드
질문: "CEO가 알고 싶어하는 작업인가?"
Yes → User Goal Level
- "오늘 몇 건의 판매가 있었나?"
- "얼마나 많은 환불이 처리됐나?"
No → Subfunction Level
- "세금 계산이 몇 번 실행됐나?" (CEO는 관심 없음)
Use Case 작성 형식
Larman은 세 가지 형식을 제시한다.
1. Brief (간략 형식)
언제: how-to-conduct-inception의 Inception 단계
내용: Use Case 이름 + 한 줄 요약
예시:
Process Sale: 고객이 상품을 구매한다
Handle Returns: 고객이 상품을 반품한다
2. Casual (비공식 형식)
언제: 초기 Elaboration
내용:
- Main Success Scenario만 간단히
- 단락 형식
예시:
Process Sale
Customer가 상품들을 가지고 온다. Cashier가 각 상품을 스캔한다.
System이 가격을 표시하고 running total을 계산한다.
모든 상품이 입력되면 total이 계산되고 Customer가 결제한다.
System이 sale을 기록하고 영수증을 출력한다.
3. Fully Dressed (완전 형식)
언제: Elaboration 후반, 핵심 Use Case에 대해
내용:
- Stakeholders and Interests
- Preconditions
- Postconditions
- Main Success Scenario (단계별)
- Extensions (모든 예외 경우)
- Special Requirements
- Technology and Data Variations
예시: 위의 "Process Sale" 완전 버전 참조
Actor (행위자)
Use Case의 주체가 되는 역할을 Actor라 한다.
Actor의 종류
1. Primary Actor:
- Use Case를 시작하는 주체
- 가치를 받는 주체
- 예: Customer, Cashier, Manager
2. Supporting Actor:
- 시스템이 서비스를 요청하는 외부 주체
- 예: Payment Service, Tax Calculator, Inventory System
3. Offstage Actor:
- Use Case에 이해관계가 있지만 직접 상호작용하지 않음
- 예: Government Tax Agency (세금 규정 준수)
Actor는 역할이다
중요: Actor는 "사람"이 아니라 **역할(Role)**이다.
✓ "Cashier" (역할)
✓ "Manager" (역할)
✓ "System Administrator" (역할)
❌ "홍길동" (특정 사람)
❌ "Alice" (특정 사람)
같은 사람이 여러 역할:
- Alice가 낮에는 Cashier
- Alice가 저녁에는 Manager
- → Alice는 두 Actor의 역할을 한다
외부 시스템도 Actor
Actor: Payment Authorization Service
- 카드 승인 요청을 처리
- 시스템 관점에서는 "외부 행위자"
Actor: Tax Calculator Service
- 세금 계산 서비스
- 시스템과 상호작용하는 외부 주체
Use Case와 요구사항
Use Case는 기능 요구사항을 포착하는 주요 방법이다.
Functional Requirements
Use Case로 표현:
- "무엇을 해야 하는가?"
- "어떤 기능이 필요한가?"
예시:
Use Case: Process Sale
→ 판매 처리 기능 필요
→ 재고 갱신 기능 필요
→ 영수증 생성 기능 필요
Non-Functional Requirements
Use Case로 표현하기 어려움:
- 성능: "응답 시간 2초 이내"
- 보안: "HTTPS 필수"
- 가용성: "99.9% uptime"
→ Supplementary Specification에 별도로 기록
Use Case = System Requirements
Use Cases + Supplementary Specification
= 완전한 시스템 요구사항
Use Case 작성 가이드라인
1. 사용자 의도에 집중
질문: "사용자는 왜 이 작업을 하는가?"
❌ "데이터베이스에 레코드를 삽입한다"
→ 구현 세부사항
✓ "판매 기록을 저장한다"
→ 비즈니스 의도
2. Essential Style 유지
Essential UI-Free Style:
- UI 요소 언급 안 함
- "버튼", "클릭", "입력창" 같은 단어 제거
❌ "Cashier가 'New Sale' 버튼을 클릭한다"
✓ "Cashier가 새 판매를 시작한다"
❌ "System이 팝업창에 메시지를 표시한다"
✓ "System이 에러를 알린다"
3. Black Box 스타일
시스템 내부 동작을 설명하지 않음:
❌ "System이 데이터베이스 트랜잭션을 시작하고,
Sale 테이블에 INSERT하고, 커밋한다"
✓ "System이 sale을 저장한다"
4. Actor-System 대화
주체를 명확히:
1. Cashier가 새 판매를 시작한다 (Actor)
2. System이 빈 판매 화면을 표시한다 (System)
3. Cashier가 상품 ID를 입력한다 (Actor)
4. System이 상품을 기록하고 total을 갱신한다 (System)
실전 팁
Inception에서
간략하게:
- Use Case 이름만 나열
- 한 줄 설명 추가 (선택)
- 상세 시나리오 ❌
핵심 Use Case (10-20%):
- Process Sale
- Handle Returns
- Cash In/Out
Elaboration에서
핵심부터 상세하게:
- 가장 중요한 2-3개부터 Fully Dressed로
- 나머지는 Casual로
- 모든 Use Case를 Fully Dressed로 쓸 필요 없음
우선순위 기준:
- 비즈니스 가치가 높은 것
- 아키텍처적으로 중요한 것
- 리스크가 높은 것
Use Case의 가치
1. 공통 언어
- 개발자, 사용자, 관리자가 같은 언어로 소통
- "Process Sale"이라는 용어로 모두가 이해
2. 범위 관리
- 무엇이 시스템 내부인가?
- 무엇이 시스템 외부인가?
- 프로젝트 범위 정의
3. 테스트 케이스 기반
Use Case: Process Sale
Main Success Scenario
→ Happy Path 테스트
Extensions:
3a. Invalid item
→ 예외 처리 테스트
7a. Card payment
→ 통합 테스트
4. 사용자 매뉴얼 기반
- Use Case = 사용자 작업
- 매뉴얼 구조의 기반
핵심 정리
Use Case는:
- ✓ 사용자의 목표 중심
- ✓ 비즈니스 가치 제공
- ✓ Actor와 System의 대화
- ✓ 기능 요구사항 포착
Use Case는 아니다:
- ❌ UI 설계서
- ❌ 화면 흐름도
- ❌ 구현 명세서
- ❌ 시스템 내부 동작 설명
Larman의 강조:
- User Goal Level에 집중
- Essential (UI-Free) Style 사용
- Black Box 관점 유지
- Iterative하게 정제 (처음부터 완벽하게 ❌)