본문 바로가기

Web

Cookie 쿠키 와 3rd party cookie

여-어

광고 쪽에서는 워낙 핫한 주제고 최근 브라우저나 매체, OS단까지 정책이 워낙 급변하고 있기 때문에 한번은 다뤄야 하는데, 제대로 다루려면 두시간 컷도 모자라서 딱 궁금한거 위주로만 적어보려 한다. 우리 부서 쿠키 다루는 모듈 이름이 쿠키몬스터다. 짱귀엽죠?

 

쿠키의 정의

http쿠키, 웹 쿠키, 브라우저 쿠키라고도 한다. "하이퍼 텍스트의 기록서(HTTP)의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를 통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일" (wikipedia) 이라고 하는데, 그래서 '소프트웨어'는 아니고 임시 파일에 가깝다는 것. 

 

 

쿠키가 하는 일

대체로 로그인 상태, 검색 기록, 사이트 환경설정 유지에 쓰이기 때문에 같은 사이트를 재방문했을 때 도움이 된다.

https://www.youtube.com/watch?v=QWw7Wd2gUJk / 이런 사태를 방지하도록 로그인 된 상태를 유지하기 위해 쿠키를 사용.

 

구글의 쿠키 사용법 이라는 문서를 살펴보면, "사용자가 선호하는 언어를 기억하고, 사용자에게 더 관련성 높은 광고를 제공하고, 페이지 방문자 수를 기록하고, 사용자가 Google 서비스에 가입하도록 지원하고, 사용자의 데이터를 보호하며, 사용자의 광고 설정을 기억하기 위해 쿠키를 사용"한다고 한다. 특히 커머스에서는 장바구니 정보를 저장하는 데에도 유용하다. 로그인하지 않고 장바구니에 물건을 담아두고, 얼마 후에 그 사이트에 비로그인 상태로 방문해도 장바구니는 그대로 유지되어 있는 경우를 상기해보면 좋다. 실제로 1994년 Netscape에 의해 쿠키가 만들어졌을 때, 최초 목적은 커머스 사이트에서의 카트 유지였다. 클라 쪽에서 보관해야 서버의 부담이 줄어들 테니까. 또 맞춤형 광고에 활용한다는 점  활용 때문에 최근에 3rd party cookie가 상당히 핫한 주제가 되었다. (사실 쿠키를 처음 만든 Montulli는 이 때문에 쿠키를 발명한 것을 후회한다고 인터뷰했다.)

 

쿠키가 필요한 이유

  • HTTP는 근본적으로 stateless(무상태성)을 기본으로 한 프로토콜이기 떄문에, 쿠키를 이용해 이를 보완
  • 참고: 왜 HTTP는 "stateless"한가? HTTP가 애초에 파일 전송 프로토콜이었기 때문이다. 
  • HTTP is called as a stateless protocol because each request is executed independently, without any knowledge of the requests that were executed before it, which means once the transaction ends the connection between the browser and the server is also lost.
    • make a request for a file named by a URL,
    • get the file in response,
    • disconnect.
  • What makes the protocol stateless is that in its original design, HTTP is a relatively simple file transfer protocol:

 

쿠키의 동작

클라 단에서 생성/저장될 수도 있고, 서버에서 전송한 쿠키가 클라이언트에 전송될 수도 있다. example.com 이란 사이트에 접근할 때 서버가 클라(브라우저)에 쿠키를 전달하고, 브라우저는 동일 서버에 다른 요청을 보낼 때 쿠키를 전송한다.

By Tizio - 자작, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1577024

 

쿠키의 구성

키key / 값value 으로 구성되는데, 거기에 더해 만료시간 등을 미리 선언한다. 가령 지금 이 편집창에서 생성된 쿠키들은 아래와 같다. 4KB가 넘지 않는 작은 사이즈. 

 

물론 이 티스토리에는 광고가 없으니까 쿠키도 얼마 없는데, 경향신문 같은 매체에 들어가보면 쿠키 수가 어마어마한 것을 볼 수 있다. 크리테오, 유튜브, 데이블 같은 익숙한 이름들도 많이 보이고.

 

 

잠깐: 쿠키랑 캐시는 뭐가 달라?

