서형석
한국사이베이스 차장
<Hyung-suk.Suh@sybase.com>

EAI는 엔터프라이즈 애플리케이션 인티그레이션의 약자로 발음만큼이나 어려운 개념이다. 또 STP(Straight Through Processing)나 B2Bi, 최근 많이 사용하는 eAI(e-Business Application Integration)에 이르기까지 서로 비슷한 개념들이 혼란을 가중시키고 있다.

이에 EAI와 나머지 용어들을 비교하면서 EAI 개념에 확실히 접근하는 한편 인프라 구축을 위한 기술 요소들을 비교 설명하도록 하겠다. 먼저 STP는 주로 금융권을 중심으로 많이 논의되고 있다. 즉 외환, 증권 등 금융거래에 있어 사람의 개입을 최소화하여 거래와 결제 기간을 단축하고 실수를 최소화하기 위해 사용한다. 국제 거래에서 중요성이 더욱 강조되고 있다.

외환거래를 위한 SWIFT(Society for Worldwide Interbank Financial Telecommuni-cations)나 최근 증권사를 중심으로 활발하게 구축이 논의되고 있는 FIX(Financial Information eXchange)프로토콜은 앞으로 국제화 시대의 글로벌 표준으로 금융 기관에서는 필수 시스템으로 자리잡고 있다. 이밖에 대고객 금융서비스 통합을 위한 OFX(Open Financial eXchange) 등이 STP를 위한 국제 표준으로 자리잡고 있다. 이들을 활용한 금융권의 STP 도입은 다양한 응용프로그램을 통합한다는 EAI의 개념과 매우 유사하며 일부 솔루션들은 그 영역을 금융권EAI까지 확대하고 있다. 실제로 금융권이 EAI인프라를 구축할 경우 기존 솔루션은 정보계성 업무를 중심으로 구축할 수밖에 없는 한계가 있는 반면 FIX, OFX 등을 활용한 금융전문 STP는 주문을 포함한 계정업무까지 통합 영역을 확대할 수 있는 특징이 있다.

B2Bi·eAI·EAI의 구분

B2Bi는 문자 그대로 기업간의 데이터 및 업무 프로세스의 통합을 말하며 EAI와는 여러가지 차이점이 있지만 최근 들어 그 차이가 모호해지고 있다. 특히 기존에 두가지 개념을 구분하는 기준으로 사용되던 웹과 XML이 기업내부에서도 사용하게 되면서 차이점은 점점 없어지고 있다. 이제 EAI와 B2Bi를 구분할 수 있는 가장 확실한 기준은 인프라에 대한 통제권이라고 하는 것이 현실적이다. 즉 데이터 전송을 위한 매개체로 어떤 방법을 사용할 것인가의 문제이다. 데이터를 주고받기 위해 메시지큐잉시스템이나 버스시스템 등을 표준으로 선택해 사용할 것인가 아니면 http, SOAP 등 일반적인 규약을 사용해 상대방과 통신할 것인가에 대한 것이다.

EAI와 eAI는 똑같아 보이지만 차이점이 있다. 전자의 ‘E’가 기업내 또는 전사적이란 뜻을 갖고 있는 엔터프라이즈인 반면 후자의 ‘e’는 ‘e-비즈니스’를 뜻하기 때문에 eAI는 작게는 e-비즈니스 애플리케이션 인티그레이션, 즉 B2Bi의 영역을 주로 통합하는 경우이고 크게는 EAI를 포함한 통합 영역을 뜻한다고 할 수 있다. 전송매개체는 기업의 전사적인 시스템들을 유기적으로 통합하는 인프라인 EAI의 동맥과 같은 인프라라고 할 수 있다. 최초 EAI가 탄생하는 계기가 되었던 것도 이런 메시징 인프라를 통합하기 위한 용도로 사용됐다고 해도 과언이 아니다. 전송매개체로 주로 사용되는 것으로는 메시징큐잉시스템과 메시지버스시스템 등 여러 가지가 있다. 그 중 가장 보편적으로 사용되는 메시징큐잉방식과 메시지버스방식에 대해 주로 알아보자.

