UML 프로파일로 도메인 모델을 확장하는 방법

UML 메타모델을 바꾸지 않고 스테레오타입, 태그 값, OCL 제약, 프로파일로 도메인 요구를 모델에 반영하는 방법

2026-08-15 · 최초 발행 2025-10-31

메타모델을 바꾸지 않고 도메인 언어를 담는 방법

UML Extension Mechanisms는 표준 UML 위에 도메인 특화 요구를 얹기 위한 경량 확장 체계다. UML 메타모델 자체를 수정하는 대신, 기존 메타클래스에 의미를 부여하고 필요한 속성과 규칙을 연결한다. 도메인 특화 모델링(DSML)의 표현력을 확보하면서도 도구 상호운용성과 표준 준수성을 지키려는 목적에 맞는다.

이 방식은 스테레오타입, 태그 값, 제약, 프로파일로 구성된다.

  • 스테레오타입(Stereotype)은 메타클래스의 도메인 특화 유형을 정의한다.
  • 태그 값(Tagged Value)은 스테레오타입이 보유하는 속성값이다.
  • 제약(Constraint/OCL)은 모델이 지켜야 할 규칙을 선언한다.
  • 프로파일(Profile)은 이런 확장 정의를 묶어 재사용하는 단위다.

UML 자체의 메타모델을 변경하는 무거운 확장은 피한다. MOF 기반 도구 간 상호운용성과 표준 준수성을 유지하기 위해서다.

모델 요소에 의미와 정책을 연결하기

스테레오타입은 Class, Component, Association 같은 메타클래스에 의미론적 레이블을 붙인다. 도메인 개념과 UML 요소의 대응 관계가 분명해지고, 아이콘·모양·추가 속성·적용 범위도 정의할 수 있다. 스테레오타입은 상속 관계로 재사용하고 계층화할 수 있지만, 하나의 UML 요소에 여러 스테레오타입을 적용할 때는 의미 충돌을 피하는 규칙이 필요하다. 스테레오타입이 지나치게 늘어나면 모델을 읽기 어려워진다.

태그 값은 스테레오타입의 속성으로 구체적인 파라미터를 전달한다. 예를 들어 endpoint: URL, retry: Integer처럼 정의할 수 있다. 타입, 기본값, 다중성을 지정할 수 있으며, 도메인 정책을 데이터로 분리해 템플릿화하기에도 적합하다. 코드 생성·검증·보고서에서 사용하는 메타데이터를 태그 값으로 데이터화하면 모델 전반의 표현을 일관되게 유지할 수 있다.

OCL(Object Constraint Language)은 구조적·행위적 규칙을 선언하는 데 쓴다. endpoints > 0, latency < 10ms 같은 규칙을 표현할 수 있으며, 정적 분석에 기반한 자동 검증이 가능하므로 설계 단계 검증과 코드 생성 전 품질 게이트에 연결할 수 있다. 다만 제약을 과도하게 강화하면 모델링 유연성이 낮아질 수 있다.

프로파일은 스테레오타입·태그·제약을 패키징한 배포 단위다. 네임스페이스, 버전, 의존성을 명시한 패키지로 관리하고 하위 호환성 정책을 함께 마련한다. 모델에는 Profile Application을 수행하며, 어느 모델과 패키지 범위에 어떤 우선순위로 적용할지 설계한다. 적용과 해제가 가역적이며, SysML·MARTE·SoaML·UTP 같은 표준 프로파일과 함께 사용할 수 있다.

아키텍처와 모델링 파이프라인에 적용하는 모습

마이크로서비스 아키텍처에서는 Component«Service», «Gateway», «Adapter»를 적용해 역할을 표현할 수 있다. endpoint, timeout, circuitBreaker 정책은 태그 값으로 선언하고, 공개 API 가시성이나 순환 의존 금지는 OCL로 검증한다. 금융·통신 도메인에서는 «Service», «API», «Event»에 SLA와 규제 속성을 부여해 표현 방식을 표준화할 수 있다.

임베디드·실시간 시스템에서는 MARTE 프로파일을 기반으로 주기, 데드라인, 자원 제약과 스케줄러 특성을 모델링한다. 이 모델은 스케줄링·성능 분석 도구와 traceability 자동화에 사용된다.

데이터와 영속성 모델에서는 «Entity», «ValueObject», «Repository»로 영속성 경계를 드러낼 수 있다. 테이블명, 인덱스 힌트, 샤딩 키는 태그 값으로 관리한다.

규제 또는 보안 준수 모델에서는 «PII», «Secret», «Audited» 같은 스테레오타입으로 데이터 민감도를 표시한다. 암호화 필수 여부와 감사 추적 필드 존재 여부는 OCL 제약으로 확인한다. 추적성, 등급, 검증 상태 태그를 일원화하면 감사 대응 리포트를 자동 생성할 수 있고, 엔터프라이즈 아키텍처에서는 NFR인 보안·가용성 속성을 통일된 방식으로 표기해 아키텍처 리뷰 체크를 자동화할 수 있다.

MBD/MDA 파이프라인에서는 프로파일 태그를 코드 생성과 테스트 케이스 템플릿에 매핑해 지속적 생성 자동화에 활용한다. 모델에 적용된 프로파일은 코드·문서 생성물과 검증 결과를 연결하는 공통 메타데이터가 된다.

프로파일 설계와 검증을 잇는 운영

