Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

웹용 스토리지

브라우저에 데이터를 저장하는 방법은 다양합니다. 어떤 방법이 가장 적합할까요?

Pete LePage

인터넷 연결은 이동 중에 불안정하거나 존재하지 않을 수 있으므로 오프라인 지원과 안정적인 성능은 프로그레시브 웹 앱의 일반적인 기능입니다. 완벽한 무선 환경에서도 캐싱 및 기타 저장소 기술을 신중하게 사용하면 사용자 환경을 크게 개선할 수 있습니다. 정적 애플리케이션 리소스 (HTML, JavaScript, CSS, 이미지 등)와 데이터 (사용자 데이터, 뉴스 기사 등)를 캐시하는 방법은 여러 가지가 있습니다. 하지만 어떤 솔루션이 가장 좋을까요? 얼마나 저장할 수 있나요? 제거되지 않도록 하려면 어떻게 해야 하나요?

어떤 것을 사용해야 하나요?

다음은 리소스 저장에 관한 일반적인 권장사항입니다.

앱을 로드하는 데 필요한 네트워크 리소스에는 Cache Storage API (서비스 워커의 일부)를 사용합니다.
파일 기반 콘텐츠에는 Origin Private File System (OPFS)을 사용합니다.
기타 데이터에는 IndexedDB (프로미스 래퍼 포함)를 사용합니다.

IndexedDB, OPFS, Cache Storage API는 모든 최신 브라우저에서 지원됩니다. 비동기식이며 기본 스레드를 차단하지 않습니다 (하지만 웹 워커에서만 사용할 수 있는 OPFS의 동기식 변형도 있습니다). window 객체, 웹 워커, 서비스 워커에서 액세스할 수 있으므로 코드의 어느 곳에서나 사용할 수 있습니다.

다른 저장소 메커니즘은 어떤가요?

브라우저에서 사용할 수 있는 다른 저장소 메커니즘도 있지만 사용이 제한되어 있고 상당한 성능 문제가 발생할 수 있습니다.

SessionStorage는 탭별로 지정되며 탭의 수명으로 범위가 지정됩니다. 예를 들어 IndexedDB 키와 같이 세션별 정보를 소량 저장하는 데 유용할 수 있습니다. 동기식이며 기본 스레드를 차단하므로 주의해서 사용해야 합니다. 약 5MB로 제한되며 문자열만 포함할 수 있습니다. 탭별로 지정되므로 웹 워커 또는 서비스 워커에서 액세스할 수 없습니다.

LocalStorage는 동기식이며 기본 스레드를 차단하므로 피해야 합니다. 약 5MB로 제한되며 문자열만 포함할 수 있습니다. LocalStorage는 웹 워커 또는 서비스 워커에서 액세스할 수 없습니다.

쿠키는 용도가 있지만 저장소로 사용해서는 안 됩니다. 쿠키는 모든 HTTP 요청과 함께 전송되므로 소량 이상의 데이터를 저장하면 모든 웹 요청의 크기가 크게 늘어납니다. 동기식이며 웹 워커에서 액세스할 수 없습니다. LocalStorage 및 SessionStorage와 마찬가지로 쿠키는 문자열로만 제한됩니다.

File System Access API는 사용자가 로컬 파일 시스템에서 파일을 읽고 수정할 수 있도록 설계되었습니다. 페이지에서 로컬 파일을 읽거나 쓰려면 사용자가 권한을 부여해야 하며, 파일 핸들이 IndexedDB에 캐시되지 않는 한 권한은 세션 간에 유지되지 않습니다. File System Access API는 파일을 열고 수정한 다음 변경사항을 파일에 다시 저장해야 하는 편집기와 같은 사용 사례에 가장 적합합니다.

File System API 및 FileWriter API는 샌드박스 처리된 파일 시스템에서 파일을 읽고 쓰는 메서드를 제공합니다. 비동기식이지만 Chromium 기반 브라우저에서만 사용할 수 있으므로 권장되지 않습니다.

