[지디넷코리아]기업의 생산성을 최대로 높이기 위한 필수 요건 중 하나가 지금까지 사람이 맡아왔던, 사업절차에 필요한 다양한 시스템의 접합을 기술로 대체하는 것이라는 점은 더 이상 비밀이 아니다. 이런 기술은 파이어월 뒷단에 위치한 시스템 사이에서만 적용되는 것이 아니라 협력업체, 공급사, 고객들처럼 파이어월 외부의 요소들에도 적용돼야 한다.

지난 몇 년간 통합 기술은 존재해왔다. 그러나 대부분 ‘전용 연결’ 기술이었기 때문에 소유 비용이 감당하기 힘들 정도로 높았다. 또한 한 부분을 조금만 업그레이드해도 다른 관련 시스템을 여기에 맞춰야 했기 때문에 결국 프로젝트가 줄지어 생기는 일이 일아나곤 했다.

결국 IBM과 MS는 지금 고객의 고통 해소가 절반, 그리고 상대방 회사의 고객을 빼앗아오기 위한 교두보를 구축한다는 희망이 절반인 채 상이한 미들웨어 기술과 애플리케이션을 통합하는 방안을 모색하고 있다. 이에 대한 단적인 예가 바로 IBM의 자바 기반 웹스피어와 MS의 닷넷이다.

API의 수많은 집합인 이에 대한 결과물은 현재 웹서비스라 불리고 있다. 모든 시스템이 이해할 수 있는 XML 기반 언어로 구축되는 웹서비스는 ‘전용 연결’을 대다수 대체할 수 있다. 궁극적으로 모든 시스템이 동일한 언어를 사용하게 된다면 기업은 가장 많은 비용을 잡아먹는 부분을 타개할 수 있을 것이다.

API의 진화, 플러그인 천국 만들다
API의 진화에 따라 웹서비스 플러그인들로 점철된 시스템을 통해 소프트웨어 컴포넌트들이 어떻게 서로 쉽게 통신할 수 있는지 검증되고 있다. MS의 비주얼 스튜디오 닷넷과 같은 개발 툴들은 서비스 지향 아키텍처(SOA)에 따른 소프트웨어를 만들어내는 것 뿐 아니라 기존 소프트웨어에도 몇 단계만 추가해 XML을 지원하는 서비스 지향 계층으로 변신시키는 역할까지 수행하고 있다. 바뀐 소프트웨어는 그 내부는 이전과 동일한 구식 아키텍처라 하더라도 외부에서는 웹서비스를 훌륭히 지원하는 것처럼 보인다.

웹서비스를 수용할 준비가 됐다고 해서 모든 문제가 해결된 것은 아니다. 소프트웨어 컴포넌트와 시스템을 서로 용이하게 통신할 수 있도록 만들 수 있다는 것과 이것을 반드시 해야 한다는 것은 별개의 문제이기 때문이다.

매일 수백만건의 트랜잭션을 수행하는 시스템의 경우 웹서비스로 이전시킨다는 것이 트랜잭션들을 TCP/IP 네트워크로 분리해 최대 속도로 내보내고 그 결과만 기다리는 것처럼 간단하진 않는다. 트랜잭션들은 그 종류도 다양할 뿐 아니라 각 시스템 통합에 있어서 우선 순위를 두는 것도 필요하기 때문이다.

또한 트랜잭션 수신 시스템의 수신 경로를 네트워크로 대체하고 ‘XML 요청에 개방’돼 있다는 신호를 간간히 보내기만 하면 되는 문제도 아니다.

물론 둘 다 할수도 있다. 그러나 상황에 따라서는 대공황을 불러일으킬 가능성도 농후하다. 축구경기를 보기 위해 수천명의 관람객이 무질서하게 출입문으로 쇄도하는 상황을 가정해보라. 결과는 전혀 아름답지 않다.

네트워크로서의 TCP/IP는 트랜잭션의 무결성을 통제할 수 있는 내부 기능이 충분하지 않다. 트랜잭션은 신뢰성 있고 안전해야 하며 대부분 잘 조율된 형태로 우선순위를 갖고 진행돼야 하기 때문이다.

웹서비스, XML 지원이 전부가 아니다
이런 폭주 사태를 다루는 일은 XML이나 웹서비스의 전문 영역이 아니다. 십년 이상 시스템 통합에 매진해온 전문가들이 해온 방식처럼 이런 문제들은 데이터, 혹은 네트워크 프로토콜에 상관없이 통합 전문가가 나서서 해결해야만 하는 종류의 문제다. 물론 대부분 각자의 고유한 방식을 쓰겠지만 말이다.

이와 같은 혼돈에 질서를 부여하는데 있어 XML, 그리고 웹서비스 측면에서의 정답은 통합 시스템간에 추상화 계층의 역할을 하는 메시지 큐를 추가하는 것이다.

