GTM 서버사이드 태깅, 클라이언트 방식과 뭐가 다른가

# GTM 서버사이드 태깅, 클라이언트 방식과 뭐가 다른가

브라우저가 직접 쏘는 방식 vs 서버를 거쳐 전달하는 방식, 2026년 기준 완전 비교

왜 지금 서버사이드 태깅을 이해해야 하는가

웹사이트나 앱에서 발생하는 추적 데이터가 브라우저를 거치지 않고 서버를 통해 전달되는 구조로 바뀌고 있다는 사실을 마케팅 담당자든 개발자든 한 번은 짚고 넘어가야 할 시점이다. 브라우저의 서드파티 쿠키 차단이 강화되고, 애드블록 사용률이 꾸준히 유지되며, 사파리의 ITP(지능형 추적 방지) 같은 정책이 자리 잡으면서, 기존 방식으로 수집하던 전환 데이터의 정확도가 흔들리는 경우가 점점 늘고 있다.

이런 배경에서 구글은 태그 관리자(GTM)에 서버 컨테이너 기능을 제공하고 있고, 최근에는 CDN 기반의 경량 대안인 구글 태그 게이트웨이까지 정식 출시했다. 문제는 이 기술들이 "무조건 도입하면 좋은 것"이 아니라, 트래픽 규모와 조직의 운영 역량에 따라 유불리가 갈리는 선택지라는 점이다.

이 글은 홈페이지나 쇼핑몰을 운영하며 전환 추적 정확도를 고민하는 사람, 마케팅 자동화나 광고 성과 측정을 담당하는 사람, 그리고 서버 인프라 비용까지 감당해야 하는 개발 조직 모두를 대상으로 한다. 클라이언트사이드 태깅과 서버사이드 태깅의 데이터 흐름 차이부터, 실제로 발생하는 서버 유지비, 애드블록·쿠키 정책 대응의 현실적 한계까지 순서대로 짚어보면, 어떤 방식을 선택해야 할지 스스로 판단할 기준이 생길 것이다.

클라이언트사이드 vs 서버사이드, 무엇을 기준으로 비교해야 하는가

두 방식을 비교할 때 가장 먼저 봐야 할 것은 데이터가 어디를 거쳐 어디로 가는가라는 흐름 구조이며, 그 구조 차이가 성능·보안·비용·규제 대응이라는 네 가지 결과로 이어진다. 이 네 가지 축을 이해하면 나머지 판단은 자연스럽게 따라온다.

첫째, 데이터 흐름(경유 경로)이다.
클라이언트사이드는 브라우저가 구글 애널리틱스, 메타 픽셀, 광고 플랫폼 등 각각의 외부 서버로 직접 요청을 쏜다. 서버사이드는 브라우저가 자신이 관리하는 서버 컨테이너 하나에만 데이터를 보내고, 그 서버가 외부 플랫폼으로 재전송한다.

둘째, 성능과 보안이다.
Google 공식 문서는 서버 측 태그 지정을 이용하면 계측을 웹사이트나 앱에서 Google Cloud 기반 서버 측 처리 시스템으로 이전할 수 있으며, 이것이 클라이언트 측 태그 지정에 비해 성능 향상과 보안 강화 이점이 있다고 명시하고 있다.

셋째, 유지비라는 새로운 변수다.
서버사이드는 서버 인스턴스를 직접 운영해야 하므로, 기존에는 없던 월 단위 인프라 비용이 발생한다.

넷째, 쿠키·애드블록 대응력이다.
서버사이드는 퍼스트파티 쿠키 활용과 애드블록 우회에 있어 일부 완화 효과가 있지만, "완전한 해결책"은 아니라는 점을 뒤에서 구체적으로 다룬다.

클라이언트사이드 태깅, 브라우저가 직접 쏘는 기존 방식의 실체

클라이언트사이드 태깅의 핵심은 사용자의 브라우저가 구글·메타 같은 외부 서버로 데이터를 직접 전송한다는 것이며, 이 구조가 도입은 쉽지만 브라우저 환경 변화에 그대로 노출된다는 약점을 만든다. 지금까지 대부분의 웹사이트가 사용해온 방식이 바로 이것이다.