얼마나 저장할 수 있나요?

간단히 말해 많이 저장할 수 있습니다. 최소 수백 메가바이트, 잠재적으로 수백 기가바이트 이상을 저장할 수 있습니다. 브라우저 구현은 다르지만 사용 가능한 저장용량은 일반적으로 기기에서 사용 가능한 저장용량을 기반으로 합니다.

Chrome에서는 브라우저가 총 디스크 공간의 최대 80% 를 사용할 수 있습니다. 출처는 총 디스크 공간의 최대 60% 를 사용할 수 있습니다. StorageManager API를 사용하여 사용 가능한 최대 할당량을 확인할 수 있습니다. 다른 Chromium 기반 브라우저는 다를 수 있습니다.
- 시크릿 모드에서 Chrome은 출처가 사용할 수 있는 저장용량을 총 디스크 공간의 약 5% 로 줄입니다.
- 사용자가 Chrome에서 '모든 창을 닫을 때 쿠키 및 사이트 데이터 삭제'를 사용 설정한 경우 스토리지 한도가 최대 약 300MB로 크게 줄어듭니다.
Firefox에서는 브라우저가 사용 가능한 디스크 공간의 최대 50% 를 사용할 수 있습니다. eTLD+1 그룹 (예: example.com, www.example.com 및 foo.bar.example.com) 은 최대 2GB를 사용할 수 있습니다. StorageManager API를 사용하여 사용 가능한 공간을 확인할 수 있습니다.
Safari (데스크톱 및 모바일)는 약 1GB를 허용하는 것으로 보입니다. 한도에 도달하면 Safari에서 사용자에게 메시지를 표시하고 한도를 200MB씩 늘립니다. 이에 관한 공식 문서를 찾을 수 없었습니다.
- PWA가 모바일 Safari의 홈 화면에 추가되면 새 저장소 컨테이너가 생성되고 PWA와 모바일 Safari 간에 공유되는 항목이 없습니다. 설치된 PWA의 할당량에 도달하면 추가 저장용량을 요청하는 방법이 없는 것으로 보입니다.

이전에는 사이트에서 저장된 데이터의 특정 기준점을 초과하면 브라우저에서 사용자에게 더 많은 데이터를 사용할 수 있는 권한을 부여하라는 메시지를 표시했습니다. 예를 들어 출처에서 50MB 이상을 사용하면 브라우저에서 사용자에게 최대 100MB를 저장하도록 허용하라는 메시지를 표시한 다음 50MB씩 증가할 때마다 다시 묻습니다.

오늘날 대부분의 최신 브라우저는 사용자에게 메시지를 표시하지 않고 사이트에서 할당된 할당량을 사용할 수 있도록 허용합니다. 예외는 Safari인 것으로 보입니다. Safari는 스토리지 한도가 초과되면 메시지를 표시하고 할당된 할당량을 늘릴 수 있는 권한을 요청합니다. 출처에서 할당된 할당량을 초과하여 사용하려고 하면 데이터를 쓰려는 추가 시도가 실패합니다.

사용 가능한 저장용량을 어떻게 확인할 수 있나요?

대부분의 브라우저에서 StorageManager API를 사용하여 출처에 사용 가능한 저장용량과 사용 중인 저장용량을 확인할 수 있습니다. IndexedDB 및 Cache API에서 사용한 총 바이트 수를 보고하고 사용 가능한 대략적인 남은 저장공간을 계산할 수 있도록 합니다.

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

할당량 초과 오류를 포착해야 합니다 (아래 참고). 경우에 따라 사용 가능한 할당량이 실제 사용 가능한 저장용량을 초과할 수 있습니다.

검사

개발 중에 브라우저의 DevTools를 사용하여 다양한 저장소 유형을 검사하고 저장된 모든 데이터를 삭제할 수 있습니다.

