광고 대행사 에이달 | sGTM 도입했더니 GCP 청구서가 폭탄이 됐다: Cloud Run 비용 급증 원인 진단과 캐싱 최적화 실무

sGTM 도입했더니 GCP 청구서가 폭탄이 됐다: Cloud Run 비용 급증 원인 진단과 캐싱 최적화 실무

2026년 05월 24일

#서버사이드 GTM 비용

#sGTM Cloud Run 요금

#구글 태그 매니저 서버사이드

#GCP 비용 최적화

#데이터 파이프라인 구축

요약

서버사이드 GTM(sGTM)을 GCP Cloud Run에 배포한 뒤 예상보다 훨씬 높은 클라우드 청구서를 받고 당황한 경험이 있으신가요? 이 글은 그 원인을 세 가지로 정확히 짚고, Cloud Run 인스턴스 튜닝과 CDN 캐싱 레이어 구성으로 비용을 실질적으로 낮추는 실무 방법을 단계별로 안내합니다. 최적화된 환경 기준 sGTM 운영 비용은 100만 요청당 약 €3~€7(약 4,500~10,000원) 수준이 가능합니다. 아직 최적화를 못 하고 있다면, 지금 바로 점검이 필요합니다.

왜 sGTM 비용이 예상을 초과하는가: 핵심 개념부터 이해하기

sGTM이 뭔지 먼저 간단히 정리

서버사이드 GTM(sGTM) 은 기존에 사용자 브라우저에서 직접 실행되던 GA4, Meta Pixel 같은 추적 스크립트를 자사 서버(클라우드 인프라)로 옮겨서 처리하는 기술입니다. 쉽게 말해, 브라우저가 직접 Meta 서버에 데이터를 보내는 대신, 우리 회사 서버가 중간에서 데이터를 받아 가공한 뒤 전달하는 구조입니다.

이 방식은 쿠키 제한(ITP)이나 Consent Mode v2 대응에 효과적이고, 퍼스트파티 데이터 제어권도 강해집니다. 그런데 문제는 이 서버를 운영하는 비용이 생각보다 크게 나온다는 것입니다.

GCP Cloud Run이란?

Cloud Run은 Google Cloud Platform(GCP)에서 제공하는 서버리스 컨테이너 서비스입니다. 서버를 직접 관리하지 않아도 되고, 트래픽에 따라 자동으로 인스턴스(서버 단위)가 늘어나거나 줄어듭니다. sGTM을 Cloud Run에 배포하는 것이 현재 글로벌 표준입니다.

핵심 문제: Cloud Run은 편리하지만, 설정을 제대로 잡지 않으면 트래픽 폭증 시 인스턴스가 무한정 늘어나고 청구서가 폭발합니다.

sGTM 비용 폭탄의 3가지 원인 진단

원인 1: 기본 고정 비용의 함정

Google 공식 가이드는 sGTM 안정 운영을 위해 최소 2~3개의 Cloud Run 인스턴스를 항상 켜두도록 권장합니다. 각 인스턴스는 1 vCPU, 0.5GB RAM 사양에 'CPU 항상 할당' 모드로 설정됩니다.

이 경우 실제 트래픽이 전혀 없어도 인스턴스 한 대당 월 약 $45의 비용이 발생합니다. 3개 운영 시 기본 고정비만 월 $120~$150(약 17~21만 원) 이 됩니다. 사이트 규모가 작은 스타트업이나 중소기업이라면 이것만으로도 부담스러운 수준입니다.

원인 2: 오토스케일링 제한 미설정

Cloud Run의 max-instances(최대 인스턴스 수) 기본값은 최대 100개입니다. 연말 프로모션이나 바이럴 마케팅으로 트래픽이 갑자기 12배 폭증하면, Cloud Run은 충실하게 수십 개의 인스턴스를 동시에 띄웁니다.

실제 사례로, 한 이커머스 기업은 연말 기획전 기간 동안 일일 페이지뷰가 평소 대비 12배 급증했습니다. max-instances를 100으로 둔 채 캐싱도 없었던 탓에, 사흘 만에 평소 월 청구서의 12배에 달하는 수천 달러가 청구됐습니다. 이후 CDN 캐싱과 인스턴스 최적화로 CPU 부하를 70% 이상 줄이고 비용을 정상 범위로 되돌렸습니다.

원인 3: 스크립트 파일 직접 호출에 따른 Egress 비용

사용자 브라우저가 매 세션마다 gtm.js나 gtag.js 같은 자바스크립트 파일을 sGTM 서버에 직접 요청합니다. 이 요청 하나하나가 Cloud Run 컨테이너의 컴퓨팅 자원을 소모하고, GCP의 아웃바운드 네트워크 전송(Egress) 요금을 발생시킵니다.