작동 구조를 보면, GTM 웹 컨테이너 스니펫이 페이지에 삽입되고, 사용자가 페이지를 열거나 특정 행동을 하면 브라우저 안의 자바스크립트가 실행되어 구글 애널리틱스, 광고 전환 태그, 메타 픽셀 등 각 플랫폼의 서버로 개별 요청을 보낸다. 태그가 몇 개든 브라우저가 각각 따로 요청을 쏘는 구조다.

강점은 명확하다.
① 별도의 서버 인프라가 필요 없어 초기 도입 비용과 기술 난이도가 낮다
② GTM 웹 컨테이너 하나만 설치하면 대부분의 태그를 즉시 붙일 수 있어 운영 편의성이 높다
③ 이미 시장에 방대한 레퍼런스와 튜토리얼이 쌓여 있어 문제 해결이 상대적으로 수월하다

하지만 약점도 구조적으로 명확하다.
① 브라우저가 외부 도메인으로 요청을 보내기 때문에 서드파티 쿠키 차단, ITP 같은 브라우저 정책 변화에 직접 노출된다
② 애드블록 프로그램이 특정 호스트명이나 경로 패턴을 감지해 요청 자체를 차단하기 쉬운 구조라, 전환 데이터 누락 가능성이 상대적으로 크다
③ 태그 개수가 늘어날수록 브라우저가 처리해야 할 스크립트 실행과 네트워크 요청이 함께 늘어나 페이지 로딩 속도에 영향을 줄 수 있다
④ 클라이언트 측 스크립트는 브라우저 개발자 도구로 누구나 들여다볼 수 있어, 전송되는 데이터 구조가 그대로 노출된다는 보안상의 한계가 있다

정리하면, 클라이언트사이드 태깅은 "빠르게 붙이고 바로 쓸 수 있는" 방식이지만, 브라우저 환경 변화와 애드블록에 대한 방어력이 서버사이드에 비해 상대적으로 약하다는 점을 인지하고 써야 한다.

서버사이드 태깅, 서버 컨테이너를 거쳐 정리해서 보내는 방식의 구조

서버사이드 태깅의 핵심은 브라우저가 자신이 관리하는 서버(구글태그매니저 서버컨테이너)에만 데이터를 보내고, 그 서버가 다시 외부 플랫폼들로 데이터를 정리해 전달한다는 것이며, 이 한 단계가 성능·보안·쿠키 처리 방식을 모두 바꿔놓는다.

작동 구조는 이렇다.
브라우저는 웹사이트 도메인에 연결된 서브도메인(예: sgtm.자기도메인.com)으로만 요청을 보낸다. 이 서버 컨테이너가 Google Cloud의 Cloud Run이나 App Engine 같은 인프라 위에서 실행되며, 받은 데이터를 다듬고 필요한 형태로 가공해서 구글 애널리틱스, 광고 플랫폼, 메타 등으로 재전송한다.

강점을 짚어보면 다음과 같다.
① Google 공식 문서에 따르면 계측을 서버 측 처리 시스템으로 이전하면 클라이언트 측 태그 지정 대비 성능 향상과 보안 강화 효과가 있다고 명시돼 있다
② 브라우저가 여러 외부 도메인이 아닌 자기 도메인의 서브도메인 하나로만 요청을 보내므로, 웹사이트 도메인에 연결된 서브도메인을 퍼스트파티 쿠키로 설정할 수 있어 서드파티 쿠키 차단의 직접적 영향을 덜 받는다는 설명이 있다
③ 서버 단에서 데이터를 가공·필터링·마스킹할 수 있어, 민감 정보를 외부로 그대로 넘기지 않고 통제할 여지가 생긴다
④ 브라우저가 처리해야 할 스크립트·요청 수가 줄어들어 페이지 성능에 유리할 수 있다

