AWS·구글 클라우드 멀티클라우드 연동 발표 — 아키텍트가 봐야 할 진짜 변화와 한계

멀티클라우드를 오래 해본 사람이면 안다. 두 클라우드를 “붙인다”는 말이 실무에서 얼마나 지저분한 작업인지. VPN 터널이든 전용선이든, 각 클라우드의 게이트웨이·라우팅·BGP·보안그룹을 양쪽에서 따로 맞춰야 하고, 한쪽 설정이 바뀌면 반대쪽도 손대야 한다. 이번 발표의 핵심은 그 “양쪽에서 따로”를 “한 번의 요청으로” 바꾸겠다는 것이다. AWS 네트워크서비스 담당 부사장 로버트 케네디는 “고객이 연결을 만들려고 무거운 작업을 할 필요가 없어진다. 멀티클라우드 연결이 필요할 때 클릭 몇 번으로 몇 분 안에 활성화된다”고 밝혔다(보도 인용).

위 수치와 명칭은 CIO Dive 보도를 근거로 정리한 것이다. 프리뷰 단계 제품은 정식 출시 과정에서 이름·범위·조건이 바뀔 수 있으니, 실제 도입 전에는 각 클라우드의 공식 문서를 다시 확인하는 걸 권한다.

무엇이 발표됐나: 한 문장으로

AWS와 구글 클라우드가 서로의 클라우드를 잇는 전용 네트워크 연결을 자동화하기로 했다. AWS의 신제품 “AWS Interconnect - multicloud”와 구글의 기존 제품 “Cross-Cloud Interconnect”가 공통 사양으로 맞물려, 예전엔 며칠씩 걸리던 클라우드 간 프라이빗 연결을 콘솔에서 몇 분 만에 프로비저닝할 수 있게 된다는 게 골자다.

중요한 건 이게 단순한 “둘이 사이좋게 지내자” 선언이 아니라 네트워크 상호운용을 위한 개방형 사양을 함께 정의했다는 점이다. 수동으로 양쪽 클라우드에 연결을 세팅하던 방식에서, 클라우드 네이티브한 네트워킹 경험으로 넘어가겠다는 것. 그리고 애저까지 2026년에 이 사양에 합류한다면, 사실상 3대 클라우드가 공유하는 연결 규격이 생기는 셈이다.

두 제품이 실제로 어떻게 맞물리나

기존에 클라우드 두 개를 프라이빗하게 잇는 방법은 크게 두 갈래였다. 하나는 퍼블릭 인터넷 위에 IPsec VPN 터널을 까는 것, 다른 하나는 통신사 전용선이나 상호접속 지점(콜로케이션)을 거쳐 물리적으로 잇는 것. 전자는 싸지만 지연·대역폭·보안이 아쉽고, 후자는 튼튼하지만 주문부터 개통까지 몇 주가 걸린다. 이번 협업은 후자의 품질을 전자의 속도로 제공하겠다는 시도로 읽힌다.

표에서 내가 주목하는 칸은 “설정 위치”다. 멀티클라우드 네트워킹에서 진짜 고통은 대역폭이 아니라 양쪽을 일관되게 유지하는 운영 부담이다. A클라우드에서 라우트를 하나 바꾸면 B클라우드 쪽도 손대야 하고, 그걸 IaC로 관리한다 해도 두 프로바이더의 상태를 동기화하는 건 늘 삐걱댄다. 개방형 사양으로 양쪽이 같은 언어를 쓰면 이 마찰이 줄어든다.

왜 이게 이례적인 움직임인가

경쟁사끼리 자기 고객을 상대에게 넘겨주기 쉬운 “문”을 스스로 열어주는 건 상식적으로 이상하다. 그런데 자세히 보면 각자의 계산이 맞아떨어진다. 구글은 엔터프라이즈에서 흔히 “세 번째 클라우드”로 불린다. 이미 AWS를 쓰는 계정에 발을 들이기가 어려운데, 연결 장벽이 낮아지면 “AWS는 그대로 두고 이 워크로드만 구글에서”라는 제안이 쉬워진다.

