UML 클래스 다이어그램으로 도메인 구조와 책임을 설계하는 법

도메인 지식과 코드 구조를 연결하는 정적 모델

클래스 다이어그램은 시스템의 정적 구조를 드러내는 UML 산출물이다. 클래스와 인터페이스의 속성·연산·가시성, 그리고 타입 사이의 연관, 합성, 상속, 의존, 실체화 관계를 기록한다. 이를 통해 요구사항에서 발견한 도메인 개념을 코드 구조와 연결하고, 책임 배분과 추상화 수준을 검토할 수 있다.

객체 다이어그램이 특정 시점의 인스턴스 상태를 보여준다면, 클래스 다이어그램은 그 상태를 만들 수 있는 타입 구조를 다룬다. 시퀀스 다이어그램과 커뮤니케이션 다이어그램은 동적 상호작용을 보완한다. ERD가 데이터 중심의 구조를 표현하는 데 비해, 클래스 다이어그램은 책임과 행위를 중심으로 모델을 구성한다.

표현은 OMG UML 2.5.1을 기준으로 삼을 수 있으나, 도구마다 표기 방식에 차이가 있을 수 있다.

클래스 안에 담는 책임과 추상화 수준

클래스는 속성(Attributes)과 연산(Operations)을 가진다. 가시성은 + public, # protected, - private로 나타낸다. 정적 속성이나 연산은 밑줄로, 추상 클래스와 추상 연산은 이탤릭으로 표현해 타입의 역할과 추상화 수준을 구분한다.

책임-주도 설계(RDD)와 함께 사용하면 각 클래스가 맡아야 할 책임을 더 분명히 나눌 수 있고, 응집도를 높이는 데 도움이 된다.

관계가 생명주기와 변경 비용을 결정한다

연관(Association), 합성·집합(Composition/Aggregation), 상속(Generalization), 의존(Dependency), 실체화(Realization)는 모두 타입을 연결하지만 의미와 결합 강도가 다르다.

다중성 1, 0..1, 0.._, 1.._는 연결 가능한 객체 수를 나타내고, 화살표는 탐색 가능성을 표현한다. 한정자(Qualifier)는 관계의 식별 기준을 드러내며, 연관 클래스(Association Class)는 관계 자체에 속성이나 식별 정보를 부여할 때 사용한다.

패키지는 모듈의 경계를 표현한다. 패키지 멤버의 public/private 범위를 통제하고, 상위 레이어에서 하위 레이어로 향하는 단방향 의존 원칙을 유지하면 순환 의존을 줄일 수 있다. 안정된 인터페이스 계층을 보존하는 일은 변경 비용을 낮추는 기반이 된다.

제약(Constraints)과 OCL은 모델의 무결성 규칙을 명시하는 수단이다. context Order inv TotalEqualsSumOfItems처럼 객체 상태가 만족해야 하는 조건을 모델에 남길 수 있다. <<Entity>>, <<ValueObject>>, <<PII>> 같은 프로파일과 스테레오타입은 도메인 또는 보안 맥락을 일관된 표기로 정리한다.

주문 모델에서 보는 합성과 연관

⤢✕

Order와 OrderItem은 생명주기가 일치해야 하는 구성으로 합성(Composition)을 적용한다. 반면 Payment는 주문과 분리된 생명주기를 허용하며, 0..* 결제 시나리오를 수용한다. 관계를 설계할 때는 탐색 방향을 최소화하고, 필요하지 않은 양방향 연관은 피하는 편이 낫다.

요구사항을 검증 가능한 모델로 바꾸는 흐름

모델링은 요구사항 명세, 유즈케이스, 용어사전, 이벤트 스토밍 산출물에서 출발한다. 성능·보안·규정준수 같은 비기능 요구와 경계 컨텍스트(Bounded Context)도 함께 정의한다.

후보 클래스를 찾은 뒤 CRC 카드와 RDD를 통해 책임을 배분하고, 응집도와 결합도를 점검한다. 이어서 합성·집합·연관·상속·실체화 가운데 적합한 관계를 선택하고, 다중성·탐색성·제약/OCL을 결정한다. 패키지를 계층화하면서 인터페이스를 식별하고 순환 의존을 제거한다.

