최근 주목받고 있는 MDD 기술에 대한 이해를 돕기 위해 소프트웨어정책연구소의 MDD 관련 연구 내용을 2회에 걸쳐 독자 여러분께 소개드립니다. 많은 도움 되시길 바랍니다.

MDD(Model Driven Development, 모델 주도 개발) 의의

① MDD의 개념과 특징

MDD는 모델 개발에 중점을 둔 개발방법론으로 모델을 이용하여 목표 시스템을 단순화함으로써, 사용자는 시스템을 쉽게 이해할 수 있고 개발자는 개발을 용이하게 하는 것이 목적인 개발방법론입니다.

모델은 목표 개발물의 특징을 추출하여 단순화하는 표현 방식으로, 업무, 프로세스, 도메인(금융, 제조, 정부, 의료 등), 정보 & 데이터, 시스템(하드웨어, 플랫폼)의 정보를 가진 생성물로 구분하여 정의합니다. 업무, 프로세스, 도메인 모델은 컴퓨터 하드웨어 및 소프트웨어 아키텍처 기술을 숨겨서 소프트웨어 개발 시 업무 프로세스 개발에 집중하게 하는데요.

모델은 표현 범위 및 내용에 따라 상위•하위 모델로 구분하며, 하위 모델로 갈수록 구체적입니다. 상위 모델은 모델 변환 기술(예: 모델 → 소스코드)에 의해 하위 모델 또는 프로그램 코드로 변경되며, 하위모델이나 프로그램 코드로 변경될수록 IT 기술과 연관된 내용이 포함됩니다.

모델은 목표 시스템에 대하여 사용자와 IT기술자가 소통할 수 있는 언어로 표현되는데요. 일반적인 모델링 언어로는 UML(Unified modeling Language)1, SQL, BPMN, E/R 다이어그램 등이 있습니다. 도메인 특화 언어인 DSL(Domain Specific Language)을 이용하여 모델을 구현하기도 합니다.

MDD는 이러한 모델을 중심으로 분석, 설계를 수행하고 이에 대한 결과물로써 소스코드 및 산출물을 자동 생성하는 소프트웨어 개발방법론입니다. 기존 코드 중심 개발 방식과 달리 사용자의 요구사항을 모델로 생성하는 과정이 중심이 되는 것이죠.

MDD에서 소프트웨어 개발 방법은 개발플랫폼에 종속되지 않은 모델(메타모델)을 정의하고, 소프트웨어 아키텍처를 세분화하는 것인데요. MDD는 추상적인 형태의 모델과 모델간 변환 기술로 구성되어 있으며, 이러한 추상성은 시스템을 간단히 하고 정규화(표준화)하여 소스코드 생성, 문서제작, 테스팅 자동화가 가능하게 합니다.

MDD는 단순화된 모델을 통해 IT기술과 업무를 분리하고, 소프트웨어 개발 시 모델을 활용하여 도메인전문가와 IT 기술자간의 커뮤니케이션이 용이하게 하는데요. 업무와 IT 기술이 변경되더라도 전체 소프트웨어 변경이 아닌 필요한 모델만 변경하여 소프트웨어 개발이 가능하다는 장점이 있습니다.

② MDD의 적용 요건

MDD의 성공적인 도입을 위해서는 모델간의 변환, 모델과 소스 간의 변환을 구현하는 MDD 도구가 지원되어야 합니다. MDD에 대한 연구는 2000년 초부터 시작하여 학술적으로는 많은 성과가 있었지만, 산업계에서 MDD 도입 성과를 확인하기 어려운 이유는 MDD 도구에서 기인하는데요. MDD의 이론을 적용하여 자유로운 모델과 변환 툴을 만드는 것은 쉬운 일이 아니기 때문입니다.

MDD도구가 하위 모델과 밀접하게 연관되면 모델의 범위가 좁아지나, 자동 코드 생산율이 높아지며, 반대의 경우는 모델의 범위는 넓어지나 자동 코드 생산율이 낮아지는데요. MDD 도구는 도메인 범위, 코드 자동생산 정도, 개발프레임의 종속성 정도에 따라 다양합니다.

