Compute Engine vs GKE vs Cloud Run: 소규모 서비스 비용 비교와 선택 기준

컨테이너로 만든 작은 API 하나를 배포하려는데, Compute Engine·GKE·Cloud Run 중 어떤 구성이 비용에 유리할까? 요청이 적으면 사용한 만큼만 내는 방식이 유리해 보이지만, 접속 지연을 줄이려고 인스턴스를 유지하거나 도메인을 연결하면 추가 비용이 생긴다.

접속이 드문 API, 계속 실행하는 서비스, 이미 Kubernetes를 사용하는 환경은 유리한 선택이 다르다. 아래에서는 트래픽 패턴별 비용과 상시 실행 비용을 계산해, 어떤 조건에서 비용이 역전되는지 살펴본다. 배포·HTTPS·롤백에 필요한 작업도 선택 기준으로 함께 확인한다. 금액은 공개 단가와 가정에 따른 계산 예시다.

1. 비교 조건: 서울 리전의 컨테이너 API 한 개

#

Compute Engine은 VM, GKE(Google Kubernetes Engine)는 관리형 Kubernetes, Cloud Run은 관리형 애플리케이션 실행 플랫폼이다. 세 서비스에 동일한 컨테이너 HTTP API를 배포한다고 가정한다. DB와 업로드 파일은 별도 서비스에 저장하고, 컨테이너 이미지는 이미 준비되어 있다.

GKE의 Pod는 컨테이너를 배포·실행하는 단위다. 이 글에서는 API용 Pod 한 개에 자원을 할당한다. 같은 2vCPU·4GiB라도 VM에는 OS·런타임 사용량이 포함되므로 동일 성능 비교는 아니다. VM 한 대와 Pod 한 개는 고가용성 구성도 아니다.

Cloud Run·GKE 정책과 단가는 2026년 10월 28일 공식 가격표 확인 기준이다. VM·디스크·IPv4는 기존 GCP VM 비용 글의 2026년 10월 16일 서울 견적을 사용했다. 실제 배포 전에는 계산기의 리전·과금 방식을 다시 확인한다.

아래 기본비는 최종 서비스 요금이 아니라 실행 환경의 비용이다. VM은 디스크·IPv4까지 포함하지만 GKE의 외부 공개용 LB는 포함하지 않아, 세 구성의 공개 경로까지 동일한 조건은 아니다. DB, 인터넷 아웃바운드(이그레스), 빌드·이미지 저장, 로그, DNS, 백업, VPC 연결도 별도다. 외부 공개와 커스텀 도메인은 5절에서 비교한다.

2. 접속이 없을 때: 계속 확보한 자원에는 비용이 든다

#

VM과 상시 실행 Pod는 요청이 없어도 자원을 유지한다. 반면 최소 인스턴스가 0인 Cloud Run은 요청이 없을 때 인스턴스를 0개까지 줄일 수 있다. 먼저 이 차이가 기본비에 어떻게 반영되는지 보자.

Cloud Run의 $0는 위 비교 조건의 실행비이며, 프로젝트 전체가 무료라는 뜻은 아니다. 이미지 보관·DB 등 별도 리소스 비용은 남을 수 있다.

GKE: 클러스터 무료와 Pod 무료는 다르다

#

서울의 일반용 Autopilot Pod 단가로 vCPU 시간당 $0.0571, 메모리 GiB·시간당 $0.0063215, 임시 스토리지 GiB·시간당 $0.0001784를 사용했다.

Pod 실행비
(2 × $0.0571 + 4 × $0.0063215 + 1 × $0.0001784) × 730
= 약 $101.96

클러스터 관리비
$0.10 × 730 = $73.00

결제 계정당 월 $74.40의 GKE 무료 크레딧은 Autopilot 또는 zonal Standard 클러스터 관리비에 적용된다. 다른 클러스터에서 사용하지 않았다면 이 예시의 $73은 충당되지만, Pod 실행비까지 없어지지는 않는다. Standard에서는 노드 VM 요금을 계산하므로 이 Autopilot 예시와 구분한다. GKE 가격표

Pod의 CPU·메모리·임시 스토리지는 명시적으로 설정한다. 기본값이나 최소 자원 보정으로 실제 요청량이 달라지면 비용도 달라진다. 요청이 없다고 상시 실행 Pod의 자원 요청량이 자동으로 0이 되는 것도 아니다. Autopilot 리소스 요청량

기존 클러스터의 여유 자원을 활용하는 경우에는 클러스터를 새로 만드는 이 표와 비용 구조가 다르다. 특히 Standard의 이미 확보한 노드 여유 공간에 Pod를 추가하는 경우와, Autopilot의 Pod 자원 과금을 동일하게 보지 않는다.

3. 요청이 들어올 때: 같은 100만 회도 비용이 다르다

