“Shared Storage”, 개발자 도구에 왜 이런 저장소가 있지?

들어가며

개발자 도구의 Application 탭을 열어보면 생각보다 많은 저장소가 등장합니다.

Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage까지는 이름만 봐도 어느 정도 용도를 짐작할 수 있습니다.

그런데 조금 더 살펴보다 보면 Shared Storage라는 이름이 눈에 들어오는 경우가 있습니다.

여기서 처음 개발자 도구를 보는 사람이라면 자연스럽게 이런 생각이 들 수 있습니다.

“Local Storage와 Session Storage도 있는데 Shared Storage는 또 뭐지?”

저도 이런 저장소 이름을 처음 접하면 일단 데이터를 저장하는 공간부터 떠올리게 됩니다.

하지만 Shared Storage는 일반적인 웹 저장소와는 목적이 상당히 다릅니다.

특히 이 기능은 Chrome의 Privacy Sandbox와 관련된 기술로 등장했으며, 여러 사이트에 걸친 데이터를 활용하면서도 사용자를 직접 추적하기 어렵게 만드는 것을 목표로 설계되었습니다.

다만 현재는 상황이 조금 달라졌습니다.

현재 MDN에서는 Shared Storage API를 Deprecated, To be removed로 표시하고 있습니다. Chrome이 제3자 쿠키에 대한 기존 접근 방식을 유지하기로 하면서 Privacy Sandbox의 일부 기능을 철회하기로 했기 때문입니다.

그래서 지금 시점에서는 “새로운 서비스에서 Shared Storage를 적극적으로 사용하자”는 관점보다는, 개발자 도구에서 Shared Storage가 무엇이었고 왜 만들어졌는지 이해하는 것에 초점을 맞추는 것이 좋습니다.

Shared Storage란 무엇일까?

Shared Storage는 일반적인 localStorage나 sessionStorage처럼 단순히 웹페이지에서 데이터를 저장하고 자유롭게 읽기 위한 저장소가 아닙니다.

Shared Storage가 등장한 가장 큰 배경에는 서드파티 쿠키와 사용자 추적 문제가 있습니다.

웹에서는 한 사이트에서 발생한 정보를 다른 사이트에서도 활용해야 하는 경우가 있습니다.

예를 들어 광고 노출 빈도를 측정하거나, 여러 사이트에서 발생한 정보를 바탕으로 통계적인 결과를 만들어야 하는 상황이 있을 수 있습니다.

기존에는 이런 작업에 서드파티 쿠키 등이 활용되기도 했습니다.

하지만 사용자의 웹 활동을 여러 사이트에 걸쳐 추적하는 문제가 발생할 수 있기 때문에 브라우저에서는 이러한 방식에 대한 제한을 강화해왔습니다.

Shared Storage는 이런 상황에서 원본 데이터를 다른 사이트의 JavaScript가 그대로 읽지 못하게 하면서 필요한 결과만 활용할 수 있도록 하는 방향으로 설계되었습니다.

Local Storage와는 무엇이 다를까?

이 부분이 가장 중요합니다.

Local Storage는 우리가 일반적으로 사용하는 웹 저장소입니다.

localStorage.setItem("theme", "dark");

const theme = localStorage.getItem("theme");

저장한 값을 같은 출처의 페이지에서 JavaScript로 직접 읽을 수 있습니다.

반면 Shared Storage는 이런 방식으로 자유롭게 데이터를 읽도록 만들어진 기능이 아닙니다.

Shared Storage에서는 데이터를 쓰는 것과 읽는 과정이 분리되어 있습니다.

값을 저장할 수는 있지만, 저장된 원시 데이터를 일반적인 페이지 코드에서 그대로 꺼내는 것이 제한됩니다.

Shared Storage의 값을 읽고 처리하는 작업은 Shared Storage Worklet이라는 별도의 환경에서 수행하도록 설계되었습니다.

쉽게 표현하면 이런 차이가 있습니다.

Local Storage

저장
 ↓
JavaScript로 직접 읽기
 ↓
값 활용


Shared Storage

저장
 ↓
Worklet에서 처리
 ↓
허용된 방식으로 결과 활용

이런 구조를 통해 브라우저가 원본 데이터를 그대로 노출하지 않도록 하는 것이 Shared Storage의 중요한 특징이었습니다.

개발자 도구에서 Shared Storage를 보는 이유

