SOA 실현의 핵심, ESB

SOA 실현의 핵심, ESB

최근 서비스 지향 아키텍처(SOA) 가 엔터프라이즈 분야에서 핫 이슈로 떠오름에 따라 이를 실현하기 위한 핵심 미들웨엉인 ESB(Enterprise Service Bus)가 많은 개발자들에게 주목받고 있다. ESB란 미즈니스 내에서 서비스 ,애플리케이션, 자원을 연결하고 통합하는 미들웨어라고 할 수 있으며, 이를 통해 분산된 서비스 컴포넌트를 쉽게 통합 연동할 수 있어 신뢰성 있는 메시지 통신이 가능하다. IT 통합을 위한 인프라스트럭처로 새롭게 부상하고 있는 ESB가 오늘날 엔터프라이즈 환경의 문제를 어떻게 해결해 줄 수 있는지 그 주요 기술과 제품을 통해 살펴보자

 

특집 1부	기업 환경 통합을 위한 해법, EAI에서 ESB까지
특집 2부	자바 ESB 기술의 현주소
2-1	ESB 패턴 구현을 통해 본 IBM ESB
2-2	전사 IT 환경을 위한 BEA의 ESB, 미뉴
2-3	자바 ESB 표준의 삼총사 JBI,SCA,SDO
특집 3부	JBI 구현을 우한 오픈소스 ESB, ServiceMix
특집 4부	ESB의 비판적 대안, MS WCF와 비즈토크 서버

 

기업 환경 통합을 위한 해법 EAI에서 ESB까지

 

김민호｜프로그래머

 

SOA와 그 토대가 되는 ESB는 분명 최근 IT의 화두이다. 그러나 IT의 화두들은 언제나 그렇듯 하위호환성의 근간을 두며 전혀 새로운 것이 아닌 EAI나 APS 등에서의 흐름과 통하는 것이라 할 수 있다. 특집 1부에서는 EAI의 도입 초기부터 시작하여 ESB의 개념이 나오게 된 동기와 개념에 대해 알아보고자 한다.

 

기업 환경의 변화는 분명 필수불가결한 결론에 다다르게 된다. 필요에 의해 하나둘씩 생긴 시스템들은 서로 인터페이스를 하게 되고, 또한 어쩔 수 없는 중복도 생기게 된다. 이런 혼잡한 기업 환경에서 ESB(Enterprise Service Bus)는 최적화된 기술 구조를 제공해주며, 유지보수의 편리성과 기업의 신속한 의사결정의 기반이 된다.

 

기업 환경의 확장

 

기업 환경만큼 IT의 흐름에 민감한 환경 또한 없을 것이다. 더군다나 우리나라의 기업 환경은 획일적일만치 IT 흐름의 정석을 따르고 있다. 그동안 한 기업 내에는 수많은 시스템들이 구축되었다. 그룹웨어 시스템을 비롯하여, CRM(Customer Relationship Manage ment)과 ERP(Enterprise Resource Planning)는 어느 정도 이상의 규모에서는 모두 구축되어 있다고 봐도 과언이 아닐 것이다.

 

이런 기업 환경은 구축된 시스템 간의 데이터에 대한 동기화와 비즈니스 요구사항을 빠르게 반영하기 위해 분명 변화해야 하는 필요성이 생기게 된다. 대부분이 SI(System Integration) 형태로 진행된 단위 프로젝트이고 보면, 다른 시스템과의 연계성이나 전체 기업 환경의 구조까지를 생각하고 진행하게 되는 경우는 그리 많지 않았다.

 

또한 IT 기술적인 변화는 결코 현재 운영 중인 시스템에는 영향을 주지 않은 상태여야 하고, 이런 통합 작업은 <그림 1>과 같은 형태의 Point-to-Point 방식으로 진행되는 경우가 많았다. 이는 간단한 연동일 때 빠른 적용이 가능하고, 복잡하지 않은 환경에서는 적용이 가능한 형태라고 할 수 있다. 그러나 다음과 같은 단점들이 있다.

 

