MDA는 소프트웨어 개발의 산업혁명을 가져올 것인가?

정지훈

객체지향 모델링 언어의 표준인 UML과 분산객체기술 표준인 CORBA, 그리고 그 밖에도 MOF, XMI, CWM 등의 표준안을 발표했던 OMG가 이번에는 MDA로 최근 소프트웨어 개발 방법 패러다임에 새로운 변화를 시도하고 있다. 여기서는 소프트웨어 개발 방법론과 OMG에서 MDA가 나오기까지의 역사적인 흐름과 숨겨진 뒷이야기를 알아보고 MDA의 기본적인 구성과 앞으로의 전망을 논의해 본다.

우리가 현재 살고 있는 산업사회에 있어서 중요한 것은 무엇인가? 혹자는 믿음이라고 답할 것이고, 혹자는 밥이라고 답할 것이며, 어떤 사람은 그저 애니메이션이나 실컷 보면서 살 수 있으면 그만이라고 말할 것이다. 무엇이 되었든 개인에게 있어서 틀린 답은 아니겠으나 산업사회의 발전을 위해서 가장 중요한 사회학적인 요인을 하나만 선택하라고 하면 그것은 곧 ‘생산성(productivity)’이 될 것이다. 소위 우리가 말하는 ‘산업혁명’이라는 것도 생산성의 폭발적인 증대로 귀결될 수 있다.
소프트웨어를 개발하는 입장에서도 이 생산성의 문제는 무척이나 중요하다. 같은 수준의 완성품을 만드는 데 있어서 가능하면 적은 시간과 적은 노동력과 원자재만을 이용하는 방법을 연구하는 것은 그런 측면에서 커다란 의미를 가지는 것이다. 이번 호 특집에서 언급하는 MDA(Model Driven Architecture) 역시 소프트웨어의 생산성과 관련해서 중요한 의미를 가진다.

소프트웨어의 생산성은 어떻게 높아지는가

그렇다면 과연 어떻게 소프트웨어의 생산성을 높일 수 있는가? 이 문제는 비단 최근에 제기되는 문제가 아니다. 물론 과거에 비해 복잡한 시스템 요구사항과 수많은 기술들이 등장하고 있는 근래에 그 중요성이 높아지고는 있으나 이미 소프트웨어 초창기부터 이 문제는 많은 사람들의 고민거리였다. 이 문제를 해결하기 위해서 등장한 대표적인 학문이 바로 소프트웨어 공학이다.
소프트웨 어 공학의 영역은 상당히 포괄적이다. 소프트웨어 개발에 투여되는 수많은 자원들의 효과적인 관리 방법과 평가, 그리고 조직과 의사결정 구조, 심지어는 개발자들의 심리상태에 대한 것도 대상이 될 수 있다. 소프트웨어 공학에 대해서 자세한 이야기를 하자면 소프트웨어의 위기에서부터 많은 방법론에 대한 것까지 커다란 연구 분야라고 할 수 있으며, 그 중요성은 복잡해진 환경에 의해 점점 더 높아가고 있다.

전통적인 방법론 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 Manage ment Architecture)인데, OMA에서 가장 중요한 역할을 하는 것이 바로 CORBA이다. CORBA는 다양한 프로그래밍 언어 간의 상호운용성을 위해 IDL(Interface Definition Language)을 도입했다. 플랫폼에 독립적인 프로토콜을 위해 IIOP(Internet Inter-Operable Protocol)와 같은 프로토콜 표준안을 제시했다. <그림 1>은 OMA를 도식화해서 나타낸 것이다.



그 리고 OMG에서는 객체지향 소프트웨어 디자인을 위해서 그동안 다양하게 제시되었던 모델링 시스템을 표준화해 UML을 1997년에 발표하게 된다. 그 밖에도 OMG에서 발표된 대표적인 표준안으로는 플랫폼에 독립적으로 메타 데이터와 데이터를 정의, 조작, 통합할 수 있는 모델 기반의 프레임워크인 MOF(Meta-Object Facility), MOF를 모델 기반의 XML 통합 프레임워크로 재구성한다. MOF 기반의 메타모델의 XML 맵핑을 지원하는 XMI(XML Metadata Inter change), 데이터 웨어하우스 도구, 웨어하우스 플랫폼 그리고 서로 다른 환경에 분산된 웨어하우스 메타 데이터 저장소들 사이의 비즈니스 메타 데이터의 상호교환을 가능하게 하는 표준 인터페이스인 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>에서 3가지 유형의 MDA 모델을 볼 수 있을 것이다. 일반적으로 비즈니스를 분석하고 요구사항을 추출하는 역할을 맡은 분석가가 CIM(Compu tation Independent Model)을 모델링하며, 비즈니스 아키텍트나 디자이너가 PIM(Platform Independent Model)을 만든다. PIM 모델은 특정한 구현 모델과는 독립적으로 어떤 형태의 아키텍처를 가질 것인지 기술한다. 그리고 나서 개발자와 테스터가 소프트웨어 툴을 이용해서 PSM을 PIM에서 뽑아낸 뒤에 이를 플랫폼 특성에 맞게 최적화를 하고 코드를 뽑아내게 된다. MDA 개발 프로세스를 단계별 스텝으로 정리하면 다음과 같다.

1. 애플리케이션에 대한 비즈니스 요구사항을 수집한다.

2. 도메인 모델에 대한 UML 다이어그램을 작성한다. 먼저 J2EE, 닷넷, CORBA와 같은 특정 기술에 종속적이지 않은 모델을 먼저 만든다. 이렇게 작성된 UML 모델은 핵심 비즈니스 서비스와 컴포넌트를 나타내게 되는데, 예를 들면 가격 결정 엔진이라든지 쇼핑 카트 모델이라든지 주문 모델 같은 것이 될 것이다. 이러한 UML 모델을 PIM이라고 한다.

3. 애플리케이션에 대한 특정 기술과 관련한 UML 모델을 작성한다. 이와 같이 특정 기술에 종속적인 UML 모델을 PSM이라고 한다. PSM은 직접 작성할 수도 있고 MDA 지원 툴을 이용해서 PIM에서 자동으로 만들어내거나 또는 만들어진 모델을 수정하는 방식으로 작업할 수 있을 것이다.

4. 마지막으로 MDA 툴을 이용해서 애플리케이션 코드를 만들어낸다. 현재 이미 J2EE의 경우에는 MDA 툴들이 대부분의 서블릿, JSP, EJB와 관련한 코드를 자동을 생성해준다. 그 다음에 만들어진 코드를 바탕으로 수정과 최적화 과정을 거쳐서 프로젝트를 완성한다.

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

◆ MDA는 다른 디자인 프로세스보다 고수준의 추상화를 먼저 시작한다. 예를 들어 PIM은 매우 추상적이다. 여기에는 엔티티와 서비스만 정의되어 있을 뿐이다.

◆ PSM은 메타 데이터의 형태로 애플리케이션을 완전하게 기술한다. PSM 수준에서 개발자들은 해당 기술과 관련된 디자인을 직접 코드를 건드리지 않고 향상시킬 수 있다.

◆ PSM에서 만들어진 코드는 완성된 애플리케이션에 근접하게 된다. 기존에 많은 도구들이 자동으로 만들어낸 코드들이 애플리케이션의 일부에 해당하는 것에 비해서 그 범위와 정도에 큰 차이가 있다.

◆ PIM에서 PSM을 만들어내고 PSM에서 코드를 만들어내는 알고리즘은 기본적인 것은 제공되지만 아키텍트가 변경하거나 재정의할 수 있다.

MDA의 중요한 특징 중의 하나가 이와 같이 모델링 언어를 프로그래밍 언어처럼 이용하는 것이다. 모델링 언어는 일반적으로 자바나 C++와 같은 프로그래밍 언어에서 하는 것보다 더 높은 수준에서 ‘추상화(abstraction)’를 가능하게 하며, 이러한 추상화 프로세스를 통해 개발자들은 시스템 코드에 꼭 필요한 데이터 이외의 것들은 모두 숨길 수가 있다. 이런 과정은 개발 과정에서의 복잡도를 감소시키는 효과를 가져오기 때문에 개발의 생산성을 높일 수가 있다.
아마도 여기까지 읽은 독자는 일반적인 객체지향 프로그래밍 언어의 가장 큰 특징 중의 하나인 ‘캡슐화(encapsulation)’를 떠올린 경우가 많다. 보통 객체지향 프로그래밍 언어의 3대 특징을 이야기하면 캡슐화, 상속성(inheritance) 그리고 다형성(polymorphism)을 언급한다. 그 중에서도 객체지향이라는 개념을 위해서 가장 중요한 것은 바로 캡슐화이다. 다른 두 가지 특징은 완전히 지원하지 않더라도 객체지향 언어라고 말할 수 있지만 캡슐화가 지원되지 않으면 객체지향이라고 말할 수가 없다. MDA는 이러한 객체지향 개념의 캡슐화를 극대화한 것으로 이해할 수 있다. 단순히 프로그래밍 언어 수준에서의 캡슐화가 아닌 모델링을 포함해서 구현에 이르는 과정을 단계별로 캡슐화한 것이 바로 MDA의 정체이다.
MDA 개발 프로세스에서의 이러한 추상화는 시스템의 규격을 하부의 컴퓨팅 환경에 덜 좌우되게 하기 때문에 시스템의 생산성을 높일 뿐 아니라 지속성도 높여준다. 이와 같은 추상화의 수준을 높임으로서 소프트웨어 개발 생산성을 높이려는 시도는 새삼스러운 것은 아니다. 가장 직접적인 예로 현재 우리가 사용하고 있는 대부분의 프로그래밍 언어는 3세대 언어(3GL, 3rd Generation Language)라고 할 수 있는데, 3GL 언어는 기본적으로 어셈블리 언어를 추상화한 것이라고 할 수 있다. 이를 통해 어셈블리 언어로 프로그래밍할 때 알아야 했던 많은 어려운 문제들을 간단하게 컴파일러에게 맡겨버린 뒤 소프트웨어의 생산성이 급속도로 높아졌다는 것은 모두가 인정할 것이다. 그러나 3GL이 처음 등장했을 때만 해도 여러 개발자들은 3GL이 개발자들이 코드를 작성하기 쉽게 해주고 높은 수준의 생산성을 보장하지만 만들어진 실행 프로그램의 수행 속도 문제 때문에 한동안 수많은 논쟁을 했었다. 이러한 문제는 하드웨어의 비약적인 성능 발전으로 인해 자연스럽게 작은 문제로 치부되기 시작했고 이를 통한 소프트웨어 생산성의 증가는 많은 것을 가능하게 하였다.

왜 MDA인가

