Isoline 가이드

쿠키, 로컬 저장소, 캐시, 브라우저 핑거프린트 이해하기

쿠키, 로컬 저장소, 캐시는 브라우저에 보존되는 상태입니다. 브라우저 핑거프린트는 관찰 가능한 신호로 구성되므로 저장 데이터 삭제는 신원 표면의 일부만 다룹니다.

이 개념들은 개인정보 보호 설정, 디버깅 지침, 브라우저 프로필 제품에서 함께 등장하는 경우가 많습니다. 하지만 동작 방식이 서로 달라서 “브라우저를 지우세요”라는 안내만으로는 충분하지 않습니다.

이해를 위한 기본 모델

메커니즘 생성하거나 통제하는 주체 일반 범위 주된 목적 요청에 자동으로 포함되나요?
HTTP 쿠키 서버가 설정하고 브라우저가 범위 규칙에 따라 저장하고 반환 호스트 또는 도메인, 경로, 수명, 연결 조건 세션 식별자, 기본 설정, 악용 방지 상태 예. 요청이 범위와 일치할 때 포함됩니다.
localStorage 사이트 JavaScript 오리진. 브라우저 파티셔닝과 정책의 영향을 받음 지속형 키-값 애플리케이션 상태 아니요.
sessionStorage 사이트 JavaScript 최상위 브라우징 세션 안의 오리진 임시 탭 또는 업무 상태 아니요.
HTTP 캐시 브라우저와 HTTP 캐싱 규칙 캐시 키, 응답 지시문, 브라우저 정책 응답을 재사용해 지연 시간과 트래픽 감소 요청을 캐시로 충족하거나 재검증할 수 있습니다.
Cache Storage API 사이트 또는 서비스 워커 JavaScript 오리진 또는 저장소 파티션 오프라인 리소스와 애플리케이션 관리 응답 자동 첨부되지 않으며 스크립트가 사용을 제어합니다.
브라우저 핑거프린트 사이트 또는 다른 관찰자가 신호를 측정 관찰자와 신호에 따라 다름 보안, 사기 탐지, 분석 또는 추적 일부 신호는 요청에서 보이고 다른 신호에는 능동 코드가 필요합니다.

앞의 다섯 행은 보존된 상태와 관련됩니다. 마지막 행은 관찰 및 상관관계 분석 방식이지만, 보존된 상태도 입력 중 하나가 될 수 있습니다.

쿠키: 범위 규칙을 따르는 서버 대상 상태

HTTP 자체는 대부분 상태를 저장하지 않습니다. 쿠키를 사용하면 서버가 브라우저에 이름-값 쌍을 전달하고 이후 일치하는 요청에서 다시 받을 수 있습니다. RFC 6265Set-Cookie 응답 헤더, Cookie 요청 헤더, 브라우저 저장 모델을 정의합니다.

쿠키에는 다음과 같은 특성이 있을 수 있습니다.

  • 세션 범위: 브라우저가 정의한 세션이 끝날 때까지 보존
  • 지속형: 만료일 또는 최대 수명을 지정
  • 호스트 전용: 설정한 호스트에만 반환
  • 도메인 범위: 지정한 도메인과 일치하는 하위 도메인에 반환 가능
  • 경로 범위: 일치하는 요청 경로에만 반환
  • Secure: 브라우저가 정의한 보안 채널을 통해서만 반환
  • HttpOnly: 스크립트용 쿠키 API에서는 숨기지만 HTTP 요청에는 계속 사용 가능

이러한 속성은 전송과 스크립트 접근에 영향을 줍니다. 쿠키 값을 독립적인 보안 경계로 만들지는 않습니다. RFC 6265는 특히 보안을 위해 Path 속성에 의존해서는 안 된다고 경고하며, 민감한 쿠키 내용에는 보안 전송과 추가 보호를 권고합니다.

쿠키를 삭제하면 로그아웃되는 이유

많은 서비스는 무작위 세션 식별자를 쿠키에 저장하고 계정 기록과 세션 세부 정보는 서버에 보관합니다. 쿠키를 삭제하면 브라우저가 가진 식별자 복사본이 사라져 다음 요청에서 같은 세션을 제시하지 못합니다. 서버 측 계정과 다른 세션은 남아 있을 수 있습니다.

인증 쿠키 복사가 민감한 이유도 같습니다. 사용 가능한 세션 식별자는 자격 증명처럼 작동할 수 있습니다. 원본 쿠키를 티켓, 로그, 자동화 출력 또는 팀 채팅에 붙여 넣지 마세요.

