[지디넷코리아]소프트웨어 발전 방향을 미리 예견하기는 무모하거나 용감한 작업이 될 수 있다. 선배의 말을 빌리자면 차세대 채택되는 패러다임을 예측하기란 현재 학계나 커뮤니티에서 논의되고 있는 패러다임을 제비로 접어서 통에 넣어 흔든 후 하나를 뽑는 것과 같다고 한다. 그만큼 장담하기 힘들고 어려운 부분이다. 하지만 그것은 학계에서 발표되는 패러다임 101 버전의 얘기이지(이번 특집의 주제인 MDA만 하더라도 3년 전에 발표된 내용이다).

실제 산업에서 사용할 수 있는 수준의 차세대 패러다임을 점친다는 것은 메이저 벤더들의 제품 비전만 보더라도 쉽게 알 수 있다(대형 밴더들이 그런 고민은 다 해준다). 물론 ‘시장에서 채택될 것인가?' 하는 아주 복잡하고 우연적인 변수를 제거했을 때 말이다. 또 다른 방법이 있다 약간의 추리력과 예지력이 필요한데 과거 소프트웨어가 어떻게 발전되었는지 흐름을 잡고 미래를 예측해보는 것이다. 이 방법은 ’메이저 벤더들의 제품 비전’ 보다 앞서 미래를 점쳐볼 수 있다.

MDA의 목적, 실체를 살펴보기 위해 OMG에서 꾸준히 추진해온 OMA(Object Management Architecture)를 살펴보는 것은 도움이 된다. 결국 MDA는 OMG의 주력 표준인 UML과 OMA를 조합해 탄생한 총아이기 때문이다. 또한 MDA를 통해 얻고자 하는 것이 무엇인지, 그리고 다른 ‘제비’들과는 어떻게 다른지를 살펴보는 것은 흥미롭다. 자, 그럼 OMA를 통해 엔터프라이즈 소프트웨어가 어떤 것들을 어떻게 정복하며 발전했는지 살펴보자. 여기서 관전 포인트는 소프트웨어 재사용 단위, 형태를 기준으로 하는 것이 적당하겠다. 그리고 이 재사용성은 표준 혹은 규약으로 형상화된다.

OMA에서 MDA로
라이트 형제가 만든 플라이어호는 F-16 전투기와 너무도 다르다. 과거의 비행기에 비해 현재의 비행기는 너무 강력하고 많은 기능들이 추가되었다. F-16 전투기는 플라이어호부터 F-16 전투기 이전 버전까지의 결과물이다. 즉 F-16 전투기를 이해하기 위해 이전 버전들의 발전 과정을 추적해 보면 아주 잘 이해할 수 있다. OMA와 MDA의 관계가 그렇다.

<그림 1> OMA 아키텍처 1

OMA는 크게 분산 객체 명세와 객체간 원격 호출의 신뢰성, 상호운용성, 이식성 등을 보장하는 ORB가 그 핵심에 있다. ORB를 통해 객체(컴포넌트, 서비스 등으로 대치시켜도 무방하다)를 배포할 수 있었고 배포된 객체는 실행 환경에서 (재)사용된다(객체 표준/규약). 분산객체에 원격호출이 요청되면 그 객체가 가지는 비즈니스를 실행하게 된다. 엔터프라이즈 시스템에서의 비즈니스는 상당히 복잡한 처리과정을 갖는다. 네이밍 서비스를 통해(J2EE에서 JNDI) 타 서비스를 찾아 비즈니스를 연동하기도 하며 트랜잭션 서비스를 통해(J2EE에서 JTS or MTS, TP Monitor) 트랜잭션 처리를 위임하기도 한다.

또한 이벤트/Notification 서비스를 통해(J2EE에서 JMS or IBM MQ Series) 메시징 처리 및 EAI를 위임하는 것 이외에(데이터베이스) 쿼리, 보안, 라이선싱, 객체 저장 등의 서비스를 사용한다. 이런 각 코바 서비스는 비즈니스 처리를 위해 기술적 난점들을 재사용 가능하게 한다. 과거에 이 서비스들을 미들웨어라 불렀다(미들웨어 표준/규약).