Chrome 88에 저장소 창에서 사이트의 저장용량 할당량을 재정의할 수 있는 새로운 기능이 추가되었습니다. 이 기능을 사용하면 다양한 기기를 시뮬레이션하고 디스크 사용 가능성이 낮은 시나리오에서 앱의 동작을 테스트할 수 있습니다. 애플리케이션 > 저장소로 이동하여 맞춤 스토리지 할당량 시뮬레이션 체크박스를 사용 설정하고 유효한 숫자를 입력하여 저장용량 할당량을 시뮬레이션합니다.

이 가이드를 작성하는 동안 가능한 한 많은 저장용량을 빠르게 사용해 보는 간단한 도구를 작성했습니다. 다양한 저장소 메커니즘을 실험하고 할당량을 모두 사용했을 때 어떤 일이 발생하는지 확인하는 빠른 방법입니다.

할당량을 초과하는 경우 어떻게 처리해야 하나요?

할당량을 초과하면 어떻게 해야 하나요? 가장 중요한 것은 QuotaExceededError이든 다른 오류이든 항상 쓰기 오류를 포착하고 처리해야 한다는 것입니다. 그런 다음 앱 디자인에 따라 처리 방법을 결정합니다. 예를 들어 오랫동안 액세스하지 않은 콘텐츠를 삭제하거나 크기에 따라 데이터를 삭제하거나 사용자가 삭제할 항목을 선택할 수 있는 방법을 제공합니다.

IndexedDB와 Cache API 모두 사용 가능한 할당량을 초과하면 QuotaExceededError라는 DOMError를 발생시킵니다.

IndexedDB

출처에서 할당량을 초과한 경우 IndexedDB에 쓰려는 시도가 실패합니다. 트랜잭션의 onabort() 핸들러가 호출되고 이벤트를 전달합니다. 이벤트에는 오류 속성에 DOMException이 포함됩니다. 오류 name을 확인하면 QuotaExceededError가 반환됩니다.

const transaction = idb.transaction(['entries'], 'readwrite');
transaction.onabort = function(event) {
  const error = event.target.error; // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
};

Cache API

출처에서 할당량을 초과한 경우 Cache API에 쓰려는 시도는 QuotaExceededError DOMException으로 거부됩니다.

try {
  const cache = await caches.open('my-cache');
  await cache.add(new Request('/sample1.jpg'));
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}

제거는 어떻게 작동하나요?

웹 저장소는 '최선의 노력'과 '영구'라는 두 개의 버킷으로 분류됩니다. 최선의 노력은 사용자를 방해하지 않고 브라우저에서 저장소를 삭제할 수 있지만 장기 또는 중요한 데이터에는 내구성이 떨어집니다. 영구 스토리지의 저장용량이 부족할 때 자동으로 삭제되지 않습니다. 사용자는 브라우저 설정을 통해 이 저장소를 수동으로 삭제해야 합니다.

기본적으로 사이트의 데이터 (IndexedDB, Cache API 등)는 최선의 노력 카테고리에 속합니다. 즉, 사이트에서 영구 저장소를 요청하지 않는 한 브라우저는 기기 저장용량이 부족할 때와 같이 재량에 따라 사이트 데이터를 삭제할 수 있습니다.

최선의 노력에 관한 삭제 정책은 다음과 같습니다.

Chromium 기반 브라우저는 브라우저에 공간이 부족하면 데이터를 삭제하기 시작합니다. 가장 최근에 사용한 출처의 모든 사이트 데이터를 먼저 삭제한 다음 브라우저가 한도를 초과하지 않을 때까지 다음 출처의 데이터를 삭제합니다.
Firefox는 사용 가능한 디스크 공간이 가득 차면 데이터를 삭제하기 시작합니다. 가장 최근에 사용한 출처의 모든 사이트 데이터를 먼저 삭제한 다음 브라우저가 한도를 초과하지 않을 때까지 다음 출처의 데이터를 삭제합니다.
Safari는 이전에는 데이터를 삭제하지 않았지만 최근에 모든 쓰기 가능한 저장소에 새로운 7일 한도를 구현했습니다 (아래 참고).

