“Storage Buckets”, 저장한 데이터가 전부 같이 지워진다고?

들어가며

웹 서비스를 만들다 보면 어느 순간부터 브라우저에 저장해야 할 데이터가 꽤 많아진다.

로그인 상태나 사용자 설정처럼 간단한 데이터는 Local Storage에 넣을 수 있고, 조금 더 많은 데이터를 다뤄야 한다면 IndexedDB를 사용할 수도 있다. 오프라인 기능을 제공하는 웹 앱이라면 Cache Storage까지 함께 사용하게 된다.

그런데 여기서 한 가지 문제가 생긴다.

브라우저 저장 공간이 부족해지면 중요한 데이터와 덜 중요한 데이터를 똑같이 취급해도 괜찮을까?

예를 들어 오프라인 메모 앱을 만들었다고 생각해보자. 사용자가 아직 서버에 동기화하지 않은 중요한 메모와, 다시 다운로드하면 되는 이미지 캐시가 같은 저장 공간에 들어 있다면 저장 공간이 부족해졌을 때 어떤 데이터를 먼저 지워야 할지 구분하기가 어렵다.

이런 문제를 조금 더 세밀하게 다루기 위해 등장한 것이 바로 Storage Buckets다. Chrome에서는 개발자 도구의 Application > Storage 영역에서도 Storage Buckets를 직접 확인할 수 있다.

Storage Buckets란 무엇일까?

Storage Bucket을 아주 간단하게 생각하면 하나의 웹사이트 저장 공간을 목적에 따라 여러 개로 나눠 관리하는 방식이라고 볼 수 있다.

기존에는 하나의 origin에 저장되는 데이터를 사실상 하나의 큰 저장 공간처럼 관리하는 방식이 중심이었다. IndexedDB나 Cache API 같은 여러 저장 기술을 사용하더라도 브라우저 입장에서는 해당 사이트의 저장 데이터를 관리하는 큰 단위가 존재했다.

Storage Buckets를 사용하면 개발자가 이름을 가진 별도의 버킷을 만들 수 있다.

예를 들어 메일 서비스를 만든다면 다음과 같이 나눠볼 수 있다.

Storage Buckets
├─ inbox
├─ drafts
└─ cache

받은 메일과 임시 저장한 작성 중인 메일, 다시 받아올 수 있는 캐시 데이터를 서로 다른 버킷으로 구분하는 것이다.

Chrome에서 설명하는 대표적인 사용 사례도 비슷하다. 서버에 이미 저장된 받은 메일은 어느 정도 다시 가져올 수 있지만, 아직 서버에 저장되지 않은 임시 작성 내용은 삭제되면 곤란할 수 있다. Storage Buckets는 이런 데이터의 중요도를 서로 다르게 관리하기 위한 목적을 갖는다.

개발자 도구에서는 어디에서 볼 수 있을까?

Chrome DevTools를 열고 Application 탭으로 이동해보자.

왼쪽 메뉴에서 Storage 영역을 보면 Storage Buckets 항목을 확인할 수 있다.

Application
 └─ Storage
     └─ Storage Buckets

Chrome 126부터는 기존에 실험적으로 제공되던 Storage Buckets 트리가 기본적으로 활성화되어 Application > Storage에서 직접 확인할 수 있게 됐다.

이 부분이 꽤 재미있다.

예전에는 브라우저에 데이터가 저장됐다고 하면 Local Storage나 IndexedDB 같은 각각의 저장 기술을 찾아보는 느낌이었다. Storage Buckets는 그보다 한 단계 위에서 저장 공간이 어떤 버킷으로 나뉘어 있는지를 확인하는 구조에 가깝다.

실제로 Storage Bucket을 사용하는 사이트라면 버킷 이름을 확인하고 그 안에서 지원되는 저장 API와 연결된 데이터를 살펴볼 수 있다.

Storage Buckets는 왜 필요한 걸까?

가장 중요한 이유는 데이터의 삭제 우선순위를 구분할 수 있다는 점이다.

브라우저의 저장 공간은 무한하지 않다. 사용자의 디스크 공간이 부족해지거나 브라우저가 저장 공간을 정리해야 하는 상황이 발생하면 웹사이트의 저장 데이터가 영향을 받을 수 있다.

일반적인 사이트 저장 데이터는 기본적으로 best-effort 방식으로 관리된다. 즉, 브라우저가 저장 공간 압박을 받는 상황에서는 해당 데이터를 계속 보존한다고 보장할 수 없다. 반면 persistent storage를 요청하면 보다 강한 보존 정책을 적용할 수 있다.

