길리랩blog

MDD로 모델에서 코드까지 자동화하는 개발 체계

MDD의 CIM·PIM·PSM 모델 변환, 코드 생성, 추적성과 검증 체계를 실무 관점에서 정리한다.

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

엔터프라이즈 개발에서는 재사용성, 일관성, 납기 속도를 동시에 맞춰야 하는 경우가 많다. 코드 중심 개발은 복잡성 증가, 유지보수 부담, 플랫폼 의존성에 부딪힐 수 있다. Model Driven Development(MDD)는 OMG의 Model-Driven Architecture(MDA) 원칙을 실무 개발 흐름에 적용해, 비즈니스 모델에서 계산 독립 모델(CIM), 플랫폼 독립적 모델(PIM), 플랫폼 종속적 모델(PSM), 코드 아티팩트까지 이어지는 변환 과정을 자동화한다.

모델은 설계 설명을 위한 부속 문서가 아니라 설계·검증·변환·코드 생성을 이끄는 일급 산출물이 된다. PIM에서 PSM을 유도하고, M2T(Model-to-Text) 템플릿으로 실행 코드를 생성하는 방식이다.

비즈니스 모델에서 플랫폼별 구현으로 이어지는 구조

CIM은 시스템 환경과 요구사항을 비즈니스 관점에서 설명하는 도메인 모델이다. 컴퓨팅 구현의 세부사항은 포함하지 않으며, 비즈니스 전문가와 개발자가 요구를 공유하는 매개체가 된다. 비즈니스 모델은 이러한 CIM 관점에서 도메인 개념, 정책, 프로세스를 기술 중립적으로 표현한다.

그 위에서 PIM은 아키텍처 패턴과 서비스 경계를 담되 특정 플랫폼의 제약은 배제한다. 비즈니스 로직과 데이터 구조를 중심으로 시스템이 수행해야 할 일을 표현하며, UML로 모델링할 수 있다. PSM은 프레임워크, 미들웨어, 배포 대상에 맞게 모델을 구체화한 결과다. Java, .NET, Python 등의 특정 플랫폼에 맞는 기술과 컴포넌트, 실제 구현 환경의 제약사항을 상세 설계에 반영한다.

이 계층을 분리하면 플랫폼이 바뀌더라도 PIM을 안정적으로 유지하면서 PSM을 추가하거나 교체할 수 있다. 변환은 한 방향으로만 흐르지 않는다.

  • PIM→PIM 변환은 리팩터링, 정규화, 아키텍처 규칙 적용에 사용한다.
  • PIM→PSM 변환은 타깃 플랫폼 매핑과 보일러플레이트 자동화를 맡는다.
  • PSM→PSM 변환은 같은 플랫폼 안에서의 최적화나 버전 업 대응에 쓰인다.
  • PSM→PIM 변환은 역공학과 동기화를 통해 모델과 코드의 일치를 유지하는 라운드트립에 해당한다.

메타모델은 MOF/Ecore로 정의하고, UML/OCL로 제약을 검증할 수 있다. 모델 변환에는 QVT/ATL, 코드 생성에는 Acceleo/XTend 등을 사용한다.

변환 규칙과 추적성을 운영 자산으로 다루기

MDD의 핵심은 단순히 코드를 생성하는 데 있지 않다. PIM과 PSM 사이의 매핑 규칙, 변환 파이프라인, 요구사항부터 모델 요소와 코드 라인까지 이어지는 추적 링크가 함께 필요하다. 이 연결이 있어야 변경 영향 분석과 감사 대응이 가능해진다.

코드 생성 템플릿에는 반복 코드와 상용구를 자동화하는 역할뿐 아니라 표준과 보안 규약을 담을 수 있다. 부분 클래스와 보호 영역(Protected Region)을 두면 생성 코드와 수동 커스터마이징도 공존할 수 있다.

OCL이나 DSL 규칙은 정적 검증에 사용하고, 시뮬레이션과 프로파일링은 행위 검증에 활용한다. 라운드트립과 정합성 검사는 모델-코드 드리프트를 억제하는 장치다. EMF, Papyrus, Cameo, EA, JetBrains MPS, Enterprise Architect, IBM Rational Software Architect, Visual Paradigm, StarUML, AndroMDA 같은 툴체인을 사용할 수 있으며, 협업에서는 Git 기반 텍스트 DSL과 모델 리포지토리, 브랜치 전략, 모델 머지·리뷰 워크플로우를 함께 운영한다.

