퍼블릭 클라우드 간 마이그레이션(이전) 과정의 에러, 복잡성, 인력 부족 등의 문제점이 있긴 해도 IT기술에 의해 개발된 비즈니스 디바이스 중에서 멀티클라우드가 가장 이상적인 대안으로 자리잡고 있다. 지난해 가을 아마존이 대거 해킹당해 곤욕을 치른 사례에서 보듯, 이제 외부의 침투와 공격은 데이터센터 운영업체나 호스팅 제공업체의 가장 큰 골칫거리다. 이에 맞설 좋은 방법은 아예 외부 침입자에 의해 전체 네트워크가 다운되지 않도록 하는 복수의 제공업체가 운영하는 복수의 데이터센터, 즉 멀티클라우드다.

여러 클라우드 플랫폼 옮겨다니며 확장
간단히 말해 멀티클라우드의 무기는 여러 업체의 클라우드에 워크로드(작업 공정)를 배치하고, 배치할 수 있는 역량도 유지하는 것이다. 예를 들어 글로벌 기업의 클라우드 플랫폼인 아마존의 AWS와 마이크로소프트 애저, 구글 클라우드 플랫폼 등에 모두 공통의 소프트웨어를 유지하는 방식이다. 이를 위해 각각의 여러 데이터센터에 걸쳐 확장이 가능한 데이터 아키텍처도 필요하다. 말하자면 클라우드 플랫폼을 옮겨 다니면서, 시공간의 제약없이 비즈니스를 수행할 수 있는 것이다.
만약 그렇지 않고 단일 클라우드, 즉 단일 업체의 클라우드에 의존할 경우도 해당 클라우드 서비스 업체가 제공하는 소프트웨어를 이용할 수 있다. 이는 멀티클라우드보다는 가격이 저렴한게 보통이다. 예를 들어 AWS 이용자라면, 자신만의 검색 클러스터를 구축하는 대신 아마존 일래스틱서치 서비스(Amazon Elasticsearch Service)를 사용하면 된다. 구글 고객이라면 문서 데이터베이스를 직접 운영할 필요 없이 구글 문서 데이터베이스인 구글 클라우드 데이터스토어(Google Cloud Datastore)를 사용하면 된다.

단일 클라우드, ‘서비스업체에 종속’ 우려도
그러나 멀티클라우드에 비해 이같은 단일한 플랫폼은 위험 부담이나 치러야 할 기회비용이 더 크다. 해당 클라우드 서비스 업체가 지금 당장은 가격이 저렴하겠지만, 향후 어떻게 변할지 모른다. 또 클라우드 업체가 전략을 변경하면 갑자기 소프트웨어나 데이터가 사라질 염려도 있다. AWS 데이터센터가 장시간 다운되거나 속도가 느려지거나 불안정하게 되는 경우도 생각할 수 있다. 특히 해당 클라우드 서비스 업체가 배포(릴리스)하는 소프트웨어에서 보안상의 결함이라도  발견되어, 이를 교체하는 경우 클라우드 서비스 업체의 절차나 일정에 따를 수 밖에 없다. 그야말로 클라우드 서비스 업체에 종속되어 제약을 받을 수 밖에 없게 된다. 이는 대기업이라고 해도 예외가 아니다.

단일 클라우드 서비스 ‘싼게 비지떡?’
결국 개별 혹은 단일 클라우드 서비스 업체의 전용 소프트웨어는 고객으로선 여러 가지로 단점이 장점보다 많다. 그다지 비싸지 않은 듯한 가격 정책을 구사하며, 고객을 자신들의  플랫폼을 떠나지 않도록 하고, 오래도록 컴퓨팅 비용을 지불하게 한다.
무엇보다 개별 클라우드 서비스 업체의 가장 큰 문제는 역시 보안과 불안정한 시스템이다. 만약 사로라도 생기면 고객인 기업이나 개인은 미리 다른 곳에 코드를 예비로 갖춰두지 않았다면, 속수무책일 수 밖에 없다. 그런 식으로 해당 클라우드 서비스 업체에 묶여있고 쉽사리 떠날 수 없는 상황에선 결국 가격 협상 측면에서도 불리하다.
물론 전문가들은 멀티클라우드 역시 완전무결한 것은 아니며, 업체 중립성이나 탄력적인 아키텍처가 전제 조건임을 강조한다. 처음에는 여러 클라우드 서비스 업체와 협상해야 하고, 기술 간 통합 지점을 모색한 후, 통합 지점의 보안도 유지해야 하는 등 ‘복잡성’이 매우 높다. 그럼에도 불구하고, 멀티클라우드는 단일 서비스 업체를 사용할 때에 비해 고객으로서 더 많은 선택의 기회와 보안을 보장한다. 예를 들어 서비스 업체가 불안정한 파트너로 판단되거나, 서비스 가격을 지나치게 올리는 경우 해당 클라우드를 떠나버리면 된다.
다만 멀티클라우드를 안정적으로 활용하기 위해선 쿠버네티스나 오프소스, 혹은 개방형 표준 등 공개 표준과 산업 표준이 중요하다. 오픈소스 컨테이너 관리 플랫폼, 즉 컨테이너화된 애플리케이션을 관리하는 쿠버네티스는 현재 클라우드 서비스 업계의 표준이다. 노트북에서 실행되는 표준 쿠버네티스 배포 기준을 여러 클라우드 서비스 업체에서 실행할 수 있다. 개방형 표준 역시 중요하다. 즉, 다른 소프트웨어와의 모든 접점이 개방적이며 업체 중립적인 산업 표준을 따라야 하는 것이다.

마이그레이션, 복잡성 등 과제도
그럼에도 아직 기업이나 비즈니스 현장에서 클라우드 컴퓨팅은 복잡하고 어렵다는 인식이 적지않다. 특히 많은 사용자들이 클라우드 마이그레이션이 지연되거나 중단되어 불편하고 어렵게 느끼기도 한다. 
그러나 이는 어쩌면 소프트웨어의 문제라기보단 사용자의 에러라고 할 수도 있다는 지적이다. 퍼블릭 클라우드 간의 이전을 위해 별 생각없이 아무런 수정없이 그저 데이터를 들어 옮기는 ‘리프트 앤 시프트(Lift and shift)’ 방식의 마이그레이션이 문제다. 흔히 많은 사용자들은 시간과 비용을 줄이기 위해 이런 방식으로 클라우드 이전을 한다. 여기서 문제가 발생한다.
이 경우 클라우드에 최적화된 구조를 갖추고, 퍼블릭 클라우드 호스트를 제대로 이용하기 위해선 애플리케이션을 다시 리팩토링해야 하므로, 결국 마이그레이션을 두 번 하게 되는 셈이다. 그 만큼 시간과 비용이 더 소요되는 것이다. 사실상 쉽고 간편한 마이그레이션은 거의 드물다는게 전문가들의 지적이다.
또 클라우드의 ‘복잡성’에 제대로 적응하지 못한 클라우드 운영자들로 인해 운영 중단이나 데이터 유출 등의 사고가 생길 수도 있다. 그럼에도 불구하고 전문가들은 “실용적이고 기본적인 멀티클라우드 기술 활용은 되돌릴 수 없는 추세”라며 “다만 실용적인 보급을 위해서는 더욱 치밀한 기술 보정과 빈틈없는 배치 계획, 그리고 서비스 질을 높이기 위한 클라우드 벤더들의 노력이 중요하다”고 강조한다.