기업 응용 프로그램 통합

3. EAI의 목적 및 유형

기업 응용프로그램 통합(EAI)은 서로 다른 시스템 간의 연결을 통해 조직 내 업무 프로세스를 단순화하고 자동화하는 것을 목표로 한다. 이는 정보 통합, 프로세스 통합, 그리고 벤더 독립성을 확보하는 데 중요한 역할을 한다.

EAI는 다음과 같은 주요 목적을 가진다.

• 정보 통합: 여러 시스템에 분산된 정보를 일관성 있게 유지하고 관리한다. 이는 기업 정보 통합(EII)이라고도 불린다.
• 프로세스 통합: 서로 다른 응용프로그램 간의 비즈니스 프로세스를 연결하여 효율성을 높인다.
• 벤더 독립성: 특정 벤더에 종속되지 않고 시스템을 유연하게 운영할 수 있도록 한다. 비즈니스 규칙을 EAI 시스템에 구현함으로써, 응용프로그램이 변경되어도 규칙을 다시 만들 필요가 없다.

4. EAI의 구조 및 기술 요소

EAI는 여러 다른 시스템 간의 연결을 통해 업무 프로세스를 단순화하고 자동화한다. 이러한 시스템은 서로 다른 운영 체제, 데이터베이스, 프로그래밍 언어를 사용하거나, 더 이상 지원되지 않는 레거시 시스템일 수 있다. EAI는 이러한 시스템들을 '강 종속 시스템(stovepipe system)'이라고 부르며, 수정하기 어려울 정도로 강하게 뭉쳐 있을 수 있다.^[8]

EAI 시스템은 중앙 집중 방식(hub-and-spoke)과 버스 방식 두 가지 주요 구조를 가진다.

• 터미널 집중 방식 (Hub-and-Spoke): 중앙에 EAI 시스템(허브)이 있고, 연결된 응용 프로그램들이 연결대를 통해 상호 교류한다.
• 버스 방식 (Bus): EAI 시스템이 버스 역할을 하거나, 기존 메시지 버스(메시지 지향 미들웨어)에 내재되어 운영된다.

• 버스/허브 (Bus/hub): 표준 미들웨어 또는 단일 프로그램으로 구현된다.
• 응용 연결 (Application connectivity): 어댑터(커넥터)를 통해 응용 프로그램과 연결된다. 어댑터는 양방향 통신을 수행하며, 표준 프로토콜(SOAP, SMTP 등) 또는 벤더의 클라이언트 라이브러리를 이용한다. 자바에서는 JCA와 같은 표준을 통해 벤더 중립적인 어댑터 생성이 가능하다.
• 데이터 포맷 및 변환 (Data format and transformation): 응용 프로그램 간 데이터 변환을 방지하기 위해 공통 데이터 포맷을 사용한다. EAI 시스템은 응용 프로그램 고유 포맷과 공통 포맷 간 변환 서비스를 제공하며, 의미에 맞는 변환(예: 우편번호를 도시 이름으로 변환)도 수행한다.
• 통합 모듈 (Integration modules): 특정 이벤트에 대한 구독 및 처리를 담당한다. 자바 기반 EAI 시스템에서는 웹 애플리케이션, EJB, POJO 등으로 구현될 수 있다.
• 트랜잭션 지원 (Support for transactions): 통합 연산의 일관성을 위해 2단계 커밋(two-phase commit) 또는 보상 트랜잭션(compensating transaction)을 사용한다.

5. EAI의 구현 패턴 및 토폴로지

EAI 시스템을 구현하기 위한 유형에는 중개와 연합 두 가지가 있다. 이 두 유형은 동시에 일어나기도 하며, 같은 EAI 시스템은 다중 중계 시스템으로 유지될 수 있고, 외부 사용자의 요청에 대해서는 연합으로 서비스를 제공할 수 있다.

• 중개: EAI 시스템은 여러 응용 프로그램 사이에서 중개자 역할을 한다. 응용 프로그램에서 어떤 상황이 발생하면, EAI 시스템의 통합 모듈에 통보되고, 해당 모듈은 다른 관련된 응용 프로그램들에 이를 전파한다.
• 연합: EAI 시스템은 모든 응용 프로그램들의 최상위에 위치한다. 모든 외부로부터의 접속은 EAI를 통해 이뤄진다. EAI 시스템은 외부로 적절한 정보와 인터페이스를 제공하기 위해 구성되고, 요청자를 위한 응용 프로그램과 서로 작업을 수행한다.

6. EAI 구현의 문제점 및 해결 방안

2003년에 진행된 EAI 프로젝트 중 70%가 실패했는데, 이는 대부분 소프트웨어 자체의 결함이나 기술적인 어려움 때문이 아니라 관리적인 문제였다. 유럽통합회의 의장 스티브 크락스는 EAI 시스템을 사용할 때 기업이 인식해야 할 7가지 주요 위험 요소와 문제 해결 방법을 제시하였다.^[9]