개발자 도구는 웹페이지가 브라우저의 어떤 기능을 사용하고 있는지 확인하는 데 상당히 유용합니다.

Cookies나 Local Storage처럼 우리가 자주 사용하는 저장소는 실제 데이터를 직접 확인하면서 디버깅하는 경우가 많습니다.

하지만 Shared Storage는 조금 다르게 접근해야 합니다.

이 기능의 핵심은 “저장된 값을 개발자가 마음대로 꺼내 본다”는 것이 아니라 데이터를 특정 환경 안에서 처리하고 필요한 결과만 외부로 전달하는 구조에 있기 때문입니다.

따라서 Shared Storage를 개발자 도구에서 발견했다고 해서 Local Storage처럼 Key와 Value를 열어보면 된다고 생각하면 안 됩니다.

오히려 이 저장소가 어떤 목적을 위해 존재했는지 이해하는 것이 중요합니다.

Shared Storage는 어디에 사용하려고 했을까?

Shared Storage는 특히 크로스 사이트 활용이 필요한 데이터를 대상으로 설계되었습니다.

대표적인 예가 광고 관련 측정입니다.

예를 들어 어떤 사용자가 여러 웹사이트에서 동일한 광고를 봤다고 가정해보겠습니다.

사이트 A에서 광고를 보고 사이트 B에서도 같은 광고를 봤다고 해서, 브라우저가 사용자의 모든 행동을 그대로 다른 사이트에 알려주는 방식은 개인정보 보호 측면에서 문제가 될 수 있습니다.

Shared Storage는 이런 상황에서 원본 데이터를 직접 노출하지 않고 필요한 작업을 수행하는 것을 목표로 했습니다.

또 다른 예로 A/B 테스트를 생각할 수 있습니다.

사용자를 실험 그룹 A와 B로 나누고 그 그룹 정보를 저장한 다음, 해당 정보에 따라 서로 다른 콘텐츠를 선택하는 방식입니다.

Shared Storage의 selectURL() 같은 출력 게이트를 이용하면 저장된 정보를 기반으로 표시할 URL을 선택하는 형태의 사용 사례가 설계되어 있었습니다.

Shared Storage의 데이터를 마음대로 읽을 수 없는 이유

Shared Storage를 이해할 때 가장 중요한 부분입니다.

일반적인 Local Storage라면 다음처럼 값을 가져올 수 있습니다.

const value = localStorage.getItem("userType");

하지만 Shared Storage는 이런 식으로 원본 값을 일반 페이지에서 직접 가져오는 것을 허용하지 않는 방향으로 설계되었습니다.

그 이유는 간단합니다.

Shared Storage가 여러 사이트에 걸친 데이터를 활용하기 위한 기술인데, 저장된 값을 아무 코드에서나 자유롭게 읽을 수 있다면 오히려 사용자 추적에 악용될 가능성이 있기 때문입니다.

그래서 Shared Storage에서는 데이터를 읽고 처리하는 작업을 제한된 Worklet 환경에서 수행하도록 했습니다.

결국 핵심은 데이터를 저장하는 것보다 데이터를 어떻게 외부에 노출하지 않고 활용할 것인가에 있습니다.

Shared Storage API는 어떻게 사용했을까?

기본적인 저장 방식은 다음과 같은 형태입니다.

window.sharedStorage.set(
    "ab-testing-group",
    "0"
);

이런 식으로 Key와 Value를 저장할 수 있습니다.

MDN에서도 set() 메서드를 통해 새로운 Key-Value를 저장하거나 기존 값을 변경할 수 있다고 설명하고 있습니다.

다만 여기서도 일반적인 Local Storage와 차이가 있습니다.

Shared Storage는 아무 웹사이트에서 바로 사용할 수 있는 범용 저장 기능처럼 생각해서는 안 됩니다.

기존 설계에서는 Privacy Sandbox 등록과 관련된 조건도 있었으며, 로컬 테스트를 위한 별도의 Chrome 설정도 제공되었습니다.

따라서 실제 프로젝트에서 코드를 그대로 따라 하기보다는 현재 브라우저 지원 상태와 공식 문서의 변경 사항을 먼저 확인하는 것이 중요합니다.

Shared Storage와 Session Storage의 차이

이름 때문에 Session Storage와 혼동할 수도 있습니다.

하지만 둘은 목적이 완전히 다릅니다.

Session Storage는 현재 브라우징 세션 동안 필요한 데이터를 저장하는 일반적인 Web Storage 기능입니다.