#

VM과 GKE가 처음 확보한 자원으로 요청을 감당한다면 기본비는 유지된다. Cloud Run은 요청을 처리하는 인스턴스의 과금 시간에 따라 실행비가 늘어난다. 월 요청 수뿐 아니라 처리 시간과 실제 동시 처리량을 알아야 하는 이유다.

모든 요청의 처리 시간은 0.2초라고 가정한다. 아래는 요청 겹침의 효과를 보기 위해 시작·종료·추가 확장 시간은 제외한 단순 모델이며, 실제 부하 측정 결과는 아니다. 따라서 표의 금액은 요청 처리분의 계산값이며 실제 청구액을 보장하지 않는다.

GKE는 관리비 무료 크레딧이 전부 남은 경우다. VM 한 대와 Pod 한 개가 부하를 감당한다고 가정했으며, 추가 자원이 필요하면 비용도 늘어난다. 외부 LB·DB·아웃바운드(이그레스) 등 앞서 제외한 항목은 이 표에도 합산하지 않았다.

B는 100만 × 0.2초 = 200,000초, C는 100만 ÷ 10 × 0.2초 = 20,000초로 계산했다. C는 동시 처리 설정을 10으로 바꾸면 무조건 10배 저렴해진다는 뜻이 아니다. I/O 대기가 많고, 애플리케이션이 실제로 요청 10개를 같은 시간에 처리할 수 있다는 가정이다. CPU 연산이 많으면 처리 시간이 길어지거나 인스턴스가 추가될 수 있다. Cloud Run 동시 요청 처리

이 예시에서 Cloud Run이 저렴한 이유는 합산 과금 시간이 월 730시간보다 훨씬 짧기 때문이다. 요청이 집중되더라도 항상 비용이 내려가지는 않는다. 피크에 필요한 인스턴스 수와 시작 시간을 함께 측정해야 한다.

계산 근거: 서울 단가와 무료 사용량

#

서울의 요청 기반 활성 단가는 다음과 같다.

2vCPU·4GiB에서는 과금 시간 1초당 $0.0000812다. 아래 T는 모든 인스턴스의 활성 과금 시간을 합친 값이며, 달력상 경과 시간이나 실제 CPU 연산 시간과 구분한다. Cloud Run 가격표: Seoul 선택

무료 사용량 적용 전 실행비
= T × (2 × $0.0000336 + 4 × $0.0000035)
  + 월 요청 수 ÷ 1,000,000 × $0.40

요청 기반 과금에는 시작·종료 시간도 포함되고, 과금 시간은 100ms 단위로 올림된다. 인스턴스 하나에서 겹쳐 처리한 요청은 CPU·메모리를 공유한다. 실제 계산에서는 관측한 합산 과금 시간을 사용한다. 과금 시간 설명

위 무료 적용 열은 결제 계정의 해당 무료분을 다른 서비스·프로젝트가 사용하지 않았다는 가정이다. CPU $4.32, 메모리 $0.90, 요청 200만 회를 각 항목에서 차감했다. 서울에 미국 기준 무료 초 수를 그대로 빼면 안 된다. 무료분은 Tier 1 단가의 할인액으로 적용되며, 항목 간 남은 할인액을 서로 옮기지 않는다. 무료 사용량 적용 기준

소량 사용까지 포함해 계산하려면 아래처럼 각 항목에서 무료분을 차감한다. max(값, 0)은 무료분보다 사용액이 작을 때 해당 요금을 0으로 처리한다는 뜻이다.

2vCPU·4GiB, 요청 기반, 무료분이 전부 남은 경우
N = 월 요청 수, T = 합산 활성 과금 시간(초)

CPU 요금    = max(T × 2 × $0.0000336 − $4.32, 0)
메모리 요금 = max(T × 4 × $0.0000035 − $0.90, 0)
요청 요금   = max(N − 2,000,000, 0) ÷ 1,000,000 × $0.40
실행비      = CPU 요금 + 메모리 요금 + 요청 요금

이 예시에서는 월 몇 회부터 VM보다 비싸질까?

#

앞의 B 조건인 요청당 0.2초·요청 겹침 없음을 유지하면, 무료분이 전부 남은 경우 다음과 같이 변한다.

이 조건에서는 월 약 401만 회, 무료분을 이미 소진했다면 약 365만 회에서 VM 기본비와 같아진다. 단, 요청이 겹치지 않는다는 가정에서는 실제 처리 시간이 두 배가 되면 CPU·메모리 과금도 두 배가 되므로 더 적은 요청 수에서 기준을 넘는다.