• 거듭되는 변화(Constant change): EAI는 동적이고 역동적이므로, EAI를 적용하려면 그에 상응하는 관리자가 필요하다.
• EAI 전문가 부족(Lack of EAI experts): EAI는 기술 기반의 다른 많은 지식들을 필요로 한다.
• 참가의 표준화(Competing standards): 전 세계적으로 EAI 표준이 정해지지 않았다.
• EAI는 툴 패러다임이다(EAI is a tool paradigm): EAI는 도구가 아니며, 오히려 구현될 시스템이다.
• 건축 환경은 예술이다(Building interfaces is an art): 공학적 해결 방법은 충분치 못하기 때문에, 해결 방안으로 최종 결과를 도출하기 위한 협의가 필요하다. 디자인에 대한 협의 부족으로 다양한 시스템 데이터 요구사항을 상세히 그려내기 위한 많은 노력이 필요하게 되었다.
• 세세한 손실(Loss of detail): 초기에 중대하지 않게 취급되던 정보는 후에 대단히 중대한 요소로 대두될 수 있다.
• 의무(Accountability): 많은 지식활동 분야에서 다량의 대립된 요구사항을 소유하고 있기 때문에, 시스템의 최종 구조에 대한 의무가 해결될 것이다.

• 필요조건의 대두(Emerging Requirements): EAI는 확장성이 있어, 규격화된 단위 모듈화로 인해 미래가 바뀔 것이다.
• 보호(Protectionism): 기술과 문화, 그리고 다른 단체와 정보를 공유하지 않기를 원하는 정치적인 문제를 안고 있는 조직 간의 데이터와 응용프로그램은 통합하게 될 것이다.

7. EAI의 장단점

EAI는 여러 시스템을 통합하여 효율성을 높이지만, 구조화되지 않은 통합은 점대점 연결을 증가시켜 유지 관리가 어려운 복잡한 구조, 즉 '스파게티Spaghetti^영어'를 초래할 수 있다.^[1] 예를 들어 10개의 애플리케이션을 점대점으로 완전히 통합하려면 45개의 연결이 필요하며, 이는 제곱 성장 패턴을 따른다.^[1]

조직 내 연결 수는 지점 수의 제곱에 비례하여 항상 증가하지는 않지만, EAI는 시스템 간의 결합도를 높여 관리 비용을 증가시킬 수 있다.^[1] EAI는 데이터와 비즈니스 프로세스를 모두 공유하며, 미들웨어 분석가는 종종 시스템 오브 시스템을 고려한다.^[1]

EAI는 1990년대 후반 TP 모니터 기술, 서버 간 메시지 큐잉, WebAP 서버 등을 연계하여 시스템을 구축하는 경우가 많았다.^[2] CORBA나 MQ 등의 기술은 구현 비용이 높았고, EAI 패키지를 탑재하는 허브 서버는 고성능 UNIX 서버 최고 기종을 사용하는 경우가 많아 도입 사례가 적었다.^[2]

그러나 인터넷 발전으로 시스템 연결 자동화 요구가 증가하면서, XML, RSS 등의 인터넷 기술, 오픈 소스 제품, Struts, Ruby on Rails 등의 오픈 프레임워크를 활용한 EAI 제품이 보급되었다.^[2] 최근에는 웹 서비스 기반 ESB(Enterprise Service Bus)가 등장하여 EAI와 ESB의 구별이 사라지고 있다.^[2]

7. 1. 장점

• 여러 시스템에서 실시간 정보 조회를 제공한다.
• 능률적인 비즈니스 프로세스를 지원하여 조직의 효율을 높인다.
• 여러 시스템 간 정보 통합을 이룬다.
• 개발과 유지보수가 쉽다.

7. 2. 단점

• 소규모 비즈니스에서는 필요 이상의 개발 비용이 발생할 수 있다.
• EAI는 시간 소모가 많고 많은 자원을 필요로 한다.
• 많은 관리자들이 설계하려 하지 않고, 투자하려고 하지도 않는 디자인 작업을 미리 해야 한다. 대부분의 EAI 프로젝트는 일반적으로 지점 간의 움직임(운동)으로 시작하고 이는 곧 관리되지 않는 다수의 응용 프로그램 증가를 낳게 된다.
• 통합이 구조화된 EAI 접근 방식을 따르지 않고 적용될 경우, 조직 전체에 걸쳐 점대점 연결이 증가한다. 종속성은 즉흥적으로 추가되어 유지 관리가 어려운 복잡한 구조를 초래한다. 이는 일반적으로 스파게티 코드의 프로그래밍과 유사하다는 의미에서 스파게티라고 한다.
• 예를 들어, n개의 지점을 가진 완전 연결된 점대점 연결을 갖는 데 필요한 연결 수는 $\backslash tbinom\; n\; 2\; =\; \backslash tfrac\{n(n-1)\}\{2\}$로 주어지며(이항 계수 참조), 10개의 애플리케이션을 점대점으로 완전히 통합하려면 $\backslash tfrac\{10\backslash times9\}\{2\}\; =\; 45$개의 점대점 연결이 필요하며, 이는 제곱 성장 패턴을 따른다.
• 조직 내 연결 수는 지점 수의 제곱에 비례하여 증가하지 않을 수 있다. 일반적으로 임의의 지점에 대한 연결 수는 조직 내 다른 지점의 수에 의해서만 제한되지만, 원칙적으로 훨씬 작을 수 있다.
• EAI는 또한 시스템 간의 결합도를 증가시켜 관리 오버헤드 및 비용을 증가시킬 수 있다.
• EAI는 애플리케이션 간의 데이터 공유뿐만 아니라 비즈니스 데이터와 비즈니스 프로세스를 모두 공유하는 데에도 중점을 둔다. 미들웨어 분석가는 EAI를 처리하면서 종종 시스템 오브 시스템을 살펴보게 된다.

