웹 2.0 기술은 굉장한 약속을 하고 있지만 아직 성숙하지 못했으며, 모니터링, 관리, 보안 및 네트워크 부하 측면에서 틀림없이 인프라를 대폭 바꿔 놓을 것이다. 이번 호에는 웹 2.0 시장의 현재 상황과 앞으로의 전진을 위해 어떠한 조건들이 필요한지 살펴봤다.
웹 2.0을 채택한 회사들 가운데 위태롭게 살고 있다고 생각하는 곳은 몇 되지 않을 것이다. 실제로 에이잭스(에이잭스), 매시업(mashups) 및 REST(Representational State Transfer) 등은 인터넷 분야에 처음 등장했으며, 인터넷은 적자생존의 고장이자 신기술들이 주목을 끌기 위한 투쟁의 무대이기도 하다. 보안과 같은 멋진 것들은 아마도 나중에야 생각하게 될 것이다.
웹 2.0과 RIA(Rich Internet Applications)는 모니터링, 관리, 배치 및 가용성 면에서 인프라를 급격히 바꿔놓을 것이다. 네트워크와 백엔드 서버 둘 다에 놓이는 부하는 심각해질 수도 있다. 보안은 사후에 떠올리는 경우가 너무 많으며, IT의 안전망 ‘표준과 상호운용성 테스팅’ 두 가지는 찾아보기 힘들다. 또한 웹 사이트 이용량을 기존의 방식으로는 분석할 수 없다는 사실을 깨닫게 될 것이다.
하지만 이런 어떤 요소들도 배치를 막지는 못하는 것 같다. 2006 봄 에반스 데이터의 웹 서비스 개발 설문조사에 응답한 개발자의 절반 가까이가 이미 웹 아키텍처의 핵심 컴포넌트인 에이잭스로 작업 중이거나, 곧 그렇게 할 계획이라고 답했다. 간단한 URI 기반 서비스 아키텍처 모델인 REST를 이용하는 사람들도 또한 늘어나고 있다. 에반스 설문조사에서는 REST를 이행하고 있거나 고려 중이라는 사람이 37%가 늘어난 것으로 집계됐으며, 네명 중 한 명이 REST 기반 서비스를 SOAP 기반 서비스의 보다 간편한 대안으로 생각하고 있었다.
웹 2.0 기술은 SOAP(Simple Object Access Protocol)와 SOA 인프라의 이점을 가져올 수 있긴 하지만 대부분은 그렇게 하지 않는다. 그 이유는 이 길을 밝혔던 개발자들은 스스로를 관리, 보안, 확장성, 혹은 지원 같은 세세한 것들과 연관짓고 싶어하지 않기 때문이다.
에이잭스 Vs SOAP
SOAP는 지난 몇 년간 엔터프라이즈에서 서비스를 이행하는 데 쓰이는 주 메커니즘이었다. 이는 제대로 이해됐으며, 확장성 있고 관리성이 뛰어나며 안전한 SOAP 기반 애플리케이션을 보장해 주는 수많은 제품들이 나와 있다.
현재로서는 이들 중 어떤 것도 에이잭스, 매시업 및 REST중 해당 사항이 없으며, 이로 인해 업체들(과 현명한 IT 그룹)은 불안해 하고 있다. 우리는 이것이 바로 오픈에이잭스 얼라이언스(Open에이잭스 Alliance) 같은 업계 이니셔티브 배후의 힘이라고 생각한다. 오픈에이잭스 어도비, BEA시스템즈, IBM 및 썬 등 선도적인 ISV들이 포함된 컨소시엄으로서 상호운용성 확보에 전념하고 있다.
불행히도 SOAP와 WSDL(Web Servies Description Language) 이외의 다른 표준은 없으며, 이들 업체들은 새로운 2.0 제품에서 이 표준들을 기반으로 할 수 있다. 그리고 오아시스(OASIS)나 W3C 같은 표준화 집단은 아직 책임을 떠맡을 준비가 되지 않았다. 모두 함께 모아서 사용자를 위한 킬러 매시업을 만드는 데 있어서는 아직 많은 수동 코딩 작업이 필요하다.
제대로만 된다면 리치 정보인 웹 2.0 애플리케이션이 엔드유저의 생산성을 향상시켜줄 수 있다는 데는 누구도 반박의 여지가 없다. 하지만 이들의 이점을 완전히 확보하기 위해서는 서비스가 존재해야 하며, 이는 곧 IT에서 확장성 있는 서비스 지향형 인프라를 만들고, 이행하고, 배치하고, 관리하고, 보안하는 많은 일을 해야 한다는 것을 의미한다.
드래그 앤 드롭 패러다임을 이용해 인터페이스를 구축한다는 것은 아직은 꿈이며, 언제나처럼 그리 유쾌한 일도 아니다.
이제 매시업으로 들어가 보자. 얼리 어댑터들에게는 지금까지 사용할 수 있는 툴이 아주 적었다. IBM이 지난 6월 발표한 엔터프라이즈 매시업툴로 이 분야에서 선두를 서고 있으며, BEA가 일련의 새로운 웹 2.0 툴들(매시업에 초점이 맞춰진 소프트웨어 인프라)로 바짝 뒤따르고 있다. 이는 2007년 세상에 선보일 예정이다.
신기술을 둘러싼 흥분이 가라앉을 때 즈음이면 업체들이 지원 제품을 쏟아내 놓고 싶은 유혹을 참기 힘들어질 수 있다. 인상적인 이름을 가진 IBM의 “엔터프라이즈 매시업 시스템”은 이제 초기 채택 단계에 있으며, 이클립스(Eclipse) 개발 툴을 이용해 에이잭스는 기반 인터페이스를 구축하는 데 대한 지원으로 정리되고 있다. 불행히도 에이잭스는 아직 기업에서 프라임 타임용으로 사용될 준비가 되지 않았다.
물론 우리가 했던 말들을 들었을 것이다. 에이잭스는 멋진 기술이며, 분명히 예전에 씬 클라이언트에서 가능했던 것보다 더욱 폭넓은 기능성의 세계를 향해 브라우저를 열어 준다. 그리고 오픈에이잭스 동맹은 하나의 진술형 마크업 언어를 정의하는 방향으로 가고 있는데, 이렇게 되면 결국 개발자용의 표준 형태의 API를 제공하게 될 것이다.
이는 곧 바로 지금이 에이잭스 API와 이행에 있어 오픈 시즌이라는 얘기다. IT에서는 하나의 에이잭스 툴킷에서 다른 것으로 마이그레이팅하기가 거의 불가능하다는 것을 깨닫고 있으며, 상호운용성에 대해서는 사실상 들리는 바가 없다.
나아가 문제를 더욱 복잡하게 하는 것은 에이잭스가 엔터프라이즈 인프라의 네트워크와 서버 쪽에 미치는 영향을 감안하는 조직이 거의 없다는 것이다. 제대로 튜닝되지 못한 웹 서버는 에이잭스 지원 사용자가 조금만 있어도 항복해버릴 것이다. 수백 명이 된다면 시스템이 고장날 수 있다. 아무리 잘 봐준다고 하더라도 에이잭스는 일단 기간 시스템이 필요로 하는 귀중한 서버와 네트워크 자원을 잡아 먹는다.
데스크톱 시스템은 엔터프라이즈에서 가장 나중에 업그레이드되는 경우가 많으며, 이러한 현실은 에이잭스 기반 애플리케이션을 이용해 전진하고자 하는 의도에 정확히 위배된다. 매시업과 기타 정보 집합 기술이 정보를 보여주는 데 필요한 페이지 수를 줄임으로써 직원의 생산성을 높여주는 것은 확실하지만, 이 한 페이지에서의 로딩 시간이 몇 개의 개별 페이지를 로드하는 것보다 더 오래 걸린다면 얻는 게 하나도 없다.
최소한 얼마간의 표준 마크업 언어가 있을 때까지, 그리고 네트워크와 서버 자원에 미치는 리치 인터페이스의 영향이 보다 잘 이해될 때까지는 에이잭스 얼리 어댑터들은 인프라의 운영적 안녕을 두고 모험을 해야 하는 입장이다. 조심하라. 면밀히 관리할 수 있는 몇 가지 파일로트를 이행하는 것만이 인프라와 데스크톱이 부하를 처리할 수 있는지, 혹은 업그레이드가 필요한지를 파악할 수 있는 유일한 길이다.
보안 취약성
본지에서 최근 실시한 SOA 독자 설문조사에서 절반 이상의 응답자가 아직 포괄적인 보안을 이행하지 못하고 있다고 답했다. 그리고 웹 서비스 인프라를 보호할 수 있는 전략을 무엇이든 전혀 갖고 있지 못한 응답자는 놀랍게도 33%에 달했다.
이러한 사실을 바탕으로 할 때 웹 2.0 애플리케이션을 잠그려 시도하는 사람들에게 행운이 깃들기를 바랄 뿐이다. 에이잭스와 REST는 보다 빠듯하게 정의된 SOAP에 비해 트래픽 위반에 대해 더 높은 필요조건을 갖고 있다. SOAP는 잘 정의된 XML 스키마와 WSDL 기반의 계약에 의해 제한이 된다. 브라우저와 서버를 오가는 에이잭스 데이터는 스키마에 의해 미리 정의되는 경우가 거의 없으며, 도조 파운데이션(Dojo Foundation) 같은 툴킷을 이용해 개발이 이뤄지는 경우에도 IT에게는 이런 포맷에 대한 제어권조차 없다.
또한 클라이언트와 서버 모두의 안전을 위해 데이터를 보안하고 검증도 해야 한다. 네트워크에 있는 부하를 파악하기 위해 트래픽을 모니터링하고 관리해야 하며, 일단 웹 2.0 기술이 배치가 되면 이 네트워크는 타격을 받게 될 것이다. 대역폭 이용량이 늘어나지 않는다 하더라도 웹과 애플리케이션 서버가 이것을 지원하는 데 필요로 하는 요청 수가 올라갈 것이기 때문이다. 그리고 이러한 부하는 캐스케이딩이 돼 데이터 센터 안에 있는 거의 모든 웹 애플리케이션 인프라 조각에 부담을 추가시킬 것이다.
포럼시스템즈(Forum Systems), IBM-데이터파워(DataPower), 레이어7테크놀로지즈 및 리액티비티(Reactivity)에 의해 제공되는 SOA 보안 게이트웨이는 오랫동안 SOAP 보안을 책임져 왔지만, 일반적인 에이잭스 및 REST 트래픽을 아웃 오브 더 박스로 처리하는 데는 익숙치가 못하다.
문제는 이들이 업계 표준인 WS-시큐리티를 사용해 웹 2.0 애플리케이션을 잠글 수가 없다는 것인데, 그 이유는 에이잭스든 REST든 기본적으로는 SOAP를 이해하지 못하기 때문이다. 이것은 WS-시큐리티에서 필요조건이다.
다행히도 SOA 보안 게이트웨이는 대부분 어떠한 XML 기반 데이터든 보호할 수 있으며, SQL 투입 및 쿠키 포이즈닝 같은 악성 공격이 에이잭스 요청에 투입되지 못하게 막아줄 것이다. 스키마가 존재할 경우 대부분은 에이잭스를 검증할 수 있으며, 최소한 데이터가 제대로 구성됐다는 사실을 확인해 준다. 이 시장에 나와 있는 대부분의 제품은 XPath를 이용해 XML 메시지로부터 증명서를 추출해 낼 수 있는 능력이 있지만, 이 옵션은 계약서에 서명을 하기 전에 업체측에 확인해 보아야 한다.
XML 트래픽에 투입되는 공격에 보다 덜 비싼 보호를 할 수 있는 소스로 포럼시스템즈의 엑스월(XWall)이나 리액티비티의 XML 파이어월 같은 스탠드얼론 XML 방화벽이 있다. XML 방화벽은 큰 SOA 이니셔티브를 생각하고 있지 않더라도 이행돼야만 하는 SOA 보안 게이트웨이의 한 컴포넌트다.
