기업의 IT가 기술적인 면이나 비즈니스적인 면에서 SOA의 가치를 제공할 수 있게 하는 개발 방법을 생각해야 한다. 검증된 디자인 패턴을 포함한 MDA(Model Driven Architecture)를 제대로 적용한다면 기업의 IT는 비즈니스에 대한 초점을 놓치지 않으면서도 서비스 지향의 애플리케이션을 아주 손쉽게 적용할 수 있다. 이러한 아키텍처와 적용 방식을 채택해 SOA를 구현할 경우 비즈니스 변화에 신속히 반응할 수 있는 동적인 인프라스트럭처를 갖출 수 있게 되고 개발의 생산성이 극적으로 증대된다. 그렇게 함으로써 비즈니스 요구사항과 IT적용 간의 간격을 최소화할 수 있다. <편집자>

대부분의 IT책임자나 아키텍트들은 애플리케이션 인프라의 구축, 유지, 개선에서 SOA의 채택이 가져다주는 가치를 오래 전부터 인식하고 있다. 여러 애플리케이션에서 사용될 수 있도록 표준 인터페이스를 채택한 논리적인 소프트웨어 컴포넌트들과 비즈니스 활동이 제대로 연결된다면 새롭게 애플리케이션을 생성하거나 개선코자 할 때 엄청난 유연성을 가질 수 있게 되기 때문이다.
어떤 다른 애플리케이션 아키텍처보다도 SOA는 IT가 비즈니스 전략에 초점을 맞출 수 있는 방안을 제공한다. 기업의 SOA는 현재와 미래의 비즈니스 수요에 따라 신속하게 채용할 수 있는 비즈니스 로직의 인프라스트럭처를 구현한다. SOA의 컴포넌트들은 애플리케이션의 빌딩 블록으로 사용돼 변화하는 비즈니스의 조건들에 대한 IT의 반응을 획기적으로 개선할 수 있게 되는 것이다.
그런데 아키텍처나 IT 관리자들이 SOA의 개발이 가져다주는 가치를 충분히 인식한다 하더라도 어떻게 이것을 가능케 하느냐에 있어서는 많은 이슈들이 존재한다. 많은 경우에 당장의 소소한 문제들을 해결해야 하는 상황에서 SOA를 구축하는 것은 기술적인 측면이나 프로젝트 관리 측면에서 선뜻 엄두가 나지 않는다. 전통적인 개발 툴을 가지고 곧바로 SOA개발로 들어가는 경우가 있는데 얼마 지나지 않아 무수한 문제의 수렁에 빠져들게 된다. 혹시라도 SOA에 관한 기술적인 문제들을 극복한다 하더라도 상당한 경우에 소프트웨어의 결과들이 비즈니스와 매끄럽게 연계되지 못한다. 이러한 경우에서 IT 결과물들은 SOA의 기술적 정의를 만족시키는 아키텍처일 수는 있지만 결코 진정한 가치를 제공하지는 못한다.
여기서 기업의 IT가 SOA의 가치를 제공할 수 있게 하는 개발 방법으로 등장한 것이 바로 MDA(Model Driven Architecture)의 적용이다. 이것은 SOA의 컴포넌트들과 개별적 웹서비스 구축에 대해 수행된 조사에서 여러 차례 입증된 것으로, 가트너에 의한 조사[ARAD Methods and tools Improve Productivity and ROI, Michael Blechar and Matthew Hotle, October 11. 2004]에 의하면 ARAD(Architected, rapid-application development) 접근 방식과 도구들은 현저하게 생산성을 향상시키고 높은 ROI를 가져다준다는 것이다.
가트너는 이러한 결론에 이르기까지 툴 비용과 직원 교육비용에 대한 ROI를 알아보기 위해 선도적인 ARAD 툴을 사용하는 7개의 사용자 경우를 조사했다. 가트너는 다음과 같은 2개의 주요 요소로부터 근본적인 ROI개선이 발생한다고 보고한다.
이러한 결론들은 실제의 프로젝트를 대상으로 한 연구와 분석에 의해서도 확인된다. 미들웨어컴퍼니는 전통적인 툴을 사용하는 방식과 MDA 방식으로 동일한 프로젝트를 수행해 비교하는 실험을 실시했다. 이 실험 결과에 의하면 35%의 생산성의 차이를 보인다. 또한 유지보수 과정에서의 생산성도 검증을 했는데 애플리케이션에 따라 차이는 있지만 개발 때와 비슷하거나 그 이상의 생산성의 차이를 보여준다.
비슷한 맥락에서 EDS의 한 연구는 PetStore 애플리케이션의 구현에서 전통적인 코드 중심 개발 툴과 MDA방식의 툴간 코드 라인 수의 차이를 확인했다. 이 연구는 전통적 방식에서 수작업 코딩 라인수가 20배 이상임을 확인했다.(1만4천273 대 610 라인)
나아가 동일한 애플리케이션을 MDA 방식을 적용해 EJB1.1에서 EJB2.0으로 마이그레이션했을 때 MDA방식의 개발에서는 모든 마이그레이션이 자동화되기 때문에 단 30분이면 가능했다. 이것은 이러한 방식이 개발 생산성의 증진뿐 아니고 애플리케이션 유지보수 능력 그리고 새로운 플랫폼으로의 마이그레이션 등 애플리케이션 라이프사이클 전반에 걸친 효과를 보여주고 있음을 증명하는 것이다.
MDA 방식에서 비즈니스 요구사항과 IT 적용간의 커뮤니케이션을 개선시키는 핵심은 ‘변환 패턴’에 있다. 변환 패턴은 정의된 비즈니스 항목을 애플리케이션 로직으로 전환하는데 있어서의 원칙을 기술하고 비즈니스 분석의 산출물을 소프트웨어 컴포넌트로 변환하는 과정을 자동화해 정확성과 일관성을 유지할 수 있게 한다. 그 결과로서 소프트웨어 컴포넌트들은 비즈니스 요구사항을 제대로 맞출 수가 있고 코드의 일관성과 품질이 개선되며 요구사항의 변화에 대한 유연성을 갖게 된다. <그림 1>은 ‘변환 패턴’의 역할을 보여 주는 것이다.

