WAS와 레거시 시스템, 어떻게 연동할까

대부분의 레거시 시스템은 자바가 아닌 다른 언어로 구성돼 있다. 시간과 비용이 충분한 경우에는 레거시 시스템 전체를 아예 자바로 전환할 수 있겠지만 현실적으로 그렇지 못한 경우도 있다. 특히 자바가 적용되지 못하는 영역, 이를테면 JVM이 완벽히 지원되지 않는 리얼타임 시스템이라든가 임베디드 시스템은 WAS로 서비스를 제공하기가 쉽지 않다.

또 이미 완성도가 너무 높아 자바로의 포팅이 필요하지 않는 레거시 시스템의 경우도 마찬가지로 전면적인 WAS로의 전환에 어려움을 겪을 수밖에 없다. 그러나 이런 어려움을 감수해서라도 WAS로 서비스를 제공해야 할 만큼 WAS의 유혹(?) 또는 필요성은 강력하다.

레거시 시스템이 WAS와 연동된다는 것은 서버로서 연동되는 경우와 클라이언트로서 연동되는 경우로 나뉠 수 있다. 전자의 경우는 클라이언트에게 WAS에 내장된 컴포넌트로서 보여지며 클라이언트의 요청을 처리하는 경우이다. 후자의 경우 레거시 시스템이 클라이언트로 가장해 WAS에게 요청하는 경우이다. 하지만 대부분 분산 시스템은 클라이언트/서버의 역할이 혼용되기 때문에 이 두 가지 경우를 모두 고려해야 할 것이다.

<그림 1> J2EE 아키텍처 모델

레거시 시스템도 여러 형태로 존재할 수 있다. 이런 상황에서 기존 레거시 시스템과 새로 구축될 WAS와 서로 다른 체계를 어떻게 통합할 것인가? 필자가 경험한 프로젝트를 기반으로 각각의 문제점들에 대한 해결 방안을 모색하고자 한다. 이를 분류해 보자면 다음과 같은 몇 가지 모델로 나눌 수 있다.

<표 1> 레거시 시스템의 유형

레거시와 WAS가 동일 시스템에 배치될 경우

레거시 시스템이 자바로 구현됐다면…

레거시 시스템이 자바로 구현되어 있고 동일 시스템의 경우라면 단순히 레거시 시스템을 EJB 컴포넌트로 만들어 J2EE에 배치시키면 될 것이다. 하지만 레거시 시스템이 리얼타임 운영체제나 임베디드 운영체제에서 운용된다면 문제는 심각해진다. 리얼타임이나 임베디드에 탑재되는 WAS가 발표되지 않은 상태이기 때문이다. 임베디드에 WAS를 올린다는 가정은 상상할 수 없으며 리얼타임 시스템의 경우 제품이 지원된다 하더라도 실시간 처리에 대한 자바의 결함(JVM 자체의 시간을 예측할 수 없는 처리의 모호함 같은)이 완벽히 해소되지 않은 상태이다.

레거시 시스템이 다른 언어로 구현됐다면…

레거시 시스템이 자바가 아닌 다른 언어로 구현되어 있는 동일 시스템의 경우를 살펴보자. 레거시 시스템이 라이브러리 형태로 제공될 수 있다면 기존 레거시 시스템에서 JNI(Java Native Interface)를 통한 호출을 하면 될 것이다. 하지만 레거시 시스템이 C/C++로 구현되어야 한다는 제약이 있다(BEA의 웹로직의 경우 비주얼 베이직, 비주얼 C++, ASP, 파워빌더 등에서 사용할 수 있도록 임포트 모듈을 지원하고 있지만 특정 제품에 종속적인 경향이 있어 이 원고에서는 제외하기로 한다).

여기서 괄목할만한 것은 레거시가 동일 시스템에 배치될 경우 레거시 시스템과 WAS의 바인딩이 통신 메커니즘 기반의 메시지를 통한 바인딩이 아니라 JNI나 임플로이를 통한 직접 바인딩이 될 수 있다는 것이다. 물론 직접 바인딩 방법은 몇 가지 제약이 따르지만 가장 이상적인 방법이 될 수 있으며, 메시지를 통한 바인딩에 따르는 통신 비용이 제거된다. 즉 레거시 시스템 연동시 우선적인 고려 사항은 ‘직접 바인딩시킬 것인가’ 아니면 ‘통신 메커니즘을 통해 바인딩시킬 것인가’의 문제가 될 것이다.

<그림 2> WAS와 레거시 시스템 연동 방법

레거시와 WAS가 원격지에 배치될 경우

레거시 시스템이 자바로 구축됐다면…

