“Private State Tokens”, 쿠키도 아닌데 브라우저에 토큰이 있다?
들어가며
크롬 개발자 도구를 열어보면 생각보다 많은 저장 공간과 기능이 등장합니다.
Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage까지는 웹 개발을 조금 해봤다면 익숙한 편입니다.
그런데 Application 탭을 자세히 살펴보다 보면 처음 보는 이름이 하나 눈에 들어올 때가 있습니다.
바로 Private State Tokens입니다.
이름만 보면 “개인적인 상태를 저장하는 또 하나의 저장소인가?”라는 생각이 들 수 있습니다.
저도 처음 이런 이름을 봤다면 Local Storage나 Session Storage와 비슷한 기능부터 떠올렸을 것 같습니다.
그런데 실제로는 방향이 꽤 다릅니다.
Private State Tokens는 일반적인 웹 저장소라기보다는 웹사이트가 사용자의 신뢰 신호를 다른 웹사이트나 컨텍스트에서 활용할 수 있도록 하면서도 사용자를 직접 추적하지 않도록 설계된 기술입니다. Chrome에서는 이 기술을 사기 방지와 봇 탐지 등의 목적으로 설명하고 있습니다.
오늘은 개발자 도구에서 보이는 Private State Tokens가 무엇인지, 왜 만들어졌는지, 실제로 어떤 방식으로 동작하는지 그리고 개발자 도구에서는 어디에서 확인할 수 있는지 정리해보겠습니다.
Private State Tokens란 무엇일까?
Private State Tokens는 예전에 Trust Tokens라고 불렸던 기술입니다.
Chrome 문서에서도 기존 Trust Token API의 이름이 Private State Token API로 변경되었다고 설명하고 있습니다. 이름을 바꾼 이유는 이 기술이 단순히 “신뢰”를 저장하는 것뿐만 아니라 개인정보 보호와 활용성을 함께 고려한다는 점을 좀 더 잘 표현하기 위해서입니다.
쉽게 설명하면 이런 상황을 생각해볼 수 있습니다.
어떤 웹사이트가 사용자가 정상적인 사람이라고 판단했다고 해보겠습니다.
예를 들어 사용자가 정상적으로 계정을 이용하고 있거나, 거래를 완료했거나, 특정 검증 절차를 통과한 경우입니다.
이때 해당 사이트가 브라우저에 일종의 신뢰 신호를 발급할 수 있습니다.
이후 사용자가 다른 웹사이트를 방문했을 때 그 사이트가 직접 사용자의 과거 활동을 알아내는 것이 아니라, 신뢰할 수 있는 발급자가 발행한 토큰이 있는지를 확인하는 방식입니다.
중요한 부분은 여기에서 개인의 신원을 그대로 전달하지 않는다는 것입니다. Private State Tokens는 암호화된 형태로 저장되며 개인을 식별하거나 서로 다른 사이트의 활동을 연결하는 것을 어렵게 만드는 방향으로 설계되었습니다.
왜 이런 기술이 필요했을까?
웹사이트 입장에서는 사용자가 정상적인 사용자인지 판단해야 하는 경우가 많습니다.
특히 광고, 온라인 서비스, 결제, 콘텐츠 플랫폼 등에서는 봇이나 자동화된 공격으로부터 서비스를 보호해야 합니다.
문제는 사용자가 사람인지 판단하기 위해 너무 많은 정보를 수집하다 보면 개인정보 침해나 사용자 추적 문제로 이어질 수 있다는 것입니다.
예를 들어 브라우저 종류, 운영체제, 화면 정보, 설치된 폰트 등 다양한 정보를 조합해서 사용자를 식별하는 핑거프린팅(Fingerprinting) 같은 방식이 있습니다.
이런 방식은 사용자를 추적하는 데 활용될 수 있기 때문에 개인정보 보호 측면에서 문제가 될 수 있습니다.
Private State Tokens가 등장한 배경 중 하나도 여기에 있습니다.
즉,
“사용자를 믿을 만한 사용자라고 판단했다는 신호는 전달하되, 그 사람이 누구인지는 최대한 드러내지 않도록 하자.”
라는 방향으로 이해하면 쉽습니다. Chrome은 Private State Tokens를 패시브 추적 없이 사용자에 대한 신뢰를 전달하고, 사기나 봇을 구분하는 데 활용할 수 있는 기술로 설명하고 있습니다.
발급자와 사용자가 따로 있다
Private State Tokens를 이해하려면 Issuer와 Redeemer라는 개념을 알아야 합니다.
Issuer는 토큰을 발급하는 쪽입니다.
예를 들어 어떤 서비스가 사용자를 정상적인 사용자라고 판단했다면 해당 서비스가 브라우저에 Private State Token을 발급할 수 있습니다.
반대로 Redeemer는 발급된 토큰을 활용해서 신뢰 신호를 확인하려는 쪽입니다.
예를 들어 사용자가 다른 웹사이트를 방문했는데 해당 사이트가 특정 발급자를 신뢰하고 있다면 브라우저에 해당 발급자의 토큰이 있는지 확인할 수 있습니다.
구조를 단순하게 표현하면 다음과 같습니다.
사용자
↓
[Issuer]
신뢰할 수 있는 사용자라고 판단
↓
Private State Token 발급
↓
브라우저에 저장
↓
다른 웹사이트 방문
↓
[Redeemer]
신뢰할 수 있는 Issuer의 토큰 확인
↓
토큰 사용 및 신뢰 신호 활용
Chrome의 개발자 가이드에서도 Private State Tokens의 핵심 관계를 Issuer와 Redeemer로 설명하고 있으며, 두 주체가 웹에서 신뢰 관련 신호를 전달하기 위해 협력하는 구조라고 설명합니다.
일반적인 Cookie와 무엇이 다를까?
여기서 Cookie와 비교해보면 이해가 조금 더 쉬워집니다.
Cookie는 웹사이트에서 데이터를 저장하고 서버 요청에 함께 전송하는 데 널리 사용됩니다.
반면 Private State Tokens는 특정 사용자의 신원이나 상세한 활동 정보를 그대로 전달하는 것이 목적이 아닙니다.
예를 들어 단순하게 생각하면 Cookie 방식에서는 서버가 특정 사용자와 연결되는 값을 가지고 상태를 관리할 수 있습니다.
하지만 Private State Tokens는 “이 사용자가 특정 발급자로부터 신뢰할 만한 사용자라는 신호를 받았는가?” 같은 정보를 개인정보 보호를 고려한 방식으로 전달하는 데 초점이 있습니다.
즉, 사용자 자체를 알아내기보다는 신뢰 신호를 전달하는 기술에 가깝습니다.
Chrome 역시 Private State Tokens를 사용자 인증 자체를 수행하는 기술이 아니라, 한 컨텍스트에서 다른 컨텍스트로 사용자에 대한 신뢰를 전달하는 방법이라고 설명합니다.
개발자 도구에서 Private State Tokens 확인하기
이제 실제 개발자 도구에서 어디에 있는지 살펴보겠습니다.
크롬에서 Private State Tokens를 사용하는 환경이라면 개발자 도구를 열고 Application 탭으로 이동합니다.
그리고 Storage 영역을 살펴보면 Private State Tokens 항목을 확인할 수 있습니다.
Chrome의 공식 개발자 문서에서도 다음과 같은 경로를 안내하고 있습니다.
Application
↓
Storage
↓
Private State Tokens
여기에서 특정 페이지와 관련된 Private State Tokens 정보를 확인할 수 있습니다.
또한 Network 탭에서도 Private State Tokens와 관련된 동작을 확인할 수 있습니다.
즉 Private State Tokens를 디버깅할 때는 Application 탭만 보는 것이 아니라 Network 탭까지 함께 확인할 수 있습니다.
Local Storage처럼 직접 값을 읽는 방식일까?
이 부분은 상당히 중요합니다.
Private State Tokens를 처음 접하면 “개발자 도구에 저장되어 있으니까 JavaScript로 값을 읽으면 되겠네”라고 생각할 수 있습니다.
하지만 그런 구조가 아닙니다.
Local Storage는 다음처럼 직접 값을 가져올 수 있습니다.
const value = localStorage.getItem("test");
하지만 Private State Tokens는 일반적인 Key-Value 저장소가 아닙니다.
브라우저 내부에 저장된 토큰은 Private State Token API를 통해서만 접근하도록 설계되어 있습니다. Chrome의 개발자 가이드에서도 PST 데이터는 사용자 기기에 브라우저 내부적으로 저장되며 PST API를 통해 접근할 수 있다고 설명합니다.
따라서 개발자 도구에 보인다고 해서 일반적인 저장소처럼 값을 직접 수정하거나 읽을 수 있다고 생각하면 안 됩니다.
이 차이를 이해하는 것이 중요합니다.
Private State Tokens는 어떻게 동작할까?
전체적인 과정을 조금 더 자세히 보면 다음과 같습니다.
먼저 사용자가 Issuer 사이트를 방문합니다.
해당 사이트에서 계정을 정상적으로 사용하거나 거래를 완료하는 등 특정 조건을 만족하면 사이트가 사용자를 신뢰할 수 있다고 판단할 수 있습니다.
이후 브라우저에 Private State Token이 발급됩니다.
그리고 시간이 지난 뒤 사용자가 다른 웹사이트를 방문합니다.
해당 웹사이트는 자신이 신뢰하는 Issuer의 토큰이 브라우저에 존재하는지를 확인할 수 있습니다.
토큰이 있다면 필요한 경우 토큰을 Redeem하고 그 결과를 신뢰 신호로 사용할 수 있습니다.
Chrome 문서에서는 이 과정을 토큰 발급 → 토큰 사용 → Redemption Record 전달이라는 세 단계로 설명하고 있습니다.
간단하게 정리하면 다음과 같습니다.
1. Issuer가 토큰 발급
↓
2. 브라우저가 토큰 저장
↓
3. 다른 사이트에서 토큰 확인
↓
4. 토큰 Redeem
↓
5. Redemption Record 활용
이 과정에서 중요한 것은 상세한 개인 식별 정보를 그대로 전달하지 않는다는 점입니다.
봇 탐지와 사기 방지에 활용
Private State Tokens의 대표적인 사용 사례 중 하나가 사기 방지와 봇 구분입니다.
예를 들어 광고를 보여주는 웹사이트가 있다고 가정해보겠습니다.
광고 시스템 입장에서는 자동화된 봇이 반복적으로 광고를 요청하는 상황을 구분할 필요가 있습니다.
이때 어떤 신뢰할 수 있는 서비스가 사용자의 브라우저에 토큰을 발급했다면, 다른 서비스가 해당 토큰을 이용해 “이 브라우저에는 신뢰할 수 있는 발급자의 신호가 있다”는 정보를 활용할 수 있습니다.
Chrome에서는 이러한 방식으로 광고, 게시자, CDN 등에서 발생할 수 있는 사기 방지 요구사항을 지원하는 사례를 설명하고 있습니다.
다만 Private State Tokens가 모든 봇을 자동으로 찾아내는 만능 보안 기술은 아닙니다.
Chrome 공식 문서에서도 Private State Tokens는 reCAPTCHA 같은 검증 시스템을 완전히 대체하는 것이 아니라 신뢰를 전달하는 추가적인 수단이라고 설명합니다.
Private State Tokens와 개인정보 보호
이 기술을 이해할 때 개인정보 보호라는 부분도 빼놓을 수 없습니다.
웹사이트 입장에서는 사용자가 정상적인 사람인지 확인하고 싶지만, 그 과정에서 사용자의 웹 활동을 여러 사이트에 걸쳐 추적하는 것은 또 다른 문제가 될 수 있습니다.
Private State Tokens는 이 두 가지 요구사항 사이에서 절충점을 찾으려는 기술이라고 볼 수 있습니다.
즉,
신뢰 신호 필요
+
사용자 추적은 최소화
↓
Private State Tokens
라는 방향입니다.
토큰 자체도 암호화되어 있으며 개인을 식별하거나 신뢰할 수 있는 사이트와 그렇지 않은 사이트의 활동을 연결해서 사용자의 신원을 알아내는 방식으로 설계되지 않았습니다.
개발자 도구에서 확인할 때 주의할 점
Private State Tokens는 일반적인 저장소처럼 항상 데이터를 확인할 수 있는 것은 아닙니다.
실제로 Private State Tokens를 사용하는 사이트나 테스트 환경이 필요합니다.
Chrome 공식 개발자 가이드에서도 테스트용 데모 환경을 제공하며, 데모를 실행한 뒤 Application → Storage → Private State Tokens 경로에서 발급되거나 사용된 토큰을 확인하는 방법을 안내하고 있습니다.
따라서 자신의 일반적인 웹사이트를 열었는데 Private State Tokens에 아무것도 나오지 않는다고 해서 개발자 도구가 잘못된 것은 아닙니다.
해당 기능을 사용하는 환경인지 먼저 확인해야 합니다.
또한 Private State Tokens는 사용자가 저장소에서 삭제할 수도 있기 때문에 이것 하나만 가지고 특정 기기를 “신뢰할 수 있는 기기”라고 판단해서는 안 됩니다. Chrome 역시 위험 판단을 할 때 PST를 추가적인 신호로 활용할 것을 안내하고 있습니다.
마무리
Private State Tokens는 처음 보면 이름부터 상당히 어렵습니다.
Cookies처럼 익숙한 저장소도 아니고 Local Storage처럼 Key와 Value를 넣었다가 꺼내 쓰는 방식도 아닙니다.
조금 더 정확하게 표현하면 웹사이트 사이에서 사용자에 대한 신뢰 신호를 전달하면서 개인정보 보호를 고려하기 위한 브라우저 기술이라고 볼 수 있습니다.
특히 개발자 도구에서는
Application → Storage → Private State Tokens
경로를 통해 관련 정보를 확인할 수 있고, Network 탭에서도 토큰과 관련된 동작을 살펴볼 수 있습니다.
이번에 Private State Tokens를 공부하면서 기억해둘 핵심은 세 가지 정도입니다.
첫 번째는 Trust Tokens에서 이름이 변경된 기술이라는 점입니다.
두 번째는 사용자를 직접 식별하기보다 신뢰 신호를 전달하는 것이 목적이라는 점입니다.
세 번째는 Local Storage나 Cookies처럼 일반적인 웹 저장소와 동일한 방식으로 생각하면 안 된다는 점입니다.
개발자 도구의 Application 탭에는 우리가 평소 자주 사용하는 저장소 외에도 이런 특수한 브라우저 기능들이 숨어 있습니다.
처음에는 이름만 보고 지나치기 쉽지만 하나씩 살펴보면 웹 브라우저가 개인정보 보호와 보안 문제를 해결하기 위해 어떤 방향으로 발전하고 있는지도 볼 수 있습니다.
특히 봇 탐지나 사기 방지, Privacy Sandbox 같은 주제에 관심이 있다면 Private State Tokens를 한 번쯤 살펴볼 만합니다.
다만 브라우저 기술은 계속 변경되고 있기 때문에 실제 프로젝트에 적용하기 전에는 반드시 현재 Chrome의 공식 문서와 지원 상태를 확인하는 것이 좋습니다.
홍TV



![Eclipse에서 갑자기 "[m2e] Lifecycle Mapping" 오류? Maven 프로젝트가 빨간 줄 뜨는 이유 4 Eclipse에서 갑자기 [m2e] Lifecycle Mapping 오류? Maven 프로젝트가 빨간 줄 뜨는 진짜 이유](https://hongtv.co.kr/wp-content/uploads/2026/09/62edeb0f-aaf8-42cc-af31-1a91e54bc187-300x200.png)
댓글 0
첫 댓글을 남겨보세요.