◆ Point-to-Point 방식의 연결로 인한 시스템 독립성이 보장 불가
◆ 시스템 변동시 과다한 수정사항 발생
◆ 프로세스의 변경 곤란(Ripple Effect)
◆ 비즈니스 로직의 재사용 불가
◆ 시스템 간 정보 흐름의 지체현상 발생

 

이런 단점들 때문에 어느 정도 이상 규모의 기업 환경에서는 더 큰 문제가 되기도 한다. 따라서 <그림 2>와 같은 좀 더 통합적인 관점에서 EAI(Enterprise Application Integration)의 도입이 진행되었던 것이다. 즉 EAI가 중심이 되어 인터페이스될 여러 시스템들이 EAI를 통하게 됨으로써 각 레거시 시스템은 EAI를 위한 단일의 인터페이스 형태만으로도 여러 종류의 레거시 시스템과 연동할 수 있게 된다. 뿐만 아니라 이런 중앙 집중 형태의 EAI는 미들웨어의 특징을 가지며, 데이터의 변환, 역할(Rule) 기반의 프로세싱, 트랜잭션의 무결성을 제공한다. 장점이 되는 특징들은 다음과 같은 것들이 있다.

 

◆ 단순 아키텍처 지향으로 재사용율을 높임
◆ 신규 애플리케이션 도입시 확장 용이
◆ 개발 편의성 증대
◆ 유지보수 편의성 증대
◆ 에러발견 및 로깅 , 복구의 편의성 증대

 

결국 <그림 1>의 전통적인 스파게티식의 인터페이스 방법은 <그림 2>의 방식으로 변경되었을 경우 개발과 운영 측면에서 2/3의 절감 효과를 기대할 수 있다.

 

<그림 1> Point-to-Point 방식의 통,인터페이스가 스파게티식으로 어지럽게 엮여져 있는 기업 환경

 

EAI의 대두

 

현재까지 이렇게 다양해지는 기업 환경을 통합하는 최선의 선택은 EAI이다. EAI는 e비즈니스를 구현할 때 기존 시스템과 단기간에 유기적으로 통합할 수 있는 비즈니스 통합 솔루션으로써의 역할을 수행할 수 있기 때문이다. 이렇게 EAI를 도입함으로써 시스템 통합에 대한 과다한 비용을 해소하고 여기저기 흩어져 있는 정보 자원을 효율적으로 사용할 수 있게 되며, 기업 내 시스템의 효과적인 통합을 통한 민첩하고 경쟁력 있는 기업으로의 성장이 원활하게 되는 것이다.

 

EAI 프로젝트는 기업 환경의 획기적인 변환 시점에 즈음하여 대개는 거론 또는 구축되는 경우를 많이 보는데 이는 그저 시스템 하나 둘 정도 늘어나는 정도의 변화 수준을 넘어 기업 내의 기반 플랫폼이 되는 새로운 시스템의 도입에 EAI가 병행되는 경우가 대부분이기 때문이다. 예를 들어 전사 기반의 ERP라든지 차세대 또는 신 시스템 등의 구축 등 상당히 중요한 시스템의 도입으로 인하여 대대적인 변화가 있는 경우에 대개는 진행되어 진다는 것이다. 과거 진행되었거나, 현재 진행되고 있는 국내의 EAI 프로젝트들은 크게 다음 두 가지로 분류하여 볼 수 있다.

 

◆ ERP 시스템이 도입되면서 전체 시스템에 영향을 미치는 EAI 프로젝트
◆ 차세대 또는 신 시스템 구축을 통하여 EAI가 도입되는 프로젝트

 

ERP가 도입되면서 진행되는 EAI 프로젝트

 

국내에서 ERP가 중심이 되어 EAI 프로젝트가 도입되는 사례를 살펴보면, 여러 산업 분야 중에서도 특히 제조, 통신 부분이 많이 차지하고 있다. 기업에서 새롭게 ERP를 채택하면서 진행되는 EAI 프로젝트는 당연 ERP를 기준으로 주변 시스템들을 재배치 또는 조정하는 모습이 보이는 것이 특징이며, ISP 단계에서 ERP 도입이 결정되면 기존 시스템들은 한편 생사의 기로(?)에 놓이게 되는 것이다.

 