Storage Buckets의 핵심은 여기서 한 단계 더 나아간다.

사이트 전체를 하나로 묶어서 생각하는 대신,

중요한 사용자 데이터
        ↓
important bucket

다시 다운로드할 수 있는 캐시
        ↓
cache bucket

처럼 저장 데이터를 목적에 맞게 나눌 수 있다.

Chrome의 Storage Buckets 설명에서도 브라우저가 저장 공간을 확보해야 할 때 각각의 버킷을 독립적으로 삭제할 수 있도록 하는 것이 핵심 개념이라고 설명한다.

JavaScript에서는 어떻게 만들까?

Storage Buckets API를 사용하는 기본적인 형태는 생각보다 간단하다.

const bucket = await navigator.storageBuckets.open("my-bucket");

navigator.storageBuckets.open()을 이용해 이름을 지정한 Storage Bucket을 만들거나 기존 버킷에 접근할 수 있다.

예를 들어 로그 데이터를 별도로 관리하고 싶다면 다음처럼 작성할 수 있다.

const logsBucket =
  await navigator.storageBuckets.open("logs-bucket");

이렇게 만들어진 버킷은 단순히 이름만 붙이는 공간이 아니다.

Storage Bucket에는 IndexedDB 같은 저장 API를 연결해서 사용할 수 있다.

const bucket =
  await navigator.storageBuckets.open("logs-bucket");

const request = bucket.indexedDB.open("logs", 1);

즉 기존 IndexedDB를 무조건 버리는 것이 아니라, 어떤 Storage Bucket에 속한 IndexedDB를 사용할 것인지 구분하는 방식으로 생각하면 이해하기 쉽다.

Chrome 공식 문서에서도 Storage Bucket에서 IndexedDB에 접근하는 방식을 소개하고 있으며, Chrome 126에서는 Storage Bucket을 활용해 IndexedDB 인스턴스를 분리하는 방식이 성능 측면에서도 소개됐다.

persistent와 durability도 확인해볼 부분

Storage Bucket을 만들 때는 단순히 이름만 지정할 수도 있지만 저장 데이터의 특성에 따라 옵션을 지정할 수도 있다.

예를 들어 중요한 데이터를 저장하는 버킷이라면 다음과 같은 형태를 사용할 수 있다.

const draftsBucket =
  await navigator.storageBuckets.open("drafts", {
    durability: "strict",
    persisted: true
  });

여기서 persisted는 저장 데이터를 지속적으로 보존하기 위한 옵션이고, durability는 데이터 쓰기의 내구성과 성능 사이에서 브라우저가 고려할 수 있는 힌트다.

durability에는 relaxed와 strict가 있으며, strict는 데이터 손실 가능성을 줄이는 방향인 대신 쓰기 성능이나 시스템 자원 측면에서 비용이 발생할 수 있다.

물론 persisted: true라고 설정했다고 해서 개발자가 원하는 순간에 절대 삭제되지 않는다는 식으로 이해하면 안 된다. 브라우저의 저장 정책과 사용자의 환경, 권한 등에 따라 실제 동작은 달라질 수 있다.

IndexedDB와 Storage Buckets의 관계

여기서 처음 보면 조금 헷갈릴 수 있는 부분이 있다.

이미 IndexedDB가 있는데 왜 Storage Buckets가 또 필요한 것일까?

IndexedDB는 데이터를 저장하는 기술이다.

반면 Storage Buckets는 저장 데이터를 관리하는 단위에 가깝다.

비유하면 IndexedDB가 창고 안에 있는 보관함이라면 Storage Bucket은 창고를 목적별로 나누는 구역이라고 생각하면 편하다.

예를 들어 다음과 같은 구조가 가능하다.

사이트
│
├─ 기본 저장 공간
│   └─ IndexedDB
│
├─ user-data bucket
│   └─ IndexedDB
│
└─ cache bucket
    └─ IndexedDB

Chrome 공식 자료에서는 Storage Bucket에 연결된 IndexedDB를 DevTools에서 확인할 수 있고, IndexedDB 성능 개선과 관련해서도 버킷별로 IDB 인스턴스를 분리하는 방법을 소개하고 있다.

Storage Buckets와 Local Storage는 같은 걸까?

이 부분도 개발하면서 한 번쯤 헷갈릴 만하다.

