84. 필립 크루첸 (Philippe Kruchten)의 4+1 View 아키텍처 모델

⚠️ 이 문서는 소프트웨어 시스템의 거대한 구조(아키텍처)를 설명할 때 "수십 명의 다양한 이해관계자(개발자, 인프라 팀, 고객)들이 모두 각기 다른 것(코드, 서버 랙, 결제 기능)을 궁금해하는데, 도대체 어떤 관점(View)들로 도면을 쪼개 그려야 모두를 만족시킬 수 있을까?"라는 근본적 질문에 대해, 1995년 필립 크루첸이 제안한 가장 위대하고 대중적인 도면 분류법인 '논리, 구현, 프로세스, 배포의 4가지 기술적 뷰와 이를 한가운데서 묶어주는 1개의 유스케이스(Use Case) 뷰'의 4+1 View 모델을 다룹니다.

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

  1. 본질: 복잡한 건물을 그릴 때 평면도, 배관도, 전기 배선도를 따로 그리듯, 눈에 보이지 않는 소프트웨어를 **4개의 서로 다른 각도(카메라)**에서 촬영하여 각 이해관계자의 가려운 곳을 긁어주는 5장 세트의 표준 도면 작도법이다.
  2. 가치: 고객(사장님)은 서버 구조를 모르고, 인프라 엔지니어는 소스코드를 모른다. 이 모델은 각자의 눈높이에 맞춘 4장의 도면을 던져주고, 마지막 한가운데에 '+1 (유스케이스)' 도면을 박아 넣어 이 4장의 도면이 "고객의 요구사항"이라는 단 하나의 목적을 위해 톱니바퀴처럼 어긋남 없이 돌아가는지 100% 정합성을 증명해 낸다.
  3. 기술 체계: 고객을 위한 Use Case 뷰(+1), 설계자를 위한 논리 뷰(Logical), 개발자를 위한 구현 뷰(Development/Implementation), 성능 테스터를 위한 프로세스 뷰(Process), 인프라 엔지니어를 위한 물리/배포 뷰(Physical/Deployment) 로 구성된다.

Ⅰ. 4개의 기술적 뷰 (The '4' Views)

시스템의 속살을 각 분야 전문가의 현미경으로 4등분 하여 쳐다본다.

  1. 논리 뷰 (Logical View) - '설계자(Architect)'의 뷰:
    • 목적: 시스템이 '기능적'으로 어떻게 쪼개져 있는지 보여준다.
    • 내용: "고객 관리 모듈, 결제 모듈, 장바구니 모듈이 서로 이렇게 데이터를 주고받는다." 소스코드 레벨이 아니라 개념적인 객체와 클래스의 덩어리를 그린다.
    • 사용 도구: UML의 '클래스 다이어그램(Class Diagram)', '상태 다이어그램'.
  2. 구현 뷰 (Implementation/Development View) - '개발자(Programmer)'의 뷰:
    • 목적: 개발자가 키보드를 칠 때 필요한 파일 폴더 구조와 소스코드의 묶음(패키지)을 보여준다.
    • 내용: "결제 모듈을 짜기 위해 com.shop.pay 패키지 안에 이 .java 파일 3개를 넣고 spring-boot.jar 라이브러리에 묶어(의존성) 컴파일해라."
    • 사용 도구: UML의 '컴포넌트 다이어그램(Component Diagram)', '패키지 다이어그램'.
  3. 프로세스 뷰 (Process View) - '시스템 통합/성능 테스터'의 뷰:
    • 목적: 시스템이 실제로 램(RAM)에 올라가서 돌아갈 때, 스레드(Thread)나 프로세스들이 동시성(병렬 처리)을 띠며 어떻게 살아 움직이는지(동적 흐름)를 보여준다.
    • 내용: "결제 버튼을 누르면 1번 스레드가 DB에 락(Lock)을 걸고, 2번 스레드가 외부 카드사 API를 비동기로 찔러서 병목(Deadlock)을 피한다."
    • 사용 도구: UML의 '시퀀스 다이어그램(Sequence Diagram)', '액티비티 다이어그램'.
  4. 물리/배포 뷰 (Physical/Deployment View) - '인프라 엔지니어(SysAdmin)'의 뷰:
    • 목적: 다 짜진 소프트웨어 조각들을 쇠창살이 있는 '물리적인 진짜 기계(서버, 클라우드)'에 어떻게 얹어놓을 것인가를 보여준다.
    • 내용: "결제 war 파일은 강남 센터의 AWS EC2 3대에 로드밸런서를 걸어 분산시키고, DB 서버는 방화벽 뒤쪽 보안망(Private Subnet)에 꽂아라."
    • 사용 도구: UML의 '배포 다이어그램(Deployment Diagram)'.

