조직에서 ‘실시간 기업(real-time enterprise)’이 되려 할 때는 몸을 빨리 놀릴 필요가 있다. 즉 의사결정은 몇 시간이 아닌 몇 분 내에 이루어져야 한다. 소프트웨어 업체들은 실시간 데이터를 수집 및 분석할 수 있는 기술적 수단을 제공할 수 있으며, 이 데이터를 통합시키고 응집력 있게 이용하여 애플리케이션 인프라의 보안을 감시하는 것은 당신의 책임이다.
웹서비스
이미 우리가 예언했던 것처럼 웹서비스는 ERP(Enterprise Resource Planning)와 CRM(Customer Relationship Management)과 같은 대형 애플리케이션에서 기업으로 파고들었다. 웹서비스 이행은 주로 개발자가 데이터에 액세스하기 위해 맞춤 코드를 만들거나 전용 ‘어댑터’를 설치할 필요 없이 애플리케이션에서 기간 업무 데이터로의 액세스를 제공한다. ISV는 2003년에 분명히 발생할 폭발에 대비해 자신들의 애플리케이션에 이 기술을 통합시키기 시작했다.
웹서비스 기술은 다른 웹서비스 지원 비즈니스 애플리케이션에서 데이터로의 액세스를 허용하는 특정 비즈니스 기능을 개방형 표준을 통해 노출시킨 것이다. 과거에는 애플리케이션에서 데이터로 액세스하려면 보통 맞춤 코드를 개발해서 애플리케이션에 맞는 프로토콜을 지정해야 했다. 웹서비스에서는 XML(Extensible Markup Language)을 이용해 애플리케이션으로 데이터를 송수신하는 SOAP(Simple Object Access Protocol)라는 정의된 개방 프로토콜을 통해 같은 방식의 데이터 액세스가 제공된다.
이러한 변화는 곧 애플리케이션에 비즈니스 기능으로의 액세스가 플랫폼과 언어에 구속을 받지 않는다는 것을 의미한다. SDK는 언어와 플랫폼 전용이지만, 웹서비스는 진정한 유비쿼터스(ubiquitous) 액세스를 제공한다. 기술은 CORBA의 보다 개방적이고 합리적으로 부활된 CORBA다. 웹서비스는 긴 개발 사이클 문제를 치유해주는 만병 통치약으로 인식되고 있지만, 웹서비스가 객체 지향형 패러다임으로의 이동이 했던 것 이상으로 코드의 재사용을 장려하게 될 것 같지는 않은데 그 이유는 신뢰와 커뮤니케이션이라는 두 가지 요소 때문이다.
코더들은 자신의 코드만을 신뢰하며 설령 사용할 수 있다는 사실을 알게 되더라도 기존의 코드를 다시 사용하려 하지 않는 경향이 있다. 이보다 더 큰 문제는 개발팀들간의 커뮤니케이션인데, 이런 팀들은 한 가지 구성요소의 영향에 대해 다른 팀과 의논하는 경우가 드물다. 결국 그 구성요소 즉 웹서비스는 모든 팀의 필요를 충족시키기 힘들기 때문에 완전히 다시 써야하는 경우가 많다.
웹서비스는 패키지드 애플리케이션에 있어서 훨씬 더 많은 것을 제공하는데, 그 이유는 이 개방형 인터페이스가 통합용 메커니즘을 제공하며, 코딩이나 별도 어댑터 구매를 통한 맞춤화가 필요 없는 아웃 오브 더 박스를 지원하기 때문이다.
불행히도 웹서비스는 여전히 보안이나 신뢰성 문제를 그리 잘 해결해주지 못한다. 웹서비스는 J2EE(Java 2 플랫폼, 엔터프라이즈 에디션) 기반이든 마이크로소프트 닷넷 기반이든 모두 XML의 혜택을 받으며, 이것은 SOAP를 통해 애플리케이션들간에 전달된다. 웹서비스가 노출되고 액세스되는 방식을 설명해 놓은 SOAP 표준은 매우 장황하다. 인프라에서 웹서비스 지원 애플리케이션의 수가 증가함에 따라, 수용 가능한 성능을 유지하기 위해 그 어느 때보다도 자원들이 더 열심히 일해주기를 바랄 것이다. 표준은 보안이나 신뢰성을 해결해주지 못하기 때문에 비즈니스 기능의 노출은 ‘전부 또는 전혀 없음(all-or-nothing)’이 된다.
웹서비스 보안 시장 형성
선두 주자를 호명하기에는 아직 너무 새로운 분야이긴 하지만 웹서비스 보안 부문에서 시장이 형성되고 있으며, 보안과 신뢰성 문제의 해결을 위한 솔루션들이 올해 상당수 나올 전망이다. 케이프 클리어 소프트웨어(Cape Clear Software), 블루 타이탄 소프트웨어(Blue Titan Software), 액셔널(Actional), 그리고 심지어 체크포인트 소프트웨어 테크놀로지즈(Check Point Software Technologies)까지도 웹서비스 보안 및 관리를 지원하는 제품을 제공하고 있으며, 향후 몇 개월 사이에 더 많은 제품들이 나올 예정이다.
또한 앞으로, 그것도 조만간에 플랫폼에 대해 단호한 결정을 내려야 할 때가 올 것이다. 닷넷을 사용할 것인가, 아니면 썬 마이크로시스템즈의 썬원(SUNONE)과 같이 많은 J2EE 제품들 가운데 하나를 사용할 것인가. 개발자들이 포함되는 어떠한 선택에서나 마찬가지지만 만만치 않은 전쟁의 기류가 벌써 불어닥치고 있다.
J2EE 제품에는 물론 많은 이점이 있다. 많은 업체들이 제품을 보유하고 있으며, 나와 있는 툴들도 다양하다. 닷넷 환경은 한 업체에게 구속되어야 하며 업체와 플랫폼 지원에 있어서 선택을 극도로 제한하지만, 그 개발 환경과 언어는 대다수 개발자들에게 친숙하기 때문에 교육과 배치 시간 면에서 매력적이다. J2EE 기반 솔루션이 마이크로소프트 제품이 제공하는 개발 및 배치의 편이와 경쟁하기도 또한 힘든 일이다.
웹서비스와 같은 외부의 소프트웨어 구성요소들은 그리 빠른 시간 안에 내부 개발 작업에 통합되기 힘들지만, 인트라넷 포털을 위한 웹서비스의 내부적 사용과 통합 작업은 수용 가능할 뿐만 아니라 기대되는 수준이다. 그리고 아키텍처의 일부로 웹서비스를 심각하게 생각해보지 않았다면 올해는, 특히 새로운 애플리케이션용으로 그렇게 해볼 필요가 있을 것이다.
주장했던 만큼의 ROI를 달성하지 못한 CRM 개발의 실패와 함께 웹서비스는 CRM 아웃소싱 시장을 촉진시키고 있다. 세일즈포스닷컴(Salesforce.com)이나 업샷(UpSot)과 같은 ASP 기반 CRM 제품들은 보다 강력한 기능과 사양을 제공하기 위해 웹서비스를 이용해 마이크로소프트 아웃룩에 자신들의 아웃소스드 CRM 애플리케이션을 통합시키고 있다. 지난해 CRM 붕괴를 감안할 때, 아웃소스드 솔루션을 고려하는 게 현명해 보인다. 웹서비스는 기능성을 희생하지 않으면서 요구되는 보다 낮은 총 소유비용을 제공하기 위해 이런 솔루션을 지원해 왔다.
엔터프라이즈 애플리케이션 통합
기업에서 통합 작업은 언제나 중요한 문제이며, 이것은 올해도 변하지 않을 것이다. 대다수 애플리케이션은 서로 다른 시스템들이 소통하도록, 혹은 데이터를 공유하도록 해주는 기술을 필요로 한다. 웹서비스를 이행함으로써 통합에 소모되는 시간을 대폭 줄일 수 있지만, 이런 새로운 제품들은 업그레이드를 필요로 하며, 인프라 변경을 요하는 경우가 많다.
올해 업그레이드용 시장에 있을 게 아니라면 아마도 지난해와 마찬가지로 애플리케이션을 통합하느라 많은 시간을 보내게 될 것이다. 그 시간의 일부는 통합 솔루션 코딩에 쓰여지겠지만 더 많은 시간이 아마도 데이터 정션(Data Junction)이나 아이비엠, 팁코 소프트웨어(Tibco Software), 혹은 웹메소드(WebMethods) 제품들 같이 통합 작업을 도울 수 있는 솔루션에 사용될 것이다. 이미 통합 작업을 고려하고 있지 않다면, 의사결정 프로세스 구조를 바꾸는 데 대해 생각해 보라. 즉 통합 작업을 지원할 수 있는 솔루션을 설계하는 데 더 많은 시간을 보내도록 하라. 일단 이행한 후에 끼워 넣으려면 서로 다른 애플리케이션들간에 데이터를 공유할 수 있는 솔루션을 만드는 것보다 더 많은 돈과 시간이 필요하다.
통합을 위한 하나의 수단으로 웹서비스를 도입한다는 것은 즉 보다 적은 전문가 서비스 시간을 의미하지만, EAI(Enterprise Application Integration)는 단순히 두 개의 애플리케이션이 잘 돌아가게 하는 일 이상이 된다. 이런 애플리케이션은 데이터를 공유해야 하며, 기업 대 기업 파트너들간의 번역 작업도 필요하다.
웹서비스는 이 일을 보다 간단하게 해주지만 여전히 데이터를 라우팅하기 위한 솔루션을 필요로 하며, 그 솔루션이 바로 EAI다. 예를 들어 고객의 주문을 두 개 이상의 애플리케이션들(주문 처리와 CRM)로 라우팅해야 할 수 있으며, EAI는 양쪽 시스템 모두 데이터를 가질 수 있는 수단을 제공한다. 혹은 비즈니스 파트너들간에 데이터를 교환해야 하는 경우를 생각해 보라. XML은 표준을 제공하긴 하지만, 포맷을 규정하지는 않는다. EAI 솔루션은 한 쪽 포맷에서 다른 쪽 포맷으로 번역해줄 수 있다.
