웹에서의 개인정보 보호와 개인화: 프라이버시와 타게팅 광고

웹브라우저를 켤 때마다 마주하는 ‘맞춤형’ 광고는 단순한 운이 아닙니다. 과거에는 써드파티 쿠키(Third Party Cookie, 혹은 크로스 사이트 쿠키cross-site cookies)가 사용자의 웹 활동을 다양한 사이트에 걸쳐 추적해 왔으나, 이는 심각한 개인정보 침해 우려를 초래했습니다. 이에 유럽의 GDPR과 미국의 CCPA 같은 법률이 제정되었고, Apple Safari는 Intelligent Tracking Prevention을 도입해 서드파티 쿠키를 기본 차단하기 시작했습니다. Mozilla Firefox 역시 Enhanced Tracking Protection을 통해 서드파티 쿠키 차단을 기본 정책으로 채택하였고, Chrome은 2025년까지 단계적 완전 폐기를 계획 중입니다.

써드 파티 쿠키는 어떤 방식으로 개인정보를 침해했을까요?

써드파티 쿠키는 단순히 ‘내가 어떤 웹사이트를 방문했는가’라는 정보만을 수집하지 않습니다. 다양한 웹사이트에 퍼져 있는 광고 스크립트나 분석 도구를 통해, 사용자의 행동 데이터를 끊김 없이 이어붙여 하나의 사용자 프로파일을 만들어 냅니다. 이 과정을 통해 사용자 개인에 대한 놀라울 정도로 정교한 정보들이 축적될 수 있습니다.

쿠키의 작동 방식을 보여주는 그림

서드파티 쿠키는 사용자가 방문하는 여러 웹사이트에 삽입된 동일한 제3자 스크립트를 통해 작동합니다. 예를 들어, 광고 네트워크 A가 사이트 X, Y, Z에 광고 배너로 삽입되어 있다면, 사용자가 이 세 사이트를 방문하는 동안 광고 네트워크 A는 동일한 쿠키를 통해 사용자의 이동 경로, 클릭 내역, 머문 시간 등을 추적할 수 있습니다. 이렇게 수집된 정보는 단순한 방문 로그를 넘어서 이를 활용해 사용자의 행동을 예측하거나, 고도로 개인화된 광고를 노출하는 데 활용합니다.

 

문제는 이러한 추적이 사용자의 명시적인 동의 없이 진행된다는 점입니다. 처음에는 익명으로 수집되던 데이터라 하더라도, 사용자가 웹사이트에 로그인하거나 이메일 주소를 입력하는 순간, 해당 쿠키 데이터가 특정 인물과 직접적으로 연결될 수 있습니다. 특정 쿠키 ID가 '홍길동@example.com'이라는 실제 사용자와 연결되는 것이죠. 이렇게 수집된 데이터가 사용자와 연결되면서 사용자의 익명성은 사실상 사라지게 됩니다. 그리고 이렇게 수집된 데이터는 단일 기업 내에 머물지 않습니다. 광고 네트워크, 데이터 브로커, 제휴 마케팅 업체 등 다양한 이해관계자들과 교환되거나 판매됩니다. 이러한 데이터 공유는 사용자의 명확한 인지나 동의 없이 이뤄지는 경우가 많으며, 일단 퍼진 데이터는 누가 어떻게 활용하는지 추적하거나 제어하기 어렵게 됩니다.

그렇다면 사용자의 개인 정보를 보호하면서 어떻게 사용자의 취향을 파악하나요?

서드파티 쿠키가 사라진 이후에도 광고 기술은 멈추지 않았습니다. 웹은 여전히 '무료' 콘텐츠로 운영되기 위해 광고 수익에 의존하며, 사용자의 관심사에 맞춘 광고는 그 핵심에 있습니다. 다만, 이제는 개인의 프라이버시를 보호하면서도 개인화된 경험을 제공하는 방향으로 기술이 변화하고 있습니다. 이 과제를 해결하기 위해 Google은 Privacy Sandbox라는 프레임워크를 제안했고, 다양한 브라우저 기술들이 등장하고 있습니다. 그럼 개인 정보 유출은 어떻게 막을 수 있게 되었고 동시에 광고 등 기존에 써드파티 쿠키에 의존하던 기술들은 어떻게 같은 기능을 유지할 수 있게 되었는 지 알아보도록 하겠습니다.

정보 유출 경로 차단

