147. 유스케이스 다이어그램 (Use Case Diagram) - 액터, 유스케이스, 관계(포함, 확장)

핵심 인사이트 (3줄 요약)

본질: 유스케이스 다이어그램은 이바르 제이콥슨(Ivar Jacobson)이 창안한 UML 모델링 기법으로, "어떤 사용자(Actor)가 이 시스템을 통해 어떤 기능적 가치(Use Case)를 얻는가"를 거시적이고 직관적인 동그라미와 졸라맨으로 그려낸 조감도다.

가치: 개발자 중심의 복잡한 코드나 데이터 흐름(DFD)을 배제하고 오직 비즈니스 목적만을 보여주기 때문에, IT 지식이 없는 현업 고객(Client)과 개발팀이 요구사항의 범위를 합의하는 완벽한 커뮤니케이션 도구로 작용한다.

융합: 유스케이스 간의 재사용성을 높이기 위해 공통 로직을 뽑아내는 포함(Include) 관계와, 특정 조건에서만 선택적으로 파생되는 확장(Extend) 관계를 도입하여 아키텍처의 중복을 제거하고 객체지향의 근본 철학을 실현한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 유스케이스 다이어그램(Use Case Diagram)은 객체지향 분석(OOA)의 가장 첫 단계에서 작성되는 UML의 행위(Behavioral) 다이어그램이다. 시스템 경계(Boundary) 바깥의 사용자나 외부 시스템을 '액터(Actor)'로, 시스템 안에서 제공하는 서비스를 '유스케이스(Use Case)'로 정의하여 이들의 관계를 선으로 묶어 표현한다.
필요성: 구조적 분석(DFD) 시대에는 데이터를 쪼개고 함수를 정의하는 데 급급한 나머지, 정작 "이 시스템을 쓸 사람이 도대체 누구며, 그 사람이 진짜로 원하는 결과물이 무엇인가?"라는 가장 근본적인 비즈니스 목적을 잃어버리는 경우가 많았다. 엔지니어링의 관점을 컴퓨터 안쪽(Inside-out)에서 **시스템 바깥쪽의 사용자 관점(Outside-in)**으로 완전히 180도 뒤집어버릴 철학적 도구가 절실했다.
💡 비유: 복잡한 식당 주방의 배관도와 조리 기구 명세서(기존 분석법)를 보기 전에, 먼저 식당 문 앞에 세워두는 **'메뉴판과 손님 안내도'**입니다. "어린이 손님(액터)은 아이스크림(유스케이스)을 먹을 수 있고, 어른 손님(액터)은 커피(유스케이스)를 시킬 수 있다"라고 누구나 이해할 수 있게 한눈에 그려놓은 그림입니다.
등장 배경:
1. 사용자 중심주의 도래: 시스템의 성패가 코드의 완벽함이 아니라 '사용자의 만족'에 달려있다는 인식이 확산되었다.
2. 제이콥슨의 OOSE 제안 (1992): 유스케이스 기반의 소프트웨어 공학(OOSE) 방법론이 발표되며 큰 반향을 일으켰다.
3. UML 1.0 표준화 (1997): 럼바우, 부치의 기법과 함께 UML의 핵심 다이어그램으로 통합되면서 전 세계 요구사항 분석의 바이블로 자리 잡았다.