AWS 입장에서도 손해가 아니다. 시장 지배력을 지렛대 삼아 자기가 정의한 개방형 API를 사실상의 업계 표준으로 굳힐 수 있다. 표준을 쥔 쪽이 판을 주도한다. 보도에서는 이 움직임이 오라클 같은 후발주자에게도 같은 사양을 따르라는 압박이 된다고 짚었다. 그리고 둘의 진짜 공동의 적은 서로가 아니라, “AI 네이티브 클라우드 주도권” 경쟁에서의 애저라는 해석이 붙는다.

아키텍트 관점: 멀티클라우드에 실제로 뭐가 좋아지나

멀티클라우드를 하는 이유는 유행이 아니라 대개 구체적 필요다. 특정 클라우드에만 있는 서비스(예: 한쪽의 AI 가속기나 특정 매니지드 DB), 인수합병으로 떠안은 이종 환경, 규제·데이터 주권, 그리고 협상력 확보. 이번 연동은 이 중 데이터가 클라우드 경계를 넘나드는 시나리오의 비용을 직접 낮춘다.

• AI 데이터 파이프라인: 학습 데이터는 A클라우드 스토리지에, GPU/TPU는 B클라우드에 있는 구성에서 데이터 이동 지연과 이그레스 경로가 개선될 여지.
• 재해복구(DR): 다른 클라우드를 스탠바이로 두는 크로스클라우드 DR의 링크 구성이 단순해진다.
• 점진적 이관: 빅뱅 마이그레이션 대신 서비스 단위로 옮기는 동안 두 환경을 프라이빗하게 잇고 살 수 있다.
• 협상 지렛대: 이전 비용(전환 비용)이 낮아질수록 단일 벤더에 대한 협상력이 올라간다.

다만 냉정하게 보면, 이건 네트워크 연결 계층의 개선이다. 멀티클라우드의 진짜 난도는 그 위에 있다. 그 얘기를 다음 섹션에서 하자.

벤더 락인은 정말 완화되나 (기대치 조정)

결론부터. 네트워크 락인은 줄지만, 진짜 락인은 그 위 계층에 있다. 두 클라우드를 광케이블처럼 잘 이어놔도, IAM 모델, 매니지드 서비스 API, 관측성 스택, 과금 단위가 서로 다르면 워크로드는 여전히 한쪽에 묶여 있다. 실무에서 나를 가장 오래 붙잡은 건 대역폭이 아니라 “이 IAM 정책을 저쪽에선 어떻게 표현하지” 같은 것이었다.

멀티클라우드에서 이식성을 결정하는 층위를 락인 강도 순으로 정리하면 이렇다.

데이터/네트워크 통합의 현실: 코드로 보는 원칙

프리뷰 제품의 정확한 CLI는 정식 출시 때 확정되니, 여기서는 멀티클라우드 연결을 다룰 때 변하지 않는 설계 원칙을 실제로 돌아가는 코드 수준에서 보여준다. 핵심은 세 가지 — 겹치지 않는 주소 대역, IaC로 양쪽을 한 소스에서 관리, 그리고 최소 권한 라우팅이다.

첫째, 두 클라우드의 VPC/VNet 대역이 겹치면 라우팅이 성립하지 않는다. 이건 연결 방식이 뭐가 됐든 불변의 전제다.

# 겹치지 않는 CIDR 설계 (겹치면 프라이빗 연결 자체가 불가)
AWS  VPC : 10.10.0.0/16   # AWS 쪽 워크로드
GCP  VPC : 10.20.0.0/16   # 구글 쪽 워크로드
# 예약/공유 대역은 문서화해서 팀 전체가 공유할 것
#   10.30.0.0/16 -> 향후 Azure(2026 합류 대비) 미리 비워둠