비즈니스에서 출발 기술로 구현
MDA 방식의 개발은 비즈니스 요구사항으로부터 완성된 소프트웨어에 이르는 과정을 일관되게 자동화함으로써 매우 높은 유연성을 갖춘 소프트웨어 컴포넌트를 제공한다. 비즈니스 프로세스를 자동화하기 위해 소프트웨어 라이프 사이클을 시작할 때 이 프로세스를 표현한 정형화된 모델을 사용함으로써 정확한 적용 과정을 가져가는 유일한 방식이 MDA이다. 비즈니스 프로세스를 표현하는 모델은 3가지로 구성된다.
이러한 모델을 만들어 내는 핵심 도구는 UML(Unified Modeling Language)이다. UML은 복잡한 시스템을 표현하기 위해 보편적으로 인정되는 표준이다. 많은 사람들이 UML을 애플리케이션 개발자들의 도구나 일종의 고도의 프로그래밍 언어로서 생각하기도 하지만 소프트웨어 애플리케이션과 비즈니스 프로세스를 동시에 모델링한다는 보편적 목적을 갖는 도구이다. 다음 그림에서 볼 수 있듯이 시스템 분석가들은 UML에 의해 한 가지 의미로만 분명하게 해석되는 정형화된 다이어그램을 가지고 프로세스를 명쾌하게 정의할 수 있다. 그래서 아키텍처나 애플리케이션 개발자들은 그 내용을 정확하게 해석하고 이해할 수 있게 되는 것이다.
다음 단계로, 기술적인 솔루션의 아키텍처와 디자인은 아키텍처 모델을 통해 이뤄진다. 아키텍처 모델은 애플리케이션 컴포넌트 및 컴포넌트 간의 상호작용을 기술한다. 컴포넌트 중에는 이미 서비스로 존재하는 것들일 수도 있다. 그러면서 애플리케이션 전체의 구조를 정의하게 된다. 예를 들어 아키텍처 모델은 컴포넌트들의 번호와 기능을 표시하고 컴포넌트들 사이의 커뮤니케이션을 표시한다.
아키텍처 모델 역시 UML 다이어그램으로 표시하는데 이때는 기술적인 솔루션을 비즈니스 프로세스에 맞춰 정리하는 것이다. 다이어그램은 개별 컴포넌트를 상세히 기술하게 된다. 무엇을 하고 어떻게 다른 것들과 관계하고 입/출력은 어떠한 것들인지를 기술한다. 마지막 단계에서는 실제 설계의 구현으로서 애플리케이션 코드이다. 전통적인 개발에서 개발 구현은 애플리케이션 개발팀에 의해 이루어지며 개발자들은 비즈니스에서 요구하는 작업을 수행키 위해 설계에 명시된 기능을 고난도의 코딩을 통해 만들어 낸다. MDA 방식에서는 코드 모델이라는 개념이 존재하며 이는 아키텍처 모델에서 만들어지는데 아키텍처 모델은 서비스 제공 단계에서 사용할 구체적 플랫폼에 대한 정보를 기반으로 한다.
이상과 같은 MDA방식의 각 단계에서 함께 결합하는 것이 ‘변환 패턴’이다. 변환 패턴은 각 모델을 다음 단계로 변환할 수 있게 하는 전문성과 로직을 제공한다. 때문에 변환 패턴은 논리적인 프로세스로 표현되고 코드화될 수 있으며 자동적으로 실행될 수 있도록 돼 있다. 이는 결국 서비스 개발 라이프사이클 각 단계들 사이의 이동 절차를 자동화할 수 있게 한다.
전통적인 개발 사이클에서는 각 단계들 사이의 이동에 커다란 갭이 존재한다. 대체로 비즈니스 요구사항으로부터 아키텍처로 그리고 완성된 애플리케이션 혹은 서비스로의 전환은 사람이 직접 텍스트 형식의 문서와 정형화되지 않은 다이어그램을 해석하는 과정을 따른다. 이것은 문제와 솔루션의 정의를 불명확하게 하고 때로는 여러 가지의 서로 다른 해석을 가능하게 한다. 결과적으로 아주 중요한 비즈니스 서비스를 제공해야 할 프로젝트가 연기되고 서비스가 요구사항을 정확이 반영하지 못해 재작업을 하기도 하고 제공되는 서비스가 비즈니스적 요구사항을 해결하지 못하는 상황이 비일비재하다.
MDA방식의 서비스 개발 라이프사이클은 내용과 설계를 정확하고 세밀하게 정의하면서 각 단계의 변환을 자동화해 이러한 잠재적인 문제들을 제거할 수 있다. 이를 통해 현재의 비스지스의 요구를 충족할 수 있는 SOA를 빠르게 개발하면서 역동적인 비즈니스 조건의 변화를 신속히 수용할 수 있는 유연성을 갖출 수 있게 된다.
이러한 MDA 적용 프로세스가 복잡한 것일까? 시스템을 분석하며 비즈니스 요구사항을 도출하고 비즈니스 요구사항을 솔루션 아키텍처로 전환하고 마지막으로 이러한 아키텍처를 구현하는데 있어 전통적인 접근 방식은 오히려 더욱 복잡한 단계를 겪는다. 또한 전통적인 접근 방식에서 애플리케이션 개발 단계 사이의 수동적인 이관과 텍스트 문서나 비정형 다이그램 해석의 모호함 등으로 인한 에러 발생 가능성은 매우 높을 수밖에 없다.
결과적으로 애플리케이션의 서비스 지향 개발을 위한 MDA 방식은 개발 라이프 사이클을 가속화하면서도 개발된 솔루션이 실제의 비즈니스 요구를 제대로 해결할 수 있도록 하는 것이다. 이는 앞에서 언급했듯이 개발 라이프 사이클을 자동화하며 모호함을 제거하고 비즈니스 내역을 직접적으로 반영하는 컴포넌트를 설계하고 구축할 수 있게 함으로써 가능한 것이다.

