UML 복합 구조 다이어그램으로 내부 협력과 경계 모델링하기
UML 복합 구조 다이어그램의 파트·포트·커넥터와 협력 구조를 정리하고, 내부 연결 정책을 설계·검증하는 방법을 다룬다.
2026-08-14 · 최초 발행 2025-10-31
내부 협력 구조를 모델에 남기는 방법
복합 구조 다이어그램(Composite Structure Diagram)은 클래스나 컴포넌트의 정적 선언만으로 보이지 않는 내부 협력 구조를 표현하는 UML 2.x 표기법이다. 런타임에 배치되는 파트, 외부와 맞닿는 포트, 이들을 잇는 커넥터를 모델에 담아 요청과 책임이 내부에서 어떻게 이어지는지 드러낸다.
마이크로서비스, 임베디드 시스템, 도메인 중심 설계처럼 내부 책임의 분리와 연결 정책이 설계 품질에 영향을 주는 환경에서 특히 유용하다. 단일 클래스나 컴포넌트의 내부 구성뿐 아니라 역할 기반 협력 구조, 어셈블리와 델리게이션 연결도 함께 명세할 수 있다.
파트(Part)는 내부 구성요소가 차지하는 슬롯이다. 타입(Class, Interface, Component), 역할명, 다중성을 지정한다. 포트(Port)는 외부와 내부를 가르는 인터페이스 경계로서 제공·요구 인터페이스와 프로토콜을 나타낸다. 커넥터(Connector)는 파트와 포트 사이의 통신 경로이며, 내부 상호연결인 어셈블리와 외부 경계에서 내부로 요청을 전달하는 델리게이션으로 나뉜다.
콜라보레이션(Collaboration)은 역할(Role) 집합으로 상위 협력 구조를 정의한다. 이를 구체 클래스에 바인딩하면 협력 패턴을 재사용할 수 있다.
포트와 커넥터가 드러내는 설계 경계
복합 구조 다이어그램은 타입보다 인스턴스 슬롯의 배치와 연결에 초점을 둔다. 인터페이스의 제공과 요구를 표시해 의존성을 드러내고, 포트를 통해 외부 노출 면과 내부 책임을 분리한다. 내부 구현을 바꾸더라도 포트 계약이 유지되면 외부 영향은 줄일 수 있다.
커넥터에는 동기·비동기 연결, 버퍼링·큐 정책 같은 통신 특성을 표시할 수 있다. 인터페이스 조건, 시퀀스 제약, 다중성, QoS도 함께 다룰 수 있으며, OCL이나 노트를 이용해 선행조건·후행조건과 오류 처리 규칙을 명세할 수 있다.
콜라보레이션 템플릿을 정의하면 Mediator, Proxy 같은 설계 패턴의 구조적 구현에도 활용할 수 있다. 인터페이스 불일치, 다중성 위반, 연결 누락을 정적으로 검증할 수 있고, 시뮬레이션이나 테스트에서 에뮬레이터와 스텁을 구성하기도 쉽다.
주문 서비스 내부 연결 예시
apiIn과 invOut은 외부 인터페이스 경계인 포트다. apiIn으로 들어온 요청은 델리게이션 커넥터를 통해 PaymentHandler로 전달된다. PaymentHandler와 InventoryProxy의 관계는 어셈블리 커넥터로 표현하며, InventoryProxy는 다시 invOut 포트를 거쳐 Inventory Service와 통합한다. Payment Gateway로 연결되는 경로도 함께 확인할 수 있다.
모델을 작성할 때 확인할 흐름
유즈케이스, 시퀀스 다이어그램, 도메인 클래스, 인터페이스 정의서에서 입력을 수집한다. 성능 목표(QPS/Latency), 장애 격리 기준, 보안 정책(API 권한/암호화)도 이 단계에서 제약으로 정리한다.
이후 주요 서비스·컴포넌트·장치 가운데 StructuredClassifier 후보를 고르고, 내부 책임을 분해해 파트와 역할, 다중성을 정한다. 외부에 제공하거나 요구하는 인터페이스는 포트로 분리하고, 요청–응답·스트림·QoS 같은 포트별 프로토콜과 계약을 명세한다.
포트에서 내부 파트로 들어가는 경로는 델리게이션 커넥터로, 파트 사이의 연결은 어셈블리 커넥터로 설계한다. 파트 간 연결에는 동기·비동기 방식과 버퍼링·큐 정책을 표시할 수 있다. 다중성, 스레드 안전성, 트랜잭션 경계, 타임아웃도 필요한 범위에서 부착한다. 오류 처리에서는 재시도, 서킷 브레이커, 대체 경로를 명시한다.
마지막으로 제공·요구 인터페이스의 합치성, 타입과 포트의 불일치를 확인한다. 시퀀스 다이어그램과 라운드트립 검증을 수행하고 테스트 더블을 매핑한다. 산출물은 복합 구조 다이어그램, 인터페이스 계약서(IDL/Swagger), 연결 구성표와 요구사항 ↔ 역할/포트 ↔ 테스트 케이스의 추적 매핑으로 이어진다.
포트 타입이 지정되지 않았다면 컴파일 전 검증 규칙으로 차단하고 기본 인터페이스를 할당한다. 1..1에 0 연결이 발생하는 다중성 위반은 모델 검증 에러와 연결 필수 경고로 처리한다. 동기와 비동기 프로토콜이 맞지 않으면 어댑터 파트를 삽입하거나 포트를 분리한다.
내부 연결 정책을 다뤄야 하는 시스템
마이크로서비스에서는 API 포트, 내부 핸들러, 외부 서비스 프록시를 분리해 내부 구조를 명세할 수 있다. 서킷 브레이커와 리트라이처럼 서비스 안에 포함된 레질리언스 메커니즘도 연결 경로에 표시한다.
임베디드·IoT 시스템에서는 센서·액추에이터 포트와 제어 로직 파트를 나누고 실시간성 제약을 붙인다. CAN, SPI 같은 버스와 프로토콜을 커넥터로 명시하면 타이밍 분석에도 도움이 된다.
DDD에서는 애그리게이트 내부 협력 구조와 인바운드·아웃바운드 포트를 연결해 볼 수 있다. 애플리케이션 서비스, 도메인 서비스, 리포지토리 간 연결도 같은 방식으로 명세한다. UI 컴포지션에서는 View 포트와 Presenter 또는 Controller 파트의 연결로 이벤트 흐름을 모델링하고, 상태 저장·검증 컴포넌트를 분리해 테스트 용이성을 높일 수 있다.
설계 검증과 운영 관점에서의 효과
인터페이스 불일치와 연결 누락을 통합 이전에 발견하면 통합 단계의 이슈를 줄일 수 있다. 조직과 도메인에 따라 통합 결함 10~30% 수준 감소를 기대할 수 있으며, 경험치 기반이므로 편차는 존재한다.
포트 기반 경계는 내부 리팩토링이 외부에 미치는 영향을 축소한다. 호환성이 필요할 때는 어댑터 파트를 삽입하기 쉽다. 동기·비동기와 큐잉 같은 커넥터 정책을 모델에 남기면 병목 분석의 기반이 되고, 장애 격리 경로와 대체 경로를 명시해 MTTR 단축도 기대할 수 있다.
포트와 엔드포인트를 매핑하면 모니터링·로그의 상관관계를 분석하기 쉬워진다. 테스트 더블(스텁/모크) 설계 자동화에도 활용할 수 있다.
클래스·컴포넌트 다이어그램과의 선택 기준
| 지표 | 클래스 다이어그램 | 복합 구조 다이어그램 | 컴포넌트 다이어그램 |
|---|---|---|---|
| 성능(평가/튜닝 적합도) | 낮음 | 중간 | 중간~높음 |
| 확장성(확장 경로 가시화) | 낮음 | 중간 | 높음 |
| 일관성(타입/관계 일관성) | 높음 | 중간 | 중간 |
| 안정성(장애 격리 표현력) | 낮음 | 높음 | 높음 |
| 운영 편의(모니터링 연계) | 낮음 | 중간 | 높음 |
내부 협력과 경계, 연결 정책을 명세해야 한다면 복합 구조 다이어그램이 적합하다. 배포 단위나 노드 관점까지 확장해야 하면 컴포넌트 다이어그램이나 배포 다이어그램으로 보완한다.
포트에는 제공·요구 인터페이스와 프로토콜을 표시하고, 불필요한 포트를 늘리지 않아야 결합도를 관리할 수 있다. 커넥터에는 동기·비동기, 재시도·타임아웃, 트랜잭션 경계 속성을 부여한다. 반복되는 Adapter, Proxy 구조는 콜라보레이션 템플릿으로 재사용할 수 있다.
반대로 내부 파트를 과도하게 분해하면 모델 복잡도와 유지보수 비용이 커진다. 도구별 지원 수준의 차이도 있으므로 코드와 모델을 동기화하는 정책이 필요하다. 오토스케일처럼 런타임 토폴로지가 동적으로 변하는 상황은 모델만으로 표현하기 어려워 실행 시 뷰(Observability)로 보완해야 한다.