GA4 태그 게이트웨이: 서버 사이드 GTM의 진입 장벽을 낮춰주는 구글의 전략적 선택

광고비를 아무리 정교하게 집행해도, 정작 그 성과를 측정하는 데이터의 상당 부분이 소리 없이 사라지고 있다면 어떨까요? 2026년 현재 데이터 유실은 더 이상 예외적인 사고가 아니라 클라이언트 사이드 수집 방식이 안고 있는 구조적 한계입니다. 이 글에서는 데이터가 유실되는 근본 원인부터, 구글이 그 해법으로 내놓은 ‘태그 게이트웨이(Tag Gateway)’가 무엇이고 어떤 기업이 어떻게 도입해야 하는지까지 차근차근 정리하겠습니다.

목차

• GA4 데이터가 유실되는 이유
• 데이터는 왜 사라지는가: 서드파티 vs 퍼스트파티
• 태그 게이트웨이의 등장과 발전 과정
• 클라우드플레어(Cloudflare) 사용자를 위한 업데이트
• 태그 게이트웨이를 써야 하는 기업의 조건
• 실무 적용 가이드
• 마무리

1. GA4 데이터가 유실되는 이유

현재 GA4를 포함한 대다수 웹 분석 도구와 광고 매체 스크립트는 클라이언트 사이드(브라우저) 환경에서 데이터를 수집합니다. 그러나 이 방식은 구조적으로 데이터 유실을 피하기 어렵습니다. 업계에서 일반적으로 추정하는 데이터 손실률은 평균 한 자릿수 후반에서 10%대 초반(대략 7~11% 수준)으로, 세팅을 잘했더라도 여러 브라우저와 통신 환경, 외부 요인에 의해 데이터 중 일부가 측정되지 못하는 상황이 발생합니다. (※ 유실률은 측정 환경·업종·트래픽 구성에 따라 편차가 크며, 단일 공식 통계가 아닌 업계 추정치입니다.)

데이터 유실의 주요 원인

1. 클라이언트 사이드 스크립트 및 외부 네트워크 요청 차단
   • 브라우저나 확장 프로그램이 google-analytics.com 등 외부 광고/분석 도메인으로 나가는 데이터 요청을 감지하여 통신을 차단하는 방식입니다.
2. 서드파티 쿠키 규제 강화 기조
   • 애플은 ITP 정책으로 이미 2020년부터 서드파티 쿠키를 전면 차단해 왔습니다. 크롬은 서드파티 쿠키를 즉시 폐지하지는 않았지만(2024년 폐지 계획 철회), 사용자가 직접 추적을 통제할 수 있도록 프라이버시 제어권을 지속적으로 강화하는 방향으로 움직이고 있습니다.

   

3. 브라우저 트래킹 방지 기능 및 애드블록
   • 최신 브라우저의 내장 프라이버시 보호 기능 강화

   

   • 브레이브(Brave) 브라우저처럼 광고 차단 기능을 내장한 브라우저나 AdBlock 소프트웨어는 추적 스크립트가 아예 로드되지 못하게 막거나 쿠키 생성을 원천 봉쇄합니다.

데이터 유실 원인 요약

※ 위 비중은 공식 통계가 아닌 대략적인 추정치이며, 사이트 환경과 방문자 구성에 따라 달라질 수 있습니다.

2. 데이터는 왜 사라지는가: 서드파티 vs 퍼스트파티

웹 로그 분석을 하는 마케터와 엔지니어에게 가장 괴로운 점은 ‘유실률’입니다. 공들여 설치한 데이터 수집 도구와 광고 매체 스크립트가 왜 데이터를 놓치는지, 그 근본 원인인 쿠키(Cookie)와 도메인 정책을 깊이 파헤쳐 보겠습니다.

1. 퍼스트파티 쿠키마저 위협하는 브라우저의 규제

우리가 흔히 쓰는 GA4나 Facebook 픽셀은 기본적으로 우리 웹사이트 도메인의 이름으로 ‘퍼스트파티(1st-party)’ 쿠키를 발행하여 사용자를 식별합니다. 브라우저가 서드파티 쿠키를 차단하자 내놓은 구글과 메타의 해법이었습니다.

하지만 브라우저들의 개인정보 보호 정책이 진화하면서 이 방식도 한계에 부딪혔습니다. 데이터를 전송하는 목적지가 여전히 외부 서버(google-analytics.com, connect.facebook.net 등)인 데다가, 웹 브라우저 상에서 자바스크립트로 생성된 퍼스트파티 쿠키는 우회 추적 수단으로 의심받기 시작했기 때문입니다.