IT와 비즈니스 사이 간격의 최소화
MDA 개발 라이프 사이클이 애플리케이션 서비스 더 나아가 기업의 SOA를 만들어 내는 과정을 자동화하고 가속화하는 각 단계를 자세히 살펴보자. 라이프 사이클의 각 단계는 비즈니스 모델로부터의 정형화되고 논리적인 프로세스에 의한 변환을 통해 이루어지기 때문에 원래의 비즈니스 요구사항으로 일관된 연계성을 갖으면서 전개된다.
전통적인 소프트웨어 개발에서도 비즈니스 혹은 기술 전문가 그리고 애플리케이션 사용자들은 애플리케이션 혹은 애플리케이션 서비스로서 해결되어야 할 문제나 필요를 제기한다. 이를 위한 예산이 책정되면 시스템 분석가가 비즈니스 니즈를 분석 정의하게 된다. 분석 산출물은 일반적으로 요구에 대해 설명하면서 어떤 솔루션이 잠재적으로 이러한 요구를 만족시킬 수 있을 것인가를 기술하는 문서이다. 이 문서는 텍스트와 다이어그램으로 구성될 것이며 이것은 일반적으로 소프트웨어 솔루션의 오퍼레이션에 대한 상세 사항을 파악하는데 사용된다.
이러한 프로세스의 결과는 비즈니스의 요청에 대한 비즈니스 모델을 정의하는 것이다. 이 모델은 대체로 UML로 표현되는데 클래스 모델을 통해 구조를, 서비스 모델을 통해 동작을 담아낸다. 비즈니스 모델은 기술적인 상세 사항은 포함하지 않는다. 대신 비즈니스 문제에 대한 애플리케이션의 기능에 초점을 맞춘다.
비즈니스 모델은 애플리케이션 전체에 적용되는 비즈니스 룰들을 포함하여 애플리케이션 오퍼레이션의 조건을 제공한다. 이러한 룰들은 솔루션이 데이터를 저장하거나 입력할 때의 제한 조건(Constraint)이나 솔루션이 데이터를 검증하고 계산하는 수식이 될 수 있다. 달리 프로세스의 플로우를 정해 개별 서비스들로써 프로세스 상의 여러 순차적인 단계가 이루어지도록 한다.
비즈니스 모델 수준단계에 웹서비스를 반영함으로써 비즈니스 요구사항을 제대로 반영하게 할 수 있다. 이것이야말로 비즈니스 목표를 제대로 반영하는 SOA를 일관되게 구축할 수 있는 유일한 출발점이다. 기존의 컴포넌트들을 웹서비스로 씌우는 순수한 기술적 측면에서 출발해서는 결코 비즈니스의 문제와 기술적 솔루션 사이의 일관되고 논리적인 연결성을 제공할 수 없다.
변환 패턴을 사용해 비즈니스 모델은 아키텍처 모델로 변환된다. 이러한 자동화된 변환을 통해 속도 그리고 정확성과 해석의 일관성이라는 장점을 얻을 수 있다. 이 모델은 애플리케이션 컴포넌트들로의 논리적인 분기를 반영해 여러 개의 하위 레벨 모델들로 구성될 수 있다.
예를 들어 일반적인 3티어 애플리케이션에서 아키텍처 모델은 프리젠테이션 모델, 논리 모델, 데이터 모델로 나눠 질 수 있다. 프리젠테이션 모델은 데이터를 사용자에게 보여주기 위해 데이터 스키마와 유저 인터페이스 컴포넌트들을 포함한다. 비즈니스 논리 모델 역시 데이터 스키마와 클래스 정의, 엔터티 컴포넌트 정의, 세션 컴포넌트 정의, 비즈니스 룰들을 포함한다. 마지막 데이터 모델은 데이터를 검색, 수정하고 저장하기 위해 테이블, attribute, 키를 정의하는 관계형 데이터 스키마를 갖는다.
일단 애플리케이션이나 서비스 아키텍처가 정의되면 아키텍처 모델은 또다른 변환 패턴을 사용해 코드 모델로 전환될 수 있다. 비즈니스 모델과 코드 모델간의 자동화된 변환으로 인해 비즈니스적인 문제와 기술적인 솔루션 사이에 직접적인 관련을 유지할 수 있게 된다. 더 나아가 비즈니스 모델이 전체적인 서비스의 모델로서 정의됐기 때문에 전체적인 서비스의 기능과 동작은 비즈니스 프로세스의 요구를 정확히 반영하게 된다.
중요한 것은 이 단계에서 사용되는 변환 패턴은 최고 수준의 성능을 내는 개발팀에 의해 만들어진 것과 같은 최고 품질의 코드를 만든다는 것이다. 또한 수작업 코딩과 테스트에 소요되는 시간이 극도로 단축된다. 만약 성능과 확장성의 이슈가 애플리케이션에서 발견된다면 그 정보는 다시 변환 패턴에 반영돼 지속적인 개선을 도모하게 된다.

