클라우드 애플리케이션 통합을 위한 4단계 접근법

클라우드를 둘러싼 IT 업체들의 주장은 가지각색이다. 하지만 이들 업체가 자사 제품이 어떻게 얼마나 클라우드를 기반으로 하는지 보여주려고 노력하는 와중에, 클라우드 애플리케이션이란 어떤 것인가에 나타내는 특성들은 오히려 모호해지고 있다.

따라서 여기서는 각 클라우드 공급업체들마다 달리 적용될 것이다. 그리고 이 기사의 목적을 위해, 비록 몇 가지 같은 원칙이 적용되더라도 스스로 구축한 것은 제외하고 공급업체나 SI가 제공하는 SaaS와 클라우드 기반의 애플리케이션에 대해 살펴볼 것이다.

인정하지 않는 사람도 있지만, 클라우드 소프트웨어의 특성 중 하나는 통합할 수 있는 방식의 다양성이다. 대다수의 클라우드 애플리케이션이 일련의 웹 서비스 형태로 제공되므로 비록 모든 SOA 프로토콜을 따르지는 않는다고 하더라도 서비스 지향적 구조로 대여된다.

사용자는 적절한 툴킷과 개발 방법을 통해 다양한 기법으로 클라우드 애플리케이션을 통합할 수 있으며, 심지어 같은 애플리케이션에서도 원하는 만큼 많은 애플리케이션을 동시에 사용할 수 있다. 물론 사용자는 각 접근 방식의 한계를 알아야 하지만 일을 빨리 처리한다고 해서 나쁠 것은 없다.

계층 1 : 화면 상의 통합

혼합 방식이라고도 하는 이 통합 형태는 신속함과 교활함의 극치다. 코딩하는 방식은 화면 배치를 위한 아이프레임(iFrames)과 다른 클라우드의 좋은 점을 가져오기 위한 다수의 매개변수를 가진 URL을 구축하는 것이다.

이는 구글이나 야후와 같이 공개적으로 이용 가능한 서비스에서 제공받을 수 있는 이미지, 지도, 뉴스 항목과 데이터를 끌어오기 위한 최소한의 절차다. 이 절차는 그래프 작성 패키지 및 기타 문서 서비스가 클라우드 서비스처럼 보편화됨에 따라 점점 강력해지고 있는데, 특히 시청용 견본에서 더욱 그렇다. AJAX는 그 페이지에 현대적이고 직관적이고 반응하는 UI를 제공할 수 있다.

불행히도 혼합 방식은 보안 방법에 있어서 본질적으로 많은 것을 제공하지 않으므로 SI는 예를 들어 민감한 데이터를 위해 정교한 코딩 기법과 서버측 평가를 살펴보아야 하며, 아마도 사용자를 짜증나게 하지 않으면서 액세스를 제어할 수 있는 SSO(Single Sign-On)나 다른 인증 인프라를 필요로 할 것이다. 그래서 이 계층에서 중요한 것은 단순하면서 읽기만 가능한 코드와 복잡하지만 안전한 코드 사이에서의 선택이다.

계층 2 : 표현 계층 통합

클라우드 애플리케이션이 웹 페이지를 생성하는 방식에 따라 클라우드 통합을 위해 풍부한 기반을 제공하는 서버측 프로그래밍 계층을 가질 수 있다. 반대로 매시업 전략은 브라우저 전체에 걸쳐 작동한다. 매시업 전략이 전략이 지도나 그래픽을 배치도에 추가하는 등 페이지의 전체 세그먼트를 함께 꿰어 맞추는 데 적합한 반면, 표현 계층 통합 방식은 페이지의 각 절에 개개의 필드를 추가하는 능력이 뛰어나다.

