87. 구현 뷰 (Implementation View / Development View)

⚠️ 이 문서는 시스템을 4+1개의 렌즈로 바라보는 크루첸 모델 중 논리적인 객체 뼈대(논리 뷰)나 살아 움직이는 스레드(프로세스 뷰)를 철저히 배제하고, 오직 **"키보드를 두드리는 프로그래머 입장에서 소스코드(.java, .py) 파일들을 어떻게 쪼개서 폴더(패키지)에 담고, 그 파일들을 엮어 어떤 .jar나 .dll 같은 쇳덩어리 조각(컴포넌트)으로 컴파일(빌드)할 것인가?"에 대한 철저한 '물리적 소스코드 패키징 도면인 구현 뷰(개발 뷰)'**를 다룹니다.

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

  1. 본질: 사장님은 모르는, 100% 프로그래머(개발자)만을 위한 도면이다. 깃허브(Git) 저장소에 올라갈 폴더(디렉토리) 구조와 소스코드 파일들의 의존성(Dependency)이 이 도면 한 장에 낱낱이 그려진다.
  2. 가치: 100만 줄의 스파게티 코드가 되는 것을 막아준다. "결제 모듈 코드 덩어리(Component A)가 회원 모듈 코드 덩어리(Component B)를 갖다 쓰도록 화살표를 단방향으로 통제"하여, 나중에 코드를 수정할 때 다른 모듈이 연쇄 폭발하는 끔찍한 결합도(Coupling)를 사전에 차단한다.
  3. 기술 체계: UML의 **컴포넌트 다이어그램(Component Diagram)**과 **패키지 다이어그램(Package Diagram)**을 전가의 보도처럼 사용하며, 시스템을 독립적이고 교체 가능한 '레고 블록(컴포넌트)'들의 조립 도로 그려낸다.

Ⅰ. 논리 뷰(Logical)와의 차이: 개념에서 실물 덩어리로

생각(아이디어)을 끝냈으면, 이제 진짜 하드디스크에 저장될 파일의 덩어리를 빚어라.

  1. 논리 뷰 $\rightarrow$ 구현 뷰의 물리적 변환:
    • 어제 그린 '논리 뷰'에는 [주문 클래스], [장바구니 클래스] 같은 개념적인 둥근 박스들이 떠다닌다.
    • 아키텍트는 오늘 '구현 뷰' 도화지를 꺼낸다. 그리고 선언한다. "어제 그린 주문 클래스와 장바구니 클래스는, 묶어서 OrderManagement.jar 라는 하나의 컴파일된 쇳덩어리(실행 파일 조각)로 구워내라!"
    • 즉, 논리 뷰의 수많은 클래스 조각들을 '실제 윈도우/리눅스 OS 위에 깔릴 물리적인 파일 덩어리(Component)' 단위로 패키징(포장)하는 것이 구현 뷰의 최우선 목적이다.
  2. 컴포넌트(Component)의 철학:
    • 컴포넌트는 단순히 코드를 모아둔 폴더가 아니다.
    • "독립적으로 교체 가능할 것". 내일 자동차의 타이어가 터지면 타이어만 쏙 빼서 새 타이어로 끼우듯, 결제 로직이 바뀌면 기존 결제 쇳덩어리(Pay.dll)를 삭제하고 새로 컴파일된 Pay_v2.dll을 끼워 넣기만 하면 전체 시스템이 돌아가도록 덩어리의 선(인터페이스)을 예쁘게 잘라두는 예술이다.

📢 섹션 요약 비유: 논리 뷰가 "집에 화장실 1개, 안방 1개를 배치하자"라는 '건축 평면도(아이디어)'라면, 구현 뷰는 "화장실 벽은 콘크리트 블록(컴포넌트 A)으로 공장에서 찍어오고, 안방 바닥은 목재 패널 블록(컴포넌트 B)으로 찍어와서, 트럭에 싣고 와 조립하자"라는 '실물 자재(코드 파일) 조립 지시서'입니다. 설계의 개념이 진짜 눈에 보이는 물리적인 코드 덩어리로 형체를 갖추기 시작하는 첫 단계입니다.

Ⅱ. 핵심 무기: 컴포넌트 다이어그램 (Component Diagram)