• ITP(Intelligent Tracking Prevention): 애플은 자바스크립트로 생성된 퍼스트파티 쿠키의 수명을 강제로 단축(조건에 따라 1일~7일)시키고 있습니다. 사용자가 일주일 뒤에 재방문하면 전혀 다른 신규 사용자로 인식되어 광고 성과 분석이 왜곡됩니다. 또한 보안 기능에 의해 외부 트래킹 스크립트 수집 요청 자체가 완전히 차단되기도 합니다.
• Chrome의 프라이버시 강화: 전 세계 점유율 1위인 크롬은 한때 프라이버시 샌드박스(Privacy Sandbox)로 서드파티 쿠키를 대체하려 했지만, 2024년 7월 서드파티 쿠키 폐지 계획을 철회했고 2025년 4월에는 별도 선택 프롬프트 도입 계획마저 폐기, 2025년 10월에는 프라이버시 샌드박스의 핵심 광고 API(Topics, Attribution Reporting, Protected Audience)를 공식 종료했습니다. 즉 현재 크롬에는 서드파티 쿠키가 그대로 유지되고 있습니다. 다만 크롬은 사용자가 크로스 사이트(Cross-Site) 추적을 직접 통제할 수 있도록 프라이버시 제어 UI를 강화하는 방향은 이어가고 있습니다.
  • 이처럼 ‘쿠키 폐지’라는 직접 규제는 후퇴했지만, 사용자 통제권 강화와 사파리·애드블록 등 다른 변수는 여전해 퍼스트파티 수집의 중요성은 줄어들지 않았습니다.

2. 이제는 쿠키가 아닌 ‘데이터 수집 경로’를 퍼스트파티화해야 할 때

단순히 쿠키 이름만 자사 도메인으로 굽는 것을 넘어, 데이터가 전송되는 네트워크 경로(도메인)까지 우리 웹사이트 주소와 일치시키는 ‘완전한 퍼스트파티 수집 구조’가 주목받는 이유가 바로 여기에 있습니다.

• 안정적인 식별자 수명: 우리 웹사이트 도메인(A.com) 엔드포인트를 거쳐 서버 레벨에서 쿠키를 제어할 수 있게 되면, 까다로운 사파리 ITP 환경에서도 쿠키 이슈 없이 안정적으로 유지됩니다.
• 애드블록(AdBlock) 우회: 대부분의 광고 차단 프로그램은 알려진 ‘외부 추적 도메인(google-analytics.com 등)’ 리스트를 기반으로 작동합니다. 데이터 수집 주소 자체가 자사 도메인(A.com)으로 위장되면 차단 리스트에 걸리지 않습니다. 즉, 데이터 수집을 위해 브라우저가 구글 도메인과 통신하는 과정을 우회할 수 있습니다.
• 정확한 사용자 식별: 쿠키 수명이 온전히 보존되면서 며칠 후 재방문한 사용자도 새로운 사용자가 아닌 ‘동일 인물’로 정확하게 매칭할 수 있게 됩니다.

내 데이터를 직접 소유한다는 점에서 서버 사이드 GTM과도 맞닿아 있는 개념입니다. 서버 사이드 GTM이 궁금하신 분들은 이 글을 참고해보세요.

3. 태그 게이트웨이의 등장과 발전 과정

데이터 유실이라는 벽을 넘기 위해 구글은 기존 서버 사이드 GTM보다 훨씬 가볍게 퍼스트파티 수집을 구현하는 ‘태그 게이트웨이(Tag Gateway)’를 선보였습니다. 핵심은 데이터 수집 경로를 자사 도메인으로 통합하는 것인데, 그 진입장벽을 크게 낮춘 결정적 계기가 바로 Cloudflare 연동이었습니다.

• Cloudflare 연동: 2024년 10월 비공개 베타를 거쳐 2025년 5월 정식 출시(GA)되었습니다. Cloudflare를 이미 쓰는 기업은 별도 서버 없이 클릭 몇 번으로 퍼스트파티 수집 환경을 구축할 수 있게 됐습니다.
• GCP 직접 배포 옵션: 2026년 1월 5일 GTM 릴리스 노트를 통해, Cloudflare를 쓰지 않는 기업도 구글 클라우드(GCP)에 직접 태그 게이트웨이를 배포할 수 있는 옵션이 베타로 추가됐습니다.

즉 ‘Cloudflare 연동’과 ‘GCP 직접 배포’는 결합된 하나의 인프라가 아니라, 기업의 환경에 따라 선택하는 두 가지 별개의 배포 경로입니다. 이 글은 그중 진입장벽이 가장 낮은 Cloudflare 연동을 중심으로 다룹니다.