결론부터 말하면 같은 개념이 아니다.

Local Storage는 문자열 형태의 key-value 데이터를 간단하게 저장하기 위한 Web Storage API다. 반면 Storage Buckets는 웹사이트가 사용하는 저장 데이터를 관리하고 구분하기 위한 보다 큰 단위다.

그래서 다음처럼 이해하면 편하다.

Local Storage
→ 간단한 key-value 데이터 저장

Session Storage
→ 세션 동안 사용할 데이터 저장

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

Cache Storage
→ 요청/응답 캐시 저장

Storage Buckets
→ 저장 데이터를 목적별 버킷으로 구분하고 관리

Storage Buckets가 Local Storage의 대체재라고 생각하면 방향을 잘못 잡게 된다.

오히려 IndexedDB나 Cache 같은 기존 저장 기술을 어떻게 묶고 관리할 것인가에 가까운 개념이다.

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

실제로 웹 개발을 하다 보면 “분명 데이터를 저장했는데 어디에 있는 거지?”라는 상황을 자주 만나게 된다.

특히 오프라인 기능이나 PWA를 개발할 때는 Local Storage만 보는 것으로는 부족하다.

IndexedDB를 사용하는지, Cache Storage를 사용하는지, Service Worker가 어떤 캐시를 사용하는지 확인해야 할 때가 있다.

여기에 Storage Bucket까지 사용한다면 Application 탭에서 저장 구조를 확인하는 것이 상당히 중요해진다.

예를 들어 데이터가 예상하지 못한 위치에 저장되고 있다면 버킷 구조를 확인하면서 어느 저장 공간을 사용하고 있는지 추적할 수 있다.

Chrome DevTools는 Application > Storage에서 Storage Buckets를 별도의 트리 형태로 제공하고 있으며, 이를 통해 버킷과 연결된 저장 구조를 확인할 수 있다.

Storage Buckets를 꼭 사용해야 할까?

모든 웹사이트에서 Storage Buckets를 사용할 필요는 없다.

간단한 로그인 관련 상태나 사용자 설정 정도라면 Local Storage나 쿠키만으로 충분한 경우도 많다.

단순한 데이터 저장이라면 IndexedDB 역시 훌륭한 선택이다.

하지만 다음과 같은 서비스라면 이야기가 달라진다.

오프라인 웹 애플리케이션
대용량 로컬 데이터 서비스
PWA
온라인 문서 편집기
메일 또는 메모 서비스
IndexedDB 기반 애플리케이션
브라우저에서 장시간 데이터를 유지해야 하는 서비스

특히 삭제되어도 괜찮은 데이터와 절대 잃으면 안 되는 데이터를 구분해야 하는 서비스라면 Storage Buckets라는 개념을 알아두는 것이 좋다.

마무리

Chrome DevTools의 Storage Buckets를 처음 보면 “Storage에 또 새로운 저장 공간이 생겼네?” 정도로 생각하기 쉽다.

하지만 조금 들여다보면 단순한 저장 기능 하나가 추가된 것이 아니라는 걸 알 수 있다.

Local Storage, Session Storage, IndexedDB, Cache Storage처럼 브라우저에는 이미 여러 가지 저장 기술이 존재한다. Storage Buckets는 이런 저장 데이터를 보다 세밀하게 관리하기 위한 또 하나의 계층이라고 이해하면 쉽다.

특히 브라우저 저장 공간이 부족해졌을 때 어떤 데이터가 더 중요하고 어떤 데이터는 다시 만들어도 되는지를 구분해야 하는 웹 애플리케이션이라면 의미가 있다.

그리고 개발자 입장에서는 Application → Storage → Storage Buckets라는 위치만 기억해두어도 좋다.

나중에 IndexedDB나 Cache Storage를 사용한 서비스를 디버깅하다가 “이 데이터가 도대체 어느 저장 공간에 들어가 있는 거지?”라는 상황이 생겼을 때 한 번 확인해볼 만한 곳이다.

브라우저 저장소를 하나씩 공부하다 보면 처음에는 Local Storage와 Session Storage 정도만 보이지만, 실제 웹 애플리케이션으로 들어가면 IndexedDB, Cache Storage, Storage Buckets처럼 훨씬 다양한 구조가 등장한다.

결국 중요한 건 저장 기술의 이름을 많이 외우는 것보다 어떤 데이터를 어디에 저장하고, 브라우저가 그 데이터를 어떻게 관리하게 할 것인지 이해하는 것이다.