둘째, 두 클라우드를 하나의 Terraform 구성에서 선언적으로 다루면 “양쪽을 손으로 맞추다 틀어지는” 문제가 근본적으로 줄어든다. 아래는 두 프로바이더를 한 파일에서 잡는 뼈대다. 개방형 사양이 자리 잡으면 이 사이의 상호접속 리소스가 지금보다 훨씬 단순해질 것으로 기대한다.

terraform {
  required_providers {
    aws    = { source = "hashicorp/aws" }
    google = { source = "hashicorp/google" }
  }
}

provider "aws"    { region  = "ap-northeast-2" }   # 서울
provider "google" { project = "my-proj"  region = "asia-northeast3" }

# AWS 쪽 네트워크 (연결의 한쪽 끝)
resource "aws_vpc" "main" {
  cidr_block = "10.10.0.0/16"
  tags = { Name = "multicloud-aws" }
}

# GCP 쪽 네트워크 (연결의 반대쪽 끝)
resource "google_compute_network" "main" {
  name                    = "multicloud-gcp"
  auto_create_subnetworks = false
}

# 상호접속(Interconnect)은 프리뷰라 리소스명이 확정 전 -> 출시 후 공식 문서 확인
# 원칙: 양쪽 attachment/BGP 세션을 같은 state에서 관리해 드리프트를 막는다

셋째, 연결됐다고 전부 열지 마라. 멀티클라우드 연결에서 가장 흔한 사고는 “일단 다 통하게” 열어두고 방치하는 것이다. 필요한 서비스 대역만, 필요한 포트만 여는 최소 권한 라우팅이 기본이다.

# 예: GCP DB 서브넷(10.20.5.0/24)에서 AWS 앱 서브넷(10.10.1.0/24)
#     3306 포트로 들어오는 트래픽만 허용 (개념 예시)
aws ec2 authorize-security-group-ingress \
  --group-id sg-app \
  --protocol tcp --port 3306 \
  --cidr 10.20.5.0/24        # 상대 클라우드 대역을 명시적으로 화이트리스트

# 광범위한 0.0.0.0/0 이나 전체 VPC 대역 허용은 금물

지금 무엇을 준비해두면 좋은가

프리뷰라 당장 프로덕션에 넣을 건 아니지만, 방향은 분명하다. 3대 클라우드가 공통 연결 사양으로 수렴한다면, 미리 정리해둘수록 나중에 편하다. 내가 팀에 권하는 준비 목록은 이렇다.

• 주소 계획 통합: 클라우드별로 따로 노는 CIDR을 지금 한 장의 IPAM 시트로 모아라. 겹침을 나중에 푸는 건 지옥이다.
• IaC 일원화: 클라우드마다 다른 도구로 흩어져 있으면 Terraform/OpenTofu 같은 단일 도구로 상태를 모으는 작업을 먼저.
• 데이터 중력 파악: 어떤 데이터가 얼마나 크고 어디서 자주 읽히는지 측정해라. 이게 “무엇을 어느 클라우드에 둘지”를 결정한다.
• 이그레스 비용 모델링: 크로스클라우드 트래픽이 늘 때 청구서가 어떻게 변하는지 시나리오를 미리 계산.
• 관측성 통일: 두 클라우드에 걸친 요청을 하나의 트레이스로 보는 분산 추적을 붙여두면 장애 대응 난도가 확 낮아진다.

정리: 기대는 하되 계층을 구분하라

개인적으로는 반가운 소식이다. 멀티클라우드 연결의 지긋지긋한 수작업이 줄어드는 방향은 분명 옳다. 다만 “이제 벤더 락인 끝” 같은 헤드라인은 걸러 듣는다. 이번 발표가 푸는 건 배관(네트워크)이고, 진짜 락인은 그 위의 서비스·데이터·운영 모델에 여전히 두껍게 남아 있다.

