컴퓨팅 옵션이 너무 많아 보이는 이유
Google Cloud를 처음 접하는 엔지니어가 가장 먼저 느끼는 혼란은 "어떤 컴퓨팅 서비스를 써야 하는가"입니다. Compute Engine, GKE, GKE Autopilot, App Engine Standard, App Engine Flexible, Cloud Run, Cloud Functions. 이름만 나열해도 일곱 가지입니다. 이름이 낯설고 경계가 모호하게 느껴지지만, 두 축으로 정리하면 전체 그림이 보입니다.
첫 번째 축은 제어 수준입니다. "OS까지 내가 직접 관리할 것인가, 아니면 코드만 올릴 것인가." 두 번째 축은 실행 단위입니다. "VM 전체를 띄울 것인가, 컨테이너를 실행할 것인가, 함수 하나를 호출할 것인가."
| 제어 수준 | VM | 컨테이너 | 함수 | |---------|-----|---------|------| | 높음 (직접 관리) | Compute Engine | GKE Standard | — | | 중간 (관리형) | — | GKE Autopilot / App Engine Flex | — | | 낮음 (서버리스) | — | Cloud Run / App Engine Standard | Cloud Functions |
이 표를 머릿속에 고정하면 나머지는 각 서비스의 세부 특성을 채워 넣는 작업이 됩니다. 시험에서 출제되는 문제의 80% 이상은 이 두 축에서 파생됩니다.
---
Compute Engine: 가장 유연한 IaaS의 본질
Compute Engine은 GCP의 핵심 IaaS 서비스입니다. VM 하나를 완전히 제어할 수 있다는 것이 가장 큰 특징입니다. OS 선택, JVM 버전 고정, 커널 파라미터 조정, 특수 라이브러리 설치, 포트 바인딩 설정 — 온프레미스 서버에서 할 수 있는 모든 것을 동일하게 할 수 있습니다.
시험에서 Compute Engine이 정답인 상황의 신호는 두 가지입니다. 하나는 "코드 수정 없이 그대로 이전"이라는 Lift-and-Shift 요구사항입니다. 레거시 Java 애플리케이션이 특정 JVM 옵션(-Xms, -Xmx)과 특수 라이브러리 버전에 강하게 의존한다면 App Engine이나 Cloud Run의 런타임 제약 때문에 이전이 불가능합니다. 이럴 때 Compute Engine이 유일한 선택입니다. 다른 하나는 "물리 서버 독점 격리" 요구사항인데, 이 경우 Sole-tenant Node를 조합합니다.
머신 유형 선택 전략
| 머신 패밀리 | 시리즈 예시 | 주요 사용 사례 | |-----------|-----------|-------------| | 범용 (General-purpose) | N2, E2, N1 | 웹 서버, 개발 환경, 중간 규모 DB | | 컴퓨트 최적화 (Compute-optimized) | C2, C2D | 고성능 컴퓨팅, 게임 서버, 과학 시뮬레이션 | | 메모리 최적화 (Memory-optimized) | M2, M3 | SAP HANA, 대용량 인메모리 DB | | 가속기 최적화 (Accelerator-optimized) | A2, G2 | ML 학습, GPU 추론, 렌더링 | | 스토리지 최적화 (Storage-optimized) | Z3 | 고성능 로컬 SSD, Spanner 등 |
Custom Machine Type은 사전 정의 머신 유형으로 정확한 리소스 조합을 맞출 수 없을 때 씁니다. E2는 vCPU 1개 단위, N1/N2는 2개 단위로 증가하며 메모리는 256MB 단위로 조정합니다. vCPU당 기본 메모리 한도를 초과해야 한다면 Extended Memory 옵션을 추가합니다.
Spot VM: 비용 절감의 핵심
Spot VM은 On-demand 대비 최대 91% 할인이지만 Google이 자원 회수 시 30초 전 알림 후 종료합니다. 배치 처리, ML 학습, 렌더링처럼 체크포인트 재시작이 가능한 작업에 최적입니다. Committed Use 할인(1~3년 약정, 20~57% 할인)은 상시 실행 워크로드에 유리하고 간헐적 배치에는 비효율적입니다.
Managed Instance Groups과 자동 확장
Managed Instance Group(MIG)은 동일한 VM 템플릿으로 여러 인스턴스를 묶어 관리하는 구조입니다. CPU 사용률이나 Cloud Pub/Sub 구독 backlog를 기준으로 인스턴스 수를 자동 조절합니다. 요청이 수십만 건 몰리는 상황에서는 Pub/Sub가 메시지를 내구성 있게 수신하고(최대 7일 보존, ACK 전 삭제 없음), MIG가 backlog 기준으로 VM을 확장하는 패턴이 효과적입니다.
---
Google Kubernetes Engine: 컨테이너 오케스트레이션의 표준
GKE는 Kubernetes 클러스터를 GCP에서 관리형으로 제공하는 서비스입니다. 컨테이너화된 워크로드를 대규모로 운영할 때 가장 강력한 선택지이지만, 그만큼 운영 복잡도도 높습니다.
애플리케이션이 컨테이너로 패키징되어 있거나 마이크로서비스 구조라면 GKE를 고려합니다. 단일 모놀리식 앱을 그대로 이전한다면 컨테이너화 오버헤드 없이 Compute Engine이 낫습니다.
GKE Standard는 노드 풀을 직접 구성하고 DaemonSet, 커스텀 네트워크 정책 등 Kubernetes 고급 기능이 필요할 때 적합합니다. GKE Autopilot은 Pod 수준에서 리소스를 선언하면 Google이 노드 프로비저닝, 스케일링, 업그레이드를 모두 처리합니다. 과금도 노드 VM 시간이 아니라 실제 Pod 리소스 요청량 기준이라 유휴 노드 비용이 없습니다.
GKE HPA는 최소 1 Pod를 유지하므로 트래픽이 없어도 비용이 발생합니다. 완전한 scale-to-zero가 필요하다면 Cloud Run을 검토합니다.
---
App Engine과 Cloud Run: 서버리스 컨테이너 두 갈래
App Engine과 Cloud Run은 둘 다 PaaS 서버리스 서비스입니다. 개발자는 OS 패치나 서버 프로비저닝 없이 코드(App Engine) 또는 컨테이너 이미지(Cloud Run)만 제공하면 됩니다. 설계 철학의 차이가 선택 기준입니다.
App Engine Standard vs App Engine Flexible
| 구분 | App Engine Standard | App Engine Flexible | |------|--------------------|-----------------------| | 런타임 | 제한된 런타임 (Python, Java, Node.js, Go, PHP, Ruby) | 커스텀 Docker 컨테이너 | | Scale-to-zero | 지원 (트래픽 없을 때 인스턴스 0) | 미지원 (최소 1인스턴스) | | 콜드 스타트 | 있음 | 없음 (상시 실행) | | 과금 | 인스턴스 시간 (유휴 무료) | VM 시간 (최소 1분) | | 네트워크 제한 | 일부 제한 | 제한 없음 | | 적합한 상황 | 간헐적 트래픽, 표준 런타임 | 커스텀 바이너리, 상시 서비스 |
App Engine Standard의 가장 큰 장점은 scale-to-zero로 트래픽이 없는 시간대 비용이 0이 됩니다. 단, 특수 JVM 설정이나 커스텀 라이브러리는 샌드박스 제약으로 지원이 어렵습니다.
Cloud Run의 핵심 특성
Cloud Run은 시험에서 가장 자주 정답으로 등장하는 서비스 중 하나입니다. 핵심은 scale-to-zero, 요청 기반 과금(밀리초 단위), 컨테이너 이식성 세 가지입니다. 대형 이벤트 발표 직후 수십 배 트래픽이 급증하는 티켓 판매 사이트처럼 변동성이 극단적인 워크로드에 최적입니다. 콜드 스타트가 우려된다면 min-instances 설정으로 최소 인스턴스 수를 유지하면 됩니다. Cloud Run vs App Engine Standard 선택이 헷갈린다면 "컨테이너 이미지를 올리는가, 코드 자체를 올리는가"로 구분합니다.
---
Cloud Functions: 이벤트 트리거 기반의 코드 단위 실행
Cloud Functions는 GCP의 FaaS 서비스입니다. 단일 함수 단위로 배포하고 이벤트 발생 시에만 실행됩니다. 서버 관리 없이 실행 횟수와 실행 시간에 따라서만 과금합니다.
Cloud Functions가 정답인 상황의 키워드: 서버 관리 없음, 사용량 기반 과금(유휴 0원), 간헐적 트래픽, 수초 이내 완료되는 단순 작업, HTTP/Pub/Sub/Cloud Storage 이벤트 트리거.
파트너사 주문 데이터가 하루 중 특정 시간에 몰려 들어오고 각 요청이 수초 내 단순 변환 작업이라면 Cloud Functions가 이상적입니다. App Engine Standard도 scale-to-zero를 지원하지만 단일 함수 이벤트 핸들링에서는 Cloud Functions가 더 세밀한 과금으로 비용 효율이 높습니다.
실행 시간 한도가 중요합니다. 1세대는 최대 9분, 2세대는 60분까지 실행 가능합니다. 수분 이상의 장기 실행이나 온프레미스 DB와의 지속 연결이 필요하면 Cloud Functions는 적합하지 않습니다. 함수 간 상태 공유는 Cloud Firestore나 Cloud Memorystore 같은 외부 저장소를 활용합니다.
---
다섯 가지 옵션 한눈에 비교하기
각 서비스의 특성과 워크로드별 추천을 종합합니다.
| 서비스 | 과금 기준 | Scale-to-zero | 운영 부담 | 적합한 워크로드 | |--------|---------|--------------|---------|---------------| | Compute Engine | 인스턴스 시간 | 없음 | 높음 | Lift-and-Shift, 레거시, 특수 런타임 | | GKE Standard | 노드 VM 시간 | 없음 | 높음 | K8s 고급 제어, 마이크로서비스 | | GKE Autopilot | Pod 리소스 요청량 | 없음 | 낮음 | K8s 관리 없이 컨테이너 | | App Engine Standard | 인스턴스 시간 | 있음 | 낮음 | 표준 런타임 웹 앱, 간헐적 트래픽 | | App Engine Flexible | VM 시간 | 없음 | 낮음 | 커스텀 런타임, 상시 서비스 | | Cloud Run | 요청 처리 시간 | 있음 | 매우 낮음 | 변동성 극단적, 컨테이너 서버리스 | | Cloud Functions | 호출 수 + 실행 시간 | 있음 | 최소 | 이벤트 기반, 수초 단위 단순 작업 |
무상태 워크로드는 Cloud Run, Cloud Functions, App Engine Standard와 잘 맞습니다. 세션 상태 유지, 로컬 파일 시스템 지속 쓰기, 장기 WebSocket 연결이 필요한 상태성 워크로드는 Compute Engine 또는 GKE를 선택합니다.
!GCP 컴퓨팅 옵션 5가지 비교
시험에서 헷갈리는 의사결정 시나리오
시험 문제는 대부분 "가장 적합한 서비스"를 묻는 형식입니다. 여러 서비스가 기술적으로 가능하더라도 특정 키워드가 정답을 가리킵니다.
시나리오 1: "운영 부담 최소화" + "컨테이너 기반"
GKE Standard는 오답입니다. 노드 풀 관리, 업그레이드, 패치가 여전히 사용자 몫이기 때문입니다. Cloud Run 또는 GKE Autopilot이 정답 후보입니다. 유휴 비용이 없어야 한다면 Cloud Run, 마이크로서비스 간 복잡한 내부 통신이나 사이드카 패턴이 필요하다면 GKE Autopilot을 선택합니다.
시나리오 2: "사용량 기반 과금" + "서버 관리 없음"
Cloud Functions 또는 Cloud Run입니다. 여러 HTTP 엔드포인트를 가진 API 서버라면 Cloud Run, 특정 이벤트에 반응하는 단일 로직이라면 Cloud Functions입니다.
시나리오 3: "scale-to-zero" + "예측 불가능한 트래픽 급증"
Cloud Run의 정답 패턴입니다. App Engine Standard도 scale-to-zero를 지원하지만 컨테이너 이미지가 언급되거나 유연성이 강조되면 Cloud Run이 선호됩니다.
시나리오 4: "코드 수정 없이 이전" + "특수 런타임 의존성"
Compute Engine이 유일한 정답입니다. "특수 JVM 설정", "커스텀 바이너리", "온프레미스와 완전히 동일한 환경" 문구가 나오면 Compute Engine을 선택합니다.
시나리오 5: "비용 최소화" + "중단 허용" + "배치 작업"
Compute Engine Spot VM 패턴입니다. 체크포인트 재시작이 가능한 ML 학습, 렌더링, 빅데이터 처리에 Spot VM으로 최대 91% 비용 절감이 가능합니다. Committed Use 할인(1~3년 약정)은 상시 실행에 유리하고 간헐적 배치에는 비효율적입니다.
시나리오 6: "대량 요청 유실 없이" + "자동 처리 용량 조절"