레거시 시스템이 자바이며 원격지에 구축된 경우 WAS를 통해 연동할 수도 있겠지만 WAS를 구동한다는 것은 시스템 자원(CPU, 메모리 등)과 비용, 이식성의 문제가 야기될 수 있다. 따라서 레거시 시스템이 운용되는 장비에서는 WAS를 사용하지 않는 경우가 대부분이다. 이 경우 JDK에 내장된 RMI(Remote Method Invocation)나 RMI-IIOP(Internet Inter Orb Protocol)를 이용해 연동을 위한 인터페이스만 추가로 구현해주면 연동 문제가 쉽게 해결될 수 있다. 이런 구조는 레거시 연동을 위한 개발 노력과 시간에 대한 최소 비용이 할애된다.

그러나 이와 같은 모델에도 문제점이 있을 수 있다. 기존 레거시 시스템이 요구하는 최고의 품질 요소가 퍼포먼스라면 좋은 모델이 될 수 없다. RMI 통신은 프로토콜 구조상 객체 직렬화를 위해 많은 데이터를 요구한다(대략 IIOP의 2배 소요된다). 이에 따라 필요 이상의 마살링(메소드 호출 매개변수를 전송하기 위해 표준 포맷으로 묶기 위한 기능)/언마샬링(표준 포맷에서 목표 객체에게 알맞은 포맷으로 푸는 기능) 비용이 든다. 뿐만 아니라 실시간 운영체제나 임베디드 환경에서 RMI 패키지는 지원되지만 RMIRegistry가 지원되지 않는 경우가 있다.

RMI-IIOP 통신으로 연동할 경우의 문제점을 제시하면 레거시 시스템의 대부분은 JDK 버전 1.4 이하로 탑재되어 있다는 것이다(가령 UNIXware의 경우 JDK 1.1.8 버전만 지원된다). JDK 벤더나 버전에 무관하게 CORBA 스펙으로는 연동이 가능하다고 되어 있지만 실제로 구현된 CORBA 패키지의 완성도가 떨어져 연동에 심각한 장애를 초래할 수도 있다. 이를테면 JDK 1.3 이하에서 내장된 CORBA 패키지는 ChildPOA를 생성할 수 없으며, 생성한다 하더라도 호출 과정에서 객체에 대한 정보를 찾지 못하기 때문에 정상적인 호출을 할 수 없다. 이와 같은 상황에서 필자는 성능과 안정성을 위해 JDK 1.4 버전 이상을 추천해왔다.

레거시 시스템이 다른 언어로 구축됐다면…

실제 레거시 시스템의 대부분은 자바가 아닌 다른 언어로 구성되어 있으며 WAS와의 연동 이슈가 가장 빈번하게 발생한다. WAS의 타겟이 주로 엔터프라이즈 시장이었지만 국방이나 네트워크 관리 시스템(NMS), 원자력 관리 시스템 등과 같은 시스템에서도 WAS의 요구가 증폭되고 있다(이 시스템들은 대부분 자바가 아닌 다른 언어로 구현되어 있다). 다른 언어로 구현된 레거시 시스템과 연동을 위해 선택할 수 있는 통신 메커니즘은 TCP/IP 소켓을 이용하는 방법과 CORBA를 통한 연동 방법이 있다.

TCP/IP 소켓을 이용하는 경우 개발자가 직접 통신을 위한 프로토콜을 정의해야 하며 통신시 장애와 예외 처리, 커넥션 관리와 같은 원시적인 통신 수단에 대한 고려가 가중된다. 즉 비즈니스 로직에 대한 고려보다 통신에 대한 고려가 증가되어 ‘배보다 배꼽이 큰’ 경우가 발생할 수 있다. 또한 언어마다 다르게 정의된 메시지 타입과 타입에 대한 데이터 크기, 시스템에 따라 다르게 처리되는 Byte-Endian 문제, 한글 코드셋 처리 문제 등 여러 부분을 정의해야 한다. 이와 같은 문제로 초기 클라이언트/서버(C/S) 시대로 다시 역행하는 결과를 낳으며 개발자들은 과거 C/S 개발자가 고민했던 모든 것을 그대로 상속받아 고민해야 할 것이다. 또한 레거시 시스템뿐만 아니라 WAS에서도 TCP/IP 소켓 커넥터를 구현해줘야 하기 때문에 이것만으로 하나의 프로젝트가 될 수 있을 정도이다. 사실 TCP/IP 소켓을 통한 연동은 경우의 수만 될 뿐이지 선택하기에 너무도 괴로운 작업이므로 더이상 고려하지 않기로 한다.