iOS 및 iPadOS 13.4와 macOS의 Safari 13.1부터 IndexedDB, 서비스 워커 등록, Cache API를 비롯한 모든 스크립트 쓰기 가능한 저장소에 7일 한도가 적용됩니다. 즉, 사용자가 사이트와 상호작용하지 않으면 Safari는 Safari를 사용한 지 7일 후에 캐시에서 모든 콘텐츠를 삭제합니다. 이 삭제 정책은 홈 화면에 추가된 설치된 PWA에는 적용되지 않습니다. 자세한 내용은 WebKit 블로그의 서드 파티 쿠키 전체 차단 및 추가 정보를 참고하세요.

저장소 버킷

Storage Buckets API의 핵심 아이디어는 사이트에 여러 저장소 버킷을 만들 수 있는 기능을 부여하는 것입니다. 브라우저는 다른 버킷과 독립적으로 각 버킷을 삭제할 수 있습니다. 이를 통해 개발자는 삭제 우선순위를 지정하여 가장 중요한 데이터가 삭제되지 않도록 할 수 있습니다.

보너스: IndexedDB에 래퍼를 사용하는 이유

IndexedDB는 사용하기 전에 상당한 설정이 필요한 하위 수준 API이며, 특히 복잡성이 낮은 데이터를 저장하는 데 어려움을 겪을 수 있습니다. 대부분의 최신 프로미스 기반 API와 달리 이벤트 기반입니다. IndexedDB용 idb와 같은 프로미스 래퍼는 일부 강력한 기능을 숨기지만 더 중요한 것은 IndexedDB 라이브러리와 함께 제공되는 복잡한 메커니즘 (예: 트랜잭션, 스키마 버전 관리) 을 숨긴다는 것입니다.

보너스: SQLite Wasm

Web SQL이 지원 중단되고 Chrome에서 삭제된 후 Google은 인기 있는 SQLite 데이터베이스의 유지관리자와 협력하여 SQLite를 기반으로 Web SQL을 대체할 수 있는 기능을 제공했습니다. 사용 방법에 관한 자세한 내용은 Origin Private File System으로 지원되는 브라우저의 SQLite Wasm을 참고하세요.

결론

저장용량이 제한되고 사용자에게 더 많은 데이터를 저장하라는 메시지를 표시하던 시대는 지났습니다. 사이트는 실행하는 데 필요한 모든 리소스와 데이터를 효과적으로 저장할 수 있습니다. StorageManager API를 사용하면 사용 가능한 용량과 사용한 용량을 확인할 수 있습니다. 영구 저장소를 사용하면 사용자가 삭제하지 않는 한 삭제되지 않도록 보호할 수 있습니다.

추가 리소스

감사합니다.

이 가이드를 검토해 주신 Jarryd Goodman, Phil Walton, Eiji Kitamura, Daniel Murphy, Darwin Huang, Josh Bell, Marijn Kruisselbrink, Victor Costan께 특별히 감사의 말씀을 전합니다. 이 가이드의 기반이 된 원본 기사를 작성해 주신 Eiji Kitamura, Addy Osmani, Marc Cohen께도 감사의 말씀을 전합니다. Eiji는 현재 동작을 검증하는 데 유용한 브라우저 저장소 악용자라는 유용한 도구를 작성했습니다. 이 도구를 사용하면 가능한 한 많은 데이터를 저장하고 브라우저의 저장용량 한도를 확인할 수 있습니다. Safari의 저장용량 한도를 파악하기 위해 Safari를 조사해 주신 François Beaufort님과 2024년에 Origin Private 파일 시스템, 저장소 버킷, SQLite Wasm에 관한 정보와 전반적인 콘텐츠 업데이트를 추가해 주신 Thomas Steiner님께도 감사의 말씀을 전합니다.