두가지 방식 모두 기업내에서 데이터를 쉽고 안전하게 전송할 목적으로 만들어 졌으며 이후 이들 MOM(Message Oriented Middleware)를 통합하기 위해 MOM통합서버로 출발한 것이 EAI의 시초라고 할 수 있다. 메시징큐잉시스템의 대표격인 IBM MQ시리즈는 가장 많은 플랫폼을 지원하며 실제 EAI인프라 구축을 위해서도 가장 많이 사용되고 있다. 메시징큐잉시스템의 가장 큰 특징은 ‘큐’라는 시스템의 메모리 또는 디스크상의 매개체를 통해 서로 통신하며 작업단위를 큐를 중심으로 분할하여 메시지 전달을 보증해 준다.

예를 들어 두개의 분산되어 있는 응용프로그램에서 데이터베이스를 갱신하는 OLTP(On-Line Transaction Pro

cessing) 업무의 경우 원천 데이터베이스에 대한 갱신이 이루어지고 대상 데이터베이스가 갱신된 후에 양쪽 데이터베이스를 모두 확인해야 단위작업이 끝나게 된다. 그러나 MOM을 이용하는 경우는 원천 데이터베이스 갱신후 한단위 작업 종료, 큐를 이용해 데이터 전송 후 한단위 작업을 종료하고 대상 데이터베이스 갱신 후 한단위 작업을 종료하게 된다. 즉 MOM을 사용할 경우 완벽하게 두 데이터베이스가 일치하진 않지만 시차를 두고 일치하게 되는 비동기방식이다. 물론 동기방식으로 MOM을 사용할 수도 있지만 분산시스템의 독립성 보장이라는 EAI의 취지와는 맞지 않는다.

만약 반드시 동기방식으로 처리해야할 단위업무가 있다면 MOM의 요청/응답 방식을 사용하든지 아니면 최근 많이 사용되는 프로세스 관리를 통해 MOM의 비동기성이 갖고 있는 약점을 어느 정도 보완될 수 있다. 메시지큐잉방식을 사용할 경우 분산시스템의 큐관리자와 여러가지 큐를 설계해야하며 응용프로그램 또는 어댑터에 사용될 큐 관련 정보를 정의해야한다. 일단 분산시스템에 대한 큐설계와 정의가 완료되면 큐를 매개로 하는 데이터의 전달은 가장 확실하게 보장받을 수 있다.

이 방식은 초기에 설계 및 정의에 노력이 필요하지만 큐와 큐간의 통신을 확실히 보장하며 네트워크의 부하도 최소화할 수 있는 장점이 있다. 반면 메시지버스방식은 퍼블리시/스크라이브 메커니즘을 기본으로 하고 있다.

이 방식은 원천시스템에서 버스에 메시지를 전송하면 대상시스템에서는 필요한 데이터를 받아 가는 방식으로 메시지버스에 참여하는 분산시스템들이 쉽게 데이터를 주고받을 수 있고 버스방식 자체가 로드 밸런싱을 해 주기 때문에 이를 위해 별도의 클러스터링을 하지 않아도 되는 장점이 있다. 그러나 원천시스템에서 대상을 정하지 않은 상태에서 버스에 데이터를 전송하기 때문에 네트워크에 많은 부하를 줄 가능성이 높다. 이 두가지 전달방식의 경우 각각 장단점이 있으므로 필요에 따라 선택하여 구축할 필요가 있다.

보통 통합서버, EAI서버, EAI허브 등으로 불리는 것에 대해서 알아보면 분산돼 있는 각종 응용프로그램들을 통합한다는 의미와 논리적으로 마치 네트워크와 흡사하기 때문에 허브라고도 불린다. 국내에서는 최초의 EAI구축으로 알려져 있는 S전자의 당시 프로젝트명에서부터 많은 사람들이 허브라는 단어를 사용하기 시작했다. 여기서는 통상적으로 사용되는 EAI서버라고 통칭한다. 앞서 언급한 전송매체를 포함해서 EAI인프라를 구축하기 위해서는 EAI서버, 어댑터, 프로세스 관리시스템, 모니터링시스템 등이 필요하게된다. 그러나 실제 여러 업체들이 제공하는 EAI솔루션을 살펴보면 여기에서 분류해서 사용하는 기능영역이 분명치 않는 경우가 많다. 즉 이 글에서 제시되는 분류들은 EAI분야에서 가장 많이 참조되고 있는 컨설팅사의 분류에 따른 설명이기 때문에 시장에 나와있는 솔루션들의 경우 여러 기능들이 혼재돼 구별하기 힘든 경우가 있을 수 있다. 다만 구조상의 문제는 기능상의 그것과는 달리 선택에 신중을 기해야 한다.