월 방문자 수십만 명 규모의 사이트라면, 이 스크립트 호출만으로도 상당한 Egress 비용이 누적됩니다. 캐싱 레이어 없이 모든 요청이 Cloud Run까지 도달하는 구조라면 이 비용은 계속 선형적으로 증가합니다.

단계별 실행 가이드: Cloud Run 인스턴스 최적화

1단계: max-instances 하향 조정

GCP 콘솔에서 Cloud Run 서비스 편집 화면으로 이동합니다. '용량' 탭에서 최대 인스턴스 수를 찾아 기본값에서 3~5개로 낮춥니다.

대규모 커머스(일 PV 100만 이상): 최대 10개 내외
중소형 사이트(일 PV 10만 미만): 3~5개로 충분
설정 후 모니터링하며 점진적으로 조정

이 설정 하나만으로도 비정상 트래픽 스파이크나 봇 공격 시 비용 상한선이 생깁니다.

2단계: 동시성(Concurrency) 최적화

Cloud Run의 기본 동시성 한도는 인스턴스당 80개 요청입니다. sGTM은 Node.js 기반의 입출력(I/O) 중심 프로세스이므로, 실제 지연율(Latency) 모니터링 수치를 보면서 동시성 값을 조정하면 새 컨테이너가 불필요하게 스핀업되는 현상을 막을 수 있습니다.

실무 팁: Cloud Run 모니터링 탭에서 Request latency와 Instance count를 함께 확인하세요. 지연율이 안정적인데 인스턴스 수가 계속 늘어난다면 동시성 설정을 높여볼 수 있습니다.

3단계: 결제 모드와 리전 선택

트래픽이 매우 적거나 야간 유휴 시간이 긴 서비스라면 '요청 기반 결제(Request-based billing)' 모드를 검토하세요. CPU를 요청 처리 시간에만 할당하므로, 유휴 시간 비용이 크게 줄어듭니다.

또한 Cloud Run 배포 리전을 GCP Tier 1 리전(예: us-central1, asia-northeast1 등)으로 설정하면 vCPU 및 메모리 단가 자체가 낮아져 누적 비용이 줄어듭니다. 한국 사용자 대상 서비스라면 asia-northeast3(서울) 또는 asia-northeast1(도쿄)을 비교해보세요.

단계별 실행 가이드: 캐싱 레이어 구성 실무

4단계: Cloud Load Balancer + Cloud CDN 연동

sGTM 커스텀 도메인(예: gtm.yourcompany.com) 앞단에 GCP 부하 분산기(Load Balancer)를 배치하고 Cloud CDN을 연동합니다. 구성 흐름은 다음과 같습니다.

사용자 브라우저 → Cloud CDN 에지 캐시 → (캐시 미스 시에만) Cloud Run sGTM

이렇게 하면 gtm.js 같은 정적 스크립트 파일은 글로벌 에지 포인트에서 캐싱 처리되어 Cloud Run까지 도달하지 않습니다. 컴퓨팅 시간과 Egress 비용 모두 획기적으로 줄어듭니다.

5단계: 이벤트 수집 경로는 반드시 캐싱 제외

절대 주의사항입니다. 캐싱 정책을 모든 경로에 적용하면 실시간 데이터 수집이 마비됩니다.

반드시 캐싱에서 제외(Bypass)해야 하는 경로:

GA4 수집 경로: /g/collect
Meta Conversion API 엔드포인트
기타 실시간 이벤트 페이로드가 담기는 동적 수집 경로

Cloud CDN 또는 Load Balancer 설정에서 URL 경로 기반 캐시 규칙을 만들어, 위 경로는 캐시 없이 Cloud Run으로 직접 전달되도록 설정하세요.

실행 전 점검 항목 체크리스트

[ ] max-instances 값을 기본값에서 3~10개 수준으로 낮췄는가
[ ] GCP 결제 예산 경고를 월 예상 금액의 50%, 80%, 100% 지점에 설정했는가
[ ] Cloud CDN을 sGTM 도메인 앞단에 연동했는가
[ ] /g/collect 등 수집 경로를 캐싱 제외(Bypass) 처리했는가
[ ] sGTM 디버그/미리보기 서버(/gtm/debug)를 프로덕션 도메인과 분리했는가
[ ] Direct VPC Egress 설정으로 전환하여 유휴 리소스 낭비를 줄였는가
[ ] Cloud Run 배포 리전이 Tier 1 리전인지 확인했는가