과거에는 광고가 웹사이트의 콘텐츠와 상호작용하면서 사용자의 개인정보를 쉽게 추적할 수 있었습니다. 특히 <iframe>을 이용한 광고 시스템은 부모 페이지와 자유롭게 데이터를 주고받을 수 있었기 때문에 광고는 쉽게 사용자의 활동을 추적할 수 있었습니다. 이를 막기 위해, 이제 Fenced Frame이라는 새로운 기술이 등장했습니다. 이 기술은 광고 등의 외부 콘텐츠가 완전히 독립된 환경에서 실행되도록 만들어줍니다. 기존의 iframe은 호스트 페이지와 postmessage등의 방법을 통해 데이터를 주고 받았지만 Fenced Frame에서는 호스트 페이지와 광고 페이지가 서로 데이터를 주고받을 수 없게 되어, 사용자의 정보가 외부로 유출되는 경로가 차단됩니다. 다만 Attribution Reporting API를 통해서 사용자의 상호 작용을 통제된 방식으로 보고할 수 있습니다.

 

Fenced Frame은 호스트 페이지와의 데이터 교환을 차단하지만, 광고 성과 분석을 위해서는 Attribution Reporting API와 같은 별도의 메커니즘이 필요합니다. Fenced Frame 자체가 광고 성과 분석을 지원하는 것은 아닙니다. 개인 정보를 보호하면서 광고 성과를 측정할 수 있는 방법인 Attribution Reporting API를 알아보기전에 Fenced Frame과 비슷한 역할을 할 수 있는 CHIPS라는 보안이 강화된 버전의 쿠키를 먼저 알아보겠습니다.

CHIPS??

웹사이트를 방문하면, 그 웹사이트(첫 번째 도메인)에서 서버가 사용자의 브라우저로 쿠키를 전송할 수 있습니다. 이 쿠키는 해당 웹사이트의 설정과 로그인 상태, 사용자 선호 설정 등을 저장하는 데 사용됩니다. 이러한 쿠키는 첫 번째 도메인의 첫 번째 파티(웹사이트 자체)에서만 접근할 수 있습니다.

 

하지만 서드파티 쿠키는 조금 다릅니다. 서드파티 쿠키는 웹사이트에 포함된 외부 자원(예: 광고, 분석 스크립트, 소셜 미디어 플러그인 등)이 다른 도메인에서 발행한 쿠키입니다. 예를 들어, 사용자가 shop.com이라는 쇼핑몰에 방문했을 때, 이 웹사이트에 포함된 광고나 추적 스크립트는 ad.com이라는 광고 서버에서 발행된 쿠키를 브라우저에 저장할 수 있습니다. 이 쿠키는 ad.com에 의해 설정되지만, shop.com을 방문할 때마다 사용자의 브라우저에 저장되며 ad.com이 사용자 행동을 추적할 수 있습니다. 여기서 문제가 되는 부분은 ad.com이 shop.com과 같은 다른 도메인에서도 쿠키를 읽고 데이터를 수집할 수 있다는 점입니다.

 

top-level sites가 현재 글에서 말하는 호스트 사이트입니다.

CHIPS는 "Cookies having Independent Partitioned States"의 약자로, 서드파티 쿠키가 다른 도메인 간에 데이터를 추적하고 공유하는 방식에서 발생하는 문제를 해결하려는 기술입니다. 쉽게 말해, CHIPS는 서드파티 쿠키의 공유를 제한하고, 특정 도메인 내에서만 쿠키가 접근될 수 있도록 만드는 기술입니다. CHIPS는 서드파티 쿠키를 상위 도메인별로 파티션하여, 동일한 서드파티 도메인 이 여러 상위 도메인에 임베드되더라도 각 상위 도메인에 종속된 별도의 쿠키 저장소를 사용하게 합니다. 즉, 임베드된 사이트는 각 상위 도메인 내에서만 해당 쿠키에 접근할 수 있으며, 다른 상위 도메인에서는 접근할 수 없습니다. 이를 통해 광고 추적이나 호스트 사이트에서의 상호작용 추적을 차단할 수 있습니다. 예를 들어, 임베드된 사이트가 호스트 사이트의 사용자 행동을 추적하거나, 호스트 사이트가 임베드된 사이트의 쿠키를 읽고 정보를 보는 것을 방지합니다.

익명으로 성과 측정하기

