203. 아키텍처 뷰 모델 (4+1 View) - 필립 크루첸 논리 뷰 구현 뷰 프로세스 뷰 배치 뷰 유스케이스 뷰 다각도 시스템 모델링 UML

핵심 인사이트: 코끼리를 장님 5명이 만진다. 다리를 만진 놈은 "이건 기둥이야!" 하고, 코를 만진 놈은 "이건 뱀이야!"라고 싸운다. 1,000만 줄짜리 소프트웨어 아키텍처도 똑같다. 프로그래머는 "어떤 클래스 파일이 있나?"가 궁금하고, 네트워크 엔지니어는 "서버가 몇 대고 IP가 뭐냐?"가 궁금하고, 고객은 "그래서 이 버튼 누르면 장바구니 담기냐?"가 궁금하다. 서로 궁금한 게 다른데 하나의 떡진 설계도만 던져주면 피 터지게 싸우다 프로젝트가 망한다. "야! 완벽한 건축 설계도를 원해? 그럼 코끼리를 4개의 다른 안경(뷰)을 끼고 다각도에서 4장(논리, 구현, 프로세스, 배치)으로 그려! 그리고 그 4장의 그림 정중앙에 고객이 원하는 '핵심 시나리오(+1 유스케이스)'를 박아 넣어서 4장이 서로 헛소리하지 못하게 접착제로 묶어버려라!!" 한 시스템을 5가지 각도에서 엑스레이 찍는 마법, 4+1 뷰 모델이다.

Ⅰ. 단일 뷰(View) 설계도의 치명적 한계

• 하나의 거대한 설계도로 수백 명의 이해관계자(개발자, 테스터, 고객, 관리자)를 모두 이해시킬 수 없습니다.
• 건축으로 치면, 전기 배선도(엔지니어용)와 거실 인테리어 투시도(고객용)를 한 장의 종이에 겹쳐 그리면 아무도 못 알아보는 쓰레기 도면이 되는 것과 같습니다.

Ⅱ. 필립 크루첸(Philippe Kruchten)의 4+1 View Model 🌟

1995년 제안되어 시스템 아키텍처 설계의 글로벌 바이블이 된 다각도 도면 규격입니다.

[4개의 기본 View] - 각자의 안경을 끼고 본다! 🌟 핵심 기출 🌟

1. 논리 뷰 (Logical View) - "설계자/개발자의 뇌"

• 관점: 시스템이 제공하는 '기능적' 요구사항을 어떻게 클래스와 객체로 쪼갤 것인가?
• 내용: "회원 클래스랑 장바구니 클래스가 있고, 둘이 1:N 관계로 화살표가 묶여있네!"
• UML 다이어그램: 클래스 다이어그램, 객체 다이어그램, 상태 다이어그램.

2. 구현 뷰 (Implementation View) - "프로그래머의 작업 폴더"

• 관점: (개발 뷰라고도 함) 코딩을 다 짜고 나서 실제로 src/ 폴더에 소스 코드 파일(Java, JAR, DLL)들이 어떻게 예쁘게 정리되어 묶여 있는가?
• 내용: "결제 폴더 안에 인증 라이브러리가 쏙 들어가 있군! 패키지 구조가 이렇게 되어있네."
• UML 다이어그램: 컴포넌트 다이어그램.

3. 프로세스 뷰 (Process View) - "시스템 통합자와 테스터의 시계"

• 관점: 멈춰있는 코드가 아니라, 코드가 살아서 메모리에 올라간 상태(런타임)에서 프로세스와 스레드들이 어떻게 핑퐁을 치고 돌아가는가? 비기능적 속성(성능, 동시성, 병목)을 체크합니다.
• 내용: "결제 스레드가 10개 떴을 때, DB 접속 스레드랑 데드락(Deadlock)이 걸리나 안 걸리나 보자!"
• UML 다이어그램: 시퀀스 다이어그램, 활동 다이어그램.

4. 배치 뷰 (Deployment View) - "인프라 엔지니어의 지도"

• 관점: 소프트웨어 앱이 물리적인 쇳덩어리 기계(하드웨어 서버, 라우터) 위에 어떻게 설치되어(Install) 네트워크 선으로 엮여 있는가?
• 내용: "웹 서버 기계 3대가 L4 스위치에 랜선으로 묶여있고, 10Gbps 방화벽 너머에 오라클 DB 서버 쇳덩어리가 떡하니 놓여있네!"
• UML 다이어그램: 배포(Deployment) 다이어그램.

[+1 뷰] - 접착제이자 심장 🌟

5. 유스케이스 뷰 (Use Case View) - "고객(사용자)의 시나리오"

• 관점: "위의 4가지 도면 다 좋은데, 그래서 내가 '장바구니 담기 버튼' 누르면 어떻게 되냐고?"
• 왜 +1 인가?: 가장 근본적이고 중요한 사용자의 요구사항(시나리오)이기 때문입니다.
• 이 유스케이스 뷰를 가운데 떡하니 놔두고, 나머지 4개의 뷰가 "저 장바구니 담기 시나리오를 완벽하게 구동시키기 위해 우리는 이렇게 움직인다!" 라며 유스케이스를 중심으로 도면을 일치시킵니다. 즉, 4개의 다면 도면이 서로 모순되지 않는지 검증하고 묶어주는 절대적인 접착제 역할을 합니다.
• UML 다이어그램: 유스케이스 다이어그램.

📢 섹션 요약 비유: 4+1 뷰 모델은 100층짜리 거대한 오피스텔 건물을 짓기 위해 **'각 분야 전문가용 도면 4장과 건축주의 소망 1장을 합친 궁극의 마스터 플랜'**입니다. 인테리어 디자이너는 방의 크기와 벽 위치가 그려진 **'평면도(논리 뷰)'**를 봅니다. 목수와 배관공은 실제 나무와 파이프가 얽혀있는 **'자재 구조도(구현 뷰)'**를 봅니다. 소방관과 테스터는 불이 났을 때 사람들이 안 막히고 뛰어나갈 수 있는 **'비상구 동선도(프로세스 뷰)'**를 봅니다. 전기 통신 기사는 100층까지 거대한 전력 케이블과 두꺼비집이 기계적으로 어떻게 깔려있는지를 보여주는 **'설비 배선도(배치 뷰)'**를 봅니다. 이렇게 4명이 각자의 도면만 보고 헛짓거리하는 걸 막기 위해, 도면 한가운데에 건축주(고객)가 그린 **'우아하게 커피를 마시며 엘리베이터를 타는 한 편의 영화 시나리오(유스케이스 뷰, +1)'**를 대못으로 박아 둡니다. 이 4장의 엑스레이 도면들은 오직 건축주의 한 편의 영화 시나리오(+1)를 현실로 상영하기 위해 서로를 검증하고 아귀를 맞춰가며 하나의 완벽한 소프트웨어 빌딩을 조립해 내는 위대한 5차원 청사진입니다.