85. 논리 뷰 (Logical View) - 기능적 요구사항의 개념 설계

⚠️ 이 문서는 소프트웨어 시스템을 다각도로 해부하는 크루첸의 '4+1 View 모델' 중 첫 번째이자 가장 뼈대가 되는 핵심 도면으로, 물리적인 서버 기계가 몇 대인지, 자바(Java) 폴더 구조가 어떻게 생겼는지는 철저히 무시한 채 오직 **"이 시스템이 최종 사용자(Customer)에게 제공해야 할 핵심 비즈니스 '기능(Functionality)'들이 어떻게 쪼개져 있고 서로 어떻게 데이터를 주고받는가?"를 개념적으로 아름답게 그려낸 설계자(Architect)의 도화지인 '논리 뷰'**를 다룹니다.

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

1. 본질: 하드웨어나 특정 프로그래밍 언어(C++, Python)에 종속되지 않는 순수한 '개념 설계도'다. 이 도면은 10년 뒤 회사가 자바에서 파이썬으로 넘어가더라도 절대 변하지 않는 비즈니스 로직의 절대 뼈대(Domain Model)를 담고 있다.
2. 가치: 사장님과 기획자가 요구한 "쇼핑몰에서 결제하고 이메일을 보낸다"는 막연한 요구사항(+1 유스케이스 뷰)을 낚아채어, 이를 [주문 클래스], [결제 클래스], [알림 클래스]라는 시스템 내부의 독립적인 부품(객체) 덩어리로 예쁘게 번역해 주는 최초의 통역 역할을 한다.
3. 기술 체계: 객체지향 설계(OOD) 사상과 가장 맞닿아 있으며, UML의 클래스 다이어그램(Class Diagram), 상태 다이어그램(State Diagram), 통신 다이어그램을 주력 무기로 사용하여 덩어리들의 정적인 구조와 관계(연관, 상속)를 명확히 표현한다.

Ⅰ. 기술의 분리: 기계와 코드를 잊어라

훌륭한 설계자는 뼈대를 그릴 때 시멘트의 브랜드를 따지지 않는다.

1. 순수한 비즈니스 기능 (Functional Requirements):
   • 4+1 View 모델에서 **논리 뷰(Logical View)**가 챙겨야 할 최우선 관심사(Concern)는 오직 하나, '기능(Function)'이다.
   • "고객이 로그인한다", "포인트를 차감한다" 같은 비즈니스 로직이 시스템 내부에 어떤 모듈 덩어리로 존재해야 하는지를 파악한다.
2. 구현 세부 사항의 의도적 배제 (Abstraction):
   • 초보 설계자는 논리 뷰를 그리라고 하면 MySQL DB 연동 객체, AWS S3 업로드 클래스 같은 구체적인 기술 단어를 적는다. (이건 나중에 '구현 뷰'나 '배포 뷰'에서 할 일이다.)
   • 논리 뷰의 도화지에는 철저하게 기술 종속적인 단어가 배제되어야 한다. 오라클 DB든 파일 저장이든 상관없이 그냥 둥글게 **[데이터 저장소 인터페이스]**라고 개념적으로 추상화(Abstraction)해서 얹어놓아야 100점짜리 논리 도면이다.

📢 섹션 요약 비유: 자동차(시스템)의 논리 뷰를 그릴 때, 타이어가 '미쉐린' 제품인지, 볼트가 십자(+)인지 일자(-)인지는 전혀 그리지 않습니다. 오직 "둥근 고무바퀴 4개가 앞뒤로 2개씩 배치되어 굴림대(차축)와 연결된다"라는 순수한 기계적 개념(기능)만을 선으로 이어 그립니다. 타이어 브랜드가 한국타이어로 바뀌어도 이 도면(논리 뷰)은 평생 뜯어고칠 필요가 없는 영원불멸의 철학적 설계도입니다.

Ⅱ. 논리 뷰의 해부학: 클래스와 객체의 세계

건물을 떠받치는 기둥과 벽돌들의 이름표를 붙여준다.