ERP 중 국내에 많은 시장을 확보하고 있는 SAP를 기준으로 살펴보면, SAP ERP에서는 BAPI, RFC 또는 IDoc의 형태로 프로그래밍되며, 이것이 EAI 시스템과 ERP를 연결하는 프로그램 역할을 수행하여 준다. BAPI와 RFC는 동기 형태를 지원하며, IDoc은 비동기를 지원함으로 쓰임새가 좀 다르다고 할 수 있다. 특별히 해당 모듈이 IDoc 기반으로 되어 있지 않은 이상은 RFC를 이용한다고 보면 된다. IDoc은 동작된 것에 대한 모니터링이나 재처리, 주고받는 데이터에 대해 확인할 수 있는 등 많은 기능을 제공하지만, 비동기라는 방식 자체를 선호하지 않는 경우가 많아 ERP 자체적으로는 잘 사용되고 있으나, EAI에서는 그리 각광을 받지 못하는 것 같다는 느낌이다.

 

이런 ERP가 중심이 되는 EAI 프로젝트는 다른 어떠한 프로젝트보다 경험이 중요하다. 분명 EAI 프로젝트 자체가 다양한 레거시의 효율적인 연계를 위한 것이므로 시스템들 전반에 대한 지식을 필요로 하고 있고 따라서 보통은 웹 프로젝트에 비해 기반 기술을 비롯한 다양한 지식을 필요로 하는데 이것은 경험하지 않으면 쉽게 쌓이지 않는 부분이며 무엇보다도 경험을 통한 큰 그림을 가지는 능력이 반드시 필요하다.

 

오랜 시간 ERP를 하던 개발자들은 보통 자신이 속한 모듈의 지식만(?)을 가지고 있는 경우가 많고, 시스템의 관리를 맡는 BC 또한 ERP 외에 부분. 특히나 EAI와 같은 외부 연동 경험이 그리 풍부하지 않기 때문에 전체를 아우르는 EAI 입장에서 이러한 레거시는 물론 좀 더 상위 레벨의 전반 아키텍처를 그리지 않으면 안된다. ERP가 주가 되는 EAI 프로젝트의 장단점은 다음과 같다.

 

<그림 2> EAI, 중앙 집중 형태의 통합 기업 환경

 

<그림 3> 전통적인 인터페이스 방식과 EAI를 통한 인터페이스 방식의 도입효과, EAI의 도입효과 분석

 

<그림 4> EAI, EAI의 엔터프라이즈 미들웨어 프레임워크

 

<그림 5> EAI 프로젝트 종류 1, ERP 중심의 EAI 프로젝트

 

장점
◆ ERP가 주가 됨으로, 전체 아키텍처의 구성이 비교적 간단하다.
◆ ERP 도입으로 인한 컨설팅 진행으로 시스템들이 재정비되며, 프로세스가 효율적으로 간략화되는 경우가 많다.

 

단점
◆ ERP와 연계되는 시스템이 노후화된 경우가 많다.
◆ 연계 시스템의 노후화는 EAI 시스템의 부하를 증대시키고 전체 트랜잭션에 영향을 주게 된다.
◆ ERP 컨설턴트에 의해 기획되는 경우가 많고 기존 레거시의 기술적인 분석이 부족한 경우가 많음
◆ ERP 프로젝트 일정에 EAI가 속하게 됨으로 자체적인 프로젝트 일정이 의미가 없는 경우가 많다.
◆ ERP나 레거시 시스템의 개발자가 외부 연동의 경험이 없는 경우가 많아 EAI 측에서 이를 지원하거나 프로그램 샘플을 제공해야 하는 경우도 있다.

 

<그림 6> 차세대 프로젝트 등에서의 EAI 프로젝트, EAI 프로젝트 H/W 아키텍처 예시

 

ERP가 주가되는 EAI 프로젝트의 개발방법론

 

보통의 프로젝트에서 개발방법론은 ‘요구사항 분석->설계->개발->테스트’와 같은 폭포수 모델을 근간으로 하는 경우가 많다. 프로젝트 초창기 PM이나 컨설턴트에 의해 고객의 요구사항이 분석되며, 아키텍처나 고급 개발자가 설계하고 개발, 테스트하는 형태는 많은 개발자들이 받아들이기에 그리 무리가 없는 형태라 할 수 있다.

 