검증부터 배포까지 연결하는 파이프라인

입력은 요구사항, 도메인 용어집, 비즈니스 규칙이다. 이를 비즈니스 모델링, PIM 설계, OCL 검증, QVT/ATL 기반 PIM→PSM 변환, Acceleo 코드 생성, 빌드·테스트 순으로 처리한다. 결과물은 플랫폼별 코드뿐 아니라 YAML/Helm 구성, API 스펙, 추적성 리포트까지 포함할 수 있다.

검증이 실패하면 변환을 중단하고 오류 위치와 규칙 ID를 반환한 뒤 모델 수정 후 다시 실행한다. 충돌이나 머지에 실패한 경우에는 요소 단위 락 또는 세분화된 텍스트 기반 DSL로 컨플릭트를 해소한다. 라운드트립에서는 코드 변경을 감지해 PSM에 반영하고, 필요하면 PIM까지 역전파한다. 규칙을 따르지 않는 변경은 차단한다.

모델 리포지토리는 트랜잭션 단위로 커밋하고 전후 정합성을 검사한다. 변환·생성·빌드는 CI에서 원자적으로 실행하며, 실패 시 전체를 롤백한다.

⤢✕PIM→PIMPIM→PSMPIM→PSMPSM→PSMPSM→PIMfeedbackValidation & TraceabilityOCL rulesTrace linksRequirementsBusiness ModelPIMPIM refinedPSM (Java/JPA)PSM (.NET/EF)PSM optimizedPIM synchronizedCode GenerationCode GenerationJava code + configC# code + config

도메인 모델이 여러 플랫폼 산출물로 확장되는 경우

금융 코어뱅킹과 대출 심사에서는 PIM에 상품, 한도, 심사 룰을 모델링한 뒤 JPA/JMS/REST PSM으로 매핑하고 코드와 스키마를 함께 생성할 수 있다. 규제 변경은 룰 모델 수정, 변환, 배포로 연결돼 리드타임 단축에 활용된다. 금융 시스템에서는 복잡한 비즈니스 규칙을 모델로 정확하게 표현하고, 규제 요구사항이 바뀌면 모델 수정으로 대응할 수 있다. 증권사 A는 MDD 도입으로 개발 기간을 30% 단축하고 유지보수 비용을 25% 절감했다.

통신 BSS/OSS에서는 카탈로그 주도 서비스 모델을 여러 REST/SOAP 게이트웨이 PSM으로 자동화하고, 요금과 프로비저닝 정책을 모델로 일관되게 관리한다. 다양한 네트워크 프로토콜과 장비를 모델링하고, 서비스 구성이 바뀔 때 모델 수준에서 변경해 일관성을 유지할 수 있다. 통신사 B는 MDD를 통해 신규 서비스 출시 기간을 50% 단축했다.

임베디드·자동차 분야에서는 상태기계와 시퀀스 모델에서 C/C++ 코드를 생성하며 MISRA 규칙을 템플릿에 담을 수 있다. 테스트 케이스 모델로 HIL 테스트를 자동 생성하는 방식도 가능하다. 하드웨어 제약사항을 모델에 반영하고 다양한 하드웨어 환경에 같은 소프트웨어를 구현하는 데 활용할 수 있으며, 자동차 제조사 C는 MDD로 차량 제어 소프트웨어의 검증 오류를 40% 감소시켰다.

클라우드 네이티브 환경에서는 서비스·이벤트 모델에서 K8s 리소스(YAML)와 API 스펙(OpenAPI)을 동시에 만들고, 서버리스와 컨테이너 같은 여러 타깃의 PSM을 병렬로 생성할 수 있다. 마이크로서비스 아키텍처를 위한 모델링 확장, 클라우드 리소스 및 배포 자동화와의 통합, DevOps 파이프라인 연계도 발전 방향으로 제시된다. AI는 모델링 자동화, 요구사항에서 모델 자동 추출, 모델 검증과 최적화에 활용될 수 있다. 특정 업종과 도메인에 맞춘 도메인 특화 모델링 언어(DSML)는 비개발자의 모델링 참여를 넓히고 비즈니스와 IT의 협업을 강화하는 방향으로 확산될 수 있다.

레거시 현대화에서는 역공학으로 PSM을 추출하고 PIM을 정제한 뒤 .NET→Java와 같은 신규 플랫폼으로 재생성한다.

