구글 클라우드 플랫폼(Google Cloud)을 처음 열어보면 150개가 넘는 제품 목록부터 마주하게 됩니다. 그러나 개인 개발자나 소규모 사업자가 초기에 결정할 문제는 모든 제품을 이해하는 일이 아닙니다. 웹앱을 어디에 실행할지, 파일을 어디에 저장할지, 데이터베이스가 필요한지, 그리고 사용량 기반 과금을 어떻게 통제할지가 먼저입니다.
이 글은 홈페이지·소규모 웹앱·데이터 분석 환경을 시작하는 상황을 기준으로 대표 서비스를 구분하고, 무료 체험 이후에도 비용을 예측 가능하게 관리하는 방법을 정리합니다. 가격과 무료 한도는 바뀔 수 있으므로, 내용은 2026년 9월 17일 기준 공식 자료를 바탕으로 했으며 실제 배포 전에는 최신 가격표를 확인해야 합니다.
구글 클라우드 플랫폼이란? Google Drive·Workspace와 다른 점
Google Cloud는 애플리케이션을 만들고 운영하기 위한 클라우드 플랫폼입니다. 가상 머신, 컨테이너 실행 환경, 객체 저장소, 관리형 데이터베이스, 데이터 분석 도구, 보안과 개발 도구 등을 제공합니다. 즉, 개발·배포·데이터 처리용 인프라에 가깝습니다.
반면 Google Drive는 파일 보관과 공유에, Google Workspace는 문서·메일·협업에 초점이 맞춰진 서비스입니다. Drive에 파일을 올리는 일과 Cloud Storage 버킷에 서비스용 이미지·백업 파일을 저장하는 일은 목적과 과금 방식이 다릅니다. Google Cloud에서는 프로젝트를 만들고, 필요한 API와 리소스를 활성화하며, 결제 계정과 권한을 관리하게 됩니다.
인프라 위치도 선택 대상입니다. Google Cloud는 물리적 인프라를 universe, region, zone 구조로 나눕니다. 리전은 서비스 배치의 지리적 범위이고, 존은 리전 안의 배포 단위입니다. 선택한 위치는 사용자와의 지연 시간, 데이터 위치, 가용성, 일부 가격에 영향을 줄 수 있습니다. 서울 리전을 포함한 실제 지원 여부는 서비스별 문서에서 따로 확인하는 편이 안전합니다.
사용 목적별 핵심 서비스 지도: 서버·컨테이너·저장소·데이터베이스·분석
초기 구성에서는 아래 다섯 서비스를 구분해 두면 제품 목록에 압도되지 않습니다. 이들은 서로 대체재라기보다 역할이 다른 조합 요소입니다.
| 서비스 | 주 역할 | 선택할 상황 | 비용에서 볼 항목 |
|---|---|---|---|
| Compute Engine | 가상 머신(VM) | 운영체제와 서버 환경을 직접 구성해야 할 때 | vCPU, 메모리, 디스크, 네트워크, 실행 시간 |
| Cloud Run | 컨테이너 애플리케이션 실행 | 컨테이너화한 웹 서비스나 API를 관리형 환경에 배포할 때 | 요청 기반·인스턴스 기반 설정과 리소스 사용량 |
| Cloud Storage | 객체 저장소 | 이미지, 파일, 백업, 정적 웹 자산을 저장할 때 | 저장량, 작업, 데이터 처리, 네트워크 |
| Cloud SQL | 관리형 관계형 데이터베이스 | MySQL, PostgreSQL, SQL Server가 필요할 때 | 인스턴스, 스토리지, 백업, 네트워크 |
| BigQuery | 서버리스 데이터 웨어하우스 | 대규모 데이터를 SQL로 분석할 때 | 쿼리 처리 데이터량, 슬롯, 저장량 |
예를 들어 웹앱이 업로드한 사진이나 첨부 파일은 Cloud Storage에, 회원·주문 같은 관계형 데이터는 Cloud SQL에 둘 수 있습니다. 이후 서비스 로그나 대량의 이벤트 데이터를 집계·분석하려면 BigQuery가 별도 분석 계층이 됩니다. 파일 저장소, 운영 데이터베이스, 분석용 데이터 웨어하우스는 처리 방식과 비용 계산 기준이 다르므로 하나의 서비스로 뭉뚱그려 판단하면 안 됩니다.
홈페이지와 웹앱 배포: Compute Engine과 Cloud Run 중 무엇을 고를까
파일 보관이 목적이라면 서버를 만들기 전에 개인용 클라우드 저장소와 동기화가 충분한지 확인하세요.
Compute Engine은 Linux 또는 Windows 가상 머신을 구성·운영하는 IaaS 서비스입니다. 운영체제 수준의 설정, 서버 소프트웨어 설치, 실행 방식 제어가 필요한 경우에 맞습니다. 대신 사용자가 VM 환경을 직접 관리하는 범위가 커집니다.
Cloud Run은 컨테이너화한 애플리케이션을 관리형 환경에 배포하는 서버리스 실행 서비스입니다. 애플리케이션을 컨테이너 단위로 배포하려는 경우에 비교 대상이 됩니다. 다만 서버리스라는 말만으로 비용이 자동으로 사라진다고 해석하면 안 됩니다. 공식 문서상 요청 기반 또는 인스턴스 기반 과금 설정을 제공하며, 실행 방식과 자동 확장 설정에 따라 과금 구조가 달라집니다.
- 서버 OS, 패키지, 실행 환경을 직접 제어해야 한다면: Compute Engine을 우선 검토합니다.
- 컨테이너로 만든 웹앱이나 API를 관리형 환경에 배포하려면: Cloud Run을 우선 검토합니다.
- 비용 관리 관점: Compute Engine은 RUNNING 상태의 유휴 VM도 과금될 수 있다는 점을 먼저 확인해야 합니다. Cloud Run은 배포 전에 요청 기반·인스턴스 기반 설정과 리소스 기준을 확인해야 합니다.
Compute Engine의 실행 시간은 1분 최소 과금 후 초 단위로 계산되며, vCPU·메모리 외에도 디스크와 네트워크 사용량이 비용에 영향을 줍니다. 따라서 개발용 VM을 만들었다면 “사용하지 않을 때 중지하거나 삭제할 대상인지”를 생성 시점부터 정해 두는 편이 좋습니다.
파일 저장·데이터베이스·분석 서비스 조합: Cloud Storage·Cloud SQL·BigQuery
Cloud Storage: 서비스용 파일을 담는 버킷
Cloud Storage는 파일, 이미지, 백업, 정적 웹 자산을 버킷에 저장하는 객체 스토리지입니다. 파일을 저장한다는 점에서 Drive와 비슷해 보일 수 있지만, 애플리케이션이 접근하고 운영하는 저장소라는 점에서 성격이 다릅니다. 가격은 스토리지 클래스와 버킷 위치, 저장량만이 아니라 데이터 처리·작업·네트워크·검색·복제 등의 항목에도 영향을 받습니다.
따라서 저장 용량만 계산해 “저장료가 낮으니 전체 비용도 낮다”고 판단하기 어렵습니다. 다운로드가 많은 서비스인지, 리전 간 데이터 이동이 있는지, 객체 작업이 빈번한지를 함께 살펴야 합니다.
Cloud SQL: 운영 데이터용 관리형 관계형 DB
Cloud SQL은 MySQL, PostgreSQL, SQL Server를 관리형으로 운영하는 서비스입니다. 서비스의 회원 정보, 주문 정보처럼 애플리케이션이 지속적으로 읽고 쓰는 관계형 데이터를 다루는 경우에 검토할 수 있습니다. 가격은 인스턴스 컴퓨팅, 스토리지, 백업, 네트워크 등 구성과 사용량에 따라 달라집니다. 관리형 서비스여도 인스턴스 크기나 고가용성, 백업 정책은 선택해야 하므로 고정 월정액으로 보기는 어렵습니다.
BigQuery: 분석 쿼리용 별도 환경
BigQuery는 대규모 데이터를 SQL로 분석하는 서버리스 데이터 웨어하우스입니다. 운영 DB를 대신하기보다 분석 목적의 쿼리 환경으로 이해하는 편이 적절합니다. 온디맨드 쿼리는 처리한 데이터량을 기준으로 비용이 계산되고, 저장 비용은 별도로 계산됩니다. 공식 가격 페이지에는 계정당 월 1TiB까지의 쿼리 처리 무료 구간이 안내되어 있습니다.
BigQuery에서는 LIMIT을 붙였다고 스캔 비용이 자동으로 크게 줄어드는 것은 아닙니다. 어떤 열을 조회하는지와 스캔하는 데이터량이 중요합니다. 최대 바이트 처리량 제한과 파티셔닝을 함께 활용하는 방식이 비용 통제에 도움이 됩니다.
구글 클라우드 요금 구조: 300달러 크레딧·무료 등급·종량제 구분
Google Cloud의 무료 관련 제도는 한 가지가 아닙니다. 혼동을 피하려면 다음 세 층을 분리해 봐야 합니다.
- 신규 고객 300달러 무료 크레딧: Google Cloud 제품과 개념검증에 사용할 수 있는 체험성 크레딧입니다.
- Always Free 월별 무료 사용량: 공식 무료 프로그램은 20개 이상의 제품에서 월별 무료 사용량을 안내합니다. 서비스마다 적용 조건과 한도가 다릅니다.
- 사용량 기반 과금: 무료 크레딧이나 무료 한도와 별도로, 핵심 서비스는 대체로 리소스와 사용량을 기준으로 과금됩니다.
예를 들어 Compute Engine 무료 등급에는 조건을 충족하는 e2-micro VM 1개, 월 최대 30GB 표준 영구 디스크, 월 최대 1GB 외부 데이터 전송이 공식 안내되어 있습니다. 하지만 적용 리전과 기타 리소스 조건을 확인해야 하며, 이를 전체 VM 사용이 무료라는 뜻으로 확대해서는 안 됩니다.
가격은 제품, 리전, 저장량, 처리량, 네트워크 사용량에 따라 달라집니다. 배포 전에 공식 가격 목록과 Pricing Calculator로 자신이 만들 구성 단위의 비용을 계산하는 절차가 필요합니다.
초보자가 놓치기 쉬운 비용: VM 유휴 실행·스토리지 작업·네트워크·BigQuery 스캔
예상 밖 과금은 대개 서비스 자체보다 “계속 남아 있는 리소스”와 “보이지 않는 사용량 단위”에서 발생합니다.
- 실행 중인 VM: Compute Engine VM은 유휴 상태여도 RUNNING이면 과금될 수 있습니다. 중지 여부만 볼 것이 아니라 연결된 디스크, 이미지, 네트워크 항목도 살펴야 합니다.
- Cloud Storage의 저장료 외 항목: 객체 저장량 외에 작업, 데이터 처리, 네트워크, 검색·복제 비용이 영향을 줄 수 있습니다. 파일 다운로드 또는 데이터 이동이 많은 구조인지 확인해야 합니다.
- Cloud SQL의 구성 요소: 데이터베이스 비용은 인스턴스만이 아니라 스토리지, 백업, 네트워크 선택과 함께 달라집니다.
- BigQuery의 스캔량: 온디맨드 쿼리는 결과 행 수보다 처리한 데이터량이 핵심입니다. 필요한 열만 선택하고, 파티셔닝과 최대 바이트 처리량 제한을 검토해야 합니다.
또한 운영에 넣을 기능은 제품 출시 단계도 확인해야 합니다. Google Cloud 제품은 GA, Preview 등으로 구분될 수 있고, Preview 기능은 기능 완성도·지원·SLA가 제한될 수 있습니다.
과금 사고를 줄이는 설정 순서: 프로젝트·리전·예산 알림·리소스 삭제·비용 리포트
정적 사이트만 배포할 때는 무료 호스팅의 서버 지원·상업 이용 제한을 비교하면 불필요한 인프라 구성을 줄일 수 있습니다.
- 용도별 프로젝트를 구분합니다. 실험, 개발, 운영을 한 프로젝트에 섞기보다 목적에 따라 나누면 비용 확인과 리소스 정리가 쉬워집니다.
- 리전을 먼저 결정합니다. 사용자 위치, 데이터 위치, 서비스 지원 여부, 가용성 요구를 고려합니다. 같은 서비스라도 지원 리전이 다를 수 있습니다.
- 필요한 API와 리소스만 활성화합니다. 실험용 리소스를 만들기 전에 종료·삭제 기준을 함께 정합니다.
- Cloud Billing에서 예산과 알림 기준을 설정합니다. 예산은 프로젝트, 폴더, 조직, 전체 결제 계정 단위와 월·분기·연간·사용자 지정 기간 단위로 설정할 수 있으며, 설정한 기준 초과율에 따라 이메일 알림을 받을 수 있습니다.
- 알림을 자동 차단으로 오해하지 않습니다. 일반 Budget은 비용을 자동으로 막는 기능이 아니라 알림 중심 기능입니다. Spend Cap은 Preview이며 적용 대상 서비스와 조건을 별도로 확인해야 합니다.
- 실험이 끝나면 리소스를 삭제하고 비용 리포트를 확인합니다. 인스턴스뿐 아니라 디스크, 저장 객체, 백업처럼 남아 있을 수 있는 항목을 점검합니다.
이 순서는 비용을 완전히 0으로 보장하는 방법이 아니라, 어떤 프로젝트의 어떤 리소스가 비용을 만드는지 파악하고 대응하기 위한 기본 절차입니다.
사용자 유형별 결론: 개인 개발자·소규모 사업자·데이터 분석팀·대규모 운영팀
개인 개발자라면 먼저 배포 방식부터 좁히는 것이 좋습니다. 서버 환경을 직접 다뤄야 하면 Compute Engine, 컨테이너 앱을 관리형으로 배포하려면 Cloud Run을 비교합니다. 무료 크레딧은 검증 용도로 활용하되, 프로젝트별 예산 알림과 실험 리소스 삭제를 동시에 운영해야 합니다.
소규모 사업자라면 웹앱 실행 환경과 데이터 계층을 분리해 보세요. 앱 실행에는 Compute Engine 또는 Cloud Run, 파일에는 Cloud Storage, 관계형 운영 데이터에는 Cloud SQL이 각각 후보가 됩니다. 가장 작은 구성이 아니라 실제 트래픽·백업·다운로드·네트워크 사용 시나리오까지 가격 계산기에 반영하는 것이 중요합니다.
데이터 분석팀은 BigQuery를 운영 데이터베이스와 다른 분석 환경으로 보고, 쿼리 처리량과 저장량을 따로 관리해야 합니다. 특히 쿼리 습관이 스캔 비용에 영향을 주므로 파티셔닝, 필요한 열 선택, 최대 바이트 처리량 제한을 검토할 필요가 있습니다.
대규모 운영팀은 서비스 선택만큼 프로젝트·폴더·조직 및 결제 계정 단위의 비용 가시성을 설계해야 합니다. 리전, 가용성, 출시 단계, 지원 조건을 서비스별로 확인하고 예산 알림을 운영 절차에 연결하는 접근이 적합합니다.
결국 구글 클라우드 플랫폼의 시작점은 “무엇이 무료인가”가 아니라 내 서비스에 서버·파일·DB·분석 중 무엇이 필요한지, 각 리소스를 언제 삭제하거나 축소할지를 먼저 정하는 데 있습니다.
Leave a Reply