불행하게도 현대의 소프트웨어 개발자들은 ‘유행’이라는 복병에 휘말려서 뒤돌아 볼 수 없을 만큼 바쁘게 살아가고 있다. 몇 달이 멀다 하고 새로운 버전의 개발 도구나 개발 플랫폼들이 발표되고, 하나에 대해 익숙해져서 사용할 만 하면 그것은 이미 시대에 뒤떨어진 구물이 되어 있어서 새로운 것을 배워야 하는 고민에 빠지고 만다. 소프트웨어 개발자들은 늘 새로운 기술이나 제품에 대해 콤플렉스를 지니고 살아가고 있는 것이다.

그런 것 중에 하나로 모델링 기법을 예로 들 수 있다. 7～8년 전으로 되돌아 가보면 그 시대는 객체지향이란 것에 대해 맹목적인 추종이 있었던 시기였다. 그러던 것이 3～4년 전부터 컴포넌트라는 것으로 슬그머니 이름을 바꾸어 개발자들을 괴롭히더니, 작금에는 아키텍처라는 단어가 컴포넌트라는 단어를 대신하여 개발자들을 현혹시키기 시작했다. 한 때 객체와 컴포넌트가 무엇이 다른가에 대해 생산성 없는 논쟁을 벌이기도 했다.

모델링과 MDA를 위한 OMG의 노력
실질적으로 OMG의 고민은 객체와 컴포넌트가 어떻게 다른 것인가가 아니라 왜 달라야 하는가에서 시작한다. 이를 이해하면 OMG가 왜 그토록 홈페이지부터 MDA에 매달리기 시작했는지 짐작할 수 있게 된다. 소프트웨어 공학 역사의 많은 부분은 모델링과 관련되어 있다. 시스템적인 방법으로 소프트웨어를 개발하는 방법으로는 시스템을 모델링하여 개발하는 것부터 시작한다.

<그림 1> 영업과 관련된 사항을 모델을 이용해 명확하고 쉽게 표현

모델링은 필요 없는 정보를 생략하게 하고 주요한 부분에 대해 관심을 집중하게 함으로써 사물을 효과적으로 분석할 수 있는 방법을 제공한다. <그림 1>의 예처럼 모델로서 영업과 관련된 사항만 명확히 표시할 수 있다. 이러한 모델이 아키텍트나 개발자에게 줄 수 있는 장점들을 정리하면 다음과 같다.

우리가 잘 알고 있는 대형 항공기인 보잉 747 비행기를 상상해 보자. 조정실 안에는 수 백 개의 제어 장치가 있고, 수 백 톤이 넘는 무게의 각종 부품 6백만 개 이상이 조립된 물건이다. 이러한 제품을 처음 만들던 1960년대에는 75,000개가 넘는 엔지니어링 도면들이 제작되어야 했다. 그 이유는 수백 명의 사람을 싣고 수천 킬로미터를 안전하게 논스톱으로 날아야 하는 물건을 정확히 만들기 위해서였다. 그러나 소프트웨어 산업에서는 아쉽게도 객체지향 시대부터 혹은 그 훨씬 이전의 시절부터 모델의 중요성에 대해 강조해 왔지만 모델링이 엔지니어링으로 정착하는 것에는 실패했다. 그 결과 객체가 컴포넌트가 되고 이것이 다시 아키텍처라는 이름으로 유행을 몰아가고 있는 것이다.

OMG는 어떻게 하더라도 모델링이 갖고 있는 엔지니어링으로서의 참된 의미를 밝히고 소프트웨어 개발자들이 이에 대한 가치(value)를 인정할 수 있는 방법을 제공하고자 하는 것에 가장 큰 목적을 두고 있다. 따라서 모델을 가장 가치있게 사용할 수 있는 방법이 무엇인가에 대한 고민의 결과로 몇 가지 툴 공급자에 무관한 각종 표준 규약을 제시하게 됐다. 이에는 구현과 관련 없는 부분(Platform Independent Model, PIM)과 밀접히 관련된 부분(Platform Specific Model, PSM)으로 구분하는 개념적인 사항 이외에 UML(Unified Modeling Language), MOF(Meta Object Facility), XMI(XML Metadata Interchange), CWM(Common Warehouse Model) 등이 포함된다.

