Conceptly
← 전체 목록
💾

Web Storage API

상태 관리브라우저에 키-값 데이터를 저장하는 클라이언트 측 API

Web Storage API는 브라우저에서 키-값 형태의 데이터를 저장할 수 있는 클라이언트 측 저장소입니다. localStorage는 브라우저를 닫아도 데이터가 유지되고, sessionStorage는 탭을 닫으면 삭제됩니다. 쿠키와 달리 서버로 자동 전송되지 않으며, 도메인당 5~10MB의 넉넉한 용량을 갖고 있어 클라이언트에서만 쓰는 데이터를 저장하기에 적합합니다. setItem, getItem, removeItem 같은 간단한 API로 동기적으로 데이터를 읽고 쓸 수 있습니다.

아키텍처 다이어그램

🔍 구조 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

브라우저에서 데이터를 저장해야 하는 상황은 쿠키만으로 해결되지 않는 경우가 많습니다. 쿠키는 매 HTTP 요청에 자동으로 실려 서버로 전송되기 때문에, 서버가 전혀 알 필요 없는 데이터까지 쿠키에 넣으면 요청마다 불필요한 트래픽이 생깁니다. 하나의 쿠키가 4KB, 도메인당 수십 개라는 제한도 걸려서 조금만 데이터가 커지면 공간이 부족합니다. 사용자가 다크 모드를 켜거나, 사이드바를 접거나, 목록의 정렬 순서를 바꾸는 것은 브라우저 안에서만 의미 있는 설정입니다. 이런 데이터를 서버까지 보내는 건 과하고, 매번 날리는 것은 사용자 경험을 해칩니다. 브라우저 안에서만 쓰되 쿠키보다 넉넉하고 서버 전송 부담이 없는 저장 방법이 필요했습니다.

왜 이런 방식이 등장했나요?

웹이 단순한 문서 뷰어에서 애플리케이션 플랫폼으로 진화하면서, 클라이언트 측에서 유지해야 할 상태가 점점 늘어났습니다. 쿠키는 원래 서버와의 상태 교환을 위해 만들어진 것이라, 클라이언트 전용 데이터를 담기에는 용량도 작고 매 요청에 전송되는 특성이 부담이었습니다. 2009년 HTML5 명세에 Web Storage API가 포함되면서 브라우저는 처음으로 HTTP와 무관한 독립적인 키-값 저장소를 갖게 됐습니다. 같은 시기에 웹 애플리케이션이 복잡해지면서 SPA(Single Page Application) 패턴이 확산됐고, 페이지 전환 없이 클라이언트 상태를 유지해야 하는 수요가 Web Storage의 채택을 빠르게 끌어올렸습니다.

안에서 어떻게 동작하나요?

Web Storage API는 두 가지 저장소로 나뉘며, 둘 다 같은 인터페이스를 공유합니다. localStorage는 데이터를 영구적으로 보관합니다. 브라우저를 닫았다 열어도, 컴퓨터를 재시작해도 남아 있고, 개발자가 removeItem이나 clear를 호출하거나 사용자가 직접 브라우저 데이터를 삭제하지 않으면 사라지지 않습니다. 같은 도메인이면 탭이 달라도 같은 localStorage를 공유합니다. sessionStorage는 브라우저 탭의 수명에 묶입니다. 같은 사이트를 새 탭에서 열면 각 탭은 독립적인 sessionStorage를 갖고, 탭을 닫으면 해당 저장소는 삭제됩니다. 폼에 입력 중인 데이터를 임시 보관하거나, 한 번의 방문 동안만 유효한 상태를 관리하는 데 적합합니다. 두 저장소 모두 문자열 키-값 쌍으로 동작합니다. 객체나 배열을 저장하려면 JSON.stringify로 변환한 뒤 넣고, 꺼낼 때 JSON.parse로 되돌려야 합니다. API 자체는 동기적으로 실행되기 때문에, 대량의 데이터를 한꺼번에 읽고 쓰면 메인 스레드가 잠시 멈출 수 있습니다. 이 점은 성능에 민감한 상황에서 주의가 필요합니다. 보안 측면에서, Web Storage는 같은 출처(프로토콜 + 도메인 + 포트)의 페이지만 접근할 수 있는 동일 출처 정책을 따릅니다. 하지만 JavaScript로 자유롭게 접근할 수 있기 때문에, XSS 취약점이 있으면 저장된 데이터가 공격자에게 노출됩니다. 인증 토큰이나 민감한 정보를 Web Storage에 넣는 것은 권장되지 않습니다.

무엇과 헷갈리나요?

Web Storage와 쿠키는 둘 다 브라우저에 데이터를 저장하지만, 설계 목적이 다릅니다. 쿠키는 서버에 자동으로 전송되므로 서버가 사용자를 식별하는 데 쓰이고, Web Storage는 서버와 무관하게 클라이언트에서만 데이터를 보관합니다. 용량도 쿠키의 4KB와 Web Storage의 5~10MB로 크게 차이납니다. Web Storage와 IndexedDB도 비교되는 경우가 많습니다. Web Storage는 문자열 키-값 쌍만 저장하고 동기 API라 간단한 설정값에 적합합니다. IndexedDB는 구조화된 데이터를 비동기로 다루며 인덱스 검색까지 지원하는 클라이언트 측 데이터베이스입니다. 수십 KB 이하의 단순한 값이면 Web Storage가 편하고, 데이터 양이 많거나 검색이 필요하면 IndexedDB가 맞습니다. localStorage와 sessionStorage의 선택 기준은 데이터의 수명입니다. 사용자가 다음에 다시 와도 남아 있어야 하면 localStorage, 이번 탭을 닫으면 사라져야 하면 sessionStorage입니다.

언제 쓰나요?

Web Storage는 SPA에서 클라이언트 상태를 유지하는 가장 간단한 방법으로 많이 쓰입니다. 사용자가 선택한 테마, 언어, 정렬 순서 같은 환경 설정을 localStorage에 저장하면 새로고침이나 재방문 시에도 동일한 환경을 복원할 수 있습니다. 폼이 긴 페이지에서는 sessionStorage에 입력 중인 데이터를 주기적으로 저장해, 실수로 탭을 새로고침해도 작성 내용이 날아가지 않게 하는 패턴이 일반적입니다. 탭을 닫으면 자연스럽게 사라지므로 별도의 정리 코드가 필요 없습니다. 주의할 점은 Web Storage에 인증 토큰을 보관하는 관행입니다. localStorage는 JavaScript로 자유롭게 접근 가능하기 때문에, XSS 취약점이 생기면 저장된 토큰이 그대로 탈취됩니다. 인증 관련 데이터는 HttpOnly 쿠키에 두는 것이 더 안전합니다. Web Storage는 유출돼도 보안 사고로 이어지지 않을 데이터에 쓰는 것이 바른 방향입니다. 또 하나 실무에서 놓치기 쉬운 점은, 시크릿 모드(Private Browsing)에서는 브라우저에 따라 localStorage의 동작이 달라지거나 용량이 제한될 수 있다는 것입니다. Web Storage에 의존하는 기능은 저장 실패 시의 대비 코드를 함께 두는 것이 안전합니다.

UI 상태 유지폼 임시 저장오프라인 캐시사용자 기본값