어떤 클라우드를 고를 것인가부터 정해야 한다

GTM 서버 컨테이너를 어디에 올릴지는 자사가 이미 쓰고 있는 클라우드 인프라, 개발팀의 운영 숙련도, 예상 트래픽 규모를 함께 고려해 정합니다. 구글은 자사 서비스인 만큼 GCP 위에서 App Engine·Cloud Run 두 가지 배포 경로를 공식 문서로 상세히 제공합니다. 이미 GCP를 쓰고 있거나 처음 서버사이드 태깅을 도입하는 팀이라면 이 공식 경로를 따르는 편이 문서·지원이 가장 충실합니다.

App Engine 배포는 무엇을 해주는가

App Engine 경로는 구글이 제공하는 배포 스크립트를 실행하면 필요한 리소스(서버 인스턴스, 로드밸런서, HTTPS 인증서 등)가 자동으로 구성되는 방식입니다. 구글 공식 가이드는 프로덕션 환경에서 서버 36대 구성을 권장하며, 서버 1대당 월 약 40달러, 초당 요청 50200건 처리를 기준값으로 제시합니다. 다만 이 수치는 표준 구성 예시일 뿐이고, 실제 트래픽·리전·부가 서비스에 따라 비용이 달라지므로 구글 클라우드 요금 계산기(Pricing Calculator)로 자사 트래픽 기준 견적을 직접 산출하는 절차가 안내돼 있습니다. 이 요금 계산기 화면에는 서버사이드 태깅 기본 구성이 미리 채워져 있어 트래픽 예상치만 조정하면 됩니다.

Cloud Run 배포는 어떻게 다른가

Cloud Run은 서버리스 방식으로, 트래픽이 없을 때는 인스턴스를 최소로 줄이고 트래픽이 몰리면 자동으로 확장합니다. 이 방식의 핵심 설정값은 최대 인스턴스 수(max-instances)입니다 — 이 값이 트래픽이 아무리 몰려도 지불하게 될 비용의 이론적 상한선 역할을 합니다. 이 상한을 설정해두지 않으면 트래픽 급증 시 비용이 통제 없이 늘어날 구조적 위험이 있는데, 이 리스크와 예방책은 이 과목 8강에서 실패 사례 관점으로 더 깊이 다룹니다.

배포 전에 확인해야 할 조건들

클라우드 인프라를 세팅하기 전에 확정해둘 것이 몇 가지 있습니다. 먼저 4강에서 다룰 퍼스트파티 도메인(서브도메인)을 이 서버 컨테이너에 연결할 계획인지 미리 정해야 도메인·인증서 설정 순서가 꼬이지 않습니다. 또한 어떤 이벤트부터 서버 경로로 옮길지(2강에서 정리한 우선순위)에 따라 서버 컨테이너에 필요한 클라이언트·태그 구성 범위가 달라지므로, 인프라만 먼저 만들어두고 태그 설계는 나중으로 미루기보다는 두 작업을 병행 설계하는 편이 재작업을 줄입니다.

AWS 등 다른 클라우드에서는 어떻게 하나

GCP 외 인프라(AWS, Azure 등)에 서버 컨테이너를 올리는 구체적 절차는 이번 조사에서 공식 자료로 확인하지 못했습니다(미확인). 원리 자체는 GCP와 다르지 않습니다 — GTM 서버 컨테이너는 컨테이너화된 애플리케이션이므로 도커(Docker) 이미지를 지원하는 인프라라면 이론적으로는 어디든 올릴 수 있습니다. 다만 구글이 직접 제공하는 원클릭 배포 스크립트·공식 운영 가이드는 GCP 대상이고, AWS 등에서는 자체적으로 컨테이너 오케스트레이션(예: ECS, EKS)을 구성해야 합니다. 자사가 AWS 중심 인프라라면, 먼저 개발팀과 함께 GTM 서버 컨테이너의 도커 이미지 배포 가능 여부를 AWS 공식 문서(ECS/EKS) 기준으로 검토한 뒤, 필요하면 이 부분에 정통한 클라우드 엔지니어의 확인을 받는 순서를 권장합니다.

App Engine과 Cloud Run 중 무엇을 고를지의 기준

두 배포 방식은 트래픽 패턴에 따라 유불리가 갈립니다. 트래픽이 하루 중 큰 변동 없이 꾸준한 서비스라면 App Engine의 정형화된 서버 구성이 예측 가능한 비용·성능을 제공합니다. 반대로 특정 시간대나 프로모션 기간에만 트래픽이 급증하고 평소에는 낮은 서비스라면, 트래픽이 없을 때 인스턴스를 최소로 줄이는 Cloud Run이 평상시 비용을 아낄 수 있는 구조입니다. 다만 Cloud Run은 트래픽이 없다가 갑자기 몰릴 때 첫 요청의 응답 지연(콜드 스타트)이 발생할 수 있어, 이 부분이 실시간성이 중요한 전환 추적에 미치는 영향을 사전에 검토하는 것이 좋습니다.

팀 내 역할 분담은 어떻게 나누는 게 현실적인가

서버 컨테이너 인프라 구축은 마케팅·데이터 분석 담당자가 혼자 진행하기 어려운 영역입니다. 클라우드 계정 생성·권한 관리·배포 스크립트 실행은 개발팀 또는 인프라 담당자의 협조가 필요하고, 그 위에서 클라이언트·태그를 설계하는 것은 데이터 분석·태깅 담당자의 영역입니다. 실무에서는 인프라 담당자가 먼저 배포를 완료해 기본 주소(appspot.com 또는 run.app 도메인)를 확보하면, 그 다음 단계로 4강의 퍼스트파티 도메인 바인딩과 5~6강의 데이터·태그 설계가 이어지는 순서로 진행하는 것이 일반적입니다.