광고 성과를 추적하려면 사용자가 광고를 클릭한 후 어떤 행동을 했는지를 알아야 합니다. 예를 들어, A 사이트에서 광고를 클릭하여 B 사이트로 이동한 후 구매나 다른 활동을 했을 경우, 광고업체는 이를 성과로 측정할 수 있어야 합니다. 그러나 이 과정에서 중요한 점은, 사용자의 개인정보를 보호하는 것입니다. 즉, 사용자가 어떤 경로로 웹사이트에 들어왔고 어떤 행동을 했는지 알 수 있으면서도, 그 정보가 실명으로 추적되지 않도록 해야 합니다.

 

이를 해결하는 기술이 바로 Attribution Reporting API입니다. 이 API는 사용자의 행동을 추적하면서도 개인정보는 보호할 수 있도록 설계되었습니다. 전통적인 광고 추적 방식에서는 사용자가 광고를 클릭한 후 어떤 사이트에서 어떤 행동을 했는지를 추적하기 위해 실명 기반의 데이터나 쿠키를 사용했습니다. Attribution Reporting API는 개인 식별 정보를 완전히 배제하는 방식으로 작동합니다. 사용자의 활동을 추적하되, 그 과정에서 개인정보가 전혀 식별되지 않도록 보장합니다. 사용자가 광고를 클릭하고 다른 웹사이트로 이동한 후, 그 사이트에서 구매나 가입과 같은 전환이 발생했을 때, 이 API는 해시(Hashing) 처리되어 익명화된 집계 정보만을 전달합니다. 즉, 광고주는 사용자가 광고를 클릭한 후 어떤 행동을 했는지 알 수 있지만, 개별 사용자가 누구인지는 알 수 없습니다.

Attribution Reporting API을 나타낸 그림

예를 들어, news.com 사이트에서 광고를 클릭한 후 shop.com사이트로 이동한 사용자가 shop.com 사이트에서 구매를 완료한 상황을 가정해보겠습니다. (광고의 콘텐츠를 제공하는 곳은 ad.com이라고 가정합니다.)

 

사용자가 news.com 사이트에 접속한 후 어떤 방식으로든 광고가 활성화 되면(이미지 광고면 보이는 순간 단순 링크 형식이라면 클릭한 순간) Attribution Source가 등록됩니다. 이 소스가 등록될 때 광고는 ad.com Attribution-Reporting-Eligible 헤더가 포함된 요청을 보내며 응답에는 Attribution-Reporting-Register-Source가 포함됩니다. 응답으로온 Attribution-Reporting-Register-Source 헤더에는 광고주와 페이지에 대한 첫 번째 데이터 및 컨텍스트 데이터, 광고 기술 회사의 출처 정보, 그리고 전환이 발생할 것으로 예상되는 목적지(예시에선 shopping.com) 등이 포함됩니다.

 

이후 사용자가 shop.com에 방문하게 되면 shop.com에서는 사용자의 상호작용 중 전환(마케팅의 목적이 되는 행위)가 발생한다면 Attribution Trigger를 등록합니다. 예를 들어, 사용자가 "장바구니에 추가" 버튼을 누른다면 브라우저는 ad.com으로 Attribution-Reporting-Eligible라는 헤더와 함께 요청을 보내고 응답에는 Attribution-Reporting-Register-Trigger를 보내주는 데 이것이 Attribution Trigger의 등록입니다. 브라우저는 광고 클릭 시 등록된 소스(Source)와 전환 시 등록된 트리거(Trigger)를 매칭하여, 익명화된 보고서를 생성합니다. 이 보고서는 일정한 지연 후에 광고주(ad.com)에게 전달되며, 개인 식별 정보는 포함되지 않습니다.

 

쿠키와 달리, Attribution Reporting API의 데이터는 특정 사이트에서만 접근 가능하며, 다른 곳과는 공유되지 않습니다. 예시의 경우 Attribution Reporting과 관련된 정보는 모두 ad.com에 저장됩니다. news.com은 아무것도 모릅니다. 단지 광고를 게제할 뿐입니다. 반대로 shop.com 또한 전환과 관련된 상호작용에만 trigger를 등록하여 전환의 발생만 Attribution Reporting API에 알릴 뿐입니다. ad.com은 어느 사이트에서 광고를 클릭했었고 이후 전환이 발생했는지에 대한 데이터가 있지만 사용자를 특정할 수는 없습니다.

정보 유출의 탈출구 막기

하지만 ad.com이 큰 회사여서 1000만 개의 사이트에서 광고를 게제한다면 Attribution Trigger로도 개인을 식별할 수 있지 않을까요? 각 사이트의 캠페인 ID를 보고 사용자가 어떤 사이트를 다니는 지 알 수 있을 것만 같습니다.

 