반면 Shared Storage는 여러 사이트에 걸친 데이터 활용과 개인정보 보호를 함께 고려한 Privacy Sandbox 계열의 기능으로 설계되었습니다.

간단하게 비교하면 다음과 같습니다.

Local Storage
→ 사이트의 데이터를 브라우저에 지속적으로 저장

Session Storage
→ 브라우징 세션 동안 데이터를 저장

Shared Storage
→ 사이트 간 활용을 고려하면서 원본 데이터 노출을 제한

즉 Shared Storage에서 “Shared”라는 단어를 단순히 여러 탭에서 데이터를 공유한다는 의미로 이해하면 안 됩니다.

여기서 중요한 것은 크로스 사이트 활용과 개인정보 보호를 함께 고려한 구조라는 점입니다.

지금 Shared Storage를 새 프로젝트에 사용해도 될까?

여기서는 현재 시점을 기준으로 주의해서 볼 필요가 있습니다.

MDN은 현재 Shared Storage API를 Deprecated로 표시하고 있으며, 향후 제거될 예정이라고 안내하고 있습니다. 또한 비표준 기능이며 브라우저 지원이나 동작이 변경될 수 있기 때문에 새로운 프로덕션 프로젝트에서 사용하는 것을 권장하지 않는다고 설명합니다.

따라서 지금 Shared Storage를 공부한다면 “앞으로 이 API를 적극적으로 사용해야 한다”는 의미보다는 Privacy Sandbox가 어떤 문제를 해결하려고 했는지 이해하기 위한 기술 지식으로 접근하는 편이 적절합니다.

특히 개발자 도구에서 새로운 저장소 이름을 발견했을 때 단순히 기능만 외우는 것보다 “왜 이런 저장소가 만들어졌을까?”를 생각해보는 것이 좋습니다.

개발자 도구의 Storage를 볼 때 기억할 것

지금까지 이 시리즈에서 여러 저장소를 살펴봤습니다.

Cookies부터 Local Storage, Session Storage, IndexedDB, Cache Storage, Extension Storage 그리고 Shared Storage까지 종류가 상당히 많습니다.

이름만 보면 전부 비슷하게 데이터를 저장하는 것처럼 보입니다.

하지만 실제로는 각각 목적이 다릅니다.

Cookies
→ 서버와 브라우저 사이의 상태 유지 등에 활용

Local Storage
→ 웹페이지의 지속적인 Key-Value 데이터 저장

Session Storage
→ 브라우징 세션 동안 필요한 데이터 저장

IndexedDB
→ 구조화된 데이터를 저장

Cache Storage
→ 요청과 응답 등의 리소스 캐싱

Extension Storage
→ 브라우저 확장 프로그램의 데이터 저장

Shared Storage
→ 크로스 사이트 활용과 개인정보 보호를 고려한 저장 방식

이렇게 목적을 구분해두면 개발자 도구를 열었을 때 훨씬 이해하기 쉬워집니다.

마무리

Shared Storage는 이름만 보면 Local Storage나 Session Storage의 또 다른 버전처럼 보입니다.

하지만 실제로는 전혀 다른 배경에서 만들어진 기술입니다.

특히 서드파티 쿠키를 대체하면서도 여러 사이트에 걸친 활용 사례를 지원하고 개인정보 보호를 강화하려는 Privacy Sandbox의 방향을 이해하는 데 중요한 기술이었습니다.

다만 현재 Shared Storage API는 변경 단계에 있으며 MDN에서도 Deprecated 및 제거 예정으로 표시하고 있습니다. 따라서 새 프로젝트에 적용하기보다는 현재 브라우저 플랫폼이 어떤 방향으로 변화해왔는지를 이해하는 관점에서 살펴보는 것이 좋습니다.

개발자 도구를 사용하다 보면 앞으로도 익숙하지 않은 저장소나 API를 발견할 수 있습니다.

그럴 때 단순히 “이건 데이터를 저장하는 기능이구나”라고 넘어가기보다는 어떤 문제를 해결하기 위해 만들어졌는지, 어떤 데이터를 보호하려고 하는지, 현재도 사용 가능한 기술인지까지 확인해보면 개발자 도구를 보는 눈도 조금씩 달라집니다.

특히 브라우저 기술은 계속 변하고 있기 때문에 개발자라면 API 이름만 외우는 것보다 이런 변화의 흐름을 함께 알아두는 것이 꽤 도움이 됩니다.