[지디넷코리아]우리가 현재 살고 있는 산업사회에 있어서 가장 중요한 것은 무엇인가? 혹자는 믿음이라고 답할 것이고, 혹자는 밥이라고 답할 것이며, 어떤 사람은 그저 애니메이션이나 실컷 보면서 살 수 있으면 그만이라고 말할 것이다. 무엇이 되었든 개인에게 있어서 틀린 답은 아니겠으나 산업사회의 발전을 위해서 가장 중요한 사회학적인 요인을 하나만 선택하라고 하면 그것은 곧 ‘생산성(productivity)’이 될 것이다. 소위 우리가 말하는 ‘산업혁명’이라는 것도 기실은 생산성의 폭발적인 증대로 귀결될 수 있다.

소프트웨어를 개발하는 입장에서도 이 생산성의 문제는 무척이나 중요하다. 같은 수준의 완성품을 만드는 데 있어서 가능하면 적은 시간과 적은 노동력과 원자재만을 이용하는 방법을 연구하는 것은 그런 측면에서 커다란 의미를 가지는 것이다. 이번 호 특집에서 언급하는 MDA(Model Driven Architecture) 역시 소프트웨어의 생산성과 관련해서 중요한 의미를 가진다.

소프트웨어의 생산성은 어떻게 높아지는가
그렇다면 과연 어떻게 하면 소프트웨어의 생산성을 높일 수 있는가? 이 문제는 비단 최근에 제기되는 문제가 아니다. 물론 과거에 비해 복잡한 시스템 요구사항과 수많은 기술들이 등장하고 있는 근래에 그 중요성이 높아지고는 있으나 이미 소프트웨어 초창기부터 이 문제는 많은 사람들의 고민거리였다고 말할 수 있다. 이 문제를 해결하기 위해서 등장한 대표적인 학문이 바로 소프트웨어 공학이다.

소프트웨어 공학의 영역은 상당히 포괄적이다. 소프트웨어 개발에 투여되는 수많은 자원들의 효과적인 관리 방법과 평가, 그리고 조직과 의사결정 구조, 심지어는 개발자들의 심리상태에 대한 것도 대상이 될 수 있다. 소프트웨어 공학에 대해서 자세한 이야기를 하자면 소프트웨어의 위기에서부터 많은 방법론에 대한 것까지 커다란 연구 분야라고 할 수 있으며, 그 중요성은 최근의 복잡해진 환경에 의해 점점 더 높아가고 있다. 거창하게 소프트웨어 공학을 이야기했지만 소프트웨어 생산성을 높이기 위해 그 동안 시도됐던 몇 가지 방법에 대해서 간단히 이해하는 것이 MDA에 대한 이야기를 풀어나가는 데 도움이 될 것이다.

전통적인 방법론 vs. 창조적 프로그래밍
소프트웨어의 생산성을 높이기 위한 방법으로 그 동안 다양한 방법론과 이론이 등장했다. 이들에 대한 자세한 논의는 한 권의 책으로도 부족할 것이므로 여기서는 대표적인 몇 가지의 특징에 대해서 간단히 알아보기로 하자. 소프트웨어 공학의 정의로 본다면 모든 방법론들이 소프트웨어 공학으로 설명할 수 있겠으나 최근에 각광받는 몇 가지 방법론이 기존의 방법론과는 상당한 철학적인 차이를 보여주고 있기 때문에 여기서는 이들을 포괄적으로 ‘창조적 프로그래밍’으로 표현하고자 한다.

필자의 경우 소프트웨어 공학을 전문적으로 전공한 것은 아니므로 다소의 용어 선택과 학문적인 설명에 있어서는 오류가 있을 수 있으나 MDA를 설명하기 이전에 그 동안의 경험했던 것들을 바탕으로 접근하는 것이 도움이 될 것이라 생각하기 때문에 이 부분을 언급하도록 하겠다. 혹시라도 필자의 글에 대해 다른 의견이 있는 독자는 언제든지 필자에게 메일을 보낸다면 검토 후 다음 기회에 정정하도록 할 것이다.

전통적인 소프트웨어 공학 방법론은 소프트웨어의 개발 단계를 요구, 분석, 설계, 구현, 테스트와 유지보수로 분류하고 각 단계별로 소프트웨어의 생산성에 영향을 주는 여러 요소들을 관리하고 조정해 생산성을 높이는 방법과 절차, 그리고 이를 지원하는 여러 가지 도구 등으로 구성된다. 소프트웨어 개발에 관한 접근 방식에 따라 기능 중심의 개발방법론, 구조적 개발방법론, 객체지향 개발방법론 등이 있으며 최근에 가장 각광받는 것은 객체지향 개발방법론이라고 할 수 있다.

