퍼스트 파티 도메인 바인딩: 추적 서버의 주소를 자사 메인 도메인의 서브 도메인(예: ://mybrand.com)으로 설정하여 브라우저 차단 우회하기

서버 컨테이너를 App Engine이나 Cloud Run에 배포하면 구글이 기본으로 부여하는 도메인(예: xxxx.appspot.com, xxxx.run.app)이 생깁니다. 문제는 이 기본 도메인이 구글 소유 도메인이라는 점입니다. 브라우저와 광고 차단 필터 리스트 입장에서는 이 주소가 여전히 "구글 서버로 가는 요청"으로 보이기 때문에, 서버사이드로 전환한 의미가 반감됩니다.

이를 해결하는 방법이 퍼스트파티 도메인 바인딩입니다. 자사가 소유한 메인 도메인의 서브도메인(예: track.mybrand.com, analytics.mybrand.com)을 만들어 그 서브도메인이 서버 컨테이너를 가리키도록 DNS를 설정합니다. 이렇게 하면 브라우저의 네트워크 요청 로그에는 "mybrand.com의 하위 도메인"으로 기록되어, 필터 리스트가 매체 도메인을 직접 겨냥해 만든 차단 규칙에 걸리지 않게 됩니다.

많은 실무자가 "서브도메인만 자사 것처럼 보이면 영구적으로 우회가 된다"고 오해하지만, 이는 2023년 4월 출시된 Safari 16.4부터 더는 사실이 아닙니다. 애플은 이 우회 방식(CNAME 클로킹)을 겨냥해, 서브도메인이 실제로는 서드파티 인프라를 가리키는 CNAME 레코드로 연결돼 있거나, 응답하는 서버의 IP 주소 앞부분이 사용자가 방문 중인 사이트의 실제 서버와 불일치하면 "의심스러운 서버"로 판정합니다. 이렇게 판정되면 그 서버가 발급한 쿠키도 자바스크립트 쿠키와 동일하게 최대 7일로 제한됩니다.

즉 도메인 이름만 자사 브랜드처럼 바꾸고 실제로는 벤더의 프록시 서버를 그대로 가리키는 얕은 CNAME 설정으로는 이 판정을 피하기 어렵습니다. 우회 판정을 피하려면 서버 컨테이너가 실제로 자사가 통제하는 인프라(자사 명의의 클라우드 프로젝트, 자사 IP 대역)에서 직접 응답하는 구조여야 합니다.

일반적인 흐름은 다음과 같습니다. 먼저 자사 메인 도메인의 DNS 관리 화면에서 서브도메인 레코드를 새로 만듭니다. 이 레코드가 서버 컨테이너(App Engine·Cloud Run 등)의 주소를 가리키도록 CNAME 또는 A 레코드를 설정합니다. 이후 그 서브도메인에 대한 HTTPS 인증서를 발급받아 연결하고, GTM 웹 컨테이너의 설정에서 서버 컨테이너 URL을 새 서브도메인 주소로 변경합니다. 마지막으로 미리보기 모드로 실제 요청이 새 도메인을 통해 정상적으로 서버 컨테이너까지 도달하는지 확인하는 검증 단계를 거칩니다.

여러 브랜드나 여러 도메인을 운영하는 조직이라면, 서버 컨테이너 하나를 여러 도메인이 공유하도록 설계할지, 도메인별로 서버 컨테이너를 분리할지부터 정해야 합니다. 공유 구조는 인프라 관리가 단순하지만, 서브도메인이 브랜드마다 다른 실제 서버(공유 서버 컨테이너)를 가리키게 되므로 도메인·서버 소유 관계가 애플의 CNAME 클로킹 판정 기준과 어떻게 맞물리는지 케이스별로 확인이 필요합니다. 이 판단은 인프라 구조가 확정된 뒤 실제 브라우저(특히 Safari)에서 쿠키 수명을 직접 검증하는 절차로 확인하는 편이 안전합니다.

서브도메인 이름 자체는 임의로 지어도 기능상 문제는 없지만, track. analytics. 처럼 지나치게 추적 목적을 명시적으로 드러내는 이름은 향후 필터 리스트가 패턴 기반으로 차단 규칙을 갱신할 때 다시 표적이 될 가능성을 배제할 수 없습니다. 반대로 서비스 운영에 실제로 쓰이는 다른 서브도메인(예: API 서버가 쓰는 서브도메인)과 명확히 구분되지 않으면 운영·보안 관리가 꼬일 수 있으므로, 추적 목적임을 인지할 수 있으면서도 지나치게 노골적이지 않은 이름을 택하는 것이 실무에서 흔히 쓰는 절충안입니다.

이 강의에서 다루는 도메인 바인딩은 애플의 정책을 속이거나 피해가는 기술이 아니라, 애플이 열어둔 "퍼스트파티 서버가 발급한 쿠키"라는 정상 경로를 활용하는 것입니다. 다만 그 정상 경로로 인정받으려면 실제로 자사가 통제하는 인프라여야 한다는 조건이 있고, Safari 16.4의 CNAME 클로킹 대응은 바로 이 조건을 검증하기 위한 장치입니다. 이 구분을 팀 내에서 명확히 공유해두면, 나중에 이 설정이 왜 작동하고 왜 가끔 재검증이 필요한지를 개발팀·법무팀에 설명할 때도 오해 없이 전달할 수 있습니다.