모델과 모델 변환
이상에서 이야기 한 바와 같이 모델링의 중요성을 강조하고 이의 부흥을 이끌자는 것이 OMG의 목적임을 염두에 두고 OMG에서 정의한 MDA의 정의를 곱씹어 보자. 정의의 정확성을 위해 원어로 먼저 표현하겠다. “MDA is a way to organize and manage enterprise architectures supported by automated tools and services for both defining the models and facilitating transformations between model types.” 이 정의에 의하면 대규모 시스템을 아키텍처 기반으로 개발하는데, 모델링 기법을 사용하고 각각의 모델의 변환을 통해 시스템을 구축하며 이러한 모든 활동은 자동화된 도구의 도움을 받는다는 것이다.

모델링을 이용한 소프트웨어 개발을 가정해 보자. 고객의 요구 사항으로부터 초기 모델을 만들고 이로부터 각종 정보를 첨가하면서 모델을 변경시켜 최종적으로 우리가 필요한 소스코드를 생성함으로써 실제적으로 실행 가능한 시스템을 구축하는 것이다. 즉, 개발의 모든 활동은 모델을 만들고 이 모델에 각종 정보를 첨가하고 보충하여 더욱 세밀한 모델로 변환시켜서 작동 가능한 소스코드를 만드는 작업인 것이다.

OMG는 모델을 변환시키는 과정에 소요되는 각종 정보나 경험들을 시스템적으로 저장하고 재사용할 수 있다면, 그리고 자동화된 도구의 지원을 받아서 개발할 수 있다면 시스템 개발 생산성을 획기적으로 향상시킬 수 있다는 것에 주목했다. 바꿔 말하면 모델들에 대한 정의가 표준화되어 있고 모델들 간의 변환을 쉽게 해주는 메커니즘이 존재하면 모델을 이용한 개발은 소프트웨어에 대한 개발 생산성을 획기적으로 높일 수 있다는 결론이 나온다. 이것이 OMG가 MDA를 지원하기 시작한 이유이다.

이러한 방법은 몇 가지 유익한 부가적인 효과를 얻을 수 있게 한다. 그 첫째는 비즈니스, 데이터, 사용자 인터페이스, 소프트웨어 아키텍처, 테스트 및 전개에 이르는 소프트웨어 라이프사이클 전체에 걸치는 추적성을 구축할 수 있다. 추적성은 소프트웨어 품질 유지에 있어서 가장 중요한 단어이다.

두 번째는 각 변환에서 사용되는 도메인 정보나 각종 경험적인 지식 및 플랫폼에 관한 정보들이 축적되고 과정에서 이러한 지식들이 정형화됨으로써 표준화된 지식 패턴이나 아키텍처를 유도를 촉진하게 된다. 초기에 GoF 패턴 밖에 없었던 패턴들이 현재는 많은 수의 패턴들이 발표되고 있으며, 각 회사마다 자신들이 필요한 패턴들을 스스로 만들게 되었다. 이러한 재사용 노력들이 소프트웨어 개발 생산성에 많은 기여를 하게 됨은 의심의 여지가 없다. 정의되는 패턴의 수가 많아지고 그 크기도 커지게 되면 자연스럽게 자신의 조직만의 혹은 자신이 속한 도메인 영역만의 아키텍처를 정형화할 수 있게 된다. 즉, 표준화된 아키텍처의 사용과 패턴의 적용으로 재사용에 대한 기회가 획기적으로 증가함으로써 짧은 시간 안에 많은 기능을 높은 품질로 구축할 수 있게 된다.

