여전히 비현실적인 클라우드 앱의 이동성과 기본 대응 방안

클라우드 이동성은 한때 디지털 인프라 환경에서 획기적인 발전처럼 보였다. 2006년 아마존 S3와 유사한 서비스가 출시되면서 초기에는 기대감이 높았다. 서비스 업체들은 여러 서비스 업체 간에 워크로드를 원활하게 마이그레이션할 수 있는 기능을 약속했다. 이들 서비스는 기업이 더 나은 가격이나 향상된 기능을 제공하는 서비스 업체로 쉽게 전환할 수 있는 미래를 제시했다.
 

ⓒ Getty Images Bank

하지만 초기의 이런 기대감과는 달리 클라우드의 이동성은 구현하기 어렵고 비용이 많이 든다는 것이 입증됐다. 필자는 2017년에도 클라우드 애플리케이션 이동성은 SF 소설이라고 지적한 바 있다. 오늘날에도 같은 이유로 클라우드 애플리케이션의 이동성은 여전히 복잡하고 비용이 많이 든다. 물론 돈이 모든 문제의 해결책이라고 인정하고 막대한 비용을 지출할 준비가 되어 있다면, IT에서는 무엇이든 가능하다. 하지만 돈이 화수분처럼 솟아나는 기업은 없으며, 문제의 핵심은 클라우드 간 애플리케이션 이동성에 많은 사람이 예상했던 것보다 훨씬 더 많은 작업이 필요하다는 것이다.
 

쉽거나 저렴하지 않은 클라우드 이동성

근본적인 문제는 클라우드 환경 간의 내재적인 차이에 있다. 각 클라우드 서비스 업체는 고유한 API, 프로토콜, 기능으로 운영되기 때문에 플랫폼 간 마이그레이션에는 상당한 기술적 장벽이 존재한다. 이로 인해 클라우드 서비스는 기존 IT 서비스처럼 조달 및 관리되는 또 다른 엔터프라이즈 솔루션 업체 옵션이 됐다. 옴디아(Omdia)의 수석 애널리스트 로이 일슬리는 클라우드와 온프레미스 환경 모두 워크로드를 새로운 플랫폼에 맞게 조정하려면 서로 다른 수준의 수정 작업이 필요하다고 지적한다. 이런 작업은 운영체제 및 프로그래밍 언어에 따라 약간의 조정부터 애플리케이션 코드의 거의 완전한 재작성까지 다양하다. 이 당연한 이야기가 클라우드로 마이그레이션하는 많은 기업에 놀라운 소식이었다.

가상머신 내에서 실행되는 애플리케이션을 이전하는 것은 관리하기 쉬워 보일 수 있지만, 확장의 유연성을 비롯한 클라우드의 일부 장점이 줄어든다. 클라우드 환경을 위해 특별히 설계된 클라우드 네이티브 애플리케이션의 경우에도 현실은 비슷하게 복잡하다. 쿠버네티스는 크고 작은 클라우드 서비스 업체에서 사용하는 표준 프레임워크이지만, 쿠버네티스를 기반으로 구축된 애플리케이션을 업체 간에 이동하려면 구성의 차이와 추가 플러그인을 해결해야 하는 경우가 많다.

컨테이너와 쿠버네티스를 홍보하는 사람들이 말하는 것처럼 결코 쉬운 일은 아니다. 필자도 여러 컨테이너 기반 개발 프로젝트에 참여했는데, IT 책임자가 이 명백한 사실을 이해하지 못해 프로젝트가 궤도에서 벗어난 적이 있다.
 

이동성을 고려해야 할 가치

일부 전문가들은 여전히 클라우드의 전략적 이점 때문에 클라우드 이동성을 추구해야 한다고 주장한다. 가트너 리서치의 시드 나그에 따르면, 어느 정도 이동성을 확보하면 업체 종속 위험을 완화할 수 있다고 한다. 계약 갱신 시 협상력으로 활용하고 단일 공급업체에 대한 과도한 의존으로 인한 잠재적 문제로부터 보호함으로써 더 나은 결과를 얻을 수 있다.