서비스 개발에의 적용
MDA개발은 웹 서비스와 SOA 개발에 매우 효과적이다. MDA는 비즈니스 프로세스와 활동에서 출발해 최종 결과물인 소프트웨어 서비스로 직접 매핑하기 때문에 소프트웨어 컴포넌트들은 실제의 비즈니스 니즈에 분명한 근거를 갖게 된다.
기업의 SOA를 목표로 하는 서비스와 관련하여 MDA 접근 방식이 어떠한 모습을 갖는지 생각해 보자. 그 작업은 비즈니스 문제와 요구 사항으로부터 출발하게 되고 그것은 각종 프로세스나 액티비티의 자동화 요구로 표현된다. 비즈니스가 지향하는 목표에 관점을 두고 문제를 구체화하기 위해 시스템 분석가는 비즈니스와 서비스 모델을 만들어 이것을 해결할 소프트웨어 솔루션의 구조와 동작을 정의하게 된다.
여기에서의 소프트웨어 컴포넌트는 독립적인 애플리케이션이지만 여기에 SOA 소프트웨어 모델의 고유한 유연성과 적용성이 부여된다. 그래서 하나의 컴포넌트로 동일한 로직을 요구하는 여러 비즈니스 니즈를 만족하는 솔루션이 된다. 일단 비즈니스 모델이 완성되면 애플리케이션 아키텍트는 서비스를 적용하기 위해 설계된 변환 패턴을 적용하여 웹서비스 아키텍처를 만들게 되고 로직과 데이터 엑세스, WSDL 레파지토리, XML 스키마, 인터페이스, 비즈니스 facade를 포함한다. 컴포넌트는 비즈니스 오브젝트로부터 아키텍처적인 것으로의 전환으로 볼 수 있다.
코드 모델은 또 다른 변환 패턴으로부터 만들어 진다. 이 변환 패턴은 플랫폼에 따른 특성을 적용하여 실행 가능한 코드를 생산하는 것으로 실행 가능한 서비스로서 특정 소프트웨어 환경을 전제로 한 결과물이다. 이 변환은 또한 테스트 하네스, 설치 기술서, 환경 설정 파일, 기타 플렛폼으로 전개에 필요한 컴포넌트들을 생성한다. 이상적으로 MDA 방식은 여러 애플리케이션에서 사용이 될 수 있는 비즈니스 오퍼레이션을 수행할 수 있는 완전한 기능을 갖춘 이상적인 서비스를 만들어 낸다.

