기업 응용 프로그램 통합

기업 응용 프로그램 통합(영어: Enterprise Application Integration, EAI) 또는 기업 애플리케이션 통합은 기업용 응용 프로그램의 구조적 통합 방안을 가리킨다. 전사적 응용 프로그램 통합이라고도 한다. 국내에서는 Enterprise Architecture와 더불어 EAI로 구축하도록 되어있는 법이 존재한다.

개요

재고와 선적(수송) 관리 목적의 공급망 관리(SCM) 응용프로그램과, 현재의 고객과 잠재고객 관리 목적의 고객 관계 관리(CRM) 응용프로그램, 경영 정보학(BI) 업무로부터 발생하는 데이터를 통해 일정 패턴을 찾아 내기 위한 응용프로그램, 인적 자원, 의료 관리, 조직내 모든 의사소통, 기타 여러가지의 데이터를 관리 하기 위한 응용프로그램들은 일반적으로 서로의 정보 공유나, 업무의 이해를 돕기 위한 의견 교환을 할 수 없다. 이런 이유로, 위의 응용프로그램들은 이따금 '자동화의 섬'(islands of automation), 또는 '정보 적재소'(information silo)로 불린다. 이런 상호교류의 부족은 동일한 데이터를 여러 곳에 저장하거나, 간단한 업무를 자동화하지 못하는 것과 같은 비효율을 야기하게 된다.

이에 비해, 기업 응용프로그램 통합은 단일 조직 내부에서의 업무 프로세스를 최대한 단순화 및 자동화 하기 위한 응용프로그램들의 연결을 할 수 있게 하며, 이미 존재하는 응용프로그램과 데이터구조에 대한 전면적인 수정 작업을 하지 않도록 도와 준다. 이에 대해, 가트너 그룹은 'EAI는 기업환경에서 연결되어 있는 어떠한 응용프로그램과 어떠한 원천 데이터 간에도 이뤄지는 구속 없는 공유'라고 정의 하기도 하였다.

기업 응용프로그램 통합이 가지는 큰 의미는 서로다른 다양한 시스템간의 연결에 있다. 다른 운영체제를 가동 중일 경우, 또는 다른 데이터베이스와 프로그래밍 언어를 사용 중 이거나 더 이상의 고객지원을 받을 수 없는 기존의 레거시 시스템 간의 통합이 여기에 해당된다. 이런 경우, 시스템은 수정하기 힘들정도로 강하게 뭉쳐 있기 때문에, 강 종속시스템(stovepipe system)이라 불린다.

구조 개선

만약, 조직화된 통합 구조 없이 시스템통합을 진행하게 된다면, 상호 연결은 교차 형태로 이뤄지게 된다. 즉흥적인 원칙으로 인한 종속성과, 관리하기 어려워져버린 뒤죽박죽 결과물이 증가하게 된다. 이런 현상을 스파게티의 형상에서 차용하여, 스파게티 코드라 한다.

예를 들어, n개의 커넥션은 ${\frac {n(n-1)}{2}}$에서와 같이 지점간에 완전히 맞물려야 한다. 따라서, 10개의 응용프로그램은 완전한 통합을 위해 ${\frac {10\times 9}{2}}=45$개의 지점간 연결이 필요하게 된다.

그러나, EAI는 응용프로그램간 데이터에 대한 공유만을 의미하지 않고, 서로간의 비즈니스 데이터와 프로세스의 공유에 초첨이 맞춰져 있다. EAI의 적용은 둘 이상의 학문 분야에 걸치는 복합적인 큰 문제와 이질성, 네트웍스에 내포된 다양한 계층의 분산 시스템 등을 내포하고 있는 복합 체계에 대한 주시가 요구된다.

목적

EAI는 다음의 목적들로 사용될 수 있다.

• 정보의 통합 : EAI는 일관성 있는 여러 시스템들의 정보를 보증하며, 기업 정보 통합(EII)을 의미한다.
• 프로세스 통합 : 응용프로그램간 비즈니스 프로세스를 연결 한다.
• 벤더에 대해 독립 : 응용프로그램으로부터 업무의 정책과 규칙을 추출하고, EAI 시스템에 구현하여 비즈니스 응용프로그램 중 하나가 다른 벤더에 의해 수정된다고 해도, 비즈니스의 규칙은 다시 만들어질 필요가 없다.

일반적 견해로, EAI 시스템은 응용프로그램 단위의 전위 처리 시스템 될 수 있으며, 일관성이 유지된 접점을 제공 한다. 또한, 다른 소프트웨어 패키지를 새로 익혀야하는 번거로움으로부터 벗어나게 해 준다.

통합 패턴

통합 형태

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

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

접근 형태