1. 클래스 (Class)와 패키지 (Package):
   • 논리 뷰를 구성하는 가장 작은 레고 블록 단위는 객체지향의 꽃인 **'클래스(Class)'**다.
   • Customer, Order, Payment 같은 클래스 네모 박스를 띄워놓고, 그 안에 어떤 속성(이름, 나이)과 행동(결제하다, 취소하다)이 들어있는지 적는다.
   • 비슷한 클래스 수십 개가 모이면, 이를 커다란 묶음 상자인 **'패키지(Package)' 또는 '서브 시스템(Sub-system)'**으로 한 번 더 감싸서 덩어리로 만든다. (예: 회원 관리 시스템, 결제/정산 시스템)
2. 관계 (Relationship)의 시각화:
   • 네모 박스만 던져놓으면 도면이 아니다. 박스 간의 관계를 선으로 이어준다.
   • Order 클래스와 Payment 클래스 사이에 실선을 긋고 "주문 1개당 결제는 1개만 발생한다(1:1 연관 관계)"라고 쓴다.
   • VIP 고객과 일반 고객 박스는 화살표를 위로 올려 Customer라는 부모 박스를 상속(Inheritance)받는다고 그려주어 구조의 우아함을 완성한다.

📢 섹션 요약 비유: 대기업의 조직도(논리 뷰)를 그리는 것과 같습니다. 사장님 방 아래에 '영업팀(패키지)'과 '회계팀(패키지)' 박스를 그립니다. 영업팀 안에는 영업 1팀장, 영업 2팀장(클래스)이 있습니다. 그리고 영업팀과 회계팀 박스 사이에 점선을 그어 "영업팀이 영수증을 회계팀에 제출한다(관계/통신)"라고 화살표를 그어줍니다. 이 조직도만 보면 회사가 어떻게 굴러가는지 눈에 훤히 들어오는 명확한 지휘 통제도입니다.

Ⅲ. 고객(+1 유스케이스)과의 끈끈한 접착

도면이 예뻐도 고객이 요구한 기능이 빠져있으면 쓰레기다.

1. 유스케이스(Use Case)의 수용:
   • 아키텍트는 사장님(고객)이 들이민 '유스케이스 뷰(+1)' 시나리오를 집어 든다.
   • 시나리오: "고객이 상품을 장바구니에 담고 신용카드로 결제한다."
2. 논리 뷰의 증명 (Validation):
   • 아키텍트는 자기가 그린 논리 뷰(클래스 다이어그램)를 펴놓고, 형광펜으로 사장님의 시나리오를 따라가며 도면에 길을 그려본다.
   • "고객이 장바구니에 담으면 Cart 클래스가 반응하고(OK), 결제를 누르면 Payment 클래스로 데이터가 잘 넘어가서 처리되네(OK). 사장님이 원한 기능이 우리 시스템 뼈대에 100% 누락 없이 구현되어 있습니다!"라고 찰떡같이 증명해 낸다.
3. 다음 뷰(View)를 위한 이정표 역할:
   • 논리 뷰가 확정되어 도장이 찍히는 순간, 이 도면은 뒷단에 대기하고 있는 '프로그래머'와 '인프라 엔지니어'에게 하달된다.
   • 프로그래머는 이 논리 도면(클래스 이름)을 보고 똑같이 자바 소스코드 파일(구현 뷰)을 만들어내고, 인프라 엔지니어는 이 거대한 모듈 덩어리들을 보고 서버 3대에 어떻게 찢어서 얹을지(배포 뷰) 고민을 시작하는, 모든 아키텍처 파이프라인의 출발점이 된다.

📢 섹션 요약 비유: 식당 사장님(+1 유스케이스)이 "김치찌개를 시키면 계란말이도 세트로 나오는 코스를 만들어!"라고 지시합니다. 설계자(논리 뷰)는 주방 화이트보드에 [찌개 조리 파트] 네모와 [사이드 반찬 파트] 네모를 그리고 두 파트 사이에 "동시 출구 배식"이라는 선을 그어 시스템을 설계합니다. 이 보드의 그림이 완성되어야, 그제야 요리사(개발자)가 가스레인지를 켜고 파와 마늘을 썰며(구현 뷰) 실제 음식을 만들어낼 수 있는 뼈대 잡기 작업입니다.