EAI 도입 전략

한국 소프트웨어 진흥원 부탁으로 써줬던 기고인데,
EAI의 도입 전략에 대해서 설명했던 글이다.

==

Introduction strategy of EAI

 

2006년 7월 5일

자바스터디 네트워크 (http://www.javastudy.co.kr)

 조대협 (bcho@bea.com)

 

1. 왜 EAI 가 필요한가?

 

전통적으로 기업의 애플리케이션들의 개발은 각 부서의 업무나 특정 업무의 요구 사항에 맞춰서 필요한 시기에 전사적인 기업 업무나 기존의 IT 시스템에 대한 고려 없이 독립적으로 개발되었다.

  즉, 고객 관리를 위해서 CRM이 개발이 되었고, 경영자의 데이터 분석을 위해서 DW 시스템이 개발이 되었고, 기업 내부의 전산화를 위해 그룹 웨어가 개발이 되었다.

 이런 각각의 애플리케이션의 개발은 개발 당시의 적합한 기술(?) 또는 주류가 되는 기술에 의해서 개발이 되었고 결과적으로 기업의 애플리케이션들은 각기 다른 기술로 구축이 되고, 데이터 또는 기능상의 불필요한 중복을 야기하게 되었다.

특히 1980년대를 거쳐 1990년에 이르기 까지, 메인프레임에서부터 C/S환경 인터넷 환경까지의 급격한 기술 변화를 거치면서, IT 시스템들의 플랫폼은 점점 더 다양화 되게 되었다.

 이로 인해서 점점 거대해지고 다양화된 IT 시스템에 대한 유지보수 및 중복 개발로 인한 비용이 증대하게 되었고, 이는 기업 시스템 운영의 하나의 문제점으로 대두 되게 된다.

 

이 시기에 경영자들은 각 부서간 협업과 업무 프로세스 개선을 통해서 기업의 전략을 신속하게 비즈니스에 반영하려는 시도를 하지만, 기존의 IT 시스템은 이미 독립적으로 개발이 되어서 연계성이 떨어지고, 비즈니스 요구 사항을 IT 시스템에 반영하려면 기존 시스템들에 대한 수정을 일일이 거쳐야 하기 때문에 민첩성이 떨어지게 되었다.

 

이런 이유로 기업의 애플리케이션들의 통합에 대한 필요성이 대두되게 된다.

 

2. EAI 의 개념

먼저 EAI의 개념에 대해서 간략하게 설명하기 위해서 간단한 예를 들어보자. 고객이 어떤 기업에 물건을 하나 주문하고, 구입하는 순서를 살펴보면 “ 고객이 물건을 주문을 하면, 기업에서는 주문 내용을 시스템에 입력하고, 입금이 된 것을 확인한 다음에, 재고 관리 시스템을 조회해서 재고가 있는지를 체크한다. 재고가 없으면 다시 발주시스템을 통해서 협력사에 물품을 발주하고, 재고가 있으면 물류 시스템을 통해서 해당 물품을 출고 시키도록 하고 출고된 물품은 운송 추적 시스템을 통해서 고객에게 수령되기 까지 추적된다. “

주문 입금확인 재고체크 출고 운송 발주 납품 수령 고객 기업 협력사 발주 시스템 주문 시스템 재고관리 물류 시스템 운송 시스템

< 그림 1. 주문 프로세스 예제 >

이 업무 프로세스에서 기업에서는 각기 독립된 다른 시스템에 접근해서 데이터를 입력해야 하고(주문,영업정보 etc), 때로는 중복된 데이터를 입력해야 하는 경우도 있을 것이고, 재고가 없어서 발주라도 했을 경우에는 발주자가 해당 물품이 납품이 되었는지 아닌지를 일일이 확인한 후에 출고를 시킬 수 있다.이렇게 다수의 인터페이스를 통해서 각각의 애플리케이션을 접근해야 하는 복잡성 때문에 업무의 효율이 급속하게 감소된다.

 만약에 이 각각의 시스템들이 유기적으로 결합되어 하나의 통합된 ‘주문 처리’ 시스템으로 존재한다면 좀더 빠르고 신속하게 ‘주문’ 이라는 업무에 대해서 대응을 할 수 있게 될것이다.

 이렇게 각기 다른 시스템을 통합해주고 유기적으로 연결 시켜주는 시스템을 EAI (Enterprise Application Integration)이라고 한다.

 

폭넓은 의미에서의 EAI는 전체 시스템 통합을 의미한다. 즉 Presentation Layer간의 통합, Application 간의 통합, Data 간의 통합을 모두 포함한 개념이지만, 현재 일반적으로 사용하는 EAI는 Application 간의 통합을 지칭한다. (참고: Presentation Layer간의 통합은 Enterprise Portal, Data간의 통합은 Data Integration Solution 등을 통해서 이루어 진다.)

 

3. EAI 모델과 단계별 도입 전략

 

EAI의 단계별 발전 모델로 분리했을 때 크게 3가지 모델로 분류할 수 있다.

1) P2P