EAI는 동기와 비동기 접근을 모두 지원하며, 동기의 경우는 전형적인 중개의 경우, 비동기는 연합의 경우를 의미한다.

수명 형태

통합된 수행은 짧은 수명을 가지거나 또는 지속적 수명을 가질 수 있다. 특히 짧은 수명의 경우, 동기방식으로 연결된 두 가지의 응용프로그램은 완벽한 보완책이 될 수 있으며, 지속적 수명에서도 사람이 하는 대출 기간에 대한 승인 업무 흐름과 상호 연관되는 EAI시스템을 포함할 수 있다.

의미

EAI는 각 터미널 집중 방식(hub-and-spoke)과 버스 방식의 두 가지의 중요한 의미적 위치를 보유하고 있다. 또한 각각의 장점과 단점이 있는데, 터미널 집중 방식의 모델은 중앙에 EAI 시스템이 존재하고(HUB구조), 연관된 응용프로그램들은 연결대를 통해 상호 교류 한다. 버스 모델은 EAI 시스템이 버스가 되거나, 또는 이미 구현되어 있는 메시지 버스에 내재되어 운영된다. 혹은 메시지 지향 미들웨어라고도 한다.

기술요소

여러 기술들이 EAI 시스템의 구성요소들을 구현하기 위해 사용되며, 구체적으로는 다음과 같다.

• 버스/허브(Bus/hub) : Bus/hub는 보통 진보적인 표준 미들웨어에 의해 구현된다. 또는 미들웨어는 아니지만, 미들웨어처럼 동작을 하는 단일 프로그램에 의해 구현된다.

• 응용 연결(Application connectivity) : bus/hub는 어댑터(또는 커넥터)의 셋을 통해 연결되고, 어댑터는 어떻게 비즈니스 애플리케이션과 연동되어야 하는지를 알고 있다. 어댑터는 두 가지의 방법으로 연결되고, 응용프로그램으로부터 들어오는 요청을 이행한다. 그리고 새로운 정보가 추가 되거나, 단위 작업이 완료되는 등의 상황이 감지되었을 때, 허브에게 알려준다. 어댑터는 벤더의 클라이언트 라이브러리를 이용하여 만들어지는 등, 명시적으로 응용프로그램이 될 수 있다. 또는 응용프로그램의 클래스가 될 수 있다. 표준 프로토콜인 SOAP 이나 SMTP를 이용하여 어떠한 응용프로그램과도 상호연동할 수 있는 클래스가 그 예이다. 또한, 어댑터는 같은 프로세스 영역 bus/hub로 위치할 수 있고, 또는 원격에서 실행하고 산업표준 메시지 큐나 웹서비스 또는 독점적인 프로토콜을 사용해서라도 hub/bus와 서로 영향을 미칠 수 있다. 자바에서 JCA와 같은 표준은 어댑터가 벤더에 중립적으로 생성될 수 있도록 해준다.

• 데이터 포맷과 변환(Data format and transformation) : 모든 어댑터와 응용프로그램 간의 별도의 데이터 변환을 방지하기 위해, 일반적으로 EAI시스템은 응용프로그램의 공통적으로 사용할 수 있는 데이터 포맷을 요구한다. 일반적으로 EAI시스템은 응용프로그램의 고유의 데이터 포맷에서 공통의 데이터 포맷으로 변환시켜 주는 서비스를 제공한다. 여기에는 두 가지의 단계가 있는데, 첫 번째로 어댑터는 응용프로그램의 데이터 포맷을 버스의 공통적인 포맷으로 변환하고, 그 후 우편번호를 도시의 이름으로 변환하는 것과 같은 의미에 맞는 변환이 적용된다. 또는 하나의 응용프로그램의 객체를 다른 응용프로그램의 객체로 분열 또는 병합하는 것을 의미하기도 한다.

• 통합 모듈(Integration modules) : EAI 시스템은 언제라도 다중 병렬처리 시스템에 참여될 수 있고, 병렬처리 시스템의 통합 유형에 따라 다른 통합모듈이 처리된다. 통합모듈은 지정된 일련의 이벤트에 대해 구독을 하고, 이런 이벤트가 발생하여 전단되는 통지를 이행, 처리하게 된다. 이런 모듈은 다음의 여러 방법으로 구현이 가능하다. 대표적으로 자바를 기반으로 한 EAI 시스템이 있다. 이런 시스템은 EAI 시스템 정의에 따라 웹 애플리케이션, EJB 또는 POJO가 될 수 있다.

• 지원 트랜잭션(Support for transactions) : 통합된 프로세스를 사용하려 할 때, 관련한 모든 통합연산의 실행에 의해 EAI시스템은 업무처리에서의 일관성을 제공한다. 통합연산은 2단계 커미트(two-phase commit), 또는 보상 트랜잭션(compensating transaction)을 이용하는 최상위의 단일 분산트랜잭션이 가지는 모든 응용프로그램과 연관되어 있다.

