A03(마케팅데이터측정)에서 다룬 구글 태그 매니저(GTM)는 대부분 브라우저(클라이언트) 안에서 동작하는 컨테이너였습니다. 방문자의 브라우저에 스크립트가 실행되고, 그 스크립트가 각 매체(구글 애즈, 메타 픽셀 등)로 직접 데이터를 쏘는 구조입니다. 이 방식은 설치가 간단하다는 장점이 있지만, 브라우저 확장 프로그램의 광고 차단, 사파리·파이어폭스의 트래킹 방지 정책(114-1강에서 다룬 ITP·ETP)에 그대로 노출된다는 약점이 있습니다. 서버사이드 태깅은 이 스크립트가 브라우저에서 각 매체로 직접 쏘는 대신, 일단 광고주가 관리하는 서버(또는 클라우드 컨테이너)로 데이터를 모은 뒤, 그 서버가 각 매체로 다시 전달하는 구조로 바꾸는 것입니다.
116과목 3강에서 다룬 데이터 파이프라인 설계를 떠올려보면, 그 흐름은 "소스 시스템 → 수집(SDK·API·웹훅) → 원시 데이터 저장 → 정제 → Identity Resolution"이었습니다. 서버사이드 태깅 컨테이너는 정확히 이 흐름의 "수집" 단계에 해당합니다. 브라우저가 아니라 광고주가 통제하는 서버가 1차 수집 지점이 되면, 그 서버는 자연스럽게 CDP로 데이터를 흘려보내는 파이프라인의 출발점이 될 수 있습니다. 즉 서버사이드 태깅 도입은 "광고 태그를 조금 더 안정적으로 심는 기술적 선택"이 아니라, "데이터 수집의 통제권을 브라우저에서 광고주 인프라로 옮기는" CDP 인프라 결정의 첫 단계입니다.
클라이언트사이드 방식에서는 방문자 브라우저가 동시에 여러 매체(구글, 메타, 카카오 등)로 각각 별도 요청을 보냅니다. 이 요청 각각이 광고 차단 확장 프로그램이나 브라우저 자체 추적 방지 정책에 개별적으로 걸릴 수 있어, 매체마다 데이터 유실률이 다르게 나타나는 문제가 있습니다. 또한 브라우저에서 실행되는 스크립트는 그 코드가 그대로 노출되므로, 어떤 데이터를 어디로 보내는지 외부에서 확인 가능하다는 보안상 약점도 있습니다.
서버사이드 태깅은 방문자 브라우저와 광고주 서버 사이의 통신을 한 번만 거치게 만들어, 광고 차단 확장 프로그램에 걸리는 지점을 줄여줍니다. 또한 서버 단에서 데이터를 한 번 정제·검증한 뒤 각 매체로 내보낼 수 있어, 114-5강에서 다룬 해싱·정규화 같은 작업을 서버 쪽에서 일괄 처리하기에도 유리합니다. 다만 서버사이드 태깅 자체가 114-1강에서 다룬 사파리·파이어폭스의 서드파티 쿠키 차단 문제를 없애주지는 않습니다. 브라우저가 애초에 쿠키를 저장하지 않으면 서버가 아무리 잘 정리해도 그 쿠키를 읽을 방법이 없기 때문입니다. 서버사이드 태깅은 "데이터 유실을 줄이는" 기술이지, "쿠키리스 문제를 해결하는" 기술이 아니라는 점을 구분해야 합니다.
서버사이드 태깅 컨테이너를 새로 세팅하려면 클라우드 인프라(대개 GTM 서버사이드 컨테이너는 구글 클라우드 위에서 동작)를 운영할 개발 리소스가 필요합니다. 마케팅팀 단독으로 전환할 수 있는 작업이 아니라, 116과목 3강에서 다룬 것처럼 데이터 엔지니어링 인력의 참여가 필수입니다. 또한 서버 비용(클라우드 컴퓨팅 비용)이 별도로 발생하므로, 전환 전에 이 비용을 감당할 만큼 트래픽 규모와 광고 예산이 확보돼 있는지도 함께 판단해야 합니다. 트래픽이 적은 소규모 계정에서는 서버 운영 비용 대비 얻는 데이터 품질 개선폭이 작을 수 있습니다.
[클라이언트 vs 서버사이드 태깅 전환 검토 체크리스트]
1. 현재 데이터 유실 신호
- 매체별 전환 리포트 수치가 GA4 등 자사 로그 대비 몇 % 차이 나는가:
- 사파리·iOS 트래픽 비중(114-1강 기준 30% 이상이면 우선 검토):
- 광고 차단 확장 프로그램 사용률 추정(가능하면 사내 로그로 확인):
2. 조직 리소스 조건
- 클라우드 인프라(서버 컨테이너)를 운영할 개발 인력이 있는가: [ ] 있음 [ ] 없음 [ ] 외주 검토
- 서버 비용을 감당할 광고 예산·트래픽 규모인가: [ ] 예 [ ] 아니오
- 데이터 엔지니어링팀과 정기 협업 체계가 있는가(116-12강 참고): [ ] 예 [ ] 아니오
3. 전환 우선순위 매체
- 유실률이 가장 큰 매체부터 순서를 매긴다:
1순위:
2순위:
3순위:
4. 전환 이후 CDP 연동 계획
- 서버 컨테이너가 CDP 파이프라인의 수집 층(116-3강)으로 확장될 여지가 있는가: [ ] 예 [ ] 아니오
- 확장한다면 어떤 이벤트부터 CDP로 넘길 것인가:
5. 판단
- 지금 전환할 것인가, 보류할 것인가:
- 보류한다면 재검토 시점(예: 트래픽 2배 성장 시):
18강에서는 CDP를 상용 벤더로 도입할지, 자체 구축할지를 판단하는 기준을 다룹니다. 이번 강에서 정리한 서버사이드 태깅 검토 결과가 그 판단의 입력값 중 하나가 됩니다.