그러나 필자가 경험한 ERP가 주가 되는 EAI 프로젝트의 경우 이러한 단계별 진행이 거의 불가능하다. EAI 프로젝트의 경우 연계되는 시스템이 적게는 몇 십 개에서 많게는 몇 백 개의 시스템이 되며, 그 시스템들을 담당하고 있는 담당자들 또한 수십 명에 이르기 때문에 인터페이스의 설계가 프로젝트 초창기에 한꺼번에 진행되지 않고, ERP 프로젝트의 개발 일정에 EAI는 설계, 개발 , 테스트가 한꺼번에 이루어지게 된다. 물론 분석의 경우 인터페이스 할 레거시 시스템을 초기에 어느 정도 유추하는 것이 가능하기 때문에 100%는 아니더라도 거의 90% 이상 분석을 마친 상태로 프로젝트를 시작할 수 있다.

 

이런 조금은 다른 개발 방법은 개발자들에게 상당히 큰 스트레스가 된다. 분석/설계된 개발물량에 대한 특정 일자동안 개발하고 테스트했으나, 개발 중에 수시로 해야 하는 테스트와 EAI 단독적으로 진행할 수 있는 테스트가 거의 없기에 각 시스템 담당자와의 시간 약속, 그리고 수정 변경이 빈번이 일어나는 환경 등은 이제껏 경험할 수 없었던 독특하고 쉽지 않은 것이기 때문이다.

 

또한 테스트 부분도 단위 테스트, 통합 테스트, 병행가동 테스트 그리고 성능/부하 테스트 등 빈도가 많은 것은 기본이며 많은 시간을 할애해서 진행해야 하는 부분으로, 사전에 아주 치밀한 계획과 각 부서의 유기적인 협조가 이루어지지 않으면 거의 밤샘을 해야하는 상황까지 자주 연출될 수밖에 없는 것이다.

 

차세대 또는 신 시스템 구축을 통해 진행되는 EAI 프로젝트

 

주로 금융 또는 제2금융권에서 진행되는 경우가 많다. 이런 프로젝트의 특징은 트랜잭션 자체가 상당히 중요하나, 또한 이 트랜잭션을 잘게 나누는 것이 의미 있는 경우가 많으며, 대용량의 데이터를 실시간 또는 배치 형태로 전달하는 것이 중요한 부분을 차지하게 된다. 또한 신뢰성이 상당히 중요해서 EAI 시스템 자체에 대한 장애 복구 방안은 기본이며, 다른 레거시 시스템들에 장애가 발생했을 경우에 대처할 수 있는 방안 또한 중요하게 취급되어 진다.

 

EAI와 ESB 그리고 SOA

 

가트너 그룹의 보고서에 따르면 EAI를 “엔터프라이즈 미들웨어를 인프라로 하여 다양한 이질적 기업적 환경(애플리케이션, 데이터, 플랫폼 및 네트워크 등)을 통합하여 하나의 시스템으로 관리 운영할 수 있는 유기적인 시스템”이라고 정의하고 있으며, 다른 기관에서의 정의 또한 대동소이한 편이다. 하지만 ESB의 경우 다음과 같이 기관마다 차이가 나는 다른 정의를 내리고 있는 것을 볼 수 있다.

 

◆ 느슨하게 결합되었거나 결합되지 않은 구성 요소들 간에 중재적인 관계와 직접 통신을 지원하는 웹 서비스가 가능한 인프라 - Gartner Group

◆ ESB란 표시는 그 제품이 MOM과 웹 서비스 프로토콜 모두를 지원하는 일종의 통합 미들웨어 제품 - Burton Group

◆ 표준 기반 통합 백본, 통합 메시징, 웹 서비스, 변환, 그리고 인텔리전트 라우팅 - Sonic Software

◆ 통신과 연결, 변환, 보안을 위한 표준화된 인터페이스를 구현하는 엔터프라이즈 플랫폼 - Fiorano Software

◆ 쉽게 말해 웹스피어 MQ와 그 밖의 다른 웹스피어 브로커 그리고 통합 서버를 가지고 있다면 당신은 ESB를 가지고 있는 것 - Bob Sutor, IBM