이러한 전통적인 소프트웨어 공학 방법론은 기본적으로 소프트웨어의 개발을 제조업에서의 생산 공정의 연장선상에서 소프트웨어라는 생산 대상의 특성을 고려하여 만들어지기 때문에 공정의 관리와 제어에 초점을 맞추게 되는 경우가 많다. 예를 들면 프로젝트의 관리를 위해 제안서 및 프로젝트 비용 산정, 프로젝트 계획과 스케줄링, 감독과 검토 과정을 거친 뒤 적합한 인력 배치 등을 하고 프로젝트 팀으로 구성된 조직은 조직 관리의 측면에서 최대한의 생산성을 갖출 수 있는 방향을 선택하도록 하는 것이다.

이런 소프트웨어 공학 방법론은 커다란 프로젝트의 위험성을 최대한 관리하면서 기존에 제조업과 사회과학 분야에서 개발된 여러 가지 형태의 도구를 응용할 수 있기 때문에 중간 규모 이상의 프로젝트에서 상당한 효과를 발휘한다. 이에 비해 창조적인 프로그래밍에 중점을 둔 방법론은 기본적으로 소프트웨어의 개발을 제조업에서의 생산 공정으로 보기보다는 개개인의 숨겨진 잠재력을 최대한 발휘해서 조합하는 것을 더욱 중요하게 생각한다. 그러므로 창조적인 프로그래밍에서는 소프트웨어 개발이란 일종의 공동 예술 작품을 완성하는 것과 비슷하다고 간주한다.

모든 방법론을 이러한 잣대로 분류하는 것은 무리이지만 최근에 각광을 받는 XP(eXtreme Programming), 애자일 소프트웨어 개발(Agile Software Development) 등의 방법론은 기존의 방법론에 비해 이러한 특성의 중요성을 많이 인정하고 있다. 필자는 개인적으로 이러한 두 가지 방법론을 모두 시험해 보았는데 어느 한 쪽의 방법론이 더 우월하다고 말하기는 어렵지만 전반적으로 프로젝트의 규모가 커지고 개발 인원의 수준의 차이가 많이 나는 구성원을 가질수록 전통적인 소프트웨어 개발 방법론이 효과적이며, 반대로 소규모 프로젝트이면서 개발 인원의 수준의 차가 적고 쌍방의 대화가 잘 이뤄질 수 있는 그룹이라면 창조적인 프로그래밍 방법론이 훨씬 효과적이었다.

