MDA로 PIM을 플랫폼별 구현 모델과 코드로 연결하는 방법

엔터프라이즈 시스템이 복잡해질수록 요구, 설계, 구현 산출물이 서로 어긋나는 문제가 커진다. Model Driven Architecture(MDA)는 구현 환경과 분리된 모델을 먼저 만들고, 이를 대상 플랫폼용 모델과 코드로 변환해 이 간극을 줄이는 접근이다. MOF, UML, CWM, XMI로 이어지는 OMG 표준군을 기반으로 재사용성과 상호운영성을 확보한다.

모델이 구현을 이끄는 MDA의 구조

MDA는 메타모델 기반 모델링과 자동 변환으로 PIM에서 PSM을 거쳐 코드까지 생성하는 소프트웨어 개발 아키텍처다. 중심에는 다음 요소가 있다.

PIM(Platform-Independent Model): 도메인 로직과 제약을 구현 환경에서 분리해 표현한 모델
PSM(Platform-Specific Model): Spring, .NET, Kubernetes, RDBMS 등 대상 플랫폼에 맞춰 구체화한 모델
모델 변환 규칙: QVT 또는 ATL로 정의하는 PIM과 PSM 사이의 매핑 규칙
메타모델: MOF를 토대로 정의하는 모델의 구조와 의미
교환 포맷: XMI 기반의 모델·메타모델 교환 형식

목표는 구현 자동화만이 아니다. 모델 재사용, 플랫폼 이식, 도구 간 상호운영성을 함께 다룬다.

PIM과 PSM 사이를 연결하는 표준 구성

PIM은 비즈니스 규칙과 도메인 제약을 구현 기술과 분리한다. 이후 PSM은 선택한 플랫폼의 구조와 관례를 반영한 매핑 산출물이 된다. QVT(OMG 표준)나 ATL 같은 모델 변환 언어는 이 변환 규칙을 명시하고, 자동 생성 파이프라인이 같은 기준을 반복 적용하도록 만든다.

MOF(Meta Object Facility)는 UML이나 CWM, 도메인별 DSL 같은 메타모델을 정의하는 메타-메타모델 표준이다. 모델의 정형 정의를 제공하므로 도구 간 호환성과 모델 검증의 엄밀성을 확보하는 기반이 된다.

UML은 구조와 행위를 표현하는 사실상 표준 언어이며 PIM 정의에 주로 사용된다. 클래스, 컴포넌트, 시퀀스, 상태도 등으로 요구사항과 설계를 정형화해 추적성을 높인다.

CWM(Common Warehouse Metamodel)은 데이터웨어하우스와 BI를 위한 메타모델 표준이다. 데이터 소스, 변환, OLAP 구조를 모델로 표현해 ETL과 DDL 자동화의 기반을 제공한다.

XMI(XML Metadata Interchange)는 모델과 메타모델을 교환하는 표준 포맷이다. 리포지토리와 도구 사이의 상호운영성을 높이고 형상관리, CI 파이프라인과의 연계를 용이하게 한다.

검증부터 생성 코드 테스트까지의 흐름

⤢✕

입력에는 UML 또는 CWM 기반의 PIM, MOF 메타모델, OCL 제약식, QVT·ATL 변환 규칙, 프로파일과 스테레오타입 정의가 포함된다. 처리 단계에서는 OCL·EMF 검증, QVT·ATL 변환 실행, Acceleo·Velocity 코드 생성, 단위·계약·스키마 검증을 수행한다. 결과물은 Java·.NET·DDL 등의 PSM 아티팩트, 생성 코드와 스켈레톤, XMI 기반 문서와 스키마다.

검증 실패를 생성 이후까지 넘기지 않는 것이 중요하다. 메타모델과 모델이 맞지 않아 OCL 검증에 실패하면 변환을 중지하고 모델을 수정한 뒤 다시 실행한다. 매핑 누락이나 규칙 충돌은 트레이스 로그를 바탕으로 변환 규칙을 갱신하고 회귀 테스트로 확인한다. 생성 산출물의 스키마, 컴파일, 테스트가 실패하면 생성기 템플릿 또는 PSM 매핑을 재검토한다.

모델 리포지토리에 CDO나 EMFStore를 사용할 때는 브랜치 전략과 변경 세트 단위 트랜잭션 커밋이 필요하다. 병행 편집 환경에서는 요소 단위 락 또는 변경 충돌 병합 정책을 정해야 한다. CI에서는 검증, 변환, 생성을 원자 단계로 구성해 일관성을 유지한다.

여러 플랫폼과 데이터 모델에 적용하는 방식

PIM에서 서비스 인터페이스와 도메인 모델을 정의한 뒤 Spring·.NET PSM, REST·GraphQL 스펙을 생성하는 방식으로 멀티 플랫폼 비즈니스 서비스를 만들 수 있다.

