89. 유스케이스 뷰 (Use Case View / +1 View) - 아키텍처의 절대 중심

⚠️ 이 문서는 소프트웨어 시스템을 각 전문가의 시선으로 찢어 그린 4장의 기술 도면(논리, 구현, 프로세스, 물리 뷰)이 그들만의 화려한 기술 자랑(오버엔지니어링)으로 끝나지 않도록, **도면들의 한가운데에 턱 하니 박혀서 "너희가 아무리 멋진 서버와 코드를 짰어도, 결국 '고객(사용자)'이 장바구니에 물건을 담고 결제하는 이 시나리오 하나 제대로 작동 못 시키면 다 쓰레기야!"라며 시스템의 존재 목적(기능적 요구사항)을 통제하고 검증하는 절대 잣대인 '유스케이스 뷰(+1 View)'**를 다룹니다.

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

1. 본질: 크루첸의 4+1 View 모델에서 4장의 도면을 묶어주는 **'접착제(Glue)'**이자 시스템의 영혼이다. 시스템이 내부적으로 어떻게 돌아가든 알 바 없고, 밖에서 쳐다보는 멍청한 사용자(Actor) 입장에서 "이 시스템으로 뭘 할 수 있는가?"를 시나리오로 그린다.
2. 가치: 설계도(Architecture)가 잘 그려졌는지 100% 확신할 수 있는 테스트 도구(Validation)다. 이 유스케이스에 적힌 시나리오가 4장의 기술 도면 위에서 물 흐르듯 통과되어야만 아키텍처가 승인(Sign-off)된다.
3. 기술 체계: 졸라맨 아이콘인 액터(Actor, 사용자/외부 시스템), 동그라미인 유스케이스(기능 단위), 그리고 둥근 사각형인 **시스템 경계(Boundary)**를 이용한 '유스케이스 다이어그램(UML)' 단 하나로 모든 비즈니스 요구사항을 직관적이고 완벽하게 포착해 낸다.

Ⅰ. 왜 5 Views가 아니라 '4+1' View 인가?

기술은 목적을 위해 존재한다. 목적이 빠진 기술은 허상이다.

1. 엔지니어들의 오만과 폭주:
   • 아키텍트들을 모아놓으면 각자 자기 분야 자랑에 빠진다. DB 전문가는 논리 뷰에 100개의 클래스 테이블을 복잡하게 그리고, 인프라 담당자는 배포 뷰에 쿠버네티스 노드 50대를 화려하게 깔아놓는다.
   • 결과물이 엄청 멋있어 보인다. 하지만 사장님(고객)이 와서 "그래서 우리 회사 앱에서 비밀번호 찾기 기능 어딨어?"라고 물으면, 도면에 그 뼈대(클래스, API)가 쏙 빠져있는 어처구니없는 참사가 발생한다.
2. +1 뷰(유스케이스)의 중앙 통제 선언:
   • 그래서 필립 크루첸은 4장의 기술 도면 정중앙에 이 '유스케이스 뷰'를 배치(+1)했다.
   • 이 도면은 "우리 앱은 [회원가입], [결제하기], [비번찾기] 라는 3가지 기능을 무조건 손님에게 제공해야 한다"라고 요구사항을 박제해 둔 성역이다.
   • 나머지 4장의 도면은, 오직 이 한가운데 박혀있는 3가지 유스케이스 동그라미를 실현하고 굴러가게 만들기 위해 봉사하는 '하인'들로 전락(통제)하게 된다.

📢 섹션 요약 비유: 자동차 공장에 엔지니어 4명이 있습니다. 엔진 전문가, 타이어 전문가가 각자 세계 최고의 도면 4장(기술 뷰)을 그려왔습니다. 하지만 회장님(+1 유스케이스 뷰)이 나타나 말합니다. "다 집어치우고, 이 차가 시속 100km에서 급브레이크를 밟았을 때 3초 안에 멈출 수 있어? 그 시나리오가 너희들 도면 4장에서 증명돼?" 이 회장님의 '급브레이크 기능(유스케이스)'이라는 단 하나의 미션을 통과하지 못하면 4장의 명품 도면은 당장 불쏘시개로 전락하는, 시스템의 절대 기준점입니다.

Ⅱ. 유스케이스 다이어그램의 해부학 (졸라맨과 동그라미)

단 한 줄의 코드도 없이, 유치원생도 이해할 수 있는 완벽한 기획서.

