크롬에서 실제로 무슨 일이 일어났나

전제부터 바로잡고 시작해야 합니다. 구글은 2020년 크롬에서 제3자 쿠키를 단계적으로 폐지하겠다고 발표했지만, 2024년 7월 22일 이 계획을 공식 철회하고 지원을 계속 유지하기로 했습니다. 그리고 2025년 4월, 예고했던 사용자 선택 프롬프트마저 출시하지 않기로 최종 확정됐습니다. 크롬은 새 선택 화면을 띄우지 않고 기존 설정의 쿠키 제어 방식을 유지하며, 서드파티 쿠키는 계속 기본적으로 작동합니다. 폐지 시한도 없습니다.

대체재로 준비되던 쪽도 정리됐습니다. 서드파티 쿠키 대체를 목표로 개발돼온 Privacy Sandbox의 핵심 API 10종이 폐기 대상이 됐고, Topics, Protected Audience, Attribution Reporting 등이 여기 포함됩니다. 크롬 144에서 단계적 폐지가 시작돼 크롬 150 시점의 완전 제거를 목표로 진행되고 있습니다. 다만 전부 사라지는 것은 아닙니다. 파티션된 퍼스트파티 쿠키인 CHIPS, 연합 로그인용 FedCM, 부정 트래픽 판별용 Private State Tokens 세 가지는 폐기 대상에서 제외됩니다.

이 과목의 원 제목이 전제한 상황은 실제로 일어나지 않았습니다. 마감이 사라진 것이지 압력이 사라진 것은 아니라는 점이 다음 절의 내용입니다.

그런데도 준비가 필요한 이유는 어디에 남았나

두 곳입니다. 첫째, 브라우저의 다른 쪽입니다. 애플 사파리와 모질라 파이어폭스는 크롬과 별개로 이미 수년간 기본값으로 제3자 추적 쿠키를 차단해왔습니다. 크롬의 결정과 무관하게 그 사용자들의 데이터는 원래 잡히지 않고 있었습니다.

둘째, 퍼스트파티 쿠키까지 걸리는 제한입니다. 사파리 ITP는 2.1부터 자바스크립트로 생성한 퍼스트파티 쿠키의 수명을 최대 7일로 제한하고, 광고 클릭 파라미터가 붙어 유입된 세션에서 생성되는 쿠키는 24시간으로 더 짧게 제한합니다. 서버가 발급한 쿠키라고 안전하지도 않습니다. 사파리 16.4부터는 서버가 헤더로 발급한 퍼스트파티 쿠키라도 그 서버가 서드파티를 가리키는 CNAME 뒤에 있으면 수명을 동일하게 7일로 제한합니다. 서브도메인을 벤더 서버로 우회 연결하는 구성으로는 이 제한을 피해 갈 수 없다는 뜻입니다.

무엇을 퍼스트파티 데이터로 셀 것인가

용어를 먼저 맞춥니다. 제로파티 데이터는 고객이 자발적으로 브랜드에 직접 제공하는 정보로 선호도나 구매 의도 같은 것입니다. 퍼스트파티 데이터는 자사 채널에서 자사가 직접 수집하는 데이터입니다. 세컨드파티 데이터는 파트너사의 퍼스트파티 데이터를 제휴로 공유받는 것이고, 서드파티 데이터는 직접 관계가 없는 애그리게이터로부터 구매하는 데이터입니다.

이 구분이 필요한 이유는 확보 방법이 전혀 다르기 때문입니다. 제로파티는 물어봐야 얻어지므로 회원가입 항목과 설문 설계의 문제이고, 퍼스트파티는 심어야 쌓이므로 이벤트 설계와 적재의 문제입니다. 로드맵 문서에서 두 축을 섞어 적으면 어느 팀이 무엇을 해야 하는지가 흐려집니다.

1단계, 자사 안에서 사람 단위로 잇는다

첫 작업은 식별 축을 회원 쪽으로 옮기는 것입니다. GA4의 BigQuery Export 스키마에는 이벤트마다 user_id와 user_pseudo_id가 함께 남으므로, 회원 식별자를 보내기 시작하면 사람 단위와 브라우저 단위를 나란히 놓고 볼 수 있습니다. 같은 스키마에 event_params, items, collected_traffic_source가 함께 있어 주문과 유입을 한 줄에서 잇는 것도 가능해집니다.

두 번째 작업은 적재입니다. GA4 이벤트 데이터 보관 기간은 2개월 또는 14개월 중 하나만 고를 수 있고 14개월이 최댓값입니다. 로드맵이 분기 단위 추세를 다루려면 이 기간을 넘겨 남길 방법이 먼저 있어야 하므로, 원시 데이터를 별도 저장소로 내보내는 설정이 1단계 안에 들어갑니다. 순서를 뒤집으면 나중에 비교하려던 기준선이 이미 없어져 있습니다.

2단계, 매체로 내보내는 경로를 해시로 만든다

자사에 쌓인 데이터가 광고 성과로 연결되려면 매체와 이어야 합니다. 개인정보가 오가는 대목이므로 순서를 지킵니다.

메커니즘은 이렇습니다. 해시 매칭 기반 리타게팅은 원본 개인정보를 매체사에 평문으로 전달하지 않고, 광고주와 매체사 양쪽이 동일한 해시 알고리즘으로 각자 데이터를 해싱한 뒤 그 해시값끼리만 비교해 일치 여부를 확인하는 방식입니다. 구글 고객 매치에 올리는 이메일·전화번호·이름은 SHA256 방식으로 해싱해야 하고, 해싱 전에 앞뒤 공백 제거, 소문자 변환, 전화번호의 E.164 형식 정규화가 필요하며 국가와 우편번호는 해싱하지 않습니다. 메타 맞춤 타겟도 SHA-256 단방향 해싱을 쓰고, 업로드된 해시값은 처리 완료 후 삭제된다고 안내합니다.

위험은 정규화 단계에 몰려 있습니다. 규칙이 어긋나면 해시값이 달라져 매칭이 실패합니다. 그래서 원본을 그대로 넘겨 매체에서 처리하게 하는 방식은 권하지 않습니다. 개인정보를 밖으로 내보내지 않는 것이 이 구조의 목적이고, 매칭에 필요한 것은 원본이 아니라 같은 규칙으로 만든 해시값이기 때문입니다. 대안은 정규화와 해싱을 자사 파이프라인 안에 함수로 고정해 두고, 매체별로 다른 요구 규칙만 분기로 처리하는 구성입니다.

3단계, 전송 경로를 서버로 옮긴다

마지막 단계가 수집 경로 자체를 브라우저 밖으로 옮기는 작업입니다. 서버사이드 태깅은 이벤트를 자사 도메인에 호스팅된 서버 컨테이너를 거쳐 보내는 방식으로, 데이터 정확성, 개인정보 제어, 브라우저 부하 감소, 데이터 라우팅 유연성에서 이점이 정리돼 있습니다. 다만 자동 확장 구조라 최대 인스턴스 수와 예산 알림을 함께 걸어두는 것이 도입 조건에 포함됩니다.

진행 상황을 판정할 기준도 여기서 정합니다. 공식 기준이 없는 항목이므로 자사 기준선으로 봅니다. 최소 4주치 기준선을 확보하고, 한 번에 한 항목만 바꾸고, 같은 요일끼리 비교합니다. 지표는 로그인 상태로 발생한 이벤트의 비중, 매체별 매칭률, 매체 전환수와 주문 데이터의 오차율 세 가지면 세 단계의 진척이 각각 보입니다.