'GA4 사용하면 필수' 구글 태그 게이트웨이(Google Tag Gateway) 총정리.Zip

광고 성과의 정확한 측정은 올바른 방향으로 캠페인을 운영하기 위해 꼭 필요한 전제조건 입니다. 하지만 광고 차단, 브라우저의 개인정보 보호 기능, 쿠키 제한 정책 등이 강화되면서 광고 신호 일부가 실제로 수집되지 못한 채 사라지고 있는 요즘인데요.

결국 마케터 입장에서는 “광고는 집행했는데, 이게 실제 매출에 얼마만큼 기여했는지” 정확하게 판단이 어려우니 잘못된 의사 결정을 하게되고 잠재 매출 기회를 놓치는 경우가 발생하게 되죠.

이 때문에 2025년 5월, 구글은 이 문제에 대응하기 위한 새로운 방식을 내놨습니다. 바로 Google Tag Gateway, 구글 태그 게이트웨이입니다.

기존 구글태그(Google Tag) 작동 방식

지금까지 대부분의 광고주는 클라이언트 사이드 태깅, 즉 Client-Side Tagging 방식을 사용해왔습니다. 말은 조금 어렵지만 구조는 단순합니다.

사용자가 광고를 클릭하거나 웹사이트에 방문하면, 웹사이트에 심어져 있는 자바스크립트 태그가 사용자의 행동 데이터를 브라우저에서 바로 구글 서버로 전송합니다. GA4, Google Ads, Floodlight 등 우리가 익숙하게 쓰는 구글 측정 도구들이 기본적으로 이런 방식으로 데이터를 수집해왔죠.

문제는 이 구조가 외부 환경 변화에 꽤 취약하다는 점입니다. 예를 들어 광고 차단기는 구글 도메인으로 향하는 태그 요청 자체를 막아버릴 수 있습니다. Safari의 ITP, Firefox의 Enhanced Tracking Protection, Brave처럼 개인정보 보호 기능이 강한 브라우저에서는 외부 추적 요청에 대한 제한이 더 강하게 작동할 수 있고요.

특히 중요한 것은 페이지를 호스팅하는 도메인과 데이터를 수집하는 도메인이 다르다는 점입니다. 예를 들어, 유저가 brand.com에 접속했는데, 그런데 측정 데이터는 google-analytics.com이나 기타 광고 플랫폼 도메인으로 전송되는 것이죠. 브라우저 입장에서는 사용자가 방문한 사이트와 데이터가 전송되는 대상이 서로 다른 상황인 것인데요. 문제는 일부 브라우저나 광고 차단 환경에서는 이런 호스트 간 차이를 외부 추적 요청으로 인식할 수 있습니다. 그래서 태그 요청 자체가 차단되거나, 일부 이벤트가 수집되지 않는 상황이 발생할 수 있죠.

구글 태그 게이트웨이(Google Tag Gateway) 작동 방식

Google Tag Gateway, 이하 GTG를 사용했을 때의 핵심적인 변화는 데이터가 이동하는 경로입니다.

기존 구글태그 방식이 아래와 같았다면,

브라우저 → 구글 서버

GTG는 경로를 이렇게 바꿉니다.

브라우저 → 광고주 자체 도메인 → 구글 서버

조금 더 쉽게 말하면, 사용자의 브라우저가 데이터를 곧바로 구글로 보내는 것이 아니라, 먼저 광고주의 자체 도메인을 거치게 만드는 방식입니다. 일종의 서버 사이드 프록시 구조라고 볼 수 있습니다.

예를 들어 tracking.brand.com 같은 형태의 자체 도메인이 중간 경유지 역할을 하게 됩니다. 브라우저 입장에서는 데이터를 외부 광고 플랫폼이 아니라, 사용자가 방문한 사이트의 도메인으로 보내는 것처럼 인식하게 되는 것이죠.

GTG 핵심은 페이지 호스트와 데이터 수집 호스트를 최대한 일치시키는 것입니다. 기존에는 사용자가 광고주 웹사이트에 방문했더라도, 구글 태그 스크립트와 측정 요청은 구글 도메인으로 향했습니다. 반면 GTG를 적용하면 Google tag가 광고주 자체 도메인에서 로드되고, 측정 이벤트도 먼저 광고주 도메인으로 전송된 뒤 Google로 전달됩니다.

이 차이는 매우 중요한데요. 광고 차단기나 브라우저의 프라이버시 제한은 보통 외부 추적 도메인, 특히 광고 플랫폼으로 향하는 요청에 민감하게 반응합니다. 그런데 GTG를 사용하면 데이터 요청이 광고주 자체 도메인 기반의 퍼스트 파티 요청처럼 처리되기 때문이죠.

즉, 구글의 추적 요청이 아니라, “내가 방문한 사이트와의 통신”으로 보이게 하는 것입니다. 이 구조 덕분에 일부 브라우저 정책이나 광고 차단 환경에서 발생하던 데이터 유실을 어느 정도 줄일 수 있습니다.