참고로 같은 사이트를 재방문할 때 도움이 되는 또 다른 요소로 캐시cache가 있는데, 캐시의 개념은 쿠키와는 다르다. 캐시의 목표는 웹 페이지의 요소 (이미지 등)를 저장해놓아서 재방문 시 렌더링을 빠르게 하려는 목적이 크고, 쿠키는 사용자 인증이나 설정 복원의 목적이 더 크다. 그래서 웹 배포 한 다음에 "배포 안 된 것 같은데요?" 하면 쿠키가 아니라 "캐시 지워보세요"라고 하는 거고.

(프론트 개발자가 굉장히 짜증내는 부분이므로... 그냥 처음부터 시크릿 모드로 테스트해보는 게 좋다)

(그럼 배포가 이루어진 파일은 어떻게 교체가 이루어지는가? 이거에 대해서는 토스 테크 글에 잘 정리되어 있다.)

 

StackOverflow의 쿠키 약관 구경하기

쿠키를 활용하고 있는 (대부분의) 사이트에는 개인정보보호약관에 쿠키의 활용 범위를 명시하게 된다. StackOverflow 쿠키 약관을 한번 살펴보면 사이트의 정상적인 운용을 위해 1st-party 쿠키를 사용하는 것, 그 외의 광고 등 활용을 위해 3rd party 쿠키를 사용한다고 한다. 

Our third party partners and other organizations that sponsor pages on Stack Overflow may use cookies or other technologies to learn more about your interest in their products and services and in some cases to tailor such products and services to you.
Third-Party Cookies: Our services also include cookies from third parties that we partner with or which provide services us. These include third party companies that work with us or with advertisers who advertise on the Stack Exchange Network in order to help target ads or measure the results of an advertising campaign.

StackOverflow가 언급하는 쿠키는 대략 다음의 카테고리로 나누어진다:

  • Strictly Necessary: stackoverflow가 정상적으로 동작하기 위해 반드시 필요하고, opt-out할 수 없는 쿠키로 만약 쿠키 블락을 해두었으면 사이트 일부가 비정상 작동할 수 있음을 경고. 어떤 개인식별정보도 저장하지 않는다. 꼭 1st party cookie만 있는 건 아니고, google 등의 3rd party cookie 도 포함한다. sid가 명시되어 있는데, 사용자가 google 계정 id 및 최근에 로그인한 시간 기록이 암호화되어 포함된다고 한다.
  • Optional
    • Performance: 사이트의 퍼포먼스를 높이기 위해 방문이나 트래픽 소스를 파악할 수 있게 하는 쿠키를 운영하고 있다. 사이트 내에서 인기있는 페이지를 확인하는 등의 활동에 사용하는데, 역시 비식별 정보다.
    • Functional: 더 나은 기능과 개인화를 제공하기 위해 사용하는 쿠키라고 한다. 
    • Targeting: 여기가 결국 상품담당자로선 핵심일 텐데, 허용하면 타게팅 광고를 더 보게 될 거고, 허용하지 않으면 무관한 광고를 보게 되겠다. (사실 이 점은 참 복잡미묘한데, 관련있는 정보를 보고싶을 때도 있고, 너무 따라다니는 느낌은 싫고, 또 어중간하게 맞추면 도움은 안되는데 기분만 나쁘고...이 최적점 찾기가 참 어려운 것 같다)
      • 대충 아래와 같은 3rd party와 광고 타게팅용 쿠키를 공유한다는 이야기. 
      • askubuntu.com, mathoverflow.net, serverfault.com, stackapps.com, stackexchange.com, stackoverflow.co, stackoverflow.com, stackoverflow.blog, stackoverflowsolutions.com, superuser.com __gads, _dlt, GoogleAdServingTest, urr 1st Party
        youtube.com GPS, VISITOR_INFO1_LIVE, YSC 3rd Party
        linkedin.com bcookie, lang, li_gc, lidc, lissc, UserMatchHistory 3rd Party
        mathtag.com uuid 3rd Party
        doubleclick.net IDE, test_cookie 3rd Party
        ads.linkedin.com lang 3rd Party
        scorecardresearch.com UID, UIDR 3rd Party
        www.linkedin.com bscookie, JSESSIONID 3rd Party
        facebook.com fr 3rd Party
        yahoo.com A3 3rd Party
        www.facebook.com   3rd Party

 

3rd party cookie와 cross-site tracking

파티 (아니야)

