컴포넌트 다이어그램으로 설계하는 모듈 경계와 의존성
UML 컴포넌트 다이어그램에서 제공·요구 인터페이스, 의존성 방향, 배포 매핑을 설계하는 방법을 정리합니다.
2026-08-14 · 최초 발행 2025-10-31
경계와 계약을 한 화면에 드러내는 UML 다이어그램
컴포넌트 다이어그램은 시스템을 교체 가능한 컴포넌트와 그 사이의 인터페이스·연결 관계로 나타내는 UML 구조 다이어그램이다. 여기서 컴포넌트는 배포 단위일 수도 있고 논리 모듈일 수도 있다.
모델은 제공(Provided) 인터페이스와 요구(Required) 인터페이스, 포트(Port), 어셈블리·위임 커넥터, 패키지와 배포의 매핑을 다룬다. 모듈 간 결합도를 낮추고 응집도를 높이며, 의존성이 향하는 방향을 일관되게 유지하는 데 목적이 있다. 독립적인 개발·빌드·배포 경로를 확보하려는 서비스 지향, 마이크로서비스, 플랫폼 제품 환경에서도 유용하다.
컴포넌트는 자신이 맡은 책임과 경계를 명확히 가져야 한다. 외부에는 포트를 통해 제공 또는 요구 인터페이스를 드러내고, 계약에는 ABI/API 수준의 버전을 표기할 수 있다. 요구 인터페이스와 제공 인터페이스를 연결하는 어셈블리 커넥터는 실제 결선 관계를 표현한다.
안정성이 높은 모듈을 향하도록 의존성 방향을 통제하고, Bounded Context·Layer·Subsystem 같은 경계를 시각화한다. 패키지 다이어그램과 함께 보면 네임스페이스와 소스 구조가 설계와 맞는지도 확인할 수 있다.
컴포넌트와 아티팩트, 노드(Deployment)의 관계를 연결하면 운영 토폴로지까지 설계 범위에 들어온다. Replica, Zone, Edge를 고려한 확장 전략도 이 단계에서 반영할 수 있다. 인터페이스의 SemVer, 호환성 표시, 변형(Variant)을 기록하고 호환성 매트릭스와 업그레이드 경로를 문서화하는 일도 포함된다.
서비스 분해부터 플랫폼 조립까지
이 다이어그램은 마이크로서비스 경계를 정하고 API 계약을 관리할 때 사용한다. 레거시 모놀리식을 분해하면서 스트랭글러 패턴 이행 계획을 세우거나, COTS·오픈소스 통합 지점과 교체 전략을 검토하는 데도 맞는다.
도메인별 API 거버넌스와 팀 책임(Owner)을 연결해 볼 수 있으며, 데이터 제품과 플랫폼 컴포넌트의 조립 방식, 운영 자동화 파이프라인의 구조를 설계할 때도 활용할 수 있다.
요구사항에서 운영 제약까지 연결하는 과정
모델링은 비즈니스 요구사항, 도메인 맥락, NFR(성능/가용성/보안)에서 출발한다. 기존 시스템 토폴로지, 팀 구조, 배포 제약도 함께 입력으로 둔다.
컴포넌트 후보를 찾은 뒤 경계와 책임을 확정하고, 제공·요구 인터페이스에 데이터 계약과 에러 계약을 명시한다. 다음으로 상위 안정 모듈을 향하는 의존성 규칙을 세우고 순환을 제거한다. 런타임 노드, 레플리카, 네트워크를 기준으로 배포를 매핑하며 관찰성 요구도 반영한다. 마지막으로 시퀀스 다이어그램을 이용해 시나리오를 추적하고 품질 속성을 점검한다.
결과물은 컴포넌트 다이어그램뿐 아니라 인터페이스 카탈로그, 의존성 규칙, 배포 맵, 변경 영향도 행렬, 팀 오너십 매트릭스로 이어진다. 순환 의존이 발견되면 경계를 다시 나누거나 중간 파사드를 둘 수 있다. 인터페이스가 누락되거나 중복되면 계약을 통합하거나 버전을 분기한다. 컴포넌트가 지나치게 잘게 나뉜 경우에는 결합도와 운영 복잡도를 다시 평가해 통합 여부를 결정한다.
설계 검토에 필요한 다이어그램 조합
컴포넌트 다이어그램은 경계와 의존 관계를 판단하는 데 강점이 있다. 행위 흐름은 시퀀스 다이어그램, 런타임 배치는 배포 다이어그램이 보완한다.
| 다이어그램 | 성능 | 확장성 | 일관성 | 안정성 | 운영 편의 |
|---|---|---|---|---|---|
| 컴포넌트 | 중 | 고 | 고 | 고 | 고 |
| 클래스 | 저 | 중 | 고 | 중 | 저 |
| 배포 | 고 | 고 | 중 | 고 | 중 |
| 시퀀스 | 중 | 중 | 중 | 중 | 저 |
이 평가는 각 품질 속성을 달성하기 위한 의사결정 지원 기여도를 상대적으로 나타낸다. 컴포넌트 다이어그램으로 경계와 의존성을 보고, 시퀀스 다이어그램으로 행위를 검토하고, 배포 다이어그램으로 런타임을 연결하는 조합이 적합하다.
인터페이스 계약을 표시하는 예시
아래 예시는 제공·요구 인터페이스를 드러내고, 어댑터와 도메인 경계를 분리하며, 버전 호환성을 표기한다.
분리의 이점과 운영 복잡도의 균형
모듈은 높은 응집과 낮은 결합을 유지하면서 비즈니스 기능 단위의 독립 배포를 지향한다. 의존성은 안정성이 높은 모듈을 향하는 단방향으로 유지하고 순환을 허용하지 않는다. 인터페이스 계약에는 데이터 스키마, 에러 코드, 슬라(성능·가용성)를 명시하며 SemVer를 적용한다.
관찰성도 컴포넌트의 외부 계약으로 다룬다. 각 컴포넌트에 로깅·트레이싱·메트릭 계약을 포함하면 운영 단계의 추적성을 설계에서 확보할 수 있다.
세분화가 과하면 운영 복잡도와 네트워크 지연이 늘어난다. 반대로 지나친 통합은 변경 충격을 키운다. 컴포넌트의 그래뉼러리티는 이 두 비용을 함께 보고 결정해야 한다.
변경 영향 범위를 줄이고 회귀 결함을 낮추면 평균 수정 시간(MTTR)을 10~30% 단축할 가능성이 있다. 팀의 병렬 개발 효율과 독립 배포 비율이 높아지면 릴리스 리드타임 단축에도 연결된다. 아키텍처 가시성은 설계 리뷰, 보안 점검, 용량 계획의 자동화 연동을 쉽게 만들고, 인터페이스 버전과 호환성 관리는 롤링 업그레이드와 카나리 배포의 리스크를 낮춘다.