이런 비유가 과도한 단순화일 수도 있지만 IBM의 웹스피어MQ와 같은 메시지 큐는 통합에 있어 축구경기에서 관람객들의 출입을 질서있게 만드는 줄과 같은 역할을 한다. TCP, UDP와 같은 프로토콜은 QoS 보장과 같은 문제들을 프로토콜 스택의 상위 계층에서 일어나는 트랜잭션에 대해서는 적용할 수 없다는 우려도 큐를 통해 해결할 수 있다.

메시지 큐는 비용 절감이라는 측면에서도 장점이 있다. 전형적인 중재자 입장에서 메시지 큐를 이용하면 근방에 위치한 메인 시스템이 트랜잭션을 내보내는 데에만 전념할 수 있도록 할 수 있다.

큐는 여기에 라우팅이나 우선 순위 부여 등을 통해 트랜잭션을 이용하는 방법을 모색하는 매개자 역할을 수행한다. 관리 측면에서 이와 같은 업무 분담은 트랜잭션 로직을 비즈니스 로직과 연결시키는 복잡한 작업을 수월하게 진행할 수 있도록 해준다. TCO에 대한 일반 규칙이 ‘복잡도를 줄이면 비용도 줄어든다’라는 것임을 상기해보라.

그러나 메시지 큐, 그리고 이와 관련된 추상화 시스템만으로 혼돈의 가능성과 복잡성을 모두 없앨 수는 없다. 최소한 메시지 큐를 직접, 서로 연결하는 데에는 ‘직접 연결’을 사용해야 한다. 추상화 과정을 통해 개선될 수 있긴 해도 말이다.

예를 들어 메시지 큐를 다른 시스템이나 다른 메시지 큐에 연결하려면 시스템의 이전이나 변경, 교체시마다 큐를 재프로그래밍해야 할 수도 있다. 통합해야 할 시스템으로 구성된 행렬에 노드가 두개만 있다면 별 문제가 아니겠지만 통합이 아주 어려운 시절에는 시스템을 두개 이상 수동으로 연결한다는 것은 꿈에서나 가능한 일이었다.

메시지 큐, 이기종 시스템을 연결하라
통합이 보다 보편화되고 더 많은 노드가 추가됨에 따라 메시지 큐를 사용하면 접속에 추가 책임을 지지 않아도 된다는 사실은 분명해지고 있다. 통합이 하나의 문제라면 시스템이 잘 성장하는지는 이와 또다른 문제이기 때문이다. 메인 시스템과 메시지 큐를 다른 업무와 혼용한다면 전체 운영이 엉망으로 흐트러질 수 있다.

예를 들어 POS 시스템에서 발생하는 하나의 트랜잭션이 재고 시스템 - 물건이 있는가? - 과 신용카드 처리 서비스 - 유효한 카드인가? - , 장부, CRM 시스템 - 업데이트된 고객 정보가 있는가? - , 운송업자 - 한번에 운송하는가? - 들의 상호 작용을 초래한다고 치자. 여기에서 메시지 큐는 이 시스템들이 어디에 있는지 찾아내서는 안된다. 이유가 무엇이든지 간에 동일한 서비스로 다른 POS 시스템이 다른 비즈니스와 상호작용하는 경우라면 더욱 그렇다.

큐에 연결되는 데이터를 모두 관리하는 것보다 더 좋은 방법은 중앙의 한 곳에 라우터 정보를 유지시키는 형태로 또다른 추상화 계층을 구축하는 것이다.

BEA 웹로직의 제품 마케팅 담당 수석부장인 피터 린킨은 이렇게 설명했다. “필요한 것은 메시지가 무엇이고, 컨텐트가 어디에 있으며, 어디로 가야 하는지, 그리고 필요한 QoS가 무엇인지 알려주는 시스템이다. 그 다음에는 중앙 우체국과 같은 역할을 담당하는 다음 단계로 넘어간다. 우체국장은 ‘모든 지국에서 메시지를 내게 보내라. 내가 중재한다. 각 메시지가 정확하게 모든 종점으로 차질없이 전송되는 것을 보장하겠다’라고 말한다. 이것이 바로 비즈니스 프로세서에 따른 메시지 브로커다. 종점에 대해선 서로 모르기 때문에 각각 무지한 상태이며 대신 비즈니스 프로세스의 로직이 전송 배관 역할을 담당한다.”

만약 두개의 POS 시스템이 각 비즈니스 프로세스의 일부로 CRM 시스템에 접근해야 한다면 메시지는 목적지가 명시되지 않은채 패키징돼 CRM 시스템으로 보내질 준비를 하게 된다. 메시지가 큐의 제일 위에서 튀어나와 중앙우체국과 같은 브로커에 도달하면 우체국장은 ‘CRM 시스템이 어디에 있는지는 내가 알지’라고 말하며 메시지가 이미 정의된 QoS에 따라 확실하게 배달되도록 담보한다.

