EAI, Portal AND SOA

 

1.3     EAI, Portal 그리고 SOA

웹 애플리케이션 서버 시장이 폭발적으로 성장을 한 후 언제부턴가 그 성장폭이 줄어들게 되었습니다. 그 이유는 대부분의 기업들이 웹 애플리케이션 서버를 도입했기 때문이며, 이후 도입된 S/W 자산을 업그레이드만 시키면 됐기 때문입니다. 이에 벤더들은 다른 형태의 솔루션을 모색해야만 할 필요성이 있었을 것이란 추측(?)입니다.

 

1.3.1    개념을 IT화시키는 데 걸리는 평균 시간 30년

바코드 시스템은 1932년에 고객의 자동 구매를 위한 프로젝트로 시작이 됐습니다. 하지만 실제 최초 설치된 것은 1960년대였고 활성화되기 시작한 것이 1980년대부터였습니다.

 

ERP(Enterprise Resource Planning)은 1960년초에 IMC(Inventory Management Control)이라는 재고 관리를 위한 시스템 개념으로부터 시작되어 1970년대 MRP(Manufacturing Resource Planning), CIM(Computer Integrated Manufacturing)으로 발전하면서 1990년대에 ERP 붐을 일으켰습니다.

 

CRM(Customer Relationship Management)는 전단지와 같은 카탈로그 마케팅(catalog marketing)으로 1950년대에 처음 시작이 되었고, SCM(Supply Chain Management)은 MRP II(1970년대)와 같이 시작해서 1990년대에 와서야 비로소 정착하게 되었습니다.

 

BPM(Business Process Management)의 경우는 1970년대 제록스의 OA(Office Automation) 개념으로 시작되었으니 딱 30년째 되던 2000년대에 어느 정도 성숙 단계로 접어들고 있습니다.(현재는 많이 사용안함)

 

위의 경우를 살펴보았을 때 우리가 현재 사용하고 있는 IT개념들이 정착되는데 걸리는 시간이 평균 30년임을 예상하고 다음의 개념들을 살펴보도록 하시죠.

 

1.3.2    EAI(Enterprise Application Integration)

EAI는 1990년대 메이저 ERP 사용 기업들이 시스템을 업그레이드 하면서 레거시 시스템과의 연계 요구로 처음 생겨나게 되었습니다.이 때 TIBCO, Vitria, WebMethod, iWay 등의 전통 EAI 업체가 생겨나게 되었는데, 이 업체들의 특징을 살펴보면, 레거시 시스템과 연계하는 어댑터를 통해 기업 고객은 개발 생산성, 성능에 집중하도록 함으로써 고가의 어댑터를 공급하기 시작하였습니다.

 

이에 애플리케이션 서버 벤더들이 눈을 돌린 것이 하부의 레거시 시스템(Legacy, Proprietary) 이었습니다. 웹 애플리케이션 서버가 레드오션으로 전락함으로써 블루오션인 영역에 눈을 돌린 것입니다.

 

이에 웹 애플리케이션 서버 벤더들은 기존의 애플리케이션 서버 위에 기존의 시스템들을 연결할 수 있는 레거시 어댑터를 탑재하여 하부의 시스템들을 연결할 수 있는 기능을 선보였습니다. 이러한 것들이 자바 표준에도 영향을 미쳐 RAR(Resource Archive) 형태의 어댑터 라이브러리를 통해 기존의 자원에 연결할 수 있는 명세서가 제정되었습니다.

 

레거시 시스템 연계를 편리하게 한다는 논리를 통해 기업고객들을 설득하였고, 2000 초반에 금융권을 중심으로 많은 EAI 프로젝트가 생겨났습니다. 당시 EAI를 도입하는 고객 측에서 고려했었던 사항은 다음과 같은 것들이었습니다.

 

정보 전략 파트:

l  EAI를 도입했을 경우 나타나게 되는 전체 운영시스템에서의 이점은 무엇인가?

l  EAI를 적용했을 경우 향후 ROI는 어떻게 되는 것인가?

l  EAI 프로젝트를 진행하는 데 필요한 발생예산은 얼마인가?(기간, 유지보수 등)

