UML 모델·뷰·다이어그램을 분리해 설계 일관성 관리하기

그림이 아니라 원천 모델에서 시작하는 UML

UML(Unified Modeling Language)은 소프트웨어와 시스템을 표준 표기법으로 추상화하는 모델링 언어다. 규모가 커질수록 다이어그램을 개별 문서로 관리하는 방식은 변경과 검증에서 쉽게 흔들린다. 모델을 원천으로 두고, 이해관계자별 뷰를 정의한 뒤, 다이어그램을 그 결과물로 다루면 설계·문서화·변경 관리의 일관성과 추적성을 유지할 수 있다.

모델은 시스템의 개념과 규칙을 메타모델에 따라 구조화한 추상 표현이다. 도메인 개념, 관계, 제약을 저장소(repository)에 일관되게 보관하며 단일 사실 원천(Single Source of Truth)이 된다.

뷰는 특정 이해관계자(stakeholder)가 필요로 하는 모델의 부분집합을 조직한 관점이다. ISO/IEC/IEEE 42010의 관점-관심사 체계를 적용해 요구, 품질 속성, 책임을 선택적으로 보여준다.

다이어그램은 뷰 또는 모델 일부를 시각적으로 표현한 구체 산출물이다. UML 표기법을 통해 커뮤니케이션과 검증을 지원하며, 뷰를 구현하거나 모델을 직접 투영할 수 있다.

모델은 제약과 관계를 보관한다

모델에는 클래스, 속성, 연관, 상태, 활동처럼 시스템을 설명하는 핵심 요소가 들어간다. UML 2.5.x 메타모델을 준수하고, 형상관리 및 버전 분기 전략을 적용해 변경 이력을 다룬다. main/release/hotfix와 같은 분기 전략, OCL 제약과 규칙 기반 검증 자동화도 이 계층에서 연결된다.

다이어그램만 먼저 만들면 서로 다른 그림이 같은 개념을 다르게 설명할 수 있다. 반대로 모델을 기준으로 두면 스코프 확장과 일관성 검증에 강점을 갖는다. 그 대가로 초기 구축 비용과 관리 부담은 커진다.

이해관계자마다 필요한 뷰가 다르다

아키텍트, 개발, 운영, 보안 담당자는 같은 시스템을 보더라도 확인하려는 내용이 다르다. 뷰는 이 관심사를 명시하고 필요한 모델 요소만 노출하는 장치다.

4+1 뷰 모델은 논리, 개발, 프로세스, 물리 뷰와 시나리오를 함께 다루는 방식으로 실무에서 빈번히 사용된다. 다만 뷰가 늘어날수록 관리 대상도 늘어난다. 이해관계자-관심사 매트릭스를 유지해 뷰 증식을 통제해야 한다.

다이어그램은 관점을 전달하는 산출물이다

UML 다이어그램은 목적에 따라 구조, 행위, 상호작용을 표현한다.

구조 다이어그램에는 클래스, 컴포넌트, 컴포지트 구조, 배치, 오브젝트, 패키지가 포함된다.
행위 다이어그램에는 유스케이스, 활동, 상태 머신이 포함된다.
상호작용 다이어그램에는 시퀀스, 커뮤니케이션, 타이밍, 상호작용 개요가 포함된다. 최신 규격 확인이 필요하다.

모델·뷰·다이어그램의 특성은 다음과 같이 비교할 수 있다.

구분	확장성(스코프 확장)	일관성(검증/제약)	안정성(변경 내성)	운영 편의(협업/버전)	적용 성능(작성/탐색 효율)
모델	매우 높음	매우 높음	높음	중간	중간
뷰	중간	높음	중간	높음	높음
다이어그램	낮음~중간	도구 의존	낮음	매우 높음	매우 높음

뷰와 다이어그램은 협업과 전달에 유리하지만, 원천 사실을 유지하는 역할까지 대신하지는 못한다. 그 기반은 모델에 둬야 한다.

추적성과 검증을 변경 관리에 연결한다

요구사항에서 모델 요소, 테스트 케이스까지 양방향 추적성을 설정하면 변경 영향도 분석을 자동화할 수 있다. 클래스와 시퀀스 다이어그램 사이의 시그니처 불일치처럼 교차 다이어그램에서 발생하는 문제도 검사 대상이 된다. 이런 검증은 모델 부식을 막는 수단이다.