이 때 CORBA를 사용한 연동 방법이 가장 적절한 대안이 될 수 있을 것이다. J2EE에는 CORBA가 내장되어 있으며 CORBA에서 정의한 서비스, 이를 테면 트랜잭션, 네이밍, 타임 서비스 등과 같은 서비스들을 J2EE에서 확장하여 사용할 수 있다. J2EE 2.0 스펙에서는 표준 프로토콜로 CORBA를 채택하였기 때문에 WAS 연동에 가장 적합한 모델이 될 수 있을 것이다. 레거시 시스템의 입장에서 CORBA는 여러 프로그래밍 언어를 지원하고 있기 때문에 언어가 다른 시스템을 위한 연동 방법으로 가장 좋은 솔루션이 된다. 또한 TCP/IP 소켓의 문제점들을 IIOP 프로토콜로 모두 보완하고 있다.

실제 프로젝트를 통해 살펴본 가상 시나리오

CORBA를 사용한 연동 방법을 필자가 참여한 프로젝트의 예를 통하여 살펴보자. A 회사의 레거시 시스템은 RTOS 환경인 QNX 버전 6.2로 고객 관리에 대한 서비스를 담당하고 있었다. 이 프로젝트의 임무는 기존 레거시 시스템의 일부분을 분산 환경에서 새롭게 구축하는 것이며, AIX 5L 기반의 WAS와 연계하여 로드분산과 각종 관리 체계를 WAS를 통해 서비스할 수 있도록 해주는 것이다.

<표 2> A 회사의 시스템 운용 환경

먼저 고려할 것은 기존 레거시 시스템의 변경을 최소화하면서 확장될 WAS 체계와 연동해 성능(안정성, 효율성, 속도, 확장성, 이식성)의 극대화를 도모해야 한다는 것이다. 이 때 CORBA를 사용하는 경우 2가지의 방법이 있을 수 있다. 첫째는 CORBA 통신을 이용해 EJB 컴포넌트와 직접 연동하는 방법이며, 두 번째는 레거시 시스템과 EJB 컴포넌트 사이에 브릿지를 이용해 연동하는 방법이다.

<그림 3> CORBA를 이용한 WAS와 레거시 시스템 연동

<그림 4> 중간 브릿지와 CORBA를 이용한 WAS와 레거시 시스템 연동

먼저 CORBA를 적용해 연동하는 모델은 기존 레거시 시스템의 변경을 최소화하는 가운데 IDL 맵핑을 통해 서비스를 제공할 수 있는데, 분산 환경에서 성능을 최적화하여 연동할 수 있는 방안이다. 개발자는 레거시 서비스를 외부와 연동시킬 수 있는 CORBA 애플리케이션만 제작하면 된다. 이러한 경우 레거시 시스템에서는 WAS 사용을 위한 인터페이스와 인터페이스의 필드, 인터페이스의 부모에 해당하는 모든 스텁(stub)을 갖고 있어야 한다. 이 경우 상당한 스텁들을 레거시 시스템이 포함하고 있어야 하며 경우에 따라선 레거시보다 스텁의 크기가 더 많아질 수 있는데, 디스크 스페이스와 메모리가 부족한 임베디드 시스템에선 큰 단점이 된다.

다음으로 중간에 브릿지를 이용하는 방법은 레거시 시스템이 RTOS든 임베디드든 연동을 위한 스텁/스켈레톤 코드를 브릿지로 넘겨 레거시의 부담을 최소화할 수 있다. 이제 레거시 시스템에 포함되는 스텁은 레거시를 서비스할 IDL에 정의된 스텁만 남게 될 것이다. 레거시 대 브릿지간의 통신은 ORB를 사용한 IIOP 통신이 이뤄지며 브릿지 대 WAS의 통신은 RMI 통신으로 이뤄진다. 브릿지라는 프록시를 거쳐야 하는 비용이 들지만 레거시 시스템을 가볍게 가져가기 위한 방법으로 적당할 것이다.

하지만 CORBA를 사용하는 경우에 Any Type(CORBA 제공 타입 및 사용자정의 타입을 담을 수 있는 일종의 구조체)에 대한 처리 문제가 여전히 남아 있다. 레거시 시스템에서 Any Type을 정의한 경우 IIOP를 통해 전송되어 문제가 없다. 그러나 브릿지와 WAS간의 RMI 통신인 경우 CORBA의 Any Type을 직렬화 가능한 Any로 둔갑시켜야 하는데 자동화된 메커니즘이 없다. 즉 Any Type 전송시 직렬화할 수 있는 기능을 브릿지가 내장해야 한다. 즉 브릿지는 Any를 직렬화할 수 있는 타입으로 변경하는 로직을 포함해야 한다.

WAS는 아직까지 자바가 아닌 시스템과의 연동에는 불친절하다. 또한 WAS가 스펙 기반으로 진화하고 있지만 이런 스펙에 충실하지 않은 모습도 보인다. 하지만 이 원고를 쓰는 순간에도 이런 불리함을 감내하면서도 WAS에 매력을 갖게 하는 강력함을 다시 한번 절감하게 된다. @