멀티클라우드, 이제 '설계'가 아니라 '클릭'의 문제입니다
Azure와 AWS를 동시에 쓰는 조직이라면 한 번쯤 겪어봤을 겁니다. ExpressRoute와 Direct Connect를 각각 신청하고, 라우팅 테이블을 맞추고, 프로비저닝 일정을 조율하고, 모니터링을 이중으로 붙이고, 수명주기 관리까지… 이걸 다 사람이 손으로 맞춰야 했어요. 이른바 '멀티클라우드 네트워킹 삽질'의 정석이죠.
Microsoft가 최근 공개한 Azure Multicloud Interconnect는 이 모델을 근본부터 바꿉니다. 양쪽 클라우드가 표준화된 Open API 스펙으로 협업해서, 고객은 복잡한 네트워킹 세부사항을 신경 쓰지 않고 프라이빗 전용 연결을 만들 수 있게 됐어요. 인프라 관리가 아니라 애플리케이션과 데이터에 집중할 수 있는 구조로의 전환이라고 보시면 됩니다.
이 글에서는 이번 발표의 기술적 핵심, AI 시대에 왜 이게 중요한지, 그리고 국내 환경에서 어떤 의미가 있는지를 정리해볼게요. 근거자료는 Azure 공식 블로그에서 직접 확인하실 수 있습니다.
기술적으로 뭐가 달라졌나 — Open API + Private Link 조합
1) 추상화 계층이 '양쪽'에 생겼다
기존 멀티클라우드 연결은 각 클라우드의 네이티브 도구(ExpressRoute, Direct Connect)를 사람이 이어 붙이는 방식이었어요. Azure Multicloud Interconnect는 여기에 표준 Open API 스펙을 끼워 넣어, 양쪽 프로바이더가 같은 언어로 연결을 협상하도록 만듭니다.
# 개념적 흐름 (실제 CLI는 Azure Portal / AWS Console에서 제공)
# 1. Azure 측에서 Multicloud Interconnect 리소스 생성
az network multicloud-interconnect create \
--name azure-to-aws-prod \
--peer-provider aws \
--bandwidth 100Gbps \
--region koreacentral
# 2. AWS 측에서 동일 Open API 스펙으로 페어링 요청 수락
# → 라우팅/보안 정책은 양쪽 API가 자동 협상
# 3. Azure Private Link 엔드포인트로 종단 간 프라이빗 경로 완성
az network private-endpoint create \
--name aws-app-pe \
--connection-name multicloud-link \
--resource-group rg-ai-workloads
핵심은 **"라우팅/모니터링/수명주기를 사람이 맞추지 않는다"**는 점이에요. API가 그 일을 대신합니다.
2) 스펙 한눈에 보기
| 항목 | 기존 방식 | Azure Multicloud Interconnect |
|---|---|---|
| 초기 대역폭 | 수십 Mbps~10Gbps, 협의 필요 | 최대 100 Gbps (GA 시점부터) |
| 보안 | IPsec/VPN 별도 구성 | MACsec 기본 제공 |
| 가용성 | SLA 협상 필요 | Four-nines (99.99%) |
| 확장 | 재설계/재프로비저닝 | 동적 확장 (무중단) |
| 프로비저닝 | 수동 조율 | API 기반 자동화 |
| 종단 경로 | 클라우드 경계에서 종료 | Azure Private Link까지 확장 |
3) AI 워크로드 관점에서의 의미
학습(training)과 추론(inference)은 데이터가 환경을 넘나드는 걸 전제로 합니다. 예를 들어 AWS S3에 있는 학습 데이터를 Azure의 GPU 클러스터로 가져와야 하는 상황을 생각해보면, 이때 필요한 건 고대역폭 + 낮은 지터 + 프라이빗 경로예요. 퍼블릭 인터넷을 경유하는 순간 컴플라이언스도 깨지고 예측 가능성도 사라집니다. Azure Multicloud Interconnect는 이 세 가지를 동시에 잡으려는 시도라고 볼 수 있어요. 관련해서 Azure의 AI 데이터센터 전략은 엔비디아 루빈 대응 전략 정리 글에서 더 자세히 다뤘어요.
주의할 점과 현실적인 한계
좋은 소식만 나열하는 건 멘토로서 예의가 아니죠. 몇 가지 짚어볼게요.
- GA 시점과 리전 제약: 100Gbps가 'day one'부터 제공된다고는 하지만, 모든 Azure 리전과 모든 AWS 리전 조합에서 즉시 되는 건 아닙니다. 국내 고객이라면 Korea Central ↔ ap-northeast-2(서울) 조합의 GA 여부를 먼저 확인해야 해요.
- Open API 스펙의 확산 속도: 현재는 Azure ↔ AWS 단일 관계에 초점이 맞춰져 있습니다. GCP나 OCI로 확장된다는 건 '비전'이고, 실제 지원 시점은 별개예요. 멀티클라우드 3사 이상을 쓰는 조직이라면 여전히 일부는 수동 구성이 필요합니다.
- 비용 모델 불투명: 프라이빗 연결은 결국 양쪽에서 과금됩니다. 송신 트래픽(egress) 비용이 어디서 어떻게 잡히는지, MACsec 암호화 오버헤드가 처리량에 얼마나 영향을 주는지는 실제 PoC로 검증하는 걸 권합니다.
- 운영 주체의 변화: 'API가 다 해준다'는 건 곧 API 장애 시 양쪽 클라우드가 동시에 영향받는다는 뜻이기도 합니다. 이중화 경로 설계는 여전히 필요해요.
한국 개발 생태계에서의 적용 맥락
국내 SI/엔터프라이즈 환경에서는 이 변화가 두 갈래로 갈릴 가능성이 큽니다.
- 금융/공공: 규제상 '데이터 국외 이전' 이슈가 있어서, AWS 서울 리전과 Azure Korea Central 간 연결은 오히려 규제 친화적일 수 있어요. 기존에는 VPN 이중화로 버티던 부분을 MACsec + four-nines로 대체할 명분이 생깁니다.
- 스타트업/중견: 두 클라우드를 쓰는 이유가 대부분 '각 클라우드의 강점 활용'인데, 지금까지는 그 대가로 네트워킹 복잡도를 치렀죠. 이번 발표는 그 복잡도를 관리 대상에서 제거하는 방향이라, 소규모 팀에도 실질적인 이득이 있습니다.
다만 국내 클라우드 MSP 생태계는 기존 ExpressRoute/Direct Connect 기반 구축 노하우가 자산이었는데, 이게 추상화되면 부가가치 지점이 '설계'에서 '운영 자동화'로 이동할 겁니다. 관련 흐름은 메타의 RCCLX AMD GPU 통신 오픈소스 소식과도 연결되는데, 결국 하드웨어·네트워크 계층에서 '개방형 표준'이 이기는 방향으로 업계가 움직이고 있다는 신호로 읽힙니다.
정리 — '연결'은 이제 인프라가 아니라 API입니다
Azure Multicloud Interconnect의 본질은 새로운 전용선 상품이 아니라, 멀티클라우드 네트워킹을 API 계층으로 끌어올린 것이에요. 이게 성공하면 다음 단계는 자연스럽게 이렇게 흘러갑니다.
- 1단계 (현재): Azure ↔ AWS 프라이빗 연결 자동화
- 2단계 (예상): GCP, OCI 등 다른 하이퍼스케일러로 Open API 스펙 확산
- 3단계 (비전): 통신사업자/ISP까지 같은 프레임워크로 묶여 '메트로 ↔ 클라우드 ↔ 엔터프라이즈'가 하나의 API로 연결
다음 단계 학습 방향
- 직접 PoC 해보기: Azure Portal에서 Multicloud Interconnect 리소스를 만들어보고, AWS 측 페어링까지 한 번 끝까지 해보세요. 문서만 읽는 것과 실제 삽질은 완전히 다릅니다.
- 비용/성능 벤치마크: 10Gbps vs 100Gbps에서 AI 학습 데이터 전송 시간이 얼마나 줄어드는지, egress 비용은 어떻게 변하는지 측정해보세요.
- 보안 정책 재정비: MACsec이 기본이 되면서 기존 IPsec 기반 정책과 어떻게 공존할지 정리해야 합니다.
- 오픈 표준 흐름 따라가기: Open API 스펙이 어디까지 확장되는지, IETF/ONF 같은 표준 기구에서 논의되는지 추적해두면 2~3년 뒤 설계에 큰 자산이 됩니다.
함께 보면 좋은 글
멀티클라우드는 이제 '왜 쓰나'의 문제가 아니라 '얼마나 자연스럽게 잇느냐'의 문제로 넘어왔습니다. 이번 발표는 그 전환점에 서 있는 신호예요. 😊