서비스 지향 아키텍처(SOA)는 소프트웨어 분야의 최신 경향 중 하나다. 여기에서 핵심 마인드는 기술 지향적인 솔루션과는 거리를 두고 비즈니스 프로세스 쪽으로 더 접근했다는 것이다.
서비스에 집중함으로써 애플리케이션들은 보다 풍부하고 의미가 있는 비즈니스 프로세스를 제공할 수 있도록 모아지고 있다. 그 결과 SOA 솔루션들은 대부분 진정한 의미에서 비즈니스 모델에 더 부합하는 면모를 보여주고 있다.
이 글에서는 SOA의 구성 요소와 해당 요소가 비즈니스에 어떻게 할당되는지 알아보도록 하자.
기술, 애플리케이션 중심적 관점
한동안 비즈니스 소프트웨어 솔루션들은 특정 기술이나 애플리케이션에만 집중됐다. 그림 A는 전형적으로 기술 컴포넌트에 중점을 맞춘 아키텍처를 보여준다. 기술 중심적 모델의 아주 좋은 사례인 이 솔루션은 데이터베이스 기술, 통합 기술, CRM/ERP 애플리케이션 등으로 구성돼 있다.
이런 관점의 배경 원인은 대체적으로 기업들이 기술과 애플리케이션을 판매하는 벤더들로부터 소프트웨어를 구매함으로써 비즈니스를 수행해왔기 때문이다. 이런 관행은 일정한 비즈니스 모델을 수행하는데 있어 특정 기술이나 애플리케이션만이 적합한 기능성을 제공할 수 있다는 사고에서 비롯되고 있다.
이와 같은 접근법에는 분명 부정적인 측면이 존재한다. 바로 특정 애플리케이션에 있어 비즈니스 모델을 그 소프트웨어에 적합하도록 변형해야 하는 경우가 빈번하게 발생한다는 것이다.
이것은 IT 솔루션의 중심을 비즈니스 모델에서 떼어놓고 기술 측면에만 맞췄기 때문이다. 때로는 좋은 기술을 얻기도 하고 좋은 결과를 낳기도 하지만 대부분의 경우 비즈니스에서 필요로 했던 결과를 얻지 못하게 된다.
다수의 App.으로 구성되는 비즈니스 프로세스·서비스
단 하나의 애플리케이션이 비즈니스 상의 수많은 필요들을 충족시켜 줄 수는 없을 것이다. 비록 이런 애플리케이션이 거대한 ERP 솔루션이라 할지라도 여전히 해당 비즈니스에 꼭 필요한 특정 기능을 시스템 내에서 제공하지 못하는 격차가 있기 마련이다.
따라서 대다수 비즈니스는 비즈니스 프로세스를 실행하고 비즈니스 모델을 현실화하기 위한 다수의 애플리케이션을 필요로 한다.
서비스는 위에서 아래로 보여지는 것처럼, 비즈니스 프로세스의 견지에서 볼 때 기술적 관점이라 할 수 있다. 즉 사용 가능한 기술에 의해 추구되는 비즈니스의 통상적인 시각에서는 배치되는 것이다.
애플리케이션보다 비즈니스에 더 밀접한 서비스
‘서비스’를 사용할 때 이점은 몇가지가 있다. 우선 서비스는 비즈니스 프로세스와 밀접한 관련을 맺고 있기 때문에 비즈니스 모델을 보다 정확하게 구현한다. SOA 솔루션을 실행하는 것은 비즈니스를 정의하는 것이 아니라 비즈니스와 교류함으로써 비즈니스에 대한 지원을 더욱 강화할 수 있도록 지원하는 것을 말한다.
애플리케이션 중심의 모델에서 비즈니스는 애플리케이션이 수행할 수 있는 작업 영역만으로 그 기능이 제한된다. 그러나 SOA 모델에서는 서비스와 함께 애플리케이션도 비즈니스를 지원하며 그 사이의 격차는 다른 애플리케이션에 의해 채워진다.
비즈니스 프로세스에서 서비스 도출
SOA를 정의하는 것은 만만한 작업이 아니다. 여기에는 원칙적으로 수많은 분석, 전략, 그리고 비즈니스에 대한 이해가 상당 수준 요구된다.
대다수 SOA 모델들은 비즈니스 모델을 구성하는 프로세스와 컴포넌트를 정의하는 엔터프라이즈 프레임워크의 청사진을 기반으로 구축된다.
엔터프라이즈 비즈니스 프레임워크
엔터프라이즈 프레임워크는 비즈니스 모델을 매우 높은 수준에서 이해하는 방법론이다. 그림 B에서 볼 수 있는 것처럼 이 작업은 비즈니스 프로세스의 분류와 이들이 어떻게 조직되는 지에 대한 방법론을 정의하고 있다. 보다 성숙한 환경에서는 프레임워크 컴포넌트들의 우선순위까지 정의할 수도 있다.
프레임워크는 비즈니스 모델을 구성하는 컴포넌트를 보여주는 것으로 기업 외부의 구성물까지 포함할 수도 있다.
진정한 비즈니스 모델은 진공 상태에서 동작하진 않는다. 따라서 엔터프라이즈 프레임워크는 파트너 연계점, 고객, 벤더, 그리고 비즈니스 모델을 창출하기 위해 상호작용하는 기타 요소까지 모두 망라해야 한다.
위 모델에서 고객 부분은 ‘프런트 오피스’ 컴포넌트와 상호작용하는 반면 벤더와 파트너 부분은 아직 ‘확장 오피스’(extended office) 컴포넌트에 잡혀있다.
엔터프라이즈 프로세스
엔터프라이즈 프로세스란 비즈니스 모델 내의 컴포넌트에 활력을 불어 넣어주면서 보다 분명하게 상호 관계를 정의하는 것으로 엔터프라이즈 프레임워크를 가로질러 순환하는 공기와도 같다.
하나의 프로세스는 비즈니스 모델과 상호작용하는 한 특정 모델을 정의한다. 예를 들어 회계는 프레임워크의 한 컴포넌트일 수도 있다. 하지만 클라이언트에게 송장을 발급하는 것은 비즈니스 프로세스에 해당한다.
서비스를 정의하는 목적은 비즈니스 프로세스를 지원하기 위해서다. 프로세스 전반에 걸쳐 프로세스의 진행과 논리를 촉진시키기 위해 다양한 서비스들이 필요하다. 비즈니스 프로세스를 이해하는 것은 서비스를 정의하는 데 핵심 열쇠다.
내부 요소
많은 프로세스가 조직에 대해 내적인 성향을 띤다. 프레임워크 안에서 이러한 프로세스들은 기업의 지향점을 지지하고 있다. 내부 프로세스는 단지 내적인 서비스만을 사용한다.
외부 요소(B2B)
일부 프로세스는 다른 조직과 상호작용해야 한다. 이러한 외부 지향 프로세스는 B2B 통합이란 문제를 한층 부각시키고 있다. 외부 지향 프로세스는 내/외부 서비스의 조합 형태를 사용한다.
비즈니스 프로세스에 적합한 서비스 할당
SOA 설계라는 도전은 비즈니스 모델을 지원하는 유용한 일련의 서비스 집단을 만드는 것이다.
아키텍처에서 서비스가 정의됐다고 해서 당신이 실행하려는 프로세스를 정의하는 것은 아니다. 오히려 비즈니스 프로세스가 당신이 필요로 하는 서비스가 무엇인지를 정의한다. 덧붙여 단일 서비스 하나로는 만족스러운 것이 될 수 없다. 바로 서비스 사이의 상호작용이 비즈니스 프로세스의 실행을 창출하는 요소다.
비즈니스 프로세스를 지원하는 서비스의 정의
엔터프라이즈 프레임워크는 비즈니스 모델의 컴포넌트들을 정의하며 또한 엔터프라이즈 프로세스는 해당 모델 컴포넌트 사이의 관계와 상호작용 등을 정의한다. 기술, 애플리케이션은 계층을 한창 훑고 내려가는 반면 서비스는 비즈니스 프로세스를 실현하는데 필요한 다음 계층을 하향 조정해 제공한다.
프로세스를 실현하기 위한 서비스간 안무
서비스는 각각 분리된 컴포넌트로, 관계의 관점에서 정의돼야 한다. 하나의 프로세스가 단일 서비스만을 사용하는 경우는 거의 없다. 대신 다양한 방법으로 다중 서비스를 사용하게 된다.
서비스간의 상호작용은 ‘안무’라고도 부를 수 있다. 일련의 조화로운 서비스간 상호작용은 비즈니스 프로세스 실행이란 대명제를 실현해줄 것이다.
애플리케이션 관점에서 서비스 조망
서비스는 매우 단순하게 말할 때 애플리케이션과 기술 위의 개념이라 할 수 있다. 이것은 이미 변화하고 있는 기술과 민감한 비즈니스 모델 사이의 논리적인 분리 방법을 제시하고 있다.
SOA의 정의에 있어 다음 단계로 익혀야 할 것은 서비스와 애플리케이션 사이의 관계를 이해하는 것이다.
카탈로그 애플리케이션 - 세부 기능
애플리케이션은 서비스를 구축하는데 있어 토대가 된다. 이들은 때때로 설정 가능한 특정 기능들을 제공한다. 애플리케이션들을 아우르는 서비스 계획을 구상하기 이전에 현재 보유한 애플리케이션들이 어떤 기능들을 제공하는지 먼저 이해해야 한다.
기업들은 이메일부터 이동성 평가까지 다양한 분야에 걸친 복합적인 애플리케이션들을 보유하고 있다. 이러한 애플리케이션들을 통해 어떠한 작업이 가능한지 살펴보는 것이 현재의 서비스를 통해 무엇이 가능하고 가능하지 않은지 가늠할 수 있는 첫번째 작업이 될 것이다.
부족한 기능의 보완
만약 당신이 운이 좋다면 보유한 애플리케이션으로 비즈니스 모델을 실현하는데 필요한 모든 기능을 구현할 수 있을 것이다. 그러나 불행하게도 이런 경우는 거의 없다. 많은 기업들은 현재 보유한 애플리케이션으로 서비스를 제공해봐야 80% 수준에 그친다는 것을 잘 알고 있다.
하지만 원하는 기능에 대한 모색은 비즈니스 모델을 구현하기 위해 여전히 필요한 부분이다. 이처럼 부족한 기능에 대해서는 아키텍처 내에 격차를 메워줄만한 특별한 프로그램을 정의하는 방법으로 해결할 수 있다.
SOA의 컴포넌트
하나의 서비스 아키텍처는 다음과 같은 3가지 주요 컴포넌트들로 구성된다.
첫째는 실제 서비스인 서비스 제공자다. 다음은 서비스 요청자로 서비스에 접근하는 컴포넌트를 의미한다. 마지막으로 서비스 에이전시는 등록 및 서비스 발견 등의 역할을 담당하는 부분이다.
그림 C는 이런 컴포넌트의 역할을 그림으로 표현한 것이다.
서비스 제공자
서비스 제공자는 서비스 기능성의 원천이 된다. 이 부분은 요청자가 서비스에 접근하기 위해 사용하는 인터페이스 규약을 출판한다. 이 규약은 서비스가 하는 업무와 그에 대한 접근 방법 등을 정의한다.
서비스 요청자
서비스 요청자는 서비스에 대한 클라이언트 개념이다. 이 부분은 에이전시를 활용해 어떤 서비스가 가능한지 알아본다. 일단 서비스가 배치되고 나면 서비스 요청자는 에이전시로부터 인터페이스 규약에 관한 정보를 받아오게 된다. 클라이언트는 인터페이스 규약을 통해 서비스에 접근하는 방법을 이해한다.
서비스 에이전시
서비스 에이전시는 가용한 서비스의 레지스트리라고 할 수 있다. 각각의 서비스 제공자는 서비스를 위치시키기 위해 사용하는 정보와 함께 에이전시에 대한 인터페이스 규약을 출판한다. 요청자는 적절한 서비스에 대해 에이전시를 검색해 인터페이스 규약에 관한 정보를 받는다.
프레임워크 구축
지금까지 SOA에 대한 정의와 아키텍처 방법에 대해 검증해 보았다. 다음 단계는 웹서비스의 아키텍처를 실현하는 방법을 이해하는 것이다. 다음에는 웹서비스가 서비스 요청자, 서비스 제공자, 그리고 서비스 에이전시 등에 대해 프레임워크를 제공하는 방법론에 대해 알아보자. @