프로파일 설계는 도메인 요구사항, 확장 대상 UML 요소 목록, 표준 UML 모델, 도구 지원 범위를 입력으로 삼는다. 도메인 개념을 추출한 뒤 메타클래스에 매핑하고, 스테레오타입과 태그를 정의한다. 이어 OCL 제약을 작성하고 프로파일의 버전을 지정·서명한 뒤 리포지토리에 배포한다. 도구에 프로파일을 적재해 샘플 모델에 적용하고, 제약 검증과 리포트 발행을 거쳐 적용된 모델, 검증 결과, 코드·문서 생성물, 프로파일 아티팩트(XMI)를 남긴다.

검증 실패명명/타입규칙 과잉도구 불일치검증 성공도메인 요구 수집개념-메타클래스 매핑스테레오타입/태그 설계OCL 제약 정의프로파일 패키징/버전도구 통합/배포모델 적용/검증오류 유형태그 스키마 수정제약 완화/스코프 조정호환 옵션/업데이트코드 생성/분석/리뷰 게이트통과

Cameo/MagicDraw, Enterprise Architect, Papyrus 등은 프로파일 편집과 검증을 지원한다. 모델과 프로파일은 XMI로 교환할 수 있지만 도구별 확장 포맷 차이가 있을 수 있다. Export/Import와 Round-trip 교차검증, 차이 리포트 관리로 호환성을 확인한다. 도구가 지원하지 않는 표현은 최소표기 전략이나 스크립트 확장을 검토한다.

제약 위반이 발생하면 경고 또는 오류 리포트를 확인하고 모델을 수정한 뒤 다시 검증한다. 이 흐름을 OCL과 스크립팅 검증 파이프라인으로 CI에 연결하면 요구사항에서 모델 적용, 생성물, 검증 결과까지 추적할 수 있다.

규칙은 엄격하되 확장은 가볍게 유지한다

프로파일에는 MAJOR.MINOR.PATCH 같은 버전 규칙을 두고, 마이그레이션 스크립트와 가이드를 제공할 수 있다. 배포와 변경 이력은 중앙 레지스트리인 사내 아티팩트 저장소에서 관리한다.

설계에서는 최소한의 스테레오타입을 사용하고, 태그는 데이터 중심으로 설계하며, 검증 가능한 OCL을 우선한다. 특정 벤더의 확장보다 도구 독립적 표현을 우선하는 편이 이식성에 유리하다. 스테레오타입과 태그 수를 최소화하고 의미 충돌 방지 규칙을 두며, 하위 호환 지침과 마이그레이션 스크립트를 함께 준비한다.

제약을 엄격하게 만들수록 모델의 일관성은 높아지지만 모델링 속도는 저하될 수 있다. 태그 스키마를 세분화하면 표현력은 커지지만 유지보수 복잡도도 함께 증가한다. DSL이나 메타모델 수정은 표현력이 우수한 대신 표준 호환성 저하 위험이 있으며, 시각 표기는 다이어그램 가독성을 높이지만 태그 데이터를 과도하게 표시하면 모델이 복잡해질 수 있다.

요소 성능(모델 로드) 확장성 일관성 안정성 운영 편의
스테레오타입 매우 높음 높음 중간 높음 높음
태그 값 매우 높음 높음 중간 높음 높음
제약(OCL) 중간 높음 높음 중간 중간
프로파일 높음 매우 높음 높음 높음 매우 높음

성능 영향은 일반적 도구 기준의 보수적 추정이며, 대규모 모델에서는 OCL 검증 단계가 병목이 될 가능성이 있다.

OCL로 Service 연산의 가시성을 검사하기

Eclipse Modeling Tools 2023+, Papyrus 6.x, Eclipse OCL 6.x 환경에서 MyProfile 프로파일의 Service 스테레오타입이 UML Component에 적용됐다고 가정한다. 아래 제약은 «Service»가 적용된 Component의 모든 Operation이 public 가시성을 갖도록 강제한다.

-- Context: UML Component
context Component
inv ServiceOpsPublic:
  self.getAppliedStereotype('MyProfile::Service') <> null implies
  self.ownedOperation->forAll(o | o.visibility = VisibilityKind::public)

검증 보고서에서 위반 Operation을 식별하면 가시성을 수정하거나 스테레오타입을 해제한다. 규칙 예외가 필요하다면 스테레오타입에 allowNonPublic:Boolean 태그를 추가한 뒤 제약식을 조정한다.

검증과 공통 언어가 만드는 효과

보수적 예시로, 리뷰 결함인 표현·명세 불일치는 2035% 감소하고 설계 리뷰 시간은 1525% 단축될 수 있다. 모델 자동 검증 커버리지를 60% 이상 확보하면 빌드 파이프라인 재작업률은 1020% 감소한다. 사내 적용 및 공개 사례 기준으로 모델 재사용률은 2040% 개선, 리뷰 결함 건수는 1530% 감소, 문서·코드 생성 자동화율은 3060% 상승할 수 있다. 다만 도구와 프로세스 성숙도에 따라 편차가 존재한다.

도메인 공통 언어가 정립되고 설계 의도가 더 명확해진다. 도구와 조직 사이의 상호운용성이 높아지며, 온보딩 학습 곡선도 완화된다.

확장 범위를 통제하면서 자동화를 얻는 방식

UML 확장 메커니즘은 도메인 의미를 표준 범위 안에서 체계화하는 실무 프레임워크다. 스테레오타입, 태그, OCL, 프로파일을 설계·검증·배포 과정에 연결하면 표현력, 일관성, 자동화 수준을 함께 높일 수 있다. 가벼운 스키마와 검증 가능한 규칙, 버전 거버넌스를 기준으로 단계적으로 적용한다.

UML프로파일스테레오타입OCL모델링