8. 결론 및 전망

EAI 기술은 계속 발전하고 있지만, 기업에서 참고할 만한 적절한 기술 표준이나 단체가 부족하다. 다른 단체의 기술을 활용하거나 확장하려 해도, 이는 벤더 종속적인 방식으로 개발되는 경우가 많다.^[1]

기업 응용 프로그램 통합(EAI)이 처음 등장한 것은 1990년대 후반이다. 이 시기에는 TP 모니터 기술, 서버 간 메시지 큐잉, 그리고 아직 기능이 충분하지 않았던 WebAP 서버 등을 연계하여 시스템을 구축하는 경우가 많았다. 또한, CORBA나 MQ 같은 통신 기반 기술도 구현 비용이 높았고, 대규모 시스템 구축이 필요했기 때문에 EAI는 주로 대규모 시스템에 적용되었다. 이러한 이유로 EAI 허브 서버는 고성능 UNIX 서버의 최고 기종을 사용하는 경우가 많았다.^[1]

이러한 특성 때문에 EAI 개발 비용과 제품 가격이 높아 도입 사례가 매우 적었다. 일본에서도 EAI를 탑재한 서비스를 제공하는 IT 기업은 많았지만, 실제 시스템 제공은 대기업에 한정되었고, EAI라는 용어 자체도 점차 사라져 갔다.^[1]

그러나 인터넷과 인트라넷의 발전으로 시스템 간 연동 및 자동화에 대한 기업의 요구가 커지면서, 인터넷 표준 기술을 사용한 제품들이 개발되고 보급되기 시작했다. 또한, XML, RSS와 같은 인터넷 기술, 오픈 소스 제품, Struts, Ruby on Rails와 같은 공개된 프레임워크 덕분에 각종 기능 부품을 쉽게 구할 수 있게 되었다. 이러한 기술 발전으로 인해 웹 간 시스템 연계가 일반화되면서, 2000년대 중반에는 EAI 제품이 기능적으로 반복 사용되는 부품들의 집합으로서 활용되어 개별 부문 서버 등에 도입되기 시작했다.^[1]

최근에는 웹 서비스를 기반으로 한 ESB(Enterprise Service Bus, 전사 서비스 버스)라는 기법을 통해 애플리케이션 통합이 보급되고 있다. 다양한 EAI 제품들이 ESB 기능을 통합하기 시작하면서, EAI와 ESB라는 제품 카테고리 간의 구별은 점차 사라지고 있다.^[1]

9. 주요 EAI 제품

• TIBCO Software의 ActiveMatrix BusinessWorks (외부 링크)
• 오라클의 AquaLogic Integration Server
• 아스테리아의 ASTERIA Warp
• 마이크로소프트의 BizTalk Server
• 세존 정보 시스템즈의 DataSpider Servista
• 썬 마이크로시스템즈의 eGate Integrator
• SAP (기업)의 SAP NetWeaver XI
• 소프트웨어 AG의 webMethods Enterprise Service Bus
• 한국IBM의 WebSphere Enterprise Service Bus
• 피오라노 소프트웨어의 Fiorano SOA Platform (외부 링크)
• Guaraná DSL
• Zato (Python으로)

참조

_[1] 서적 Enterprise Application Integration https://books.google[...] Addison-Wesley Professional 2000
_[2] 간행물 Enterprise application integration http://www.techstree[...] 2008-01-22
_[3] 웹사이트 Messaging Patterns Overview http://www.enterpris[...] Enterpriseintergationpatterns.com and Addison-Wesley 2016-05-19
_[4] 웹사이트 Types of EAI http://www.msquaresy[...] MSquare Systems 2014-05-21
_[5] 웹사이트 Dancing Around EAI 'Bear Traps' http://www.ebizq.net[...] 2006-06-27
_[6] 웹사이트 Avoiding Pitfalls of Integration Competency Centers http://integrationwa[...] 2013-10-26
_[7] 웹사이트 社内のデータが”つながる”EAIツールとは https://xeex-product[...] 株式会社エクス コラム 2017-12-19
_[8] 저널 Enterprise application integration http://findarticles.[...] 2008-01-22
_[9] 웹인용 Dancing Around EAI 'Bear Traps' http://www.ebizq.net[...] 2006-06-27