l  EAI 완료 후 향후 발생되는 프로젝트에 끼치는 영향은 무엇인가?

 

시스템 운영 파트:

l  Control Tower에 대한 관심

l  Timer에 의한 장애 발생시 대처를 어떻게 할 것인가?

l  전체 시스템을 모니터링할 수 있는 방법이 있는가?

l  EAI 환경 구성 및 변경, 디플로이를 쉽게 할 수 있는가?

 

인프라 개발 파트:

l  개발시 데이터 정합성 보장을 어떻게 할 것인가?

l  각 시스템별 프로토콜을 처리하기 위한 효과적인 방안은 무엇인가?

l  EAI를 도입함으로 인한 표준 거래 전문에 대한 변환을 어떤 방식으로 할 것인가?

l  거래를 잃어버렸을 경우 어떤 방식으로 처리해야 하는가?

l  2PC를 적용하여야 할 시스템은 무엇인가?

 

EAI는 단일 부서의 프로젝트의 사항이 아니었습니다. 이는 시스템과 연계되는 모든 부서의 공통된 작업이었고, 부서 간의 마찰도 빚을 수 있는 상황이었습니다.  게다가 EAI를 개발할 수 있는 도구들 또한 벤더에 종속될 수 있는 상황이었고, 개발을 위한 교육비용이 상당하였습니다.

 

생각해보세요. 위와 같은 그림을 통해 EAI를 구축한다고 했을 때 개발자들 중에 Tuxedo, EJB, Socket, SAP 등과 연계 애플리케이션 구축을 경험했던 개발자가 몇이나 있을까요? 이로 인해 EAI 개발자의 몸값은 현재의 클라우드 환경의 개발자처럼 상승하였고, 이는 고스란히 프로젝트 비용으로 연결되는 결과를 초래하였습니다.

 