세 번째는 잘 통합된 개발 도구의 도움을 받을 수 있게 된다. 완전히 통합된 도구에 대한 논의를 학술적으로 시작한 것은 십 년 이상 진행되어 왔다. 이에 대한 연구도 충분히 진행되어 기술적인 문제도 없다. 그럼에도 불구하고 실제적인 개발에 적용하지 못한 이유는 통합에 대한 가치를 사용자들이 충분히 수용하지 못하였기 때문이다. 그러는 사이에 단지 컴파일이나 디버깅 정도 하는 기능의 개발 도구들이 그 틈을 비집고 들어가 IDE라는 용어를 사용하기 시작했다.

그러나 MDA가 지원되면 요구사항으로부터 테스트까지 일련의 개발 활동이 일사천리로 진행됨으로써 통합 개발 환경에 대한 요구가 강하게 요청될 것이며 이러한 요건을 만족시키는 도구들이 MDA 도구의 주요 부분을 차지하게 될 것이다. 마지막으로 충분히 자동화된 도구가 지원된다면, 비즈니스 모델링만으로도 실제적으로 작동하는 시스템을 구축할 수 있다는 것이다. 즉 IT 전문가가 아닌 도메인 전문가가 비즈니스에 대한 정책을 모델링하면 바로 작동하는 제품을 구축할 수 있게 된다. 빠른 시간 안에 비즈니스의 요구사항을 정확히 운용 환경으로 적용시키는 체제가 완성되는 것이다. 금융권에서 CBD나 MDA를 급속히 받아들이고 있는 이유도 급속히 개발되는 금융 상품을 빨리 시장에 출시하기 위해서는 이를 지원하는 IT 서비스도 역시 빨리 지원되어야 가능하기 때문이다.

MDA의 현재와 미래
결론적으로 말하면 MDA는 소프트웨어를 모델 기반으로 개발할 때 개발자가 가장 많은 이익을 받을 수 있도록 하는 방법을 전파하기 위한 OMG의 각고의 결과물이다. 빠른 속도로 발전하고 있지만 아직도 기술적으로 많은 부분이 보완되어야 한다. 그럼에도 불구하고 많은 도구 제공 업체에서는 MDA를 “지원한다” 혹은 “적합하다”라는 마케팅 용어를 사용하고 있다. 이러한 도구들의 나누어 보면 다음의 2가지 범주로 나눌 수 있다.


앞의 두 도구에 대한 분류 기준은 공통성이다. 웹 서비스 응용 소프트웨어를 J2EE 플랫폼에서 정형화된 WAS와 DB 시스템을 사용하는 경우, 많은 부분들이 공통적으로 사용될 수 있기 때문에 비즈니스 정책에 대한 부분만 모델링을 하면 쉽게 시스템을 생성할 수 있다. 이러한 프로젝트는 범주 [1]에 해당하는 자동화된 도구를 사용하여 한달 안에 개발을 완료하기도 한다.

[2]의 경우에는 일반화되어 있지 않은 정보를 많이 사용하는 경우여서, 개발자 스스로가 도메인 정보나 경험적 지식을 정형화하여 저장하고 이를 모델에 적용시킬 수 있는 메커니즘을 지원한다. 이를 얼마나 효율적이고 쉽게 지원하느냐에 따라 도구의 성능이 결정된다. OMG는 이런 메커니즘을 위해 최근 RAS(Reusable Asset Specification)이라는 재사용 패턴에 대해 표준화를 추진하고 있다. RAS 표준의 형태로 각종 개발 정보를 정리하고 공유했다가 개발에 실제적으로 적용하는 방법을 지원하는 것이다. 이 방법은 앞으로 도메인 영역별로 고유의 프레임워크를 갖도록 하는데 많은 도움을 줄 것이다.

초기에는[1]에 해당하는 도구들이 MDA 도구로 많이 소개되었으나 앞으로는 [2]에 해당하는 도구들이 많이 출시되며 앞으로의 MDA 시장을 개척할 것이다. @