반대로 약점도 명확하다.
① 서버를 직접 운영해야 하므로 서버사이드 태깅 비용이라는 새로운 고정비가 발생한다
② 서버 설정·모니터링·장애 대응을 담당할 기술 역량이 조직 내부에 있어야 하며, 없으면 관리형 서비스를 별도로 이용해야 한다
③ 애플 ITP는 자사(퍼스트파티) 쿠키의 수명도 7일 또는 24시간으로 제한할 수 있어, 서버사이드로 옮긴다고 해서 쿠키 수명 문제가 완전히 사라지는 것은 아니다
④ 애드블록은 서버 아키텍처가 아니라 브라우저가 보내려는 요청의 호스트명·경로·파라미터를 검사해 차단하는 방식이라, 서버사이드 태깅 자체만으로 광고 차단을 완전히 우회하지는 못한다는 지적이 있다

결론적으로, 서버사이드 태깅은 "돈과 기술력을 들여서 정확도와 통제력을 높이는" 방식이지 "설치만 하면 모든 문제가 해결되는" 마법 같은 해법은 아니라는 현실 인식이 필요하다.

구글 태그 게이트웨이, 완전한 서버사이드가 아닌 경량 대안의 등장

2026년 6월 Google Cloud에서 정식 출시된 구글 태그 게이트웨이는 CDN 기반으로 구글 태그 스크립트를 자사 도메인에서 서빙하는 경량 대안일 뿐, 완전한 서버 측 처리 기능을 제공하는 것은 아니라는 점을 먼저 이해해야 한다. 서버 컨테이너를 직접 운영할 여력이 없는 경우를 위한 중간 지점 성격의 옵션으로 볼 수 있다.

작동 방식을 보면, 기존 서버사이드 태깅처럼 별도의 서버 인스턴스를 띄워 데이터를 가공·재전송하는 것이 아니라, 구글 태그(gtag.js) 스크립트 자체를 CDN을 통해 자사 도메인 경로로 서빙하는 방식에 가깝다. 즉 "태그 전달의 안정성"과 "퍼스트파티 신호 처리 개선"에 초점이 맞춰져 있고, 서버 컨테이너처럼 데이터를 임의로 가공하거나 여러 플랫폼으로 라우팅하는 유연성은 제한적이다.

강점은 다음과 같이 정리할 수 있다.
① 별도의 서버 인스턴스를 직접 운영하지 않아도 되므로 서버 유지비 부담이 상대적으로 낮다
② 구글 태그 스크립트가 자사 도메인 경로로 서빙되면서, 일부 애드블록 필터가 구글 표준 도메인을 차단하는 패턴에서는 완화 효과를 기대할 수 있다
③ 서버 컨테이너 운영에 필요한 기술 역량 없이도 도입 문턱이 낮다

한계도 명확히 짚어야 한다.
① 완전한 서버 측 처리 기능(다양한 플랫폼으로의 커스텀 라우팅, 서버 단 데이터 가공)은 제공하지 않는다
② 서버 컨테이너 방식만큼의 성능·보안 이점을 기대하기는 어렵다
③ 애드블록 프로그램이 호스트명뿐 아니라 경로·파라미터 패턴까지 검사하는 경우가 많아, 이 방식 역시 완전한 애드블록 우회를 보장하지 않는다
④ 2026년 6월 정식 출시된 지 얼마 되지 않은 기능이라, 장기적인 안정성이나 세부 기능 확장 방향은 계속 지켜봐야 하는 단계다

정리하면, 구글 태그 게이트웨이는 서버 컨테이너를 운영할 조직 역량이나 예산이 부족하지만 클라이언트사이드의 한계를 일부라도 완화하고 싶은 경우를 위한 절충안으로 볼 수 있다. 다만 출시 초기 단계인 만큼 발행 시점 기준으로 기능 범위가 달라졌을 가능성을 감안해야 한다.

세 가지 방식을 비용·성능·대응력 기준으로 종합 비교하면