로컬 저장소: 한 오리진을 위한 스크립트 제어 상태

HTML 표준은 localStorage를 오리진의 로컬 저장 영역에 대한 접근으로 정의합니다. 이 저장소는 여러 창에 걸쳐 유지되고 현재 세션보다 오래 지속하도록 설계되었습니다. 문자열 키-값 쌍을 담으며 해당 오리진에 접근할 권한이 있는 스크립트가 사용할 수 있습니다.

오리진은 일반적으로 스킴, 호스트, 포트의 조합입니다. 따라서 다음 주소는 서로 다른 저장 범위를 가집니다.

  • https://app.example.test
  • http://app.example.test
  • https://admin.example.test
  • https://app.example.test:8443

URL 경로는 오리진에 포함되지 않습니다. 애플리케이션에서 자체 논리 분리를 만들지 않는 한 같은 오리진의 /billing//support/ 페이지는 같은 로컬 저장 영역을 사용할 수 있습니다.

쿠키와 달리 localStorage 항목은 HTTP 요청에 자동으로 첨부되지 않습니다. 사이트 스크립트가 이를 읽고 사용할 방법을 정해야 합니다. 따라서 인터페이스 기본 설정, 초안 상태, 애플리케이션 데이터에 유용하지만, 오리진 권한으로 실행되는 모든 스크립트가 접근할 수 있을 가능성이 있습니다. 민감한 세션을 설계할 때 “로컬”이라는 말이 비밀이라는 뜻이라고 가정하지 말고 스크립트 침해를 고려해야 합니다.

여기서 지속성이란 브라우징 세션이 끝난 뒤에도 데이터가 남을 수 있다는 의미입니다. 영구 보존을 뜻하지는 않습니다. 사용자가 데이터를 지울 수 있고, 브라우저 정책이 제한할 수 있으며, 브라우저가 저장소 및 축출 규칙을 적용할 수 있습니다.

sessionStorage는 수명이 다릅니다

sessionStorage는 오리진 및 최상위 브라우징 세션과 연결됩니다. 탭이나 창의 업무가 계속되는 동안 유지되고 세션과 함께 끝나야 하는 상태에 적합합니다. 복제되거나 복원된 탭에는 브라우저별 수명 주기 세부 사항이 있을 수 있으므로, 애플리케이션이 중요한 업무의 유일한 기록으로 사용해서는 안 됩니다.

로컬 저장소는 사이트 데이터 방식 중 하나일 뿐입니다

최신 웹 애플리케이션은 IndexedDB, Cache Storage, 서비스 워커 등록, Origin Private File System, 권한 및 기타 브라우저 관리 저장소에도 데이터를 보관할 수 있습니다. 따라서 개발자 도구에서 localStorage만 지우면 다른 상태가 남을 수 있습니다.

HTML 표준의 개인정보 보호 지침은 사이트가 한 저장소를 이용해 다른 저장소에서 삭제된 식별자를 재생성할 수 있으므로, 브라우저에서 지속형 저장 방식을 함께 삭제할 수 있게 할 것을 권고합니다.

캐시: 여러 메커니즘을 가리키는 한 단어

HTTP 캐시

RFC 9111은 HTTP 캐시를 응답 메시지 저장소와 그 저장, 검색, 삭제를 제어하는 시스템으로 정의합니다. 브라우저 캐시는 최신 응답을 재사용하거나 오래된 응답을 재검증해 지연 시간과 네트워크 전송량을 줄일 수 있습니다.

캐시 키에는 적어도 요청 메서드와 대상 URI가 포함되며, 응답 헤더는 응답을 재사용할 수 있는지와 그 기간에 영향을 줍니다. HTTP 캐시는 최적화 계층입니다. 이미지나 스크립트가 캐시에 있다는 사실이 일반적으로 사용자의 로그인 상태를 의미하지는 않습니다.

캐시 상태도 개인정보 보호에 영향을 줄 수 있습니다. 어떤 위협 모델에서는 타이밍이나 리소스가 이미 존재하는지 여부가 정보를 드러낼 수 있습니다. W3C 핑거프린팅 지침은 브라우저나 사용자 구성을 추론하는 방법에 캐시된 리소스 관찰을 포함합니다.

Cache Storage와 서비스 워커

Cache Storage API는 사이트가 명시적으로 스크립트로 제어하는 Cache 객체를 제공하며 오프라인 웹 애플리케이션에서 자주 사용됩니다. Service Workers 명세는 이 캐시가 브라우저 HTTP 캐시와 분리되고 오리진별로 격리되며, 일반 HTTP 최신성 규칙이 아니라 애플리케이션 로직에 따라 업데이트되거나 삭제된다고 설명합니다.