반대로 C처럼 10개 요청을 같은 인스턴스에서 0.2초에 완료할 수 있다면, 무료분이 남은 경우 계산상 기준은 약 3,295만 회까지 올라간다. 이 숫자는 성능 보장이나 공통 임계치가 아니라, 처리 시간과 실제 동시 처리량에 따라 비교 결과가 얼마나 달라지는지를 보여주는 값이다. VM도 해당 부하를 한 대로 처리할 수 있어야 이 비교가 유지된다.

두 계산은 같은 비용식을 사용한다. CPU·메모리·요청 무료분이 모두 차감되는 위 손익분기점 구간에서는 다음처럼 확인할 수 있다.

요청 겹침 없음, 요청당 0.2초
Cloud Run 비용 = 월 요청 수 × $0.00001664 − $6.02
VM과 같아지는 요청 수 = ($60.68 + $6.02) ÷ $0.00001664
                     ≈ 4,008,413회

여기서 $6.02는 CPU $4.32·메모리 $0.90·요청 $0.80의 합계다. 위 식은 손익분기점을 구하기 위한 간략식이며, 무료분을 전부 차감할 수 없는 소량 사용에는 앞의 항목별 계산식을 적용한다.

4. 인스턴스를 항상 유지하면 비교 결과가 달라진다

#

앞의 세 시나리오는 모두 요청 처리 시간이 짧은 경우다. 서비스가 하루 종일 실행 자원을 사용한다면 Cloud Run이 더 저렴하다는 결론은 달라질 수 있다.

730시간 계속 실행하는 경우

#

이번에는 Cloud Run HTTP 서비스를 인스턴스 기반 과금으로 바꾸고, 2vCPU·4GiB 한 개를 730시간 유지한다고 가정한다. 이 방식은 요청별 요금 없이 인스턴스 수명 전체에 과금한다. 서울 단가는 vCPU·초당 $0.0000216, 메모리 GiB·초당 $0.0000024다.

인스턴스 기반 과금으로 바꾸는 것만으로 항상 한 개가 유지되는 것은 아니다. 이 계산은 최소 인스턴스 등의 설정으로 한 개를 유지하고, 부하에 따른 추가 확장은 없다는 조건이다.

Cloud Run 인스턴스 기반 실행비
(2 × $0.0000216 + 4 × $0.0000024) × 730 × 3,600
= 약 $138.76

Cloud Run 무료 적용 열은 인스턴스 기반 무료분의 CPU $4.32·메모리 $0.90를 차감한 값이다. VM은 디스크·IPv4를 포함하고 GKE·Cloud Run은 앞서 정의한 실행 자원 기준이며, DB·외부 LB·전송 비용은 별도다. 이 표 역시 동일 성능이나 가용성을 보장하는 비교는 아니다. 과금 방식, 서울 단가와 무료 적용 기준

이 상시 실행 예시에서는 VM이 더 저렴하다. Cloud Run은 서버 구성 작업을 줄여주는 편의성이 있지만, 그 편의성이 항상 실행비 절감까지 의미하지는 않는다. GKE도 실행비만으로 선택하기보다는 필요한 Kubernetes 기능과 기존 환경을 함께 봐야 한다.

인스턴스 기반 과금의 시간당 실행비는 $0.0000528 × 3,600 = $0.19008이다. 합산 인스턴스 시간이 월 약 319시간이면 무료 적용 전 비용이 VM의 $60.68과 같아진다. 해당 무료분이 전부 남았다면 약 347시간이다. 인스턴스 두 개를 1시간 실행하면 합산 2시간으로 계산한다.

따라서 월 730시간 내내 자원이 필요한 HTTP 서비스라면 VM 견적을 우선 비교할 근거가 있다. 이는 이 글에서 선택한 Cloud Run HTTP 서비스의 인스턴스 기반 과금에 대한 계산이며, 별도 요금 체계인 Jobs·worker pools·Cloud Run instances에 그대로 적용하지 않는다.

최소 인스턴스만 유지하는 경우와 구분하기

#

Cloud Run은 인스턴스가 0개인 상태에서 새 요청을 받으면 컨테이너를 시작해야 한다. 이때 발생하는 초기 지연을 콜드 스타트라고 한다. 영향을 줄이려고 최소 인스턴스를 1로 두면 요청이 없어도 유지비가 생긴다.

서울 요청 기반 유휴 단가로 2vCPU·4GiB 한 개를 730시간 유지하면 무료분 적용 전 약 $55.19다. 활성 시간이 생기면 해당 시간에는 활성 단가가 적용된다. 최소 인스턴스 0에서 계산한 앞의 금액과 구분해야 한다. 최소 인스턴스 설정, 유휴 단가

요청 외 시간에도 CPU를 사용하는 백그라운드 작업이 있다면 인스턴스 기반 과금 등 실행 방식부터 다시 비교한다. 접속이 드문 API의 계산 결과를 상시 실행 작업에 그대로 적용할 수는 없다. Cloud Run 과금 방식