세 방식을 나란히 놓고 보면, 서버사이드 태깅이 성능·보안·쿠키 대응력에서 앞서지만 그 대가로 서버 운영이라는 고정비와 기술 부담을 떠안아야 하고, 클라이언트사이드는 그 반대이며, 구글 태그 게이트웨이는 그 중간에서 절충점을 찾는 옵션이라는 구도가 명확해진다.

이 표에서 눈여겨봐야 할 것은 애드블록 대응 항목에서 서버사이드와 태그 게이트웨이 모두 "완전 우회 아님"으로 표기했다는 점이다. 애드블록 프로그램은 서버 아키텍처를 판단하는 것이 아니라 브라우저가 보내려는 요청의 호스트명·경로·파라미터를 검사해서 차단 여부를 결정하기 때문에, 어떤 방식을 쓰든 필터 목록에 걸리는 패턴을 완전히 피하기는 어렵다는 구조적 한계가 공통으로 존재한다.

또한 관리형 호스팅 서비스를 이용하는 경우, 월 10,000건 미만 요청 사이트에 한해 무료 요금제를 제공하는 곳이 있고, 유료 요금제는 월 20달러부터 시작한다는 자료가 있어, 직접 인프라를 구축하지 않고 서버사이드 태깅에 진입하는 경로도 존재한다는 점을 함께 참고할 만하다.

소규모 사이트를 운영 중이라면 어떤 방식이 맞을까

트래픽이 크지 않고 서버 운영 인력이 별도로 없는 사이트라면, 클라이언트사이드 태깅을 유지하거나 구글 태그 게이트웨이 같은 경량 대안을 검토하는 편이 현실적이다. 서버 컨테이너 운영에는 최소한의 인스턴스 유지비와 이를 관리할 기술 역량이 필요한데, 트래픽이 적은 사이트에서는 이 투자 대비 얻는 정확도 개선 효과가 크지 않을 수 있기 때문이다.

구체적으로 보면, Cloud Run 방식 기준 최소 2개 인스턴스를 운영해야 데이터 손실 위험을 줄일 수 있다는 것이 구글의 권장 사항이고, 인스턴스 1개당 약 45달러라는 점을 감안하면 최소 월 90달러 수준의 고정비가 발생한다. 월 방문자 수가 많지 않은 사이트 입장에서는 이 비용이 전환 데이터 정확도 개선분보다 클 수 있다.

이런 상황이라면 다음 순서로 검토해볼 만하다.
① 먼저 클라이언트사이드 태깅을 유지하면서 태그 개수를 최소화하고 로딩 성능을 점검한다
② 다음으로 구글 태그 게이트웨이처럼 서버 인스턴스 없이 퍼스트파티 신호 처리를 개선할 수 있는 경량 옵션을 검토한다
③ 그리고 관리형 호스팅 서비스의 무료 요금제(월 10,000건 미만 요청 기준)로 서버사이드 태깅을 소규모로 테스트해본다
④ 마지막으로 트래픽이 실제로 늘어나는 시점에 맞춰 본격적인 서버 컨테이너 도입을 재검토한다

즉, 트래픽 규모가 작은 단계에서는 서버사이드 태깅을 무리해서 도입하기보다, 비용 부담이 적은 옵션부터 단계적으로 테스트하는 접근이 합리적이라는 것이 이 시나리오의 핵심이다.

트래픽이 많고 광고 성과 측정이 핵심인 사이트라면 어떤 방식이 맞을까

전환 광고 예산이 크고 정확한 성과 측정이 매출에 직결되는 사이트라면, 서버사이드 태깅으로 전환해서 얻는 데이터 정확도 개선이 서버 유지비를 상쇄할 가능성이 높다. 이런 사이트는 애드블록으로 인한 전환 데이터 누락, 서드파티 쿠키 차단으로 인한 리타게팅 정확도 저하가 광고 효율에 바로 영향을 미치기 때문이다.