📢 섹션 요약 비유: 자동차(소프트웨어)를 설계합니다. 논리 뷰는 "엔진과 바퀴의 회전 비율(개념 설계)"을 그립니다. 구현 뷰는 "엔진 부품(소스코드)들을 1번 박스에 담고 조립 라인(컴파일)에 올려라"라는 조립 지시서입니다. 프로세스 뷰는 "시동을 걸었을 때 피스톤 4개가 1초에 어떻게 엇갈리며 움직이는가(스레드 병렬 처리)"라는 동적 투시도입니다. 배포 뷰는 "이 완성된 자동차를 서울 공장에 몇 대, 부산 공장에 몇 대 세워둘 것인가(서버 기계 배치)"라는 물류 배치도입니다.

Ⅱ. 정중앙의 접착제: 유스케이스 뷰 (+1 View)

4장의 기술 도면이 쓰레기가 되지 않으려면 '고객의 요구사항'에 묶여야 한다.

  1. 유스케이스 뷰 (Use Case/Scenarios View) - '고객(Customer/User)'의 뷰:
    • 목적: 위에서 찢어놓은 4장의 기술 도면들이 결국 "무엇을 위해 이 생고생을 하는가?"를 증명하는 사용자 중심의 시나리오다.
    • 내용: 사용자가 시스템 바깥에서 시스템과 상호작용하는 사건 자체를 그린다. "고객이 [장바구니 결제] 버튼을 누른다 $\rightarrow$ 은행 인증을 한다 $\rightarrow$ 영수증이 뜬다."
    • 사용 도구: UML의 '유스케이스 다이어그램(Use Case Diagram)'.
  2. 중앙 통제와 정합성 검증 (The Glue):
    • 왜 '5 View'가 아니라 굳이 **'4+1 View'**라고 멋을 부려 불렀을까?
    • 유스케이스(+1) 뷰는 나머지 4개 뷰의 정중앙(Center)에 위치하여 4개의 도면을 거미줄처럼 강력하게 하나로 묶어주는 접착제(Glue) 역할을 하기 때문이다.
    • 아키텍트는 4장의 도면을 쫙 펴놓고 유스케이스 시나리오 하나를 던져본다. "자, 유스케이스 1번: 고객이 1만 명 동시에 결제 버튼을 눌렀다. 논리 뷰(클래스) 설계 문제없나? 프로세스 뷰(스레드) 뻗지 않나? 배포 뷰(서버 3대) 버틸 수 있나?"
    • 이 (+1) 시나리오 하나로 나머지 4개 도면의 모순(충돌)을 잡아내고 100% 아다리가 맞아떨어짐(정합성)을 수학적으로 증명(Validation)해 낸다.

📢 섹션 요약 비유: 엔지니어 4명이 자동차의 엔진(논리), 부품 박스(구현), 피스톤 동작(프로세스), 공장 배치(배포) 도면 4장을 완벽하게 그려왔습니다. 사장님(+1 유스케이스 뷰)이 묻습니다. "다 좋은데, 이 4장 도면대로 만들면 '고객이 시속 100km에서 급브레이크를 밟는다(사용자 시나리오)'는 내 최우선 요구사항을 만족할 수 있어?" 이 사장님의 질문(+1)이라는 잣대를 4장의 도면 한가운데에 찔러 넣어보고, 4장의 도면이 모두 "예, 브레이크 완벽히 작동합니다"라고 일관되게 답할 수 있어야만 비로소 자동차(소프트웨어 아키텍처) 설계가 합격 도장을 받는 완벽한 검증 체계입니다.