Offcanvas

디지털 트랜스포메이션 / 클라우드

'멀티클라우드'의 11가지 그늘

2021.05.07 Peter Wayner  |  CIO
다양한 환경에서 ‘멀티클라우드(Multicluoud)’ 아키텍처는 적절한 선택지가 될 수 있다. 하지만 멀티클라우드를 실전에 적용해 민첩성을 확보하고 락인(lock-in)을 피하다 보면 숨겨진 비용과 문제에 직면할 수도 있다. 
 
ⓒGetty Images

클라우드 컴퓨팅은 스프레드시트를 사용하는 CIO부터 컨테이너를 쓰는 인턴까지 누구나 눈이 돌아갈 만큼 선택지가 다양하다. 램(RAM)이 24GB나 되는 서버도 좋아 보이고, 새로운 AI 이미지 분류 시스템도 좋아 보인다. 장기 객체 스토리지? 그것도 좋아 보인다. 

그렇다면 한 클라우드 업체의 옵션이 꽤 괜찮다고 할 때 과연 하나만 선택할까? 2개, 3개… 더 나아가 N개를 선택하지 않을까? 오늘날의 아키텍트라면 온 인터넷을 돌아다니면서 사용할 수 있는 것은 모조리 활용하고 싶어 하는 게 지극히 당연하다. 

여기서 멀티클라우드 아키텍처가 합리적인 이유가 있다. 클라우드가 많을수록 API 옵션, 데이터센터를 둘 위치, 사용할 수 있는 지능형 AI 알고리즘이 늘어나서다. 또 여러 클라우드를 사용하는 아키텍트 팀은 새로운 개선사항이 나왔을 때 민첩하게 이를 활용할 수 있을 것이다. 

한 업체에 종속(lock-in)되지 않으려는 니즈도 있다. 재계약을 할 때 경쟁 업체를 찾지 않는다면 가격이 오르기 마련이다. 처음부터 아키텍처에 멀티클라우드로 민첩성을 확보한다면 클라우드 업체 영업팀이 압박을 가하고자 할 때(비용을 올리려 할 때) 다른 업체로 쉽게 전환할 수 있다. 주말 사이에 다른 업체로 거래처를 옮긴다는 건 거부할 수 없을 정도로 달콤한 꿈이다. 

그러나 모든 선택에는 대가가 따른다. 경쟁을 즐길 수 있을 만큼 민첩성을 유지하는 것에는 어두운 비밀이 있는데, 이는 분명히 드러나기까지 몇 주 내지 몇 달, 심지어는 몇 년이 걸릴 수도 있다. 멀티클라우드에 숨겨진 위험 11가지를 살펴본다. 

1. 독점 솔루션을 사용할 기회를 놓칠 수 있다 
오늘날 많은 클라우드 업체가 램(RAM) 용량을 변경할 수 있고, 선호하는 리눅스 버전을 선택할 수 있는 인스턴스를 판매하고 있다. 또 모든 업체가 사용자의 데이터를 클라우드에 저장해준다. 이 지극히 평범한 모든 옵션 사이에 독보적이고 강력한 도구가 있는데, 이는 대부분 독점 기술이다. 예를 들면 오라클의 기본 데이터베이스, 구글의 파이어베이스(Firebas), 마이크로소프트의 닷넷(.Net) 등이다.           

멀티클라우드를 채택하면 이러한 독점 도구를 충분히 활용하지 못할 수 있다. 다른 클라우드에 이들 도구를 복제하기 어렵기 때문이다. 여러 도구를 ‘즐기기 위해’ 치러야 할 큰 대가는 한 가지 뛰어난 도구와는 결혼할 수 없다는 점이다. 

2. 지나치게 많은 선택지
후기 자본주의를 비판하는 사람들은 일부 쇼핑몰에 수천 가지 종류의 양말을 쌓아 두기만 하고 아무것도 하지 않는 매장들이 있다고 말한다. 아마도 이러한 비판론자들은 선택지가 단 하나뿐이었던 공산주의 체제를 경험해보지 못했을 테지만 이들의 주장에도 일리는 있다.

선택에는 시간이 걸린다. 선택의 여지가 너무 많으면 어쩔 수 없이 스프레드시트와 체크리스트를 작성해야 하고, 회의를 통해 위원회 검토를 받아야 한다. 이러한 작업은 시간당 급여를 받는 직원들의 리소스를 조금씩이라도 잡아먹기 마련이다. 

3. 여러 변화를 동시에 관리해야 하는 어려움
클라우드의 많은 부분이 자동화돼 있긴 하지만 작은 차이점들이 항상 존재하기 때문에 이를 추적하고 파악해야 할 필요가 있다. 예를 들면 한 클라우드가 다른 클라우드보다 먼저 PHP 8로 업데이트됐을 수 있고, 또 다른 클라우드는 가격 책정 모델을 바꾸고 있을 수도 있다. 

또 공급업체와 협력업체가 많아진다는 건 곧 이메일 공지, 화상회의(그리고 언젠가는 리조트에서 개최될 연례 컨퍼런스)가 많아진다는 의미다. 그리고 이는 할 일이 더 많아진다는 뜻이기도 하다. 즉 멀티클라우드라는 자유를 누리는 대신, 여러 업체의 이메일과 보도자료, 발표를 끝없이 확인해야 한다.