지금까지 설명한 내용을 충분히 이해한 독자라면 아마도 MDA가 어떤 녀석인지 정도는 감을 잡았을 것이다. 그렇다면 왜 MDA가 최근에 각광받게 되었는지에 대해서 조금 더 생각해 보자. MDA는 MDA 표준을 적용해서 모델의 자동화와 변환(transfor mation)을 통해 여러 플랫폼을 쉽게 지원하고 개발자의 입장에서는 시간을 많이 잡아먹는 코드 작성 부분을 줄일 수 있으며 개발 프로세스의 측면에서도 품질 관리(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는 기술의 우위성을 떠나 확실히 성공할 수밖에 없는 단계에 도달하고 있다는 것을…

[ 모델~ 모델 ? 모델 ! ]

모델이란 무엇인가? 최소한 3가지 의미를 생각해 볼 수 있다. 첫 번째 의미는 스케치(sketch)이다. 우리들은 흔히 새의 날개를 보고 간단하게 긴 타원형의 날개를 연필로 그리기도 하며 비행기가 이륙할 때 흐르는 공기의 흐름을 몇 줄의 선을 긋는 것으로 표현하기도 한다. 경우에 따라서는 몇 가지 스케치 사이의 관계를 한두 개의 공식으로 표현하기도 한다. 스케치는 완벽하지도 않고 그래서도 안 된다. 이러한 스케치의 목표는 아이디어를 구체화하는 것이다. 프로그래머는 그들의 생각을 클래스와 유스 케이스(Use Case)로 스케치를 한다. 이러한 스케치를 하기 좋도록 제공되는 것이 UML이다. 간혹 스토리(story)라는 표현도 있는데 본질적으로는 비슷한 거라고 볼 수 있겠다. 스케치를 좋아하는 개발자 중에서는 코드를 이용하는 사람들도 있다.
두 번째 의미는 청사진(blueprint)이다. 가장 흔한 예가 건물을 지을 때 단면도 등이다. 청사진의 특징은 실제 계획에 대한 실체화라는 점이다. 그런데, 보통 모델을 청사진으로 이야기할 때에는 건축이나 제조 공장에서 사용되는 의미가 강하기 때문에 소프트웨어 개발과 같이 창조적인 작업에는 잘 맞지 않는 측면도 있다. 그렇지만 이러한 제조 공정에서의 장점을 살려서 소프트웨어 개발의 생산성을 따지는 경우에는 이러한 청사진의 의미로 모델이 쓰이는 경우가 많다. 소프트웨어 공학에서는 모델을 이러한 의미로 이용하는 경우가 많다. 가장 대표적으로 SEI(Software Engineering Institute)의 CMM(Capability Maturity Model)을 들 수 있겠다. 그렇지만 소프트웨어를 제조 공정보다는 창조적인 작업이 우선하는 것으로 간주할 경우에는 모델을 청사진의 의미로 이용하는 것은 적절하지 않다. 왜냐하면 창조적인 작업의 경우에는 개발자들이 모델을 예측 가능한 것으로 보기보다는 변화에 대한 적응으로 봐야하는 경우가 많기 때문이다.
마지막 세 번째 의미는 실행 가능(executable)한 것이다. 예를 들면 실제 비행기에 대해 하늘을 나는 모형 비행기를 만드는 작업을 연상하면 된다. 이러한 모델링이 소프트웨어 개발에서 가능하려면 모델링 언어도 실행 가능해야 할 것이다. 그러므로 실행 가능한 UML 모델을 만들 수 있다면 마치 자바나 C++로 프로그래밍을 하듯이 시스템의 행위를 더 명확하게 기술할 수 있을 것이다. 이러한 실행 가능한 관점에서의 모델의 의미를 적용한다면 자바와 같은 고수준 언어로 만들어진 프로그램들도 모델이라고 할 수 있을 것이다. 자바 프로그램은 실행이 가능한 바이트 코드로 변환되며 이러한 과정을 모델의 변환을 통한 실행이라고 볼 수 있다. 이 경우 모델을 만드는 사람, 즉 프로그래머는 자바 컴파일러가 어떻게 동작하는지, 그리고 프로그램이 어떻게 실행될 수 있는지에 대해서는 알 필요가 없다.
앞서 언급한 XP나 애자일 소프트웨어 개발과 같은 방법론(방법론이라고 하면 반대하는 이들도 많겠으나, 이 글에서는 그냥 용어의 통일성과 비교를 가능하게 하기 위해서 그냥 방법론이라고 하겠다)에는 코드를 관리하는 방법이 나와 있는 것이 아니라 프로세스나 고객과의 관계 그리고 관리 방법에 대해 기술되어 있다. 그러나 이러한 프로세스의 원칙들은 실행 가능한 모델을 구축하거나 코드를 만들어나가는 데에도 그대로 적용할 수 있는 것이다.

소프트웨어 개발 패러다임이 MDA로 진화하고 있다. MDA는 기존의 OMA, CORBA에 대한 업그레이드 버전이 아니라 이식성, 상호운용성, 재사용성에 대한 문제를 근본적으로 해결해 보고자 하는 노력의 산물이다. 특집 2부에서는 개발자 관점에서 MDA 개발 환경을 이해하고 각 MDA 기술 요소를 살펴보며 어떻게 개발이 수행되는지 알아본다.

MDA또 새로운 이름이 나왔구나. 그런데 이것을 적용하면 정말 좋아지긴 좋아지는 것인가? 이거 장사 속 아니야? 그러면 재미있게 일할 수 있는 거야? 야근 안 해도 되나? 개발자들은 이러한 원초적인 질문을 던질 수 있다.
소 프트웨어 개발 패러다임이 점차 MDA(Model Driven Architecuture)로 진화하고 있다. 시스템 규모가 전사적으로 확대되면서 데이터 모델의 설계가 중요하다며 정보공학이라는 개발 방법론이 제시되더니만 시스템 규모가 점점 더 확대되고 통합과 유지보수에 대한 이슈가 큰 문제로 제기되자 객체지향 방법론이 그 대안으로 제시됐다. 그러나 정보공학이 안정되기 시작하는 때에 컴포넌트란 명찰을 달고 유행을 일으킨 CBD 방법론이 나왔고, 다시 새로운 개발 패러다임이라면서 MDA를 논하기 시작한다. 이것들을 자세히 들여다보면 모두 하나의 큰 흐름 속에 존재하며 진화해가고 있는 것을 발견할 수 있다.

MDA의 이해

아주 오래 전의 개발 환경을 생각해 보자. 그 시대에는 컴퓨터가 각 대학교 연구소에서만 활용됐다. 이때 연구원들은 무언가를 시뮬레이션하기 위해 프로그래밍했고, 프로그래밍 언어로서 어셈블리어 같은 저수준 언어를 사용했다. 이는 간단한 프로그램을 개발하는 데도 아주 많은 양의 코드가 필요하며, 가독성도 떨어지고 디버깅도 아주 어렵다. 어쩌면 이 시대에는 이것들이 특별한 문제점으로 인식되기보다도 ‘이 바닥이 원래 그렇지~’라고 스스로를 위안하며 어셈블리 코드를 작성하고 있었을지도 모르겠다.
이런 환경에서 코드 생산성을 증대시키는 하나의 혁명이라고 할 수 있는 것이 탄생했으니, 그것은 바로 ‘컴파일러’이다. 누구나 쉽게 프로그래밍할 수 있는 고수준의 언어가 정의되고 개발자는 이 언어를 사용해 프로그래밍하고 컴파일러를 사용해 일종의 변환(trans formation) 작업을 거치면 바로 실행할 수 있는 바이너리 모듈을 뽑아낸다. 컴파일러의 등장은 어느 정도의 수행 능력(performance)을 희생해야 했지만 개발자에게는 가히 상상도 할 수 없을 정도로 큰 생산성을 가져왔다. 여러분이 현재 개발하는 시스템을 모두 어셈블리어로 작성한다고 생각해 보라. 생각만으로도 아주 끔찍하지 않은가.
MDA도 그 이상을 그리자면 소프트웨어 개발 패러다임의 혁명이라고 할 수 있다. 이제는 소스코드 레벨의 개발 작업이 한 단계 위로 끌어올려져 개발자는 시스템의 비즈니스에만 집중해 PIM(Platform Indepen dent Model)이라는 플랫폼 독립적인 모델을 설계하고 이것을 특정 플랫폼에서 동작하는 하나의 애플리케이션으로서 뽑아내기 위한 변환 정보 정의를 기술함으로써 프로그래밍 작업을 수행한다. 이제 컴파일러 격에 대응되는 MDA 툴들은 이 정보들을 갖고 변환 작업을 수행한 후 바로 실행 가능한 하나의 거대한 시스템을 탄생시킨다.
컴파일러는 그 당시 가장 큰 문제였던 프로그래밍에 대한 문제를 고수준으로 끌어올려 코드의 생산성을 증대시켰다면 MDA는 현재 엔터프라이즈 급에서 큰 고민인 (미들웨어를 포함한) 구현 플랫폼으로의 포팅 문제, 상호운용성, 재사용성에 대한 문제를 고수준으로 끌어올려 그것을 구현하는 데에 생산성을 증대시키려 하고 있다.

과연 MDA가 뜰까?

OMG(Object Management Group)에서는 1990년대부터 분산 네트워크 상에서 서비스 가능한 객체 모델에 대해 고민하기 시작했다. 시스템 용량이 커지면서 이것들이 플랫폼에 독립적으로 수행되기 위한 객체 표준과 그 객체가 분산 시스템 환경에서 어떻게 서로 서비스를 수행할 것인지에 대한 표준의 필요성이 대두되었다. 이에 따라 세상을 개방형 객체 모델로 묶어 보자는 의미에서 개방된 표준 객체 기반의 인터페이스를 제공하는 참조 모델로서 상호운용성과 재사용 가능한 이식성 있는 소프트웨어 컴포넌트 아키텍처를 정의하는 OMA (Object Management Architecture)를 발표했고, 이 분산 객체 아키텍처를 실현하기 위한 객체 요청 브로커(ORB)에 대한 표준화 작업을 수행했으며 결국 OMG 프레임워크 모델에 대한 첫 번째 인스턴스인 CORBA가 탄생했다.
그러나 CORBA는 점차 시장에서 다른 미들웨어 제품에 밀리면서 OMG 개방형 표준으로서의 입지는 사라지게 되었고 그 와중에 MDA가 탄생했다. MDA는 기존의 OMA, CORBA에 대한 업그레이드 버전이 아니라 이식성, 상호운용성, 재사용성에 대한 문제를 근본적으로 해결해 보고자 하는 노력의 산물이다. 현재 OMG는 UML 표준, Executable UML, UML 프로파일, MOF(Meta Object Model), CWM(Common Warehouse Metamodel), XMI의 표준화 작업을 수행하고 있으며 이것들은 MDA라는 OMG의 새로운 프레임워크로 조직화되고 구현되고 있다(<그림 1>).

<그림 1> MDA 적용


OMG 표준화 단체뿐만 아니라 현재의 IT 기술 리더와 기존의 각 케이스 툴 벤더들도 MDA 툴로의 진화를 가속화하고 있다. IBM은 강력한 공개용 통합 개발 환경인 이클립스에 많은 돈을 투자하고 있고 래쇼날을 인수해 비즈니스 시스템을 구축하기 위한 핵심적인 방법론, 케이스 툴 등 많은 엔지니어링 기술 및 도구를 확보했다. 또한 엔터프라이즈 애플리케이션 플랫폼으로 웹스피어를 갖고 있다. IBM은 개발 방법론부터 구현, 배치까지 서비스 수행에 이르기까지의 소프트웨어 개발에 필요한 모든 도구들을 확보했으며, 이것들의 통합은 MDA라는 새로운 패러다임 속에서 강력한 힘을 발휘할 것이다. 볼랜드도 자사의 애플리케이션 서버에 개발 도구로 J빌더를 갖고 있고 투게더를 인수해 모델링 도구인 투게더를 통합, MDA 도구로서의 진화를 꾀하고 있다. 마이크로소프트도 비주얼 스튜디오 2005에서는 MDA 도구를 제공한다고 한다.
시장을 주도하는 기술은 그 기술의 질과 유용성도 중요하겠지만 더 중요한 것은 영향력 있는 회사가 얼마나 그 기술에 투자하느냐는 것이다. 두 가지는 모두 시장의 기술을 선도하기 위한 필수적인 것이다. MDA는 기술적으로 현재의 시장 요구를 실현해 생산성을 높일 수 있는 패러다임으로서 진화 단계에 있는 모델이며, IT 세상을 주도하는 주요 회사들 역시 MDA에 많은 투자를 하고 있다. MDA 이상이 실현되기 위해서는 좀 더 지켜봐야겠지만 이는 일단 앞에서 제시한 두 가지 조건을 모두 만족시킨다. 자본주의 관점에서 얘기하면 MDA는 기술을 주도하고 있는 여러 회사들에게 돈을 벌어다 줄 수 있는 도구이다.

시장 트렌드 속에서의 MDA

MDA에 대해 이야기하기 전에 먼저 현재의 개발 플랫폼의 트렌드를 살펴보자. 가장 큰 이슈가 되는 것은 다음의 세 가지이다.

◆ 빠른 시장 대응(time to market)

◆ 상호운용성(interoperability)

◆ 개발 생산성(productivity), 유지보수(maintenance)

오늘날의 비즈니스 환경은 아주 빠르게 변화하고 있다. 끊임없이 변화하는 비즈니스와 고객들의 요구에 빠르게 대응해야만 시장에서 살아남을 수 있다. 현재의 주요 미들웨어 벤더나 통합 개발 방법론(UP : Unified Process), 최근에 부각되고 있는 애자일 방법론(Agile Method)은 모두 변화하는 고객 요구와 시장에 효과적으로 대응하기 위해 우수한 시스템을 개발하는 것을 최종 목표로 삼고 있다. 소프트웨어 업계에서는 이 문제들을 해결하기 위해 시스템 개발시 비즈니스 로직을 담고 있는 기능적(functional) 요구사항과 비기능적인(non-functional) 부분을 분리하자는 노력이 계속되고, 시장에 빠르게 대응하기 위한 컴포넌트 모델이 제안됐다.
비즈니스의 규모가 커지면서 각 엔터프라이즈급 시스템간의 상호운용에 대한 문제가 발생하고 이 문제를 효과적으로 해결하기 위해 많은 EA, EAI 솔루션들이 나오고 있다. 앞으로는 엔터프라이즈 망과 이동통신 망도 통합될 것이고 상호운용성에 대한 문제는 더더욱 커질 것이다. 현재 이런 고민들은 ‘미들웨어’라는 고마운 도구들이 많이 해결해 주고 있다. 우수한 미들웨어들이 많이 개발되고 있음에도 불구하고 앞의 문제는 개발 프로젝트 수행과 시스템 확장 및 유지보수의 문제에 있어서 여전히 큰 위험으로 작용하고 있다. 이러한 문제들을 근본적으로 해결할 수 없을까 하는 고민에서 나오게 된 것이 MDA이다.

기존 개발 방식과 MDA 개발 방식

MDA는 아주 오래 전부터 소프트웨어 공학자들에 의해 만들어지고 정제되어 왔으며 대부분의 SI 프로젝트에서 적용되고 있는 ‘비즈니스 모델링쭻요구사항 분석쭻설계쭻구현’ 방식의 탑 다운(top down) 모델의 개념을 갖는다.
대 표적인 객체지향 방법론인 UP에서는 비즈니스 모델링을 통해 전체 비즈니스를 파악하고 유스케이스 다이어그램을 통해 요구사항을 모델링하며 이것으로 분석 모델을 만든다. 이때의 분석 모델은 비기능적 요구사항이 전혀 반영되지 않은 순수한 비즈니스를 모델링하고 있으며, 이 분석 모델을 기반으로 적절한 플랫폼과 설계 메커니즘을 적용해 플랫폼 종속적인 설계 모델을 만들고 이를 기반으로 구현한다. 요구사항 모델은 시스템을 개발자 관점으로 가져오기 전에 고객과 의사소통하기 위한 수단이고 분석 모델에서는 어떤 환경에서 어떤 제약 조건을 갖고 구현될지는 생각하지 않고 순전히 비즈니스만을 반영한 모델을 모델링한다. 그리고 설계 모델에서는 비기능적 요구사항을 반영해 세부 설계를 하고 이 모델을 이용해 구현 소스 코드를 만든다.
MDA는 기존 개발 방식과 확실히 다른 소프트웨어 개발 패러다임을 갖고 있다. 기존 방법은 분석, 설계 작업을 통해 나온 모델을 개발자가 직접 구현하는 데 반해 MDA는 개발 작업의 중심이 플랫폼 독립적인 모델인 PIM을 구축하는 것에 맞춰져 있고 이후에는 MDA 툴을 사용해 변환 작업을 하여 최종 소스코드, 애플리케이션을 만들어내는 것이다. MDA 중심에는 PIM이 있고 툴과 변환 작업이 애플리케이션을 만들어내는 데 중요한 역할을 한다.

<그림 2> 기존 개발 방식과 MDA 개발 방식

MDA 개발 프로세스와 기술

MDA는 플랫폼 독립적인 PIM(Platform Independent Model)을 구축하고 이를 플랫폼 종속적인 모델인 PSM(Platform Specific Model)으로 변환하고 최종 애플리케이션을 구축하는 프로세스를 갖는다. 이때 가장 중요한 작업 중 하나가 PIM에서 PSM 모델로, PSM 모델에서 소스코드로 변환하기 위한 변환 작업이다(<그림 4>). 그러면 이것들은 어떤 기술 요소를 갖고 있고 어떻게 개발 작업이 수행되는지 살펴보자.

<그림 3> MDA 기술


<그림 4> MDA 개발 방법

도메인 모델, CIM

CIM(Computation Independent Model)은 시스템 요구사항과 환경에 대한 것을 기술하는 모델이다. 지금까지 우리가 써오던 용어를 빌리자면 도메인 모델(domain model) 또는 비즈니스 모델(business model)이라고 할 수 있다.
CIM에서는 시스템을 어떻게 구축해야 하는가를 고민하기 이전에 시스템의 전체적인 운용 모습을 이해하고 그 속에서 시스템이 무엇을 해야 하는지를 기술하며 개발자에게 시스템의 도메인에 대한 전반적인 이해를 도와 도메인 숙련자와 개발자간의 틈을 줄이는 역할을 한다.
CIM은 시스템의 비즈니스를 설명하는 소프트웨어 독립적인 모델이기 때문에 CIM으로부터 PIM을 추출할 수는 없다. 다만 PIM을 구축할 때 CIM을 통해 요구된 비즈니스 정보는 중요한 자산이 되며 CIM으로부터 추적성을 제공한다.

플랫폼 독립적인 모델, PIM

MDA 개발 프로세스에서 개발자의 주요 관심사는 좋은 소스코드를 작성하는 것에서 좋은 PIM 모델을 구축하는 것으로 옮겨간다. 다시 말해 개발자의 가장 중요한 작업은 PIM을 구축하는 것이다.

PIM 개발
MDA 개발 프로젝트의 시작점은 PIM을 구축하면서부터이다. PIM은 이름 그대로 구현 플랫폼 환경은 고려되지 않은 순수한 플랫폼 독립적인 설계 모델이며 UML 표준 모델링 도구를 이용해 시스템을 모델링한다. PIM의 상위 모델인 컨텍스트와 요구사항은 CIM과 여러 요구사항 수집 도구 및 방법론을 사용해서 수집하고 정형화시킨다. 여기까지는 정확한 요구사항을 모델링하기 위해 고객 입장에서 요구사항을 기술하고 모델링한다.
이제 앞 모델을 개발자 관점으로 가져와 시스템 개발을 위한 플랫폼 독립적인 모델을 구축한다. 요구사항을 통해 비즈니스의 기능들을 추출해 구조화시키고 이 기능을 수행하기 위한 동적 모델을 구축한다. 이때 모델은 각 비즈니스 규칙에 따라 정확하고 명료하게 기술해야 한다. 기존의 개발 방식은 대략 비즈니스의 개념을 잡는 정도로만 모델링해도 이후에 개발자가 직접 소스코드를 작성할 것이기 때문에 큰 문제가 없었으나 MDA 개발 방식에서는 기술한 비즈니스 규칙이 그대로 마지막 소스코드로 구현되기 때문에 상당히 주의해야 한다. PIM 모델은 시간이 아무리 지나도 비즈니스 규칙이 바뀌지 않는 이상 변경되지 않는다. 이후에 시스템이 새로운 비즈니스 기회를 맞아 다른 외부의 시스템과 연동을 위한 아키텍처로 변경되더라도 이것은 플랫폼 선택에 대한 문제이다. 그리고 새롭게 변화되는 플랫폼과의 연동 문제는 PSM 모델에서 브릿지를 통해 해결할 수 있다. 개발자는 비즈니스 규칙을 자바, C++, C# 같은 프로그래밍 언어로 소스코드를 작성하는 것이 아니라 설계 모델과 비즈니스 규칙을 기술하기 위한 새로운 도구를 이용해 프로그래밍하게 된다.
그 다음으로는 시스템의 비기능적 요구사항을 기술한다. 이것은 PIM 모델을 플랫폼 종속적인 PSM 모델로 변환하기 위한 정보들로써 플랫폼에 대한 변환 정보, 객체 모델, 지속성 모델, 트랜잭션, 보안 등에 대한 정보를 기술한다. 기존의 통합 방법론의 4+1 아키텍처 뷰에서는 유스케이스 모델을 가장 중심에 두고 유스케이스가 개발 프로세스 전반을 주도하는 모델인 데 비해 MDA는 가장 핵심이 되는 PIM 모델을 중심에 놓고 관리하면서 PSM으로 변환을 하고 소스코드를 추출한 후 완전한 하나의 시스템으로 패키징되어 테스팅할 수 있는 모델을 갖고 있다. PIM 모델을 효과적으로 구축하는 것은 MDA 개발 활동의 핵심이라고 할 수 있을 만큼 아주 중요하다.

PIM 구축을 위해 필요한 것
PIM이 명확히 정의되어 있지 않으면 PSM 모델을 만들 수 없고 시스템 구축은 불가능하다. 그만틈 PIM은 아주 중요하다. 앞에서 PIM을 구축할 때 UML을 사용한다고 이야기했다. 그렇다면 평소에 쓰던 UML만을 사용해 시스템의 모든 부분을 구축할 수 있을까라는 의문을 가질 수 있고 UML을 사용해 본 대부분의 독자는 절대 그럴 수 없다고 주장할 것이다.
표준 UML은 시스템의 정적인 측면과 동적인 측면을 모두 모델링할 수 있다. UML은 시스템의 구조적 모델(structural model)을 모델링하는 데 강력한 기능을 갖고 있다. 클래스 다이어그램은 각 클래스간의 모든 관계를 표현할 수 있고, 그 이상으로 스테레오 타입과 태그 값 등을 사용해 개념적인 부분까지 표현할 수 있다. 또한 이 클래스들을 그룹화해 서브시스템 또는 컴포넌트로 표현 가능하고 인터페이스를 사용해 컴포넌트를 캡슐화할 수 있다.
그러 나 UML은 시스템의 동적인 부분을 세밀하게 나타내기에는 부족하다. 현재 UML에서 정의하고 있는 인터랙션 다이어그램, 상태 다이어그램, 활동 다이어그램만으로는 PSM을 추출하고 코드까지 완성하기 위한 동적인 부분을 상세하게 표현할 수 없다. 시스템의 정적 모델을 표현하는 것은 아주 중요하다. 이외에 어떤 상황에 따라 시스템이 어떻게 동작해야 하는지 기술하는 것도 시스템을 구현하기 위한 필수적인 요소다. 어쨌든 우리는 PIM 모델을 PSM을 거쳐 소스코드까지 변환시켜 완전한 시스템을 구축해야 한다. 그러면 이 동적인 부분을 어떻게 표현해야 할까. 그리고 PSM 변환을 위한 정보는 어떻게 구축해야 하는 것일까. 다음의 세 가지 확장 기술이 해결점을 제시하고 있다.

◆ Executable UML

◆ CWM(Common Warehouse Metamodel)

◆ OCL(Object Constraint Language)

▶ QVT(Query, View, and Transformations)

Executable UML은 Action Semantics를 정의하고 상태 머신을 이용해 동적인 부분을 보다 상세히 기술한다. 이것은 실제 소스코드로 변환시키기에는 여전히 추상화 레벨이 높고 명확히 표준화되지도 않았다. 결국 이것은 아직 PIM에서 사용하기에는 부족한 부분이 많다. CWM은 원래 데이터 웨어하우스를 관리하기 위한 메타 모델인데 스키마 모델 변환에 대한 정의도 포함되어 있다. 2003년 말을 기준으로 아직 CWM 변환에 대한 스펙 작업은 거의 이뤄지지 않은 상태여서 어떻게 이것이 정의될지는 좀 더 지켜봐야 한다. 오래 전부터 UML의 확장 메커니즘으로 사용된 OCL은 시스템의 동적 모델을 상세하고 명확히 표현하기 위한 좋은 도구이다. 우리는 UML과 OCL을 이용해 시스템의 비즈니스 규칙과 흐름을 기술할 수 있고, 이는 어느 정도 완성도 있는 PSM 모델로 변환할 수 있다. 그러나 사실 개발자가 상세한 부분까지 OCL을 이용해 모든 흐름을 기술한다는 것은 개발 속도를 저하시키는 피곤한 일이 아닐 수 없을 것이다.
QVT는 PIM에서 PSM으로, 그리고 PSM에서 소스코드로 변환시키는 작업을 위한 표준 변환 정보를 정의한다. 앞의 세 가지 모델은 모두 QVT 범주에 포함되며 이는 각 모델간의 변환 작업을 위한 표준으로서 현재 표준화 작업이 진행중이다. QVT에 대해서는 뒤에서 자세히 살펴보겠다.
기존의 개발 프로세스에서 이전의 모든 분석, 설계 작업은 결국 마지막 소스코드로 작성하는 것이다. 최종 목적은 좋은 코드를 만들어내는 것이다. 우리는 이 코드를 컴파일할 것이고 컴파일러는 시스템 레벨 또는 가상머신 레벨의 어셈블리 코드 또는 가상머신 코드를 만들어낸다. MDA 모델에서는 최종 목적이 PIM이라고 할 수 있다. 개발자는 좋은 PIM을 구축해야 한다. MDA 툴은 컴파일러처럼 PIM으로 플랫폼 종속적인 모델을 추출하고 소스코드를 만들어내고 최종적으로 완전한 시스템을 구축한다. 효과적인 PIM을 구축하는 데는 여러 설계 패턴들이 존재할 것이며 PSM으로 변환하기 위해서 변환 정보를 기술하기 위한 QVT가 그 핵심적인 역할을 할 것이다.

<그림 5> PIM 개발 모델

플랫폼 종속 모델, PSM

PIM 모델이 완성되면 이 모델 정보는 MOF 저장소에 저장되고 변환 정보에 기술된 내용에 따라 특정 플랫폼에 대한 PSM(Platform Specific Model) 인스턴스를 생성한다. PSM 모델은 특정 플랫폼에 종속적인 모델로서 모든 플랫폼에 대한 정보를 표현해서 이후 컴파일 가능한 코드를 산출한다.
PSM 모델을 구축하기 위해서는 먼저 대상 플랫폼을 선택하고 런타임 환경과 구성 정보를 기술해 특정 기술 및 미들웨어 플랫폼의 형태로 변환한다. 이때 효과적인 변환 작업을 수행하기 위해서는 해당 플랫폼에 대한 숙련자가 필요하고 이들이 PSM 변환 작업에 참여해 플랫폼에 적절한 패턴을 적용해 모델을 정제한다. 그러면 질 좋은 PSM 모델을 구축할 수 있다. 해당 플랫폼에 대한 모델은 특정 플랫폼에 대한 UML 확장판이 UML 프로파일을 이용해 표현하고, 특정 벤더 종속적인 정보는 각 벤더에서 제공되는 플러그인을 사용해 표현하거나 직접 개발자가 세부 내용들을 작성함으로써 표현할 수 있다.
하나의 PIM은 하나 이상의 PSM으로 진화되는데, 여러 시스템이 하나의 PIM 집합으로 관리되거나 한 도메인에서 정의된 서브시스템이 서로 다른 플랫폼을 가질 때(예를 들어 A 시스템의 비즈니스는 전체적으로 EJB 환경에서 구현되는데 특정 서브시스템의 인터페이스는 다른 시스템과의 상호운용성을 위해 웹 서비스화시킬 수 있다) 멀티 플랫폼 형태로 진화된다. 이 때 두 개 이상의 PSM 모델이 구축되며 각 PSM 모델간에는 브릿지를 통해 서로 통신한다.
플랫폼 독립적인 설계 모델은 특정한 기술, 미들웨어를 갖는 플랫폼 종속적인 모델로 변환하는 것은 결코 쉬운 작업이 아니다. 좋은 PSM을 구축하기 위해서는 좋은 PIM 모델 구축이 중요하겠지만 플랫폼 숙련자가 PSM 모델로 변환하는 데 얼마나 힘을 발휘하는지, PSM 변환 툴이 어느 정도나 자동화되는지, 또한 변환 툴이 각각의 플랫폼을 얼마나 확실히 지원하면서 어렵지 않는 UI 환경을 갖는지 등 현실적으로 구현되기 까다로운 부분이 많이 존재한다. 이것들을 어떻게 효과적으로 풀어가느냐가 OMG와 각 벤더들의 과제일 것이다.

<그림 6> PIM에서 PSM으로 변환 모델

애플리케이션 생성

PSM은 자동으로 해당 구현 환경에 대한 소스코드를 생성하고 런타임 구성 파일을 만든다. 만약 구현 환경이 EJB라면 홈 인터페이스, 리모트 인터페이스, EJB 클래스를 생성하고 배치를 위해 여러 배치 디스크립터(deployment descriptor)를 만든다. 구현 환경이 웹 서비스라면 툴은 WSDL 파일들을 생성하고 UDDI 레지스트리 정보를 구축한다.
기존의 케이스 툴도 모델로부터 소스코드를 생성하는 순공학(forward engineering)을 지원했다. 그러나 MDA 툴은 그것을 뛰어넘어 각 컴포넌트의 비즈니스 로직을 구현하고, 바로 실행시켜 서비스를 제공할 수 있는 ‘완전한’ 하나의 시스템을 구축한다는 것이다. 즉 컴파일러에서 전처리, 컴파일, 링크 과정을 거쳐서 실행할 수 있는 하나의 실행 파일을 뽑아내듯이 MDA 툴을 통해 바로 서비스 가능한 완전한 시스템을 만들어낸다. 자동화 툴에 의해 완전한 시스템 하나를 구축하는 것. 그것이 MDA의 지향점이다. 그러나 이것이 현실로 실현되려면 아직 넘어야 할 산들이 많다.

변환 정의(Transformation Definition)

소스코드를 작성하고 이것으로부터 실행 파일을 만들어낼 때 제일 중요한 것은 너무 당연하고 보편적으로 인식되어 어느새 우리의 기억속에서 잊혀져 버린 ‘컴파일러’이다. PIM에서 PSM, 그리고 PSM에서 소스코드로 변환하는 작업은 MDA의 꽃이라고 할 만큼 혁신적이고 중요한 개념이다. 이 작업을 수행하기 위해서는 먼저 컴파일러 격에 해당하는 변환 툴이 있어야 하고, 변환 작업이 어떻게 이뤄지는지에 대한 정보를 갖는 변환 정보가 정의되어 있어야 한다. 특정 프로그래밍 언어로 개발을 수행할 때 가장 기초가 되는 것이 바로 프로그래밍 언어의 문법이다. 이와 마찬가지로 MDA에서 변환을 수행하기 위해서는 반드시 표준화된 변환 정보가 정의되어 있어야 하고, 이 변환 정보 정의는 세부적인 표준화된 세부 지침과 명확한 가이드를 갖는 변환 규칙(transformation rules)들로 구성되어 있다.

<그림 8> MDA 개발 방식


<그림 9> 공통 QVT 컴포넌트 : 인프라스트력쳐 라이브러리의 특화된 형태로 나타난다

QVT 표준화 작업
OMG에서는 변환 작업에 대한 표준화 작업이 절실하다는 것을 느껴 변환 정보 정의의 표준화 작업을 시작했는데, 이 표준을 QVT(Query, View, and Transformation)라고 한다. QVT는 OMG에서 2002년 4월에 처음 RFP가 정의됐고 2003년 3월 첫 번째 서브미션을 거쳐 2004년 4월에는 두 번째 개선안이 발표됐다. QVT는 2003년도에 발표된 첫 번째 개선 작업에 의하면 전체 7개의 영역으로 나뉘어 정의하고 있다.

◆ 아키텍처 : QVT에 대한 전체 아키텍처를 설명한다.

◆ QVT Common Structure : QVT를 사용해 변환 정보를 정의하기 위한 기본 QVT의 개념과 용어들을 정리한다.

◆ QVT using a rule-based language : TRL(Transformation Rule-based Language)과 이를 표기하기 위한 BNF 문법을 정의한다.

◆ QVT in the context of UML Profiles : QVT에서 UML 프로파일에 기반한 변환 작업을 기술한다.

◆ QVT using a framework approach: QVT 작성시 프레임워크 적용에 대한 내용

◆ QVT Interoperability : 서로 다른 QVT 컴포넌트에 대한 상호운용 모델을 표현하기 위한 메타 모델을 제시한다.

◆ 추적성(Traceability) : 요구사항→PIM→PSM→소스코드까지의 추적성에 대한 개념을 제시한다.

모델 변환 방법
OMG에서 2003년 발표한 MDA 가이드 1.0에 따르면 다음 네 가지 형태의 변환 방법을 정의하고 있다.

◆ 손으로 직접 변환

◆ UML 프로파일을 사용한 변환

◆ 패턴을 적용해 변환

◆ 자동화 툴을 사용한 변환

일단 하나의 방법으로 개발자가 직접 변환하는 방법을 제시하고 있지만 이것은 지금까지의 설계 작업을 하는 것과 전혀 다르지 않다. 결국 MDA가 지향하는 바는 UML 프로파일과 패턴들을 적용해 툴에 의해 자동으로 변환 작업을 수행하는 것이다.

<그림 10> UML 프로파일을 적용한 QVT 변환 모델


<그림 11> QVT 프레임워크 접근법에 대해 인터프리터 패턴을 적용한 추상화 모델

변환 작업 수행에 대한 과제
개발자는 표준 QVT의 정의와 가이드에 따라 설계하고 시스템을 구현하기 위한 모든 정보를 기술한다. 이것은 툴을 통해 변환 작업을 거쳐 PSM을 추출하고 다시 이를 변환해 소스코드와 구성 정보를 만들어내고 이를 컴파일해 최종 애플리케이션을 구축한다. PIM 이후 작업은 툴에서 알아서 해주기 때문에 애플리케이션 구축 과정에 대해서는 신경 쓸 필요가 없다.
이 모델이 실현되기 위해서는 해결돼야 할 두 가지 문제가 있다. 그것은 시스템를 구축할 수 있을 정도의 정교함을 갖는 QVT의 표준화 작업과 QVT 정보를 분석해 모델을 변환하고 최종 시스템을 만들어내는 MDA 툴의 개발이다. 두 가지 작업은 이제 막 시작됐으며 아직은 안개 속에 있고 어떻게 그 최종 목표를 향해 진화될 것인지 지켜봐야 한다.

MDA 개발 모델과 개발자

앞서 MDA 개발 방식에 대해 살펴봤다. 독자들은 MDA를 적용한 개발 방식이 어떻게 수행되며 이것이 실현되기 위한 요소가 무엇인지 파악했을 것이다. 이제는 오늘날의 개발 프로세스를 생각해 보면서 MDA가 적용됐을 때 변화되는 개발자의 역할에 대해 살펴본다.

역할 변화

MDA 개발 프로세스는 기존의 개발 프로세스 방법과 차이점이 있다. 기존의 방법은 최종에 개발자가 효과적으로 하나의 거대한 시스템을 직접 손으로 구현해야 하는 것에 초점이 맞춰져 설계되어 있다. 그러나 MDA 개발 프로세스 모델은 요구사항을 정확히 분석하고 비즈니스를 세밀하게 모델링해 PIM을 구축하도록 하고 있다. 이 PIM에는 PSM으로 변화하기 위한 표준 지침인 QVT를 기술하고 이 정보들을 중심으로 PSM을 추출하고 소스코드를 추출하면서 플랫폼 아키텍처 모델, 데이터베이스 스키마, 테스트 코드, 구현 소스코드 등이 작성된다.
기존에는 대략 전체적인 개념만을 잡고 필요에 따라 세부 설계를 하여 개발했고 한번 작성한 모델이 구현 단계에서 변화하는 경우가 빈번했다. 그러나 MDA 개발 프로세스에서는 PIM 구축시 모든 비즈니스에 대한 정적 구조 및 동적인 부분을 완벽하게 기술해야 한다. 그래야만 원하는 애플리케이션을 구축할 수 있다. 결국 MDA 개발 프로세스로 인해 구축돼야 할 핵심이 변화하고, 이에 따라 개발자의 역할도 각 핵심을 실현하는 형태로 변화해야 한다.

각 역할에 대한 책임
MDA 개발 프로세스를 수행하는 각 역할을 정의하고 그 역할의 책임에 대해서 살펴보자. MDA는 새로운 개발 패러다임이다. 기존에 비해 각 개발 단계에서 추구하는 최종 목적이 다르며 이를 개발하는 개발자의 역할들도 그 목적에 따라 변화하게 된다.

◆ 분석가(Analyst, Requirement Analyst) : 고객으로부터 시스템에 대한 요구사항과 주요 문제점을 추출해야 할 것과 하지 말아야 할 것에 대한 접점을 명확히 분석해야 한다. 유스케이스 모델이나 활동 다이어그램을 이용해 PIM을 설계하는 데 중요한 정보인 기능적 요구사항 모델을 구축하고 보안, 성능, 가용성에 대한 내용을 갖는 비기능적인 요구사항을 정리해 CIM을 구축한다.

◆ 아키텍트(Architect) : 전 체적인 개발 프로세스를 진행하면서 기술 리더로서 시스템의 논리적, 물리적 모델을 제시하고 아키텍처 스타일, 설계 패턴, 플랫폼에 대한 선택과 적용에 대해 결정하며 효과적인 PIM을 구축하고 각 변환 작업을 수행할 때 핵심적인 역할을 수행한다.

◆ 설계자(Designer) : 요구사항 모델을 갖고 클래스 다이어그램, 상태 다이어그램, 시퀀스 다이어그램 등 각종 표준 도구를 사용해 요구사항을 모델링한다. 여기서 개발자가 설계하는 모델은 다른 모델과 소스코드로 변환되기 때문에 매우 엄격하게 분석 및 설계해야 한다.

◆ 구현자(Implementor) : 자 바, C++와 같은 소스 레벨의 프로그래밍 언어 대신에 QVT, OCL 및 Executable UML을 이용해 비즈니스를 구현한다. 이들은 MDA 개발 툴을 사용해 PSM 모델과 소스코드를 생성하고 그 자체로 하나의 시스템을 구축하기 위한 내용을 구현한다. 현재 개발자들 관점에서 보면 개발 작업이 더 지루해질 것 같은데, 앞의 사항들은 매우 세밀하게 기술돼야 하며 여러 테스트 도구와 유효화 도구들이 그 작업을 도울 것이다.

◆ 테스터(Tester) : MDA 툴에 통합되어 있는 MDA 테스트 도구는 현재 구축되어 있는 모델로부터 바로 테스팅 프레임워크를 구축하고 테스트 코드를 추출한다. 테스터는 MDA 테스트 도구의 특정 설정을 변경하거나 일정의 테스트 코드를 수정, 입력하면서 편리하게 테스트를 수행할 수 있다.

◆ 유지보수자(Maintenancers) : 유 지보수의 중요성은 아주 오래 전부터 이야기되고 있는 문제이다. 사실 소프트웨어 공학이 나온 가장 근본적인 시발점이 바로 유비보수 비용에서라고 말해도 무리는 아닐 것이다. MDA에서는 매우 정교한 PIM 모델이 존재하기 때문에 기존처럼 소스코드와 모델의 불일치성을 걱정하지 않아도 되고, 시스템의 비즈니스 흐름이나 구현 플랫폼이 변경되었을 때 소스코드가 아닌 PIM에 정의된 모델과 각종 규칙만을 변경하면 되므로 유지보수에 있어 생산성을 향상시킬 수 있다.

<그림 12> MDA 개발 모델에서의 역할

함께 하는 MDA 프로젝트

앞서 MDA의 개념, 개발 방식, 특징들에 대해 살펴봤다. 그러면 이것들을 적용해서 개발한다면 어떻게 진행될까. 정말 생산성 향상은 있을까?
현 재 여러 곳에서 MDA를 적용한 참조 구현 모델에 대한 자료가 발표되고는 있지만 아직 변환 정보 정의를 포함함 스펙 작업, MDA 개발 툴 및 WAS 벤더들의 MDA 적용을 위한 플러그인 등이 성숙되지 못해 그것의 실현 모델은 안개 속에 있다. 올해 말부터는 각 툴 벤더들이 MDA를 강력히 지원한다고 하니 필자도 MDA 도구들이 어떤 모습을 하고 있을까 기대된다. MDA의 실현에 대한 안개는 서서히 걷히고 있지만 그래도 변환 정보 정의가 정식 릴리즈되고 개발 방법론이 안정화되고 툴이 강력해지면서 MDA 시장이 성숙하는 데까지는 적잖은 시간이 소요될 듯싶다.

요구사항 정의

이제 MDA를 적용했을 때 어떻게 개발이 수행되는지 간단한 예제를 갖고 직접 MDA 개발 방식을 체험해 보는 시간을 갖자. 간단한 전자상거래 시스템을 예로 들자. 이 시스템은 전자 제품 쇼핑몰로서 사용자는 구입을 원하는 상품을 선택해 장바구니에 넣어놓고, 주문을 요청했을 때 주문되는 시스템이다. 우리는 이중에서 주문을 관리하는 부분을 구현할 것이다.
이 시스템은 3티어 구조를 갖고 있으며 누구나 쉽게 접속해서 주문 처리를 할 수 있도록 클라이언트는 웹 기반의 JSP 클라이언트가 필요하고 고객 데이터와 상품 정보, 주문 정보를 관리하기 위해 독립적인 데이터베이스를 사용한다. 그리고 미들티어에는 전자상거래 비즈니스를 수행하기 위한 비즈니스 로직을 구현한다.

PIM 모델 개발

개발자는 요구사항을 분석해 <그림 13>처럼 PIM 모델을 만든다. 사용자는 원하는 상품을 검색해 구매를 위해 ‘장바구니’에 지정한 상품을 넣는 작업을 할 것이고 이 상품은 ShoppingCart에 저장된다. 쇼핑을 마쳤으면 최종 주문을 위해 화면에서 ‘주문’ 버튼을 선택해 주문하고 주문 요청은 PurchaseOrder에서 받아 현재 장바구니에 있는 상품 리스트를 얻어와서 주문 총액을 계산한 후 주문을 처리한다.
현재 이 모델은 순수 비즈니스를 표현하고 있으며 어떤 플랫폼으로 어떻게 구현될 지 전혀 모른다. 다시 말해 이 모델은 웹 브라우저 클라이언트와 EJB로 구현될 수도 있고, 클라이언트 애플리케이션과 웹 서비스 모델로도 구현될 수 있다.
이제 PIM을 PSM으로 변환시켜야 한다. 모델 변환을 위한 변환 정보를 기술해야 한다. 이 시스템을 3티어 구조로 만든다고 정의했기 때문에 각 티어는 서로 다른 플랫폼을 갖게 되고 우리가 설계한 PIM은 최소 3개의 PSM으로 진화한다.
먼저 데이터 저장소를 위해 앞 모델로부터 객체 데이터 모델을 위한 변환 정보를 기술하고, 비즈니스 로직은 EJB로 구현하기 위해 EJB에 대한 변환 정보를 작성한다. 마지막으로 JSP, 서블릿 플랫폼에서 동작하기 위한 웹 클라이언트 모델로의 변환 정보를 작성한다. PIM에 변환 정보를 기술하고 MDA 툴을 통해 변환을 수행하면 자동으로 PIM에서 정의한 비즈니스를 갖는 각 티어별로 플랫폼 종속적인 PSM 모델이 만들어진다.

<그림 13> 쇼핑몰 예제의 PIM


<그림 14> 쇼핑몰 예제의 PIM의 진화 모델

PSM 모델 개발

PIM에서 변화된 PSM 모델을 살펴보자.

PSM #1 : EJB 플랫폼
PIM에서 설계한 클래스는 PSM으로 맵핑되면서 그 속성에 따라 세션 빈과 엔티티 빈으로 나뉜다. 세션 빈으로 맵핑되는 모델은 MDA 툴에 의해 홈 인터페이스와 리모트 인터페이스를 추출한다. 리모트 인터페이스의 리모트 메쏘드는 PIM 모델에서 특정 메쏘드에 리모트 메쏘드 성격을 기술해 만들어진다. 그리고 실제 비즈니스를 갖는 EJB 구현 클래스가 생성된다. 이 구현 클래스에는 PIM에서 정의한 비즈니스 메쏘드뿐 아니라 EJB 컨테이너에 의해 콜백되는 라이프사이클 관련 메쏘드도 만들어진다.
엔티티 빈으로 맵핑되는 모델도 홈 인터페이스와 리모트 인터페이스를 추출하고 해당 홈 인터페이스에는 엔티티 맵핑에 대한 메타 타입이 작성되면서 하나 이상의 find 메쏘드가 정의된다. 그리고 리모트 인터페이스에는 각 엔티티 애트리뷰트를 읽고 쓰기 위한 get, set 메쏘드가 정의되고 EJB 구현 클래스는 이들을 구현한다. 이처럼 만들어진 EJB 플램폼에 대한 PSM 모델은 UML 프로파일에 정의된 표준 EJB 표현 형식을 빌어 기술되고 이후 소스코드로 변환되기 위한 중간 단계인 PSM 모델을 완성하게 된다. 우리는 PIM에서 미들티어를 EJB로 선정해 플랫폼 종속적인 모델을 추출했다(<그림 15>). 만약 미들티어를 웹 서비스 환경으로 변환시키려면 웹 서비스 변환 규칙에 따른 변환 작업을 해주면 된다(<그림 16>).

<그림 15> PurchaseOrder의 PSM(EJB 맵핑)


<그림 16> PurchaseOrder의 PSM(웹 서비스 맵핑)

PSM #2 : 데이터베이스 플랫폼
PIM에서 정의한 비즈니스를 수행한 지속성 메커니즘으로 독립적인 데이터베이스 플랫폼을 사용한다. PIM에서 설계한 클래스는 관계형 데이터베이스 모델로 변환된다. PIM 모델에는 해당 비즈니스를 위한 엔티티 모델이 존재한다. 엔티티 객체 모델에서는 각 엔티티간의 관계를 모델링 또는 기술하게 되고 이 정보를 이용해 데이터 모델을 추출한다. 우리가 사용할 데이터베이스는 관계형 데이터베이스이기 때문에 객체-관계 맵핑(object-relational mapping) 규칙을 적용해 데이터 모델을 구축한다.
엔티티 객체 모델에서 하나의 클래스는 하나의 테이블로 맵핑되고, 클래스에 정의된 애트리뷰트는 하나의 컬럼으로 맵핑된다. 이때 애트리뷰트가 특정 데이터 타입을 갖는다면 그 애트리뷰트는 독립적인 테이블로 분리하며 분리된 테이블의 키 컬럼으로 foreign key 관계를 설정한다. 현재 설계 모델에서 바로 데이터 모델을 추출하는 문제는 많은 툴 벤더들이 오래 전부터 고민해 왔으며 현재의 케이스 툴에서도 상당 부분 지원하고 있다.

PSM #3 : 웹 클라이언트 플랫폼
웹 클라이언트의 모습을 살펴보면 사용자가 특정 요청을 보내면 시스템은 그 요청을 처리한 후 결과가 화면에 보여지는 형태를 띠고 있다. 웹 모델에는 화면에 결과가 디스플레이되기 위한 웹 엔티티와 화면 레이아웃, 사용자와 인터페이스하기 위한 HTML 페이지가 만들어진다.
이때 만들어지는 웹 데이터 스키마는 EJB 모델의 그것과 유사한 형태인데 다만 그것을 기준으로 사용자에게 나타나고 사용자를 통해 운용되기 위한 모델로 다듬어진다. 또한 클라이언트는 사용자와 인터페이스하며 사용자의 액션을 받아 처리하기 때문에 각 액션에 대한 정의도 구축되고 이 액션에 따른 웹 프리젠테이션 모델이 구축된다.
웹 인터페이스는 최초 요구사항을 수집할 때부터 정확히 정의하기 위해 사용되기 시작해서 프로젝트가 끝날 때까지 새로 생기고, 가장 빈번히 변경되는 부분이다. 결국 이 부분이 어떻게 구축되느냐는 프로젝트 생산성에 있어서 큰 영향을 미치게 되고 현재 이러한 문제를 해결하려는 관련 프레임워크들이 존재한다. 대표적으로 스트럿츠(Struts)의 예를 들 수 있다. 웹 모델로의 PSM 변환 작업은 QVT에 웹 모델 변환 표준들이 존재하면서 특정 또는 툴 벤더 자체의 웹 프레임워크를 적용한 형태로 변환 작업이 수행될 것이다.

소스코드 변환

이제 모든 비즈니스 정보를 갖는 PIM에서 각 플랫폼을 적용한 PSM을 통해 특정 환경 종속적인 소스코드를 만든다. 먼저 EJB 모델은 PSM 모델에서 구축한 모습에서 표준 소스코드 변환 규칙을 적용해 소스코드를 만들어내고, 데이터 모델은 DDL을 생성해 지정된 데이터베이스에 바로 데이터베이스 스키마를 구축한다. 그리고 웹 클라이언트는 지정된 프레임워크의 구현 모델로 변화하며 웹 저작툴을 이용해 사용자 친숙한 화면을 설계한다.
MDA 개발 방식에 대해 간단한 전자상거래 시스템 예제를 갖고 이야기를 했다. 사실 예제에서 제시한 방법은 MDA의 강력함을 느끼기에는 부족한 점이 많다. 비록 시스템의 일부분이지만 MDA 접근법으로 개발하는 모습을 그릴 수 있었으면 하는 바람이다.
예제에서 변환 작업을 수행할 때 아주 중요한 것을 빠뜨렸는데 그것은 바로 QVT를 정의하는 것이다. 앞의 내용들을 이해한 독자들은 변환 정보를 기술하기 위한 표준인 QVT가 어떻게 작성되는지 궁금할 것이고 이번 예제에서 모두 적용해 다뤄졌으면 할 지도 모르겠다. 사실 QVT에 대한 모든 내용과 변환 작업의 테크닉에 대한 내용은 이번 특집의 범위를 벗어난다. 또한 변환 정보 정의 작업은 그 형태가 MDA에서 그리는 이상향 정도로 완성되려면 앞으로 많은 시간이 필요하다. MDA의 변환 작업에 대한 것은 다음에 상세히 알아보고 일단 독자들의 궁금증을 해소시켜 주기 위해 쉽게 해석 가능한 변환 정보 정의 예제 코드를 제시하겠다.
<리스트 1>은 데이터 모델 변환화 작업을 할 때 사용되는 정의이다. 우리는 예제에서 기본적으로 하나의 클래스는 하나의 테이블로 맵핑시킨다고 이야기했다. 이것은 데이터 모델 맵핑 규칙에 대한 정의이다. UML을 SQL로 변환시킨다고 정의했고 UML에 정의된 각 속성을 SQL로 변환하는 모습을 확인할 수 있다.
<리스트 2>와 <리스트 3>은 UML 모델이 EJB로 맵핑할 때 사용되는 정의인데 UML 정의한 오퍼레이션은 EJB의 비즈니스 메쏘드로 변환시키고, UML 오퍼레이션에 사용한 인수들 또한 EJB 비즈니스 메쏘드의 인수로 변환시키겠다는 정의를 하고 있다.
미들웨어컴퍼니(http: //www.middlewarecompany.com/)의 자료를 찾아보면 흥미있는 리포트를 볼 수 있다. 그것은 바로 썬에서 J2EE 아키텍처 적용 예제 시스템의 PetStore 도메인을 갖고 두 개의 개발팀을 조직해, 한 팀은 전통적인 방법으로 개발을 수행하고 다른 팀은 MDA 방식을 적용해 개발을 수행한 후 개발 생산성에 대한 결과를 분석해 놓은 문서이다. 각 팀의 주 단위 개발 현황 리포트도 간략하게 볼 수 있다. 그 결과는 MDA의 승리였다. 전통적인 개발 방식을 선택한 팀은 전체 약 499시간이 소요될 것을 계획해 507.5시간에 개발을 완료했고, MDA 방식을 선택한 팀은 약 442시간이 소요될 것을 계획해 개발을 완료하는 데 330시간이 소요됐다. MDA를 적용한 개발 방식이 10~20% 빠른 개발 생산성을 가져왔다. 두 팀의 멤버들은 모두 EJB 숙련자들이었고 EJB 관련 툴 사용에 익숙한 상태였으나 MDA팀 멤버는 이번에 처음 MDA를 적용해 개발하고 툴을 사용하는 것이기 때문에 기술 습득의 소요 시간을 제외하면 더 나은 생산성을 추출할 수 있다고 한다. MDA를 적용한 모델은 추후 유지보수까지 생각한다면 더 많은 비용을 줄일 수 있을 것이다. 예제의 목적은 단지 빠른 개발에 목표가 맞춰진 개발 생산성의 분석이다. MDA 툴을 통해 만들어진 소스코드는 지저분하고 비효율적인 부분이 여럿 발견됐다고 하는데 이것은 앞으로 시간이 지나면서 개선될 것이다. 컴파일러가 점차 최적화되었던 것처럼 말이다.

MDA 호의 닻은 올라가고

MDA는 이제 막 마지막 결승점을 향한 스타트를 끊었다. 표준화 단체에서는 MDA 구축을 위한 여러 제반 기술들을 개발하고 있고, 모델 변환을 위해 QVT 표준화 작업도 계속 수행중이다. 주요 벤더들은 MDA 툴을 개발하기 시작했으며 올해 말에서 내년 초 정도면 그 모습이 서서히 드러날 것이다. 또한 MDA 방법론도 그 구색이 많이 갖춰지며 MDA 개발 프로세스를 가이드할 것이다. MDA 툴들이 출시되면 현재의 MDA 실현 모습을 물리적인 시야 안에 놓고 바라볼 수 있을 것이며 점차 진화해 소프트웨어 개발의 새로운 패러다임으로 자리잡을 것이다

새로운 IT 패러다임이 등장할 때마다 현기증을 느낀다. 특히 소프트웨어 개발 업계에 막 입문한 사람보다는 나름대로 경험과 노하우를 가지고 있고 실질적으로 새로운 작업을 추진할 만한 위치에 있는 엔지니어일수록 그런 현상이 더욱 심한 것 같다. 국내의 가장 전형적인 SI 업체의 R&D 팀에 소속된 필자의 경우도 꼭 그런 상황이다. 이 글에서는 최근 이슈가 되고 있는 MDA를 필자가 속한 회사가 전문 개발 영역인 ‘인사관리 업무’ 도메인에 도입해, 그것을 조직의 소프트웨어 개발 생산성 향상으로 접목시키는 과정에서 겪었던 그리고 앞으로 겪을 것으로 예상되는 문제점들과 그 해결 방안을 담담히 정리해 본 것이다.

현재 필자가 근무하는 회사에서는 지난 2003년을 전후해서 제대로 만들어진 컴포넌트 혹은 컴포넌트가 아니더라도 무엇인가 실질적인 소프트웨어 생산성을 끌어 올릴만한 묘안이 절실히 필요했다. 2~3년 전만 해도 그 묘안은 CBD 혹은 컴포넌트였고 현재도 그러한 사실에는 변함이 없다. 필자의 조직은 그러한 컴포넌트 패러다임이 이슈로 등장하던 시절의 초기에 나름대로 사활을 걸었다. CBD 사상에 전력투구했던 덕에 지금까지 업계에서 CBD에 관한 기술 선도 업체로서 인정받으면서 영업적으로나 마케팅적으로 그 효과를 보고 있는 것이 사실이었다. 하지만 컴포넌트가 가져다 줄 것이라고 믿었던 본질적인 소프트웨어 생산성 효과보다는 오히려 그 이면에 깔린 마케팅적인 대외 홍보 효과가 더 주효했던 것이 부정할 수 없는 사실이기도 하다. 이 글에서는 CBD 이후에 새롭게 주목받고 있는 MDA를 조직에 접목하게 된 배경을 비롯해 도입하는 과정에서 겪었던 문제들과 이를 해결하기 위해 고심했던 방안을 필자가 속한 R&D 팀을 중심으로 이야기하고자 한다.

MDA 도입 배경

2003년을 전후해서 필자의 회사는 꾸준히 프로젝트를 수주해 그 수가 증가했고 더불어 규모나 기간도 상대적으로 커지고 길어졌다. 어느 회사에서나 그러하듯이 전통적인(?) 대처 방식, 즉 새로운 개발자를 내부 직원으로 충원하거나 임시방편으로 외부 인력을 조달하면서 프로젝트를 진행했다. 하지만 시스템의 개발 납기가 자의반 타의반 연장되면서 그로 인한 기회비용 손실은 말할 것도 없고 회사가 ‘울며 겨자 먹기’ 식으로 어쩔 수 없이 떠안아야 하는 재정적 부담은 이루 말할 수 없었다. 회사의 재정을 관리하는 관리 부서를 중심으로 볼멘소리가 터져 나오기 시작했다. ‘대형 SI 업체들의 프로젝트 저가 수주 전략(?)이라는 육탄 세례 속에서, 이미 탁상공론을 넘어 저 먼 외국 사례로 인용되고 있는 정통부나 과기처의 소프트웨어 개발 단가표는 고사하고, 우리가 무슨 떼돈 벌겠다고 하는 것도 아닌데…’ 근본적인 해결책이 없는 가운데 프로젝트를 계속해서 수주하는 것이 관리부서 입장에서는 기쁜 일만은 아니었다. 사실 이에 대해서는 중소 SI 업체에서 할 말이 많을 것이다. 대형 SI 업체의 프로젝트 저가 수주는 곧 중소 하청 SI 업체가 고스란히 떠안아야 할 부담이 된다는 것은 자명한 사실이다.
실제 현장(site)에서 프로젝트를 수행해 보면 그런 소리 못한다고 현장에서 겪는 고초를 하소연하던 개발팀에서도 점차 자성의 목소리가 흘러 나왔다. 당장 촉박하게 프로젝트를 종료하기 위해 몸부림치던 당시에는 못 느꼈지만 막상 프로젝트를 마무리하고 본사로 철수하거나 다른 현장으로 투입된 초기에 가만히 앉아서 살펴보면, ‘저쪽 고객사에서 요구했던 것이나 이쪽 고객사에서 요구하는 것이나 크게 차이가 나지 않는데 왜 그렇게 프로젝트를 마무리하기 어려웠을까?’ 머리를 갸우뚱거리게 된다. 고객의 요구사항이 수시로 바뀌는 것이야 어제 오늘의 이야기가 아니고 인터넷 기반의 시스템 개발이 보편화되면서 특히 그런 요구사항 변경이 시스템 개발을 어렵게 한다는 것도 이해는 가지만, 어쨌든 SI 업계에서 수행하는 시스템 개발 프로젝트에서의 소프트웨어 생산성 문제는 대형 업체에 비해 중소 업체 입장에서는 사활이 걸린 중대 사안일 수밖에 없다.

MDA 도입 과정

‘Evaluating Software Architecture-Methods and Case Studies’라는 책을 보면 소속 조직에 새로운 기술이나 패러다임을 도입하기(ATAM 기법) 위한 아주 세부적인 전술을 제시하고 있다. ROI 분석에서부터 조직 내에서 동조자를 끌어들이고 의사결정권자를 설득하기 위한 세세한 조언까지 아끼지 않고 있다. 그러한 아이디어를 접목하여 필자의 조직에 MDA를 도입했던 과정을 살펴보기로 한다.

<그림 1> MDA 도입 메커니즘

경영진의 설득

앞선 MDA 도입 배경에서 살펴본 상황으로부터 쉽게 유추할 수 있겠지만 필자의 조직에서는 일단 어떠한 형태로든 돌파구가 필요한 상황이었다. 경영진들 입장에서의 압박감은 그 상황이 더욱 심각하게 고려되었다. MDA 이전에 가장 활발하게 이슈가 되었던 컴포넌트에 관해서는 조직 내부에서조차 그 효용성에 대해 다소 회의적인 시각들이 팽배해 있었다. 이는 곧 IT 업계에서 시기마다 발표되는 패러다임 혹은 기술이라는 것에 대한 부정적인 시각으로 확대 해석되고 있는 상황이었다. 그렇다고 컴포넌트 패러다임을 부정하면서 그것을 대체할 수 있는 패러다임이라고 MDA를 부각시키는 것은 타당성이 없어 보였다. 사실 MDA는 CBD를 대체하는 패러다임이라기보다 오히려 CBD 사상에 근거한 소프트웨어 개발의 단위인 컴포넌트를 보다 컴포넌트답게 시스템 개발 초기에 모델이라는 형태로 만들고 향후에도 그 수준에서 재사용해 보자는 것이 근본 취지였다. 물리적인 실행 파일 수준 컴포넌트 개념에서 모델 수준 컴포넌트 단위로의 형태론적(syntax) 변화일 뿐 컴포넌트의 전면적인 부정은 아니다.
필자는 그러한 사실을 지속적으로 조직 구성원, 특히 조직의 방향성에 대한 결정권을 가지고 있는 경영진들에게 전달하고 그러한 MDA 접근법이 보편화됐을 때 예상할 수 있는 시스템 개발 방식의 변화 등을 설명하려고 노력했다. 그리고 더 현실적인 측면에서 필자의 조직에서 활발하게 활용하고 있는 모 업체의 CASE 도구 속에서 그러한 MDA 사상을 접목시키고자 노력하고 있는 모습, 즉 추가하고 확장하는 기능이나 기술을 예로 들면서 앞으로 MDA가 향후 소프트웨어 산업계의 핵심 메커니즘으로 자리잡아 갈 것을 확신시키려 노력했다.
그 리고 MDA를 통해 획득할 수 있는 소프트웨어 생산성에 대한 참고자료를 소개하는 시간을 많이 갖도록 노력했다. 그 자료 중에 2003년 6월에 발표된 미들웨어 컴퍼니 연구팀에서 발표한 ‘MDA 접근법을 활용한 J2EE 플랫폼 기반의 모델중심 개발에 대한 생산성 분석(Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach-Productivity Analysis)’이나 2004년 1월에 추가로 발표한 ‘MDA 접근법을 활용한 J2EE 플랫폼 기반의 모델 중심 개발에 대한 유지보수성 분석(Model Driven Develo pment for J2EE Utilizing a Model Driven Architecture (MDA) Approach-Maintainability Analysis’ 보고서는 매우 설득력 있는 자료로 활용할 수 있었다.

수행 조직 결정

국내의 영세한 SI 업계 상황을 고려할 때 굳이 MDA가 아니더라도 고객의 명시적인 요구사항으로 제시되거나 모험을 감수해야 하는 신생업체가 아닌 이상, 일반 중소 SI 업체 입장에서는 특정 패러다임이나 기술에 대한 전문가가 부재한 상황에서 지금까지 쌓아온 개발 노하우나 방식을 전면 뒤엎으면서 새로운 패러다임이나 기술을 전면적으로 도입하는 일은 일종의 도박이다. 그것도 당장 법적으로 납기일이 명시된 현장에서 도입한다는 것은 더욱 불가능하다.
R&D 팀의 성격상 당장 고객들에게 무엇인가 보여줘야 하는 개발팀들과는 달리 2~3년 전에는 CBD, 그리고 이번에는 MDA와 같은 새로운 기술 혹은 패러다임을 접하고 그것을 조직의 새로운 패러다임으로 접목할 임무를 수행하기로 결정했다. 그것은 R&D 팀의 특정상 어쩌면 당연한 임무이자 역할이기도 하다. 하지만 관행적으로 SI 업체 R&D 조직의 보편적인 역할은 해당 업체에서 수행하는 여러 프로젝트에서 공통으로 사용하거나 상대적으로 난이도가 있는 모듈 혹은 컴포넌트 개발 및 유지보수를 전담하거나 프로젝트 초기 전반적인 시스템 아키텍처 설계 정도에 한정되는 것이 보통이다. 필자의 R&D 팀이 조직 내에서 수행하는 역할도 그런 R&D 팀의 보편적인 역할과 크게 다르지 않았다. 그러나 그것은 본격적인 작업(?)을 수행하기에는 적합하지 않기 때문에 그러한 문제를 해결하기 위해 내부적으로 R&D 팀 구성원을 추가로 확보하면서 조직 내의 개발팀들을 지원하는 팀과 MDA 기반의 내부 프로젝트를 진행할 팀으로 이원화하는 방식을 채택해 역할을 분담했다.

내/외부 공모자 확보

인사관리 도메인 지식을 갖춘 사람과 새로운 기술을 개척할 수 있는 엔지니어를 중심으로 MDA 관련 자료를 회람하면서 정보를 공유했다. 또한 내부적으로 기술적인 측면에서든 인사업무에서든 어느 한 편에 대한 상대적 경쟁력을 갖춘 역량 있는 인력을 R&D 팀으로 합류시키고, 외부적으로는 필자의 R&D 팀에서 MDA라는 새로운 패러다임에 기꺼이 도전하려는 새로운 인력 충원을 적극 고려했다. 설령 그것이 MDA가 아닌 다른 사상이나 기술이라 할지라도 개인적 신념만으로 일을 추진하기에는 너무나도 험난한 것이 사실이고, 최근의 시스템 개발 문제는 조직 내에서 단순히 능력이 뛰어난 몇 명의 컨설턴트나 엔지니어에 의해 주도적으로 수행되기에는 이미 그 규모나 비중이 커졌다는 사실을 반증하는 것이기도 하다.

개발팀과의 마찰 해소 방안

코드 중심의 개발 방식(code-centric development)에 익숙한 개발자에게 당장 눈앞에 직면한 프로젝트에 대해 반드시 MDA를 적용해서 시스템을 개발하라고 강제한다면 그것은 현장에서 고객들과 씨름해야 하는 개발팀원들은 ‘기름통을 들고 불 속으로 뛰어들어라’는 말과 다르지 않게 느낄 것이다. 그래서 일단 MDA 관련된 R&D의 작업 방향에 대해 관심을 내비치는 엔지니어에게는 그저 앞으로의 소프트웨어 개발 방식은 UML을 보다 적극적으로 활용하는 방식으로 진화할 것이며, 그에 대한 각자 나름대로의 대비가 있어야 한다는 정도로만 이슈로 제시하면서 R&D 팀을 중심으로 그러한 준비를 조직적으로 수행하고 있으며 점차 그러한 작업이 실체화되는 시점에 내부 인력을 대상으로 내부 교육이 진행될 것임을 주지시켰다. 그러한 내용을 굳이 개발팀원에게까지 전파하는 목적은 무엇보다도 향후 조직에서 필요로 하는 엔지니어가 되기 위한 실천방안을 사전에 비전으로 제시함으로써 최소한 UML을 활용해 구축된 모델을 접하게 될 시점에 거부감 없이 쉽게 수용하고 수월하게 전환 교육이 이루어질 수 있도록 채비시키기 위함이었다.

MDA 실현 이슈와 해결

지금까지 필자 조직에서 MDA라는 전략이 결정된 배경과 그 도입 과정을 간단히 살펴보았다. 이제부터는 더 구체적으로 MDA를 수용하고 필자의 조직에서 목적하는 시스템(여기서는 인사관리 시스템 중심으로)에 접목하는 과정에서 발생했고 앞으로 발생할 것으로 예상되는 난제(issue)와 그것을 해결하기 위해 채택한 전술에 대해 살펴보자.

전문 도메인 지식 습득

MDA 기반의 인사관리 시스템 개발을 추진하는 수행 조직으로 결정된 R&D 팀 이전 구성원들의 역량은 기술적인 측면에 비해 상대적으로 인사관리라는 비즈니스 측면에 대한 지식이 부족한 상황이었다. 어떠한 도메인이든 MDA 기반으로 제대로 된 시스템 개발을 위해서는 해당 도메인에 대한 전반적이고 체계적인 지식이 필수적인 상황에서 단지 CASE 도구를 활용한 UML 기반의 모델링이 가능하다는 사실은 그저 ‘무엇(business)’인가를 담을 수 있는 ‘틀(technology)’은 갖췄지만, 막상 담아야 할 ‘내용(business)’이 무엇인지는 모르는 형국에 지나지 않았다. 그렇다고 현재 추진 중인 R&D 팀의 MDA 관련 내부 프로젝트의 성격이 조직 내의 다른 개발팀처럼 특정 고객에게 필요한 인사관리 시스템만을 구축해 주고 나면 그 역할이 마무리되는 상황도 아니었다.
그러한 미비점을 보완하고자 일단 R&D 팀과 현장에서 시스템을 구축 중인 개발팀과의 유기적 정보 교류 네트워크를 구축하였다. 일단 R&D 팀에서는 지금까지 필자의 조직에서 수행한 인사관리 시스템 구축 시 활용되거나 작성한 자료를 수집하고 전사적인 차원에서 공통적으로 참고할만한 관련 자료를 정리 및 통합한 후 다시 그러한 내용을 각 개발팀원이 모두 공유할 수 있도록 시스템을 구축했다. 필요한 시점에 R&D 팀에서 각 사이트에서 진행 중인 프로젝트의 상황을 모니터링하여 필요시에 해당 사이트에 방문하여 추가적인 보완 자료를 수집할 수 있도록 사전에 협조를 요청하였다.
또한 R&D 팀에서 진행하는 인사관리 시스템은 특정 고객사를 대상으로 하는 시스템이 아니기 때문에 개발 현장에서 보편타당하게 수용할 수 있는 제품이어야 하는 특성을 고려해 인사관리에 관한 국내외 표준자료를 수집했다. 그것은 현재 OMG를 중심으로 특정 도메인에 대한 데이터 교환 표준 규약을 XML 기반으로 구축 중인 것과 일맥상통한다. 그러나 아직 OMG에서 명시적으로 인사관리 도메인에 대한 표준화 작업은 미비한 상태였다. 그 와중에 외국의 인사관리 관련 업체들을 주축으로 결성된 HR 컨소시엄에서 제시하는 공개된 자료를 발견했다. 그곳에서 제안하는 XML 기반의 인사 관련 표준 데이터 스키마와 프로세스를 중심으로 보편타당한 인사 시스템의 비즈니스 아키텍처 작성을 진행했다. 국제적으로 인정할만한 표준을 검토해 시스템 개발에 접목하게 된 것은 회사의 장기적인 비전인 국제무대로의 진출을 염두에 둔 것이었다. 명시적인 고객이 존재하지 않는 R&D 팀 관점에서 이것은 일종의 고객 요구사항으로 고려되었다.

제대로 된 UML 지식

간혹 필자는 주변에서 현재 OMG에서 준비 중인 UML 2.0 명세 최종 버전이 확정되고, 각 CASE 도구 벤더들이 본격적으로 UML 2.0을 지원하는 시점부터 MDA 기반의 시스템 개발이 가능하지 않겠느냐는 질문을 받을 때가 있다. 그러나 그것은 MDA 관련 참고할 만한 서적을 한번이라도 읽어 본 사람이라면 사실과 다르다는 것을 금방 알 수 있다. 기왕이면 ‘새로운 포도주(MDA)를 새로운 그릇(UML 2.0)에 담는 것’이 좋기는 하지만 현재 CASE 도구 벤더들이 표준으로 지원하고 있는 UML 1.4(필자가 글을 쓰고 있는 시점에 UML 2.0을 완벽하게 지원하고 있는 CASE 도구는 없다. 특정 벤더에서는 대외적으로 세계 최초의 UML 2.0 CASE 도구라고 선전하고 있지만, 실제 모든 UML 2.0에서 제시하는 모든 표기법과 다이어그램을 지원하지는 않는다. 무엇보다도 UML 2.0 명세는 현재 최종 초안이 공표되고 최종 심의를 거치고 있는 과정이다)에서도 충분히 MDA적인 시스템 개발 접근법이 가능하다. 무엇보다도 대표적인 많은 CASE 도구들이 이미 다양한 형태로 OMG에서 제안하는 MDA 구현 표준에 근거한 확장 메커니즘을 적용하여 CASE 도구에 새로운 기능을 추가하거나 기존의 기능들을 보완하고 있는 상황이다.
UML 2.0이 전제되어야만 MDA식 개발이 가능하다는 오해의 이면을 살펴보면 많은 업체들이 지금까지 표면적으로는 UML이라는 OMG의 모델링 표준에 근거해 분석과 설계 작업을 한다고 했지만, 실질적으로는 완벽한 UML 중심의 작업이었다기 보다는 UML의 일부 간단한 표기법(notation)을 중심으로 개념적이고 피상적인 수준에서 UML을 활용했다는 것을 반증하는 것이다. 그러한 결과 소프트웨어 산업계에 만연되어 있는 ‘시스템 개발 초반의 CBD 컨설팅 따로, 후반의 실질적인 개발 따로’라는 이분법적 고정관념을 엔지니어 머리속에 만들어 냈고, 이는 곧 프로젝트의 전반적인 생산성 저하라는 고질적인 소프트웨어 산업계의 악순환 구조를 양산하고 말았다.
무엇보다도 MDA 기반의 시스템 개발 방식과 지금까지의 코드 중심 개발 방식은 표면적으로는 큰 차이가 없어 보이지만, 그 내면을 들여다보면 혁신적인 패러다임의 전환이 필요하다는 사실을 직감할 수 있다. 소프트웨어 산업계에 MDA 개발 방식이 보편화되기 시작하면 이것은 예전처럼 소위 UML을 통해 어설프게 모델링 작업을 수행하던 사람들에게는 새로운 도전이며 그 동안 UML을 먼 나라 이야기처럼 한쪽 귀로 듣고 한쪽 귀로 흘려 왔던 엔지니어들에게는 가히 극복하기 어려운 도전으로 다가올 것이라 생각한다.
이러한 상황에서 R&D 팀은 내부적으로 이전에 대충 훑어보았던 기존의 UML 1.4 명세의 상급 수준 특징을 좀 더 면밀히 검토하고, 더 정밀한 모델링이 가능하도록 설계 문서간의 연관 관계에 대해 고민하기 시작했다. 특히 앞서 살펴본 인사관리 도메인을 체계적으로 모델링하는 작업에 전념했다. 한편으로는 현재 시중에 나와 있는 MDA 관련 서적을 집중적으로 살펴보고 UML 2.0 초안을 검토하여 기존에 활용하던 UML 1.4와의 차이점과 보강된 내용을 체계적으로 정리하는 작업을 수행했다.

CASE 도구 선정

특정 벤더의 모델링 CASE 도구를 필자 조직의 기본 도구로 선정하는 과정에서는 사실 거의 팀 내에서의 이견은 없었다. 무엇보다도 오랫동안 필자의 회사에서는 여러 프로젝트를 수행하면서 어설프게라도 해당 CASE 도구를 기본으로 활용해 작업했던 까닭에 상대적으로 다른 CASE 도구들에 비해 사용자 저변이 많이 확산되어 있는 상황이었다. 향후 MDA 기반의 시스템 개발이 확산되면 기존의 개발 도구나 각종 CASE 도구들에 상대적으로 모델링 CASE 도구에 대한 종속성이 커지겠지만 그렇다고 기존의 여타 코딩이나 형상관리 등의 작업에 필요한 도구 그리고 운영 플랫폼들과의 연동이나 통합을 고려하지 않을 수 없었다. 그런 관점에서 보더라도 필자의 조직에서 선정한 모델링 CASE 도구는 나름대로 적절한 선택이었고 최소한 필자 조직에서는 가장 자연스러운 최적의 선택이었다.
엔지니어의 도구 친밀도와 기술적인 측면에 덧붙여 해당 CASE 도구 제작 벤더에 대한 시장에서의 고객 선호도를 고려했다. 고객들의 CASE 도구 선정 경향은 일반적인 엔지니어적인 관점에서의 기술 구현 완성도나 기능 등에 국한되지는 않는다. 오히려 수치화가 어려운 고객간의 입 소문이라든지, 고객사의 과거 경험이나 주변인의 권유가 많이 작용하는 것이 현실이다. 고객사의 특별한 제약사항으로 제시되는 경우가 아니라면 프로젝트 초기에 개발업체에서 ‘이러이러한 도구들을 중심으로 개발하겠습니다’라는 식의 도구 제안이 들어가게 된다. 고객들은 앞서 언급한 바와 같이 특별한 상황이 아닌 이상 그러한 제안을 수용하는 것이 일반적이다. 무엇보다도 지금까지의 개발 방식에서는 CASE 도구 특히, 모델링 도구가 큰 비중을 차지하지 않았고 더욱이 국내에서 소프트웨어 개발 환경에서의 모델링 도구 위상이란 그저 요식적인 ‘그림 도구’에 지나지 않게 치부되었습니다. 그것은 곧 고객들이 모델링 도구 선정에 있어 각종 플랫폼 선정 작업에 비해 상대적으로 면밀히 검토하지 않는 원인이 되었다. 그런 현실적인 여건과 상황을 고려하여 필자가 속한 조직에서 선정한 모델링 도구는 도구 제안 시 전반적으로 고객들이 거부감을 느끼지 않을 정도의 도구로 평가될 도구였다.

모델 버전 관리

MDA 기반의 시스템 개발을 추진하게 될 고객 입장에서는 해당 결과물인 각종 모델들과 모델간 변환(transformation)을 위한 메커니즘 구현물(profiles)만을 대상으로 유지보수하는 것으로써 특정 상위 비즈니스 업무가 변경되더라도 상위 모델(PIM) 중심의 수정 작업을 통해 손쉽게 시스템을 재구성하거나 변형할 수 있다. 또한 기존의 형상관리 기법을 그대로 적용하면 손쉽게 조직 내에서 달성해야 할 소프트웨어 생산성 혹은 재사용성이라는 소기의 목적을 달성할 수 있다. 하지만 필자의 조직처럼 특정 업무영역을 특화해 비즈니스 모델 결과물(PIM)을 제작하고, 그것을 다시 재사용하면서 여러 고객 사이트에서 다양하게 변형하거나 커스터마이징 작업을 통해 수익을 창출해야 하는 경우라면 더 복잡한 메커니즘 구현이 필요하다. 이 글을 쓰고 있는 시점을 기준으로 이제 막 MDA를 도입해 시스템 개발을 추진하는 과정 중에 있는 관계로 그에 대한 명쾌한 방안을 제시할 수는 없지만 필자의 조직과 유사한 처지에 있는 상황에서 MDA를 전략적으로 도입하려고 준비하는 조직이라면 반드시 MDA 기반 시스템 개발 초기에서부터 염두에 둬야 할 주요 이슈일 것이다.
지금 현재 그러한 모델의 버전 관리 문제와 관련해서 시스템 설계 시에 고려하는 사안은 일단 인사 도메인에서 단위 비즈니스 프로세스 및 데이터 구조 자체의 비즈니스적인 유연성을 확보하기 위해 단위 업무별 공통성과 가변성을 시스템 설계 초기부터 모델에 반영하고 특정 플랫폼으로의 전환시 해당 변환 규칙에서 불필요한 요소를 아예 전환이 되지 않도록 제어하는 방식으로 고려하고 있다. 바로 SPL (Software Product Lines) 접근법이다. 또한 단위 업무(엄밀히 말하면 단위 업무별 비즈니스 모델)뿐만 아니라 변환 규칙 자체를 형상 아이템(CI: Configuration Item)으로 전환할 것을 염두에 두고 작업을 진행 중이다. 특정 CASE 도구에 종속적일 수도 있겠지만 보다 현실적인 접근법으로써 내부적으로 결정한 CASE 도구에서 제시하는 다양한 형태의 모델 단위 구조와 실제 구현 대상이 되는 인사관리 단위 업무를 매칭시켰다.
특히 필자가 주목하는 사항은 OMG의 MDA 접근법에서 제안하는 프로파일이라는 형태의 변환 규칙의 조직 자산화 문제이다. 즉 기존의 전통적인 개발 방식과는 다르게 메타 데이터를 통해 소스(PIM)를 목적 플랫폼(PSM)으로 변환하는 기술이 궁극적으로는 향후 MDA 기반 개발이 보편화되는 시점에는 필자의 조직과 같은 소프트웨어 개발 및 통합 업체 입장에서는 타사와 차별화될 수 있는 기술력에 대한 실질적인 자산이 될 것이라는 점에 주목하고 있다.

모델 보안 문제

마지막으로 앞선 단락에서 언급한 MDA 기반 기술 개발로 축적되는 모델이라는 새로운 형태의 조직 자산에 대한 보안 문제이다. 가장 중요한 문제이면서도 아직까지 명확한 방안을 생각해내지 못한 이슈이기도 하다. 가령 다른 업계에 비해 상대적으로 IT 업계에서 보편화되어 있는 엔지니어의 잦은 조직 이동 문제를 고려해 보자.
핵심 인력의 이동 문제는 과거에도 그랬고 향후에도 해당 인력의 이전 조직에 결정적인 타격을 줄 것임은 어쩔 수 없다. 하지만 MDA 기반의 개발 방식이 보편화 되는 시점에서의 핵심 인력 유출은 지금의 코드 중심의 개발 방식 시절에 비해 상대적으로 상당한 수준의 기술 자산 유출로 이어질 것임은 너무도 자명하다. 개발 소스나 자료의 보안 관리가 허술하게 이뤄지고 있는 국내 프로젝트 관리 실정을 고려하면 심히 염려되지 않을 수 없다. 가령 코드 중심의 개발 방식에서는 어떤 엔지니어가 이전 직장에서의 프로젝트에서 활용했던 아무리 잘 작성된 소스코드를 가지고 있다고 해도 막상 유사한 새로운 프로젝트에 적용하려면 소스 내부를 수정하지 않고서는 거의 재사용이 불가능한 것이 일반적이다. 반면 MDA 기반의 개발 방식에서는 소스 레벨보다 상위 추상화 수준에서 약간의 수정만으로도 지금까지 상상할 수 없었던 수준의 소프트웨어 재사용이 가능하고 이는 곧 해당 엔지니어의 역량으로 평가될 수 있을 것이기 때문이다.
모델이 아니더라도 기업의 보안 문제는 단순히 기술적으로 해결할 수 있는 문제가 아니라 사회의 제도적인 장치 마련이나 기업 문화의 성숙 등과 같은 복합적인 해결 방안이 강구돼야 할 사안으로 생각된다. 조직의 MDA 모델 자산의 보안 문제는 바로 그러한 맥락에서 그 해결 방안을 고려해야 하고 MDA 도입을 고려하고 있는 조직에서는 반드시 염두에 둬야 할 이슈가 아닐 수 없다.

컴포넌트를 더 컴포넌트답게

국내 IT 업계의 원로격이신 필자가 근무하는 연구소 소장님으로부터 예전의 구조적 프로그래밍이 팽배했던 시절 이야기나 그 원리 그리고 당시의 사회적 분위기에 대해 들으면서 놀라움을 금치 못하곤 한다. 필자의 미천(?)한 경험 탓이기도 하겠지만 이전의 패러다임에 대해 미처 제대로 경험하지 못했던 사실들을 간접적으로나마 이해하면서 점점 확신을 갖게 되는 것이 있다. 바로 구조적 분석 설계 기법(SADT: Structured Analysis & Design Technique)으로부터 시작된 정보 기술 패러다임의 변천사는 이전의 패러다임을 뒤엎는 ‘혁명(revolution)이 아니고 진화(evolution)’였다는 사실이다.
국 내 IT 업계의 문제는 이전의 패러다임에 익숙한 엔지니어들이 새로운 패러다임에 대해 피상적인 용어나 개념 정도 살펴본 것을 전부인 양 착각하게 된다. 또한 새로운 패러다임에 편승하거나 가장하다가 또 다른 새로운 패러다임이 등장하면 그 패러다임에 너무 쉽게 편승한다면 이는 뿌리 없는 기회주의(?)가 아닐까 싶다. 혹자는 MDA가 CBD를 대체하는 또 다른 유행 혹은 패러다임이라고 주장하기도 하지만 MDA는 분명히 CBD를 전제로 하면서 SPL이나 SOA (Service-Oriented Architecture) 등과 같은 동시대의 다른 패러다임들과 더불어 CBD를 엄밀히 말하면 ‘컴포넌트를 더 컴포넌트답게’ 혹은 제대로 된 컴포넌트를 만들려고 노력하는 이 시대의 선도 엔지니어들이 합의해 제시하는 미래 소프트웨어 산업계의 비전이다. MDA 개발 패러다임으로의 전환이 IT 업계 특히 소프트웨어 산업계에 가져올 가장 큰 후폭풍은 단순한 개발 방식의 변화가 아니라 전반적인 프로젝트 수행 조직의 역할 변화와 시스템 자산에 대한 인식 전환일 것이다.
마지막으로 OMG의 MDA 작업에 깊이 관여했던 전문가 중의 한 사람인 데이비드 프랑켈(David S. Frankel)의 의미심장한 비유를 소개하면서 이 글을 마무리하고자 한다. 그는 저서 ‘Model Driven Architecture-Applying MDA to Enterprise Computing’에서 데이비드는 MDA에 대해 현재 많은 엔지니어들이나 일반인들이 보이는 회의적인 시각을, 예전에 0과 1의 조합으로 작성하는 머신 코드로 프로그램을 작성하던(Machine-centric computing) 것이 일반적이었고 당시에는 혁신적인 어셈블러가 제안됐던 시절에 비유하고 있다. 당시에 많은 엔지니어들은 ‘어떻게 어셈블러와 같은 고급 언어로 프로그램을 작성할 수 있느냐’ 혹은 ‘엔지니어들은 절대 어셈블러를 개발 언어로 받아들일 수 없을 것이다. 프로그램을 제대로 작성하려면 머신 코드로 작성해야지…’라며 어셈블러에 크게 주목하지 않았다.
그러나 어셈블러는 엄연히 당대를 주름잡는 개발 언어로서 소프트웨어 공학사에 큰 족적을 남겼다. 세월이 흘러 인터넷 기반 시스템 개발이 보편화되고 있는 요즘 만약 여러분의 주변에 있는 어떤 엔지니어가 지금은 거의 특정 분야에서만 한정적으로 사용하고 있는 어셈블러를 가지고 고객관리(CRM) 시스템과 같은 인터넷 기반의 복잡한 업무 처리 시스템을 개발하겠다고 한다면 여러분은 과연 그 엔지니어에게 뭐라고 할 것인가? 데이비드는 주저 없이 그 답변에 대해 ‘제 정신 아니네’라고 단정하고 있다.

플라톤에 의하면 모든 존재는 이상과 본질의 영역인 이데아와 이데아를 모방한 현상, 현상을 모방한 가상(시뮬라크르)의 3단계 인식 전이를 말하고 있다. 우리가 상대하는 실체(여기선 MDA)의 인식 수준이 어느 단계에 있느냐에 따라 제대로 실체를 사용할 수 있을 것이다. 여기서는 실체에 대한 다각적 접근과 우리의 숙제에 대해 고민해 보겠다.

소프트웨어 발전 방향을 미리 예견하기는 무모하거나 용감한 작업이 될 수 있다. 선배의 말을 빌리자면 차세대 채택되는 패러다임을 예측하기란 현재 학계나 커뮤니티에서 논의되고 있는 패러다임들을 제비로 접어서 통에 넣어 흔든 후 하나를 뽑는 것과 같다고 한다. 그만큼 장담하기 힘들고 어려운 부분이다. 하지만 그것은 학계에서 발표되는 패러다임 101 버전의 얘기이지(이번 특집의 주제인 MDA만 하더라도 3년 전에 발표된 내용이다) 실제 산업에서 사용할 수 있는 수준의 차세대 패러다임을 점친다는 것은 메이저 벤더들의 제품 비전만 보더라도 쉽게 알 수 있다(대형 벤더들이 그런 고민은 다 해준다). 물론 ‘시장에서 채택될 것인가?’ 하는 아주 복잡하고 우연적인 변수를 제거했을 때 말이다. 또 다른 방법이 있다 약간의 추리력과 예지력이 필요한데 과거 소프트웨어가 어떻게 발전되었는지 흐름을 잡고 미래를 예측해보는 것이다. 이 방법은 ’메이저 벤더들의 제품 비전’ 보다 앞서 미래를 점쳐볼 수 있다.
MDA의 목적과 실체를 살펴보기 위해 OMG에서 꾸준히 추진해온 OMA(Object Manage ment Architecture)를 살펴보는 것은 도움이 된다. 결국 MDA는 OMG의 주력 표준인 UML과 OMA를 조합해 탄생한 총아이기 때문이다. 또한 MDA를 통해 얻고자 하는 것이 무엇인지, 그리고 다른 ‘제비’들과는 어떻게 다른지를 살펴보는 것은 흥미롭다. 자, 그럼 OMA를 통해 엔터프라이즈 소프트웨어가 어떤 것들을 어떻게 정복하며 발전했는지 살펴보자. 여기서 관전 포인트는 소프트웨어 재사용 단위, 형태를 기준으로 하는 것이 적당하겠다. 그리고 이 재사용성은 표준 혹은 규약으로 형상화된다.

OMA에서 MDA로

라이트 형제가 만든 플라이어호는 F-16 전투기와 너무도 다르다. 과거의 비행기에 비해 현재의 비행기는 너무 강력하고 많은 기능들이 추가되었다. F-16 전투기는 플라이어호부터 F-16 전투기 이전 버전까지의 결과물이다. 즉 F-16 전투기를 이해하기 위해 이전 버전들의 발전 과정을 추적해 보면 아주 잘 이해할 수 있다. OMA와 MDA의 관계가 그렇다.
OMA는 크게 분산 객체 명세와 객체간 원격 호출의 신뢰성, 상호운용성, 이식성 등을 보장하는 ORB가 그 핵심에 있다. ORB를 통해 객체(컴포넌트, 서비스 등으로 대치시켜도 무방하다)를 배포할 수 있었고 배포된 객체는 실행 환경에서 (재)사용된다(객체 표준/규약). 분산객체에 원격호출이 요청되면 그 객체가 가지는 비즈니스를 실행하게 된다. 엔터프라이즈 시스템에서의 비즈니스는 상당히 복잡한 처리과정을 갖는다. 네이밍 서비스를 통해(J2EE에서 JNDI) 타 서비스를 찾아 비즈니스를 연동하기도 하며 트랜잭션 서비스를 통해(J2EE에서 JTS or MTS, TP Monitor) 트랜잭션 처리를 위임하기도 한다. 또한 이벤트/Notification 서비스를 통해(J2EE에서 JMS or IBM MQ Series) 메시징 처리 및 EAI를 위임하는 것 이외에(데이터베이스) 쿼리, 보안, 라이선싱, 객체 저장 등의 서비스를 사용한다. 이런 각 코바 서비스는 비즈니스 처리를 위해 기술적 난점들을 재사용 가능하게 한다. 과거에 이 서비스들을 미들웨어라 불렀다(미들웨어 표준/규약).

<그림 1> OMA 아키텍처 1


객 체 표준과 객체간의 통신의 문제도 각종 기술적인 문제도 점령됐다. 이제 비즈니스 처리에 전념할 수 있다. OMA에서는 비즈니스 처리에 도움을 주는 편의 기능인 퍼실리티(CORBA Facility)를 준비하고 있다. 퍼실리티는 특정 도메인(금융권, 국방, 행정, 모바일)에서 자주 쓰이는 수직적(vertical) 퍼실리티와 소프트웨어 개발시에 일반적으로 사용할 수 있는(데이터 압축, 룰 처리, 워크플로우 처리, 컬렉션 등) 수평적(horizontal) 퍼실리티가 있다. 이로써 개발자들은 일반적으로 사용하는 수평적 편의 기능들과 현재 산업 도메인의 표준으로 정의된 모델인 수직적 편의 기능을 조합해 자신의 애플리케이션에 맞게 최적화, 특화해 개발하게 된다. 물론 도메인 퍼실리티는 CORBA 퍼실리티 프로바이더에 의해 제공된다. 그리고 이를 바탕으로 <그림 2>의 도메인(객체)이 형상화, 정규화된다(레이어가 연상되지 않는가?). CORBA 도메인은 금융권부터 국방, 통신에 이르기까지 상당히 광범위하게 정의되어 있으며 다루고 있는 영역도 상당히 정밀하다. 사실 이 도메인이나 퍼실리티는 해당 분야의 기술자들이 오랜 경험을 통해 축적된 지식과 노하우를 통해 연구하여 설계한 모델이다(산업 도메인 표준/규약).
OMA 아키텍처는 이렇게 가장 기본이 되는 것부터(밑에서부터) 하나씩 표준화 작업을 수행했으며 이 표준화된 규약에 맞춰 개발된 COTS를 이용해 좀 더 검증되고 안정된 플랫폼을 제공하려는 비전을 갖는다. 표준화 작업으로 점령하는 과정은 가장 근본적이고 재사용성이 강한 대상부터 시작한다(ORB -> Service -> Facility). 그리고 그 종국에는 도메인이 있다. 도메인은 해당 도메인에 가장 안정적인 아키텍처, 통신 프로토콜, 자료구조(경우에 따라서 데이터베이스 논리 테이블(Logical Data Model)까지) 등을 제시하고 있다. 따라서 개발자는 먼저 이미 벤더에 의해 제공되는 도메인을 도입하여 자신의 시스템에 맞게 애플리케이션을 최적화 시키고, 도메인이 제공하지 않는 자신의 시스템에 특화된 부분만 개발하는 작업으로 업무를 단순화할 수 있다.
그렇다면 왜 OMA 브레인들을 포함하여 다른 표준화 기관에서는 표준과 계약하고 싶어할까? 계약은 ‘계약에 의한 설계(Design by Contract)’를 통해 각 이해 당사자들이 상대방에 대한 서비스 제공과 같은 책임과 의무를 기술함으로써 대상에 대한 ‘How’가 아닌 ‘What’에 집중하게 한다. 표준은 반복해서 재사용할 수 있는 대상에 대한 ‘계약’으로서 지식과 경험에 대한 결과를 공유하려는 목적을 갖는다. 이를 통해 상호운영성, 통합, 연동의 문제에서 자유로울 수 있다. 그렇다면 OMA와 MDA가 어떤 연관관계가 있을까? <그림 2>에서 분류된 도메인 오브젝트와 <그림 3>에서 MDA의 화살표로 지시되는 수직적 도메인과 매우 일치하지 않는가? <그림 2>의 도메인 오브젝트는 OMA 도메인 오브젝트 중 그림 구성상 일부만 표현한 것이다. 마치 OMA의 도메인 오브젝트들을 MDA 마지막 레이어에 감싸놓은 것 같다. OMA의 경우 IDL(Interface Definition Language)로 도메인 오브젝트들을 정의한 반면 MDA는 모델로 대체하고 있다. 물론 이 연관 관계에는 OMG의 다른 표준인 MOF나 UML 등의 내용은 차치한다. MDA의 목표는 OMA의 그것과 다르지 않다. 개발을 위한 최대한의 플랫폼을 준비해 놓고 각 도메인 전문가들이 완성한 표준 모델들을 제공하여 개발에 필요한 최대한의 생산성을 극대화시킨다. MDA는 이제 CORBA만을 고집하지 않고 J2EE, 닷넷, 웹 서비스 등 다른 플랫폼을 아키텍처에 포함시켰다. 그러므로 OMA에서의 개발 프로세스와 매우 유사한 방법으로 개발 가능하다. 즉 MDA 산업 도메인 모델을 기반으로 현 시스템이 필요한 모델들을 추출한 후, 최적화시킬 부분을 커스터마이징한다. 끝으로 도메인 모델에 표현되지 않은 특화시켜 추가 개발해야 할 모델들을 모델링하므로 PIM을 완성한다. 다음 MDA 프로세스에 따라 PSM으로 모델 전이(Model Transform)를 하고 해당 플랫폼에 대한 소스코드를 생성한다. PIM → PSM → Code로의 전이는 매우 훌륭하지만(이 전이 과정은 일반적 방법론과 매우 잘 일치한다. 박스 기사 참조) 또 하나 상기해야 할 부분은 나와 똑같은 도메인 선배 전문가의 경험과 지식으로 표준화된 도메인 모델들을 잊지 않아야 할 일이다.

<그림 2> OMA 이키텍처 2


<그림 3> Model Driven Architecture

SOA 시대의 도래

엔터프라이즈 시장에서 소프트웨어 기술 추이는 분산객체(CORBA) → CBD 플랫폼(J2EE, 닷넷) → SOA로 흐르고 있다. 특징을 비교하면 재사용성이 높고 실세계적 체계를 갖는 객체지향 단위의 오브젝트에서 좀 더 굵은 입자(coarse grained)를 갖고 객체간의 상호작용을 더욱 느슨하게(loosely coupled) 하여 변경관리가 용이할 수 있는 컴포넌트가 대세가 된다. 그렇다면 컴포넌트와 서비스와는 어떤 차이가 있을까? 좀 더 구체적으로 J2EE에 배포되어 ‘서비스 되는’ 빈과 SOA(Service Oriented Architecture)의 서비스와는 어떤 차이가 있을까? SOA는 CORBA 오브젝트와 EJB를 서비스의 한 형태로 보고 있다. 단지 차이라면 그 자체가 아니라 동작되는 운용방식과 세계관에 있다. 결론만 말하면 비즈니스적이고 느슨한 관계를 가져 환경 통합이 용이하다.
웹 서비스와의 관계는 어떠한가. SOA와 웹 서비스와의 관계는 마치 애자일 방법론과 XP의 관계와 유사하다. SOA의 한 실체가 웹 서비스이고 웹 서비스는 SOA 아키텍처를 따른다. 웹 서비스와 SOA의 차별성과 개연성을 놓고 논란이 있지만 일반적인 관계는 이렇다. 즉 필자에게 객체와 컴포넌트, SOA의 차이를 규정하라고 한다면 그 기준을 크기(granularity)에 따른 책임에 두고 설명하고 싶다(단지 필자의 접근법이다). 객체는 기존에 알고리즘과 자료구조를 분리해서 다뤘던 프로그래밍 패러다임에서 실제 행위와 상태를 갖으므로 그 대상의 책임이보다 분명하게 정의할 수 있었다. 객체가 알고리즘과 자료구조를 추상화(facade) 한다. 하지만 객체간의 복잡한 관계들은 관리적 측면에선 단점이 된다. 컴포넌트는 좀 더 큰 범위에서 인터페이스를 통해 실제 사용하는 기능에 집중할 수 있게 한다. 컴포넌트가 객체들을 추상화한다. 서비스는 컴포넌트의 처리를 비즈니스 단위로 묶어 작업 단위를 상위 레벨에서 캡슐화해 접근하게 한다. 서비스가 컴포넌트을 추상화한다.
그러므로 사용자는 소비자로서 더욱 자신의 비즈니스 흐름에 집중할 수 있고 필요에 의해 비즈니스 흐름에 필요한 서비스를 선택하게 한다. <그림 4>는 SOA의 큰 범위에 등장하는 아키텍처적 레이어이다. 애플리케이션 아키텍처는 하나 이상의 서비스 공급자로부터 제공되는 서비스들을 찾아 비즈니스 프로세스 속으로 각 서비스들을 통합한다. 서비스 아키텍처는 실제 서비스를 처리하는 컴포넌트 아키텍처와 소비자 사이에 브릿지 역할을 함으로써 서비스를 위한 연동, 처리 관계, 상태 등을 관리해준다. 컴포넌트 아키텍처는 실제 서비스 구현을 담당하며 레거시 시스템이 좋은 후보가 될 수 있다. 이런 기반 구조에서 다음과 같은 효과를 얻을 수 있다.

◆ 프로세스 중심

◆ 플랫폼 독립적 애플리케이션 통합

◆ 느슨하게 결합된 메시지 지향

◆ 메시지 및 프로세스 상태 관리

<그림 4> SOQ의 3계층 아키텍처


SOA 의 기본 세계관은 이미 개발된 각 기업의 컴포넌트들을 통합하기 위해 규격화·일반화한 서비스 컴포넌트를 상호운용할 수 있도록 함으로서 개발자가 중복 개발하는 것을 지양하는 것이다. 즉 네이버에서 개발된 블로그를 엠파스에서 똑같은 작업을 반복할 필요없이 네이버 블로그 ‘서비스’를 사용한다면 개발자의 노동력을 1/n배 감소할 수 있을 거라는 가설이다. 하지만 SOA는 이처럼 단순하지만은 않다. SOA는 보다 비즈니스 프로세스 관점에서 접근한다. 비즈니스 프로세스적 접근이란 마치 C 언어에서 main 함수를 시초로 다른 함수들을 호출해 프로그램이 진행되듯이 소비자가 각 서비스를 이용해 하나의 비즈니스 프로세스를 수행하는 방식을 말한다. 물론 하나의 서비스는 독립성을 갖지만 서비스는 상호 이용할 수 있으며 하나의 비즈니스 서비스는 서비스들의 조합으로 완성된다. 이를테면 <그림 5>에 표현된대로 ‘항공권 구매’란 비즈니스 서비스는 컴포넌트의 복잡한 조합에서 작업 흐름(프로세스)에 따라 호출되는 서비스들의 집합으로 관계를 단순화시킬 수 있다(인터페이스 중심의 패러다임에서 프로세스 중심으로의 패러다임 전이). SOA가 행운의 ‘제비’가 된다면 개발자는 서비스 마켓 플레이스에 진열된 양질의 서비스를 선택해 비즈니스 프로세스의 구성요소들을 구매한다. 만약 원하는 서비스가 없다면 개발해 구성 서비스에 추가시킨 후 서비스로 제공하게 될 것이다.
여 기서 또 하나의 기대효과를 얻을 수 있다. 이렇게 서비스들이 빌트인 된 상황에서 각 서비스들의 상호작용을 마치 UML 시퀀스 모델링하듯이 비즈니스 프로세스 수행 시나리오를 작성하게 된다는 것이다. 웹 서비스의 WSFL(Web Service Flow Language)과 WSCL (Web Service Composition Language)이 이런 역할을 한다. 유사 기술은 BPM의 BPML(Business Process Modeling Language), 마이크로소프트의 XLANG가 있다.

<그림 5> SOA의 프로세스 중심적 서비스 조합의 예

디자인 완전정복, 패턴언어

필자는 본지에서 지난 2003년 3월부터 3회에 걸쳐 분산 프레임워크에서의 패턴 언어를 소개한 바 있다. 패턴의 대부분의 패러다임은 패턴의 아버지인 건축학자 알렉산더로부터 제안된다. 바꿔 말하면 알렉산더와 그의 연구소는 패턴이란 종교의 메카격이 된다. 알렉산더는 1987년 ‘A Pattern Language’란 책을 통해 ‘유기적 건축양식’이란 패턴이론을 소개했다. 소프트웨어에서도 거의 유사하게 ‘패턴언어’란 패러다임은 적용된다. 패턴언어에서의 패턴은 독립적으로 존재하지 않고(“No Pattern is an Island”) 패턴간의 조밀한 응집도를 구성할수록 그 마법과 위력은 막강해진다(“a dense composition of patterns”).
기존의 Pattern Vocabulary, Pattern System의 패러다임과는 달리 패턴언어는 도메인에 종속적인 성격을 갖는다. 즉 MDA에서 수직적/수평적 도메인이 모두 디자인 차원에서 언어화(Pattern Language)될 수 있는 대상이 된다. 하나의 도메인은 하나의 언어가 된다. 왜 도메인을 언어란 개념으로 다루고 있을까? 초기 GoF 패턴 개념은 패턴 용어집(Pattern Vocabulary)의 패러다임이었다. 사람은 정확하고 확실한 의사소통을 위해 잘 정의된 용어집이 필요하고 이 용어집의 어휘가 많을수록 의사전달자로서 유리한 자산을 확보한 셈이 된다. 디자인 패턴에서 하나의 어휘는 하나의 패턴에 해당한다. GoF의 패턴으로 설계 문제를 해결하는 방식은 문제영역(패턴의 목적과 동기)을 기준으로 패턴의 목록을 살핀 후 가장 적합한 패턴을 선택해 적용하는 방식이다. 이때까지 패턴간의 응집도는 상당히 일반적이며 그 밀도는 낮았다. 패턴언어의 개념에서는 좀 더 축적된 용어들을 체계화해 하나의 언어 영역을 구성한다고 본다. 따라서 하나의 도메인을 이해하기 위해서는 그 도메인을 구성하는 언어체계(그 도메인의 패턴과 패턴간의 관계)를 이해하는 것이 필요하며 이 언어체계를 잘 이해할수록 그 도메인의 문제영역 풀이가 쉬워진다.
그렇다면 도메인에서 패턴간의 응집도는 어떻게 구성될까? 일반적으로 그 도메인의 문제영역이나 아키텍처 구성을 기준으로 패턴간의 응집도가 구성된다. <그림 6>의 J2EE 패턴 언어를 보자. J2EE는 크게 presentation, business, integration tier로 구성된다. 처음 클라이언트로부터 HTTP 요청이 들어오면 Decorating Filter 패턴은 HTTP 요청정보를 분해, 수집(필터링) 한다. 그 후 Front Controller 패턴은 사용자 인증이나 로깅 같은 공통적인 처리를 하고 View Helper 패턴에게 다음 처리를 위임한다. View Helper는 서블릿 처리와 뷰에 관한 처리를 분리시키며 Business Tier의 Business Delegate 패턴으로 처리를 위임한다. Business Delegate 패턴은 서비스 컴포넌트의 복잡한 구조를 은닉하고 실제 비즈니스 처리를 담당하는 Session Fa ade 패턴으로 처리를 위임한다. Session Fa ade 패턴은 비즈니스 처리를 하면서 DB 접속을 시도할 경우 Integration Tier의 Data Access Object 패턴을 사용하므로 클라이언트 요청을 처리한다. 이렇게 패턴간의 응집도를 통해 처리의 전이가 발생하며 각 패턴은 해당되는 레이어의 문제들을 하나씩 해결한다.

<그림 6> J2EE 패턴언어


이 때 각 패턴들은 서로를 이용하기도 하고 같은 목적을 갖는 패턴들과 서로 경쟁하기도 한다. 또한 아키텍처 패턴과 디자인 패턴, 구현 패턴간의 계층적 포함 관계도 갖는다. 이렇게 패턴언어는 해당 도메인의 문제를 해결할 수 있는 여러 모델들을 제공하고 있다. 패턴언어에서 문제영역 해결방식은 개발자가 자신의 문제영역에 가장 적합한 패턴들의 집합을 조합하여 패턴의 구현 방식에 따라 시스템을 구성하면 된다. 즉 패턴언어의 프로세스는 이렇다. 첫째 개발자는 해당 도메인의 패턴언어를 살펴본 후 개발에 필요한 패턴 집합을 선택한다. 둘째, 선택된 패턴들을 구현한다. 셋째, 패턴으로 채워지지 않은 문제영역들을 구현한다. 패턴언어에서 재사용 자산은 도메인 개발자의 디자인 경험과 지식이고 그 결과물은 MDA에서의 모델과 다르게 패턴으로 형상화된다.

MDA, SOA, 패턴언어

눈치 빠른 독자라면 MDA, SOA, 패턴언어간의 유사성을 느꼈을 것이다. 이 세 기술은 각 공통적으로 축적 가능한 지적 자산을 최대한 모으고 축적된 자산들을 일정한 틀에 의해 배치시키고 저마다 하나의 문제영역을 해결하기 위한 최대한의 준비를 빌트인 하고 있다. 사용자의 몫은 이들을 잘 선택하고 조합해 이용할 수 있는 가치들을 최대한 획득하는 것이다.
MDA는 도메인 모델을 제공하고 모델을 재사용하게함으로서 모델을 통한 재사용성의 극대화를 추구한다. SOA는 서비스 형태를 갖는 이미 개발되어 컴포넌트들을 통합하여 하나의 비즈니스를 완성한다. 패턴언어에서는 하나의 도메인을 나타내는 패턴들의 조합들 중에 자신이 필요한 패턴의 집합을 선택해 시스템의 디자인을 구성한다. 하지만 이들의 사용 형태가 다른 만큼 이들이 채택한 기술도 차이가 있다. MDA는 Executable UML, CWM, OCL 등을 통해 모델을 정의하고, 정의된 모델들을 QVT(Query, View, and Transformations)함으로서 구현을 완성한다. SOA는 웹 서비스를 기준으로 XML을 십분 활용해 통신을 위한 프로토콜을 SOAP으로 채택하고 WSDL을 통해 서비스 명세를 하고 UDDI를 통해 서비스의 생성, 기술, 발견, 통합을 가능하게 한다. 또한 이렇게 갖춰진 환경들을 WSFL이나 WSCL을 통해 비즈니스 차원에서 워크플로우 개념으로 조합한다. 패턴언어의 경우는 좀 불행하다. 패턴의 구성 원리와 패러다임만 있을 뿐이지 기술적인 실체가 없다.
해당 도메인의 지적 자산을 모으기 위해서는 튼튼한 아키텍처와 표준이 필요하다. MDA는 도메인과 플랫폼, 이들을 유기적으로 엮을 수 있는 MOF, CWM, UML 같은 기술로 모델에서 실행 가능한 코드로의 전이를 보장하고 있다. 즉 모델링을 기반으로 한 프로세스적인 측면이 강하다. 또한 각 도메인별로 수직적인 도메인 모델들을 포진시킨다. SOA의 경우는 서비스를 독립적이고 서로간의 느슨한 결합도를 유도하는 시스템 배치, 구성, 효과적인 사용 방법에 주안점을 두고 아키텍처를 만들었다. 패턴언어의 경우 패턴언어 자체가 아키텍처를 유도하고 있다. 그러므로 MDA, SOA는 엔터프라이즈 시스템 구축에 보다 적합하며 패턴언어는 프레임워크나 자체 솔루션을 구축하기에 적합하다. 이것이 패턴이 크게 뜨지 못하는 장애요인 중에 하나이다.
끝으로 각 기술들이 꿈꾸는 유토피아는 어떤 것일까? MDA는 소프트웨어의 모든 모델들이 MDA를 통해 만들어져서 모든 마켓 플레이스에 MDA 모델들이 진열되길 바랄 것이다. SOA의 비전은 개발을 원하는 모든 컴포넌트들이 서비스화되어 컴포넌트 조합으로 프로젝트가 끝나버리는 모든 마켓플레이스에 서비스가 진열되는 세상을 목적할 것이다. 패턴언어의 경우는 어떠한가? 패턴으로 표현할 수 있는 모든 디자인의 문제들이 패턴언어로 점령되기를 바랄 것이다. 그리고 이를 통해 좀 더 실체적인 프레임워크나 플랫폼으로 구체화되길 바랄 것이다.

우리의 과제

바스티유는 무너져도 앙시앙 레짐은 무너지지 않았다.

필자가 C 프로그램을 익히고 자바 프로그래밍을 막 배울 때의 일이다. 필자의 코드를 본 선배가 ‘C-tic한 자바프로그래밍’이라고 놀리던 일이 기억난다. 구조적 습관과 접근법을 아직 벗어나지 못한 상태에서 객체지향 프로그래밍을 하니 당연히 자바로 구조적 프로그래밍을 할 수 밖에 없다. ‘C-tic한 프로그래밍?’ 그때 필자의 코드들은 문법은 자바를 사용하지만 구성과 형식은 C 언어였다. 무엇이 문제였을까? 객체지향 언어를 사용하지만 구조적 프로그래밍이란 세계관을 버리지 못했던 탓이 컸다. ‘바스티유는 무너져도 앙시앙 레짐은 무너지지 않았다.’ 프랑스 혁명의 성공으로 봉건제도의 진원지인 바스티유를 함락시켰지만 앙시앙 레짐(old regime:구체제)의 습속은 여전히 남아있는 현상을 보고 한 지식인이 한 말이다. 우리는 새로운 패러다임을 접할 때 그 패러다임이 원하는 세계관은 무시한 채 그 패러다임의 용법에만 관심을 갖는 경우가 많다. 마치 필자의 ‘C-tic한 자바프로그래밍’의 경우처럼… ‘새 술을 새 부대에 담으라’는 말이 있다. 진정으로 체화되어 그 패러다임을 십분 활용하기 위해서는 그 패러다임이 원하는 방식과 접근법을 따라야 한다. 요즘 많이 거론되는 ‘내재적 접근법’으로 MDA란 새 기술을 대하는 태도가 필요하다.
세계관과 더불어 문화를 바꿔야 한다. XP를 도입하는 조직이 힘든 이유는 XP의 기민하게 상호작용해야 하는 참여자간의 문화를 바꾸기 힘들기 때문이다. 특히 MDA처럼 개발 단계가 극도로 축소되는 프로세스를 따르는 경우는 개발 참여자의 역할이 크게 구조조정된다. 즉 MDA는 개발 조직 체계를 바꾼다. MDA를 도입한 프로젝트에서 구성원의 시스템을 문화적인 부분까지 고려하여 바꾸지 않는다면 성공을 담보하기 힘들다.

Learning Curve를 고려해야…

하나의 기술을 프로젝트에 적용하기 까지 우리는 충분히 준비하지 못한 상태에서 프로젝트에 투입되곤 한다. 마치 소총 격발법 한번 읽어보고 전쟁터에 나간다고 비유하면 억지일까? 조금 여유있는 프로젝트의 경우 그 제품에 대한 교육도 받고, 파일럿도 하고 충분히 숙련과정을 거친 상태에서 제품 컨설턴트까지 대동하여 프로젝트에 투입하는 경우도 있다. 하지만 대부분의 경우는 이렇게 행복하지 않다. 짧은 시간 안에 스파이크 솔루션을 해보고 예제 실습 및 약간의 테스트를 거치고 곧바로 프로젝트에 적용한다. 필자의 동료는 더 고약한 경우를 당했다. PHP 프로젝트에 투입됐는데 두꺼운 PHP 책을 한권 주고 하루의 여유를 주더니 다음날부터 바로 코딩을 시켰다고 한다. 당연히 제대로 프로젝트가 끝날 수 없다. 이정도 되면 ‘내재적 접근법’은 아예 시도조차 못한다.
MDA는 모델링을 통해 프로세스 전반을 아우르는 상당히 거대한 범위를 다루고 있다. 따라서 학습해야 할 부분도 상당히 많다. 이를테면 PIM을 시스템 독립적으로 설계해야 하는 기술과 PIM에서 PSM으로 전이시키기 위해 고려·설정해줘야 하는 것들 타겟 플랫폼에 대한 이해·실행 가능한 코드를 생성할 때 코드 최적화를 위해 고려해야 하는 사항, 이후 테스트, 산출물 작업에 이르기 까지 알아야 할 것도 많고 배워야 할 것도 많다.
그러므로 현재 프로젝트 성공을 위해, 그리고 성공적일 다음의 MDA 프로젝트를 위해 체계적이고 전략적인 학습과정이 필요하다. 바쁘고 촉박한 프로젝트 환경에서 프로젝트 성공을 위한 충분한 학습을 하자는 것이 아니다. (물론 가장 바람직한 경우겠지만) 프로젝트를 통해 학습할 수 있는 기회를 가능한 만들어 다음 프로젝트에서는 좀 더 숙련된 기술을 보유하려는 노력, 함부로 사용하려 하지 않는 노력이 필요하다. ‘운전은 한다. 차는 모른다’라는 광고 카피가 있었다. ‘MDA를 프로젝트에 적용시켰다. MDA는 잘 모르겠다’ 엔지니어인 우리에게 적용되기엔 너무 곤란한 경우이다.

적용을 위한 타당성, 적합성 검증 우선

좀 규모가 큰 프로젝트에서는 ‘단지 이 기술이 대세’이기 때문에 사용하려는 경우가 많다. 물론 대부분의 개발자들은 이런 기술, 플랫폼, 운용환경 선택의 의사결정 기회가 없지만 필자가 보아온 몇 가지 J2EE 프로젝트는 ‘Apache + Tomcat’만으로도 충분히 괜찮은 플랫폼인데 J2EE란 트랜드를 따라 무겁고 비싼 J2EE를 이용한다. MDA가 담당할 수 있는 영역은 상당히 광범위하다. 임베디드 시스템에서 국방, 금융권에 이르기까지 MDA로 못하는 것이 없다고 봐도 무방하다. 하지만 잊지 말아야 할 질문이 있는데, MDA가 현재 프로젝트를 위해 필요조건을 만족하는가, 충분조건을 만족하는가이다. 타당성이 확인되지 않은 기술을 사용하는 프로젝트는 개발자의 목적의식을 절감시키는 요인이 된다.
필자가 소개한 기술들은 소프트웨어 진화에 일익을 할 것이다. 그러므로 대세에 발맞추는 것도 개발자로서 좋은 태도이다. 하지만 조금 약아 보이더라도 실용적 입장을 취하는 것은 나쁘지 않다. 끝으로 MDA가 꼭 뽑히는 ‘제비’가 되기를 개인적으로 바란다.

[ 전형적인 방법론 접근법이 이입된 MDA ]

전형적인 방법론에서의 모델링 순서는 ‘비즈니스 모델 → 유즈케이스 모델 → 분석 모델 → 설계 모델 → 구현 모델’ 단계로 구체화된다. 유즈케이스 모델은 시스템 요구사항을 도출하기 위한 모델이므로 일반적인 시스템을 추상화, 개념화 작업과 거리가 있기 때문에 현재 논의에서 제외시키자. 비즈니스 모델은 플랫폼에 독립적이며 동일 도메인의 다른 환경에서도 재사용가능하다. 이를테면 A회사의 윈도우 환경, C/S 기반의 인사관리 시스템의 비즈니스 모델은 B회사의 유닉스 환경, 자바 기반의 인사관리 시스템에도 적용할 수 있다. 분석모델도 플랫폼 독립적이다. 하지만 동일 도메인간의 재사용은 불가능하며 닷넷으로 구축된 시스템의 분석 모델을 J2EE 플랫폼으로 적용 가능하다. 디자인 모델은 플랫폼 종속적이다. 하지만 운영체제 같은 시스템에 독립적이다.
그렇다면 MDA의 모델들과 비교해 보자. <표1>은 RUP의 모델들과 MDA의 모델들을 비교한 대차대조표이다.

<그림 1> RUP 모델링과 MDA 모델링

출처 : 마이크로소프트웨어