중앙 모델 저장소는 Git + XMI 또는 전용 리포지토리로 운영할 수 있다. 리뷰 워크플로우에는 CI 기반 검증을 연결하고, 모델링 가이드라인·명명 규칙·승인 기준을 명확히 둔다. 형식성을 강화할수록 작성 속도는 낮아질 수 있다는 트레이드오프가 있다.

설계부터 승인까지 이어지는 흐름

입력은 요구사항, 도메인 용어집, 비기능 요구, 제약으로 구성된다. 용어를 정합화하고 경계 컨텍스트를 식별한 뒤, 개념·클래스와 제약을 정의한다. 이어 시나리오와 시퀀스·상태·활동으로 행위를 모델링하고, 컴포넌트와 배치에 매핑해 실행 구조를 만든다. 뷰와 다이어그램을 생성한 다음 CI에서 일관성과 추적성을 검사하고, 리뷰·승인·버전 태깅을 거쳐 승인된 모델·다이어그램, 뷰 기반 문서, 코드 스텁·스키마 산출물을 낸다.

용어 충돌은 용어집을 우선하고 변경 제안 PR을 통해 합의한다. 다이어그램 표기 불일치는 메타모델 기준 자동 검증 스크립트로 차단한다. 모델과 코드의 드리프트는 역공학·전진공학 도구를 활용한 주기적 동기화 파이프라인으로 관리한다.

⤢✕

도입 맥락에 따른 모델 활용

API 중심 도메인 모델링에서는 핵심 도메인 클래스와 서비스 인터페이스를 모델에 정의한다. 소비자 뷰의 시퀀스 다이어그램으로 API 호출 흐름을, 내부 뷰의 클래스·컴포넌트 다이어그램으로 의존성을 드러내면 계약 위반을 조기에 탐지하고 변경 영향 범위를 산정할 수 있다.

마이크로서비스 아키텍처에서는 서비스 경계, 이벤트, 배포 노드를 모델에 둔다. 운영 뷰는 배치 다이어그램으로, 보안 뷰는 신뢰 경계 표시로, 개발 뷰는 컴포넌트 다이어그램으로 구성할 수 있다. 이는 배포·운영 표준화와 장애 대응 절차의 명확화에 연결된다.

의료·금융처럼 규제 준수가 필요한 시스템에서는 요구-설계-테스트 추적성 링크를 모델에 유지한다. 유스케이스는 시나리오 뷰로, 상태 머신은 안전성 뷰로 활용할 수 있으며 감사 대응 리드타임 단축과 변경 승인 근거 확보에 도움이 된다.

PlantUML로 모델과 소비자 뷰 표현하기

PlantUML 1.2023.x 이상과 Graphviz를 설치하거나 서버 렌더러를 사용할 수 있다. 다음 클래스 다이어그램은 모델 구조를 투영한 예시다.

@startuml
package "Sales" {
  class Order {
    +id: UUID
    +place(): void
  }
  class Customer {
    +id: UUID
    +name: String
  }
  Order "0..*" --> "1" Customer : placedBy
}
@enduml

다음 시퀀스 다이어그램은 소비자 뷰에서 주문 요청 흐름을 표현한다.

@startuml
actor Client
participant API
participant OrderService
Client -> API: POST /orders
API -> OrderService: createOrder(cmd)
OrderService --> API: OrderCreated
API --> Client: 201 Created
@enduml

모델이 바뀌면 클래스 다이어그램은 자동 재생성하고, 시퀀스 다이어그램은 시나리오 뷰를 기준으로 독립 관리할 수 있다. CI에서는 PlantUML 렌더링과 링크 무결성 검사를 수행한다.

운영 체계가 만드는 변화

자동 추적성 기반으로 변경 영향 분석 시간은 30~~50% 단축될 수 있다. 역할별 뷰를 제공하면 온보딩 기간은 20~~40% 단축되고, 일관성 검사는 설계 결함 사전 검출률을 15~30% 향상시킬 수 있다.

정량적 효과 외에도 이해관계자 사이의 공통 언어를 만들고, 문서 최신성과 신뢰도를 높이며, 규제와 감사 대응력을 강화한다. 초기 비용과 도구 의존성, 병합 충돌 대응은 남지만, 단일 모델·뷰 관리·자동 검증을 함께 운영하는 방식은 대규모 시스템의 변경 관리와 품질 확보에 적합하다.