가장 기본적인 형태의 EAI로 단위 애플리케이션을 1:1 로 연결한다.

기존의 전통적인 통합방법에서 가장 많이 사용한 형태로 간단한 애플리케이션간의 통합에서는 저비용으로 쉽게 구현을 할 수 있으나, 시스템의 통합 규모가 커짐에 따라서 관리상의 어려움과 함께 표준화되지 않은 인터페이스나 기술에 의한 통합이기 때문에 비용상의 문제가 함께 발생한다.

 

2) Hub & Spoke

현재 일반적으로 이야기 하는 EAI 시스템의 구조이다. EAI 솔루션이 Hub 형태로 단위 애플리케이션들을 EAI Hub에 연결하고, 이 Hub를 통해서 애플리케이션간의 호출 및 통신을 하는 구조이다.

 중앙 집중된 Hub를 통해서 통합을 진행하기 때문에 중앙에서의 통제와 관리등이 가능하며, 중앙 Hub의 통합된 연결 인터페이스를 통해서 단위 애플리케이션의 업무간의 재사용성이 극대화 된다.

 기존에는 CORBA등의 ORB 형태의 Hub를 사용했으나, CORBA의 기술적인 난이도와, CORBA를 지원하지 않는 애플리케이션까지 통합하기 위해서 2000년대에 들어서는 전용 EAI Hub와 Adapter 로 조합된 형태의 EAI 제품군들을 주로 사용한다.

 

3) BPM based EAI

Hub&Spoke 방식이 애플리케이션간의 연결만을 뜻한다면, BPM Based EAI는 애플리케이션의 업무를 재배치 및 조합하여 새로운 업무를 빠르게 구현하여 비즈니스 요구사항에 빠르게 대응할 수 있는 민첩성을 제공한다.

 비즈니스의 요구가 바뀌었을 때 해당 요구에 대한 애플리케이션을 구현하기 위해서 다시 코딩을 하는 것이 아니라 비즈니스 프로세스상에서 기존 조합을 변경함으로써 요구 사항을 반영하여 빠르게 현업의 요구 사항을 IT에 반영할 수 있게 된다.

 

일반적으로 현재 EAI 솔루션은 Hub&Spoke 모델을 지칭하는 경우가 많지만 요즘에는 BPM을 포함한 EAI 모델을 지향하는 경향이 있다.

1990년대 초반에 비즈니스 프로세스의 구축을 위한 BPR (Business Process Reengineering)이 대두 되었고, 포춘선정 500개 기업이 이 BPR을 도입하였지만 대부분의 결과는 실패로 돌아갔다. 이유는 “staring from scratch” 즉 기존의 애플리케이션의 기능들을 재 사용하는 것이 아니라 재구축 하는 곳에서부터 시작했기 때문인데, 그에 대한 대안으로 나온 것이 BPM (Business Process Modeling)이다. BPM은 기존의 애플리케이션의 기능들을 재사용하여 단위 애플리케이션들을 업무 흐름에 맞추어서 재배치 하는 것으로 기존 업무의 재 사용을 전제로 하는 만큼, EAI의 사상과 잘 매치가 된다.

 

BPM은 업무 프로세스를 재정의하고 구성하는 만큼 IT 부서에서 뿐만이 아니라 실제적인 업무와 그 흐름을 정의하는 경영부서와 함께 진행되어야 하며 Six sigma나, ISO9000같은 비니지스 프로세스의 재 정립과 함께 진행한다면 좀더 큰 효과를 기대할 수 있다..

 

기업에서 통합을 고려하고 있다면 빅뱅식의 접근 모델 보다, 이 3가지 발전 모델을 단계적으로 도입하는 것이 통합에서 올 수 있는 혼란이나 부작용을 최소화 할 수 있다.

 

4. 성공적인 EAI 구현을 위한 전략

 

그러면 지금부터 성공적으로 EAI 시스템을 구축하기 위한 몇가지 전략에 대해서 알아보도록 하자.

 

1) 목표와 범위

