VM 한 대를 띄우는 일이 결코 간단하지 않은 이유
Google Cloud Console에서 VM 인스턴스를 생성하는 데 걸리는 시간은 1분이 채 안 됩니다. 그러나 그 단순한 화면 뒤에는 머신 유형, 부팅 디스크, 네트워크 태그, 서비스 계정, 시작 스크립트, 가용성 정책, 유지보수 동작에 이르기까지 수십 가지 결정이 숨어 있습니다. 개발 환경에서는 기본값으로 충분하지만, 프로덕션에서 이 선택들이 비용, 보안, 가용성을 직접 결정합니다.
GCP-ACE 시험은 "VM을 어떻게 만드는가"가 아니라 주어진 요구사항에서 어떤 옵션 조합이 가장 적절한가를 집중적으로 묻습니다. 이 글에서는 시험에 나오는 핵심 Compute Engine 개념들을 실무 운영 관점으로 정리합니다.
---
인스턴스 생성 옵션과 머신 유형 선택
VM을 생성할 때 가장 먼저 결정해야 할 것은 머신 유형(Machine Type)입니다. Compute Engine은 사전 정의 머신 유형과 커스텀 머신 유형 두 가지를 제공합니다.
| 머신 패밀리 | 용도 | 특징 | |------------|------|------| | E2 | 범용 (비용 최적화) | 선점형 처리, 저비용 웹서버, 개발 환경 | | N2/N2D | 범용 (균형) | 중간 규모 애플리케이션, 데이터베이스 | | C2/C3 | 컴퓨팅 최적화 | HPC, 게임 서버, 고성능 처리 | | M1/M2/M3 | 메모리 최적화 | 인메모리 DB, SAP HANA, 대형 분석 | | A2/A3 | 가속기 최적화 | ML 학습, GPU 집약적 워크로드 | | T2D | Tau (비용 효율) | 스케일아웃 워크로드, 웹 서빙 |
커스텀 머신 유형은 vCPU와 메모리를 독립적으로 조정할 수 있어 사전 정의 유형에 맞지 않는 워크로드의 비용을 최적화합니다.
인스턴스 생성 시 자주 사용하는 주요 옵션을 정리하면 다음과 같습니다.
| 옵션 | 설명 | 주의사항 | |------|------|----------| | 네트워크 태그 | 방화벽 규칙 적용 대상 지정 | 태그 오타 시 방화벽 규칙 미적용 | | 서비스 계정 | VM에서 GCP API 호출 권한 부여 | 기본 서비스 계정 사용 지양 | | 시작 스크립트 | 인스턴스 부팅 시 자동 실행 | 메타데이터 서버에서 가져오기 가능 | | 가용성 정책 | 선점 허용 여부, 재시작 동작 | Spot VM은 always 재시작 불가 | | 유지보수 동작 | 호스트 유지보수 시 라이브 마이그레이션 or 종료 | GPU 인스턴스는 라이브 마이그레이션 불가 |
시작 스크립트는 메타데이터 키 에 직접 입력하거나, 로 Cloud Storage의 스크립트 파일을 가리킬 수 있습니다. 인스턴스 내부에서는 메타데이터 서버를 통해 인스턴스 ID, 존, 프로젝트 ID 같은 정보를 런타임에 조회할 수 있습니다.
---
영구 디스크와 스냅샷 — 데이터 라이프사이클
Compute Engine의 스토리지는 VM 라이프사이클과 독립적으로 관리됩니다. VM을 삭제해도 영구 디스크(Persistent Disk)는 기본적으로 유지되지만, 부팅 디스크는 함께 삭제됩니다. 이 차이가 시험의 핵심 함정입니다.
영구 디스크 종류
| 디스크 유형 | IOPS (최대) | 처리량 | 비용 | 주요 용도 | |------------|------------|--------|------|----------| | Standard HDD (pd-standard) | 낮음 | 낮음 | 가장 저렴 | 콜드 데이터, 백업 | | Balanced (pd-balanced) | 중간 | 중간 | 중간 | 범용 애플리케이션 | | SSD (pd-ssd) | 높음 | 높음 | 높음 | 데이터베이스, 고성능 | | Extreme (pd-extreme) | 매우 높음 | 매우 높음 | 가장 고가 | 고성능 DB, 실시간 분석 |
Extreme 디스크는 IOPS를 직접 프로비저닝하는 방식으로, 일반 웹 애플리케이션에는 과도하며 SAP, Oracle 같은 대형 데이터베이스에 사용합니다.
스냅샷 vs 머신 이미지 vs 사용자 정의 이미지
세 가지 백업·복제 방식의 차이를 명확히 구분해야 합니다.
| 방식 | 포함 범위 | 위치 | 주요 용도 | |------|----------|------|----------| | 스냅샷 | 단일 디스크 | 글로벌 | 증분 백업, 디스크 복제 | | 머신 이미지 | 모든 디스크 + VM 설정 | 글로벌 | VM 전체 복제, DR | | 사용자 정의 이미지 | 부팅 디스크 OS 상태 | 글로벌 | 표준 기반 이미지, 템플릿 기반 |
시험 함정: 스냅샷은 글로벌 리소스로 리전에 종속되지 않습니다. 반면 영구 디스크 자체는 존(Zone) 리소스입니다. 리전 간 디스크 이전이 필요하면 스냅샷을 만든 뒤 대상 리전에서 새 디스크를 생성해야 합니다. 부팅 디스크는 기본적으로 VM 삭제 시 함께 삭제되므로, 데이터 보존이 필요하면 이 옵션을 명시적으로 해제해야 합니다.
!스냅샷 vs 머신 이미지 vs 커스텀 이미지
인스턴스 템플릿과 관리형 인스턴스 그룹(MIG)
Compute Engine에서 확장성과 가용성을 확보하는 핵심은 관리형 인스턴스 그룹(Managed Instance Group, MIG)입니다. MIG는 인스턴스 템플릿을 기반으로 동일한 VM 집합을 관리합니다. 템플릿은 머신 유형, 부팅 디스크, 네트워크 태그, 서비스 계정 등을 미리 정의하는 불변 청사진으로, 수정 불가하며 변경 시 새 버전을 생성해야 합니다.
Zonal MIG vs Regional MIG
| 구분 | Zonal MIG | Regional MIG | |------|-----------|-------------| | 인스턴스 배포 | 단일 존 | 리전 내 최대 3개 존 분산 | | 가용성 | 단일 존 장애 시 전체 중단 | 존 장애 시 다른 존에서 서비스 유지 | | SLA | 낮음 | 99.99% (다중 존) | | 리소스 부족 | 해당 존 부족 시 확장 불가 | 다른 존에서 자원 확보 가능 | | 적합한 워크로드 | 상태 저장, 단일 존 요구 | 상태 비저장, 고가용성 요구 |
MIG의 핵심 기능 세 가지는 자동 스케일링, 자동 복구(Autohealing), 롤링 업데이트입니다.
자동 스케일링은 CPU 사용률, HTTP 부하, Pub/Sub 큐 길이, Cloud Monitoring 커스텀 메트릭을 기반으로 VM 수를 조절합니다. 최솟값과 최댓값을 설정하여 비용 초과를 방지합니다.
Autohealing은 상태 확인(Health Check) 엔드포인트를 기반으로 동작합니다. VM이 HTTP/HTTPS/TCP 상태 확인에 일정 횟수 이상 실패하면 MIG가 해당 VM을 자동 삭제하고 새 인스턴스로 교체합니다. 시험에서 Cloud Monitoring 알림과 Autohealing을 혼동하지 마세요. 알림은 사람에게 통지하는 것이고, Autohealing은 자동 복구 액션을 취합니다. 수동 개입 없는 자동 복구 키워드가 나오면 반드시 MIG + Autohealing입니다.
롤링 업데이트는 새 인스턴스 템플릿으로 점진적으로 VM을 교체합니다. 로 동시 추가 인스턴스 수를, 로 동시 중단 인스턴스 수를 제어합니다. 카나리 배포를 위해 일부 인스턴스만 새 템플릿으로 업데이트하는 방식도 지원합니다.
---
Spot VM과 비용 절감 전략
Spot VM(구 Preemptible VM)은 GCP의 잉여 컴퓨팅 용량을 사용하는 대신 최대 60~91% 할인된 가격을 제공하는 인스턴스입니다. 단, 이 VM은 Google이 필요할 때 30초 사전 경고 후 강제 종료(선점)될 수 있습니다.
| 항목 | Spot VM | 일반 VM | |------|---------|--------| | 비용 | 최대 60~91% 절감 | 정가 | | 선점 가능성 | 있음 (30초 경고) | 없음 | | 최대 실행 시간 | 제한 없음 (언제든 선점 가능) | 제한 없음 | | 자동 재시작 | 불가 | 가능 | | 가용성 정책 | 또는 | 기본값 |
Spot VM은 인터럽트를 허용할 수 있는 배치 처리, 데이터 파이프라인, CI/CD 빌드, ML 학습에 적합합니다. 반드시 완료되어야 하는 트랜잭션이나 24시간 서비스에는 부적합합니다.
MIG에서 Spot VM과 일반 VM을 혼합하면 비용 최적화와 가용성을 동시에 확보할 수 있습니다. Spot VM이 선점되더라도 일반 VM이 기본 용량을 유지합니다.
비용 최적화의 또 다른 전략은 committed use discounts(약정 사용 할인)입니다. 1년 또는 3년 약정으로 vCPU와 메모리를 예약하면 최대 57%까지 할인됩니다. 이 할인은 특정 VM이 아닌 프로젝트 수준에서 적용되므로, 해당 리전에서 약정한 자원 양만큼 어떤 VM에서든 자동 적용됩니다.
---
OS Login과 인스턴스 보안의 기본기
Compute Engine VM에 SSH로 접속하는 방법은 SSH 키 메타데이터 방식과 OS Login 방식, 두 가지입니다.
| 구분 | SSH 키 메타데이터 | OS Login | |------|-----------------|----------| | 키 관리 | 수동 (메타데이터에 공개키 등록) | Google Cloud IAM 자동 연동 | | 감사 추적 | 제한적 | Cloud Audit Logs 완전 통합 | | 사용자 계정 | 로컬 Linux 계정 생성 | Google 계정 = Linux 계정 | | 조직 정책 연동 | 불가 | 가능 (IAM 역할 기반) | | sudo 권한 | 키 등록 시 별도 설정 | 역할 | | 키 폐기 | 수동으로 메타데이터에서 삭제 | IAM 접근 제거로 즉시 폐기 |
OS Login은 메타데이터를 인스턴스 또는 프로젝트 수준에서 설정하면 활성화됩니다. 이후 사용자는 (일반 접속) 또는 (sudo 권한 접속) IAM 역할이 필요합니다. 조직 수준 보안에는 OS Login이 훨씬 편리합니다. 직원 퇴사 시 Google 계정 비활성화만으로 모든 VM 접속이 자동 차단되며, 수백 개 VM의 메타데이터를 수동으로 수정할 필요가 없습니다.
Shielded VM과 Confidential VM
| 유형 | 보호 대상 | 주요 기능 | |------|----------|----------| | Shielded VM | 부팅 과정 무결성 | Secure Boot, vTPM, Integrity Monitoring | | Confidential VM | 메모리 내 데이터 | AMD SEV 기반 메모리 암호화 |
Shielded VM은 Secure Boot로 부팅 중 루트킷·부트킷을 방지합니다. Confidential VM은 실행 중 메모리 내 데이터를 암호화하여 하이퍼바이저조차 내용을 볼 수 없게 합니다. 두 기능 모두 금융·의료 분야의 규정 준수 환경에서 주로 사용합니다.
---
시험에서 자주 헷갈리는 운영 시나리오
라이브 마이그레이션과 호스트 유지보수
Google은 정기적으로 호스트 서버 유지보수를 수행합니다. 기본적으로 Compute Engine은 라이브 마이그레이션(Live Migration)을 통해 VM을 다른 호스트로 이동시키면서 VM이 계속 실행되도록 합니다. 그러나 GPU 인스턴스는 라이브 마이그레이션이 지원되지 않습니다. GPU가 연결된 VM은 유지보수 이벤트 발생 시 종료(Terminate)됩니다. 유지보수 동작 설정에서 를 선택하고, 유지보수 후 자동 재시작 옵션을 활성화해야 합니다.
VM 삭제 후 데이터 보존
| 리소스 | VM 삭제 시 기본 동작 | |--------|-------------------| | 부팅 디스크 | VM과 함께 삭제 (기본값) | | 추가 영구 디스크 | 유지 (기본값) | | 로컬 SSD | 삭제 | | 스냅샷 | 유지 (디스크와 독립) | | 외부 IP (에페머럴) | 해제 (반납) | | 외부 IP (정적) | 유지 (요금 부과) |
부팅 디스크 데이터를 보존하려면 VM 생성 또는 수정 시에 "삭제 시 삭제" 옵션을 해제해야 합니다. 로컬 SSD는 최고의 IOPS를 제공하지만 VM 종료 시 데이터가 유실되므로, 영속성이 필요한 데이터는 절대 로컬 SSD에 저장하지 마세요.
단일 존 리소스 부족 + 스냅샷 위치
신규 서비스 출시나 이벤트 트래픽 급증 시 특정 존의 리소스가 부족해 VM 확장이 실패할 수 있습니다. 이 경우 Regional MIG로 전환하면 해당 리전 내 다른 존에서 자원을 확보할 수 있습니다. 머신 유형 변경이나 수동 배포는 임시방편이며 근본 해결책이 아닙니다.
스냅샷은 글로벌 리소스입니다. 서울 존(asia-northeast3-a)에서 만든 스냅샷으로 도쿄 존(asia-northeast1-b)에 새 디스크를 생성할 수 있습니다. 데이터 전송 비용을 줄이려면 동일 리전 내 이동 시 해당 리전으로 스냅샷 저장 위치를 지정하는 것이 좋습니다.