MDD의 개발 참여자는 기존프로젝트와 다른 역할이 부여됩니다. 기존 프로젝트와 다르게 MDD에서 새로운 역할을 하는 담당자는 도메인 전문가, MDD 도구 개발자, 프레임워크 담당자 등이 있는데요. 대형 SI 프로젝트의 경우, 관리조직은 그대로 유지하되, 모델 생성을 위한 모델러가 필요하고, 개발자의 비중보다 설계자의 비중이 커지게 됩니다.

프로젝트 수행단계를 분석, 설계, 개발, 테스트, 이행이라고 나눌 때, MDD에서는 설계와 분석 단계의 구분이 어려우며, 설계와 동시에 개발, 테스트가 진행되는 것이죠. MDD에서 코드 자동생성을 구현하기 위해 MDD 도구 개발자의 역할이 중요하며, MDD 도구 개발자는 프레임워크 담당자와 MDD도구를 수정하는 역할을 담당하게 됩니다.

③ MDD 출현의 배경

2015년에는 전 세계적으로 50,000여개의 프로젝트가 수행되었으며, 예정된 시간 안에, 예정된 금액으로 성공적으로 완료된 프로젝트는 29% 수준에 그쳤는데요. 그로 인해 명확한 요구사항의 정의 및 사용자 요구사항 변화에 따른 변화관리가 프로젝트 성공에 중요한 요소임이 확인되었습니다.

소프트웨어 개발과 업무간의 연계성이 더욱 강화되면서, 업무 변경 시 소프트웨어에 즉시 반영할 수 있는 개발방법론이 요구되었는데요. 소프트웨어 시스템의 규모와 복잡성이 증가하였음에도 기업은 업무에 적합한 소프트웨어를 적정한 가격에 구축하도록 요구했습니다. 그리고, 특정 기술자, 특정 개발 환경에 종속되지 않은 개발환경 구축이 필요하게 되었습니다.

또한 기존 소프트웨어 전체를 변경하지 않고도 새로운 기술을 적용할 수 있는 소프트웨어 개발방법론이 요구되었는데요. 신기술을 이용한 소프트웨어 개발이 가속화되면서 개발자들이 학습해야 할 기술의 양이 많아져 새로운 기술 적용 시 소프트웨어 변경을 최소화하는 방안이 필요했습니다.

프로세서, 스토리지, 소프트웨어 등을 인터넷을 통하여 제공하는 클라우드 컴퓨팅은 여러 다른 하드웨어 환경, 플랫폼에서 제공되는데요. 업무에 모바일을 적용하는 경우가 많아져 기업들은 모바일 기술을 가진 개발자를 구해야 하는 부담이 증가하고 있습니다.

개발방법론의 MDD의 유용성 검토

① MDD 이론적, 기술적 유용성

MDD에 의해 생성된 도메인 모델에는 업무 도메인에 대한 기술이 축적되어 있으며, MDD 개발과정에서 모델에 대한 최적화가 이루어지는데요. 기존 개발 방법론에 의해 구축된 소프트웨어에도 도메인 기술이 축적되어 있으나, 소프트웨어와 도메인 기술 분리가 쉽지 않습니다. 기존엔 설계 산출물은 개발된 소프트웨어와 일치되는 경우가 적어 실질적으로 개발 후 활용이 어렵고 도메인 기술 축적 자료로 사용되기 어렵기 때문인데요.

MDD에 의해 개발된 도메인 모델은 도메인 전문가가 이해하기 용이하고, 자동 생성된 문서가 제공되는 소프트웨어는 사용자가 이해하기 용이합니다. 도메인 전문가가 실질적으로 알 필요가 없는 데이터베이스 모델, 하드웨어 모델과 같은 IT 관련 기술이 분리되기 때문입니다.

