쿠키리스 대응 애드옵스 고도화: 브라우저 서드파티 쿠키 전면 제한에 따른 서버사이드 추적(GTM Server-side) 전용 자사 도메인(DNS) 매핑 및 쿠키 수명 연장

Safari의 ITP(Intelligent Tracking Prevention)는 자바스크립트(document.cookie)로 생성한 퍼스트파티 쿠키의 수명을 최대 7일로 제한합니다. 게다가 광고 클릭 링크에 추적 파라미터가 붙어 유입된 세션에서 생성되는 쿠키는 24시간으로 더 짧게 제한됩니다. 이 제한 때문에 Safari 사용자를 대상으로 한 장기 리타게팅이나 어트리뷰션 정확도가 크게 떨어지는 문제가 생깁니다.

이 제한은 클라이언트 측(브라우저 자바스크립트)에서 만든 쿠키에 적용되는 것이라, 서버 측에서 쿠키를 발급하는 방식으로 전환하면 이 제한을 우회할 여지가 생깁니다.

Safari 16.4부터는 서버가 Set-Cookie 헤더로 발급한 쿠키라도, 그 서버가 서드파티를 가리키는 CNAME 뒤에 있거나 IP 주소가 실제 방문 중인 사이트 서버와 불일치하면 '의심스러운 서버'로 판정해 동일하게 7일로 제한합니다. 즉 단순히 서버사이드 방식으로 전환한다고 해서 자동으로 제한을 피할 수 있는 것은 아닙니다.

이 우회 탐지 로직은 "서브도메인만 자사 도메인처럼 보이면 무조건 쿠키 수명이 복원된다"는 통념을 반박합니다. 서버 컨테이너가 실제로 자사 인프라(자사 IP 대역)에서 응답해야 우회 대상에서 제외되며, 단순 프록시로 벤더 서버를 가리키기만 하면 여전히 제한을 받을 수 있습니다.

GTM 서버사이드 컨테이너를 자사가 소유한 클라우드 인프라(GCP App Engine, Cloud Run 등)에 직접 배포하고, 그 인프라를 자사 도메인의 서브도메인(예: data.자사도메인.com)으로 정확히 매핑해야 합니다. 단순히 벤더가 제공하는 프록시 서비스에 서브도메인만 연결하는 방식은 CNAME 클로킹 탐지에 걸릴 위험이 있으므로, 실제 인프라가 자사 소유의 IP 대역에서 응답하도록 구성하는 것이 중요합니다.

이 구현은 상당한 기술적 작업을 요구하므로, 애드옵스 담당자나 개발팀과 함께 인프라 설계 단계부터 진행해야 합니다.

서버 컨테이너를 App Engine에 배포할 때는 프로덕션 환경 기준으로 서버 3~6대 구성, 서버 1대당 월 약 40달러가 표준 사이징 기준으로 제시됩니다. Cloud Run으로 배포하면 트래픽에 따라 동적으로 확장되며, 최대 인스턴스 수 설정값이 이론상 지불할 수 있는 최악의 비용 상한으로 작동합니다. 이 상한을 설정하지 않으면 트래픽 폭증 시 비용이 통제 불능으로 늘어날 수 있으므로, 인프라 구축 초기부터 이 상한값을 반드시 설정해야 합니다.

서버사이드 태깅으로 전환했다고 해서 모든 데이터 유실 문제가 해결되는 것은 아닙니다. 전환 이후에도 실제로 쿠키 수명이 연장됐는지, 이벤트 수집률이 개선됐는지를 클라이언트 단 데이터와 비교해 정기적으로 검증해야 투자한 인프라가 실제로 효과를 내고 있는지 확인할 수 있습니다.

서버사이드 태깅은 그 자체로 독립된 프로젝트처럼 보이지만, 실제로는 이전 레슨에서 다룬 태그 통합 관리·데이터 레이어 표준화 위에서만 제대로 작동하는 인프라입니다. 데이터 레이어 변수명이 페이지마다 제각각이거나 GTM 태그의 실행 순서가 정리돼 있지 않은 상태에서 서버사이드 컨테이너부터 먼저 구축하면, 서버로 전달되는 데이터 자체가 이미 불완전해 인프라 투자의 효과를 제대로 검증하기 어렵습니다.

따라서 서버사이드 전환을 계획하는 조직이라면, 이 전환에 앞서 데이터 레이어 표준화와 태그 관리 체계가 먼저 자리 잡혀 있는지 점검하는 순서가 실무적으로 더 안전합니다.

쿠키리스 대응이라고 하면 Chrome의 서드파티 쿠키 제한을 먼저 떠올리기 쉽지만, 이 레슨에서 다루는 Safari ITP는 서드파티 쿠키가 아니라 퍼스트파티 쿠키의 수명 자체를 제한한다는 점에서 성격이 다릅니다. 즉 자사 도메인에서 자사가 직접 발급한 쿠키조차 Safari에서는 7일로 제한될 수 있다는 뜻이며, 이는 서드파티 쿠키 차단보다 더 근본적인 제약입니다. 여러 브라우저의 쿠키 정책이 각각 다른 방식으로 데이터를 제한하고 있다는 점을 이해해야, 하나의 대응책으로 모든 브라우저 문제를 해결할 수 있다는 오해를 피할 수 있습니다.

이 때문에 서버사이드 태깅 인프라를 설계할 때는 Safari, Chrome을 포함한 주요 브라우저별 정책 차이를 각각 별도로 문서화해두고, 새로운 브라우저 정책 변경이 발표될 때마다 그 문서를 갱신하는 루틴을 함께 운영하는 것이 바람직합니다.