◆ ESB는 인프라 서비스들의 규칙적인 서비스 통합 아키텍처로 정의된 환경 내의 여러 비즈니스 서비스들에 일관된 지원을 제공한다. ESB는 웹 서비스 인터페이스를 사용해 서비스 중심 아키텍처로 구현된다. - CBDI

 

이와 같이 여러 가지 다양한 정의가 나온 것에 대해서 데이비드 채펠(채펠앤어소시에이트 사장)은 다음과 같은 말을 했다.

 

“개인적으로 ESB는 마케팅 개념에 불과하다고 본다. ESB 회사의 최고기술책임자(CTO)로 있는 친구들과 얘기를 해봤는데 사람들마다 의견이 달렸다. 현재 ESB는 자사의 독자 기술을 판매하기 위한 일종의 마케팅 전술이라고 할 수 있다. 그렇기 때문에 ESB에 대한 정의가 제각각인 셈이다.”

 

필자는 EAI라는 개념이 나왔을 당시만 해도 ESB와 EAI는 크게 다르지 않은 거의 같은 개념으로 이해하고 있었다. 다만 SOA (Servic Oriented Architecture)라는 아키텍처가 거의 모든 벤더들에게 마케팅의 중심이 되자, EAI라는 말은 거의 사라졌으며 ESB로 옮겨가고 있었다. 현재 시점에서 EAI와 ESB에 대한 구분은 EAI는 주로 허브&스포크 형태의 중앙 집중 방식이라면 ESB는 동적인 업무 프로세스를 통합하기 위한 버스 형태를 취하고 있다는 점이다. 즉 EAI는 시스템들 사이에 위치하며 각 시스템의 연계를 중심으로 한다면, ESB는 서비스를 중심으로 하나의 업무 프로세스를 진행하기 위해 하나 이상의 시스템을 거치는 운반자적인 역할이 더 중요하다는 것이다.

 

EAI가 대두되면서 기업의 통합에만 중심이 되서 EAI가 독립적으로 각광을 받았다고는 볼 수 없다. EAI가 회자될때쯤 EP(Enter prise Portal)와 함께 APS(Application Platform Suites)도 꽤 비중 있게 다루어졌다. 필자는 예전에 세미나를 통해 EAI를 발표할 기회가 있었는데 분명 EAI 자체적인 것도 중요하게 다뤘지만 이 EAI를 통하여 발전하게 될 기업 환경을 위해 APS에 대해 상당히 무게를 두었다.

 

기업 환경을 통합하는 EAI만으로는 무언가 부족함을 느끼게 된다. 분명 EAI를 통해 기업은 체계화된 데이터와 재사용 가능한 컴포넌트들을 가지게 되었지만, 이것이 적기시장진입(Time-to-Market)을 실현할 수 있는 열쇠는 될 수 없기 때문이다. 실제로 이러한 기본 환경들이 활용되기 위해서는 EP를 통한 UI 환경에서의 통합 또한 중요하기 때문이다.

 

ESB의 특징

 

ESB는 기업 IT 환경에서 중추적인 역할을 수행하는 것으로 각 레거시 시스템과의 연동을 위한 다양한 표준 프로토콜의 지원을 기본으로 재사용 가능한 컴포넌트들을 조립함으로써 서비스 지향적인 기업 환경을 만들 수 있는 기반이 되어야 한다. ESB의 특징으로는 다음과 같은 것들이 있다.

 

◆ 다양한 시스템과 연동하기 위한 멀티 프로토콜 지원
◆ 느슨한 결합(loosely coupled)
◆ 소프트웨어 컴포넌트를 조합하여 서비스를 조립하는 BPM 지원
◆ 이벤트 지향적
◆ 표준 지향적

 

ESB의 구성요소

 

어댑터 형태의 레거시 연동 컴포넌트
ESB는 기본적으로 다양한 표준 프로토콜을 어댑터(Adapter) 형태로 지원해야 한다. 어댑터 형태의 지원이란 소스 형태의 라이브러리가 아닌 통합 개발 환경에서 플러거블(Pluggable)할 수 있는 간단히 연동할 수 있는 형태여야 한다.

 