┌─────────────────────────────────────────────────────────────┐
│          유스케이스 다이어그램의 기본 구성 4대 요소 예시            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│       1️⃣ 액터 (Actor)         2️⃣ 시스템 경계 (System Boundary)  │
│          졸라맨                 ┌───────────────────────┐    │
│           ○                   │       쇼핑몰 앱 시스템      │    │
│          /|\\                 │                       │    │
│          / \\   연관(선)       │ 3️⃣ 유스케이스 (Use Case)  │    │
│         일반회원  ───────────▶ │   ( 상품 검색하기 )      │    │
│                              │                       │    │
│                              │   ( 상품 장바구니 담기 )  │    │
│           ○                   │                       │    │
│          /|\\  ───────────▶ │   ( 상품 결제하기 )      │    │
│          / \\                 │                       │    │
│         관리자                 │   ( 회원 관리하기 )      │    │
│                              └───────────────────────┘    │
│                                                             │
│ 🌟 핵심: 시스템 경계(네모 박스) 밖에는 사람이 있고, 네모 안에는 동그라미  │
│    (기능)만 있다. "누가 무엇을 하는가?" 직관성의 끝판왕이다.           │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 다이어그램을 구성하는 규칙은 철저하다. 사각형(시스템 경계)은 우리가 개발할 소프트웨어의 한계선이다. 이 박스 밖에는 액터(Actor)가 서 있다. 액터는 사람일 수도 있고, 외부의 결제 연동 은행 서버(다른 컴퓨터 시스템)일 수도 있다. 박스 안의 타원형 동그라미(Use Case)는 반드시 동사 형태로 작성되어야 한다. '고객DB' 같은 명사가 아니라 '상품 검색하기'처럼 액터가 얻어가는 가치(Value)의 결과물 단위여야 한다. 선(Association)은 액터가 해당 기능을 실행할 권한이 있음을 나타낸다.

📢 섹션 요약 비유: 이 그림은 식당(시스템 경계)의 평면도입니다. 식당 밖에는 손님과 배달원(액터)이 있고, 식당 안에는 '밥 먹기', '포장 음식 받기' 같은 행동표(유스케이스)가 둥둥 떠 있어서 누가 어떤 행동표와 끈(연관 관계)으로 묶여있는지 보여주는 명쾌한 조감도입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

관계의 마법: 포함(Include)과 확장(Extend)

유스케이스 다이어그램이 100점짜리 아키텍처 문서가 되려면, 시스템 내부의 중복된 로직을 뽑아내어 **객체지향의 '재사용성'**을 도면 레벨에서 달성해야 한다. 이때 쓰이는 두 가지 마법의 화살표가 있다. (시험 출제 1순위)

관계 명칭	점선 화살표 방향	실행 조건 및 의미	비유
포함 관계 (`<<include>>`)	본래 유스케이스 ➔ 공통 유스케이스	무조건, 반드시 실행됨. 여러 유스케이스에서 공통적으로 중복되는 로직(예: 로그인)을 별도 타원으로 뽑아낸 것. (필수)	식당에서 밥을 먹으면 무조건 결제를 해야 함
확장 관계 (`<<extend>>`)	파생 유스케이스 ➔ 본래 유스케이스	특정 조건이 만족될 때만 선택적으로 실행됨. 예외 상황이나 부가 기능(예: 재고 부족 시 대체품 안내)을 나타냄. (선택)	식당에서 밥을 먹다가 원하면 디저트를 추가 주문함

