지난 글에서는 클라우드 마이그레이션을 다루면서 “하나의 클라우드를 어떻게 쓸 것인가”의 문제에 집중했습니다. 6R로 무엇을 어떻게 옮길지 정하고, 클라우드 파운데이션으로 그 위에 올라갈 자원을 떠받치고, FinOps로 비용을 통제하는 흐름이었습니다.
그런데 현실은 한 회사가 보통 두 개 이상의 클라우드를 함께 씁니다. AWS에 데이터 분석을 돌리고, Azure에 협업 도구를 두고, GCP에 머신러닝 모델을 학습시키는 식입니다. 딜로이트 테크 트렌드 2023에 따르면 85%의 기업이 2개 이상의 클라우드를 사용하고, 25%는 5개 이상을 쓴다는 조사 결과도 있습니다. 멀티클라우드는 이미 선택이 아니라 디폴트에 가깝습니다.
이 글에서 답해보려는 질문은 다음과 같습니다.
- 멀티클라우드와 하이브리드 클라우드는 무엇이 다른가
- 기업은 왜 멀티클라우드를 쓰고, 그 대가로 무엇을 치르는가
- 멀티클라우드의 복잡성을 풀기 위해 등장한 메타클라우드는 무엇이고, 어떤 제품들이 그 자리를 노리는가
- 메타클라우드는 만능 해답이 될 수 있는가, 아니면 한계가 분명한가?
1. 멀티클라우드란 무엇인가
두 개 이상의 퍼블릭 클라우드를 함께 사용하는 것이 멀티클라우드입니다. 헷갈리는 개념으로 ‘하이브리드 클라우드’가 있습니다.
[하이브리드 vs 멀티클라우드]
하이브리드 클라우드:
┌────────────────┐ ┌──────────────────┐
│ 온프레미스 / 사설 │ ◀▶ │ 퍼블릭 클라우드 1 │
│ 데이터센터 │ │ (AWS) │
└────────────────┘ └──────────────────┘
→ 사설 인프라 + 퍼블릭 클라우드의 결합
멀티클라우드:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ 퍼블릭 클라우드 1 │ │ 퍼블릭 클라우드 2 │ │ 퍼블릭 클라우드 3 │
│ (AWS) │ │ (Azure) │ │ (GCP) │
└──────────────────┘ └──────────────────┘ └──────────────────┘
→ 두 개 이상의 퍼블릭 클라우드를 함께 사용
하이브리드는 ‘사설 + 퍼블릭’의 조합이고, 멀티는 ‘퍼블릭 여러 개’의 조합이라는 점이 핵심입니다. 물론 둘이 동시에 일어나기도 합니다. 사설 데이터센터를 두면서 퍼블릭 클라우드를 여러 개 쓰는 ‘하이브리드 멀티클라우드’ 형태도 흔합니다.
1) 왜 멀티클라우드를 쓰는가
기업이 멀티클라우드를 선택하는 이유는 보통 다음 셋 중 하나(혹은 그 조합)로 정리됩니다.
- 벤더 종속 회피: 한 CSP에 묶이면 협상력이 떨어지고, 그 회사가 가격을 올리거나 서비스를 변경할 때 대응이 어렵습니다. ‘협상 카드’로서 두 번째 CSP를 두는 의도가 큽니다.
- 각 CSP의 강점 활용: CSP마다 잘하는 영역이 다르기 때문에, 워크로드의 성격에 맞춰 ‘잘하는 곳에 잘 맞는 일을 맡긴다’는 발상입니다.
- 리스크 분산: 한 CSP에 대규모 장애가 생겼을 때 전사 서비스가 한꺼번에 멈추는 사태를 막습니다. 2021~2023년 사이 AWS, Azure, GCP가 각각 대규모 장애를 겪은 일이 있었고, 이 사건들 이후 단일 CSP 의존 리스크가 한층 더 부각됐습니다.
2) 멀티클라우드의 단점
이렇게 정리해보면 멀티클라우드의 매력이 분명합니다. 그런데 단점도 만만치 않습니다.
- 복잡성이 폭발합니다. CSP마다 콘솔, IAM 모델, 네트워크 구성, 모니터링 도구가 다 다릅니다. 새 엔지니어가 들어오면 “우리 회사 클라우드 환경”을 이해하는 데만 몇 주가 걸립니다.
- 중복 비용이 늘어납니다. 같은 일을 하는 모니터링 도구·보안 도구·로그 도구를 CSP마다 따로 사야 할 때가 있습니다. 통합 도구가 있더라도 그 도구의 라이선스 비용이 또 추가됩니다.
- 데이터 이동 비용이 큽니다. CSP 간 데이터 전송에는 ‘egress fee’라는 별도 비용이 붙습니다. AWS의 데이터를 Azure로 옮기는 순간 GB당 비용이 발생합니다. 멀티클라우드를 무계획적으로 쓰면 이 비용이 의외로 크게 누적됩니다.
- 인력을 구하기 어렵습니다. AWS, Azure, GCP를 모두 깊이 다룰 수 있는 엔지니어는 시장에 흔하지 않고, 인건비도 비쌉니다. 보통은 CSP별로 전문 엔지니어를 따로 두게 되고, 이게 인건비 증가로 이어집니다.
실제로 딜로이트 테크 트렌드 2023에 따르면 85%의 기업이 2개 이상의 클라우드를 사용하고, 25%는 5개 이상을 쓴다는 조사 결과도 있습니다. 멀티클라우드는 이미 선택이 아니라 디폴트에 가깝습니다.
2. 메타클라우드: 멀티클라우드의 다음 단계
멀티클라우드의 복잡성이 임계점을 넘으면, 결국 “이 클라우드들을 한꺼번에 통제할 수 있는 무언가”가 필요해집니다. 그게 메타클라우드(metacloud, supercloud라고도 부름)입니다. ‘슈퍼클라우드(supercloud)’라는 용어는 2016년 코넬대 연구팀이 제시한 개념으로, 원전에서는 “서로 다른 가용 영역(availability zone)이나 클라우드 제공자 사이에서 애플리케이션 마이그레이션을 서비스로 가능하게 하는 클라우드 아키텍처”로 정의됩니다.
즉, 코넬대의 원래 강조점은 ‘여러 CSP에 걸쳐 애플리케이션을 자유롭게 옮길 수 있게 만드는 일’에 있었습니다. 이후 업계에서는 이 개념을 확장 해석해, ‘여러 하이퍼스케일 CSP 위에 추상화 레이어를 두어 멀티클라우드 관리 문제 전반을 푸는 아키텍처’로 사용해 왔습니다. ‘메타’든 ‘슈퍼’든 ‘스카이 컴퓨팅’이든, 오늘날 가리키는 대상은 비슷합니다.
메타클라우드는 여러 퍼블릭 클라우드 위에 얹는 호환 레이어입니다. 저장, 연산, AI, 보안, 거버넌스, 배포 같은 공통 서비스를 통합 인터페이스로 제공해, 어느 CSP를 쓰든 비슷한 방식으로 다룰 수 있게 만드는 것이 목표입니다.
[메타클라우드 개념]
애플리케이션 / 운영팀
▲
│ (단일 인터페이스로 접근)
│
┌────────────────────────┐
│ 메타클라우드 레이어 │
│ (저장·연산·보안·거버넌스) │
└─────────┬──────────────┘
│
┌─────────┼─────────┬─────────┐
▼ ▼ ▼ ▼
AWS Azure GCP 기타 CSP
핵심은 여러 클라우드의 차이를 메타클라우드 레이어가 흡수해버린다는 점입니다. 운영팀은 “AWS의 IAM이 어떻고, Azure의 ARM 템플릿이 어떻고” 하는 차이를 매번 신경 쓸 필요 없이, 통일된 방식으로 자원을 다룹니다.
〈딜로이트 테크 트렌드 2023〉 1편에서 이미 메타클라우드를 한 번 짚은 적이 있는데, 그때 중요한 표현이 **“단순성을 서비스로 제공(Simplicity-as-a-Service)하는 것”**이었습니다. 멀티클라우드가 만들어낸 복잡성을, 단순성이라는 상품으로 되팔겠다는 발상입니다.
(1) 이미 시장에 나와 있는 메타클라우드 제품들
‘메타클라우드’가 이론적인 개념처럼 들리지만, 실제로는 이미 시장에서 그 자리를 노리는 제품들이 여럿 있습니다. 셋은 쿠버네티스를 공용 기반으로 삼고, 하나는 쿠버네티스뿐 아니라 가상머신·데이터베이스까지 함께 관리합니다.
| 제품 | 만든 곳 | 무엇을 하는 도구인가 | 어떤 조직에 잘 맞는가 |
|---|---|---|---|
| Google Anthos | 구글 | 여러 CSP에 흩어진 쿠버네티스 클러스터를 구글 콘솔 하나로 묶어서 관리 (쿠버네티스 기반) | 이미 GCP를 쓰고 있고, 구글 생태계 안에서 멀티클라우드를 통제하고 싶은 조직 |
| VMware Tanzu | VMware (Broadcom 인수) | 사내 VMware 가상화 환경과 여러 CSP의 쿠버네티스를 하나의 도구로 운영 (쿠버네티스 기반) | 데이터센터에 VMware 자산이 많고, 거기서 멀티클라우드로 자연스럽게 넓혀가려는 조직 |
| Red Hat OpenShift | Red Hat (IBM) | 온프레미스든 어떤 CSP든 똑같은 모양의 쿠버네티스 환경을 깔아주는 플랫폼 (쿠버네티스 기반) | 망분리 같은 규제로 온프레미스를 유지해야 하는 한국 금융권·공공처럼, 사내 환경과 클라우드를 같은 방식으로 운영하려는 조직 |
| Azure Arc | 마이크로소프트 | AWS·GCP·온프레미스의 가상머신·쿠버네티스·데이터베이스까지 모두 Azure 콘솔에서 관리되는 자원처럼 등록·통제 (쿠버네티스만이 아니라 자원 전반) | Azure가 주력이고, 다른 환경의 자원도 Azure 보안·정책 도구로 묶고 싶은 조직 |
표를 보면 네 제품의 출발점이 다 다릅니다.
- Anthos는 ‘구글에서 출발해서 밖으로’
- Tanzu는 ‘VMware 데이터센터에서 출발해서 클라우드로’
- OpenShift는 ‘어디든 똑같은 모양으로 깔린다’
- Arc는 **‘Azure 안으로 다른 곳을 끌어들인다’**는 식입니다.
출발점은 다르지만 도달하려는 자리는 같습니다. 여러 클라우드에 흩어진 자원을 하나의 인터페이스로 다루는 추상화 레이어입니다.
다만 결이 한 가지 다릅니다. 앞의 셋은 쿠버네티스 위에서 돌아가는 컨테이너 워크로드를 통합하는 데 초점이 있고, Arc는 거기에 더해 가상머신·데이터베이스 같은 비(非)쿠버네티스 자원까지 포함합니다. 그래서 Arc를 ‘메타클라우드’ 범주로 분류할 때는 ‘여러 클라우드의 모든 자원을 통합 관리하는 도구’라는 더 넓은 의미로 봐야 합니다.
(2) 왜 쿠버네티스가 ‘공용 언어’가 되었는가
이 제품들 중 셋(Anthos, Tanzu, OpenShift)은 쿠버네티스(Kubernetes)를 ‘공용 언어’로 삼는다는 공통점이 있습니다. 그런데 왜 하필 쿠버네티스일까요.
쿠버네티스가 사실상 모든 주요 CSP에서 ‘똑같이 동작하는 표준’이 되었기 때문입니다. AWS는 EKS, Azure는 AKS, GCP는 GKE라는 이름으로 쿠버네티스 매니지드 서비스를 제공합니다. 이름과 부가 기능은 다르지만, 그 안에서 돌아가는 컨테이너와 매니페스트(YAML)는 거의 같습니다. 즉, 쿠버네티스 위에서 돌아가는 워크로드는 어느 CSP로 옮겨도 비슷하게 동작합니다. 이 표준이 있었기 때문에 그 위에 관리·정책·모니터링 레이어를 얹어 ‘CSP를 가리는’ 메타클라우드가 가능해진 것입니다.
흥미로운 건 Azure Arc 같은 제품이 ‘메타클라우드 도구’이면서 동시에 ‘마이크로소프트 생태계의 외연 확장 도구’라는 양면성을 가진다는 점입니다. AWS·GCP의 자원을 Azure 리소스로 등록해서 Azure의 정책·모니터링 도구로 다스리도록 만드는 식이죠. ‘중립적인 메타클라우드’가 아니라 ‘우리 클라우드 깃발 아래로 다른 클라우드를 끌어오는 도구’에 가깝습니다. 메타클라우드라는 깃발은 결국 누가 그 추상화 레이어를 장악하느냐의 경쟁이기도 합니다.
(3) 메타클라우드의 한계
다만 메타클라우드에는 만만치 않은 한계가 있습니다.
| 한계 | 핵심 원인 | 구체적 양상 | 시사점 |
|---|---|---|---|
| 1. CSP들의 이해관계와 정면 충돌 | 메타클라우드 = 클라우드의 평준화(commoditization) → CSP는 가격 경쟁만 남는 시장을 원하지 않음 | CSP들이 고유 생태계를 더 깊게 만드는 방향으로 대응. 특히 AI 영역(AWS Bedrock, GCP Vertex AI, Azure OpenAI Service)에서 락인 강화. 데이터·모델·프롬프트 노하우가 특정 CSP에 축적됨 | 컴퓨팅·스토리지·네트워크 같은 공통 영역은 추상화 가능하지만, 차별화 가치가 큰 영역에서는 락인이 오히려 심해짐 |
| 2. 추상화의 비용 | 메타클라우드도 결국 또 하나의 레이어 → 운영 복잡성 추가 | 메타클라우드 도구 운영 인력, 라이선스 비용, CSP 신규 기능 미지원 시 사용 여부 고민 등 부가 비용 발생 | 만능 해법 아님. 조직의 멀티클라우드 복잡성이 메타클라우드 운영 비용을 넘어설 때만 의미 있는 선택 |
| 3. 자체 클라우드 구축 가능성과 CSP의 견제 | 메타클라우드가 보편화되면 기업이 CSP 의존을 줄이고 사설 클라우드 + 메타클라우드 레이어 조합 가능 | CSP들이 라이선스 정책, 데이터 이동 비용, 신규 서비스 접근권 등 다양한 레버로 ‘자사 클라우드 안에 있을 때의 이점’을 계속 강화 | 가능성은 있지만 CSP 견제로 단기간에 펼쳐지기는 어려움 |
한계 1: CSP들의 이해관계와 정면으로 부딪힘
메타클라우드가 잘 작동한다는 건 “AWS든 Azure든 GCP든 사실상 같은 것”처럼 다뤄진다는 뜻입니다. 이는 곧 클라우드의 평준화(commoditization)를 의미합니다. 가격 경쟁만 남게 되는 시장은 어느 CSP도 반기지 않습니다. 그래서 CSP들은 자사 고유 기능을 메타클라우드 레이어가 다 흡수하지 못하도록 자기 생태계를 더 깊게 만드는 방향으로 움직입니다.
대표적인 흐름이 AI입니다. AWS의 Bedrock, GCP의 Vertex AI, Azure의 OpenAI Service는 모두 ‘CSP 고유의 AI 서비스’입니다. 일단 이 서비스를 깊이 쓰기 시작하면 다른 CSP로 옮기기가 매우 어려워집니다. 데이터·모델·프롬프트 엔지니어링 노하우가 그 CSP 안에 쌓이기 때문입니다. 메타클라우드가 컴퓨팅·스토리지·네트워크 같은 ‘공통 영역’을 잘 추상화하더라도, AI처럼 차별화 가치가 큰 영역에서는 CSP의 락인이 강해지고 있다는 뜻입니다.
한계 2: 추상화의 비용
메타클라우드는 결국 또 하나의 레이어이고, 그만큼 운영 복잡성이 더해집니다. 메타클라우드 도구 자체를 운영할 인력, 그 도구의 라이선스 비용, 그리고 메타클라우드 레이어가 못 따라가는 CSP 신규 기능을 어떻게 처리할지의 문제까지 같이 따라옵니다. CSP가 새 서비스를 출시했는데 메타클라우드 레이어가 아직 그걸 지원하지 않는다면, 그 기능을 쓸지 말지부터 고민해야 합니다.
그래서 어떤 조직에는 멀티클라우드 자체가 견딜 만한 수준의 복잡성이라, 굳이 위에 한 층을 더 쌓을 이유가 없을 수도 있습니다. 메타클라우드는 ‘만능 해법’이 아니라 ‘조직의 멀티클라우드 복잡성이 메타클라우드 운영 비용을 넘어설 때만 의미 있는 선택’이라는 게 정확한 표현입니다.
한계 3: 자체 클라우드 구축의 가능성과 그 견제
메타클라우드 접근법이 보편화될 경우 기업들이 CSP에 의존하지 않고 자체적인 클라우드 기반을 구축할 수 있는 길이 열린다는 점도 흥미로운 가능성입니다. 즉, ‘대규모 기업이 자기만의 사설 클라우드를 구축하고 그 위에 메타클라우드 레이어로 일관성을 확보하는’ 시나리오입니다. 다만 이 시나리오는 CSP들의 견제를 거칠 수밖에 없어, 단기간에 펼쳐지기는 어려워 보입니다. 라이선스 정책, 데이터 이동 비용, 신규 서비스 접근권 같은 다양한 레버를 통해 CSP들이 ‘자사 클라우드 안에 있을 때의 이점’을 계속 키워나가고 있기 때문입니다.
메타클라우드는 멀티클라우드의 복잡성을 풀어주는 매력적인 해법이지만, 클라우드 시장의 경제 구조와 충돌하기 때문에 만능 해답이 되기는 어렵습니다. 당분간은 “필요한 조직이 부분적으로 도입하는” 형태로 천천히 자리잡을 가능성이 높아 보입니다.
클라우드를 둘러싼 의사결정은 결국 “얼마나 많이 옮기느냐”가 아니라 “어디서 가치가 나오는가, 그리고 그 가치를 여러 클라우드에 걸쳐서도 어떻게 지킬 것인가” 의 질문으로 수렴합니다. 이 질문 앞에서 6R, 클라우드 파운데이션, FinOps, 멀티클라우드, 메타클라우드가 각자의 자리를 잡습니다.