localStorage와 sessionStorage 차이: 저장 기간, 탭 범위, 보안 기준으로 고르기
빠른 답
localStorage는 브라우저를 닫아도 값이 남고, 같은origin의 여러 탭에서 공유됩니다.sessionStorage는 탭 또는 창 단위 세션에 묶이며, 해당 탭을 닫으면 값이 사라집니다.- 둘 다 JavaScript로 읽고 쓸 수 있으므로 인증 토큰, 비밀번호, 개인정보 저장소로 보기에는 위험합니다.
- 테마·언어 설정처럼 오래 유지할 값은
localStorage, 현재 탭 안에서만 필요한 임시 상태는sessionStorage가 어울립니다.
목차
한눈에 비교
localStorage와 sessionStorage는 모두 Web Storage API에 속합니다. 사용법은 거의 같습니다. setItem, getItem, removeItem, clear 같은 메서드를 공통으로 사용하고, 키와 값은 문자열 형태로 저장됩니다.
헷갈리는 지점은 API 모양이 아니라 수명과 범위입니다. 어떤 값이 다음 방문에도 남아야 하는지, 여러 탭에서 같은 값을 공유해도 되는지에 따라 선택이 달라집니다.
시간 흐름으로 이해하기
이 흐름을 기준으로 보면 sessionStorage는 “새로고침하면 사라지는 저장소”가 아닙니다. 같은 탭에서는 새로고침 후에도 유지됩니다. 차이가 크게 드러나는 시점은 새 탭을 열거나 탭을 닫을 때입니다.
origin과 탭 범위 이해하기
Web Storage는 origin 단위로 나뉩니다. origin은 프로토콜, 호스트, 포트 조합입니다. 예를 들어 아래 주소들은 서로 같은 저장소를 공유하지 않습니다.
https://example.com
http://example.com
https://example.com:8443
https://admin.example.com
겉으로는 같은 서비스처럼 보여도 origin이 다르면 localStorage도 공유되지 않습니다. 반대로 같은 origin 안에서는 여러 페이지와 탭이 localStorage 값을 공유할 수 있습니다.
sessionStorage의 “session”은 서버 로그인 세션과 다릅니다. 서버가 관리하는 인증 세션이 아니라, 브라우저의 특정 탭 또는 창에 묶인 클라이언트 저장 공간입니다. 그래서 이름만 보고 로그인 정보를 넣는 장소로 이해하면 보안 설계가 흐려질 수 있습니다.
저장소 선택 규칙 만들기
프로젝트에서 저장소 키를 여기저기 직접 쓰기 시작하면 시간이 지나면서 기준을 파악하기 어려워집니다. 값의 성격과 저장 위치를 작은 설정으로 모아 두면 유지보수가 쉬워집니다.
const storageConfig = {
theme: {
key: "app:theme",
storage: "local",
},
draftOrder: {
key: "checkout:draft-order",
storage: "session",
},
searchFilter: {
key: "products:search-filter",
storage: "session",
},
};
function getStorage(type) {
return type === "local" ? window.localStorage : window.sessionStorage;
}
키 이름에는 기능이나 앱 이름을 접두사로 붙이는 편이 좋습니다. theme처럼 짧은 이름은 같은 origin 안의 다른 코드와 충돌할 수 있습니다. app:theme, checkout:draft-order처럼 범위를 드러내면 어떤 기능의 값인지 읽기 쉽습니다.
전체 삭제에 가까운 clear() 사용도 조심해야 합니다. 같은 저장소 안에 여러 기능의 값이 함께 들어 있을 수 있기 때문입니다. 대부분의 경우에는 삭제할 키를 명확히 정하고 removeItem()을 사용하는 쪽이 낫습니다.
실제 사용 예시
테마처럼 다음 방문에도 유지되면 좋은 값은 localStorage에 둘 수 있습니다. 값이 없을 때의 기본값도 함께 처리하면 초기 화면을 안정적으로 만들 수 있습니다.
const themeKey = "app:theme";
function saveTheme(theme) {
localStorage.setItem(themeKey, theme);
}
function loadTheme() {
return localStorage.getItem(themeKey) ?? "light";
}
function resetTheme() {
localStorage.removeItem(themeKey);
}
saveTheme("dark");
console.log(loadTheme());
폼 임시 입력값처럼 현재 탭 안에서만 복원하면 되는 데이터는 sessionStorage에 둘 수 있습니다. Web Storage는 문자열 저장소이므로 객체와 배열은 JSON으로 직렬화해서 저장합니다.
const draftKey = "signup:draft";
function saveDraft(formValue) {
sessionStorage.setItem(draftKey, JSON.stringify(formValue));
}
function loadDraft() {
const raw = sessionStorage.getItem(draftKey);
if (!raw) {
return null;
}
try {
return JSON.parse(raw);
} catch {
sessionStorage.removeItem(draftKey);
return null;
}
}
saveDraft({
email: "user@example.com",
marketingAgreed: false,
});
JSON.parse는 잘못된 문자열을 만나면 예외를 던집니다. 저장소 값은 사용자가 개발자 도구에서 직접 바꿀 수도 있고, 이전 버전의 앱이 남긴 형식이 현재 코드와 맞지 않을 수도 있습니다. 읽는 쪽에 실패 처리를 두면 이런 상황에서 화면 전체가 깨지는 일을 줄일 수 있습니다.
언제 무엇을 저장할까
테마, 언어, 목록 정렬 방식, 사이드바 접힘 여부처럼 사용자 설정에 가까운 값은 localStorage에 둘 만합니다. 브라우저를 닫았다가 다시 열어도 이어지는 편이 사용자 경험과 맞기 때문입니다.
장바구니는 서비스 성격에 따라 달라집니다. 비회원 장바구니를 브라우저에 보조적으로 유지하려면 localStorage를 사용할 수 있습니다. 다만 가격, 할인, 재고, 배송비처럼 서버 검증이 필요한 값은 브라우저 저장소를 신뢰하면 안 됩니다. 브라우저에는 상품 ID와 수량 정도만 저장하고, 최종 계산은 서버에서 다시 확인하는 구조가 필요합니다.
결제 단계의 임시 선택값, 신청서 작성 중인 값, 현재 탭의 검색 필터처럼 탭을 닫으면 함께 사라져도 되는 값은 sessionStorage 쪽이 잘 맞습니다. 여러 탭에서 서로 다른 작업을 동시에 할 수 있는 화면이라면, 값이 탭마다 분리되는 특성이 도움이 됩니다.
보안 주의점
localStorage와 sessionStorage는 JavaScript로 접근할 수 있습니다. 이 특성은 개발할 때 편리하지만, XSS 공격이 발생하면 위험해집니다. 페이지에서 악성 스크립트가 실행될 수 있다면 그 스크립트도 저장소 값을 읽을 수 있습니다.
sessionStorage는 탭을 닫으면 사라지므로 저장 기간은 짧습니다. 하지만 JavaScript에서 읽을 수 있다는 성질은 localStorage와 같습니다. 인증 토큰, 비밀번호, 주민등록번호, 결제 정보처럼 유출 피해가 큰 값은 Web Storage에 두지 않는 편이 안전합니다.
인증 상태는 서버가 설정하는 HttpOnly 쿠키를 함께 검토할 수 있습니다. HttpOnly 쿠키는 JavaScript에서 직접 읽을 수 없어 XSS 상황에서 토큰 노출 가능성을 줄입니다. 다만 쿠키를 쓴다고 모든 보안 문제가 해결되지는 않습니다. Secure, SameSite, CSRF 대응, XSS 방어가 함께 설계되어야 합니다.
브라우저 저장소의 값은 사용자가 수정할 수 있다는 점도 중요합니다. 예를 들어 localStorage에 isAdmin: true를 저장해 두고 권한을 판단하면 안 됩니다. 클라이언트 저장소는 UI 상태나 캐시를 위한 보조 저장소로 보고, 권한과 결제 같은 판단은 서버에서 검증해야 합니다.
저장 실패와 예외 처리
Web Storage에는 용량 제한이 있고, 브라우저 환경에 따라 쓰기가 실패할 수 있습니다. 사생활 보호 모드, 모바일 브라우저, 임베디드 웹뷰에서는 저장소 정책이 다르게 동작할 수 있습니다.
저장 실패가 앱 전체 오류로 번지지 않도록 저장소 접근을 작은 함수로 감싸 둘 수 있습니다.
function safeSetItem(storage, key, value) {
try {
storage.setItem(key, value);
return true;
} catch {
return false;
}
}
const saved = safeSetItem(localStorage, "app:theme", "dark");
if (!saved) {
console.warn("브라우저 저장소에 테마를 저장하지 못했습니다.");
}
이런 처리는 저장소가 편의 기능일 때 특히 유용합니다. 테마 저장에 실패하더라도 화면 자체는 사용할 수 있어야 합니다. 반대로 저장 실패가 치명적인 데이터라면 Web Storage만으로 요구사항을 충족하기 어렵다는 신호로 보는 편이 좋습니다.
흔한 오해 정리
sessionStorage는 새로고침 때 사라지지 않습니다. 같은 탭에서 새로고침하면 값이 유지됩니다. 탭 또는 창을 닫을 때 해당 저장 공간이 사라진다고 이해하는 편이 정확합니다.
localStorage 값은 HTTP 요청에 자동으로 포함되지 않습니다. 쿠키와 달리 Web Storage 값은 서버로 자동 전송되지 않습니다. 서버로 보내야 한다면 JavaScript 코드가 직접 값을 읽어 요청 본문이나 헤더에 담아야 합니다.
간단한 동작 차이는 브라우저 콘솔에서 확인할 수 있습니다. 같은 사이트에서 아래 코드를 실행한 뒤 새로고침, 새 탭 열기, 탭 닫기를 순서대로 확인하면 범위 차이가 드러납니다.
localStorage.setItem("demo:local", "kept");
sessionStorage.setItem("demo:session", "tab-only");
console.log(localStorage.getItem("demo:local"));
console.log(sessionStorage.getItem("demo:session"));
테스트가 끝난 뒤에는 사용한 키만 지우면 됩니다.
localStorage.removeItem("demo:local");
sessionStorage.removeItem("demo:session");
선택 기준 정리
저장소를 고를 때는 먼저 데이터의 수명을 봅니다. 다음 방문에도 남아야 하는 사용자 설정이라면 localStorage가 맞는 경우가 많고, 현재 탭에서 진행 중인 작업에만 의미가 있다면 sessionStorage가 더 잘 맞습니다.
그다음은 공유 범위입니다. 같은 페이지를 여러 탭에서 열었을 때 값이 공유되어도 괜찮은지 확인해야 합니다. 테마는 공유되어도 어색하지 않지만, 서로 다른 결제 탭의 임시 주문 정보가 공유되면 혼란을 만들 수 있습니다.
마지막으로 보안을 봅니다. 두 저장소 모두 클라이언트 편의를 위한 저장소이지 민감 정보를 보호하는 경계는 아닙니다. 노출되어도 피해가 제한적인 UI 상태와 캐시를 저장하는 용도로 사용하고, 인증과 권한 검증은 서버 중심으로 설계하는 편이 안전합니다.
원문 참고
https://www.maeil-mail.kr/question/85
댓글
댓글 쓰기