┌───────────────────────────────────────────────────────────────┐
│        포함(Include)과 확장(Extend) 관계의 화살표 방향의 비밀       │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│ [ 1. 포함 관계: 필수적 공통 모듈 호출 ]                             │
│                                                               │
│   ( 상품 주문하기 ) ━━━━━━━▶ ( 로그인 하기 ) ◀━━━━━━━ ( 게시글 쓰기 ) │
│               <<include>>            <<include>>              │
│ ➔ 의미: 주문을 하려든, 글을 쓰려든 "로그인"은 '반드시' 거쳐야 하는 필수 관문! │
│ ➔ 방향: 내가 쓸 모듈을 향해 화살표를 던진다. (호출자 ➔ 피호출자)          │
│                                                               │
│ [ 2. 확장 관계: 선택적 예외 모듈 추가 ]                             │
│                                                               │
│   ( 상품 검색하기 ) ◀━━━━━━━ ( 품절 안내 팝업 띄우기 )               │
│               <<extend>>                                      │
│ ➔ 의미: 검색을 한다고 무조건 팝업이 뜨는 건 아님. 재고가 0일 때만 팝업 실행.│
│ ➔ 방향: "내가 너의 기본 기능에 슬쩍 숟가락을 얹을게" (확장기능 ➔ 기본기능) │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 화살표의 방향이 헷갈리기 쉬운데, 개발자 관점(의존성)으로 생각하면 쉽다. Include는 코드로 치면 내가 남의 함수를 직접 콜(login())하는 것이므로 내 쪽에서 공통 모듈 쪽으로 화살표가 나간다. 반면 Extend는 기본 유스케이스는 확장 유스케이스의 존재조차 모르고 묵묵히 제 갈 길을 가는데, 어떤 예외 조건이 터졌을 때 확장 유스케이스가 훅 치고 들어와 기능을 더해주는 구조다(콜백이나 인터셉터 패턴과 유사). 따라서 확장 기능 쪽에서 기본 모듈 쪽으로 화살표를 꽂아 넣게 된다. 이 두 가지 관계를 통해 도면의 동그라미(기능)들이 스파게티처럼 엉키는 것을 막고 깔끔한 모듈화(Modularization)를 이룬다.

📢 섹션 요약 비유: Include는 김밥을 시키면 단무지가 **'무조건 딸려오는 세트'**이고, Extend는 라면을 시키다가 "치즈 추가해 주세요"라고 **'조건부로 옵션을 붙이는 것'**입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 일반화 (Generalization) 관계 - 액터와 유스케이스의 상속

포함/확장 외에도 객체지향의 '상속(Inheritance)'을 도면에 표현하는 일반화 관계가 있다. 빈 삼각형 실선(➔)으로 그린다.

액터 간의 일반화: 일반 회원과 프리미엄 회원이 있다. 프리미엄 회원은 일반 회원이 하는 모든 행동(게시글 보기 등)을 다 할 수 있고, 추가로 'VIP 룸 입장'도 할 수 있다. 이때 프리미엄 회원(자식) ➔ 일반 회원(부모) 방향으로 빈 삼각형 화살표를 그으면, 선을 지저분하게 두 번 그을 필요 없이 권한의 상속이 완벽히 표현된다.
유스케이스 간의 일반화: 결제하기(부모) 밑에 신용카드 결제(자식)와 포인트 결제(자식)를 상속 관계로 그릴 수 있다. 부모의 성질을 물려받되 세부 방식이 다름(다형성)을 도식화한다.

과목 융합 관점