자동화가 가져오는 범위와 한계

조직 성숙도를 중간 수준으로 가정하면, 보일러플레이트는 6090% 자동화되고 기능 산출 속도는 3050% 개선될 수 있다. 결함 밀도는 3050% 감소하고 아키텍처 규칙 위반은 70% 이상 사전에 차단할 수 있다. 요구사항에서 배포까지의 사이클은 2540%, 온보딩 기간은 20~30% 단축되는 효과를 기대한다. 변경 용이성과 일관성이 높아지고, 지식 표준화와 감사 대응도 수월해진다. 플랫폼 전환과 스케일 전략의 유연성도 커진다.

항목 전통적 코드 중심 방식 MDD 방식
성능 개발자 구현 품질에 따라 편차 큼 런타임 성능은 플랫폼 영향이 큼, 템플릿 최적화로 편차 축소
확장성 신규 플랫폼 대응 시 대규모 재개발 PIM 재사용으로 PSM 추가·교체 용이
일관성 규약 준수 편차, 리뷰 의존 모델 규칙·템플릿로 조직 수준 일관성 내재화
안정성 인적 오류 위험, 테스트 보완 필요 검증 규칙·자동 생성으로 결함 유입 저감
운영 편의 산출물 산재, 추적 어려움 요구→모델→코드 추적성으로 영향 분석·감사 용이

초기에는 도구와 언어 숙련이 필요해 단기 생산성이 하락할 수 있다. 모델링 도구 구매와 환경 구축에는 비용이 들며, 개발자 교육과 적응 기간도 필요하다. 모델을 잘 만들기 위해서는 추상화 능력과 모델링 기술이 필요하고, UML 같은 모델링 언어에 대한 전문성이 요구된다. 모델의 품질은 결과물의 품질과 직접 연결된다.

특정 벤더와 도구에 의존할 위험도 있으므로 개방형 표준과 내부 스캐폴딩 프레임워크로 완화할 필요가 있다. 자동 변환만으로 100% 완전한 코드를 생성하기는 현실적으로 어렵고, 일부 코드는 수동으로 구현해야 하며 생성된 코드의 품질과 성능 역시 검증해야 한다. 코드 수준 변경을 무분별하게 허용하면 모델 드리프트가 생기므로, 라운드트립 대상과 변경 경계를 명확히 정해야 한다.

메타모델 우선 설계에서는 도메인 언어(DSL)와 제약(OCL)을 먼저 고정하고 변환 규칙을 점진적으로 강화한다. 템플릿에는 보호 영역, 부분 클래스, 규약 검사를 포함하고 성능·보안 베스트프랙티스를 내재화한다. 모델 버전관리는 텍스트 기반 DSL을 선택하고, CI에서 변환·생성·테스트 파이프라인을 원자화하는 방식으로 운영한다.

ATL과 Acceleo로 연결한 변환 예시

Eclipse Modeling Tools 2024‑xx, EMF 2.x, ATL 4.x, Acceleo 3.x를 전제로 한다. PIM에는 서비스와 엔티티, PSM에는 JPA 엔티티 메타모델이 정의된 상태다.

PIM 엔티티를 JPA 엔티티로 옮기는 ATL 변환은 다음과 같다.

module PIM2JPA;
create OUT : JPA from IN : PIM;

rule Entity2JPA {
  from  s : PIM!Entity
  to    t : JPA!Entity (
           name <- s.name,
           tableName <- s.name.toUpper(),
           fields <- s.attributes
         )
}

rule Attribute2Field {
  from  a : PIM!Attribute
  to    f : JPA!Field (
           name <- a.name,
           type <- thisModule.mapType(a.type),
           nullable <- not a.isRequired
         )
}

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

변환된 JPA 엔티티는 Acceleo 템플릿으로 코드 파일을 생성한다.

[template public generate(e : JPA!Entity)]
package com.example.model;

import javax.persistence.*;

@Entity
@Table(name="[e.tableName/]")
public class [e.name/] {
[for (f : JPA!Field | e.fields)]
  private [f.type/] [f.name/];
[/for]
}
[/template]

이 예시의 빌드 파이프라인은 모델 검증(OCL) → ATL 변환 → Acceleo 코드 생성 → 컴파일/테스트 → 아티팩트 배포 순으로 구성된다.

모델 기반 개발소프트웨어 아키텍처코드 생성MDA모델 변환