실제, 구글에 따르면 GTG를 구성한 광고주는 전환 신호가 평균 11% 증가한 것으로 나타났습니다. 마케터 입장에서 11%면 정말 큰 성과 범위죠.

클라이언트사이드태깅과 서버사이드태깅의 장점을 결합한 방식

기본적으로 우리가 웹사이트에 설치해 사용하는 구글태그매니저(Google Tag Manager, GTM)은 클라이언트 사이드 GTM, 즉 cGTM입니다. 사용자의 브라우저에서 태그가 실행되고, 브라우저가 각 플랫폼으로 데이터를 전송하는 방식이죠.

반면 서버사이드 GTM, 즉 sGTM은 브라우저에서 모든 데이터를 직접 광고 플랫폼으로 보내는 것이 아니라, 광고주가 관리하는 서버 컨테이너를 거쳐 필요한 데이터만 각 플랫폼으로 전달하는 방식입니다. 데이터 통제력은 더 높지만, 구축 난이도와 운영 리소스도 커서 인프라가 제한적인 상황에서는 잘 활용되고 있지 못하죠.

GTG는 이 둘 사이에 있는 현실적인 절충안에 가깝습니다. 완전한 sGTM처럼 모든 관련 태그와 이벤트를 서버 컨테이너에서 통제하는 방식은 아닙니다. 하지만 적어도 Google tag에 대해서는 자체 도메인을 경유하는 구조를 만들 수 있습니다. 그래서 기존 cGTM을 유지하면서도, 일부 sGTM의 장점인 퍼스트 파티 도메인 기반 측정 안정성을 가져갈 수 있는 것이죠.

정리하면 이렇게 볼 수 있습니다.

즉, GTG는 “sGTM을 대체하는 기능”이라기보다는, sGTM까지 가기 전 단계에서 적용할 수 있는 Google 계열 측정 보완책에 가깝습니다.

구글 태그 게이트웨이(GTG) 장점

1. 전환 성과 측정 정확도 향상

퍼포먼스 마케팅에서 가장 큰 아젠다 중 하나는 정확한 성과 트래킹인데요. 근데, 성과가 실제보다 낮게 측정되면 어떤 일이 생길까요?

좋은 캠페인이 조기 중단될 수 있고, 효율이 좋은 소재가 충분히 기회를 얻지 못할 수 있으며, 반대로 실제 성과가 낮은 캠페인에 예산이 계속 들어갈 수도 있죠.

즉, 데이터 손실은 예산 배분과 캠페인 의사결정 전체를 흔드는 문제입니다. 이 지점에서 GTG를 사용한다면 광고 차단기나 브라우저 제한 때문에 누락되던 전환 신호를 더 안정적으로 수집할 수 있다면, 마케터는 실제 성과에 더 가까운 데이터를 보고 판단할 수 있습니다.

2. AI 캠페인 최적화 서포트

더 중요한 이점은 AI 기반 캠페인 최적화입니다.

요즘 구글은 대부분의 광고 상품을 자동화/AI 기반 운영으로 돌리고 있습니다(DemandGen, Performance Max, AI Max 등). 이 캠페인들은 사람이 일일이 입찰가를 조정하는 방식이 아니라, 알고리즘이 전환 데이터를 학습해 누구에게, 언제, 얼마의 입찰가로 광고를 보여줄지 결정하죠.

그렇다면 알고리즘이 좋은 판단을 하려면 무엇이 필요할까요? 결국 좋은 데이터입니다. 전환 신호가 누락되거나 왜곡되면 AI는 실제 고객의 행동을 제대로 학습하지 못합니다. 성과가 좋은 유저를 놓칠 수도 있고, 반대로 효율이 낮은 유저에게 과도하게 입찰할 수도 있습니다.

그렇기 때문에, AI 광고 캠페인에서 전환 데이터는 캠페인이 잘 굴러갈 수 있도록 하는 연료와 같으며, GTG는 이 연료의 품질을 높이는데 기여할 수 있습니다. 더 정확한 전환 신호를 구글 광고 시스템에 전달함으로써, AI가 더 정확하게 학습하고 더 나은 입찰 판단을 하도록 돕는 것이죠.

구글 태그 게이트웨이(GTG) 한계

다만 GTG가 모든 데이터 유실 문제를 해결하는 것은 아닙니다.

일부 브라우저나 광고 차단 환경에서는 Google tag 요청만이 아니라 GTM 스크립트 자체를 차단하는 경우도 있습니다. 이 경우에는 GTG를 적용하더라도 태그 실행 자체가 막힐 수 있기 때문에, 문제를 완전히 해결하기 어렵습니다.

이런 환경까지 더 적극적으로 대응하려면 서버 사이드 GTM, 자체 이벤트 수집 서버, 매체별 서버 전환 API 같은 더 확장된 구조가 필요합니다. 다만 일반적인 웹사이트 운영 환경에서는 GTG만으로도 Google 계열 측정 신호의 안정성을 개선할 여지가 있습니다.