데이터베이스 (DB): 요구사항 단계의 유스케이스는 개발 후반부로 가면 철저하게 CRUD (Create, Read, Update, Delete) 매트릭스와 검증된다. 유스케이스 명세서에 등장한 '상품 검색하기'가 과연 DB 테이블의 'Product 엔티티'에 정상적으로 Read(조회) 권한을 매핑하고 있는지 검증하지 않으면 도면 따로 DB 따로 도는 유령 시스템이 된다.
소프트웨어 테스팅 (QA): QA 부서에서 만드는 시스템 인수 테스트(Acceptance Test) 시나리오의 1순위 베이스캠프가 바로 이 유스케이스 다이어그램이다. 동그라미 하나가 그대로 테스터의 점검 체크리스트(TC) 1개로 1:1 변환된다. 유스케이스가 누락되면 테스트가 누락되고 결국 버그를 양산한 채 고객에게 납품되는 참사가 발생한다.
📢 섹션 요약 비유: 일반화 관계는 가족의 유전자와 같습니다. 아빠(부모 액터)가 가진 눈썰미(권한)를 아들(자식 액터)이 그대로 물려받았기 때문에, 도면에 아들이 아빠의 능력을 쓴다고 선을 구구절절 수십 가닥씩 다시 그릴 필요가 없어 도면이 아주 깔끔해집니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 내부 시스템 모듈을 억지로 유스케이스로 뽑아낸 안티패턴: 백엔드 개발자가 요구사항 도면을 그리면서 (DB 연결하기), (JSON 파싱하기) 같은 동그라미를 잔뜩 그리고 액터를 연결해 두었다. 현업 고객 담당자는 도면을 보고 "JSON 파싱이 뭐죠? 제가 저걸 왜 해야 하나요?"라며 혼란에 빠졌다.
- 판단: 유스케이스 아키텍처의 가장 흔하고 치명적인 붕괴다. 유스케이스는 철저하게 **"외부 액터(고객)가 얻는 비즈니스 가치(Value)"**에만 집중해야 한다. DB 연결이나 텍스트 파싱은 구현 단계의 클래스 로직(How)이지, 사용자의 목적(What)이 아니다. 내부 로직을 동그라미로 끄집어내는 순간 이 문서는 고객과의 소통 도구라는 본질적 존재 가치를 상실하고 휴지통으로 직행한다.
시나리오 — 수십 장의 다이어그램만 남고 유스케이스 명세서(Description)가 증발한 프로젝트: 차세대 시스템 구축 시, 기획팀이 화려한 UML 그리기 툴로 유스케이스 동그라미를 500개나 그려서 벽에 도배했다. 개발자들은 그림을 보고 "상품 결제하기" 동그라미를 클릭하면 끝나는 줄 알고 코딩을 했다. 하지만 결제 실패 시 포인트 차감 롤백이나 이메일 전송 로직이 싹 빠져버려 시스템이 마비됐다.
- 판단: 그림(Diagram)은 목차일 뿐이다. 실무에서 유스케이스의 진정한 뼈와 살은 그 동그라미 뒤에 첨부되어야 하는 엑셀/워드 문서인 **유스케이스 명세서 (Use Case Description)**다. 이 명세서 안에 사전 조건, 사후 조건, 정상 흐름(Basic Flow), 대안 흐름(Alternative Flow), 예외 흐름(Exception Flow)이 줄글 텍스트로 꼼꼼히 적혀있지 않다면, 그 예쁜 동그라미 그림은 10원어치의 가치도 없는 낙서장에 불과하다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 유스케이스 명세서(Description)의 표준 구조        │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ 유스케이스 명: 상품 결제하기 (UC-012)                             │
  │ 참여 액터: 쇼핑몰 고객, 외부 PG사(결제대행) 서버                     │
  │                                                             │
  │ 1. 사전 조건 (Pre-condition)                                 │
  │    - 고객은 시스템에 로그인되어 있어야 하며, 장바구니에 1개 이상 상품 존재. │
  │                                                             │
  │ 2. 정상 흐름 (Basic Flow / Happy Path)                       │
  │    ① 고객이 결제 버튼을 누른다.                                   │
  │    ② 시스템은 외부 PG사로 결제 요청 API를 쏜다.                     │
  │    ③ 결제 성공 시, 주문 상태를 '결제완료'로 변경한다.                │
  │                                                             │
  │ 3. 대안 흐름 (Alternative Flow / 예외 처리)                     │
  │    [ 2-② 에서 PG사 서버 타임아웃 발생 시 ]                        │
  │    - 시스템은 결제를 취소하고, 고객에게 '통신 장애' 팝업을 띄운다.        │
  │                                                             │
  │ ✅ 판단: 동그라미 그림(다이어그램)은 이 복잡한 시나리오 문서 1장을 찾기     │
  │    위해 클릭하기 위한 '버튼(목차)'에 불과하다. 아키텍트의 진짜 무기는 이 명세서다.│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 유스케이스 모델링의 90% 노력은 그림 그리기가 아니라 이 텍스트 명세서 작성에 투입되어야 한다. '정상 흐름'은 고객이 아무런 실수 없이 행복하게 결제를 마치는 해피 패스(Happy Path)다. 하지만 개발의 진가는 '대안 흐름'과 '예외 흐름'에서 나온다. 통신이 끊겼을 때, 포인트가 부족할 때 시스템이 어떻게 방어하고 복구할지(Resilience)를 이 명세서 단계에서 철저히 텍스트로 고정시켜 놓지 않으면, 개발자는 자기 멋대로 화면을 튕겨버리는 끔찍한 코드를 짜게 된다. 이 명세서야말로 프로젝트의 무결성을 지키는 진짜 계약서다.