다만 트래픽이 늘어날수록 비용도 함께 늘어난다는 점을 미리 계산해둬야 한다. 트래픽이 많은 사이트는 Cloud Run이 자동으로 5~6개 서버까지 확장되어 월 240~300달러 수준까지 비용이 늘 수 있다는 사례가 보고된다. 이는 서버사이드 태깅이 "한 번 세팅하면 끝"이 아니라 트래픽 규모에 비례해서 계속 관리해야 하는 인프라라는 것을 의미한다.

이런 조건에서 검토할 순서는 다음과 같다.
① 현재 애드블록·쿠키 차단으로 인한 전환 데이터 손실 규모를 먼저 추정해본다
② 서버사이드 태깅 도입 시 예상되는 월 서버 비용(Cloud Run 기준 최소 2개 인스턴스, 확장 시 5~6개까지 가능)을 산정한다
③ 자체 인프라 운영 역량이 부족하다면 관리형 호스팅 서비스의 유료 요금제(월 20달러부터 시작)를 병행 검토한다
④ 서브도메인 기반 퍼스트파티 쿠키 설정으로 얻는 리타게팅·전환 추적 개선 효과를 실제로 측정해본다

중요한 것은 서버사이드 태깅이 애드블록이나 ITP를 완전히 무력화하는 것이 아니라 일부 완화하는 수준이라는 점을 광고 성과 기대치에 미리 반영해야 한다는 것이다. "서버사이드로 옮기면 전환 데이터가 100% 잡힌다"는 기대는 현실적이지 않으며, 애플 ITP는 서버사이드로 옮긴 퍼스트파티 쿠키의 수명도 7일 또는 24시간으로 제한할 수 있다는 사실을 감안한 보수적인 기대치 설정이 필요하다.

비용과 도입 기간, 실제로 얼마나 차이 나는가

서버사이드 태깅으로 전환할 때 가장 큰 차이는 초기 도입 기간과 월 고정비가 새로 생긴다는 점이며, 클라이언트사이드는 이 두 요소가 사실상 거의 없다는 점이 근본적인 비용 구조의 차이다.

클라이언트사이드 태깅은 GTM 웹 컨테이너 스니펫을 페이지에 삽입하고 태그를 설정하는 정도로 끝나기 때문에, 별도의 서버 비용이 발생하지 않고 도입 기간도 짧게 잡을 수 있다.

서버사이드 태깅은 서버 컨테이너를 구축하는 초기 작업(도메인 연결, 서브도메인 설정, 서버 인스턴스 배포)에 시간이 들고, 이후로도 월 단위 인프라 비용이 계속 발생한다.
Cloud Run 방식은 1 vCPU, 0.5GB 메모리 구성 기준 인스턴스 1개당 약 45달러이며, 데이터 손실 위험을 줄이기 위해 최소 2개 인스턴스 운영이 권장된다.
App Engine 방식은 인스턴스당 약 40달러 기준으로 3~6개 서버 운영이 권장된다는 자료도 있어, 출처에 따라 최소 권장 인스턴스 수(2개 vs 3개)와 단가(40~50달러)에 다소 편차가 있다는 점을 참고해야 한다.

트래픽이 늘어나면 Cloud Run이 자동으로 5~6개 서버까지 확장되면서 월 240~300달러 수준까지 비용이 오를 수 있다는 사례가 보고되고 있어, 초기 견적만 보고 판단하기보다 트래픽 증가 시나리오까지 감안한 비용 계획이 필요하다.

직접 인프라를 구축할 여력이 부족하다면 관리형 호스팅 서비스를 이용하는 경로도 있다. 월 10,000건 미만 요청 사이트에는 무료 요금제를 제공하는 곳이 있고, 유료 요금제는 월 20달러부터 시작한다는 자료가 있어, 소규모로 먼저 테스트해보고 트래픽 증가에 맞춰 자체 인프라로 전환하는 단계적 접근도 가능하다.

비용 구조를 정리하면, 클라이언트사이드는 초기·유지 비용이 거의 없는 대신 데이터 정확도의 한계를 안고 가는 구조이고, 서버사이드는 트래픽에 비례해 늘어나는 고정비를 감수하는 대신 정확도와 통제력을 얻는 구조라는 근본적인 트레이드오프를 이해하고 접근해야 한다.