예를 들면 "기한 경과 일수에 따라 고객이 지불"한다는 표시를 CRM 계정 페이지의 요약 영역에 추가하는 데 적합하겠지만, 이 필드는 재무 회계 시스템에만 이용할 수 있을지도 모른다. 이를 표현 계층 방식에 도입하면 사용자가 참조할 필요가 있는 것을 제공하며, 대대적인 통합을 하는 것보다 빠르다.

물론 이 접근 방식의 장점은 단점이기도 하다. 그 지불기한 초과 표시기는 CRM 시스템 어디에도 저장되어 있지 않을 것이므로 보고서, 경보 또는 기타 기능을 지원하는 데 사용할 수 없을 것이다. 또한 표현 계층 방식이 시스템의 나머지 부분에서 이용할 수 있는 보안 인프라를 가지고 있지 않을 수 있으므로 보통 읽기 전용 데이터를 위해 사용된다. 이는 전적으로 사용하는 언어와 이용 가능한 웹 서비스 보안 라이브러리에 의존하지만, 표현 계층에 통합할 때 복잡한 보안 기능을 시도하는 것은 일반적으로 적절하지가 않다.

계층 3 : 업무 로직 통합

이는 애플리케이션의 맥락이 유지되는 곳이며 또한 최고의 보안과 웹 서비스 인프라를 이용할 수 있는 곳이기 때문에 대규모 통합이 이루어지는 곳이다. 정말로 클라우드 애플리케이션을 차별화하는 것은 API의 풍요함과 용이성이다. 이들이 WSDL/SOAP, RESTful API를 지원하는지, 아니면 XML, JSON과의 간단한 대화만 지원하는지 등이 중요해지는 것이다. 생산성을 높이는 데 있어서 정확한 문서화와 샘플 코드만큼 좋은 것이 없으므로, 이 기준에 따라 클라우드 공급업체를 평가한다.

대다수 클라우드 애플리케이션의 통합 아키텍처는 요청/응답 모델을 바탕으로 하며, 이들과 상당히 느슨하게 결합되어 있다. 빈번한 요청/응답은 그리 좋은 생각이 아니며, 2 페이즈 전용과 같은 단단한 통합 루프는 너무 엄격해진다. 클라우드가 메시지 전송을 지원해야 하는 상황이라면, 내부 개발자가 애플리케이션 내에 메시지 전송을 촉발하는 로직을 만들어야 한다. 또한 네트워크 시간종료, 애플리케이션 사용불능 시간과 메시지 전달을 보장하기 위해서는 어쩌면 전용 통합 서버를 사용해 관련 전략을 개발해야 한다.

이 계층에서 통합 코드가 모든 시스템 객체와 기능에 액세스하게 될 것이므로, 보안은 필수적이 될 것이다.

계층 4 : 데이터 통합

이는 직접 클라우드 애플리케이션의 데이터베이스를 처리한다. 많은 클라우드 시스템에서는 데이터 쓰기가 정말 안전하지 않기 때문에 이 단계에서 직접 액세스할 수 있는 실질적인 방법은 없다. 심지어 읽기 통합을 위해 데이터베이스에 직접 액세스하는 것도 문제의 소지가 있다. 이는 예를 들어 구내 데이터 저장소 또는 클라우드 기반의 분석 툴에 복제하기 위한 대규모 데이터 읽기에 있어서 직접 데이터베이스 액세스의 속도를 제어하는 것이 아무 것도 없다는 말이다.

이 계층에서는 애플리케이션의 보안 모델이 일람표에서 볼 수 있는 액세스 제어값을 초과하기 때문에 보안이 문제가 된다. 대개의 경우, 데이터 통합은 높은 사용자 권한에 의해 이뤄지므로 데이터 흐름을 유발하는 것은 표준 사용자들이 직접 액세스할 수 없어야 한다.

*David Taber는 "세일즈포스닷컴의 성공 비결 (Salesforce.com Secrets of Success)"의 저자이자, 세일즈로지스틱스(SalesLogistix)의 CEO다.

editor@idg.co.kr