4. 표준이 아닌 표준
10대들은 ‘농담 아닌 농담(kidding/not kidding)’ 같은 말로 진심의 깊이를 헤아리는 걸 좋아하는데, 표준을 정하는 사람들도 그렇다. 이론적으로 인터넷은 모든 것이 상호 운용될 수 있도록 보장하는 구체적이고 뚜렷하게 명시된 표준과 결합돼 있다. 이는 사실이기도 하지만 그렇다고 해서 완벽하지도 않다. 

예를 들면 현재 사용하고 있는 우분투(Ubuntu)나 파이썬(Python) 버전 또는 소위 표준이라고 부르는 다른 버전 간에 항상 작은 차이가 있기 마련이다. 이런 차이가 발견되면 코드는 문제를 일으킬 것이다. 코드를 여러 클라우드로 분산 시켜 뒀다면 이런 작은 차이가 토요일 밤늦게 혹은 휴가 중에 불쑥 나타날 가능성이 커진다.

5. 지연
일반적으로 같은 랙에 있는 시스템 사이에서 패킷을 전송하는 것이 지구 반대편에 있는 다른 데이터센터로 패킷을 전송하는 것보다 빠르다. 남극 대륙에 있는 스토리지를 쓴다면(즉 저렴한 비용으로 사용하고자 한다면) 멀티클라우드 전략은 지연시간이 길어질 수밖에 없다. 

이것이 항상 중요한 건 아니다. 어떤 패킷은 빨리 이동할 필요가 없기 때문이다. 하지만 어떤 애플리케이션이든 상호작용이 가장 많은 부분을 구동하는 기본 루틴이라면 핵심 마이크로서비스를 근접하게 실행하는 게 좋을 것이다. 

6. 늘어나는 학습
하나의 클라우드에 투자한다는 건 해당 업체의 제품과 고유한 인터페이스를 익혀야 한다는 의미다. 따라서 여러 클라우드에 투자하면 이 학습을 여러 번 해야 한다는 뜻이다. 담당 팀은 계속해서 전문성을 쌓아야 한다. 

물론 이 과정을 단순화하는 좋은 옵션이 있다. 예를 들면 백블레이즈(Backblaze)에는 아마존의 S3 버킷을 모방한 스토리지 API가 있다. 허나 예외적인 사례일 뿐이다. N가지를 선택했으면 학습도 N번 해야 한다.

7. 가격 책정 모델이 상황을 복잡하게 만든다 
시간당 최저가를 선택하는 게 쉬운 방법 같지만 결국 다른 비용으로 인해 문제가 되는 경우도 많다. 예를 들면 일부 클라우드는 데이터를 자사 데이터센터 외부로 내보낼 때 비용을 청구한다. 장기 약정 시 혜택을 늘려주는 클라우드도 있다. 가격 책정 모델에는 여러 중심축이 있으며, 가장 저렴한 가격을 선택하려면 꽤나 정확한 추정치가 필요하다. 제품 자체는 가격이 정해진 상품처럼 보일지 몰라도 가격 책정 모델은 그렇지 않기 때문이다. 

8. 최소 공통분모 접근법
담당 팀이 마법을 부려서 코드 계층에 멋진 기능을 추가할 수도 있지만 최소한의 코드로 시작할 때는 이를 넘어서기가 다소 어렵다. 대부분의 작업은 그다지 고급 기능을 필요로 하지 않고, 가장 간단한 솔루션으로 더 잘 해결된다. 멀티클라우드 아키텍처는 최소한의 공통분모를 향해 나아가는 경향이 있다. 

9. 대량 구매로 인한 할인 혜택을 놓칠 수 있다
클라우드 업체들은 대량 구매를 하는 회사, 특히 미리 다 년간의 장기 약정을 하는 기업에 큰 할인 혜택을 제공한다. 민첩한 상태를 유지하면서 여차하면 새 클라우드로 바꿔 탈 준비가 되어 있다는 건 한 업체에 종속되는 문제를 피할 순 있지만 동시에 가격 할인을 받지 못한다는 걸 의미한다. 여러 클라우드로 지출을 분산시킬수록 대규모 약정 시에 대폭 할인을 받기가 그만큼 어려워진다.

10. 까다로운 신뢰 문제
비즈니스에서 누군가를 신뢰하는 일은 신중하게 이뤄져야 한다. 한 업체만 무조건적으로 신뢰하지 않는 것도 중요하다. 하지만 여러 업체와 거래하다 보면 신뢰하는 대상이 늘어나고, 실망하거나 배신당할 확률도 늘어나는 부작용이 생긴다. 업체 각각을 그렇게 많이 신뢰하지 않을 수도 있지만 멀티클라우드를 계속 운영하는 데 필요한 신뢰의 총량은 몇 배로 늘어나는 셈이다. 

11. 법적 허점이 쉽게 발생할 수 있다
한 클라우드 업체를 고수할 때의 장점은 해당 업체가 다른 업체 탓을 하기 어렵다는 것이다. 한 업체에서 화재 보험을 구매하고, 다른 업체에서 침수 보험을 구매했다고 해보자. 홍수로 인해 전기 누전 화재가 발생한다면 두 회사는 상대방에게 보험금 지급을 떠넘기려고 할 것이 틀림없다. 

여러 클라우드를 사용한다는 건 단순히 여러 건의 기본 계약서를 처리하고 계약을 협상한다는 의미에 그치지 않는다. 이는 그사이에 허점이 발생하기 더욱더 쉬워지는 동시에 이러한 허점에 빠지기도 쉽다는 의미다.
 
ciokr@idg.co.kr
 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.