MDA

MDA란 무엇인가

MDA(Model-Driven Architecture, 모델 주도 아키텍처)는 손으로 작성한 코드가 아니라 모델을 시스템의 1차 산출물로 삼고, 그 모델을 도구가 실행 가능한 코드로 변환하도록 설계한 개발 접근이다. 핵심 발상은 비즈니스 규칙과 설계 의도를 코드라는 구체적 형태에 묶어두지 않고, 플랫폼과 독립적인 모델로 먼저 확정하는 데 있다.

코드를 직접 다루면 기술 스택이 바뀔 때마다 같은 로직을 다시 구현해야 하지만, 모델을 중심에 두면 변환 규칙만 교체해 여러 플랫폼으로 산출물을 펼칠 수 있다. 따라서 MDA는 단순한 코드 생성 기법이 아니라, 설계 자산을 어디에 보존할 것인가에 대한 관점의 전환에 가깝다.

세 모델의 계층 구조

MDA는 추상 수준이 다른 세 모델을 단계적으로 잇는다. 계산 독립 모델(CIM)은 기술을 배제하고 업무 영역의 개념과 요구를 담고, 플랫폼 독립 모델(PIM)은 시스템의 구조와 행위를 특정 기술에 종속되지 않게 표현하며, 플랫폼 종속 모델(PSM)은 선택한 실행 환경에 맞춰 PIM을 구체화한다.

이 흐름의 가치는 상위 모델일수록 변경에 강하고 하위로 갈수록 자동 변환의 대상이 된다는 점에 있다. PIM에서 PSM으로의 변환이 도구로 처리되므로, 같은 PIM을 서로 다른 플랫폼으로 사상해 재사용할 수 있다.

모델 사이의 사상 규칙을 명확히 정의하는 일이 MDA 도입의 실질적 난이도를 결정한다.

OO 모델링과의 연결

MDA의 모델은 대개 객체지향 모델링 언어로 표현되며, 클래스·연관·상태·상호작용 같은 구조를 그대로 활용한다. OO 모델링이 도메인의 개념을 객체와 관계로 추상화하는 사고를 제공한다면, MDA는 그 추상을 실행 가능한 산출물로 자동 전개하는 장치를 더한다.

결국 잘 정제된 객체 모델이 있어야 의미 있는 코드 변환이 가능하므로, MDA의 품질은 모델링의 품질에 직접 의존한다. 모델이 모호하거나 일관성이 없으면 변환된 코드도 같은 결함을 그대로 물려받는다.

이 때문에 MDA를 도입하기 전 모델링 역량과 규약을 먼저 다지는 순서가 합리적이다.

CBD 방법론과의 관계

MDA는 컴포넌트 기반 개발(CBD) 방법론과 상호 보완적으로 결합한다. CBD가 재사용 가능한 컴포넌트 단위로 시스템을 조립하는 전략이라면, MDA는 그 컴포넌트의 명세와 인터페이스를 모델로 관리하고 구현 골격을 자동으로 생성하는 수단이 된다.

두 접근을 함께 쓰면 컴포넌트 경계를 모델 수준에서 합의하고, 반복되는 연결·변환 코드는 도구에 맡길 수 있다. 다만 자동 생성이 컴포넌트 설계의 책임을 대체하지는 않으며, 경계와 책임 분배는 여전히 설계자의 판단 영역으로 남는다.

모델과 컴포넌트가 같은 어휘를 공유하도록 정렬하는 일이 통합의 관건이다.

도입의 효과와 한계

MDA의 기대 효과는 생산성보다 일관성과 추적성에 있다. 설계 의도가 모델에 보존되므로 문서와 코드가 어긋나는 고질적 문제를 줄이고, 플랫폼 교체나 다중 배포 환경 대응에서 재구현 부담을 낮춘다.

반면 모든 영역을 모델로 완벽히 표현하기 어렵고, 변환 도구가 만든 코드를 사람이 다시 손대는 순간 모델과 코드의 동기화가 무너질 위험이 생긴다. 따라서 어디까지를 모델로 통제하고 어디서부터 수작업을 허용할지에 대한 경계 설정이 성패를 가른다.

도구에 대한 종속과 학습 비용도 사전에 가늠해야 할 현실적 변수다.

언제 MDA가 유효한가

MDA는 도메인 규칙이 안정적이고 동일한 로직을 여러 플랫폼에 반복 전개해야 하는 상황에서 가치가 가장 크다. 규칙이 자주 흔들리거나 요구가 탐색적으로 변하는 초기 단계에서는 모델 유지 비용이 이득을 넘어설 수 있다.

그러므로 전체 시스템을 일률적으로 모델 주도로 끌고 가기보다, 변경이 적고 정형화된 영역을 선별해 적용하는 편이 현실적이다. 모델의 권위를 유지할 수 있는 조직 규약과 변환 파이프라인이 갖춰질 때 비로소 MDA는 자산으로 굳는다.

그 토대 없이 도구만 도입하면 모델은 곧 방치되어 또 하나의 낡은 문서로 전락한다.