이런 브로커식 설계는 인터넷의 DNS와 동작 방식이 매우 유사하다. 예를 들어 CRM 시스템을 시벨에서 세일즈포스닷컴(Salesforce.com)으로 교체한다 해도 모든 큐를 다시 프로그래밍할 필요가 없다. 단지 중앙 디렉토리만 재프로그래밍해 ‘CRM 시스템이 저기 있다’라고 알려주면 된다.

“도시는 늘어났지만 터미널은 줄었다”
비록 전체적인 아키텍처에서 트랜잭션 시스템, 메시지 큐, 중앙 우체국과 같은 보다 기본적인 부분은 늘어났지만 관리 측면에서 책임 배분이란 점은 복잡도와 비용의 감소를 유발시키고 있다.

또한 워크플로우 로직의 컴포넌트들도 가장 효율적으로 배치되고 있다. 예를 들어 일부 고객 데이터가 CRM 시스템으로 전송되고 다른 고객 데이터는 다른 시스템으로 전송될 경우 이런 전송 결정을 내리는 브로커의 로직을 메시지 큐가 아니라 중앙 라우터에 위치시킬 수도 있다.

약간의 변화에도 수많은 시스템이 변경돼야 하는 트랜잭션 시스템과는 전혀 다르게 변경 지점이 감소될 뿐만 아니라 시스템 성능 또한 우수해진다. 이것은 다른 부분이 맡았을 때 더욱 효율적이 되기 마련인 잡무에 신경쓰지 않고 각 구성요소가 핵심 업무에 충실할 수 있기 때문이다. 게다가 변경 지점이 줄어들면 유지비용도 감소된다.

이러한 인프라스트럭처 프레임웍의 또다른 장점은 시스템이 일정 수준의 장애 극복 능력을 확보하게 된다는 것이다. 만약 제1 CRM 시스템이 고장나거나 응답이 없을 경우 중앙우체국은 이런 고장을 감지해내 트래픽을 어디로 우회시켜야 할지 판단한다. 이처럼 높은 신뢰도 때문에 SOA는 유틸리티, 혹은 온디맨드 컴퓨팅 개념과 결합되고 있다.

웹서비스의 아킬레스건, 트랜잭션을 해소하는 ESB
어떤 곳에서는 지금까지 설명한 아키텍처를 엔터프라이즈 서비스 버스(ESB)라고 부른다. IBM의 웹스피어 프로그램 담당 부장 스콧 코스비는 ESB가 아직 명확하게 정의되지 않았다고 경고했다. 그는 “각 기업 고객들이 독자적인 방식으로 자사만의 ESB를 구축할 가능성이 크다”라고 전했다.

코스비는 뒤이어 “가장 중요한 것은 ESB의 개념을 고려해볼 때 유연성이 핵심 사항이라는 점이다. ESB 구축에 왕도는 없다. 서비스 요청자(requestor)와 제공자(provider) 사이의 정보 배분을 최적화하는 접속 계층을 갖고만 있다면, 그리고 이 계층이 이벤트, 메시지, 혹은 SOA에 따른 컨텍스트에 반응할 수 있다면 바로 그것이 ESB이다”라고 설명했다.

그러나 코스비는 이런 환경에 있어 처음 등장한 것은 없다는 점 또한 상기시켰다. 이미 잘 알려진 바와 같이 IBM, BEA 같은 애플리케이션 서버 업체들은 상당기간 이런 아키텍처를 제공해왔다.

데스크톱 PC 분야에서 공통으로 채용된 내부 버스인 PCI에서처럼, 이 아키텍처가 정말로 시작되는 곳은 상호 접속기술에 합의해 기술 특성을 반영할 때다. 바로 이 때 표준이 도입된다.

코스비는 기존 레거시 ESB를 언급하며 현재 일어나고 있는 비즈니스 트랜잭션의 80%가 EDI를 통해 진행된다고 말했다. 바로 이런 이유로 코스비는 현존하는 시스템을 인식하지 못하는 ESB 정의상의 문제점을 경고했다. 그는 XML과 웹서비스가 훌륭한 ESB 구현 매개체라고 강조했다.

‘시스템 공용 언어’ 숙원 풀어준 웹서비스
대다수 사람들이 인지하고 있듯이 XML이나 웹서비스의 기초 구성요소인 SOAP와 같은 프로토콜은 통합돼야 할 시스템들이 모두 동의할 수 있는 요건들을 제공하기 때문에 통합이라는 큰 수레의 바퀴가 매끄럽게 굴러가도록 하는 역할을 담당하고 있다. 이런 요건들에는 데이터 읽기, 명령어, 각 시스템이 메시지 큐에 집어넣는 서비스 요청 등이 있다.