• 기술 부채 및 인프라 비용 해결: 과거에는 데이터 경로를 퍼스트파티화하기 위해 매달 비싼 서버 비용을 내며 서버 사이드 GTM 인프라를 직접 관리해야 했지만, 이제 Cloudflare와 GCP를 사용 중인 기업은 GTM 설정 내에서 ‘원클릭’만으로 자사 도메인을 통한 데이터 라우팅이 가능해졌습니다.
• 측정 신호 11% 개선: Cloudflare가 공식 발표한 초기 테스트 결과에 따르면, 태그 게이트웨이를 도입한 광고주들은 평균 약 11%의 측정 신호 향상(uplift in data signals)을 경험했다고 합니다(Cloudflare 공식 블로그). 이는 사파리 ITP의 쿠키 수명 단축을 방어하고 애드블록을 효과적으로 회피하여, 유실되던 데이터가 비교적 온전하게 수집되었음을 보여줍니다.

4. 클라우드플레어(Cloudflare) 사용자를 위한 업데이트

이미 Cloudflare를 CDN으로 사용 중인 기업이라면, 데이터의 퍼스트파티화를 위해 가장 큰 걸림돌이었던 추가 비용과 인프라 관리 문제를 단숨에 해결할 수 있습니다.

1. 이미 갖춰진 인프라, 추가 비용 0원

Cloudflare의 엣지 네트워크를 그대로 활용하기 때문에 별도의 수집용 서버(GCP, AWS 등)를 추가 임대할 필요가 없습니다.

• 비용 절감: Cloudflare 기존 플랜 범위 내에서 작동하므로, 별도 비용이 발생하지 않습니다.
• 통합의 편리함: 기존에 설정된 SSL 인증서와 도메인 보안 설정을 그대로 계승합니다. 복잡한 DNS 설정 없이 클릭 몇 번으로 퍼스트파티 환경이 구축됩니다.

2. Cloudflare 엣지 vs GCP Load Balancer

여기서 한 가지 짚고 넘어갈 점이 있습니다. Cloudflare 연동 방식은 Cloudflare 자체 엣지 네트워크(리버스 프록시) 위에서 동작합니다. 즉, GCP의 부하 분산기를 거치지 않고 Cloudflare 인프라만으로 자사 도메인 라우팅이 완성됩니다.

반면 Cloudflare를 쓰지 않는 기업을 위한 GCP 직접 배포 옵션에서는 구글 클라우드의 External Application Load Balancer(부하 분산기)를 활용합니다. 둘은 같은 인프라가 아니라, 기업 환경에 따라 택일하는 별개의 경로입니다.

💡 로드밸런서(Load Balancer)란?

마치 고속도로의 스마트 톨게이트와 같습니다. 수많은 차량(트래픽)이 몰릴 때 한쪽 차선만 막히지 않도록 여러 차선으로 분산해주고, 사고가 난 차선이 있으면 즉시 다른 길로 우회시켜 흐름을 유지합니다.

• 공통점: 어떤 경로를 택하든, 전 세계에 분산된 엣지/네트워크 인프라를 통해 사용자가 서울에 있든 뉴욕에 있든 가장 가까운 곳에서 태그 데이터를 처리합니다. 덕분에 속도 저하 없이 데이터 수집이 가능합니다.

3. 실제 적용 예시

태그 게이트웨이가 적용되면 브라우저와 추적 도구 사이의 통신 방식이 아래와 같이 바뀝니다.

Before: 서드파티 방식 (차단 위험 높음)

• 경로: browser > googletagmanager.com/gtm.js

• 브라우저 반응: “외부 서비스에서 스크립트를 불러오네? 차단.”

After: 태그 게이트웨이 방식 (데이터 누락 위험 낮음)

• 경로: browser > mycompany.com/metrics/gtm.js
• 브라우저 반응: “자사 도메인(mycompany.com) 내부의 통신이니 정상적인 서비스 기능”

4. 하지만 Cloudflare가 없다면?

태그 게이트웨이의 핵심은 “내 도메인을 거쳐서 데이터를 보내는 것”입니다. 하지만 이를 지원하는 쉽고 빠른 전용 인프라가 없다면 모든 과정을 수동으로 구축해야 하며, 이 과정에서 태그 게이트웨이의 장점이 대부분 사라집니다.

5. 요약: 태그 게이트웨이를 써야 하는 기업의 조건