VM 한 대에서 여러 서비스를 운영한다면

#

작은 API·관리자 페이지·배치 작업을 한 VM에 함께 배치하고도 자원이 남는다면, 각각을 별도로 상시 실행하는 구성보다 비용을 줄일 여지가 있다. 다만 서비스 수만큼 CPU·메모리가 무료로 늘어나는 것은 아니다. 전체 사용량이 VM의 자원 안에 들어가는지 확인하고, 같은 VM의 장애가 여러 서비스에 동시에 영향을 주는 점도 고려한다.

5. 배포·HTTPS·롤백: 어디까지 기본으로 제공할까?

#

비용만큼 중요한 것은 이미지를 준비한 뒤 접속 가능한 서비스를 만들기까지의 작업이다. 기본 HTTPS로 바로 시작하는 경우와 커스텀 도메인을 연결하는 경우를 나눠 비교한다.

Cloud Run은 기본 HTTPS와 리비전별 트래픽 전환을 제공해 API 한 개를 빠르게 공개하기 편하다. DB 스키마나 외부 데이터 변경까지 이전 상태로 되돌려 주는 기능은 아니므로, 세 방식 모두 데이터 변경의 호환성을 따로 고려한다. Cloud Run 배포·롤백

서울의 Cloud Run 커스텀 도메인 주의점

#

Cloud Run의 기본 run.app HTTPS 주소와 커스텀 도메인은 구분해야 한다. 직접 Domain mapping은 지원 리전이 제한된 Preview 기능이며, 확인 시점에 서울은 지원 목록에 없다. 공식 문서는 프로덕션에 이 기능을 권장하지 않고, 글로벌 외부 Application Load Balancer나 Firebase Hosting 같은 다른 연결 방식을 안내한다. 커스텀 도메인 연결 조건

외부 LB를 선택하면 전달 규칙 비용만으로도 $0.025 × 730 = 월 $18.25가 추가될 수 있다. 이는 전체 LB 요금이 아니며 데이터 처리·관련 네트워크 비용은 별도다. Firebase Hosting도 Cloud Run 연결 조건과 전송·저장 한도를 따로 확인해야 한다. 외부 LB 요금

GKE에 외부 LB로 API를 공개하는 경우에도 이 비용 항목을 더한다. 반면 VM 한 대에서 직접 HTTPS를 처리하는 구성은 외부 LB를 생략할 수 있지만 인증서 갱신·프록시 설정을 직접 구성해야 한다. 실행비가 $0에 가까운 구성도 커스텀 도메인 경로를 더하면 총비용이 달라진다.

아웃바운드(이그레스)와 VPC 비용도 따로 계산하기

#

동일 API라도 사용자에게 보내는 응답 크기에 따라 데이터 전송 비용이 달라진다. Cloud Run의 인터넷 아웃바운드(이그레스)는 Premium 기준이며, 기존 VM 글에서 사용한 Standard 무료 전송량을 그대로 적용하지 않는다. 월 요청 수와 함께 실제 전송 GiB를 추정해야 한다. Cloud Run 네트워크 요금

비공개 DB 연결에 VPC 연결을 추가한다면 Direct VPC egress 또는 커넥터 등 선택한 방식의 비용·제약도 확인한다. 이 글에서는 연결 방식을 확정하지 않았으므로 관련 금액을 기본비에 포함하지 않았다.

6. 소규모 서비스라면 이렇게 선택한다

#

GKE를 단지 컨테이너를 실행하기 위한 첫 선택으로 삼을 필요는 없다. 반대로 이미 여러 서비스를 Kubernetes로 배포하고 있다면, API 하나를 추가하는 편의성과 비용은 새 클러스터를 만드는 예시와 달라질 수 있다.

요청 사이에 자원을 줄일 수 있다면 Cloud Run, 자원을 계속 쓰거나 여러 서비스를 한 서버에 배치한다면 Compute Engine의 비용상 이점을 먼저 확인한다. Kubernetes 기능이 필요하거나 기존 클러스터를 활용할 수 있다면 GKE의 추가 비용과 배포 편의성을 비교한다.

최종 견적에는 도메인·DB 연결·아웃바운드(이그레스)를 더한다. 그다음 HTTPS·확장·롤백에 필요한 설정 작업까지 비교하면, 실행비를 낮출 것인지 배포 편의성에 비용을 지불할 것인지 판단하기 쉬워진다.

Cloud Run을 사용 중이라면 실제 합산 과금 시간과 요청 수로 계산을 갱신한다. 설정한 최소 인스턴스 수가 늘거나 실행비가 VM 견적에 가까워지는 시점이 과금 방식과 배포 위치를 다시 검토할 때다. 무료분·도메인·전송 비용까지 같은 조건으로 맞춘 뒤 결정한다.