데이터웨어하우스에서는 CWM 기반 소스-타깃 매핑과 변환 정의로 DDL·ETL 파이프라인 템플릿을 생성하고 변경을 추적한다. 레거시 현대화에서는 Cobol·DB2 도메인 모델을 PIM으로 추출한 뒤 마이크로서비스·클라우드 네이티브 PSM으로 단계적으로 옮길 수 있다.

보안과 개인정보 제약을 OCL로 명세하면 PSM에서 접근제어·마스킹 정책 코드 스텁을 자동 삽입할 수 있다. 제품 라인 엔지니어링에서는 변이점 모델링(Feature Model)과 프로파일을 활용해 SKU별 아티팩트 생성을 자동화한다.

자동 생성이 만드는 효과와 운영 부담

전형적 도입 사례에서는 신규 기능 리드타임을 30~~50% 단축하고 반복 작업 자동화율 60%+를 달성할 수 있다. 사양과 구현의 추적성이 강화되면 요구 누락 결함이 20~~40% 감소하며, 스키마와 인터페이스의 일관성도 높아진다. 플랫폼을 바꿀 때 PIM을 재사용하면 전환 비용을 30%+ 절감할 수 있고, XMI를 통한 도구 연계도 쉬워진다. 문서, 스키마, 코드의 동기화 자동화는 유지보수 안정성에도 영향을 준다.

다만 학습 곡선과 초기 구축 비용이 있으며, 조직 차원의 모델링 성숙도가 필요하다. 도구와 표준 버전에 대한 의존성, 벤더 락인 가능성도 검토 대상이다. 최신 도구 지원 범위는 최신 정보를 확인해야 한다. 생성 코드의 성능이나 가독성이 문제가 될 수 있으므로 핵심 경로는 핸드 튜닝하거나 커스텀 템플릿을 적용할 필요가 있다.

도메인 중심 메타모델을 먼저 설계하고 UML 프로파일·스테레오타입으로 구현 관심사를 분리하는 방식이 적합하다. OCL 정적 검증, 변환 규칙 단위 테스트, 생성물 계약 테스트를 함께 두고, 템플릿과 규칙은 버전 관리 및 CI에 통합한다. 생성 코드와 수작업 코드의 경계도 Partial Class나 Protected Region으로 명확히 관리해야 한다.

ATL로 UML PIM을 Java PSM으로 매핑하기

전제조건: Eclipse Modeling Framework(EMF 2.x), UML2 5.x, ATL 4.x, Java 개발 환경

-- module: PIM (UML) to Java PSM (간단 매핑)
module PIM2Java;
create OUT : JAVA from IN : UML;

rule Class2JavaClass {
  from
    c : UML!Class (not c.isAbstract)
  to
    jc : JAVA!Class (
      name <- c.name,
      visibility <- 'public',
      attributes <- c.ownedAttribute->collect(a | thisModule.mapAttribute(a))
    )
}

lazy rule mapAttribute {
  from a : UML!Property
  to   f : JAVA!Field (
    name <- a.name,
    type <- thisModule.mapType(a.type)
  )
}

helper def: mapType(t : UML!Type) : String =
  if t.name = 'String' then 'java.lang.String' else t.name endif;

이 변환은 XMI 형식 UML 모델과 ATL 변환 모듈을 입력으로 받는다. ATL 런타임이 Java 메타모델 인스턴스를 만들고, Acceleo가 이를 바탕으로 소스 코드 템플릿을 생성한다. 결과는 Java PSM 모델과 생성된 코드 스켈레톤이다.

수작업 구현과 모델 기반 생성의 차이

항목	전통적 수작업 접근	MDA 기반 생성 접근
생산성	반복 작업 과다, 인력 의존 높음	템플릿/규칙 재사용으로 고효율
일관성	산출물 간 불일치 빈번	모델 단일 진실 원천(Single Source of Truth) 유지
확장성	플랫폼 전환 비용 큼	PIM 재사용으로 확장 용이
안정성	변경 누락/회귀 위험 존재	자동 검증·생성 파이프라인으로 리스크 저감
운영 편의	문서-코드 동기화 부담	XMI/생성 자동화로 동기화 간소화

MDA는 요구, 설계, 구현을 하나의 변환 체계로 연결한다. 초기 투자와 조직적 학습이 필요하지만, 도메인 중심 모델링과 검증 자동화를 병행하면 멀티플랫폼 대응력과 유지보수 효율을 높일 수 있다. 템플릿 관리, 규칙 테스트, 생성 코드와 수작업 코드의 경계를 함께 설계하는 일이 도입의 핵심이다.