구글 클라우드 자체 관리형 VMware 정식 출시, VMware Engine과 차이는

자체 관리형 VMware GA, 무엇이 새로워졌나

Google Cloud는 2026년 10월 28일 VMware solution on Google Cloud의 정식 출시(GA)를 발표했다. 전용 Compute Engine 베어메탈 ESXi 노드를 고객 프로젝트에 배치하고 VPC 네트워크에 연결해 VMware Cloud Foundation(VCF)을 직접 설치·운영하는 모델이다.

이미 제공하던 Google Cloud VMware Engine은 Google이 핵심 VMware 스택을 관리하는 방식이다. 이번 출시는 그 관리형 서비스를 종료하거나 일괄 업그레이드한 것이 아니라, 기업이 가상화 운영 방식과 유지보수 일정을 더 직접 통제하도록 선택지를 넓힌 조치다.

이전 계획에서 가장 먼저 따질 것은 클라우드라는 위치가 아니라 운영 책임이다. VM이 자동으로 이전되거나 기존 데이터센터 운영 비용이 곧바로 줄어드는 것은 GA 발표만으로 보장되지 않는다.

VMware Engine과 자체 관리형, 누가 무엇을 관리하나

관리형 Google Cloud VMware Engine에서는 Google이 vSphere·vSAN·NSX 등 주요 VMware 구성요소의 관리와 업데이트를 맡는다. 자체 관리형에서는 고객 또는 별도 계약한 운영 파트너가 VCF 소프트웨어의 배포, 설정, 패치와 워크로드 관리를 책임진다. Google Cloud는 물리 시설·베어메탈 서버 하드웨어와 하이퍼바이저 아래의 기반 네트워크 인프라를 담당한다.

자체 관리형의 ESXi·vCenter·NSX 관리자 수준 접근은 유지보수 시간과 도구 통합의 선택 폭을 넓힌다. 반대로 보안 취약점 대응, 권한 통제, 업그레이드 검증에 필요한 인력과 절차도 고객 몫이 된다. “관리 권한이 많다”는 장점과 “운영 부담이 높다”는 비용을 함께 비교해야 한다.

라이선스 설명에도 주의가 필요하다. 공식 출시 블로그의 비교표와 별도 기술 비교 문서가 기존 관리형 상품의 BYOL 여부를 다르게 표현하고 있어, 그 상품의 라이선스 포함 여부를 일률적으로 확정하지 않았다. 실제 계약 조건은 별도로 확인해야 한다.

VCF 9.x와 BYOL, 라이선스부터 확인해야 하는 이유

새로운 자체 관리형은 VMware Cloud Foundation 라이선스를 고객이 제공하는 BYOL(Bring Your Own License) 모델이다. 따라서 구독의 이동 가능 조건, 기존 계약 범위, Broadcom 지원 자격과 버전 호환성을 구축 이전에 확인해야 한다. Google Cloud 인프라를 사용한다고 VCF 구독료가 자동으로 포함되는 것은 아니다.

Google의 출시 발표는 VCF 9.x를 새 모델의 주요 배경으로 제시하며 일부 9.1 환경을 기준으로 비교한다. 이를 모든 지역·노드에서 9.1을 곧바로 이용하거나 기존 VCF 환경에서 무중단 업그레이드할 수 있다는 뜻으로 해석해서는 안 된다. 기존 호스트·관리 구성요소·소프트웨어 저장소의 호환성을 개별 검증해야 한다.

Z3 베어메탈 사양과 비용, 발표 숫자를 읽는 법

공식 릴리스 노트에 기재된 대표 노드는 z3-highmem-192-highlssd-metal이다. Google의 사양 자료 기준 이 구성은 96개 물리 CPU 코어(192 하드웨어 스레드), 1,536GiB 메모리, 72,000GiB 로컬 SSD를 제공한다. 실제 사용 가능 용량과 클러스터 설계는 vSAN 보호 정책과 장애 대비 용량에 따라 달라진다.

발표 자료의 최대 200Gbps 네트워크 수치는 조건에 따른 상한 표현으로 이해해야 한다. 모든 워크로드에 보장되는 실측 전송 속도가 아니다. Google이 소개한 서버 또는 스토리지 TCO 절감 수치 역시 공급사 비교 가정에 기반한 주장으로, 자체 검증된 보편적 절감률은 아니다.

한국 기업이 도입 전 확인할 다섯 가지

첫째, 실제 사용 리전과 존을 확인한다. Google은 출시 당시 22개 리전에 제공한다고 발표했지만, 이 숫자만으로 서울 리전(asia-northeast3)의 해당 베어메탈 머신 타입 가용성을 확정할 수 없다. 프로젝트 쿼터와 존별 배포 가능 여부를 별도로 확인해야 한다.

둘째, 라이선스 계약과 VCF 버전 호환성을 점검한다. 셋째, 운영팀의 패치·모니터링·관리자 권한 통제 프로세스를 정의한다. 넷째, 게스트 VM뿐 아니라 vCenter 등 관리 구성요소의 백업 및 복구 책임, 목표 복구 시점(RPO)과 목표 복구 시간(RTO)을 계약·설계 수준에서 확정한다. 다섯째, 사내망과 VPC 사이 연결·마이그레이션 방법과 장애 시 지원 창구를 정리한다. 이는 실무 권고이며 제품의 자동 제공 기능을 뜻하지 않는다.

Google은 Terraform과 전용 툴킷을 이용한 노드 준비·네트워크 설정·VCF 배포 절차를 문서화했다. 그러나 자동화 수단이 존재한다는 사실만으로 모든 고객 환경의 이전 성공이나 무중단 운영을 보장하지는 않는다. 운영 책임을 직접 감당할 팀이 있는지부터 판단하는 것이 합리적이다.