통합 서비스 마스터리(Integration Service Mastery), 약칭 ISM은 Vitria의 BusinessWare나 JBOSS 같은 EAI/ESB의 기반 위에 구성되어 기업 통합백본의 역할을 한다. ISM은 기업내 어플리케이션 통합을 위한 최적의 개발 환경을 제공한다. 통합 웹 콘솔을 통해 사용자는 별도의 코딩 없이도 인터페이스를 쉽게 개발하고 관리할 수 있다. 또한 ISM은 수년간의 통합경험을 통해 해당 솔루션이 개발에 필요한 시간과 노력을 줄여준다는 사실을 증명했다. 결과적으로 ISM은 이미 개발된 기능이나 인터페이스 서비스의 관리자들에게 쉽고 편리한 통합 솔루션을 제공한다.
EAI/ESB 툴의 장점 및 한계는 통합 서비스와 환경을 추가적인 개발 없이 구성하는 것이 가능하게 해주는 반면, 사용자 요구사항에 최적화된 성능을 보장할 수 없다는 것이다. EAI/ESB 툴이 제공하는 일반적인 개발환경이나 기능을 그대로 이용하여 업무 요구사항을 구현할 경우, 필요한 수준의 성능을 내기 위한 별도의 개발 과정이 필요하다. 이런 식으로 개발이 진행되면 애초에 도입했던 툴의 효용은 사라지며 추가된 API가 이를 대체한다. 결국 EAI/ESB 툴을 통한 결과물은 당장은 괜찮지만 장기적으로는 변경 관리/서비스 확대를 위한 별도의 프로그램 유지 보수 인력을 요구한다. 필요한 인력의 수준은 초기 프로그램의 수준에 따라 달라지기 때문에 EAI/ESB 전문가 외에 해당 프로그램의 수준에 맞게 프로그램을 변경 및 관리 할 수 있는 인력이 추가로 요청된다.
이런 문제를 해결하기 위해서 통합 서비스를 구현하는 업체에서는 개발 환경 및 개발 방식의 표준화 등을 통해 제약 조건을 최소화하려고 하지만, 업무 요구사항에 따라 한계가 있다. 이는 프로그램 수준의 통일을 통해 해결할 수 있는 문제가 아니며 특정 개발자 및 유지 보수 인력의 능력으로 해결할 수도 없다. 특정 사용자 집단에서는 높은 수준의 개발 인력과 유지보수 인력을 보유하여 이 문제의 영향이 작을 수 있지만, 또 다른 사용자 집단은 정반대로 개발 인력 및 유지보수 인력이 모자라서 이 문제를 심각하게 받아들일 수 있다. 프로젝트를 운영하는 업체의 입장에서도 이전 프로젝트에서 고민했던 내용을 새로운 프로젝트에서 다시 고민해야 하는 상황은 결코 달갑지 않다.
통합 서비스 구성을 요구하는 대부분의 문제들은 이미 사용자 집단들의 대다수가 마주치고 있고, 이들은 이 문제들을 서로 유사한 방식으로 풀어가고 있다. 즉, 각 사용자 집단이 경험과 그 결과물들을 따로 누적해 가는 것이다. 이런 비효율적인 상황을 해결하는 가장 좋은 방법은 해당 툴을 제공하는 업체에서 업무 요구 사항에 따른 개발 경험을 누적한 결과물을 제공하는 것이다. 그 결과물은 업무 요구 사항에서 필요로 하는 기능 및 성능 요건들을 충족시킨 결과물로서의 프로그램이나 패키지가 되어야 한다. 그러나 현실적으로 툴을 제공하는 업체는 다양한 환경 – 대상 시스템 유형, 통합 방식 – 에 통합에 필요한 기능을 제공하지만, 업무 요구 사항에 대한 구현 경험은 갖지 못하기 때문에 기능에 대한 결과물 – 특정 어플리케이션과의 인터페이스 방식 – 은 제공할 수 있지만, 구현 경험에 따른 결과물은 제공하기 어렵다.
ISM은 일반 통신 프로토콜 수준의 통합 – 소켓, FTP, DBMS, 기타 – 만을 제공하는 것이 아니라 특별한 어플리케이션과의 통합 환경도 ISM에 포괄할 수 있도록 구성되어 있다. 또한 기능외의 성능 요구 사항이나 안정성 면에서 경험을 통해 검증된 구현 결과물(프로그램)을 제공함으로써 진정한 의미의 통합 서비스 백본 역할을 수행한다.
ISM이 제공하는 통합 서비스는 지난 10여년 간 EAI 또는 ESB가 진화해온 과정을 그대로 체화하고 있으며 EAI/ESB 툴을 통한 통합의 제약 조건을 넘기 위한 결과물이다. ISM이 제공하는 서비스를 좀 더 명확히 살펴보기 위해 이전 또는 현재 다른 툴들을 이용한 통합 방식의 장단점을 살펴본다.
EAI/ESB가 나오기 전에도 시스템 간 데이터 통합(연계)의 필요성은 존재하였지만, 통합을 위한 공통화된 기능들을 제공하는 허브(hub)가 존재하지 않아서 당시의 통합은 연계가 필요한 시스템들 사이에 직접 이루어졌다. 이 구성은 데이터를 발생시키는 시스템과 데이터를 받아들이는 두 시스템 사이의 직접 연결(Peer to Peer)로 데이터를 받아들이는 시스템이 늘어나면 직접 연결 갯수도 따라서 늘어나야만 한다. 통합 또는 연계에 관계된 시스템이 많아지면 많아질 수록 직접 연결 수도 늘어나게 되고 이 연결들은 네트웍 상에 수없이 많은 연결선들을 만들게 되며 이는 마치 스파게티 면처럼 많고 복잡하게 꼬여있다 하여 네트웍 스파게티(Network Spaghetti)라고 표현한다. 이 환경은 통합에 관계된 시스템이 적은 경우 그 연결 지점들이 명확하며, 특정 연결의 장애 또는 오류가 다른 연결에 영향을 미치지 않는다는 면에 장점이 있다. 하지만 통합에 관계된 시스템이 많아지면 이 장점을 상쇄시키는 이상의 단점들이 나타난다.
시스템 인터페이스 유형에 따라 다양한 코드가 다양한 개발자에 의해 개발되고 유지보수된다는 것이 가장 큰 단점이다. 인터페이스 기능을 수행하기 위한 코드는 각 시스템의 담당자에 의해 개발되고 관리되어야 하므로 통합의 주체는 따로 존재하는 것이 아니라 인터페이스를 수행하는 해당 시스템의 담당자들이 된다. 따라서 동일한 기능을 수행하더라도 각 시스템이 각자 통합 주체가 되므로 각자 코드를 작성하게 된다. 이는 개발 표준 준수 여부와 무관하게 개발된 결과물은 각 시스템의 인터페이스 프로그램 개발자의 능력에 좌우된다.
이 방식의 가장 큰 단점이 새로운 기술을 적용한 새로운 시스템이 등장하였을 때, 이 시스템과의 인터페이스를 수행할 개발 인력을 쉽게 갖추기 어렵다는 점이다. 인터페이스 기능을 새로운 시스템의 API또는 어댑터 등이 제공한다 하더라도 API나 어댑터를 이용한 프로그램을 작성해 주는 개발인력이 필요하며 이를 위해 별도의 인력 양성 계획이 필요하다. 이는 개발 결과물의 표준화된 품질을 보장하기 어렵다는 위험 요소로 작용한다.
EAI/ESB 통합은 P2P 통합의 한계를 어느 정도 극복한 형태의 통합이다. 기존의 복잡하고 취약한 연결 대신, EAI/ESB는 통합 실제의 집중화와 표준화를 위해 다양한 미들웨어 모델들을 도입했다. 이로써, EAI/ESB는 복잡한 통합에서 벗어나 더 높은 수준의 통합을 제공할 수 있게 되었다.
EAI/ESB가 도입되면서 업무 기능이 아닌 인터페이스 기능에 대한 부담은 툴이 가져가게 됨으로써 사용자들은 업무 기능의 구현에 대한 부담만 안게 되었다. 이를 통해 지나치게 복잡하고, 분산되어 있던 코드들은 어느정도 EAI/ESB가 흡수함으로써 관리 부담도 같이 적어지게 되었다. 이로 인해 특수한 프로토콜에 대한 전문가만이 구현할 수 있었던 시스템 인터페이스를 어느정도까지는 쉽게 구현할 수 있도록 하였다.
EAI/ESB는 통합 업무 요건을 구현하기 위해 최소한의 업무 로직만 작성할 수 있도록 하여 개발의 편의성도 상당히 높여 주었으며 구현된 프로그램의 deploy 과정도 GUI를 통해 쉽게 만들었다. 그러나 이것이 결정적으로 내부에는 중복된 코드가 산재하고, 통합 요건 단위와 프로그램 단위가 (모두 그렇다는 것은 아니지만 거의) 1:1로 구성되는 한계를 만들었다. 이는 P2P의 문제인 네트웍 스파게티를 EAI/ESB 안으로 끌어들여 스파게티 코드를 구성한 결과를 낳았다. 그러나 어찌되었건 복잡한 부분은 EAI/ESB 내부로 가져왔으므로 최소한 시스템 구성 상에서는 통합 대상 시스템들과의 인터페이스는 표준화/단순화하는 효과를 가져왔다.
통합에 관계되는 컴포넌트들을 모니터링하고 관리하는 기능을 내장함으로써, 프로세스 또는 모듈이 정상적으로 작동하고 있는 지에 대해 관리하며 오류나 장애 발생 시에 Failover 등의 기능을 통해 서비스 중단을 최소화하도록 하는 기능을 제공한다.
여기서 놓치지 말아야 할 것이 통합 서비스의 핵심이 인터페이스를 잘 수행하는 기능이 아니라는 것이다. 인통합 서비스의 핵심은 인터페이스의 관리 기능이다. 인터페이스를 잘 수행하느냐의 여부는 EAI/ESB 만이 아니라 통합 서비스를 제공해야 하는 시스템이라면 기본적으로 갖춰야 하는 기능이다. 통합 서비스를 제공하는 시스템은 서비스 관점의 인프라 스트럭쳐로서 기능하기 때문에 존재 여부가 느껴져서는 안된다. 존재 여부를 확인시키기 위해 장애를 발생시킨다든가 하는 것은 상상도 할 수 없는 일이다. 인터페이스 관리 기능은 인터페이스가 정상적으로 수행되고 있는지, 수행된 결과가 어떠한지, 또 변화가 필요할 때 현재 서비스에 영향을 주지 않고 유연하게 변화를 수용할 수 있는 구성이 되어 있는 지 등을 포함한다. 이 기능들은 단순히 툴에서 제공할 수 있는 기능이 아니라 툴의 기능을 사용자의 업무적인 관점에 맞게 커스터마이징하는 과정을 거쳐서 구현되는 기능이다. EAI/ESB 툴이 제공하는 기능은 개발 툴로서는 관리하기 쉽고 편리하지만 운영 툴로서는 적합하지 않다. EAI/ESB 툴이 제공하는 관리 기능은 해당 툴 내의 컴포넌트에 대한 관리 기능으로서 업무와 연결되어 있지 않다. 관련 컴포넌트의 상태를 보여주는 것은 가능하지만 실제 서비스가 정상적으로 수행되고 있는 지의 여부를 확인하기는 어렵다. 개별 컴포넌트의 상태가 업무 서비스와 직접 연결되지 않기 때문이다. 따라서 각 사용자 집단은 각자의 요구 사항에 맞게 해당 툴에서 제공되는 데이터를 이용하여 운영에 필요한 정보를 추출하는 개발/커스터마이징 과정을 거쳐야 한다. 이에 대한 좀 더 효율적인 방법은 운영 상황을 고려하여 설계 단계에서 이미 필요한 데이터 및 사용 방법을 고려하여 개발 과정에 이를 포함시키는 것이다.
변화 관리라는 관점에서는 더욱 어려운 과정을 거쳐야 한다. 개발 툴로서의 변경 관리는 개발된 프로그램의 버전 관리, 버전의 적용 방법 정도면 충분하지만, 운영 툴로서의 변경 관리는 개발된 프로그램 관리 – 형상 관리 – 외에 업무 서비스의 변경/추가 등에 대해 어떤 방식으로 관리하느냐가 중요한 과제이다. 프로그램 버전 관리 시에도 변경된 소스의 변경 내역이 관리되어야 하듯이, 업무 서비스의 변경 시에도 변경 내역이 관리되어야 한다. 그러나 일반적으로는 EAI/ESB 툴이 아닌 일반적인 시스템 환경에서도 시스템화된 형태로 업무 서비스 변경 내역이 관리되지 않는다. 이는 업무 서비스와 프로그램이 밀접하게 연결되어 있기 때문에 변경된 사유는 존재하지만, 그로 인해 무엇이 어떻게 변경되었는 지 정보는 관리되지 않기 때문이다. 프로그램의 변경 관리 측면에서도 일반 EAI/ESB 툴의 작업 결과물은 컴파일된 프로그램으로 생성된다. 업무가 변경되면 프로그램 코드가 변경되는 것이며 프로그램 코드의 변경은 필연적으로 해당 코드를 사용하는 프로세스의 재시작을 요구하게 되며, 이는 해당 프로세스의 서비스 중단을 의미하게 된다. 물론 대부분의 시스템은 마스터/백업, 클러스터링 등의 환경을 구성하여 최종 사용자 입장에서는 서비스 중단이 없도록 한다. 하지만 이는 툴 자체에서 제공하는 변화 관리 기능과 운영 측면의 변화 관리 기능에 괴리가 발생하는 것을 의미한다. 이런 현상이 발생하게 되는 근본적인 이유는 업무 요구 사항이 프로그램에 고정되어 있어서이다. 어떤 프로그램도 업무 요구 사항과 별도로 구현될 수 없다. 다만 변경 요건의 경중에 관계없이 프로그램 코드를 수정하는 상황은 피해야 할 상황이다.
ISM은 앞선 사례들에서 나타난 장점들은 최대화시키고 단점들은 최소화시킬 수 있는 방향으로 통합을 제공한다. EAI/ESB 개발 툴에서 제공하는 인터페이스 기능은 그대로 제공하여 통합 업무 개발 과정에서 인터페이스 로직을 배제하며 쉽게 개발할 수 있는 환경을 동일하게 제공한다. 또한 운영 측면에서 필요로 하는 정보들을 사전에 정의하여 이미 제공함으로써 운영 관리를 지원하며 변화 관리 측면에서도 서비스에 미치는 영향을 최소화하여 관리의 부담을 줄여준다.
ISM이 제공하는 쉽게 개발하는 환경의 의미는 거의 개발하지 않도록 하겠다는 것을 의미한다. 거의 개발하지 않는다는 것은 프로그램 코드를 작성하지 않는다는 것이다. 사용자가 작업한 결과가 프로그램 코드로 생성되는 것이 아닌 정보로서 존재하도록 하여 물리적으로 프로세스에 영향을 미치지 않도록 하는 것이다. 이 환경이 갖는 의미는 통합을 위한 업무 요건이 프로그램으로 존재하는 것이 아니라 정보로 존재하도록 하여 구현된 업무 요건의 가시성을 높임과 동시에 업무 서비스의 구현을 특정 툴의 개발자만이 아닌 업무 담당자도 수행할 수 있도록 한다는 것이다.
사용자는 특정한 통합 요건이 발생하였을 때, 요건의 내용에 따라 통합 서비스를 정의하거나 변경하여 통합 서비스를 적용할 수 있다. 이 과정은 개발이 아닌 정보를 등록하는 과정이다. 사용자는 정보를 ISM 콘솔 화면을 통해 등록하게 되고 등록된 정보는 컴파일된 코드로 생성되는 것이 아니라 정보 그대로 존재하게 되어 등록된 정보의 적용 시 특정한 프로세스의 재시작 같은 과정이 필요없게 된다. 이로 인해 등록된 정보를 이용하여 ISM이 작동하는 원리나 프로세스의 처리 내용은 블랙박스에 남게 되지만, 어떤 데이터가 어떻게 처리되고 있는 지는 사용자가 화면을 통해 직관적으로 알 수 있음을 의미한다.
ISM은 통합 요건을 정보화함으로써 운영 관점에서 필요한 절차들을 정의하도록 한다. 또한 블랙박스에서 제공되는 처리 결과 데이터는 정상적인 수행 여부만이 아니라 어떤 데이터를 어떻게 처리했는 지, 데이터를 얼마나 처리했는 지 등을 알 수 있도록 해준다. 이를 통해 전체 서비스의 처리 현황에 대한 통합 뷰를 제공한다. 운영 중에 필요한 정보에 대한 요구가 발생할 경우, 뷰를 위한 프로그램을 개발하는 것이 아니라 제공되는 데이터를 화면에서 구성함으로써 정보를 생성하도록 한다.
통합 요건이 변경되었을 경우에도 프로그램의 변경이나 구성의 변경이 아니라 정보의 변경을 통해 처리하도록 하며 이 정보의 변경 이력을 관리함으로써 요건의 변경 이력/내역을 확인하도록 한다. 또한 특정 정보의 변경이 다른 서비스에 미치는 영향을 확인할 수 있도록 한다. 잘못된 정보 변경이 운영 중인 서비스에 영향을 미치지 않도록 하기 위해 정보를 이중으로 관리하여 필요한 시점에 정보가 운영 서비스에 적용되도록 한다. 변경된 정보의 적용 시점은 운영자의 판단에 따라 즉시 또는 지정된 시간으로 정할 수 있도록 하여 변화 관리를 편리하게 수행하도록 한다.