238. 유스케이스 다이어그램 (Use Case Diagram) - 정적 기능적 모델링 사용자 관점 요구사항 분석 액터 포함(Include) 확장(Extend) 시스템 경계

핵심 인사이트: (모든 UML의 출발점) 고객(비전문가)이 개발 회사에 찾아와서 "나 은행 앱 만들어줘"라고 한다. 개발자가 신나서 233번 클래스 다이어그램(정적 뼈대)과 235번 시퀀스(핑퐁 통신)를 쫙 그려서 고객한테 내밀면? 고객은 "이 외계어는 뭐야 ㅆㅂ 안 해!" 하고 나간다. 고객은 자바 코드가 궁금한 게 아니다. "야! 복잡한 네모 상자 다 치우고, 아주 유치하고 단순하게 '졸라맨(사용자)' 그림 하나 그려 놔!! 그리고 그 졸라맨이 시스템 안에서 무슨 기능(동그라미)을 쓸 수 있는지 동그라미 안에 한글로 '송금하기', '잔고조회'라고 딱 2개만 큼직하게 적어!! 그리고 졸라맨이랑 동그라미를 선으로 찍 이어버려! 그럼 유치원생도 아~ 이 은행 앱은 사람이 송금하고 조회하는 기능이 있구나 하고 1초 만에 시스템의 정체(요구사항)를 이해하잖아!!" 개발의 첫 삽을 뜰 때 고객과 대화하기 위해 그리는 세상에서 가장 쉬운 껍데기 도면, 유스케이스 다이어그램이다.

Ⅰ. 고객과 개발자의 끔찍한 번역 장벽

• 코드를 짜기 전 가장 중요한 건 **요구사항 분석(Requirement Analysis)**입니다. 시스템이 무슨 '기능'을 해야 하는지 목록을 뽑는 일입니다.
• 이 목록을 글씨로만 100페이지를 적어놓으면 아무도 안 읽고 오해가 터집니다. 글씨 대신 직관적인 졸라맨 그림으로 합의를 보는 기술이 필요했습니다.

Ⅱ. 유스케이스 다이어그램 (Use Case Diagram)의 개념 🌟

• 개념: 시스템의 내부 구조(클래스)나 로직(액티비티) 같은 복잡한 기계적인 속살은 100% 철저히 다 숨겨버리고, 오직 '사용자(사용자 관점)'의 눈높이에서 시스템이 제공해야 할 핵심 '기능(서비스)'이 무엇인지, 그리고 그 기능들을 어떤 외부 요인(사람, 타 시스템)들이 사용하는지를 큼직한 동그라미와 졸라맨 그림으로 가시화한 기능적/정적 다이어그램입니다.

Ⅲ. 졸라맨과 동그라미 (3대 구성 요소) 🌟 핵심 기출 🌟

1. 액터 (Actor) - "시스템 밖의 졸라맨"

• 개념: 내가 만들 시스템의 바깥쪽에 서서, 내 시스템을 찌르거나 이용해 먹는 **'외부의 모든 대상'**입니다. 꼭 사람만 액터인 게 아닙니다.
• 종류:
  • 사람 (Primary Actor): 은행 고객, 관리자 (졸라맨 그림으로 그림)
  • 타 시스템 (Secondary Actor): 내 은행 앱이 결제를 위해 몰래 연동하는 '외부 신용카드사 서버'도 액터입니다! (얘는 네모 상자에 <<actor>>라고 적습니다.)

2. 유스케이스 (Use Case) - "타원형의 기능 덩어리"

• 개념: 사용자(액터) 입장에서 볼 때, 시스템이 제공해 주는 **하나의 온전한 기능 단위(서비스 단위)**입니다.
• 그림 모양: 타원형 동그라미를 그리고, 그 안에 무조건 "송금하다", "회원가입 하다" 같은 동사형 한글/영어 단어를 적어 넣습니다. (이 동그라미 안에서 디비 접속을 어떻게 하는지는 절대 안 그립니다. 철저한 껍데기 은닉입니다.)