이 차이는 디버깅할 때 중요합니다.

  • “캐시된 이미지 및 파일” 삭제는 브라우저의 일반 캐시를 대상으로 합니다.
  • 사이트 데이터 삭제는 Cache Storage와 서비스 워커 상태도 제거할 수 있습니다.
  • HTTP 캐시를 우회해 새로고침해도 활성 서비스 워커가 계속 요청을 제어할 수 있습니다.

검사하거나 삭제하는 방법을 정하기 전에 어떤 캐시를 뜻하는지 명시하세요.

저장소 파티셔닝이 또 하나의 키를 추가합니다

과거에는 오리진 범위 때문에 여러 최상위 사이트 안에 포함된 제3자가 같은 저장소를 읽을 수 있었습니다. 최신 브라우저는 점점 최상위 사이트 또는 관련 컨텍스트를 저장소 키에 추가하고 있습니다.

Chrome 문서에 따르면 저장소 파티셔닝a.com에 포함된 example.com 프레임이 b.com에 포함된 같은 프레임과 Local Storage, IndexedDB, Cache Storage, 서비스 워커, 일부 통신 메커니즘을 자동 공유하지 못하게 합니다. Chrome은 이 기능이 Chrome 115부터 모든 사용자에게 적용됐고 이후 일부 추가 API에도 변경이 이루어졌다고 설명합니다.

파티셔닝은 같은 임베디드 오리진도 주변 사이트에 따라 다른 저장소를 볼 수 있다는, 얼핏 놀라운 결과를 설명합니다. 그렇다고 모든 저장소가 어디서나 하나의 보편적인 2중 키 모델을 사용한다는 뜻은 아닙니다. 브라우저 버전, 최상위 및 임베디드 컨텍스트, 저장소 접근 권한, 엔터프라이즈 정책, 확장 프로그램, API별 규칙에 따라 결과가 달라질 수 있습니다.

도메인 이름만 보고 추론하지 말고 정확한 컨텍스트를 테스트하세요.

브라우저 핑거프린트: 폴더가 아닌 관찰된 신호

W3C는 브라우저 핑거프린팅을 구성 설정이나 기타 관찰 가능한 특성을 통해 사용자, 사용자 에이전트 또는 기기를 식별하거나 재식별하는 능력으로 정의합니다. 2025년 지침은 여러 형태를 구분합니다.

  • 수동적 핑거프린팅은 요청 헤더와 IP 주소처럼 요청이나 네트워크에서 이미 관찰할 수 있는 정보를 사용합니다.
  • 능동적 핑거프린팅은 코드를 실행해 창 크기, 글꼴, 연결된 기기, 성능, 센서 또는 그래픽 렌더링 같은 특성을 관찰합니다.
  • 일시적 이벤트 상관관계는 거의 동시에 발생하는 기기 또는 환경 변화를 통해 컨텍스트를 연결합니다.
  • 쿠키 유사 기법은 일반 쿠키보다 오래 남거나 쿠키를 재생성할 수 있는 메커니즘을 통해 상태를 저장하고 가져옵니다.

핑거프린트는 브라우저가 저장한 변경 불가능한 값 하나인 경우가 드뭅니다. 관찰자가 신호를 선택해 결합하고 이전 방문과 얼마나 강하게 일치하는지 판단합니다. 브라우저 업데이트, 창 변경, 글꼴 추가, 기기 연결 또는 네트워크 경로 변경에 따라 결과가 바뀔 수 있습니다. 쿠키를 지운 뒤에도 기반 신호가 상당수 그대로라면 비슷한 상태로 남을 수도 있습니다.

핑거프린팅은 신원의 증거가 아닙니다

한 신호 집합이 여러 사람에게 흔할 수 있고, 한 사람의 신호가 변할 수도 있습니다. 사이트는 핑거프린트를 로그인, 서버 측 계정 기록, 네트워크 평판 또는 저장된 식별자와 결합할 수도 있습니다. 따라서 데이터를 지운 뒤에도 알아본다는 사실만으로 핑거프린팅만이 원인이라고 입증되지는 않습니다.

같은 이유로 눈에 보이는 설정 하나를 바꾼다고 새 신원이 보장되지는 않습니다. 일관되고 흔한 구성은 일부 고유성을 줄일 수 있지만, 서로 독립적인 비정상 설정을 많이 바꾸면 더 희귀한 조합이 될 수 있습니다. 이러한 신호로는 보이지 않는 상태나 제3자 승인을 보장할 수 없습니다.