완성된 모델은 시퀀스 다이어그램을 이용한 시나리오 워크스루와 샘플 인스턴스 객체 다이어그램으로 교차 검증할 수 있다. 산출물에는 버전 태깅된 클래스 다이어그램, 용어사전, 설계 결정 기록(ADR), 검증 체크리스트가 포함된다.

합성 관계에 여러 소유자를 정의하면 오류가 발생하므로 단일 소유자로 정규화해야 한다. 순환 의존이 발견되면 인터페이스를 추출하거나 이벤트 발행으로 연결을 끊을 수 있다. 트랜잭션 경계는 합성 경계와 일치시키는 것을 권장하며, 애그리게잇 기준으로 잠금 경합을 줄이려면 연관 탐색에도 제약이 필요하다.

설계·운영에서 쓰이는 장면

백엔드 도메인 모델링에서는 엔티티와 값 객체를 구분하고, 애그리게잇 경계와 일관성 규칙을 시각화하는 데 활용한다. API 계약과 코드 생성을 함께 설계할 때는 OpenAPI·프로토 계약과 맞추며 DTO와 엔티티 스캐폴딩의 기준으로 사용할 수 있다.

레거시 시스템에서는 역공학으로 다이어그램을 만들고 의존 그래프를 파악한다. 이를 바탕으로 순환 의존 제거와 모듈 분리 계획을 세울 수 있다.

설계 결함의 조기 발견을 가정하면 요구사항 추적성 향상과 함께 결함률 1020% 감소를 기대할 수 있다. 온보딩 기간은 2030% 단축되고, 변경 영향 분석 시간은 30% 이상 절감될 수 있다. 일관성 규칙을 명문화하면 운영 사고를 줄이고 변경 승인·검토 프로세스도 효율화할 수 있다.

관계 선택에 따른 설계상의 차이

관계 유형	일관성	확장성	안정성	운영 편의
연관(Association)	중간 수준, 다중성·제약에 의존	높음, 방향/탐색 조절 용이	중간, 양방향 시 취약	높음, 구현 단순
합성(Composition)	높음, 불변식 강제 용이	중간, 강결합로 변경 비용 증가	높음, 불일치 감소	중간, 트랜잭션 경계 관리 필요
상속(Generalization)	중간, 계약 설계에 좌우	낮음, 트리 깊어질수록 취약	낮음, 파급 영향 큼	낮음, 버전 호환 난이도
의존(Dependency)	낮음, 일시적 결합	높음, 인터페이스화 유리	중간, 의존 폭 증가 시 위험	높음, 배포 분리 용이
실체화(Realization)	계약 기반으로 예측 가능	높음, 구현 교체 용이	높음, 테스트 용이	높음, 모듈 경계 명확

생명주기가 강하게 결합된 대상에는 합성을, 결합을 완화해야 한다면 집합을 선택한다. 다만 합성을 과도하게 쓰면 변경 비용이 커질 수 있다. 깊은 상속 트리는 깨지기 쉬운 베이스 클래스 문제를 만들 수 있으므로 상속은 최소화하고, 역할 변화에는 인터페이스나 전략 패턴을 우선 고려한다.

양방향 연관은 불변식을 맞추는 검증 비용을 높인다. 조회 요구가 있는 경우에만 단방향 탐색을 허용하는 기준이 필요하다. <<PII>>, <<Secret>> 스테레오타입은 민감 데이터를 식별하고 암호화·마스킹 책임을 남기는 데 사용하며, 모델과 코드의 정책은 일치해야 한다.

클래스 모델과 ER 스키마는 같은 구조가 아니다. 값 객체는 내포(Embedding)하고, 애그리게잇 사이의 연관은 식별자 참조로 느슨하게 결합할 수 있다. Mermaid, PlantUML, StarUML 등을 혼합해 쓴다면 표기 차이를 관리해야 하며, UML 버전과 도구 렌더링 차이에 대한 병행 가이드가 필요하다.