애플리케이션 서비스의 구축 이상의 것
서비스 지향의 애플리케이션 개발에서의 MDA 방식은 단순히 애플리케이션 컴포넌트들을 모으는 것 이상의 것을 제공한다. 여기에서의 컴포넌트는 검증된 요구사항을 반영한 실제의 비즈니스 로직 컴포넌트들이기 때문에 하나 혹은 그 이상의 핵심적인 비즈니스 프로세스를 처리할 수 있는 로직을 표현한다. 이러한 로직은 반드시 대부분의 경우에서 독자적인 로직 그 자체의 기능과 함께 컴포넌트들 간에 상호작용을 하게 된다.
이것은 결국 애플리케이션 서비스의 통합을 가능케 하고 비즈니스가 원하는 결과를 제공하게 된다. 애플리케이션 통합은 각 개별 요소 범주 밖의 비즈니스 결과를 만들어 내기 위해 애플리케이션과 서비스들이 함께 움직여야 하기 때문에 기술적으로 매우 어려운 작업이다. MDA 개발 라이프 사이클 방식은 한 단계에서 그 다음 단계로 넘어갈 때 적절한 변환 패턴만을 적용해 웹 서비스에 추가될 수 있는 서비스와 컴포넌트를 손쉽게 만들어낼 수 있다.
변환 패턴이 있어 아키텍트들은 통합 어댑터의 사용 뿐 아니라 XML 기반 웹서비스를 통한 통합을 목표로 할 수 있다. 기존 애플리케이션 인프라스트럭처 및 비즈니스의 필요에 따라 여러 다른 방식의 통합을 목표로 할 수 있다. 방식을 채용한 IT 전문가는 통합 적용의 가장 앞 단에 비즈니스 요구사항을 가져다 놓기 때문에 MDA 비즈니스 솔루션을 가장 잘 서비스할 수 있는 통합 방식을 가져가게 된다. 이러한 개발 라이프 사이클 접근 방식에 따르면 또한 SOA를 효과적으로 사용하게 돼 핵심 비즈니스 프로세스를 전사적으로 자동화할 수 있게 된다. 사실 <그림 3>에서 보이는 것처럼 비즈니스 프로세스 자동화는 비즈니스 니즈와 IT적용의 결합으로서 SOA 다음 단계로 보여진다. 비즈니스 액티비티를 직접적으로 반영하는 서비스 창출을 위한 개발 라이프 사이클을 자동화함으로써 기업은 비즈니스 프로세스 전반으로 영역을 넓히고 SOA를 채택해 그것들을 자동화할 수 있게 된다.
진정한 비즈니스 프로세스 자동화를 실행할 수 있는 단계로 나아갈 수 있는 능력은 SOA가 비즈니스의 핵심적인 프로세스를 반영할 수 있느냐의 문제이다. SOA의 설계와 적용은 MDA 개발 사이클을 사용함으로써 절대적인 도움을 받을 수 있다. 서비스 모델에 의해 표현되는 비즈니스 요구사항으로부터 도출되는 서비스로의 자동화된 접근방식에 의해 기업은 개별적인 서비스의 창출 이상으로 나아갈 수 있는 유리한 위치에 서게 된다.
복잡한 비즈니스 프로세스 자동화 이면의 기술은 관현악 편곡과도 같아 그것은 프로세스를 실행하기 위해 필요로 하는 컴포넌트들의 정확한 순서를 이해해야 한다. 관현악 편곡과 같이 서비스들을 적절한 순서로 정렬시키고 그리고 그것들이 순서대로 처리되도록 하고 산출물들이 다음 단계의 서비스에서 사용될 수 있게 만들어야 한다.
일단 SOA가 적용되고 운영되면 워크플로우 엔진에 따라 비즈니스 프로세스를 실행하는 것은 비즈니스 프로세스의 실행을 정확히 측정할 수 있게 한다. KPI를 정의하고 이에 대한 실제의 성과를 측정함으로써 IT전문가는 프로세스병목과 비효율을 쉽게 찾아낼 수 있고 이 이슈에 대한 솔루션 빠르게 찾아내고 테스트할 수 있게 된다.
기업의 SOA는 비즈니스프로세스를 애플리케이션 변경 없이 빠르게 변경할 수 있고 병목 해결 및 프로세스 개선을 제공한다. 덧붙여 복잡한 애플리케이션을 전개하지 않고서도 애플리케이션 서비스를 손쉽게 대체할 수 있게 한다.
결과적으로 유연한 IT 애플리케이션 인프라스트럭처, 비즈니스 조건의 변화에 따른 보다 빠르고 정확한 반응, 소프트웨어 컴포넌트에 비즈니스 프로세스의 정확한 반영이 가능하게 된다. 그리고 서비스에 MDA 방식의 개발을 채택하는 것은 이러한 목표를 달성하기 위한 가장 빠른 길이다.

▶ 교육 및 툴 구입비용
사용자들은 상대적으로 높은 ROI 결과를 말했고 요점은 도입 비용과 교육비용이 예상했던 것보다 저렴한 것이었다.
▶ 생산성 유인
ARAD 툴과 기술을 사용했을 때 예상치 보다 높은 생산성의 개선이 나온 것이다.
이러한 결과는 결론적으로 ARAD 툴들이 개발자로 하여금 모델과 패턴을 사용하게 해 IT 팀의 생산성을 향상시키고 비즈니스의 요구를 보다 잘 수용하는 소프트웨어를 구현할 수 있게 한다는 것이다.
·전 개발 비용의 최대 1/5 수준으로 비용 절감
·최대 1500%, 평균 900%의 추정된 ROI
·ARAD 채택 시 일반적으로 1년 내 투자 회수
·ARAD 중심의 툴들은 가트너 기대 이상의 학습 용이성과 높은 생산성 제공

▶ 애플리케이션에 의해 처리될 정보의 구조를 반영하는 모델 (클래스 모델)
▶ 애플리케이션의 동작을 반영하는 모델 (서비스 모델)
▶ 실행될 작업들의 순서를 반영하는 모델 (프로세스 모델)

데이터넷 관리자