일반적인 데이터 삭제 작업이 실제로 바꾸는 것

작업 예상 효과 중요하게 남는 것
사이트의 쿠키 삭제 일치하는 브라우저 보유 쿠키 상태를 제거하며 해당 프로필에서 로그아웃되는 경우가 많음 서버 측 계정 데이터, 다른 기기, 쿠키 외 저장소는 남을 수 있음
쿠키와 기타 사이트 데이터 삭제 브라우저 UI와 범위에 따라 쿠키, Web Storage, IndexedDB, 서비스 워커 및 관련 사이트 상태를 제거할 수 있음 비밀번호 관리자, 다운로드, 계정 측 데이터, 관찰 가능한 기기 신호는 별도임
캐시된 이미지 및 파일 삭제 일반 캐시 응답 콘텐츠 제거 쿠키, 로컬 저장소, Cache Storage는 별도로 선택해야 할 수 있음
기록 삭제 선택한 범위에서 방문 URL 기록과 관련 추천 제거 다운로드한 파일과 사이트가 보유한 기록은 남음
브라우저 프로필 삭제 기기에서 해당 프로필의 로컬 북마크, 기록, 비밀번호, 기타 설정 제거 동기화된 계정 데이터, 다운로드 또는 내보낸 파일, 백업, 서버 측 데이터는 남을 수 있음
새 프로필 시작 다른 프로필 상태 모음으로 시작 기기, OS, 브라우저 빌드, 네트워크는 계속 관련된 것으로 관찰될 수 있음

Chrome의 인터넷 사용 기록 삭제 안내는 기록, 쿠키 및 기타 사이트 데이터, 캐시된 이미지 및 파일, 다운로드 기록, 자동 완성, 사이트 설정, 호스팅된 앱 데이터를 서로 다른 항목으로 다룹니다. 다운로드 기록을 삭제해도 컴퓨터의 다운로드 파일은 남고, 로그인 상태에서 데이터를 삭제하면 Google 계정과 동기화된 다른 기기에 영향을 줄 수 있다고도 설명합니다.

정확한 효과는 선택한 기간, 프로필, 계정 상태, 브라우저 버전, 엔터프라이즈 정책에 따라 달라집니다. 복구하기 어려운 데이터를 삭제하기 전에 확인 문구를 검토하세요.

별도 브라우저 프로필이 각 메커니즘에 미치는 영향

올바르게 분리된 지속형 프로필에는 자체 쿠키 저장소, 웹 저장 영역, 사이트 데이터베이스, Cache Storage, HTTP 캐시 소유권, 기록, 사이트 권한, 확장 프로그램 상태가 있어야 합니다. 이렇게 하면 프로필 B가 프로필 A의 저장된 세션을 그대로 물려받지 않습니다.

여러 신호는 공통으로 남을 수 있습니다.

  • 브라우저 엔진과 버전
  • 운영체제와 하드웨어
  • 설치된 시스템 글꼴과 디스플레이 특성
  • 호스트에서 상속한 언어, 시간대 또는 접근성 설정
  • 별도 경로를 구성하지 않았을 때의 IP 주소와 네트워크 경로
  • 애플리케이션 계층에서 활동을 연결하는 운영자 행동 또는 로그인

프로필마다 확장 프로그램, 권한, 창 크기, 언어 설정 또는 프록시 경로가 달라 서로 다른 신호를 드러낼 수도 있습니다. 전체 효과는 구현과 컨텍스트에 따라 달라집니다. 프로필 분리는 상태 격리로 평가해야 하며 핑거프린트 보장으로 평가해서는 안 됩니다.

모든 데이터를 지우기 전에 증상 진단하기

“로그아웃되었습니다”

쿠키부터 확인하세요. 세션 쿠키가 만료 또는 삭제됐거나, 브라우저 정책에 따라 거부됐거나, 서버에서 무효화됐을 수 있습니다. 로컬 저장소는 인터페이스를 지원할 수 있지만 일반적으로 HTTP 인증 요청에 자동 전송되는 쿠키는 아닙니다.

“사이트에서 초안이나 오프라인 데이터를 잊어버렸습니다”

로컬 저장소, IndexedDB, Cache Storage, 서비스 워커 상태를 검사하세요. 파티셔닝에 따라 사용 가능한 저장소가 달라질 수 있으므로 오리진을 확인하고 페이지가 최상위에 있는지 다른 사이트에 포함되어 있는지도 확인하세요.

“처음 새로고침할 때 느립니다”