또 다른 한계는 Google Tag Gateway를 도입한다고 해서 GTM 안에 설치된 모든 마케팅 태그의 전환 정확도가 자동으로 올라가는 것은 아니라는 점입니다.

Google Tag Gateway는 기본적으로 Google tag 요청을 광고주 자체 도메인 경유 구조로 바꾸는 기능입니다. 즉, GA4, Google Ads, Floodlight, Search Ads 360처럼 Google 계열 측정 신호의 안정성을 높이는 데 초점이 맞춰져 있습니다.

반면 Meta, 네이버, 카카오 같은 외부 광고 플랫폼 태그는 여전히 각 플랫폼의 스크립트와 서버로 데이터를 전송합니다. GTM 안에서 실행된다고 해도, 데이터가 전달되는 최종 경로는 Google이 아니라 각 매체의 도메인인 것이죠.

이때, GTG가 일부 sGTM의 장점을 가져온다고 해서, GTM 안에 있는 모든 태그가 서버 사이드 방식으로 전환되는 것은 아닙니다. 예를 들어 Meta Pixel, 네이버 광고 전환 스크립트, 카카오 픽셀은 GTM 안에서 관리하더라도 여전히 각 플랫폼의 스크립트와 엔드포인트로 데이터를 전송합니다. GTG를 적용했다고 해서 이 태그들이 자동으로 광고주 자체 도메인을 경유하거나, 각 매체의 서버 전환 연동처럼 작동하는 것은 아닙니다.

개인정보 보호 정책과의 정합성

GTG는 개인정보 우회 도구가 아닙니다. 오히려, 구글은 GTG를 Consent Mode v2와 함께 사용하는 구조로 안내하고 있습니다. Consent Mode v2가 사용자의 동의 상태를 관리하고, GTG는 그 동의 범위 안에서 데이터가 더 안정적으로 전달되도록 돕는 방식인데요. 두 가지가 함께 작동해야 프라이버시 규정에 부합하면서도 측정 정확도를 높이는 완결된 구조가 됩니다.

또한, GTG는 GDPR, CCPA 등 글로벌 개인정보 보호 규정에도 원칙적으로 부합합니다. 데이터가 광고주 자체 도메인을 경유하기 때문에, 사용자 입장에서도 데이터가 누구의 환경에서 처리되는지 더 명확해지는 것이죠.

설치 방법

GTG의 또 다른 장점은 접근성입니다. 서버 사이드 태깅(sGTM)은 원래 서버에 접근할 기술 팀을 갖춘 기업만 구현할 수 있는 영역으로 여겨졌습니다. 하지만 구글은 GTG와 Cloudflare의 원클릭 통합을 지원하고, WordPress 등 주요 플랫폼에 대한 가이드도 공개했습니다.

GTG는 다음 순서에 따라 설치 및 운영할 수 있습니다.

1. 기술 경로 선택 : 팀의 기술 수준과 인프라에 따라 Cloudflare 같은 CDN 연동, 혹은 풀 서버사이드 GTM 컨테이너 중 선택합니다.

2. 배포 및 구성 : Google Ads나 GA4에서 GTG를 활성화하고, 도메인 프록시 설정을 완료합니다.

3. 병행 테스트 및 전환 : Google Tag Assistant로 데이터 라우팅을 검증한 뒤, 1~2주간 기존 시스템과 병행 운영 후 전환합니다.

B2B 환경이라면 GTG를 1단계로, 이후 CRM 연동과 오프라인 전환 추적까지 아우르는 풀 서버사이드 태깅(SST)으로 단계적으로 확장하는 접근이 가능해진 것이죠.

개인정보 보호 강화와 브라우저 정책 변화로 인해, 광고 데이터가 일부 누락되는 흐름은 앞으로도 계속될 가능성이 높습니다. 이제 마케터에게 중요한 것은 단순히 광고를 잘 세팅하는 일이 아니라, 광고 시스템이 학습할 수 있는 정확한 전환 신호를 안정적으로 확보하는 일입니다.

GTG는 이 문제를 해결하는 완벽한 정답은 아닙니다. 하지만 그럼에도 GA4와 Google Ads를 중심으로 운영하는 광고주라면 충분히 검토할 만한 선택지입니다. 브라우저에서 Google로 바로 향하던 태그 요청을 광고주 자체 도메인 경유 구조로 바꾸는 것만으로도, 일부 환경에서 누락되던 Google 계열 측정 신호를 더 안정적으로 수집할 수 있기 때문입니다.

결국 AI 기반 광고 운영에서 데이터는 알고리즘의 연료입니다. GTG는 그 연료가 조금 더 정확하게 전달되도록 돕는, 현실적인 측정 개선 옵션이라고 볼 수 있습니다.