소프트웨어 개발방법론에 관심이 있는 독자라면 시중에 좋은 책들이 많이 나와 있으므로 이들을 참고하면 큰 도움이 될 것이다. 전통적인 소프트웨어 공학적인 방법론은 교과서도 많이 나와 있고 방법론 자체에 대한 소개도 인터넷에서 쉽게 찾아볼 수 있다. 창조적인 프로그래밍과 관련해서는 켄트 벡(Kent Beck)이 쓴 ‘Extreme Programming Explained’와 애자일얼라이언스(AgileAlliance) 웹 사이트(http://www.aanpo.org/home)를 참고하기 바란다.

CASE vs. MDA
CASE(Computer Aided Software Engineering)는 소프트웨어 개발이나 각 과정별 작업을 컴퓨터의 도움을 받아 공학적 기술을 자동화하는 것으로 각각의 작업의 자동화에 이용되는 도구를 흔히 CASE 툴이라고 한다. 역사적으로 볼 때는 1980년대 초의 구조적 개발방법론이 80년대 후반의 CASE로 발전하게 되는데 초기의 CASE 제품들은 다양한 목적을 가지고 있었다. 대표적인 것으로는 모델링 작업을 도와주거나 데이터베이스를 생성하는 것에서부터 코드의 자동생성 및 역공학 툴, 그리고 프로그래머가 아닌 사람이 프로그래밍할 수 있도록 도와주는 GUI 툴 등이 있다.

초창기 CASE 제품들이 등장하던 시기에는 메인프레임에 대한 COBOL 프로그래밍과 관계형 데이터베이스에 대한 SQL CASE 툴이 주를 이뤘는데, 운영체제나 데이터베이스 아키텍처를 지원하기 위한 정보를 모아두는 공통적인 저장소(repository)가 존재하지 않아서 그 활용에 제한점이 있었다. 이를 극복하기 위해서 IBM에서는 AD 사이클/저장소(Cycle/Repository)를 만드는 프로젝트를 시도했지만 실패로 끝났다.

1990년대에 들어서면서 컴퓨팅 환경이 급속도로 메인프레임에서 유닉스, PC 기반의 운영체제로 그리고 컴퓨터 언어의 측면에서는 C와 베이직 같은 언어가 주류 언어로 자리를 잡게 되면서 기존의 CASE 툴의 활용도가 급속히 떨어지는 현상을 보여주게 된다. 1990년대 후반에 들어가면서 객체지향 프로그래밍 언어의 사용이 일반화되고 1997년에 OMG(Object Management Group)에서 UML(Unified Modeling Language)을 표준화한 것을 계기로 객체지향 모델링을 이용한 사례가 늘어나면서 기존의 CASE보다는 객체지향 개발방법론을 따르는 새로운 형태의 비주얼 툴들이 각광을 받게 되는데 대표적인 제품이 현재는 IBM에 합병된 래쇼날(Rational)의 로즈(Rose)나 볼랜드에 합병된 투게더(Together) 등이다.

CASE 툴의 경우 아직까지 성공과 실패를 논하기에는 이르지만 초기에 가졌던 거창한 목표 달성에는 이르지 못했다고 판단된다. 가장 큰 이유는 CASE가 지향하는 목표가 너무나 방대하고 이를 지원하는 툴들이 실제로 등장해서 소프트웨어 개발에 이용되기에는 실무 소프트웨어 개발 프로세스가 개발 방법론이라는 것을 모두 소화할 만큼 충분히 성숙하지 않았다는 것을 들 수 있을 것이다. 다시 말해, 이론은 좋았지만 현실세계에 받아들여지기에는 아직 먼 이상향이라고나 할까?

이러한 현상은 비단 CASE 툴에 국한된 것만은 아니다. OMG에서 최초로 표준화 작업을 했던 분산객체 표준인 CORBA(Common Object Request Broker Architecture) 역시 초기의 기대와는 다르게 그렇게 많은 영역에서 넓게 채택되지 못했다. 그 이유는 여러 가지가 있겠으나 가장 커다란 요인으로 생각되는 것 중의 하나가 지나치게 무겁고 복잡한 표준 규격으로 인해 실제 소프트웨어 개발에 있어서 쉽게 받아들여지기 어려웠다는 점이다. 그에 비해 최근의 웹 서비스가 그 자체가 가지고 있는 많은 약점에도 불구하고 비교적 쉽게 채택되고 있는 것은 가벼운 표준 규격으로 인해 자유로운 선택의 영역을 넓혔으며 여러 가지 지원 도구들을 통해 쉽게 구현이 가능했기 때문이라고 생각된다.

MDA는 이러한 CASE와 CORBA에서의 교훈을 바탕으로 CASE처럼 지나치게 야심차지 않으면서 보다 느슨하게 연관되어 있는 표준안들의 연결고리를 제공하는 방식으로 접근하고 있다. 또한 이러한 연결고리를 쉽게 구성할 수 있는 도구들을 적시에 제공함으로써 그 성공 가능성을 높이고 있다.

MDA 탄생 설화 - CORBA, UML, MOF 그리고 MDA
OMG는 1989년에 설립이 된 객체 기술에 대한 사용을 증진시키고 이에 대한 표준안을 만들기 위해 소프트웨어 산업계에서 구성한 컨소시엄이다. 이들이 모여서 최초로 만든 것이 바로 OMA(Object Management Architecture)인데, OMA에서 가장 중요한 역할을 하는 것이 바로 CORBA이다. CORBA는 다양한 프로그래밍 언어 간의 상호운용성을 위해 IDL(Interface Definition Language)이라는 것을 도입했다. 플랫폼에 독립적인 프로토콜을 위해 IIOP(Internet Inter-Operable Protocol)와 같은 프로토콜 표준안을 제시하였다. <그림 1>은 OMA를 도식화해서 나타낸 것이다.

<그림 1> Object Management Architecture

그리고 OMG에서는 객체지향 소프트웨어 디자인을 위해서 그동안 다양하게 제시되었던 모델링 시스템을 표준화해 UML을 1997년에 발표하게 된다. 그 밖에도 OMG에서 발표된 대표적인 표준안으로는 플랫폼에 독립적으로 메타 데이터와 데이터를 정의, 조작, 통합할 수 있는 모델 기반의 프레임워크인 MOF(Meta-Object Facility), MOF를 모델 기반의 XML 통합 프레임워크로 재구성하며 MOF 기반의 메타모델의 XML 맵핑을 지원하는 XMI(XML Metadata Interchange), 데이터 웨어하우스 도구, 웨어하우스 플랫폼 그리고 서로 다른 환경에 분산된 웨어하우스 메타 데이터 저장소들 사이의 비즈니스 메타 데이터의 상호교환을 가능하게 하는 표준 인터페이스인 CWM(Common Warehouse Metamodel) 등이 있다. 이들은 MDA를 구성한 하부 요소로서 그 역할을 하게 된다.

CORBA에서 UML로의 중심 이동
필자는 2000년부터 수년 간 OMG 총회를 참석하면서 매번 총회에 참석할 때마다 조금씩 변화해가는 분위기를 느낄 수 있었다. 2000년 초기의 OMG 총회만 하더라도 대부분의 업체들은 총회의 세부 모임에 있어서 CORBA를 중심으로 CORBA 표준 규격안을 발전시키는 데 주력하였다. 또한 CORBA를 분산객체 기술의 산업 표준안으로 발표했음에도 불구하고 이와 유사한 다양한 플랫폼들이 등장하였기 때문에 이들과의 상호운용성을 위한 작업들도 지속적으로 진행되었다. 대표적인 것이 CORBA/COM, CORBA/J2EE의 상호운용성을 확보하는 것이었다.

그리고 비교적 CORBA 표준안이 많이 채택되었던 통신업체와 국방 관련 업체들을 중심으로 해당 도메인 영역에서의 서비스(Service)와 퍼실리티(Facility)를 정의하는 작업들이 한창이었다. 그런데 해가 바뀌면서 OMG 총회에 참석하는 사람들의 움직임이 지속적으로 UML쪽으로 움직이기 시작했다. 그에 비해 CORBA 표준안과 관련한 것들은 특정 도메인 영역으로 축소가 되는 양상을 보이면서 OMG의 중심이 CORBA에서 UML로 넘어가기 시작했다.

이러한 변화는 기술 표준안의 우월성에서 기인한 것이 아니라 여타 다른 경쟁 기술들의 존재로 인해 더 이상 산업계 표준으로서의 추진동력을 점차 상실하고 있었던 CORBA에 비해 객체지향 프로그래밍의 폭발적인 증가와 경쟁이 되는 표준안이 없는 상태에서 사실상의 유일한 표준안으로서 그 위세를 떨쳐나가던 UML의 시장에서의 반응에 의한 것이다. UML은 기존의 플랫폼의 우월성이나 벤더들 사이의 제품 팔아먹기 경쟁에서 옆으로 비켜난 상태로 많은 개발자들에게 받아들여지면서 자연스럽게 OMG를 이끌어가는 핵심 표준안으로 각광받게 된 것이다.

MDA의 탄생과 그 이후
이때부터 OMG 내부에서는 MDA에 대한 구상을 의논하는 그룹들이 생겨나기 시작했다. UML의 시장주도적인 힘을 바탕으로 CORBA가 이뤄내지 못했던 이기종 플랫폼 및 언어독립성을 비교적 받아들이기 쉬운 방법으로 제시하려는 노력들이 모여서 MDA가 탄생하게 되었다. MDA는 2001년 3월 OMG의 CEO인 리차드 솔리(Richard M. Soley)가 ‘OMG Model Driven Architecture’라는 제목의 프리젠테이션을 통해 공식적으로는 처음 세상에 알려지게 되었다. 이 발표는 OMG 웹 사이트에서 현재도 10분 정도의 오디오 파일로 들을 수 있으므로 관심 있는 독자는 한 번쯤 들어보기 바란다. 이 발표를 시작으로 MDA에 대한 구체적인 규격을 논의하기 시작해서 2003년 6월에 공식적인 ‘MDA Guide v 1.0’이 공개되었다.

2001년 3월 MDA에 대한 발표가 있은 뒤부터 MDA 표준안을 실체화하고 MDA에서 내세운 개념들을 구체화하기 위한 움직임들은 점점 활성화되었는데, 그 이후의 OMG 총회에서는 이러한 논의들이 하나씩 소기의 성과를 거두게 된다. 필자는 처음 MDA를 발표하는 자리에 있었는데, 그 발표를 보는 순간 이것이 앞으로 갈 길은 멀어 보이지만 언젠가 세상에서 커다란 반향을 끌어낼 수 있을 것이라는 느낌을 받았다. 그러나 그 때만 하더라도 적어도 5년 안에는 저기서 이야기하는 것이 실체화하기는 어려울 것이라고 생각했었다.

이런 필자의 생각을 깨뜨린 것이 2001년 여름 OMG 총회에서 최초의 MDA를 지원하는 개발 툴로 소개된 아크스타일러(ArcStyler )였다. 당시의 제품은 UML 모델을 바탕으로 플랫폼에 독립적인 모델(PIM, Platform Independent Model)과 플랫폼 의존적인 모델(PSM, Platform Specific Model)을 따로 관리하는 기본적인 MDA의 형태를 갖추기는 했으나 실제로 지원하는 플랫폼은 J2EE 밖에 없는 것이었다. 그렇지만 MDA에 대한 기본적인 개념이나 구현 가능성을 실제로 보여줬기 때문에 당시에 커다란 반향을 불러일으켰다. 아크스타일러는 현재 볼랜드의 엔터프라이즈 스튜디오에 통합되어 있으며 이를 시발점으로 여러 MDA 지원 개발 툴들이 등장하기 시작했다.

MDA의 목표는 소프트웨어 분석가와 개발자가 소프트웨어와 비즈니스 자산을 기술하는데 이용할 수 있는 엔터프라이즈 아키텍처 모델링이 가능하도록 하는 것이다. 이러한 아키텍처를 소프트웨어 도구를 이용해서 만들어냄으로써 실제 소프트웨어 개발에 있어서 아키텍처를 구현하는 특정 애플리케이션을 쉽게 작성할 수 있게 되며 애플리케이션을 다양한 변경 요구에 맞게 쉽게 변경할 수 있을 것이다.

MDA 구성 요소
MDA는 여러 가지 모델과 표준들에 의해서 구성된다. 모든 MDA 모델 들은 MOF라는 추상적인 메타모델에 기초를 두고 있기 때문에 모두 연관되어 있다. 다시 말해 모든 MDA 모델은 MOF와 호환성이 있다. 이런 특징은 MDA에서 이용된 모든 모델들이 다른 MOF 호환 모델들과 호환성을 가진다는 것을 보장한다.

MDA에서 또 한 가지 중요한 부분이 UML 프로파일(profile)이다. UML 프로파일은 UML을 확장한 것이기 때문에 MOF와 호환성이 있으며, UML 2.0에서는 UML의 다양한 기능적인 사용 방법을 기술할 수 있다. UML 프로파일은 UML의 확장인 동시에 그 자체로 MOF 메타모델이다. 일부의 MDA 메타모델은 이미 OMG에서 과거에 정의된 것들이며 일부는 OMG 외부의 그룹 또는 벤더들에 의해 MOF 호환이 되는 형태로 만들어진 것이다. 이러한 OMG 외부의 메타모델들은 비록 공식적인 OMG 표준은 아니지만 MOF 호환성이 있기 때문에 MDA 개발 과정에는 사용되는 데 문제가 없다. 대표적인 MDA 모델들과 프로파일들로는 다음과 같은 것들이 있다.

CWM
CWM(Common Warehouse Metamodel)은 OMG에서 표준화한 데이터 웨어하우스를 관리하는 데 이용되는 메타 데이터 모델이다. CWM을 이용하면 개발자들이 관계형 데이터베이스 테이블, 레코드, 구조체, OLAP, XML 그리고 다차원 데이터베이스 디자인 등과 같은 수많은 데이터 모델 또는 포맷을 생성할 수 있다. 또한 CWM에는 데이터 웨어하우스 이외에도 사용될 수 있는 유용한 부분들도 있는데 예를 들면 데이터 모델이나 데이터 변환, 소프트웨어 배포 등에 관련된 내용도 포함되어 있다.

UML 메타모델
UML의 초기 버전은 MOF와의 완전한 호환성이 보장되지 않지만 UML 2.0은 MOF 호환성을 가진다. 이런 이유로 진정한 MDA 개발을 위해서는 UML 2.0이 사용돼야 한다. UML은 핵심 모델링 개념들과 이들을 위한 다이어그램들로 정의된다. 또한 개발자들이 UML 구성 요소에 다양한 제한(constraint)을 할 수 있도록 허용하고 있다. UML 2.0에서는 UML이 모델들의 행위를 지정할 수 있으며 이러한 행위의 표현들이 직접 코드로 변경된다.

XMI
XMI 표준은 MOF와 호환성이 있는 모델들을 XML 문서 형태로 표현하고 이를 MOF 호환 데이터베이스에 저장할 수 있도록 하는 표준이다. 그러므로 사실상 XMI 문서는 곧 MOF XML 문서라고 할 수 있다.

UML 프로파일
UML 프로파일은 특정 도메인에 대한 UML 모델을 작성하기 위한 일반 확장(generic extension) 메커니즘을 정의하는 것이다. 그러므로 UML 프로파일은 추가적인 스테레오타입(stereotype)과 태그 값(tagged value)이 적용된 엘리먼트(element), 애트리뷰트(attribute), 메쏘드(method), 링크(link) 등으로 이뤄진다. UML 프로파일은 이러한 확장 컬렉션을 이용해서 특정 도메인에 대한 모델링 문제를 기술하고 해당 도메인의 내용들을 모델링할 수 있도록 해준다.

현재 다양한 UML 프로파일이 나와 있으나 MDA와 관련해서는 플랫폼에 따라 각각의 프로파일이 정의될 수 있다. 현재 CORBA 프로파일, EAI 프로파일, EDOC 프로파일, 리얼타임 컴퓨팅을 위한 스케줄링 프로파일 등이 OMG에서 정의되었으며 EJB 프로파일은 JCP(Java Community Process)를 통해, 닷넷 프로파일은 마이크로소프트에 의해 정의되고 있다.

MDA 개발 프로세스와 특징
MDA는 이와 같이 그동안 발표된 여러 OMG의 표준 기술들이 하나로 접목되고 유기적으로 연결된 형태를 가지고 있다. 그 중에서도 MOF와 UML 프로파일의 역할이 가장 중요하다는 것을 아마도 독자도 느낄 수 있을 것이다. 이러한 구성상의 역할과는 별도로 MDA는 소프트웨어 리소스의 관리와 개발 자체에도 초점을 맞추고 있기 때문에 소프트웨어 개발 프로세스에서 모델들이 어떻게 이용돼야 하는지에 대해서도 기술하고 있다.

<그림 2>는 비즈니스 프로세스나 소프트웨어에 대한 기술서를 바탕으로 추상적인 모델을 추출하고, 추상적인 모델을 실행 가능한 구현 모델로 변환시키는 과정을 보여준다. 이런 프로세스에서 사용된 모델들은 UML과 같은 메타모델로 표현되는데 일부의 모델은 플랫폼과 무관하고 일부는 플랫폼과 밀접한 관계를 가진다.

<그림 2> MDA 개발 프로세스

<그림 2>에서 3가지 유형의 MDA 모델을 볼 수 있을 것이다. 일반적으로 비즈니스를 분석하고 요구사항을 추출하는 역할을 맡은 분석가가 CIM(Computation Independent Model)을 모델링하며, 비즈니스 아키텍트나 디자이너가 PIM(Platform Independent Model)을 만든다. PIM 모델은 특정한 구현 모델과는 독립적으로 어떤 형태의 아키텍처를 가질 것인지 기술한다. 그리고 나서 개발자와 테스터가 소프트웨어 툴을 이용해서 PSM을 PIM에서 뽑아낸 뒤에 이를 플랫폼 특성에 맞게 최적화를 하고 코드를 뽑아내게 된다.

MDA 개발 프로세스를 단계별 스텝으로 간단히 정리해 보면 다음과 같다.

이와 같이 MDA에서는 결국 UML 모델에서 코드를 만들어낸다. 그런데 어찌보면 이것이 새삼스러운 것은 아니다. 아마도 많은 개발자들이 래쇼날 로즈를 이용해서 자바 클래스를 UML 모델에서 만들어낸 경험이 있을 것이다. 이러한 작업과 MDA와의 가장 큰 차이점이라면 MDA는 플랫폼 독립적인 모델에서 시작해서 다양한 플랫폼을 지원하는 프로세스와 툴을 거의 완벽하게 지원한다는 점일 것이다. 이런 측면에서 간단히 MDA에서 만들어지는 모델들과 코드에 대해서 정리를 하면 다음과 같다.

MDA의 중요한 특징 중의 하나가 이와 같이 모델링 언어를 프로그래밍 언어처럼 이용하는 것이다. 모델링 언어는 일반적으로 자바나 C++와 같은 프로그래밍 언어에서 하는 것보다 더 높은 수준에서 ‘추상화(abstraction)’를 가능하게 하며, 이러한 추상화 프로세스를 통해 개발자들은 시스템 코드에 꼭 필요한 데이터 이외의 것들은 모두 숨길 수가 있다. 이런 과정은 개발 과정에서의 복잡도를 감소시키는 효과를 가져오기 때문에 개발의 생산성을 높일 수가 있다.

아마도 여기까지 읽은 독자는 일반적인 객체지향 프로그래밍 언어의 가장 큰 특징 중의 하나인 ‘캡슐화(encapsulation)’라는 단어를 떠올린 경우가 많을 것이다. 보통 객체지향 프로그래밍 언어의 3대 특징을 이야기하면 캡슐화, 상속성(inheritance) 그리고 다형성(polymorphism)을 언급한다. 그 중에서도 객체지향이라는 개념을 위해서 가장 중요한 것은 바로 캡슐화이다. 다른 두 가지 특징은 완전히 지원하지 않더라도 객체지향 언어라는 말을 할 수 있지만 캡슐화가 지원되지 않으면 객체지향이라고 말할 수가 없다. MDA는 이러한 객체지향 개념의 캡슐화를 극대화한 것으로 이해할 수 있다. 단순히 프로그래밍 언어 수준에서의 캡슐화가 아닌 모델링을 포함해서 구현에 이르는 과정을 단계별로 캡슐화한 것이 바로 MDA의 정체이다.

MDA 개발 프로세스에서의 이러한 추상화는 시스템의 규격을 하부의 컴퓨팅 환경에 덜 좌우되게 하기 때문에 시스템의 생산성을 높일 뿐 아니라 지속성도 높여준다. 이와 같은 추상화의 수준을 높임으로서 소프트웨어 개발 생산성을 높이려는 시도는 새삼스러운 것은 아니다. 가장 직접적인 예로 현재 우리가 사용하고 있는 대부분의 프로그래밍 언어는 3세대 언어(3GL, 3rd Generation Language)라고 할 수 있는데, 3GL 언어는 기본적으로 어셈블리 언어를 추상화한 것이라고 할 수 있다.

이를 통해 어셈블리 언어로 프로그래밍할 때 알아야 했던 많은 어려운 문제들을 간단하게 컴파일러에게 맡겨버린 뒤 소프트웨어의 생산성이 급속도로 높아졌다는 것은 모두가 인정할 것이다. 그러나 3GL이 처음 등장했을 때만 해도 여러 개발자들은 3GL이 개발자들이 코드를 작성하기 쉽게 해주고 높은 수준의 생산성을 보장하지만 만들어진 실행 프로그램의 수행 속도 문제 때문에 한동안 수많은 논쟁을 했었다. 이러한 문제는 하드웨어의 비약적인 성능 발전으로 인해 자연스럽게 작은 문제로 치부되기 시작했고 이를 통한 소프트웨어 생산성의 증가는 많은 것을 가능하게 하였다.

왜 MDA인가
지금까지 설명한 내용을 충분히 이해한 독자라면 아마도 MDA가 어떤 녀석인지 정도에 대해서는 감을 잡았을 것이다. 그렇다면 왜 MDA가 최근에 각광받게 되었는지에 대해서 조금 더 생각해 보도록 하자. MDA는 MDA 표준을 적용해서 모델의 자동화와 변환(transformation)을 통해 여러 플랫폼을 쉽게 지원하고 개발자의 입장에서는 시간을 많이 잡아먹는 코드 작성 부분을 줄일 수 있으며 개발 프로세스의 측면에서도 품질 관리(QA, Quality Assurance)를 수월하게 할 수 있다. 그리고 과거의 CASE나 4GL과는 다르게 구현시에 유연한 컨트롤이나 커스텀화가 가능하도록 하였다. 잘 알다시피 손으로 코딩하는 부분이 줄고 동시에 빨리 버그를 잡을 수 있다면 소프트웨어의 생산성은 월등히 증가하게 된다. MDA를 이용하는 것이 좋은 이유를 몇 가지 나열해서 설명하면 다음과 같다.

기술 플랫폼 및 기능 변화에 대한 신속한 대응
MDA에서는 PIM과 PSM을 분리했기 때문에 PIM을 변경하지 않고도 기술 플랫폼의 변화나 요구사항 변화에 발빠르게 대처할 수 있다. 예를 들어, 새로운 플랫폼에 대한 애플리케이션을 배포해야 하는 경우 PIM에는 수정이 필요 없으므로 단지 PIM을 이용해서 새로운 플랫폼에 대한 PSM을 자동으로 만들어내고, 이를 수정해서 코드를 다시 생성하는 과정을 통해 쉽게 새로운 기술 플랫폼에 대한 대응이 가능하다. 또한 기능의 변화를 요구하는 경우에도 PSM 수준에서의 변경을 고려하지 않고 PIM에 새로운 기능 변화와 관련된 수정을 가함으로써 쉽게 대응할 수 있다.

시스템의 지속성
플랫폼 의존적인 시스템은 기존의 아키텍처가 새로운 요구사항을 만족시키지 못하는 경우가 많이 발생한다. 이 경우에 완전히 새로운 아키텍처를 다시 잡기보다는 많은 사용자들은 작은 패치와 수정으로 이런 문제를 해결하기를 원하며 현실적으로도 그렇게 할 수밖에 없는 시간?경제적 여유만을 가지는 경우가 많다. MDA를 이용하면 기능과 아키텍처를 분리해서 정의하기 때문에 아키텍처의 변화가 있더라도 변환 과정을 거쳐 구현 과정으로 쉽게 진행할 수 있기 때문에 기능과 요구사항 변화에 의한 아키텍처 변경에 비교적 자유롭다. 이런 장점은 시스템의 생명주기를 연장시키며 더 안정된 시스템 유지를 가능하게 한다.

개발 생산성 증진
MDA는 모델의 자동화와 변환을 통해 여러 플랫폼을 쉽게 지원하고 시간을 많이 잡아먹는 코드 작성 부분을 줄일 수 있으며 쉽게 유지보수가 되도록 한다. 이와 같이 손으로 코딩하는 부분이 줄고 동시에 빨리 버그를 잡을 수 있다. 또한 한 번 작성된 PIM의 경우 비즈니스 핵심 부분에 대한 모델이기 때문에 향후 다른 시스템에서도 쉽게 이용될 수 있으며 재사용성이 높아지게 된다.

용이한 문서 작성
디자인 문서를 업데이트하고 관련 코드를 수작업으로 관리하는 것은 매우 시간이 많이 걸리고 귀찮은 작업이다. MDA에서는 모델과 코드, 문서가 항상 동기화되기 때문에 이러한 문서 작업에 필요한 일의 양을 줄여준다.

품질 관리 비용의 감소
개발 과정에서 소프트웨어의 문제가 늦게 발견될수록 이를 고치는 데 들어가는 비용은 증가한다. MDA 모델 자동화와 테스트 툴을 이용하면 개발자들이 애플리케이션을 모델 수준에서 테스트할 수 있기 때문에 디자인의 문제점이나 애플리케이션 로직의 에러를 빨리 잡을 수 있다. 이를 통해 품질 관리에 들어가는 비용도 감소한다.

양질의 시스템 구축
PIM의 단순함은 양질의 시스템 구축을 가능하게 한다. 모델링은 팀 멤버들 사이의 의사소통을 원활하게 만들고 동시에 결점이 있을 때 이를 빨리 제거할 수 있도록 도와준다. 또한 MDA의 자동화 도구들은 잘 정리된 코딩 패턴을 모델에 적용하기 때문에 손으로 직접 작성한 코드에 비해 결점이 적을 가능성이 많다.

기술 플랫폼 통합의 기로에 서서
OMG는 소프트웨어 개발에 있어서 운영체제와 프로그래밍 언어의 통합이라는 어려운 과제를 수행하기 위해 과거 CORBA를 통해 불철주야 노력했으나 현 시점에서 판단해 보면 그다지 성공적이라고 하기는 어렵다. 그렇지만 CORBA를 논의하면서 모였던 많은 지식과 경험들이 바탕이 되어 MDA라는 새로운 접근 방법을 합의하는 데 성공했으므로 그런 노력들이 헛되기만 한 것은 아니었다는 것을 보여준다. 마지막으로 MDA가 기술 플랫폼 통합의 기로에서 앞으로 어떤 길을 걷게 될 것인지 여러 가지 측면에서 살펴보자.

환경의 변화
최근의 소프트웨어 개발 환경은 과거 CORBA를 만들어낼 때보다도 더 많은 프로그래밍 언어와 기술 플랫폼들이 등장하고 있다. 그리고 소프트웨어의 복잡도도 나날이 증가하고 있으며 이런 복잡한 소프트웨어를 더 효과적으로 개발하는 것이 가장 커다란 도전이 되고 있다.

그렇지만 과거의 환경에 비해 좋은 점들도 있다. 그것은 실질적인 표준으로 받아들여지는 기술이 많이 등장하고 있다는 것이다. 네트워크 프로토콜에 있어서는 TCP/IP, 데이터베이스 질의와 관련한 SQL, 객체지향 모델링에 대한 UML 등은 이제 진정한 표준으로서의 입지를 굳혀가고 있다. 또한 리눅스에서 출발하고 아파치를 통해 더욱 널리 퍼져가고 있는 오픈소스 프로젝트와 이들의 개방 정신은 소프트웨어 개발 정신과 철학에도 지대한 영향을 미치고 있다. 모든 것을 처음부터 만들어내는 접근 방식을 채택하는 것보다 컴포넌트의 재사용과 ERP 애플리케이션을 개발하는 것과 같이 효율적인 소프트웨어 개발을 중요시하는 시각의 변화도 이러한 긍정적인 환경 요소이다.

그에 비해 날이 갈수로 레거시 애플리케이션과 데이터베이스가 늘어가고 ERP 애플리케이션과 같이 수정이 어려운 것들이 많아진다. 또한 다양한 미들웨어가 이용되는 최근의 환경은 다양한 요구사항을 수용하는 엔터프라이즈 아키텍처를 구성하는데 많은 장애가 되고 있다. 그렇지만 이런 장애는 바꾸어 보면 MDA의 성공을 촉진하는 계기가 될 수도 있다. 중요한 것은 MDA가 활약해야 할 환경의 조성은 확실히 되고 있다는 점이다. 그런 측면에서 현재의 환경 변화는 MDA의 성공에 긍정적이라고 할 수 있겠다.

시장의 반응
CORBA가 절반의 실패를 하게 된 가장 큰 이유는 무엇이었을까? 물론 기술적으로 여러 가지 문제를 지적하는 사람들도 많겠지만 필자는 시장의 반응에서 그 답을 찾고 싶다. OMG에서 CORBA를 처음 발표한 이후 실제 이 표준안 시장에 적용하여 내놓은 제품은 전무에 가까웠다. 기껏해야 아일랜드의 작은 벤처기업인 아이오나(IONA)가 오빅스(Orbix)를 통해 CORBA 시장에 뛰어들었고, 뒤를 이어 인도의 비지제닉(후에 볼랜드에 합병된다)이 비지브로커(Visibroker)로 승부를 해온 정도이다.

이들 회사는 마이크로소프트와 같은 거대 회사가 추진하는 COM이라는 강력한 적수를 상대로 나름대로 선전했지만 CORBA가 가지고 있었던 거대한 목표를 달성하는 데에는 실패했다. CORBA의 실패는 표준안이 만들어지는 것이 성공의 요소가 아니라 시장 주도 세력과의 타협을 이루는 것이 더 중요하다는 것을 보여주는 매우 중요한 사례이다.

그렇다면 MDA는 어떠한가? 기본적으로 MDA에 대한 시장은 객체지향 모델링과 개발 툴 벤더를 통해 활성화가 될 것이다. 이들은 MDA를 자신들이 제공하는 톨에 통합할 것이며 기존에 OMG에서 만든 표준안인 UML, MOF, CWM, XMI 등을 지원하는 툴들이 늘어나면서 자연스럽게 그 영역을 확장하고 있다.

이런 움직임은 이미 가장 커다란 벤더들을 통해 주도되고 있으며 여기에 반기를 들고 상대하는 벤더가 없는 상태이다. 쉽게 말하면 초기 장수들의 기세에 무혈 입성하는 분위기이다. 특집 3부에서 다뤄질 각 벤더들의 MDA 지원에 대한 기사를 읽어보면 이러한 움직임을 확실하게 느낄 수 있을 것이다. MDA의 성공 여부에 대해 의문을 가지고 있는 많은 독자들에게 필자는 과감하게 이야기하고 싶다. MDA는 기술의 우위성을 떠나 확실히 성공할 수밖에 없는 단계에 도달하고 있다는 것을… @