결국 무엇을 언제 선택해야 하는가

결론적으로, 서버사이드 태깅은 "더 좋은 방식"이 아니라 "트래픽과 예산, 기술 역량이 뒷받침될 때 이점이 커지는 방식"이며, 애드블록·쿠키 규제 대응은 어떤 방식을 택하든 부분적 완화 이상을 기대하기 어렵다는 현실을 먼저 받아들여야 한다.

트래픽이 적고 서버 운영 역량이 부족하다면 클라이언트사이드를 유지하거나 구글 태그 게이트웨이 같은 경량 대안부터 검토하는 것이 합리적이다. 반대로 광고 성과 측정이 매출에 직결되고 어느 정도의 월 고정비를 감당할 수 있다면, 서버사이드 태깅으로 전환해 성능·보안·퍼스트파티 쿠키 대응력을 높이는 선택이 투자 대비 효과를 낼 가능성이 크다. 다만 그 어떤 경우에도 "이 방식만 도입하면 애드블록과 쿠키 규제 문제가 완전히 사라진다"는 기대는 접어야 한다.

자주 묻는 질문

Q1. 서버사이드 태깅을 도입하면 애드블록을 완전히 우회할 수 있나요?
아니다. 애드블록 프로그램은 서버 아키텍처가 아니라 브라우저가 보내려는 요청의 호스트명·경로·파라미터를 검사해 차단하는 방식이라, 서버사이드 태깅 자체만으로 광고 차단을 완전히 우회하지는 못한다는 지적이 있다. 부분적 완화 효과로 이해하는 것이 현실적이다.

Q2. 서버사이드 태깅을 도입하면 서드파티 쿠키 차단 문제가 완전히 해결되나요?
완전히는 아니다. 웹사이트 도메인에 연결된 서브도메인을 퍼스트파티 쿠키로 설정할 수 있어 서드파티 쿠키 차단이나 ITP 제약의 직접적 영향은 덜 받지만, 애플 ITP는 자사(퍼스트파티) 쿠키의 수명도 7일 또는 24시간으로 제한할 수 있어 완전한 회피는 아니라는 점을 알아둬야 한다.

Q3. 구글 태그 게이트웨이만 도입하면 서버 컨테이너가 필요 없나요?
경우에 따라 다르다. 구글 태그 게이트웨이는 CDN 기반으로 태그 스크립트를 자사 도메인에서 서빙하는 경량 대안이며, 완전한 서버 측 처리 기능은 제공하지 않는다. 다양한 플랫폼으로의 커스텀 데이터 라우팅이나 서버 단 가공이 필요하다면 여전히 별도의 서버 컨테이너가 필요하다.

Q4. 서버사이드 태깅 비용은 트래픽이 적어도 고정으로 나가나요?
직접 인프라를 구축하는 경우에는 그렇다. Cloud Run 방식은 최소 2개 인스턴스 운영이 권장되며 인스턴스당 약 45달러가 발생하므로, 트래픽과 무관하게 최소 비용이 든다. 다만 관리형 호스팅 서비스 중에는 월 10,000건 미만 요청 사이트에 무료 요금제를 제공하는 곳이 있어, 소규모라면 이런 옵션으로 초기 비용 부담을 줄일 수 있다.

Q5. 서버 컨테이너 운영에 어느 정도의 기술 역량이 필요한가요?
서버 배포·설정·모니터링·장애 대응이 필요하므로, 클라이언트사이드 태깅보다 명확히 높은 기술 역량이 요구된다. 내부에 이런 역량이 없다면 관리형 호스팅 서비스를 이용해 초기 부담을 낮추는 방법이 일반적으로 검토된다.

---

참고 자료
· developers.google.com (Google 서버 측 태그 지정 공식 문서)
· stape.io
· analyticsmania.com
· brunch.co.kr
· experienceleague.adobe.com
· bounteous.com
· supremetracking.io