왜 서버가 발급한 쿠키는 다르게 취급되나

ITP가 겨냥하는 것은 자바스크립트(document.cookie)로 만드는 쿠키입니다. 이 방식은 광고·분석 스크립트가 브라우저 안에서 직접 쿠키를 심는 전형적인 추적 패턴이기 때문에 애플이 정조준한 대상입니다. 반면 서버가 HTTP 응답의 Set-Cookie 헤더로 직접 발급하는 쿠키는 원칙적으로 이 자바스크립트 기반 제한을 받지 않고, 서버가 지정한 Max-Age 또는 Expires 값을 그대로 유지할 수 있습니다. 서버사이드 GTM 구조에서는 서버 컨테이너가 클라이언트 ID 쿠키를 이 방식(Set-Cookie 헤더)으로 직접 발급하도록 설정할 수 있어, 기존 7일 제한보다 긴 수명(예: 1년 이상)을 유지하는 것이 가능해집니다.

실제로 어떻게 설정하나

GA4 서버 태그 설정에는 클라이언트 ID 쿠키의 만료 기간을 지정하는 옵션이 있습니다. 이 값을 원하는 기간(예: GA4 기본값과 유사한 수준)으로 설정하면, 서버 컨테이너가 응답할 때마다 Set-Cookie 헤더로 이 만료 기간을 갱신해 발급합니다. 이 과정이 정상 작동하려면 앞서 4강에서 다룬 퍼스트파티 도메인 바인딩이 먼저 완료돼 있어야 합니다 — 서버가 구글 소유의 기본 도메인으로 응답하면 그 쿠키 자체가 서드파티 쿠키로 취급돼 별도 제한을 받을 수 있기 때문입니다.

왜 이 복원이 "영구"가 아니라 "조건부"인가

2023년 4월 출시된 Safari 16.4는 이 서버 쿠키 복원 방식을 겨냥한 대응책을 내놨습니다. 서버가 발급한 쿠키라도, 그 서버가 서드파티를 가리키는 CNAME 뒤에 있거나 응답 서버의 IP 주소 앞부분이 실제 방문 중인 사이트 서버와 불일치하면 "의심스러운 서버"로 판정해 쿠키 수명을 동일하게 7일로 제한합니다. 즉 4강에서 다룬 것처럼 서버 컨테이너가 실제로 자사가 통제하는 인프라에서 응답하는 구조여야 이 복원이 유지되고, 벤더의 프록시 서버를 얕게 가리키는 CNAME 설정만으로는 Safari 16.4 이후 다시 7일로 되돌아갈 수 있습니다.

"합법적"이라는 표현의 의미를 정확히 짚어야 한다

이 기술은 ITP의 우회가 아니라 애플이 명시적으로 열어둔 경로(서버 발급 쿠키에 대한 별도 취급)를 정상적으로 활용하는 방식입니다. 다만 이 경로 자체도 애플이 계속 감시·조정하는 대상이라는 점(Safari 16.4의 CNAME 클로킹 대응이 그 사례)을 감안하면, "한 번 설정하면 끝"이라는 인식보다는 브라우저 정책 변화에 맞춰 주기적으로 재검증이 필요한 기술로 접근하는 편이 안전합니다. 또한 쿠키 수명을 늘리는 것과 개인정보 처리 동의(쿠키 동의 배너 등 자사의 프라이버시 정책·법적 요건)는 별개의 문제이므로, 수명을 늘리기 전에 자사 개인정보처리방침·동의 흐름과 충돌하지 않는지 법무 검토를 함께 거치는 것이 안전합니다.

크롬·다른 브라우저에서는 이 설정이 어떤 의미를 갖나

이 강의에서 다루는 쿠키 수명 제한은 Safari ITP를 중심으로 한 정책이라, 크롬이나 파이어폭스 등 다른 브라우저에서는 같은 방식의 7일 제한이 적용되지 않을 수 있습니다. 다만 크롬도 서드파티 쿠키를 단계적으로 축소하는 방향으로 정책을 계속 조정하고 있어, 서버가 직접 발급하는 퍼스트파티 쿠키 방식은 브라우저 정책 변화에 상대적으로 덜 흔들리는 구조라는 점에서 Safari 이외의 브라우저에도 유효한 대응 전략입니다. 즉 이 강의의 설정은 "Safari만을 위한 예외 처리"가 아니라, 브라우저 전반의 프라이버시 강화 추세에 대응하는 공통 인프라로 접근하는 편이 장기적으로 유리합니다.

재검증 주기를 실무에 어떻게 반영하나

이 과목 12강에서 다룰 공식 문서 업데이트 추적 프로토콜과 연결지어, 쿠키 수명 복원 설정도 정기 점검 항목에 포함해두는 것이 안전합니다. 브라우저 정책이 바뀌는 시점(예: Safari 신규 버전 출시)마다 개발자도구로 실제 쿠키 수명을 직접 확인하는 루틴을 분기 1회 정도로 고정해두면, 정책 변화로 조용히 수명이 다시 7일로 줄어드는 상황을 조기에 포착할 수 있습니다.