Ø

기술과 응용 측면을 고려한 SOA 도입 방안

관심에 비해 도입 사례 적어… 컴포넌트 기술적 완성 필요

 



임 철 홍 | SK C&C SW공학센터 과장,
전자계산 조직응용 기술사

 

SOA(Service Oriented Architecture)에 대한 기업의 관심이 매우 높아지고 있지만 실제로 도입하기에는 조심스러운 모습을 보이고 있다. 계속 발전하고 검증되고 있으며 SOA를 위한 프로젝트들도 진행이 되고 있기에 머지 않아 SOA가 보편화 될 것으로 예상된다. 하지만 현재 SOA 실현을 위한 장벽이 여전히 존재하고 있다. SOA의 기술(Technology Architecture)과 응용(Application Architecture) 측면을 고려한 도입 방안을 기술했다.

 

기업 환경의 정보 시스템이나 PC에서 활용되는 주요 SW들은 개별적인 단위로 이루어진 프로그램들에 의해서 구성되고 있다. 이들 프로그램의 C/S환경은 업무 단위로, Web 환경은 페이지 단위로 주로 구성이 된다. 또한 개발 단위의 재사용 모듈(DLL)이나 공통 컴포넌트를 활용하며 유틸리티 또는 기본 API 성격을 연계하여 활용하고 있다.

SW 재사용성을 높이기 위한 시도는 현재까지 계속 되고 있으나 크게 성과를 얻지는 못하고 있다. 가장 큰 원인은 개발자 뷰(View)로 제작된 재사용 컴포넌트를 활용하기가 어렵다는 점과 컴포넌트 자체적으로 데이터베이스와 밀접한 연관성을 가지고 있기 때문에 컴포넌트 단위로 다른 정보 시스템에서 활용되기가 어렵다는 점이다. 따라서 사용자 뷰에서도 활용하기가 쉬우며, 데이터베이스에 대한 연관성을 최소화하기 위해서는 기존의 컴포넌트 단위를 비즈니스 단위로 확장한 서비스(비즈니스) 컴포넌트 구축과 이를 연계하는 형태로 구성이 돼야 한다. 이러한 비즈니스 단위의 컴포넌트를 메시지 형태로 연계하는 형태가 SOA이다.

Get Customer, Get Product와 같은 형태가 여러 레거시(Legacy) 시스템의 기능을 조합한 서비스 컴포넌트이며, 이들 서비스 컴포넌트는 특정한 기능을 수행하는 재사용성이 높은 기능 단위로 구성된다. SOA기반 애플리케이션은 이러한 서비스 컴포넌트를 표준 메시지(SOAP)로 연결하여 전체 애플리케이션이 구성된다.

 

SOA기반 애플리케이션의 구성

초기의 SOA 애플리케이션은 웹서비스를 포인트 투 포인트(Point-to-point) 형태로 연결 하는 구조의 형태(Primitive SO A)였다. 모든 연결이 노드(Node)가 증가 할 때마다 증가되어 복잡한 형태를 가졌으며, 기존의 서비스를 재사용 하는 관점에서는 발전적이었지만 이러한 서비스에 대한 유연성은 부족한 형태였다. Networked SOA의 경우는 초기의 형태에서 부족한 유연성과 연결의 복잡함을 해결하기 위해서 ‘Intermediary’를 두고 공통된 버스(Bus) 형태의 통합을 지원하는 형태로 발전하였다. Process-Enabled SOA의 경우는 공통된 버스 기반 위의 서비스들을 체계적으로 모델링 하고 실행하도록 지원하는 프로세스 오케스트레이션(Process Orches-tration) 기반 위에서 동작하는 형태이며, SOA-BPM이 결합된 환경이다.

 

TA(Technical Architecture)측면의 SOA

SOA-BPM기반의 SOA 애플리케이션 구축을 위해서는 레이어(Layer) 구조를 가지는 아키텍처의 구성이 필요하다. 표준화된 통합을 위해서는 웹서비스 기술이 활용되며, ESB와 BPM을 위해서는 프로세스 오케스트레이션 및 워크플로우 기술이 활용된다. 이외에 사용자 UI처리를 위한 X인터넷 및 엔터프라이즈 포털 솔루션이 활용된다.

 

AA(Application Architecture)측면의 SOA