객체 표준과 객체간의 통신의 문제도 각종 기술적인 문제도 점령됐다. 이제 비즈니스 처리에 전념할 수 있다. OMA에서는 비즈니스 처리에 도움을 주는 편의 기능인 퍼실리티(CORBA Facility)를 준비하고 있다. 퍼실리티는 특정 도메인(금융권, 국방, 행정, 모바일)에서 자주 쓰이는 수직적(vertical) 퍼실리티와 소프트웨어 개발시에 일반적으로 사용할 수 있는(데이터 압축, 룰 처리, 워크플로우 처리, 컬렉션 등) 수평적(horizontal) 퍼실리티가 있다. 이로써 개발자들은 일반적으로 사용하는 수평적 편의 기능들과 현재 산업 도메인의 표준으로 정의된 모델인 수직적 편의 기능을 조합해 자신의 애플리케이션에 맞게 최적화, 특화해 개발하게 된다. 물론 도메인 퍼실리티는 코바 퍼실리티 프로바이더에 의해 제공된다.

그리고 이를 바탕으로 <그림 2>의 도메인(객체)이 형상화, 정규화된다(레이어가 연상되지 않는가?). CORBA 도메인은 금융권부터 국방, 통신에 이르기까지 상당히 광범위하게 정의되어 있으며 다루고 있는 영역도 상당히 정밀하다. 사실 이 도메인이나 퍼실리티는 해당 분야의 기술자들이 오랜 경험을 통해 축적된 지식과 노하우를 통해 연구하여 설계한 모델이다(산업 도메인 표준/규약).