이와 같은 동의를 이뤄냄으로써 XML 기반 웹서비스는 기존 통합 방식에 내재돼 있던 또하나의 난제를 제거해냈다. 기존에는 이런 상호 이해가 로직의 어느 한 부분에 고유한 방식으로 프로그래밍되어야 됐다.

웹서비스가 등장하면서 모든 것이 바뀌었다. 시스템이 상호작용할 수 있는 표준 언어가 자리를 잡을 수 있게 됐을 뿐 아니라 장애물도 줄어들어서 IT 사용자들 사이에 시스템 통합에 대한 열망이 솟아오르고 있다. 그러나 너무 많은 시스템들이 통합이라는 가마솥에 던져진 나머지 전체적인 아키텍처의 부담이 증가하고 일부 컴포넌트에 과부하가 걸린다면 균열이 등장하는 것은 시간문제다.

많은 컴포넌트들을 통합시키는데 있어 단점도 함께 고려해보라. 만약 한 컴포넌트가 동기화되지 못한다면 다른 모든 컴포넌트들은 기다리고만 있을 것이다.

시스템은 마치 자동차 엔진과 같다. 엔진은 밸브를 열어 공기와 연료의 혼합기체를 엔진에 넣는 절차, 실린더가 엔진의 위로 올라갈 때 공기와 연료의 혼합기체를 압축하는 절차, 그리고 압축된 혼합기체에 불을 붙이는 스파크의 생성절차 간에 타이밍이 정확히 맞아야만 최대 성능을 발휘한다. 이로 인해 발생하는 연소에 의해 피스톤은 다시 실린더를 아래로 밀고 크랭크축이 회전해 자동차 바퀴를 움직인다.

만약 자동차에서 이 절차들 중 하나에 문제가 발생하거나 다른 절차를 앞서나간다면 가속 페달을 밟을 때 엔진은 심하게 덜컹거릴 것이다.

우수한 성능의 실시간 프로세스와 타이밍이 잘 맞는 컴포넌트에 대한 요구, 그리고 통합에 관해 증가한 관심 사이에는 아직도 상호 작용이란 부분을 망가뜨릴 수 있는 여지가 있다. 웹서비스에서는 시스템들이 서로 통신할 수 있는 공통 언어가 존재하지만 XML 스키마와 같은 데이터 교환 구조와 어휘에 대해 아직도 상당한 합의 과정이 필요하다.

이젠 데이터 교환 구조의 표준을 확립해야 할 때
SAP의 ERP 시스템은 웹서비스와 호환될지 몰라도 고객 데이터 스키마는 이것을 수신하는 시벨 CRM 시스템과 많은 부분에서 다를 수 있다. 예를 들어 각 고객의 어떤 필드를 추적하는가, 이 필드들의 정확한 이름, 그리고 그 길이에 대한 것들이 정해져야 한다.

두개 이상의 시스템이 동일한 데이터를 결국 다르게 처리하고 있다면 상호 연동시키기 이전에 이 문제를 해결해야 한다. 그러나 이러한 데이터 변환은 어디서 이뤄질까? 애플리케이션? 아니면 트랜잭션 로직? 메시지 큐? 중앙 우체국?

IBM의 코스비에 따르면 정답은 위에 제시한 모든 것이다. 데이터 변환이 발생할 수 있는 레거시 시스템의 상태별로 각각 다른 해법이 존재할 것이다. 또한 이런 컴포넌트에 변환의 책임을 맡기면 엔진이 덜컹거릴 수 있다. 그렇다면 궁극적으로 ESB를 택할 수도 있다.

예를 들어 상호작용하는 모든 노드들을 단일 데이터 포맷만 분석하도록 규정하고 각 시스템이 변환 어댑터를 통해 이 포맷에 접근하도록 하는 것은 어떤가? 이 접근법은 각 종점에서 나오는 고유한 데이터 포맷이 반대쪽 종점에 있는 ‘출력 변환’ 담당 어댑터에 도달할 때까지 브로커가 버스로 이동시키는 방식이다. 이 방법은 BEA의 린킨에 따르면 분명히 ESB의 정의와 일치하고 있다.

BEA의 린킨과 IBM의 코스비는 모든 버스 기반 시스템에 관리 계층이 필요하다는 점에 모두 동의하고 있다. 린킨은 이 관리 계층이 정해진 정책과 보안이 적용된 버스 주변에 서비스 디렉토리를 위치시키는 책임을 진다고 설명했다.

이 글을 읽는 당신이 아직까지 ESB를 생각해본 적이 없다면, 이제는 심각하게 고려해 볼만한 시점이 된 것이다. @