먼저 애플리케이션을 통합하고자 하는 목적을 명확하게 정의해야한다. “통합하면 좋으니까” 라는 막연한 목표보다는 “고객 신상 정보와 고객 매출 정보 시스템을 통합하여 고객 관리 만족도를 높이겠다.” 등의 구체적인 목표를 정해야만 프로젝트의 방향이 어긋나지 않는다.

다음으로는 정해진 목표를 이루기 위한 통합의 범위를 정한다.

종종 EAI 프로젝트를 보다보면 실패하는 원인중의 하나가 초반에 정의되지 않은 범위와 목표를 벗어나는 업무를 “이번에 통합하는 김에 같이 하자” 라는 등의 막연한 이유로 막판에 통합에 포함 시키려는 시도를 보게 된다. 그러나 이는 처음에 설계되었던 통합의 방향을 바꿀 수 있고, 새로운 통합 대상 시스템이 들어오게 됨으로써 프로젝트의 범위를 넓혀버릴 수 있다.

 먼저 설정된 목표와 범위만큼만 통합을하고, 확장은 다음 단계의 개발에 반영하는 것이 현명하다.

 단 해당 목표를 위한 통합의 범위를 지정했음에도 불구하고, 개발중에 목표 달성을 위해서 통합의 범위가 더 추가가 필요로 되는 경우가 있는데, 이는 프로젝트의 수행을 순차적 수행 모델이 아닌 반복적 (Iterative) 수행 모델을 통해서, 각 프로젝트 Milestone 별로 feed back을 받고 적절한 통합 범위를 조정하는 것이 필수적으로 필요하다.

 

2) 기존 시스템 인식

통합을 진행하면서 통합할 시스템의 기능적과 비기능적인 요소에 대한 검토가 필요하다.

 먼저 통합에 필요한 기능이 있는지 없는지 그리고 새로 추가해야하는 기능이 있는지 없는지를 검토하고 통합에 필요한 기능적 요건을 모두 만족할 수 있는지를 검토한 후 에,

 비기능적인 요소, 즉 해당 애플리케이션의 동시 사용자수, 평균 응답시간, 장애에 대한 대응 능력 – SLA,Qos 등을 체크해야 한다.(대부분 기능적인 요소에 대해서는 꼼꼼하게 검토가 이루어지지만 이 비기능적인 요소에 대한 검토는 프로젝트시에 점검이 소홀한 경우가 많다.)

 예를 들어 5개의 애플리케이션을 통합하여 새로운 비즈니스 애플리케이션을 만든다고 했을 때, 4개의 애플리케이션의 평균 응답시간이 0.3 sec라도, 1개의 애플리케이션의 평균 응답시간이 5sec면, 이 새로운 애플리케이션의 전체 응답 시간은 0.3*4 + 5 = 6.2초가 된다. 이 5sec가 걸리는 애플리케이션에 대한 증설이나 재개발 또는 EAI의 메세징 모델의 변경등을 통해서 비 기능적인 요소를 만족시킬 수 있도록 해야한다.

 

3) 부서간 협력과 EAI 팀의 지배력

EAI 프로젝트를 진행하면 가장 중요한점중의 하나가 협업이다.

EAI의 대상 시스템은 주로 다른 부서간의 업무가 되는 경우가 많고, 통합을 위해서 일부 애플리케이션에 대한 수정이나 가감 작업이 수행되는 경우가 많은데, 이 경우에 부서간의 대화 문제나 책임회피 등으로 이상적이지 않은 방향으로 시스템이 통합되는 경우가 있다.

 이를 해결하기 위해서 원할한 협력관계가 우선시되어야 하는 것은 물론이고, EAI 프로젝트를 진행하는 주관팀이 효과적인 EAI 아키텍쳐를 위해서 적절하게 해당 부서에 통합 업무를 분할하고 진행 요청할 수 있는 적절한 권한을 가져야 한다.

 

4) Simple is best

애플리케이션을 상호연동하다보면 나오는 문제점중의 하나가 “트렌젝션” 에 대한 범위 지정일 것이다. 트렌젝션의 연동은 애플리케이션에서 매우 중요하고 필수적인 요소라고 할 수 있지만 그만큼 복잡성이 높고, 쉽게 연동할 수 없는 부분이기도 하다.

 실제로 기업 통합의 시나리오를 살펴보면 전체 업무의 80~85% 정도가 트렌젝션 연계가 필요없는 경우가 많다. 불필요한 부분에 트렌젝션을 연계하여 시스템의 복잡성을 증가시키지 말고 필요한 부분에만 사용하도록 하자.