3rd party cookie가 조금 더 고급 기능을 수행하려면 이 유저를 계속해서 따라다니면서 얘가 누군지, 정말로 관심사는 무엇인지, 20대라고 추정할 수 있는 근거들이 충분할지를 봐야 할 것이다. 그래서 한 개의 사이트에서 축적된 정보로는 부족하고, 유저A가 "개발에도 관심이 많은데 (stackoverflow 방문), 학생 같기도 하고 (에브리타임 방문) 여성의류에도 관심이 있네 (지그재그 방문)" 라는 종합적인 정보를 가져야 할 거다. 그래야 stackoverflow에서 여성의류 광고도 보여주고, 에브리타임에서 fastcampus 광고도 보여줄 수 있다. 즉, 개별 쿠키가 이 사람에 대한 단편적인 추정을 하는 게 아니라 "한 사람이 여러 브라우저에 걸쳐서 했던 일들"을 모아 이 사람을 프로파일링하는 거라고 보면 되겠다. 그래야 더 정확한, 더 비싼 (전환율이 높은 유저라고 가정하고 자신있게 입찰한) 광고를 보여줄 수 있을 테니까.

https://madmartech.com

 

잠깐: 픽셀과 3rd party cookie는 어떤 관계?

픽셀이라고 부르는 이유는 페이지를 불러올 때 아무 의미가 없는 1x1 픽셀을 로드하고, 그 픽셀에 ad server와의 커뮤니케이션을 수행하도록 어싸인한다는 뜻이다. 실제로 이게 픽셀로 작동하는지 은유적인 표현인지는 모르겠는데 아무래도 후자일 것으로 생각은 된다. 3rd cookie랑 동의어는 아니고, 다만 ad server와의 커뮤니케이션을 수행할 때 클라 브라우저에 3rd party cookie를 요청하게 되는 일종의 모듈이라고 보면 되겠다.

 

3rd party cookie의 위기

앞서 "프로파일링"이라고 했는데, 이 폐해가 사용자들에게 인지되기 시작하면서 개인정보 보호 요구가 커졌다. 2020년 구글이 자사 브라우저에서 3rd party cookie를 허용하지 않겠다고 선언했고, 애플은 조금 더 포괄적인 개념의 트래킹을 하기 어렵도록 os 정책을 바꾸었다. 대체로 2022~2023 사이에 효력이 시작되고, 나름의 전환기도 주면서 전환기의 연장까지도 얘기가 됐던 것 같다.

여튼 이런 글로벌 빅테크의 움직임에 따라 DMP 를 비롯한 마케팅 업체들에 패닉이 왔고, SNAP과 FB의 주가가 곤두박질쳤다. 반대로 first party cookie를 사용할 수 있는 구글 (특히 자체 브라우저를 가지고 있으므로) 이나, 네이버처럼 매체이자 광고플랫폼인 서비스에는 타격이 적을 거라는 얘기도 한동안 화두가 되었다. 개인적으로는 애플의 경우 광고사업이 그렇게 활발하진 않기에 프라이버시 보호라는 어필이 주는 기업이미지 상승 효과가 더 컸던 것 같고, 구글의 경우 강력한 브라우저와 플랫폼 파워를 기반으로 다른 마케팅 업체들을 고사시키고 광고 예산을 흡수하기 위한 전략으로 바라보고 있다. 구글이 광고시장과 매체에 대해 취해왔던 태도와 역사적인 맥락을 보면 이용자보호보다는 전략적인 움직임에 조금 더 가깝지 않을까 함.

한편으로는 "생각보다 대응이 가능했다" 라는 증언이 나오는 매체들도 있는만큼 3rd party cookie 금지에 대한 해법도 활발하게 논의되고 있고, non-cookie tracking 기술에 대해 어필을 하는 곳들도 늘었는데 , 나중에 더 알아볼 기회가 있을 것 같다. 

 

참고

https://ko.wikipedia.org/wiki/HTTP_쿠키

https://stackoverflow.com/questions/6922145/what-is-the-difference-between-server-side-cookie-and-client-side-cookie

http://www.differencebetween.info/difference-between-cache-and-cookie

https://stackoverflow.com/legal/cookie-policy

https://policies.google.com/technologies/cookies?hl=ko#how-google-uses-cookies

https://madmartech.com/first-party-cookie-vs-third-party-cookie/

https://toss.tech/article/smart-web-service-cache

반응형

'Web' 카테고리의 다른 글

SSP-DSP 간 연동을 중심으로 알아보는 HTTP GET vs POST  (0) 2025.04.29
HTTP Request 와 Request Methods  (2) 2022.05.29
Proxy와 Redirect  (1) 2022.02.19