새로 업데이트된 태그 게이트웨이는 분명 매력적인 업데이트지만, 모든 기업에게 정답은 아닙니다. 우리 회사의 인프라와 목적에 따라 다음과 같이 구분할 수 있습니다.

👍 이런 기업에는 ‘적극 추천’합니다

• Cloudflare를 이미 사용 중인 기업
  • 이유: 추가적인 서버 유지비($0) 없이 기존 인프라를 그대로 활용할 수 있습니다. ‘원클릭’ 설정만으로 데이터 유실률을 즉각적으로 낮출 수 있어 도입하지 않을 이유가 없습니다.
• 구글 광고 및 GA4 비중이 높은 기업
  • 이유: 공식 테스트에서 확인된 ‘평균 약 11%의 측정 신호 개선’ 효과를 가장 직접적으로 누릴 수 있습니다. 광고 성과 측정의 정밀도가 곧 매출로 직결되는 커머스나 플랫폼에 최적입니다.
• 기술 부채를 최소화하고 싶은 마케팅 팀
  • 이유: 복잡한 서버 사이드 GTM(sGTM) 구축 없이도 퍼스트파티 수집 환경을 구현할 수 있어, 개발 리소스가 부족한 팀에게 최고의 대안입니다.

⚠️ 이런 기업에는 ‘신중한 고민’이 필요합니다

• Cloudflare나 GCP 인프라가 없는 기업
  • 이유: 이번 업데이트의 혜택을 받을 수 없습니다. 별도의 로드밸런서를 구축하고 관리해야 하며, 이 과정에서 발생하는 설정 리소스와 인프라 비용이 오히려 부담이 될 수 있습니다.
• 데이터 유실 복구의 ROI가 낮은 기업
  • 이유: 인프라 비용을 들여 유실된 일부 데이터를 되찾았을 때, 그 데이터가 가져다주는 비즈니스 가치(광고 최적화 수익 등)가 비용보다 큰지 냉정하게 따져봐야 합니다.
• 자체 보안 정책이 엄격한 금융/공공 기관
  • 이유: 아무리 자사 도메인을 거친다 해도, 데이터를 전송하는 방식에 대해 내부 보안 검토와 승인 절차가 까다로울 수 있어 사전에 기술적 검토가 선행되어야 합니다.

6. 실무 적용 가이드

Cloudflare를 사용 중인 기업이라면 아래 순서대로 태그 게이트웨이를 적용할 수 있습니다.

1. GTM 컨테이너 → 관리자 탭으로 이동

   

2. Google 태그 게이트웨이 탭으로 이동

   

3. 안내사항을 읽고 [계속] 버튼 클릭

   

4. 도메인을 선택해 스캔한 뒤 Cloudflare를 선택하고 [계속] 버튼 클릭

   

5. 이용 중인 Cloudflare 서비스에 로그인한 뒤 [설정 완료] 클릭

   

7. 마무리

2026년 현재, 데이터 유실 문제는 프라이버시를 강화하려는 브라우저와 이를 우회하려는 추적 도구 사이의 치열한 주도권 싸움에서 발생한 ‘필연적인 공백’입니다. 사파리의 ITP 정책과 크롬의 사용자 선택권 강화, 그리고 일상화된 애드블록 환경 속에서 등장한 구글의 ‘태그 게이트웨이’는 데이터를 우리 자사 도메인 안으로 내재화하여 브라우저의 차단 명분을 없애는 ‘데이터 주권 확보’의 핵심이라 할 수 있습니다.

결국 2026년의 데이터 전략은 단순히 스크립트 도구를 웹사이트에 설치하는 수준을 넘어, 우리 회사의 인프라 구조에 따라 데이터의 해상도가 결정되는 시대로 진입했습니다. 그동안 유실되던 데이터 안에는 우리 서비스의 핵심 고객 신호가 포함되어 있습니다. 태그 게이트웨이 도입 시 측정 신호가 평균 약 11% 개선된다는 결과가 이를 방증합니다. 이렇게 복구한 정밀한 마케팅 시그널은 광고 매체 AI의 머신러닝 최적화와 직결되어, 장기적으로 비즈니스의 격차를 만드는 강력한 경쟁 우위가 됩니다.

이제 데이터 유실을 피할 수 없는 결점으로 받아들이기보다, 우리 서비스가 처한 인프라 환경을 냉정하게 진단하고 태그 게이트웨이와 같은 퍼스트파티 데이터 활용 전략을 통해 흐릿해진 마케팅 데이터의 해상도를 높이고, 데이터 주권 시대를 리드하는 강력한 성장 동력을 확보해야 할 때입니다.