도입 체크리스트

기술적: 유스케이스 이름을 지을 때 "회원DB" (명사형) 처럼 짓지 않고 반드시 "회원 정보 수정하기" 처럼 액터의 목적이 담긴 (명사 + 동사) 형태의 네이밍 컨벤션을 강제 준수하고 있는가?
운영·보안적: 해커나 악성 봇(Bot) 모델링을 간과하지 않았는가? 최신 시큐어 코딩(Secure Coding) 방법론에서는 시스템을 공격하는 **남용 케이스 (Abuse Case / Misuse Case)**를 유스케이스에 함께 도식화하여, 설계 단계부터 보안 위협(Threat)을 방어하기 위한 방어자 유스케이스를 역으로 끄집어내는 보안 모델링 융합 기법을 필수 적용한다.

안티패턴

액터(Actor)를 오직 '사람'으로만 한정 짓는 실수: "이 배치를 매일 자정에 실행하는 주체는 서버의 크론탭(Crontab) 스케줄러인데, 이건 사람이 아니니까 액터가 아니네?"라며 액터를 빼먹는 안티패턴. 유스케이스의 관점에서 시스템의 바깥쪽에서 시스템을 찌르는 트리거(Trigger) 역할을 한다면 외부 은행 시스템이든, 시간(Time Timer)이든 무조건 액터(졸라맨 또는 박스)로 그려 넣어야 시스템 외부 인터페이스 의존성이 완벽하게 맵핑된다.
📢 섹션 요약 비유: 훌륭한 영화 감독(설계자)은 대본(명세서) 없이 스토리보드 그림(다이어그램)만 예쁘게 그리지 않습니다. 그림 뒤에는 주인공이 어떤 위기에 처하고 어떻게 극복하는지 적힌 치밀한 대본(정상 흐름/대안 흐름)이 있어야 배우(개발자)들이 훌륭한 연기(코딩)를 펼칠 수 있습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	DFD 등 구형 구조적 분석	Use Case 기반 객체지향 분석	개선 효과
정량	개발 관점의 기능 분해로 요구사항 20% 누락	고객 가치 중심 도출로 100% 식별	현업 인수 거부 및 요구사항 변경 비용(Rework) 극감
정량	중복 로직 산재로 코드량 비대화	Include/Extend로 공통 로직 추출	프론트/백엔드 공통 모듈 재사용을 통한 구현 시간 30% 단축
정성	현업(비개발자)이 도면 해석 불가	직관적인 기호로 현업과 즉각적 컨펌	기획-개발-고객 3자 간의 '시각적 의사소통 브리지' 완벽 형성

미래 전망

애자일 (Agile) 스토리 카드와의 융합: UML이라는 거대한 스펙을 전부 지키며 무겁게 문서화하는 폭포수(Waterfall) 시대는 저물었다. 현대 애자일 씬에서 유스케이스 다이어그램은 칠판에 매직으로 슥슥 그리는 브레인스토밍 도구로 축소되었고, 그 뒤에 숨어있던 무거운 유스케이스 명세서 텍스트는 칸반(Kanban) 보드에 붙는 가벼운 유저 스토리 (User Story: "나는 [액터]로서 [기능]을 원한다. 왜냐하면 [가치] 때문이다") 포맷으로 완벽히 녹아들어 빠르게 소모되고 진화하고 있다.
AI 보조 분석 (AI-Assisted Modeling): 기획 회의록 스크립트를 ChatGPT에 던져주면, AI가 PlantUML이나 Mermaid.js 코드로 자동 번역하여 10초 만에 완벽한 Include/Extend 관계가 맺어진 유스케이스 다이어그램을 뽑아주는 시대가 열렸다. 도면을 그리는 단순 노동은 소멸하고, 도면에 빠진 '비즈니스 가치'의 구멍을 짚어내는 아키텍트의 통찰력만이 가치를 발할 것이다.