1. 액터 (Actor: 뼈라맨 아이콘):
   • 시스템 바깥에서 시스템을 두드리는 '모든 주체'다.
   • 일반 고객, 관리자 같은 진짜 '사람'일 수도 있고, 12시 정각에 배치 작업을 깨우는 '시간 알람(Timer)'일 수도 있으며, 카드 승인을 내어주는 '외부 신용평가사 서버(다른 기계)'일 수도 있다.
2. 유스케이스 (Use Case: 타원형 동그라미):
   • 시스템이 제공해야 할 **단위 기능(결괏값을 내어주는 행동)**이다. 무조건 동사형으로 쓴다.
   • 예: [장바구니 담기], [주문 취소하기], [월말 정산 돌리기].
3. 시스템 경계 (System Boundary: 커다란 사각형 박스):
   • 도화지 중간에 큰 네모 박스를 친다. 이게 우리가 짤 시스템의 껍데기다.
   • 유스케이스(동그라미)들은 무조건 이 박스 **'안'**에 가둬두고, 액터(졸라맨)들은 무조건 박스 **'밖'**에 세워둔다.
   • 박스 밖의 졸라맨과 박스 안의 동그라미를 펜(실선)으로 이으면 끝이다. "아하, 고객(밖)이 결제하기(안) 기능을 찌르고 쓰는구나!" 직관의 끝판왕이다.

📢 섹션 요약 비유: 식당 시스템을 설계합니다. 네모 박스(시스템 경계)는 식당 건물입니다. 박스 안에는 [요리하기], [계산하기]라는 동그라미(유스케이스)가 있습니다. 박스 바깥에는 '손님 졸라맨(액터)'과 '식자재 배달원 졸라맨(외부 시스템 액터)'을 세워둡니다. 손님 졸라맨이 선을 뻗어 [계산하기] 동그라미를 찌르고, 배달원 졸라맨이 선을 뻗어 [재료 입고] 동그라미를 찌릅니다. 초등학생이 봐도 이 식당이 누구한테 무슨 서비스를 제공하는지 10초 만에 완벽히 이해하는 기적의 다이어그램입니다.

Ⅲ. Include와 Extend: 복잡한 시나리오의 조립

"결제하려면 로그인부터 해라!" 필수와 선택을 화살표로 찢어발긴다.

1. 포함 관계 (<> 화살표):
   • 어떤 기능을 하려면 무조건, 필수적으로 먼저 거쳐야 하는 행동이다.
   • [주문하기] 동그라미에서 [로그인하기] 동그라미 쪽으로 점선 화살표를 쭉 긋고 <<include>>라고 적는다.
   • 개발자에게 내리는 지엄한 명령이다. "너희 주문 모듈 코드 짤 때, 무조건 그 앞에 로그인 세션 체크하는 모듈을 엮어서(호출해서) 짜라. 안 하면 에러 뿜게 만들어라."
2. 확장 관계 (<> 화살표):
   • 어떤 기능을 할 때, 선택적으로, 만약 조건이 맞으면 부가적으로 발생하는 행동이다.
   • [주문하기] 동그라미로 향하게 점선 화살표를 긋고, 반대쪽에 [포인트 10% 적립하기] 동그라미를 그린 뒤 <<extend>>라고 적는다. (화살표 방향이 include와 반대다!)
   • 개발자 해석: "주문은 원래 그냥 혼자 도는 놈인데, 만약 오늘이 VIP 할인 이벤트 날(특정 조건)이면 곁다리로 저 포인트 적립 기능도 띄워서(확장해서) 같이 돌려줘라."

📢 섹션 요약 비유: 마트 카운터입니다. [물건 계산하기]가 메인 동그라미입니다. 손님이 카드를 내밀면 기계는 묻지도 따지지도 않고 무조건 [카드사 한도 승인받기] 동그라미를 호출해야 결제가 됩니다(무조건 해야 함 = Include). 그런데 직원이 "손님, 혹시 포인트 카드 있으세요?" 묻습니다. 손님이 카드를 내밀 때만(선택적 조건 충족 시) [포인트 적립하기] 동그라미 기능이 메인 결제 시스템에 끼어들어 추가로 작동합니다(곁다리 추가 = Extend). 이 화살표 두 개만 알면 수천만 원짜리 컨설팅 기획서를 100% 해독할 수 있습니다.