메시지의 변환, 가공
연동되는 시스템끼리는 서로 다른 형태의 데이터일 경우가 대부분이다. 따라서 데이터 포맷과 형태 등을 통합 개발 환경 등을 통해 자유롭게 변화하고 가공할 수 있어야 한다.

 

BPM
기업에서 필요로 하는 하나의 단위 서비스들은 보통 하나의 시스템과의 연동으로 이루어지는 경우는 그리 많지 않다. 다양한 시스템의 데이터와 애플리케이션과의 연동을 통해 하나의 서비스를 이용할 수 있어야 하고, 이를 위해서 반드시 BPM이 필요로 한다.

 

컨트롤과 모니터링
레거시 시스템과의 연동에서부터 데이터의 변환, 프로세스의 작성 등은 여러 단계를 거쳐 작업되고, 이러한 과정들은 통합적인 조작과 모니터링이 가능해야 한다. 어댑터 단에서의 연결 상태부터 진행되고 있는 프로세스의 상태 및 데이터 값 등이 모니터링의 대상이 될 수 있다.

 

통합개발환경
ESB에서 통합개발환경을 구성요소로 포함시키는 경우는 거의 없다. 하지만 여러 툴을 통하여 개발되거나 툴 자체가 제공되지 않을 경우 개발 효율성은 급격히 떨어질 수밖에 없다. 따라서 통합개발환경은 ESB에서 필요한 요소 중 하나가 되기에 충분하다.

 

<그림 7> ESB, ESB를 도식화한 그림(출처 : IBM Redbooks)

 

SOA에서의 ESB

 

현대 기업에서 가장 필요한 IT적 특성은 민첩성이라고 할 수 있다. 이런 민첩성을 해결할 아키텍처가 SOA이며, SOA를 이루는 핵심 기술이 바로 ESB라고 할 수 있다. SOA가 각광받는 이유는 현재까지 다분히 소극적이었던 IT의 활용이 현재 구축된 기업 환경을 바탕으로 이제 좀 더 많은 이윤을 창출할 수 있는 바탕이 되는 것이기 때문이다. 예전처럼 기업의 서비스를 IT가 받쳐주는 것이 아닌 기 구축된 IT 환경에 의해 새로운 서비스가 탄생되어 이런 서비스로 하여감 기업이 이윤을 창출 할 수 있는 계기를 마련해주는 것이다.

 

예를 들어, 은행에서 하나의 예금상품을 만들 때 담당자가 해당 예금상품을 기획하고 그것을 창구를 통한 서비스가 아닌 인터넷 뱅킹 등의 서비스를 통해 다른 은행에 비해 더 빨리 제공할 수 있다면, 그 은행은 분명 다른 은행에 비해 더 많은 이윤을 창출할 수 있을 것이다.

 

진정한 서비스 지향으로의 ESB

 

진정한 SOA가 구축되기 위해서는 현업에서 서비스를 설계할 수 있도록 하는 구조가 되어야 한다. 보통 서비스를 설계하는 사람들이 실제 기술적인 측면을 이해하는 경우는 극히 드물다고 할 수 있다. 또한 기술적인 기반에서만 서비스를 구축할 수 있다면 그것은 진정한 서비스라고 할 수 없다. 서비스란 철저히 기술과 분리된 개념으로 이루어져서 이제껏 전통적인 방법으로 새로운 상품을 개발하는 것과 동일한 형태로 서비스를 이용할 수 있어야 하는 것이다.

 

많은 기업들이 SOA를 구축하려 시도했고 또한 시도하고 있지만 기술적인 관심사에 압도되어 적정 수준보다 적은 범위의 목표에 집중하기 때문에 현업에서 사용되어야 하는 서비스까지 도달하지 못하는 경우가 대부분이다. 분명 쉽지 않은 일이겠지만 서비스의 정의는 철저히 서비스만을 위한 정의가 되어야 하며, 이렇게 정의된 서비스를 기술에 원활히 접목시킬 수 있도록 기업 IT 환경이 ESB에 충실하게 구축되어야 할 것이다.

 

출처명 : 마이크로소프트웨어 [2006년 3월]