에이전시 실무 팁: 디버그 모드(/gtm/debug)는 캐싱·속도 제한·보안 정책을 우회하므로 일반 트래픽 대비 서버 부하가 약 3배 높습니다. 프로덕션 배포 완료 후 반드시 별도 관리자 도메인으로 분리하거나 접근을 제한하세요.

비용 벤치마크: 얼마나 줄일 수 있나?

2026년 100개 이상의 글로벌 sGTM 구축 사례를 분석한 TRKKN 데이터에 따르면, 최적화된 GCP 환경 기준 sGTM 비용은 100만 요청당 약 €3~€7(약 4,500~10,000원) 수준입니다.

최신 sGTM 도커 이미지(gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable)는 Node.js 24 및 Distroless Debian 13 기반으로 최소 RAM 점유율이 약 200MB 수준으로 최적화되어 있습니다. 이전 버전 대비 메모리 낭비가 크게 줄었으므로, 이미지 버전을 최신으로 유지하는 것만으로도 리소스 효율이 개선됩니다.

만약 Cloud Run 비용 자체의 예측 불가능성이 부담스럽다면, Stape 같은 고정 요금제 플랫폼(50만 요청당 월 €20 수준)이나 Docker VPS 자체 호스팅으로 아키텍처를 전환하는 것도 현실적인 대안입니다.

자주 묻는 질문(FAQ)

Q1. sGTM을 Cloud Run에 배포하면 무조건 비용이 많이 드나요?

아닙니다. 인스턴스 수 제한, CDN 캐싱, 적절한 결제 모드 설정을 갖추면 중소형 사이트 기준 월 $50~$100 내외로 안정적으로 운영 가능합니다. 최적화 없이 기본 설정 그대로 두는 것이 문제입니다.

Q2. CDN 캐싱을 적용하면 GA4 데이터 수집에 문제가 생기지 않나요?

수집 경로(/g/collect 등)를 캐싱 제외(Bypass)로 설정하면 문제없습니다. 정적 스크립트 파일만 캐싱하고, 실시간 이벤트 경로는 항상 Cloud Run으로 직접 전달되도록 분리 설정하는 것이 핵심입니다.

Q3. max-instances를 너무 낮게 설정하면 사이트 성능에 영향이 있나요?

있을 수 있습니다. 트래픽이 설정한 최대 인스턴스 처리 용량을 초과하면 요청이 지연될 수 있습니다. 사이트의 평균·피크 트래픽을 모니터링하면서 적정값을 찾는 것이 중요합니다. 일반적으로 일 PV 10만 미만 사이트는 5개 이내로도 충분합니다.

Q4. 결제 알림은 어디서 설정하나요?

GCP 콘솔 → 결제(Billing) → 예산 및 알림(Budgets & alerts)에서 설정합니다. 월 예상 금액의 50%, 80%, 100% 지점에 Slack 또는 이메일 알림을 연동해두면 비용 폭탄을 사전에 감지할 수 있습니다.

Q5. Stape 같은 외부 플랫폼과 GCP Cloud Run, 어떤 걸 선택해야 하나요?

트래픽이 불규칙하거나 클라우드 관리 인력이 없는 팀이라면 고정 요금제 플랫폼이 예측 가능성 면에서 유리합니다. 반면 데이터 주권, 커스텀 인프라 연동, 대규모 트래픽 처리가 중요하다면 GCP Cloud Run 직접 최적화가 더 적합합니다.

용어 설명(Glossary)

sGTM(서버사이드 GTM): 브라우저 대신 서버에서 마케팅 태그를 실행하는 Google Tag Manager 배포 방식
Cloud Run: GCP의 서버리스 컨테이너 실행 서비스. 트래픽에 따라 인스턴스가 자동으로 확장·축소됨
max-instances: Cloud Run에서 동시에 실행될 수 있는 최대 인스턴스(서버 단위) 수를 제한하는 설정값
Egress(이그레스): 클라우드 서버에서 외부로 나가는 네트워크 트래픽. GCP는 이 아웃바운드 전송량에 요금을 부과함
Cloud CDN: GCP의 콘텐츠 전송 네트워크. 글로벌 에지 포인트에 콘텐츠를 캐싱하여 원본 서버 부하를 줄임
Concurrency(동시성): 하나의 Cloud Run 인스턴스가 동시에 처리할 수 있는 최대 요청 수
Direct VPC Egress: 서버리스 VPC 액세스 커넥터 없이 Cloud Run이 VPC 네트워크에 직접 연결하는 방식. 유휴 리소스 낭비를 줄임
FinOps: 클라우드 비용을 재무적으로 관리하고 최적화하는 운영 방식. 기술팀과 재무팀이 협력하여 클라우드 지출을 통제함