EAI – 선택이 아닌 필수 [초당벤처 포름:펀글]

[ducks]

기업의 CEO에게 잘 갖추어진 조직력이나 군더더기 없이 배치된 인력구조가 해결되기 어려운 그러나 지속적인 충원과 구조조정을 통해 해결해야 할 최우선의 과제이듯이, CTO나 전체 IT시스템을 총괄하는 이에게는 기업시스템의 통합(Integration)이 언제나 목엣가시처럼 걸려있는 난제이다. 그들은 다양한 하드웨어플랫폼과 데이터베이스, 언어와 프로토콜등을 위한 개발/유지보수 인력을 항상 중복해서 관리해야 한다. 이런 비효율적인 구조하에서는 아무리 선진적인 Front/Back-End시스템을 구축하였다하더라도 인프라 투자에 대한 ROI를 단기간에 기대하기는 불가능하다. 시스템의 감가상각이 채 끝나기도 전에 기업은 새로운 비즈니스환경과 시스템에 대한 요구로 또다른 투자와 인력배치를 필요로 하게되기 때문이다.

이러한 기반환경은 거의 대부분의 영역에서 관리비용의 중복을 발생시킨다. 수억원을 들여 구입한 아이비엠의 초고속 프린터가 Idle-time이더라도 HP유닉스기반의 정보계시스템에서는 약간의 경영정보 레포트를 출력하기 위하여 별도로 기천만원하는 라인프린터를 구입해야 한다. 그것은 스토리지, 채널, 네트워크, 기타 공조기기등의 하드웨어뿐 아니라, 시스템의 백업, 장애방지(Fault-Tolerance), 미러링등 시스템을 유지하기 위한 제기능의 동일한 영향을 미칠 뿐 아니라 각각의 시스템은 상호간의 자료전송을 요구하게 되기 때문에 별도의 채널프로그램(SNA와 X.25를 위한 SNAX의 경우처럼)을 구입해야 하는 것이다. 배보다 배꼽이 크다는 속담은 이 곳에서 정확하게 자기의 아이덴터티를 찾는다.

이러한 난맥상에서 가장 큰 책임은 물론 벤더들에게 있다. 계정계에서 대외계, 정보계, 인터넷서비스로 시스템을 확장하려는 클라이언트들에게 벤더들은 시스템의 다양화에 따른 위험성에 대한 아무런 경고도 하지 않았다. 그들의 제안서에는 확신이외의 어떤 뉘앙스도 없었다. 오히려 적당히 힘들어지면 통합솔루션을 위하여 다시 벤더들을 찾을 것 이라는 달콤한 꿈을 꾸고 있었는지도 모르겠다. 그리고, 그 꿈은 실현되었다. 올해 금융, 제조등의 대기업을 중심으로 EAI(Enterprise Application Integration) 시장이 새롭게 형성되고 있다.

더욱이 이들은 시스템의 진정한 통합은 상상도 하지 못하고 각각의 이기종이 동일한 형태의 메시지로 커뮤니케이션을 가능케하는 수준의 어댑터솔루션으로 해결하려는 경향을 보이고 있다. 그럴수밖에 없는 것이 하드웨어플랫폼과 데이터베이스와 각각의 언어들을 통합하는 것은 투자에 대한 ROI를 20~30년 정도로 잡고 장기적인 투자를 하지 않으면 안되는 거의 불가능한 작업이기 때문이다. 완전한통합을 어느정도 기대할 수 있었던 시점은 기업이 대외계와 정보계에 대한 투자시에 벤더들의 시스템을 합리적으로 판단할 수 있었어야 해따. 유일한 기회를 노친 것이다. 따라서 대기업의 EAI는 또다른 벤더들을 배부르게 하는 필요악이라 할 수 있다. 아무튼 통합(Integration)이라는 원죄는 이제 시장에서 공공연한 유행이 되었고, 물론 그 소문의 시작은 벤더들일 터이다.

하지만 아직 시스템과 개별 애플리케이션의 구성이 금융권처럼 산만하지 않은 기업에서는 완전한통합에 대한 기대를 버릴 필요는 없다. (무척 어려운 작업임은 분명하지만…) 게다가 이제 기본적인 전자상거래와 그룹웨어 정도로 구성되어 있는 대부분의 성장기에 있는 IT기업들에게는 EAI를 해결해야될 과제가 아닌 반드시 고려해야할 아키텍처 방향성의 측면에서 진지한 학습과 연구가 선행된다면 좋은 결과를 얻을 수 도 있다. 다시 한 번 강조하지만 그것은 빠르면 빠를수록 좋다. CRM과 CTI/콜센타(B2C 서비스 측면), ERP와 SCM(B2B 서비스 측면) 구축 그 이전에 호흡을 멈추고 그 기업의 3년후의 시스템 환경을 예측하고 통합을 진행시킬 수 있는 덕목이 여느때 보다 필요한 시점이다.

조금 경우는 다르지만 인터넷 환경을 중심으로 비즈니스를 진행하는 중소규모의 기업에서도 마찬가지의 문제는 동일하게 진행형이다. 단순하게는 자바와 C, ASP와 온갖 스크립트 언어가 개발자가 열명도 되지 않는 회사에서도 모두 제 각각인데다 개발방법론도 DB설계도구도 컴포넌트 제작도구도 마찬가지이다. 사내 인트라넷이나 그룹웨어, CRM이나 CTI같은 고객지원 시스템, 유통관리를 위한 시스템, 오프라인에서 온라인으로 확장한 기업의 경우에는 ERP와 같은 레거시시스템등의 혼란은 시간이 갈수록 더 할 것은 자명하다. 이들에게 진정한 EAI솔루션은 되려 EPI(Enterprise Process Integration)적인 관점이라 할 수 있다. 아쉽게도 어떤 SI, EAI 업체도 이러한 고민에 대한 적절한 방법론을 제공하고 있지는 않은 것 같다. 따라서 CTO는 나름대로의 방법론으로 접근해야하며, 동일한 고민을 하는 커뮤니티에서 서로의 지혜를 모아야한다.

언어측면에서는 XML이, 구축 데스티네이션 방법론 측면에서는 EIP로의 진행이 이런 산만함을 정리해줄지는 좀 더 두고 봐야 할 것이다. 그러나, 아무런 노력없이 솔루션을 도입하는 식의 원론적인 통합은 기회가 없을 것이다. 그것은 포춘지 100대 기업리스트에서 IBM, HP,COMPAQ,MS등이 모두 사라진 이후라도 또 다른 누군가가 자리를 잡고 있을 것이기 때문이다. 기업은 환경설정을 위한 최우선의 이슈로 이제 레거시시스템과의 혈통 보존을 최고의 가치로 두어서 판단해야하며, 기업에 필요한 솔루션을 동일한 벤더가 유력한 솔루션을 제공하게 되는 때까지 적절한 시점의 조정도 필요할 것이다. 혹은 방법론적인 측면의 설계를 완료한 후 아웃소싱을 통한 자체개발이나 개별 컴포넌트들을 부분 이식하는 방법도 있을 것이다.

물론 어떤 작업도 그리 녹녹한 것은 아니다. 지금의 SI회사나 에이전시들은 그네들이 홈페이지등을 통해서 홍보하고 있는 번역문장들도 무슨 말인지 정확히 모르는 곳들이 태반인 것이 우리나라의 현실이다. 아쉽지만 다시 한 번 모든 솔루션의 구축과 시행착오에 관한 국가적인 데이터베이스의 필요성을 강하게 느낄뿐이다.