87. 구현 뷰 (Implementation View) - 소프트웨어 모듈 컴포넌트 설계

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

> 1. **본질**: 구현 뷰 (Implementation View)는 소프트웨어를 어떤 패키지·모듈·컴포넌트로 나눠 빌드하고 관리할지를 보여주는 구조다.
> 2. **가치**: 컴포넌트 다이어그램은 의존성과 제공/요구 인터페이스를 드러내어, 코드 조직이 아니라 컴파일·재사용 경계를 설계하게 만든다.
> 3. **판단 포인트**: 논리 구조만 보면 기능은 보여도 유지보수 경계가 흐려지고, 구현 뷰를 쓰면 빌드·배포·팀 책임까지 함께 정렬할 수 있다.

---

## Ⅰ. 개요 및 필요성

구현 뷰 (Implementation View)는 4+1 뷰 모델에서 코드가 실제로 어떤 단위로 묶이고 빌드되는지 보여준다. UML (Unified Modeling Language) 기준으로는 패키지 다이어그램과 컴포넌트 다이어그램이 주로 쓰이며, 이는 클래스 관계보다 더 높은 수준에서 모듈 경계를 설명한다.

대규모 시스템은 기능 목록만으로는 유지되지 않는다. 어떤 패키지가 어떤 API를 공개하고, 어떤 모듈이 어떤 팀의 책임인지가 명확해야 변경이 한 곳에서 끝난다. 구현 뷰는 바로 그 경계를 설계 문서로 고정하는 역할을 한다.

- **📢 섹션 요약 비유**: 큰 장난감을 종류별 상자에 나눠 넣는 것처럼, 코드는 역할별 구역에 들어가야 찾기 쉽다.

---

## Ⅱ. 아키텍처 및 핵심 원리

구현 뷰의 핵심은 컴포넌트가 서로를 직접 참조하는 것이 아니라, 제공 인터페이스와 요구 인터페이스로 연결된다는 점이다. 패키지 (Package)는 소스 코드 묶음이고, 컴포넌트 (Component)는 독립 배포 또는 교체 가능한 기능 단위다.

요소	역할	패키징 포인트
Package	소스와 타입을 묶는 논리 단위	순환 의존 금지, 공개 범위 최소화
Component	교체 가능한 기능 블록	명확한 인터페이스와 버전 정책
Interface	호출 규약	구현 세부를 숨기고 계약만 노출
Artifact	빌드 산출물	JAR, DLL, 이미지 등 배포 단위

[ui package] ──► [application package] ──► [domain package]
       │                    │                   │
       │                    ▼                   ▼
       └──────────────► [interface contract] [infra package]

이 구조가 중요한 이유는 코드가 파일 시스템에 존재하는 방식과, 설계자가 책임을 나눈 방식이 같아야 변경 비용이 줄어들기 때문이다.

- **📢 섹션 요약 비유**: 연결선이 많은 로봇 조립도에서 부품 역할과 호환 규칙을 먼저 정하는 것과 같다.

---

## Ⅲ. 비교 및 연결

구현 뷰는 논리 뷰, 프로세스 뷰, 배포 뷰와 역할이 다르다.

뷰	질문	초점
논리 뷰	무엇을 하는가?	객체, 책임, 기능
구현 뷰	어떻게 코드로 묶는가?	패키지, 모듈, 컴포넌트
프로세스 뷰	런타임에 어떻게 흐르는가?	스레드, IPC, 동시성
배포 뷰	어디에 올라가는가?	서버, 컨테이너, 네트워크

패키지 기준이 기능이 아니라 계층이면, 작은 변경도 여러 계층을 따라 퍼질 수 있다. 반대로 feature-based packaging은 기능 단위 응집도를 높이지만, 공유 코어가 약하면 중복이 늘 수 있다. 따라서 구현 뷰는 계층과 기능의 균형을 맞추는 협상 도구로 봐야 한다.

- **📢 섹션 요약 비유**: 지도는 방 이름을 알려주고, 설계도는 벽 위치를 알려준다. 구현 뷰는 설계도에 더 가깝다.

---

## Ⅳ. 실무 적용 및 기술사 판단

실무에서는 다음 순서로 판단하면 좋다. 핵심 변경이 자주 일어나는 제품이면 기능 기준 패키징을 우선하고, 안정적인 라이브러리나 공통 인프라면 계층 기준으로 명확히 분리한다.

체크리스트

패키지 간 순환 의존이 없는가?
공개 API가 최소화되어 있는가?
컴포넌트 경계가 팀 책임 경계와 맞는가?
빌드 도구가 모듈 경계를 강제하는가?

안티패턴

util 패키지 하나에 모든 코드가 몰리는 구조
화면·도메인·DB 코드가 서로를 직접 호출하는 구조
다이어그램은 멀쩡한데 실제 폴더 구조는 완전히 다른 구조
- 📢 섹션 요약 비유: 한 상자에 다 넣는 대신, 같은 부품끼리만 이어지는 레고 블록 설계가 필요하다.
Ⅴ. 기대효과 및 결론

구현 뷰가 잘 잡히면 리팩터링, 테스트, 배포가 모두 쉬워진다. 특히 컴포넌트 경계를 통해 변경 영향 범위를 줄이면, 새 기능을 넣어도 회귀 위험이 낮아진다.

반대로 패키징을 지나치게 잘게 쪼개면 오히려 네비게이션 비용이 커진다. 따라서 구현 뷰는 "코드를 나누는 그림"이 아니라 "변경 비용을 최소화하는 책임 지도"로 기억하는 것이 정확하다.

- **📢 섹션 요약 비유**: 책상 서랍을 과목별로 나누면 필요한 공책을 빨리 찾을 수 있는 것과 비슷하다.

---

### 📌 관련 개념 맵

| 개념 | 연결 포인트 |

### 📈 관련 키워드 및 발전 흐름도

클래스 설계
│
▼

패키지/모듈 분리 │ ▼ 컴포넌트 인터페이스 정의 │ ▼ 빌드 산출물과 배포 단위 정렬

### 👶 어린이를 위한 3줄 비유 설명

1. 장난감을 종류별 상자에 넣으면 다시 찾기 쉬워요.
2. 상자 사이에 연결 규칙이 있으면 부품이 서로 헷갈리지 않아요.
3. 그래서 코드는 아무 데나 두는 것보다 역할대로 나누는 게 좋아요.

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

체크리스트

안티패턴

Ⅴ. 기대효과 및 결론