TA측면의 SOA에서 살펴 본 것처럼, SOA 아키텍처는 개별의 서비스가 ESB와 같은 공통적인 Bus에 연결된 모습을 가지고 있다. 이러한 형태의 애플리케이션을 ‘Composite Component’라고 하며, SOA 애플리케이션은 Composite Component가 연동하여 작동하는 형태이다. 각각의 Composite Component는 여러 Service Component로 구성되어 있다. CBD방법론에서 중심적인 컴포넌트가 확장되어 서비스 컴포넌트로 구성된다. 서비스 컴포넌트의 단위는 기술적인 단위보다는 여러 컴포넌트의 조합을 통한 단위 비즈니스 수행이 가능한 형태이다.

SOA 애플리케이션 구축을 위해서는 현재의 업무를 프로세스로 구현하고 이를 다시 서비스 단위의 연결로 표현하는 ‘Ser-vice Decomposition’이 필요하다.

Composite Component 구현을 위해서 프로세스의 분석과 각 Service Compo-nent를 식별하는 작업이 필요하다. 이러한 설계 방법론은 기존의 CBD방법론을 근간으로 하여 확장 발전되었으며, 컨설팅에서 활용 되던 프로세스 모델링 기법과 연결되어 SOA 방법론의 형태로 발전하고 있다.

기업의 업무는 Value Chain으로부터 Mega Process, Process, Sub Process의 형태로 계층 구조를 가지고 있다. Service Component는 Sub Process단위와 같거나 Sub Process의 일부가 될 수 있다. 범 정부 EA에서 정의 하고 있는 서비스 레퍼런스 모델(Service Reference Model)에서도 비슷한 계층 구조를 가지고 있다. 아래 그림은 이러한 계층 구조간의 관계를 기술하고 있다.



 

SOA 도입 방안

SOA 도입을 위해 처음부터 빅뱅 방식에 의한 접근은 다소 위험성이 존재한다. 그 이유로는 베스트 프랙틱스(Best Practice)가 부족한 점과 내부적인 업무를 서비스 컴포넌트화 하는 부분이 단기간 내에 가능한 부분이 아니기 때문이다. 따라서 SOA 도입을 위해서는 단계적인 접근이 필요하다. 초기에는 인터페이스 표준화를 통해 내 외부적인 통합을 중심으로 SOA를 도입하는 것이 바람직하며, 점차적으로 공통 서비스 컴포넌트 구축으로 적용해 나가는 것이 필요하다.

 

- 인터페이스 표준화 (Technical Architecture 중심)

기업 내 외부적인 통합을 위한 환경은 수많은 프로토콜과 표준에 의해서 수행되고 있으며, 실시간적인 처리가 되고 있지 않다. 또한 중앙 집중적인 관리가 되고 있지 않으며, 포인트 투 포인트 연결에 따른 시스템 구성상의 복잡함이 존재하게 된다. SOA를 활용한 인터페이스 표준화는 기존의 EAI와 같은 역할을 하면서 표준화된 메시지(SOAP)에 의한 통합을 수행하는 방식이다. 현재 많은 정보 시스템에서 활용되고 있는 것은 다음과 같은 방법이다. 대부분 DB를 활용하여 Batch에 의존하여 연동하고 있으며, Socket을 활용한 전문 형태의 인터페이스도 많이 활용되고 있다. 이 경우 각 연동 방식에 대한 표준이 없으므로 Case-By-Case로 구축 및 운영되어야 하는 문제점이 발생된다.

SOA 기반 인터페이스 통합을 수행하기 위해 중요한 요소로써 ESB가 있다. ESB는 EAI와 비슷한 역할을 수행하며, 웹서비스 표준을 활용하여 SOA의 관점에서 EAI/B2Bi를 수행하는 미들웨어이다. ESB는 웹서비스 및 어뎁터(JCA 등)를 활용해 내외부 서비스의 연계가 가능하다. <그림6>은 EAI/ESB를 활용하여 다양한 프로토콜 기반의 인터페이스를 표준화 하여 내외부 시스템간의 연동을 지원하는 사례이다. 일반적으로 내부적인 통합을 지원하는 EAI와 대외 채널을 통합하는 MCI(Multi Channel Integration)을 활용하여 인터페이스를 이원화 하는 방안도 많이 활용 되고 있다.



 

- 공통 서비스 컴포넌트 활용(Application Architecture 중심)

인터페이스 표준화는 SOA를 지원하는 기술 아키텍처를 구축하고 내외부적인 통합을 수행하는 방식이다. 개별적으로 존재하는 레거시나 외부의 시스템들과 연계하는 측면에 관점을 두고 있다. 서비스 컴포넌트 구축은 기업의 애플리케이션을 유연하고 재사용성을 높일 수 있도록 컴포넌트 형태로 구축하고 BPM(BPEL)을 통해 프로세스 형태로 구축하고 활용하는 형태다. 기본적인 목적은 CBD와 비슷하지만 이를 비즈니스적인 관점으로 확장한 점이 다르다.