실무자로서 취할 태도는 명확하다. 배관이 좋아지는 만큼 내가 통제할 수 있는 상위 계층에서 이식성을 확보해두는 것 — 컨테이너 표준화, IaC 일원화, 매니지드 서비스 의존 최소화. 그래야 “쉬워진 연결”이 실제 선택지의 확장으로 이어진다. 연결이 쉬워졌다고 워크로드가 저절로 자유로워지진 않는다. 그건 여전히 설계의 몫이다.

자주 묻는 질문

AWS와 구글 클라우드가 정확히 무엇을 발표했나요?

두 회사가 서로의 클라우드를 잇는 프라이빗 네트워크 연결을 자동화하는 협업을 발표했습니다. AWS의 “AWS Interconnect - multicloud”(프리뷰)와 구글의 “Cross-Cloud Interconnect”가 개방형 상호운용 사양으로 맞물려, 수동으로 며칠 걸리던 클라우드 간 연결을 콘솔에서 몇 분 만에 만들 수 있게 하는 것이 핵심입니다. 보도에 따르면 마이크로소프트 애저도 2026년 합류 예정입니다.

이걸로 벤더 락인이 사라지나요?

아닙니다. 완화되는 것은 네트워크 연결 계층입니다. IAM 모델, 매니지드 서비스 API, 데이터 이그레스 비용, 관측성 스택 같은 상위 계층의 락인은 그대로 남습니다. 워크로드의 실질적 이식성은 이런 상위 계층에서 결정되므로, 연결이 쉬워진 것과 자유로운 이전은 별개로 봐야 합니다.

지금 프로덕션에 바로 써도 되나요?

권하지 않습니다. 현재 프리뷰 단계라 기능·리전·가격이 확정 전이고 SLA 보장이 제한적일 수 있습니다. 먼저 PoC로 지연, 처리량, 과금 구조를 실측하고, 정식 출시 후 공식 문서로 조건을 재확인한 뒤 도입 여부를 정하는 것이 안전합니다.

클라우드 간 데이터 전송 요금도 싸지나요?

연결 경로가 프라이빗 백본으로 바뀌면 단가나 구조가 달라질 여지는 있지만, 데이터 이그레스 요금 자체는 여전히 각 프로바이더의 과금 정책을 따릅니다. 대용량 데이터를 상시로 오가게 설계하면 비용이 커질 수 있으니, “데이터를 어느 클라우드에 둘지”를 먼저 정하는 데이터 중력 기반 설계가 중요합니다.

경쟁사끼리 왜 이렇게 협력하나요?

각자의 이해가 맞아서입니다. 구글은 “세 번째 클라우드”로서 이미 AWS를 쓰는 계정에 진입하기 쉬워지고, AWS는 자사가 정의한 개방형 API를 사실상의 업계 표준으로 굳힐 수 있습니다. 보도에서는 이 움직임이 오라클 등 후발주자에게 압박이 되며, 두 회사의 공동 견제 대상은 AI 네이티브 클라우드 경쟁에서의 애저라는 해석을 덧붙였습니다.

아키텍트로서 지금 무엇을 준비하면 좋나요?

클라우드별로 흩어진 CIDR을 하나의 IPAM으로 통합하고(겹침 방지), IaC를 Terraform/OpenTofu 등 단일 도구로 일원화하세요. 또 어떤 데이터가 크고 자주 읽히는지 측정해 데이터 배치를 정하고, 크로스클라우드 이그레스 비용을 미리 모델링하며, 두 클라우드에 걸친 분산 추적을 붙여두면 나중에 훨씬 수월합니다.

멀티클라우드 네트워크를 안전하게 연결하는 핵심 원칙은 무엇인가요?

세 가지입니다. 첫째, 두 클라우드의 주소 대역(CIDR)이 겹치지 않게 설계합니다. 둘째, 양쪽 연결을 하나의 IaC 소스에서 관리해 설정 드리프트를 막습니다. 셋째, 연결됐다고 전부 열지 말고 필요한 대역·포트만 허용하는 최소 권한 라우팅을 적용합니다. 여기에 프라이빗 DNS 해석까지 세트로 챙겨야 실제로 서로를 찾을 수 있습니다.