이동성을 확보하려면 애플리케이션을 특정 클라우드 서비스에 종속시키는 종속성을 최소화하기 위한 신중한 계획과 아키텍처 측면의 선견지명이 필요하다. 이는 일반적으로 최소 공통 분모 접근 방식을 취하는 것을 의미한다. 즉, 모든 곳에서 실행되는 것은 어디에서도 제대로 실행되지 않는 것이다. 더구나 성능 및 최적화 문제가 흔히 발생하기 때문에 이런 이동성 뛰어난 애플리케이션을 클라우드에서 실행하면, 비용이 너무 많이 들기도 한다.

공식적인 클라우드 표준이 없기 때문에 다양한 환경에서 호환성과 기능을 보장해야 하는 기업의 책임이 두드러진다. 업체별 서비스는 개발자가 AWS나 애저와 같은 고유한 생태계에 최적화된 애플리케이션을 구축하도록 유도하는 경우가 많다. 데이터 마이그레이션은 또 다른 복잡성을 추가한다. 데이터 이동에는 애플리케이션과 함께 데이터를 이동해야 하는 경우가 많으며, 이는 기술적으로 까다롭고 비용이 많이 들 수 있다.

이쯤 되면, 좋은 소식은 없는지 물어보고 싶어질 것이다.
 

기업이 할 수 있는 것

기업에는 클라우드 애플리케이션 이동성의 어려움과 관련된 비용을 최소화하기 위한 몇 가지 선택지가 있다.

여러 클라우드 서비스 업체에 걸쳐 애플리케이션을 배포한다. 기업은 여러 클라우드 서비스 업체에 애플리케이션을 배포해 위험을 분산하고 단일 업체에 대한 의존도를 줄일 수 있다. 이 전략은 계약 조건을 협상하거나 서비스를 마이그레이션할 때에도 유리하다. 업체 종속을 방지하고 여러 업체에서 제공하는 가장 비용 효율적인 서비스를 활용해 비용을 최적화할 수 있는 유연성을 제공할 수 있다.

하지만 멀티클라우드가 이동성 문제의 해답이라고 생각한다면 오산이다. 특정 클라우드 서비스 업체에 맞게 애플리케이션을 최적화하려면 네이티브 기능에 애플리케이션을 연결해야 한다. 앞서 말했듯이 이동성이 떨어지면 좋은 선택지가 없다. '여러 업체' 접근 방식은 부정적인 영향을 최소화할 수 있지만 이동성 문제를 해결하지는 못한다.

이동성을 염두에 두고 애플리케이션을 구축한다. 이 접근 방식에는 도커와 같은 컨테이너화 기술과 쿠버네티스와 같은 오케스트레이션 플랫폼이 포함된다. 기본 인프라에서 애플리케이션을 추상화하면 여러 환경과 호환성을 보장할 수 있다. 또한 독점 서비스를 피하고 오픈소스 도구를 선택하면 이동성이 향상되고 재구성 또는 마이그레이션과 관련된 비용을 줄일 수 있다. 다시 말하지만, 대부분 기업은 컨테이너를 효율적으로 실행하고 비즈니스 요구 사항을 충족하는 데 필요한 기본 서비스를 사용하지 않을 수 없다.

효과적인 데이터 관리를 통해 전환 비용을 최소화한다. 기업은 클라우드 간에 쉽게 이동할 수 있도록 데이터를 구조화하는 동시에 데이터 송신 수수료도 염두에 둬야 한다. 하이브리드 클라우드 또는 클라우드 간 전송 솔루션을 사용하면 원활한 데이터 액세스를 유지하고 관련 비용을 절감할 수 있다. 기업은 이동성을 염두에 두고 데이터 아키텍처를 계획하면 비용이 많이 들고 복잡한 데이터 마이그레이션 프로세스를 피할 수 있다.

필자가 자주 하는 한 가지 조언이 있다. 애플리케이션을 구축할 때 클라우드 애플리케이션 이동성을 고려하지 말자. 이는 비용과 위험만 가중시킬 뿐이며, 대부분 애플리케이션은 초기 클라우드 플랫폼에서 이동하지 않을 것이다.

기업이 공급업체가 폐업하거나 불안정해지거나 가격을 인상할 경우 이전할 수 있기를 원한다는 이야기를 자주 듣는다. 이는 타당한 위험이지만 가능성은 작다. 충분한 비용만 있다면 모든 애플리케이션을 이전할 수 있다. 이전으로 인한 위험 비용은 클라우드 애플리케이션 이동성을 처리하는 것보다 훨씬 적다는 것을 알게 될 것이다.
editor@itworld.co.kr