88. 물리/배포 뷰 (Physical/Deployment View)

⚠️ 이 문서는 시스템을 바라보는 크루첸의 4+1 View 모델 중 최종 종착지로, 코드를 어떻게 짜고 폴더를 어떻게 묶을지(구현 뷰) 고민하던 소프트웨어 세계를 벗어나, **"우리가 1년간 뼈 빠지게 짜놓은 쇳덩어리(war, jar 파일)들을 클라우드의 AWS EC2 서버 1번 랙에 꽂을 것인가, 아니면 L4 스위치 앞단의 Nginx 웹서버 3대에 쪼개어 배포할 것인가?"를 그리는, 100% 인프라(시스템/네트워크 엔지니어) 담당자들의 목숨 줄인 '물리/배포 뷰'**를 다룹니다.

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

  1. 본질: 소프트웨어(코드)와 하드웨어(기계)가 마침내 만나 합체하는 물리적 도면이다. 서버, 스토리지, 방화벽 같은 진짜 눈에 보이는(또는 클라우드 가상의) 기계 껍데기 상자(Node)들 위에 소프트웨어 덩어리(Component/Artifact)들을 예쁘게 얹어놓는 그림이다.
  2. 가치: "우리 결제 서버가 트래픽 1만 명을 버틸 수 있어?"라는 사장님의 질문에 답하기 위해, 서버 기계를 몇 대(Scale-out) 늘려 배치하고 로드밸런서를 어디에 꽂을지 시스템의 확장성(Scalability)과 가용성(Availability)을 한눈에 증명하는 유일한 도면이다.
  3. 기술 체계: UML의 배포 다이어그램(Deployment Diagram) 하나로 모든 것을 끝낸다. 정육면체 3D 큐브 도형인 **노드(Node: 물리 서버)**와, 그 안에서 돌아가는 아티팩트(Artifact: 톰캣, war 파일), 그리고 노드들을 잇는 선인 **통신 경로(TCP/IP, LAN)**로 구성된다.

Ⅰ. 소프트웨어 세계의 탈출: 기계(HW) 위로의 상륙 작전

코드만 짠다고 시스템이 돌아가지 않는다. 어느 쇳덩어리에 올릴지 결정하라.

  1. 구현 뷰 $\rightarrow$ 배포 뷰의 진화:
    • 어제 그린 '구현 뷰'에서는 100만 줄의 코드를 [결제.war], [게시판.war]라는 2개의 깔끔한 코드 덩어리(컴포넌트)로 분리해 냈다.
    • 아키텍트는 이제 '배포 뷰' 도화지를 꺼낸다. "좋아, [결제.war] 덩어리는 보안이 생명이니까 10.0.0.1번 내부망 결제 전용 서버 2대에 올리고, [게시판.war]는 외부망 웹 서버 3대에 쪼개서 분산 배포해!"
    • 즉, 논리적으로 만든 소프트웨어 조각들을 실제 전기를 먹는 물리적/가상적 하드웨어(Node)의 공간에 할당(Mapping)하는 작전 지도다.
  2. 비기능적 요구사항 (Non-functional)의 최종 심판대:
    • 배포 뷰는 코드가 예쁘게 짜졌는지엔 1도 관심이 없다.
    • "서버 1대가 불타서 죽었을 때(이중화/HA), 10초 만에 옆 서버가 트래픽을 넘겨받아 살아남을 수 있는가?"
    • "DB와 웹서버 사이의 네트워크 랜선 대역폭(1Gbps)이 병목을 일으키지 않는가?" 같은 철저히 무자비한 인프라 성능/가용성 관점으로만 그려진다.

📢 섹션 요약 비유: 구현 뷰가 자동차 공장에서 "엔진 부품 10개, 브레이크 부품 5개를 박스에 잘 포장했다"는 부품 출하 명세서라면, 배포 뷰는 "포장된 그 엔진 박스를 자동차 앞쪽 프레임(기계)의 1번 구멍에 끼워 넣고, 브레이크 박스는 4개의 바퀴(기계) 옆에 각각 쪼개어 장착해라!"라고 지시하는 최종 조립 공정 투시도입니다. 완벽한 부품이라도 엉뚱한 기계 위치에 꽂으면 차는 절대 굴러가지 않습니다.

Ⅱ. 배포 다이어그램 (Deployment Diagram)의 해부학