또한 2Phase Commit이나 XA 사용보다는 Logging을 이용하거나 보상 트렌젝션등을 이용하는 방법으로 시스템을 단순화 시키는 것이 시스템의 안정성과 성능 향상에 더 큰 도움이 된다.

 

5) 경영 지원

기업의 애플리케이션 통합은 IT 부서의 요구보다는 비니지스 조직의 요구사항에 의한 경우가 많다. 그 만큼 경영 부서에서 애플리케이션 통합에 대한 인식과 적절한 요구 사항을 도출 시키는 것이 중요하고, IT 부서와의 협업을 통해서 적절한 통합 범위와 프로젝트 단계를 설정하는 것이 중요하다.

 또한 BPM 기반의 통합의 경우 BPM 자체가 비니지스 조직에 의해서 도출 되는 만큼 비즈니스 프로세스의 개선 작업이 경영선에서부터 시작이 되어야 한다.

 

5. SOA 와 EAI

 

현재의 애플리케이션 통합을 이야기 하자면 SOA를 빼놓을 수 없다. EAI와 SOA의 접근 방식은 어떤면에서는 매우 비슷하게 보이지만 각각이 고유한 특징을 가지고 있다.

 SOA의 접근은 서비스 지향적인 접근 방식이다. 서비스란, 애플리케이션의 API나 구현 단위를 뜻하는 것이 아니라, 비즈니스적인 의미를 가지고 있는 단위 컴포넌트 이며, 서비스의 호출은 플랫폼이나 특정 기술에 대한 종속성을 가지고 있지 않는다. (해당 시스템이 Tuxedo ATMI나, CORBA로 개발되었던간에 사용자 입장에서는 공통된 표준 기술을 이용해서 호출이 가능하다)

 즉 “상품ID로 정보를 상품 정보를 데이터베이스에서부터 읽어온다.” 는 기능이 애플리케이션적인 의미를 가진다면 “상품 ID로 발주를 한다”는 의미는 상품의 재고 상태 파악과 입금 정산, 운송을 함께 하는 기능으로 비즈니스적인 의미를 가지게 된다. 반대로 EAI는 애플리케이션의 각 API들을 연동하여 하나의 통합된 의미의 기능을 만드는데 그 목적을 가지고 있다.

 EAI는 이 비즈니스적인 의미를 가지는 서비스 자체를 구현하기 위해서 하단의 애플리케이션들을 통합하여 상위 개념으로 추상화하여 하나의 서비스를 구축하는데 사용되며 특히 트렌젝션 연결과 같은 Tightly Coupled 된 애플리케이션 통합에서는 SOA 함께 사용되어야 한다.

 SOA 의 Reference Architecture를 보더라도, SOA의 인프라가 되는 ESB (Enterprise Service Bus)의 하단에 애플리케이션들을 통합하여 비즈니스 서비스화하여, ESB에 연결하는데, EAI 가 이 ESB의 하단에 위치하게 된다.

 

6. 결론

 

기존의 애플리케이션들은 각기 다른 요구사항에 따라서 독립적이고 상호적인 운영성이 고려되지 않은 상태에서 독립운영 되도록 설계가 되었다.

그러나 기업이 커지고 업무의 복잡성과 요구되는 민첩성이 증가함에 따라 애플리케이션 간에 서로 공유되어야 하는 정보와 애플리케이션의 필요성을 인식하면서 통합에 대한 필요성이 대두 되었고, 기업들은 이러한 자원들을 연결하여 능률적인 비즈니스 프로세스를 구현하기 위해서 EAI를 도입하고 있다.

 

EAI를 도입하기 위해서는 적절한 목표와 이를 위한 적절한 범위가 선정되어야 하며, 통합을 진행하는 과정은 업무의 성격과 시스템의 규모에 따라서 단계적으로 진행되어야 한다. 효과적인 통합을 위해서는 EAI를 추진하는 조직이 성공적인 EAI 시스템의 구축을 위해서 부서간의 통합을 통제할 수 있는 적절한 권한을 가져야 한다.

 

또한 기업의 업무 프로세스 자체를 혁신하고 이를 IT에 민첩하게 반영하기 위해서 BPM이 등장하였으며, BPM의 적용은 IT 조직뿐만이 아니라 경영조직의 지원이 함께 이루어져야 한다.

 

EAI 프로젝트는 다음단계로 이루어질 SOA를 지원하는 구조가 고려되어야 한다.