OMA 아키텍처는 이렇게 가장 기본이 되는 것부터(밑에서부터) 하나씩 표준화 작업을 수행했으며 이 표준화된 규약에 맞춰 개발된 COTS를 이용해 좀 더 검증되고 안정된 플랫폼을 제공하려는 비전을 갖는다. 표준화 작업으로 점령하는 과정은 가장 근본적이고 재사용성이 강한 대상부터 시작한다(ORB -> Service -> Facility). 그리고 그 종국에는 Domain이 있다. Domain은 해당 도메인에 가장 안정적인 아키텍처, 통신 프로토콜, 자료구조(경우에 따라서 데이터베이스 논리 테이블(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 등의 내용은 차치한다.

<그림 2> OMA 아키텍처 2		<그림 3> Model Driven Architecture

MDA의 목표는 OMA의 그것과 다르지 않다. 개발을 위한 최대한의 플랫폼을 준비해 놓고 각 도메인 전문가들이 완성한 표준 모델들을 제공하여 개발에 필요한 최대한의 생산성을 극대화시킨다. MDA는 이제 CORBA만을 고집하지 않고 J2EE, 닷넷, 웹 서비스 등 다른 플랫폼을 아키텍처에 포함시켰다. 그러므로 OMA에서의 개발 프로세스와 매우 유사한 방법으로 개발 가능하다. 즉 MDA 산업 도메인 모델을 기반으로 현 시스템이 필요한 모델들을 추출한 후, 최적화시킬 부분을 커스터마이징한다.

끝으로 도메인 모델에 표현되지 않은 특화시켜 추가 개발해야 할 모델들을 모델링하므로 PIM을 완성한다. 다음 MDA 프로세스에 따라 PSM으로 모델 전이(Model Transform)를 하고 해당 플랫폼에 대한 소스코드를 생성한다. ‘PIM → PSM → Code’로의 전이는 매우 훌륭하지만(이 전이 과정은 일반적 방법론과 매우 잘 일치한다. 박스 기사 참조) 또 하나 상기해야 할 부분은 나와 똑같은 도메인 선배 전문가의 경험과 지식으로 표준화된 도메인 모델들을 잊지 않아야 할 일이다.

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

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

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) 한다.

하지만 객체간의 복잡한 관계들은 관리적 측면에선 단점이 된다. 컴포넌트는 좀 더 큰 범위에서 인터페이스를 통해 실제 사용하는 기능에 집중할 수 있게 한다. 컴포넌트가 객체들을 추상화(Facade)한다. 서비스는 컴포넌트의 처리를 비즈니스 단위로 묶어 작업 단위를 상위 레벨에서 캡슐화해 접근하게 한다. 서비스가 컴포넌트을 추상화한다.

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

그러므로 사용자는 소비자로서 더욱 자신의 비즈니스 흐름에 집중할 수 있고 필요에 의해 비즈니스 흐름에 필요한 서비스를 선택하게 한다. <그림 4>는 SOA의 큰 범위에 등장하는 아키텍처적 레이어이다. 애플리케이션 아키텍처는 하나 이상의 서비스 공급자로부터 제공되는 서비스들을 찾아 비즈니스 프로세스 속으로 각 서비스들을 통합한다. 서비스 아키텍처는 실제 서비스를 처리하는 컴포넌트 아키텍처와 소비자 사이에 브릿지 역할을 함으로써 서비스를 위한 연동, 처리 관계, 상태 등을 관리해준다. 컴포넌트 아키텍처는 실제 서비스 구현을 담당하며 레거시 시스템이 좋은 후보가 될 수 있다. 이런 기반 구조에서 다음과 같은 효과를 얻을 수 있다.


SOA의 기본 세계관은 이미 개발된 각 기업의 컴포넌트들을 통합하기 위해 규격화·일반화한 서비스 컴포넌트를 상호운용할 수 있도록 함으로서 개발자가 중복 개발하는 것을 지양하는 것이다. 즉 네이버에서 개발된 블로그를 엠파스에서 똑같은 작업을 반복할 필요없이 네이버 블로그 ‘서비스’를 사용한다면 개발자의 노동력을 1/n배 감소할 수 있을 거라는 가설이다. 하지만 SOA는 이처럼 단순하지만은 않다. SOA는 보다 비즈니스 프로세스 관점에서 접근한다. 비즈니스 프로세스적 접근이란 마치 C 언어에서 main 함수를 시초로 다른 함수들을 호출해 프로그램이 진행되듯이 소비자가 각 서비스를 이용해 하나의 비즈니스 프로세스를 수행하는 방식을 말한다.

물론 하나의 서비스는 독립성을 갖지만 서비스는 상호 이용할 수 있으며 하나의 비즈니스 서비스는 서비스들의 조합으로 완성된다. 이를테면 <그림 5>에 표현된대로 ‘항공권 구매’란 비즈니스 서비스는 컴포넌트의 복잡한 조합에서 작업 흐름(프로세스)에 따라 호출되는 서비스들의 집합으로 관계를 단순화시킬 수 있다(인터페이스 중심의 패러다임에서 프로세스 중심으로의 패러다임 전이). SOA가 행운의 ‘제비’가 된다면 개발자는 서비스 마켓 플레이스에 진열된 양질의 서비스를 선택해 비즈니스 프로세스의 구성요소들을 구매한다. 만약 원하는 서비스가 없다면 개발해 구성 서비스에 추가시킨 후 서비스로 제공하게 될 것이다.

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

여기서 또 하나의 기대효과를 얻을 수 있다. 이렇게 서비스들이 빌트인 된 상황에서 각 서비스들의 상호작용을 마치 UML 시퀀스 모델링하듯이 비즈니스 프로세스 수행 시나리오를 작성하게 된다는 것이다. 웹 서비스의 WSFL(Web Service Flow Language)과 WSCL(Web Service Composition Language)이 이런 역할을 한다. 유사 기술로는 BPM(Business Process Management)의 BPML(Business Process Modeling Language), 마이크로소프트의 XLANG가 있다.

디자인 완전정복, 패턴언어
필자는 본지에서 지난 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가 꼭 뽑히는 ‘제비’가 되기를 개인적으로 바란다. @