누가 누구를 찌르고, 누가 누구에게 빨대를 꽂히는지 화살표로 통제하라.

  1. 컴포넌트 박스와 인터페이스(Interface):
    • 도면에 [회원 관리]라는 직사각형(컴포넌트)을 그린다.
    • 이 덩어리는 자기 내부 소스코드를 절대 남에게 보여주지 않는 블랙박스다. 대신 밖으로 동그란 '막대사탕(제공 인터페이스, Provided)'을 쭉 내밀고 있다. "내 기능 쓰고 싶으면 이 막대사탕(API)만 핥아라!"
    • 옆에 있는 [게시판] 컴포넌트는 반원 모양의 '빨대(요구 인터페이스, Required)'를 그린다. "난 회원의 권한 정보가 필요해!"
  2. 의존성 (Dependency)의 무서움:
    • [게시판]의 빨대를 [회원 관리]의 막대사탕에 찰칵! 하고 연결(화살표 긋기)한다.
    • 이것이 그 무시무시한 **의존 관계(Dependency)**다. 이제 회원 관리 코드가 박살 나거나 인터페이스가 바뀌면, 거기에 빨대를 꽂고 있던 게시판 코드도 덩달아 에러를 뿜으며 피를 토하게 된다.
  3. 스파게티 아키텍처 방어:
    • 구현 뷰를 그리는 이유는 바로 저 화살표(빨대)들이 서로 빙글빙글 돌며(순환 참조) 엉망진창으로 엉키는 것을 막기 위해서다.
    • 아키텍트는 "화살표는 무조건 위(화면단)에서 아래(DB/공통모듈)로 단방향으로만 흐르게 꽂아라! 밑에 있는 놈이 위에 있는 놈한테 빨대 꽂으면(역방향 참조) 설계도 기각(Reject)이다!"라고 코딩의 규칙을 뼈대 위에 박아버린다.

📢 섹션 요약 비유: 컴퓨터 본체 뒷면을 설계하는 것과 같습니다. 메인보드(컴포넌트 A)에는 둥근 구멍(제공 인터페이스)이 파여 있고, 모니터(컴포넌트 B)는 뾰족한 선(요구 인터페이스/빨대)을 가지고 있습니다. 모니터 선을 본체 구멍에 끼우는 순간(의존성), 본체가 전원이 나가면 모니터도 같이 꺼지는 운명 공동체가 됩니다. 구현 뷰는 이 수만 가닥의 전선들이 엉키지 않게, "모니터 선은 본체에만 꽂아라, 본체 선을 모니터에 꽂는 멍청한 짓은 절대 금지다!"라고 배선 규격(의존성 방향)을 완벽히 통제하는 조립 도면입니다.

Ⅲ. 패키지 다이어그램과 형상 관리(Git) 연동

개발자의 폴더 트리가 이 도면 한 장에서 100% 결정된다.

  1. 패키지 다이어그램 (폴더 구조화):
    • 자바(Java)로 프로젝트를 시작할 때 이클립스나 인텔리제이 왼쪽에 뜨는 트리 모양의 패키지(com.company.order, com.company.pay) 폴더 구조가 바로 이 구현 뷰에서 100% 1:1로 튀어나온다.
    • 아키텍트가 도면에 [UI 레이어 패키지], [비즈니스 레이어 패키지] 폴더 모양 아이콘을 그려서 계층을 나누면, 다음 날 출근한 막내 개발자는 깃허브(Git)에 똑같은 이름으로 새 폴더를 3개 만들고 코딩을 시작한다.
  2. 동시 병렬 개발 (Subcontracting):
    • 구현 뷰의 컴포넌트 덩어리를 기가 막히게 예쁘게 찢어두면(결합도 최소화), 회사는 프로젝트를 여러 외주 업체(SI)에 쪼개서 병렬로 하청을 줄 수 있다.
    • "A 업체는 결제 컴포넌트 .jar만 짜고, B 업체는 회원 컴포넌트 .jar만 짜라. 서로 남의 코드는 볼 필요도 없고 간섭도 안 된다. 나중에 컴파일된 두 쇳덩어리 가져오면 우리가 가운데 잭(Interface)만 끼워서 통신시킬게!" (이 철학이 훗날 MSA 마이크로서비스로 진화하는 뼈대가 된다.)

📢 섹션 요약 비유: 자동차 설계도를 바탕으로 하청 업체에 공장 오더를 내리는 단계입니다. 구현 뷰(컴포넌트 도면)를 예쁘게 잘 찢어 놨다면, 현대차 본사(아키텍트)는 한국 타이어에 "바퀴 덩어리(컴포넌트) 하나 만들어 와!"라고 주문하고, 만도기계에 "브레이크 덩어리 만들어 와!"라고 동시에 병렬로 외주를 줄 수 있습니다. 타이어 회사는 브레이크 도면(남의 소스코드)을 1%도 알 필요 없이 자기 공장(패키지)에서 타이어만 열심히 찍어내면 되는 완벽한 분업(Decoupling) 개발 체계의 완성입니다.