연결 구조

일반적으로, 기업용 응용프로그램 통합을 위해 가장 좋은 기반 구조, 컴포넌트 모델, 표준화 구조에 대한 다양한 의견들이 존재하고 있다. 근래의 기업용 응용프로그램의 통합구조를 위한 필수 컴포넌트는 다음과 같다.

1. 보안, 접근, 커뮤니케이션을 관장하는 중앙 집중 형 브로커의 운영이 있다. 브로커는 서버의 통합으로 또는 SOAP-기반의 서비스 관리기능을 하는 엔터프라이즈 서비스 버스(ESB)와 유사한 통합관리 서버를 통해 완성된다.
2. 표준 데이터구조에 기반한 비 종속적 데이터 모델이 있다. 이 모델은 사실적이고 적법한 표준인 XML과 XML 스타일 시트로 표현된다.
3. 커넥터 또는 벤더의 에이전트 모델, 응용프로그램 또는 외부 접점은 하나의 컴포넌트로 만들어질 수 있고, 그것은 중앙 집중 형 브로커와 통신하는 전통적인 응용프로그램이라 할 수가 있다.
4. API와 데이터 흐름, 위의 컴포넌트와 연동 대한 규칙을 정의 하는 시스템 모델은 표준화에 따라 생성된다. 비록 데이터베이스나 사용자 인터페이스와의 연결과 같은 접근방법이 이미 개발되었지만, 그것들은 규격을 찾기 어렵고 새로운 작업을 통해 수정되어야 한다. 각각의 응용프로그램들은 중앙의 브로커에게 메시지를 전달하고, 브로커로부터 전달되는 메시지를 받기 위해 대기 한다. 이때 각 응용프로그램과 브로커는 단일 커넥션을 유지 한다. 이런 중앙관리형 접근 방법은 높은 발전 가능성과 일관성을 가지고 있다.

기업용 응용프로그램의 통합은 메시지 지향 미들웨어(MOM)나 데이터에 대한 표현 기술인 XML과 같은 미들웨어 기술과 관련이 있다. 다른 EAI 기술요소들은 통합적 의미에서 서비스 지향 아키텍처의 일부분인 웹 서비스와 관련이 있다. 기업용 통합응용프로그램 환경은 데이터 중심으로 변화하고 있어, 향후에는 데이터 통합(Content Integration)과 비즈니스 프로세스(BP)도 모두 포함될 것으로 예상된다.

구현의 함정

2003년에 진행된 프로젝트 중 70%가 실패하였는데, 이런 실패의 대부분은 소프트웨어 자체의 결함이거나 어려운 기술로 인한 것은 아니었으며 대부분이 관리적인 면에서의 실패로 인한 문제였다. 이에 대해 유럽통합회의 의장인 스티브 크락스는 EAI시스템을 사용함에 있어서, 기업에서 인식해야 할 7가지 주요 위험요소와 문제를 해결할 방법을 제시 하였다. 구체적으로는 다음과 같다.

• 거듭되는 변화(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) : 기술과 문화, 그리고 다른 단체와 정보를 공유하지 않기를 원하는 정치적인 문제를 안고 있는 조직간의 데이와 응용프로그램은 통합하게 될 것이다.

통합의 장점과 단점

통합에 있어서는 다음과 같은 장점과 단점이 발생한다.

장점

• 여러 시스템중 실시간 정보 조회를 제공한다.
• 능률적인 비즈니스 프로세스와 도움으로 조직의 효율이 증가하게 된다.
• 여러 시스템간 정보의 통합을 이루게 된다.
• 개발과 유지보수가 쉬워진다.

단점

• 소규모의 비즈니스에선 필요이상의 개발 비용이 발생할 수 있다.
• EAI는 시간 소모가 많고 많은 자원을 필요로 한다.
• 많은 관리자들이 설계하려 하지 않고, 투자하려고 하지도 않는 디자인 작업을 미리 해야 하고, 대부분의 EAI프로젝트는 일반적으로 지점 간의 움직임(운동)으로 시작 하고 이는 곧 관리되지 않는 다수의 응용프로그램이 증가를 낳게 된다.

전망

EAI 기술은 여전히 개선되고 있으나, 여전히 접근 방법 또는 기업에서 참고 할 수 있는 적절한 기술 단체가 없다. 다른 단체의 기술을 이용 또는, 확장하여 사용하고자 하지만, 이는 벤더 독점(vendor lock-in)적으로 개발되었다.

외부 링크

• Integration Consortium
• Enterprise Architecture
• 온라인강의 video lecture