참고 표준

UML 2.5 Specification: OMG(Object Management Group)에서 공인한 유스케이스 다이어그램의 공식 문법 및 심볼 규격
이바르 제이콥슨의 OOSE: 유스케이스를 탄생시킨 객체지향 소프트웨어 공학 방법론 바이블

유스케이스 다이어그램은 "우리가 도대체 왜 이 소프트웨어를 만들고 있는가?"라는 근원적 질문을 잊지 않게 해주는 등대다. 수백만 줄의 코드가 뒤엉키고 데드락과 널 포인터 에러가 난무하는 지옥 같은 개발 기간 동안, 프로그래머의 모니터 위에 붙어있는 이 졸라맨과 동그라미 그림 한 장은 "결국 이 모든 고생은 저 밖의 사용자(Actor)가 이 가치(Use Case)를 얻게 하기 위함이다"라는 북극성이 되어준다. 인간(고객)을 소프트웨어 설계의 가장 중심에 세운 이 위대한 인본주의적 모델링 기법은, 그 껍데기 포맷이 변할지언정 결코 시스템 공학의 역사에서 지워지지 않을 철학이다.

📢 섹션 요약 비유: 복잡한 엔진 설계도(코드)만 들여다보면 이게 트랙터인지 레이싱 카인지 헷갈릴 때가 있습니다. 유스케이스 다이어그램은 차를 타는 사람(액터)이 "난 이 차로 짐을 나르고 싶다"라고 외치고 있는 모습을 그린 한 장의 스케치입니다. 엔진을 어떻게 깎든, 결국 저 사람의 소원을 들어주는 것이 아키텍트의 유일한 목적지입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Actor (액터)	시스템의 서비스를 사용하는 객체지향 분석의 주인공. 사람이 될 수도 있고 이메일 알림을 쏴주는 외부 발송 서버 시스템이 될 수도 있다.
Include / Extend (관계)	유스케이스 간의 재사용성과 예외 처리를 도면에 우아하게 분리(Decoupling)해 내는 객체지향 아키텍처 설계의 가장 강력한 마법 화살표다.
Use Case Description (명세서)	동그라미 그림 뒤에 숨겨진 진짜 영혼. 정상/대안 흐름을 텍스트로 적어두어 코더의 상상력을 막고 테스터의 TC(테스트케이스) 대본이 되는 핵심 문서다.
User Story (유저 스토리)	유스케이스의 무거운 텍스트 포맷을 애자일 스프린트에 맞게 3줄로 극단적으로 다이어트시킨 현대 요구공학의 라이트급 챔피언이다.
System Boundary (시스템 경계)	사각형 박스로 그려지며, 우리가 코딩으로 책임져야 할 영역(Inside)과 남이 만들어둔 외부 시스템/사람(Outside)의 책임 소재를 칼같이 긋는 국경선이다.

👶 어린이를 위한 3줄 비유 설명

우리가 식당을 차릴 때 복잡한 주방 요리법부터 적으면 머리가 아파요. 먼저 식당 문 앞에 **'손님 안내도(유스케이스 다이어그램)'**부터 그리는 거예요.
식당 밖에는 밥 먹을 손님과 배달 기사 아저씨(액터)를 졸라맨으로 그리고, 식당 안에는 '밥 먹기', '포장해가기' 같은 타원형 간판(유스케이스)을 달아서 선으로 이어주는 거죠.
이렇게 하면 복잡한 컴퓨터 지식을 모르는 식당 사장님(고객)도 "아, 이 식당에선 배달 아저씨가 포장해 가는 기능이 잘 만들어져 있구나!" 하고 한눈에 쉽게 이해할 수 있답니다!