공통 서비스 컴포넌트는 ESB나 Pro-cess Orchestration에 의해서 Composite Component의 형태로 구축되게 되며, 업무 변경이나 환경 변화에 유연하게 대처 가능하다. 또한 기존의 애플리케이션과 유사한 애플리케이션을 구축할 때 중복적인 개발을 막을 수 있고, 공통 컴포넌트에 대한 집중적인 관리를 통해서 효율성을 높일 수 있다.

서비스 컴포넌트들은 프로세스에 따라 조합이 되어 애플리케이션이 완성(앞에서 Composite Component로 설명)되게 된다. 이들은 서로 Loosely Coupling으로 연결되어 있어 유연성이 높다.

다음 그림은 일반 기업에서 활용되는 계약 관리 프로세스를 서비스 컴포넌트를 활용하여 구축한 예이다. CRM, ERP등 개별 애플리케이션에서 활용되는 컴포넌트를 조합하여 서비스 컴포넌트를 구축하고 활용하고 있다. ESB를 활용하여 개별 컴포넌트를 관리하고 연계하여 Composite Component를 구축하게 된다.

Composite Component를 구축하기 위하여 SOA 방법론에서는 서브 프로세스를 구성하는 요소에서 유스케이스를 식별하고 이러한 유스케이스 단위를 서비스 컴포넌트 단위로 식별 하게 된다. 식별된 서비스 컴포넌트는 내부적인 컴포넌트를 식별하여 구별하게 되며 CBD에서 활용되던 방식을 활용하여 설계 및 구축을 수행한다. SOA에서의 애플리케이션 아키텍처는 기존의 방법론과는 달리 기업의 비즈니스 프로세스 및 목표와 직접적인 연관을 가지게 된다. SOA가 비즈니스와 기술의 교차점이 되고 두 가지 요소를 모두 포함하고 있는 모습이 여기에 있다.

 

SOA 이슈 사항

SOA를 구현하기 위한 기술적인 관점에서의 완성도는 높지만, 실제로 구성되는 컴포넌트의 내용을 만들기 위한 기술은 상대적으로 완성도가 낮다. 많은 기업들이 SOA에 관심을 가지고 있으나 실제적인 도입에는 조심스러운 모습이다.

 

SOA 활용을 위한 10가지 제언

1. Divide & Conquer - 가장 재사용도가 높은 비즈니스를 중심으로 순차적으로 컴포넌트를 구축하고 활용 하는 것이 중요하다.
2. Not Solution - 솔루션에 의해서 구축되는 부분보다는 현재의 업무에 기반하여 모델링 되는 부분이 중요하며, SOA를 지원하는 전용 솔루션은 존재 하지 않으며, 여러 솔루션들이 유기적으로 통합되고 동작하도록 하는 것이 SOA 이다.
3. Business & Technology - SOA전문가는 기술 전문가의 관점과 비즈니스 전문가의 관점을 모두 가져야 하며 서로 협력해야 한다.
4. Standardization - 인터페이스 및 구축을 위한 기술을 표준 기술을 수용하여 사용 한다.
5. Invest - SOA를 위한 초기 투자 비용이 많이 들지만, 향후의 재사용을 통해 효과를 보장.
6. Keep Up - 단기간에 구축하여 효과를 보기 어려우며, 지속적인 추진과 노력을 필요로 한다.
7. Not New, Not Magic - SOA가 이전의 기술과 상관없이 갑작스럽게 등장한 개념이 아니며, 이전의 기술을 바탕으로 발전시킨 개념이다.
또한 SOA를 통해 현재의 문제점이 그냥 해결되는 마법이 아니며, 표준화와 체계화를 지향하는 아키텍처 이다.
8. Business Goal - 비즈니스의 Goal과 정보 시스템을 연계하여 비즈니스 목표에 맞도록 Revision하고 성과를 측정, 평가 한다.
9. SOA governance - SOA추진을 위한 별도의 통합 조직과 역할을 필요로 한다.
10. Catch Up - SOA 기술과 솔루션이 빠르게 변화 하고 있으므로, 변화에 유연하게 대응하고 수용해야 한다.


제공 : DB포탈사이트 DBguide.net

출처명: 경영과컴퓨터 [2006년 8월호]