비어 있거나 오래된 HTTP 캐시가 원인일 가능성이 큽니다. 네트워크, 서버, 서비스 워커 동작도 같은 증상을 만들 수 있으므로 결론을 내리기 전에 요청 시간과 캐시 상태를 기록하세요.

“데이터를 지웠는데도 사이트가 환경을 알아봅니다”

여러 설명이 가능합니다. 다른 곳에서 계정 로그인이 유지되거나, 서버가 계정 또는 네트워크 데이터로 방문을 연결했거나, 다른 브라우저 저장소가 남아 있거나, 관찰 가능한 특성이 세션을 연관 지었을 수 있습니다. 핑거프린팅은 하나의 가설로 취급해야 하며 자동으로 정답이라고 보아서는 안 됩니다.

결정을 위한 요점

메커니즘에 맞춰 해결 방법을 선택하세요.

  • 서버 세션이 문제라면 쿠키를 검사하거나 삭제합니다.
  • 웹 애플리케이션에 로컬 상태가 남아 있다면 오리진 범위 사이트 저장소를 검사합니다.
  • 오래되거나 오프라인인 콘텐츠를 진단할 때 HTTP 캐시와 Cache Storage를 구분합니다.
  • 저장된 업무 상태를 독립적으로 유지해야 한다면 별도 지속형 프로필을 사용합니다.
  • 핑거프린팅은 관찰 가능한 신호의 상관관계 분석으로 취급하고, 데이터 삭제나 설정 하나의 변경으로 없앨 수 없는 한계를 이해합니다.

이 모델은 필요한 것보다 많은 상태를 삭제하는 실수와 쿠키 저장소를 비우면 새 기기 신원이 만들어진다고 가정하는 실수를 피하게 해 줍니다.

한계

웹 저장소와 개인정보 보호 동작은 브라우저와 릴리스에 따라 발전합니다. 제3자 쿠키 규칙, 저장소 파티셔닝, 축출, 동기화, 엔터프라이즈 정책, 확장 프로그램, 비공개 브라우징 모드가 여기 설명한 동작을 바꿀 수 있습니다. 이 가이드는 접근일 현재의 표준과 Chrome 문서를 설명하며 모든 브라우저나 웹사이트 구현을 규정하지 않습니다.

편집자 주

AI 지원
AI가 한국어 번역을 지원했습니다. 한국어 전문 검토가 별도로 기록되지 않았으며, Isoline 편집팀이 게시된 텍스트에 대한 책임을 집니다.
편집 검토
Isoline 편집팀

출처

각 출처는 그 출처가 뒷받침하는 진술 묶음과 연결됩니다. 접근일은 편집팀이 인용 자료를 확인한 날짜입니다.

  1. IETF RFC 6265: HTTP State Management Mechanism Internet Engineering Task Force
    뒷받침하는 내용
    쿠키 저장 및 전송, 속성의 의미, 보안 한계, 주변 세션 권한을 뒷받침합니다.
    접근일
  2. 뒷받침하는 내용
    오리진 범위의 localStorage와 sessionStorage 동작, 지속성, 개인정보 보호 지침을 뒷받침합니다.
    접근일
  3. IETF RFC 9111: HTTP Caching Internet Engineering Task Force
    뒷받침하는 내용
    HTTP 캐시 저장, 키, 최신성, 재검증, 응답 재사용의 의미를 뒷받침합니다.
    접근일
  4. 뒷받침하는 내용
    오리진에 묶이고 스크립트로 제어되는 Cache Storage와 브라우저 HTTP 캐시의 차이를 뒷받침합니다.
    접근일
  5. 뒷받침하는 내용
    최상위 컨텍스트에 따른 Chrome 저장소 파티셔닝과 적용 과정 및 API별 한계를 뒷받침합니다.
    접근일
  6. 뒷받침하는 내용
    서로 다른 삭제 항목, 동기화에 미치는 영향, 기록 삭제 후에도 남는 데이터를 뒷받침합니다.
    접근일
  7. 뒷받침하는 내용
    Cache Storage, 서비스 워커, 사이트 저장소 유형을 포함한 브라우저 데이터 유형 제어를 뒷받침합니다.
    접근일
  8. 뒷받침하는 내용
    로컬 Chrome 프로필 분리와 프로필 삭제의 효과 및 한계를 뒷받침합니다.
    접근일
  9. 뒷받침하는 내용
    수동적·능동적·상태 기반 핑거프린팅 입력과 상관관계 분석의 한계를 뒷받침합니다.
    접근일
정정 요청