3. 시스템 경계 (System Boundary) - "거대한 네모 박스"

• 도화지 한가운데에 거대한 네모 박스를 하나 칩니다. 이 박스 안쪽이 바로 내가 개발해야 할 시스템(예: 모바일 뱅킹 앱)의 영역입니다.
• 기능(유스케이스 동그라미)들은 무조건 이 박스 안쪽에 그립니다.
• 사용자(액터 졸라맨)들은 무조건 이 박스 바깥쪽에 그립니다. (액터는 내 시스템이 아니니까요.)

Ⅳ. 유스케이스 간의 핵심 관계 (포함 vs 확장) 🌟 기출 빈도 최상 🌟

동그라미와 동그라미 사이를 점선 화살표로 잇는데, 이 2가지를 헷갈리면 무조건 틀립니다.

1. 포함 관계 (Include) - "절대 강제, 넌 무조건 내 노예야"

• 상황: (송금하기) 유스케이스를 실행하려면, 하늘이 두 쪽 나도 무조건 사전에 (공인인증서 로그인)을 해야 합니다.
• 개념: A 기능을 수행할 때, B 기능이 100% 강제로 무조건 실행(호출)되어야만 하는 절대적인 필수 의존 관계입니다.
• 그림: (송금하기) ─── <<include>> ───▷ (공인인증서 로그인)

2. 확장 관계 (Extend) - "옵션, 꼴리면 하고 말면 말고"

• 상황: (글쓰기) 유스케이스를 실행합니다. 근데 심심하면 (사진 첨부하기) 기능을 추가로 쓸 수도 있고, 사진이 없으면 안 써도 글쓰기는 정상적으로 완료됩니다.
• 개념: A 기능을 수행할 때, B 기능이 특정 조건에 따라 선택적으로(Optional) 추가 수행될 수도 있고 안 될 수도 있는 부가적인 관계입니다.
• 그림: (글쓰기) ◁─── <<extend>> ─── (사진 첨부하기)
• 주의: 확장(Extend)의 점선 화살표 방향은 포함(Include)과 반대로 옵션 놈(사진)에서 원래 놈(글쓰기) 쪽으로 화살표를 거꾸로 쏜다는 것을 객관식에서 함정으로 미친 듯이 냅니다.

📢 섹션 요약 비유: 유스케이스 다이어그램은 식당 입구에 붙어있는 **'어린이용 그림 메뉴판'**입니다. 메뉴판에는 주방장이 돈가스 고기를 어떻게 다지고 소스를 몇 분 끓이는지(내부 알고리즘, 클래스, 시퀀스) 같은 복잡한 헛소리는 1도 안 적혀있습니다. 오직 '손님 졸라맨(액터)' 그림 하나와, 그 졸라맨이 시켜 먹을 수 있는 큼직한 음식 이름 **'돈가스', '오므라이스'가 적힌 동그라미(유스케이스 기능)**들만 선으로 심플하게 이어져 있습니다. 식당 전체를 아우르는 네모 박스(시스템 경계) 바깥에는 손님 졸라맨뿐 아니라 돈을 수금해 가는 '배달의 민족 라이더 졸라맨(외부 시스템 액터)'도 서 있습니다. 메뉴판에 점선으로 **포함(Include)**이라고 적힌 건 "돈가스를 시키면 무조건 단무지가 딸려 나옴(필수 강제)"을 뜻하고, **확장(Extend)**이라고 적힌 건 "돈가스를 시킬 때 네가 원한다면 500원 내고 새우튀김을 추가로 얹을 수 있음(선택적 옵션)"을 뜻합니다. 비전문가인 고객이 1초 만에 식당의 모든 기능과 옵션을 직관적으로 이해하고 개발자와 합의(요구사항 확정)를 끝내게 만들어주는 개발 주기 1단계의 절대 껍데기 도면입니다.