<그림 > 허브&스포커 vs 1:1 매핑

EAI서버의 주요 기능

EAI서버의 주요 기능으로는 데이터를 가공 처리하는 포매터, 룰을 적용해 데이터를 분배해 주는 라우터가 있다. 흔히 EAI에서 허브&스포커 방식이라고 얘기하면 이는 포매터의 구조를 말하는 것이다. 단순히 살펴보면 모든 EAI인프라는 허브&스포커 방식인 듯 보이고 EAI인프라 구축전의 모습을 일대일 방식이라고 생각하기 쉬우나 그렇치 않다. 인프라 구축전의 경우 당연히 포매터가 존재하지 않기 때문에 일대일방식이라고 말할 수 있고 포매터를 도입하더라도 두 가지 방식은 존재하게 된다. 실제상황에서 두 가지 방식 중 어떤 방식이 더 좋다고 말하기는 상당히 어렵다.

허브&스포커 방식의 경우 기본적으로 EAI인프라 내의 모든 응용프로그램들은 데이터 포맷에 관해서는 EAI서버의 포매터와의 관계설정을 통해 데이터를 주고 받는다. 대상 응용프로그램들과 포매터와의 정의는 보통 데이터베이스를 리파지토리로 사용하게 되며 변경사항들은 데이터베이스 갱신을 통해 이루어진다. 이렇게 즉각적인 변경사항 반영이 가능한 경우와는 달리 설정된 관계를 코드화하여 사용할 경우 변경되면 재코드화해야 하기 때문에 즉각적인 반영이 힘들어 진다. 반면 포맷설정을 데이터베이스에서 읽어와 처리하는 방식과 달리 코드에서 처리하기 때문에 성능상의 이점을 가질 수도 있다.

다음으로 EAI서버로 들어 온 데이터를 분배하는 방식이다. 룰을 기반으로 하는 라우팅 기능을 갖고 있는 경우에는 입력된 데이터의 특정 필드 값을 확인하여 설정된 룰에 의해 필요한 대상 응용프로그램으로 데이터를 전송할 수 있다. 그렇지 못한 경우는 앞서 설명한 코드를 생성하는 포매터처럼 코드에 라우팅 관련 정보를 포함해야 하며 다양한 룰 변경에 대응하기 어려워진다. 룰 기반이란 다수의 특정 조건식의 결과를 사용해 새로운 동작을 발생시킬 수 있는 기능으로 EAI서버의 포매터와 라우팅과 관련해선 룰에 의한 포맷 변환과 데이터 라우팅을 가능하게 해 주는 역할을 한다.

어댑터의 역할

인프라에 포함시킬 응용프로그램에 대한 인터페이스를 위해 필요한 것이 흔히 어댑터라고 불리는 것으로 커넥터, 게이트웨이라고도 한다. 어댑터의 역할은 크게 두 가지로 정리할 수 있다. 첫째, 대상시스템으로부터 데이터를 추출하여 전송매체, 즉 MOM까지 전달하는 역할이다. MOM을 통한 비동기 처리일 경우 단위업무의 종료가 MOM에 전달될 때까지가 매우 중요하기 때문에 어댑터를 통해 데이터를 추출할 경우도 이점에 유의해야 한다.

둘째는 추출할 데이터에 대한 포맷스키마로 이는 EAI서버의 포매터 리파지토리로 로드된다. 보통의 경우 데이터를 추출하기 위해선 데몬형식의 프로세스를 사용하고 스키마를 위해선 시스템에 로그온하게 된다. 클라이언트가 서버응용프로그램을 사용하는 원리로 스키마를 추출하게 된다.