MDD에 의해 생성된 모델은 MDD 도구에 의해 소스코드로 자동 변환되므로 모델과 소스코드가 일치됩니다. 모델에서 일부 소프트웨어 코드가 자동 생성되어 프로젝트 생산성을 높이는 것인데요. MDD에서는 분석, 설계, 개발의 단계에서 산출물이 자동으로 생산되어 각각의 단계의 산출물이 가시화되어 프로젝트 참여자들의 커뮤니케이션을 돕고 프로젝트 진행 상태를 관리할 수 있습니다.

MDD에 의해 생성된 소프트웨어는 자동 문서화로 개발자 변경에 영향을 적게 받으며, 유지보수가 용이하다는 장점이 있습니다. 소프트웨어 라이프사이클에서 유지보수가 큰 비중을 차지하므로, 유지보수 비용을 줄이는 것이 IT 비용 절감에 큰 영향 준 것인데요.

MDD의 업무 모델은 IT 기술과 분리되어 있고, 하위 시스템 관련 모델은 업무 모델과 분리되어 있어 IT 기술자들이 이해하기 용이합니다. 따라서 개발자 변경 시 개발된 소프트웨어의 인수인계가 용이하고, 신규 개발자도 소프트웨어를 쉽게 이해할 수 있습니다.

② 제약요인

MDD 도구가 급변하는 경영환경에 맞추어 소프트웨어를 개발할 수 있도록 지원이 가능한지, 비용은 얼마나 절감되는지 여부를 쉽게 검증할 수 있는 방법이 충분치 않아 경영층이 MDD 적용 여부를 결정하는데 어려움으로 작용하고 있습니다.

특히 MDD 도입을 위해서는 MDD도구의 사용이 필수적이나 개발하려는 소프트웨어에 맞는 MDD 도구를 찾기 어렵고, 도구 개발에 들어가는 비용대비 효과 측면의 분석도 미비합니다.

MDD의 소스 코드 자동생성에 의한 생산성 향상 효과 측정 시 MDD 도구 개발에 대한 오버헤드를 고려해야 하고, 프로젝트 생산성 향상 정도를 MDD 도구의 도입 및 학습 비용을 비교해서 감안해야 합니다.

소프트웨어 전문가들도 MDD 사례 등에 대한 정보 공유가 부족하고, MDD 기술 문헌이나 연구가 많지 않아, 필요성이나 구체적 작동원리에 대해 충분히 이해하지 못하고 있는 실정인데요. 일부 적용 중인 사례에 대한 소개 및 연구가 필요하며 이를 통해 소프트웨어 개발 전문가들의 관심이 확대될 필요가 있습니다.

MDD 도입 시 소프트웨어 설계자, 개발자, 사용자간 역할이 변화하여야 하나 단기간에 이들의 역할변화를 효율적으로 이끌어 내기는 쉽지 않습니다. MDD로 개발방법론을 변경하면 설계자, 개발자, 사용자 등 역할이 부분적으로 변경되며, 새로운 역할을 가진 담당자가 필요한데요. 새로운 역할에 대한 당위성 증명이 필요하고, 변경된 역할에 대한 공감대 형성과 교육이 필요합니다.

다음 시간에는 MDD의 사례를 살펴보고, 향후 전망과 과제에 대해 알아보겠습니다.

글 ㅣ 진회승 선임연구원, 김태호 선임연구원 ㅣ소프트웨어 정책연구소

● 관련 글 보기

MDD(모델 주도 개발) 유용성 논의와 사례 분석 1편
http://blog.lgcns.com/1079

MDD(모델 주도 개발) 유용성 논의와 사례 분석 2편
http://blog.lgcns.com/1081

• UML은 객체관련 표준화 기구인 OMG에서 1997년 11월 객체모델링 기술을 이용하여 만든 모델링 언어. 객체 지향적 분석, 설계 방법론의 표준지정을 목표로, 요구분석, 시스템 설계, 시스템 구현의 과정에서 생길 수 있는 개발자간의 의사소통을 불일치를 해소하고자 개발. 유스케이스 다이어그램, 클래스 다이어그램 등 8개의 다이어그램을 기반으로 분석, 설계 장치를 제공 [본문으로]