결론부터 말씀드리면 거의 불가능하도록 설계되어 있습니다. 먼저 정보량이 극도로 제한되어 있습니다. 광고와 관련된 캠페인ID와 전환 코드 등 몇 개의 숫자만을 데이터로 가지며 한 사용자가 가질 수 있는 source와 trigger의 개수도 100개로 제한되어 있다고 합니다. 그리고 광고는 앞서 언급한 Fenced Frame에 갇혀 있으므로 트리거 외의 방법으로는 정보를 얻을 수 없습니다. 어떻게든 정보를 얻으려고 해도 개별 정보를 얻을 수는 없고 브라우저의 Aggregation API 통해 전환에 대한 통계만을 볼 수 있습니다. 추가로 리포트에 일부러 오차를 추가하거나 실시간이 아닌 몇 시간에서 며칠 후의 리포트를 받는 등의 방지 대책도 있다고 합니다.

개인정보 없이 관심사 기반 타겟팅

이제 개인 정보를 보호하면서 광고의 성과를 추적할 수는 있게 되었습니다. 하지만 요즘의 광고는 개인의 관심사를 기반으로 광고의 효과를 높이려고 하고 실제로도 관심사 기반 광고가 여전히 작동하고 있습니다. 예를 들어 자전거에 관심 있는 사람에게 자전거 광고가 나가면 클릭할 가능성도 높고, 실제로 구매로 이어질 확률도 높아지죠. 하지만 이렇게 광고를 잘 보여주려면 결국 “이 사람이 뭘 좋아하는지”를 알아야 하는데, 그걸 알아내려면 개인정보를 들여다보는 게 필요한게 아닐까요? 어떻게 써드 파티 쿠키를 통한 정보 제공없이 타게팅된 광고를 볼 수 있을까요?

 

Topics API는 사용자의 웹 브라우저가 직접 사용자의 관심사를 파악해서 광고주에게 간단한 '주제 정보'만 전달하는 방식입니다. 예를 들어, 어떤 사용자가 요즘 자주 자전거 리뷰 블로그, 해외여행 후기, 간편식 요리법 사이트를 본다고 해볼게요. Topics API는 이 사용자가 '자전거', '여행', '요리'에 관심이 있을 수 있다고 판단하고, 해당 주제를 광고주에게 전달합니다. 기존의 서드 파트 쿠키가 사용자의 방문 기록 자체를 전달하는 것과 달리 사용자가 방문한 정확한 사이트 주소는 광고주에게 절대 전달되지 않습니다.

 

대신 사용자가 많이 방문한 사이트를 보니 "이 사용자에게 자전거, 여행, 요리 같은 주제가 관심사로 보입니다”라는 정보만 브라우저가 전달하는 것입니다. Topics API는 사용자의 최근 웹 활동을 기반으로 상위 5개의 관심 주제를 추론하며, 각 에포크(기본적으로 1주일)마다 이 중 하나를 무작위로 선택하여 광고주에게 제공합니다. 너무 자세한 정보를 제공하지 않음으로 개인 정보를 보다 확실히 보호하는 것이죠. 예를 들어 크루와상 레시피를 자주 검색하면 제빵 혹은 요라라는 주제까지만 전달하여 개인 정보를 더 보호합니다. 또한, 5%의 확률로 무작위 주제가 선택되어 추가적인 프라이버시 보호를 제공합니다. 

 

단, 현재 Topics API는 W3C에서 아직 논의 중인 초안(draft) 상태이고, 정식 웹 표준은 아니며 Mozila의 FireFox와 apple의 Safari는 해당 사양을 반대하고 있습니다. 따라서 변경될 가능성도 있습니다. 위의 내용은 Google Developers를 기반으로 이해한 내용을 정리한 것입니다.

 

결론

개인정보 보호와 광고 성과 추적 사이의 균형을 맞추기 위해 새로운 기술들이 등장했으며, Privacy Sandbox, Fenced Frame, CHIPS, Attribution Reporting API 등이 이를 해결하는 중요한 방법으로 자리잡고 있습니다. 이러한 기술들은 광고의 개인화된 경험을 유지하면서도 사용자 개인정보를 보호할 수 있는 가능성을 제공하고 있습니다.

참고 자료

MDN, Third-party cookies, Attribution Reporting API
Webkit, Intelligent Tracking Prevention
Google Developers, 웹용 Topics API, 독립적인 파티션 상태가 있는 쿠키 (CHIPS)