어댑터의 종류와 수준으로는 SAP, 시벨, i2테크놀로지 등의 패키지에서 데이터를 추출하고 포맷스키마를 포매터에 로딩해 주는 최상위 수준으로, 어댑터 없이 통합하기 가장 어려운 반면 구축 후 가장 큰 효과를 나타낼 수 있다. 보통 SAP R/3의 경우 ALE/IDOC, BAPI, RFC, ABAP 다이렉트 서버 등 동기/비동기 방식의 인터페이스를 모두 지원하거나 일부를 지원하게 된다. 시벨의 e-비즈니스 애플리케이션은 COM과 EIM을, i2의 리듬은 CDM을 지원하는 기능을 제공한다.

다음으로는 응용프로그램에서 데이터를 추출하는 방식이 어려울 경우 사용되는 데이터베이스, 파일, 프로토콜, 3270, 웹 애플리케이션 서버(WAS) 어댑터 등이 있다. 데이터베이스 어댑터의 경우 네이티브 또는 ODBC 드라이버를 이용하는 접근을 제공하고 추출한 데이터를 MOM에 전달하며 포맷스키마를 포매터에 전달하는 역할을 한다. 데이터베이스 어댑터의 경우 어느 시점에 데이터를 추출할 것이냐에 대한 문제가 있다. 즉, 갱신을 즉시할 것인가 아니면 일정한 주기를 가지고 추출할 것인가를 기능으로 제공하는가를 살펴봐야 한다. 이런 종류의 어댑터는 많은 솔루션 벤더들이 사용하고 있지만 응용프로그램 차원의 데이터가 아닌 데이터베이스, 파일, 화면 등을 추출하기 때문에 때로는 데이터의 정합성 문제를 야기시킬 수 있다.

마지막으로 사용하기에 따라선 광범위한 영역에서 사용할 수 있는 툴이 ADK(Adapter Development Kit)이다. ADK 역시 다른 어댑터처럼 두 가지 모드로 작동한다. 획드모드는 원천시스템으로부터 데이터를 추출하는 역할을 한다. 원리는 클라이언트로 서버프로그램을 사용하는 것과 같다. 다음으로 전송모드는 문자 그대로 추출된 데이터를 전송매개체에 전달하는 영역이다. 동작 원리는 MOM의 API를 사용하여 추출한 데이터를 전달하고 확인한다. 그밖에 어댑터와 포매터의 작업을 원활히 해 주는 역할을 해 주는 관리툴이 제공되기도 한다. 이 관리툴은 추출할 포맷스키마를 검색하거나 필터링해 주며 포매터에 로딩/언로딩, 실제 사용하는 포맷인지 여부를 검증해 주기도 한다.

<그림2> 어댑터와 구축효과

EAI인프라로서 EAI서버

프로세스서버와 모니터링에 대해 살펴보면 일반적으로 프로세스서버라고 하면 업무의 흐름을 관리해주는 서버로 WMS(Workflow Management System), 전자문서관리시스템(EDMS) 등과 혼재해서 사용해 구별이 안가기도 하지만 EAI인프라 관점에서 보면 두 가지 정도로 정리할 수 있다. 첫째는 EAI서버 내의 메시지 처리 프로세스를 제어하는 역할이고 두번째는 영역을 전체 인프라로 넓혀 어댑터에서 데이터를 추출해서 MOM으로 전달하는 작업부터 EAI서버에서 데이터를 가공처리해 다시 대상시스템에 어댑터를 통해 데이터를 로딩하는 작업까지의 과정을 모두 관리하게 된다. 이 경우 각각의 작업단위들은 프로세스서버의 관리작업 단위로 정의되고 어댑터 등은 프로세스서버의 제어프로그램으로 정의된다. 특히 프로세스 서버를 통해 완벽하게 제어되는 인프라를 구축하게되면 프로세스 인스턴스 모니터링과 감사 및 각종 로그 등 프로세스 서버가 기본적으로 제공하는 여러가지 관리툴을 사용할 수 있는 장점이 있다.

만약 모니터링 등 감시 툴을 제공받지 못하면 추가적인 도입을 검토해야 하며 이때는 단순히 데이터의 전달 상태만을 모니터링할 뿐만 아니라 MOM의 상태와 MOM을 통해 전달되는 데이터까지 감시할 수 있는 툴을 사용하면 여러가지 관리체계를 구축할 수 있는 장점이 있다.

<그림3> 어댑터 개발 킷

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