3D 큐브(노드) 안에 톱니바퀴(소프트웨어)를 쑤셔 넣고 랜선으로 잇는다.

  1. 노드 (Node: 정육면체 3D 상자):
    • 그림에 진짜 컴퓨터 본체처럼 생긴 3D 상자를 그린다. 이게 '노드'다.
    • 노드는 물리적인 쇳덩어리 서버일 수도 있고(IBM Unix), 가상의 클라우드 인스턴스(AWS EC2), 스마트폰 단말기, 심지어 IoT 라즈베리파이 센서 기계일 수도 있다. 전기가 통하고 연산 능력이 있는 공간 그 자체다.
    • 상자 이름 옆에 괄호로 <<device>> (진짜 하드웨어), 또는 <<execution environment>> (Tomcat, Docker 같은 실행 환경) 라고 꼬리표(스테레오타입)를 달아준다.
  2. 아티팩트 (Artifact: 네모 종이 아이콘):
    • 3D 상자(노드) 안에, 우리가 힘들게 짰던 [결제.war], [oracle_DB.exe] 같은 진짜 소프트웨어 파일 덩어리 조각을 그려 넣는다.
    • 만약 트래픽이 몰려 스케일 아웃(Scale-out)을 한다면? 3D 상자를 3개 그려놓고, 3개의 상자 안에 모두 똑같은 [결제.war] 아티팩트를 복사 붙여넣기 하듯 그려주면 완벽한 클러스터링 도면이 된다.
  3. 통신 경로 (Communication Path: 실선):
    • 3D 상자와 상자 사이를 실선으로 쭈욱 긋는다.
    • 선 위에 이 두 기계가 어떤 물리적/논리적 핏줄로 대화하는지 적는다. [TCP/IP], [HTTPS 443], [JDBC 1521] 같은 통신 프로토콜 명세를 명확히 적어주어야 나중에 보안팀이 이 선을 보고 방화벽 구멍을 뚫어준다.

📢 섹션 요약 비유: 빌딩의 층별 입주 도면입니다. 거대한 3D 사각형(노드)은 빌딩의 '1층, 2층, 3층'이라는 공간 그 자체입니다. 아티팩트는 그 공간에 이삿짐을 풀고 입주하는 '영업팀, 재무팀'이라는 소프트웨어 회사들입니다. 층(노드)을 그렸으면 1층과 3층을 잇는 실선(통신 경로)을 긋고 "이 선은 내부 엘리베이터(LAN)고, 속도는 초당 100명(1Gbps) 통과 가능"이라고 규격을 딱 박아주는 직관적이고 물리적인 인테리어 도면입니다.

Ⅲ. 클라우드 시대의 배포 뷰 진화 (논리와 물리 공간의 붕괴)

서버 쇳덩어리가 사라지고 코드(IaC)가 인프라가 되는 시대의 딜레마.

  1. 전통적 인프라(On-premise)의 선명함:
    • 10년 전에는 랙(Rack)에 꽂힌 스위치, 방화벽 기계, L4 스위치 장비를 일일이 도면에 네모 상자로 그리며 100% 매핑했다. 서버 기계 10대가 들어오면 3D 큐브 상자 10개를 빽빽하게 그렸다.
  2. 클라우드와 컨테이너(K8s) 시대의 추상화:
    • 오늘날 AWS 클라우드나 쿠버네티스(K8s) 위에서는 '물리적인 서버 상자'의 의미가 완전히 증발했다. 노드(서버)가 오토스케일링(ASG)에 의해 밤 12시엔 3대였다가, 아침 9시엔 50대로 귀신처럼 늘어났다가 쪼그라든다.
    • 따라서 현대의 배포 뷰는 3D 상자를 50개 그리지 않는다. 커다란 구름 모양이나 단 1개의 3D 상자를 그려놓고 <<Kubernetes Cluster>> 라고 퉁친 뒤, 텍스트로 [오토스케일링: Min 3대 ~ Max 50대] 라고 조건을 명시하는 논리적-물리적 경계가 무너진 하이브리드 작도법을 주로 사용한다.
  3. +1 (유스케이스 뷰)와의 마지막 크로스 체크:
    • 아키텍트가 최종적으로 묻는다. "사장님 요구사항(+1)인 '결제 모듈이 죽어도 쇼핑몰 메인 화면은 버텨야 한다'는 미션, 달성했나?"
    • 인프라 엔지니어는 배포 뷰를 펼쳐 보인다. "보십쇼! 결제.war가 담긴 서버 그룹(노드 A)과 메인화면.war가 담긴 서버 그룹(노드 B)을 물리적인 랜선 스위치 레벨부터 완전히 찢어놨습니다. A가 폭발해도 B는 물리적으로 분리되어 절대 안 죽습니다(장애 격리)." 이로써 4+1 View의 대장정이 완벽한 정합성으로 완성된다.

📢 섹션 요약 비유: 과거에는 식당을 지을 때 "가스레인지(서버) 3대, 도마 2대"를 고정된 물리 도면에 박아넣고 10년을 썼습니다. 지금 클라우드 시대는 '움직이는 푸드 트럭(컨테이너)'입니다. 손님이 몰리면 푸드 트럭이 50대가 허공에서 펑펑 날아옵니다. 그래서 현대의 배포 뷰 도면은 트럭 50대를 일일이 그리지 않고, "이 구역엔 트럭이 3대~50대까지 고무줄처럼 자동으로 늘어나게 주차장을 비워둬라"라는 공간의 유연성(Elasticity) 규칙을 문서화하는 방향으로 진화하고 있습니다.