보고서(Trotta, Gian(2003-12-15). "Dancing Around EAI 'Bear Traps'". http://www.ebizq.net/topics/int_sbp/features/3463.html. Retrieved on 2006-06-27)에 의하면 전세계의 70%의 EAI 프로젝트는 실패했다고 보고했다. 문제는 다음과 같았다고 기술합니다.

  - 지속적인 기업환경 변화에 시스템이 따라주지 못함

  - 대상 시스템에 대한 전문가 부재

  - 각 사용자 부서와 협업, 의사 소통이 제대로 이루어지지 않아 인터페이스 도출 어려움

  - 기술, 문화, 정치적인 이유로 부서의 시스템을 다른 사업부에 보여주기 원치 않음

  - 많은 부서 참여로 인한 요구 사항 중첩 및 해결책 모호로 인하여 최종 시스템 구조가 명확하지 않음

 

EAI 프로젝트의 가장 큰 폐해 요소로 기업들은 해당 패키지 애플리케이션 벤더 및 EAI 벤더에게 종속(lock-in) 되었다고 보고되었습니다.

 

벤더 종속은 고객이 벤더, 제품, 서비스에 의존한 나머지 신규 시스템 도입시 다른 제품을 고려하지 못하고, 다시 묶임으로써 추가적인 비용이 발생하여 시장에 빠르게 진입하지 못하는 현상을 일컫습니다. 예를 들어 가장 대표적인 케이스의 생활 벤더 종속은  DSLR카메라가 아닐까 싶습니다. 타사의 성능이 좋은 렌즈를 구입하고 싶을 때, 해당 렌즈만을 구입하는 것이 아니라 카메라 바디를 바꾸어야 하는 전환 비용(switch-cost)가 발생을 하게 되는 경우입니다.

 

국내의 EAI 프로젝트를 보더라도 실제 공공, 제조는 거의 제로에 가깝다고 말할 수 있고 그나마 통신, 금융이 복잡한 시스템들로 인하여 도입을 한 경우가 상당수 있습니다. 문제는 도입됨과 동시에 앞서 언급한 상황이 발생할 수 있다는 것입니다.

 

너무 부정적인 면으로 흐르기 때문에 EAI 이야기는 여기서 끊도록 하겠습니다. 중요한 것은 EAI가 하부의 복잡한 레거시 시스템에 대한 단일 접점을 제공함으로써 메시지 표준화, 프로토콜 표준화 등을 통해 시스템 재사용성을 높일 수 있다는 것입니다. 단 그것이 명확한 기준으로 잘 개발되었을 때라는 전제가 있습니다.

 

그러면 하부(레거시) 시스템 연계에 대한  재사용성을 높일 수 있다고 했는데 웹 애플리케이션 페이지의 재사용성은 높일 수 없을까?벤더들은 포탈에 그 답이 있다고 이야기합니다.

 

1.3.3    Portal

자바에서 이야기하는 포탈을 한 문장으로 요약하자면, 포틀릿이라는 컴포넌트를 개인화시킨 웹 사이트라고 지칭할 수 있습니다. 포틀릿 명세서(JSR-168, JSR-286)를 잠깐 살펴보면 포틀릿은 서블릿과 같은 형태의 웹 컴포넌트이지만, 포탈 웹페이지에 삽입되어 실행될 수 있는 속성들을 가지고 있습다. 서로 다른 사용자 및 인스턴스 포탈 데이터 별 파라미터에 따라, 동일한 포틀릿에 대한 다수의 인스턴스들은 동일한 포탈 페이지에 같이 놓일 수 있습니다.

 

말이 필요없습니다. 백문이불여일견(百聞不如一見)이라 했습니다. 지금(2013년 11월)은 서비스를 종료했지만 기존에 구글의 iGoogle이라는 포탈서비스가 존재했었습니다. 

 

이러한 개념을 벤더들은 포탈이라는 웹 애플리케이션 서버 위의 포틀릿 컨테이너를 만들어 실행하고 있습니다. 기업 고객들은 다양한 사용자 군을 가지고 있습니다. 가령 기업이 제조회사라고 하면 영업, 생산, 마케팅, CxO(CEO, CFO, CIO 등을 일컫는 말) 영역이 있다고 했을 때 그들이 사용한 시스템을 별도로 만든다는 것은 비용이 상당히 들어가는 작업이며, 각 애플리케이션들이 공통의 데이터(로그인, 권한, 생산실적, 판매실적, 영업망 등)를 다루게 될 확률이 높아집니다.

 

기업 내 공통 웹 화면에 해당하는 것을 미리 포틀릿 컴포넌트를 만들고, 그것을 프로젝트에서 가져다 사용하면 어떨까요? 미리 구성되어 있으니, 연결하는 속성만 알고 있다면 각 사용자를 위한 개인형 포탈이 쉽게 개발될 수 있을 것입니다. 이에 따라 포탈 제품들이 나오게 되었고, 이 또한 EAI와 같이 많은 기업들이 도입을 하기 시작했습니다. 영업포탈, 사용자 포탈, 부서 포탈, 마케팅 포탈 등은 포틀릿 재사용을 통해 사이트가 구축되었습니다.

 

사실 초기에는 개인화를 하기 위해 각 개개인이 설정한 정보를 LDAP 등에 저장하여 사용하는데, 로그인시 권한, 페이지 구성 등에 대한 내용이 너무도 복잡한데다, 그것을 웹 세션 등에 저장함으로 인해 과도한 메모리 소비, 성능 문제를 야기함으로써 많은 시행착오를 겪게 되었습니다.

 

그럼에도 불구하고 포탈의 개념은 많은 장점들을 가지고 있었으며, 여기서는 설명하지 않는 BPM, 위에서 설명한 EAI 등과 연계되었을 경우 논리적인 관점에서 가장 이상적인 아키텍처를 표현하게 됩니다. EAI와 함께 포탈을 도입하는 고객들은 모든 레이어가 재사용이라는 주제 아래에서 프로젝트의 신속성을 통한 Time To Market이라는 기업의 궁극적인 목표를 달성해 줄 것처럼 보였기 때문이었습니다.

 

얼마나 시장에 발 빠르게 대응하느냐의 문제, 즉 Time to Market은 기업 생존의 기본 요소였고 지금도 그렇습니다. 기업들이 비즈니스를 하는 목적은 이익일 것이고 그러기 위해 얼마 전까지만 해도 양질의 제품을 얼마나 많이 제공하느냐가 가장 중요한 문제였습니다. 하지만 최근 시장이 너무도 빠르게 변화함에 따라 시장에 얼마나 발 빠르게 대응하느냐가 기업의 수익에 있어서 가장 큰 변수로 작용하고 있습니다. 다른 경쟁기업에 비해 새로운 아이디어를 제품으로 더 빨리 내놓기 위해서는 IT 환경의 다이내믹한 지원이 절대적으로 필요해지고 있는 것입니다. 이를 벤더들이 가만히 보고 있지 않았을 것입니다. SOA의 탄생은 여기서 시작합니다.

  

1.3.4    SOA

기업의 변화를 가로막는 3대 요인은 다음과 같습니다.

l  복잡성(Complexity) : 다양한 사람, 프로세스, 부서

l  경직성(Inflexibility) : “현 상태에 문제없으면 굳이 바꿀 필요 없다”

l  취약성(Brittleness) : 복잡성과 경직성으로 인한 이상의 발생 위험성

 

1996년 가트너 보고서에는 이런 말이 실립니다..

"잘 정의된 인터페이스를 가진 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술 구조 방식을 SOA(Service Oriented Architecture)라 한다"

 

벤더에게 딱 맞는 말이 아닐까 합니다. 비즈니스적인 용어이지만 무엇인지 그것을 이용해 새로운 무언가를 만들기 위한 좋은 단어임에는 틀림없어 보입니다. 일련의 컴포넌트, 위에서 이야기한 포틀릿과 어댑터를 통한 애플리케이션입니다.

 

이제 컴포넌트를 서비스로 바꾸어 생각해보죠. 서비스라는 용어를 다시 IT가 아닌 비즈니스로 생각해봅시다. 현재까지 기업에서 IT적인 요소가 필요할 경우, 컨설팅을 통해 프로젝트를 계획하고 여러 단계를 거쳐 프로젝트 수행으로 지원했던 반면 향후에는 서비스(Service)라는 단위로 IT로의 접근 및 활용해야 한다고 주장했습니다.

 

또한 새로운 상품에 대한 기획 안이나 아이디어들이 IT 환경에서 즉시 활용되기 위해서는 업무적으로 바로 활용할 수 있는 서비스 단위로 구성된 각 조각들을 마치 어린이용 블럭을 조립하듯 설계와 시뮬레이션이 되어야 한다고 말합니다. 이것은 SOA를 선전하는 벤더들이 시장에서 BPM과 같은 제품들을 SOA 영역에 포함시키는 이유이기도 했습니다.

 

SOA는 아키텍처이지 기술이 아닙니다. SOA를 구현하는 기술들은 ESB, 포틀릿, 리포지토리, 웹 서비스, 어댑터 등의 다양한 기술들이 존재합니다. SOA에서 가장 중요한 서비스는 업무적인 단위이고, 하나의 업무를 수행하기 위해서는 여러 시스템에 걸쳐 정보를 조회하거나 트랜잭션을 발생시켜야 하는 경우가 많습니다. 이를 구현하기 위한 앞서 언급한 다양한 기술들을 사용해야 하지만, 그러한 방식 모두가 모든 기업 환경에서 사용하기에 적당하다고는 할 수 없습니다.

 

SOA가 가트너에 의해 언급된 지 어느덧 20여년이 넘는 시간이 흘렀습니다. 국내 시장의 경우에는 SOA가 소개되는 과정에서 관련 벤더들의 몫이 컸습니다. 벤더들은 자사의 제품을 소개하는 과정에서 SOA를 대대적으로 홍보하기 시작했고, 실제로 수많은 개발자들이 그런 벤더들의 세미나나 제품 소개를 통해 SOA를 처음 접하고 알게 되었습니다. 이런 이유로 개발자의 입장에서는 SOA의 개념과 실체가 다소 왜곡된 형태로 전달될 수밖에 없었습니다.

 

SOA가 서비스가 유기적으로 잘 동작하려면 다음의 특성들을 가지고 있어야 했습니다.

 

● 프로세스 통합의 구조

프로세스를 가진 각각의 노드들이 업무적인 단위의 서비스로 표출되고 그것을 업무 관련 담당자가 설계에 참여할 수 있어야 합니다. IT로 전환될 때 설정치에 따라 시뮬레이션되고 결과 예측이 가능해야 합니다. 벤더에서는 BPM 제품을 통해 프로세스를 지원하고 있습니다.

 

● 시스템 통합의 구조

기존 EAI 시스템에서 담당했던 것과 유사한 기능의 구조를 제공해야 합니다. 업무적인 단위인 서비스는 여러 시스템과 관련될 가능성이 높습니다. 그러므로 해당 시스템의 최적화된 프로토콜 방식이나 웹 서비스와 같은 좀 더 표준화된 방식의 지원이 모두 가능해야 합니다. 보통 SOA 제품군에서는 ESB(Enterprise Service Bus)를 통해 이를 지원하고 있습니다.

 

● 데이터 통합의 구조

시스템의 통합은 보통 애플리케이션(application)간의 인터페이스를 뜻하는 경우가 많으며 여러 시스템에 흩어진 여러 가지 형태(DB, File, LDAP 등)의 데이터들을 하나의 관점에서 바라볼 수 있게 하는 구조가 필요합니다. 더 나아가서는 하나의 관점에서 바라보는 것과 더불어 여러 가지 프로그램 언어나 인터페이스 방식으로 해당 데이터에 대한 조회나 트랜잭션을 할 수 있는 방안을 제공하는 것도 필요합니다. 벤더들은 EII(Enterprise Information Integration) 제품을 통해 이를 지원하고 있습니다.

 

하지만 SOA의 문제는 무엇일까요? 아이러니하게도 EAI에서 발전된 양상이니 만큼 EAI가 가졌던 한계성을 극복하지 못한 것으로 필자는 보고 있습니다. 컴포넌트가 업무 단위의 서비스로 올라오긴 했지만 여전히 업무에 연관된 이들이 너무 많은 관계로 이를 조직적인 차원의 통제(Governance)가 이루어지지 않으면 성공하기란 하늘의 별따기 수준이었습니다.

 

전사적인 차원의 접근이 필요한 SOA 프로젝트가 부서간의 경쟁이 이루어지는 기업 조직에서 자신들의 업무를 타 부서에 공개하고 공통의 서비스를 찾아낸다는 게 쉽지 않은 일이었습니다. 2005년도 전후에 기고된 문서들을 읽어보면 그 때는 장밋빛 전망을 상당수 내놓았었습니다. 우리는 현실에 살고 있지 이상(理想) 속에서 살지 않습니다. 성공 사례(Best Practice)가 없다는 이야기는 이상이 현실이 되지 못했다는 이야기일 수도 있습니다.

 

대략 IT트렌드는 여기서 접겠습니다. 이후 무수히 나타난 개념들은 결국 현재의 종착역인 클라우드로 모이고 있습니다. 웹 애플리케이션 서버 관점에서 위의 정도를 알아두면 좋기 때문에 기술한 것입니다.

 

IBM, Oracle, SAP 등의 SOA제품을 가진 벤더 공통점은 무엇일까요? 그것은 앞서 나열한 개념을 구현한 제품들이 웹 애플리케이션 서버 위에서 만들어진 비즈니스 서비스 컴포넌트를 위한 컨테이너(포틀릿, BPM, ESB등)일 뿐이었다는 것입니다.

 

1.3.5    웹 애플리케이션 서버 순수 기능으로의 회귀

 

근래에 들어 이러한 서비스 개념에 대한 부분은 상당 부분 사라졌으며, 웹 애플리케이션 서버의 기본 항목을 이용한 스프링 프레임워크와 같은 도구를 사용하여 개발하여 가장 가벼운 형태의 개발이 다시 주를 이루고 있습니다.

 

전자정부 프레임워크 또한 표준 기반의 자바를 활용하여 벤더에 종속적이지 않은 코드를 만들어낼 수 있도록 고안되어 상당수 정부 기관의 프로젝트에서 사용중에 있습니다. 이로 인해 기존의 표준 WAS로 제정되었던 제우스, 웹로직과 같은 라이선스 비용이 비싸고,유지보수 비용에 상당한 투자가 들어가는 부분을 오픈소스 SW기반의 WAS로 전환하고자 하는 움직임이 계속되고 있습니다.

 

기존 상용 WAS를 오픈소스SW 기반의 WAS로 전환했을 때 얻는 이점을 상당히 많으며, 이는 WAS 뿐만 아닌 다른 소프트웨어의 경우도 마찬가지로 볼 수 있다.

 

[표] 상용 소프트웨어와 오픈소스 소프트웨어의 비교

구분	상용 소프트웨어	오픈소스 소프트웨어
비용분석	- 적용비용이 적음 - 유지비용 및 시스템 개선비용이 높음(윈도우계열)  - 소수의 관리자에 대한 관리비용 높음  - 라이선스 수수료에 대한 비용발생	- 적용비용이 낮음(무료) - 유지비용이 낮고 기능확장에 대한 추가비용이 들지 않음  - 다수의 공개된 사용자에 의한 관리로 관리자에 대한 관리비용이 낮음.  - 서비스에 대한 비용발생
성능분석	- 규모가 큰 시스템 환경에서 비교적 높은 성능  - 고가의 장비로 인한 고성능  - 전체적으로 공개SW와 비슷한 성능	- 규모가 작은 시스템환경에서 높은 성능  - 높은 안정성 및 비용효율이 높음
보안성	- 폐쇄적인 운영으로 인한 공개되지 않은 시스템 취약점 보유  - 최근에 다수의 취약점 발견으로 많은 보안 위협에 노출  - 프로토콜 호환이 어려워 인증체계가 취약함	- 개발 시부터 공개되어 이미 많은 취약점이 해결된 안전화 상태  - 공개키 기반의 인증 메커니즘 구현을 위한 통합패키지존재(적용이 용이)  - 다양한 암호화 알고리즘 및 키 관리에 대한 기능 제공
경제성	- TCO 높음  - 구입비, 유지비가 높음	- TCO낮음  - 라이센스 비용없음
기술성	- 재 사용성 없음	- 재 사용성 높음  - 유지보수, 업그레이드 용이  - 독점폐해방지
저작권	- 일반 라이선스  - 독과점에 의한 가격결정우려	- GPL라이선스, BSD라이선스 등
확장성	- 서버의 가용성 측면에서 클러스터링 비효율성  - 소프트웨어간의 호환성이 보장되나 높은 적용비용과 제한된 시스템 운영환경	- 효율적인 클러스터링 구현가능  - 소프트웨어간의 호환성이 조금 떨어지나 적용비용이 거의 들지 않고 낮은 수준에서의 기능추가 가능
경쟁력	- 소프트웨어선진국에 유리	- 공동개발상식에 따른 효과우수

 

 

1.3.6    웹 애플리케이션 서버 시장 현황

현재 웹 애플리케이션 서버 시장에서 공개 SW가 가지는 영향력은 상당합니다. 2012년 ZeroTurnAround사에서 진행한 개발 관련 서버 시장 조사의 웹 애플리케이션 서버 영역에 대한 결과는 아래와 같이 나타나고 있습니다.(2014년도 비슷함)

 

서버 이름	시장 점유율
GlassFish	11%
WebSphere	10%
WebLogic	14%
JBoss	28%
Jetty	27%
Tomcat	59%

현재 전세계의 애플리케이션 서버 시장 자체가 오픈소스SW 형태로 전환되고 있으며, 상용 SW 벤더로부터의 이탈이 점차 빨라질 것으로 예상하고 있습니다.

 

자바 웹 애플리케이션 서버에서 시작한 다양한 컴포넌트들이 다시 순수 기능으로 회귀하고 있는 상태입니다. "Simple is the best"를 알고 있다면 그것을 어떻게 효과적으로 사용하고 상호 운용성을 높일 수 있는지가 현재 IT 시스템을 만드는데 있어 화두입니다.

 

출처 : 오픈소스컨설팅 최지웅