세션 스토리지와 로컬 스토리지: 전산학 브라우저 안에 데이터를 보관하는 여러 방식

새로고침해도 값이 남고, 탭을 닫으면 사라지는 이유가 궁금한가

웹사이트에서 로그인 상태가 유지되거나, 입력하던 폼 값이 남아 있는 경험이 있다. 그런데 같은 사이트라도 탭을 닫거나 브라우저를 껐다 켜면 값이 사라지는 경우가 있다.

이 차이는 브라우저가 데이터를 저장하는 “장소”와 “수명”이 다르기 때문이다. 세션 스토리지와 로컬 스토리지를 구분하면, 어디에 무엇을 담아야 하는지 판단이 쉬워진다.

• 세션 스토리지와 로컬 스토리지가 각각 언제까지 살아남는지
• 같은 사이트라도 탭/창에 따라 데이터가 달라질 수 있는 이유
• origin 단위로 저장이 분리되는 원리
• 문자열 저장 방식과 JSON 변환이 필요한 상황
• 실전에서 확인하고 정리하는 절차

탭 단위 임시 보관과, 브라우저에 남는 보관을 먼저 구분한다

세션 스토리지(sessionStorage): “현재 탭에서만 잠깐” 유지되는 보관함이다

정의: 세션 스토리지는 현재 열려 있는 브라우저 탭(또는 창) 단위로 데이터를 저장하는 공간이다. 같은 사이트라도 다른 탭을 열면 저장소가 분리되는 형태로 동작한다.

핵심 특징: 탭을 닫으면 해당 세션 스토리지는 함께 사라진다. 새로고침은 “같은 탭을 유지한 상태”이므로 값이 남는 편이다.

• 수명: 탭/창이 살아 있는 동안 유지되는 경향이 있다. 탭을 닫으면 삭제된다.
• 범위: 같은 origin 안에서도 탭마다 분리될 수 있다. 한 탭에서 저장한 값이 다른 탭에서 바로 보이지 않을 수 있다.
• origin 기준: 저장은 origin 단위로 묶인다. 보통 프로토콜(https), 호스트, 포트가 같아야 같은 origin으로 취급된다.
• 문자열 저장: 값은 기본적으로 문자열로 저장된다. 숫자·객체를 그대로 넣으면 의도와 다른 형태가 될 수 있어 JSON 변환이 자주 쓰인다.

주의점: 탭 간 공유를 기대하면 설계가 어긋난다. 예를 들어 “다른 탭에서 결제 진행 상황을 이어서 보기” 같은 요구가 있다면 세션 스토리지는 맞지 않다.

주의점: 임시라서 안전하다고 오해하기 쉽다. 세션 스토리지도 자바스크립트로 접근 가능하므로, 민감한 값(인증 토큰, 비밀번호에 준하는 정보)을 저장하는 방식은 위험해질 수 있다.

 

세션 스토리지와 로컬 스토리지의 저장 범위와 수명 비교

 

로컬 스토리지(localStorage): “브라우저에 남겨두는” 보관함이다

정의: 로컬 스토리지는 origin 단위로 데이터를 저장하고, 브라우저를 닫았다가 다시 열어도 값이 남을 수 있는 저장 공간이다.

핵심 특징: 같은 origin이라면 여러 탭/창에서 같은 로컬 스토리지를 공유하는 방식으로 쓰이는 경우가 많다. 사용자가 같은 사이트를 다시 방문했을 때 이전 설정을 복원하는 용도로 자주 활용된다.

• 수명: 명시적으로 삭제하지 않으면 계속 남을 수 있다. 브라우저 설정(사이트 데이터 삭제)이나 앱 정책에 따라 지워질 수 있다.
• 범위: 같은 origin이면 탭이 달라도 같은 저장소를 바라보는 경우가 흔하다.
• origin 기준: 다른 도메인이나 다른 포트라면 서로 접근할 수 없다. 개발 환경(localhost 포트)에서 값이 “따로따로” 저장되는 현상이 여기서 자주 나온다.
• 문자열 저장: 세션 스토리지와 마찬가지로 문자열 저장이 기본이다. 구조화된 데이터를 다루려면 JSON 직렬화/역직렬화를 고려해야 한다.

주의점: 오래 남는 만큼 “정리”가 필요하다. 이벤트가 끝났는데도 값이 남아 다음 방문에서 엉뚱한 상태를 만들 수 있다. 버전 키를 두거나 만료 시각을 같이 저장하는 방식이 자주 쓰인다.

주의점: 사용자 PC를 여러 사람이 공유하거나, 공용 PC를 쓰는 환경에서는 로컬 스토리지의 잔존이 곧 정보 노출이 될 수 있다. 로그인 유지 같은 민감한 상태는 별도 방식으로 다루는 편이 안전하다.

무엇이 더 맞는지는 “지연 허용”이 아니라 “수명과 공유 범위”에서 갈린다

두 저장소는 속도 비교보다 “언제까지 남아야 하는지”와 “어디까지 공유되어야 하는지”에서 선택이 갈린다.

같은 기능이라도 사용자 경험에 따라 저장소를 나누면, 예기치 않은 상태 꼬임을 줄일 수 있다.

비교 항목	세션 스토리지(sessionStorage)	로컬 스토리지(localStorage)
수명	탭/창이 닫히면 사라지는 성격이 강하다	삭제 전까지 남아 다음 방문에도 유지될 수 있다
공유 범위	탭 단위로 분리되는 경우가 많다	같은 origin의 여러 탭에서 공유되는 경우가 많다
origin 기준	origin 단위로 저장이 구분된다	origin 단위로 저장이 구분된다
저장 형태	키-값 문자열 저장이 기본이다	키-값 문자열 저장이 기본이다
잘 맞는 예	다단계 폼 임시 저장, 탭 내 진행 상태	다크모드 설정, 최근 검색어, UI 선호값
운영 관점 주의	탭을 닫는 순간 사라지는 전제를 지켜야 한다	만료/정리 정책이 없으면 오래된 값이 문제를 만든다

표 제목: 세션 스토리지 vs 로컬 스토리지 핵심 비교

어떤 상황이면 무엇을 쓰는가: YES/NO 체크리스트

• 질문: 사용자가 탭을 닫으면 데이터가 함께 사라져도 되는가. YES: 세션 스토리지를 고려한다. NO: 로컬 스토리지를 검토한다.
• 질문: 같은 사이트를 여러 탭으로 열었을 때 값이 섞이면 곤란한가. YES: 세션 스토리지가 유리하다. NO: 로컬 스토리지로도 충분할 수 있다.
• 질문: 다음 방문에서도 설정을 복원해야 하는가. YES: 로컬 스토리지가 어울린다. NO: 세션 스토리지로도 목적을 달성할 수 있다.
• 질문: 값이 오래 남아도 사용자에게 혼란이 없도록 만료 규칙을 둘 수 있는가. YES: 로컬 스토리지를 더 안정적으로 운영할 수 있다. NO: 세션 스토리지를 선택해 잔존 문제를 줄인다.
• 질문: 민감한 정보가 섞일 가능성이 있는가. YES: 브라우저 스토리지 저장을 재검토하고, 저장이 필요하다면 최소 정보만 남기도록 설계를 바꾼다. NO: 목적에 맞는 저장소를 선택한다.

실전 예시: 결제 직전 폼이 초기화되는 문제를 어디에 저장해 막을지 결정한다

문제: 쇼핑몰에서 주소·요청사항을 입력했는데, 결제 수단 선택 단계로 이동하거나 새로고침하는 순간 입력값이 일부 사라진다. 사용자는 다시 입력해야 해서 이탈이 늘어난다.

왜 발생: 입력값이 자바스크립트 변수나 화면 상태에만 존재하면, 페이지 전환·새로고침에서 상태가 초기화되기 쉽다. SPA 구조라도 라우팅 변경이나 예외 상황에서 상태가 리셋될 수 있다.

어떤 저장소가 적합: “현재 탭에서 결제 과정을 마치는 동안만” 입력값이 보존되면 충분하다면 세션 스토리지가 자연스럽다. 탭을 닫았는데도 이전 결제 입력값이 남는 것은 오히려 위험하거나 혼란이 될 수 있다.

잘못 쓰면 어떤 문제: 로컬 스토리지에 결제 폼 값을 그대로 저장하면 공용 PC에서 정보가 남을 수 있다. 또 만료 처리가 없으면 다음 방문 때 오래된 주소가 자동으로 채워져 잘못된 배송지로 이어질 수 있다.

확인/해결: 실제로 어떤 키가 저장되고, 언제 저장·삭제되는지 브라우저에서 직접 확인한 뒤, 저장 범위를 세션으로 바꾸거나 로컬에는 “선호 설정”만 남기는 방식으로 정리하는 편이 안정적이다.

브라우저에서 확인하는 방법: 저장 위치를 직접 보고 정리한다

1. 크롬 기준으로 개발자 도구를 연다(F12 또는 우클릭 후 검사).
2. 상단 탭에서 Application(애플리케이션)을 선택한다.
3. 좌측 메뉴에서 Storage 영역의 Local Storage를 펼치고, 현재 사이트(origin)를 선택한다.
4. 같은 방식으로 Session Storage를 펼치고, 현재 사이트(origin)를 선택한다.
5. 표 형태로 보이는 키-값 목록에서 결제 폼과 관련된 키가 어디에 저장되는지 확인한다.
6. 새로고침 후 값이 유지되는지, 탭을 새로 열었을 때 값이 공유되는지 비교해 저장소 특성을 체감한다.
7. 정리 대상 키를 선택하고 삭제한다. 테스트 중에는 Clear(전체 삭제)로 빠르게 상태를 초기화할 수 있다.
8. 저장 정책을 정한다. 결제 입력값처럼 임시 데이터는 세션 스토리지로, 다크모드·글자 크기 같은 선호 설정은 로컬 스토리지로 분리한다.

현장에서 자주 생기는 꼬임을 줄이는 정리 규칙

첫째, 로컬 스토리지에는 만료 기준을 함께 둔다. 예를 들어 저장 시각과 만료 시각을 같이 저장하면 “오래된 값”을 자동으로 폐기하기가 쉬워진다.

둘째, 키 이름에 목적과 범위를 드러낸다. 예를 들어 checkout_draft 같은 이름은 임시라는 의도를 드러내어 정리 대상 선정이 쉬워진다.

셋째, origin 차이를 먼저 의심한다. 개발 환경에서 포트가 바뀌면 저장소가 분리되어 “왜 값이 안 보이지” 같은 혼란이 자주 생긴다.

결론

세션 스토리지는 탭 단위로 잠깐 유지되는 임시 보관에 어울린다.

로컬 스토리지는 다음 방문까지 남겨야 하는 설정 보관에 어울린다.

수명과 공유 범위를 먼저 고정하면 저장소 선택이 흔들리지 않는다.

• 다음에 읽으면 좋은 연계 주제: 쿠키와 스토리지의 차이와 로그인 상태를 다루는 방식
• 다음에 읽으면 좋은 연계 주제: JSON 직렬화/역직렬화로 객체 데이터를 안전하게 저장하는 방법

FAQ

세션 스토리지는 새로고침하면 사라지는가

일반적으로 같은 탭에서 새로고침하는 경우 값이 유지되는 편이다. 다만 브라우저 정책이나 상황에 따라 차이가 있을 수 있으므로, 중요한 흐름은 실제 환경에서 확인한 뒤 설계하는 편이 안전하다.

로컬 스토리지에 로그인 토큰을 저장해도 되는가

자바스크립트로 접근 가능한 저장소에 민감한 값을 보관하면 위험이 커질 수 있다. 최소한의 정보만 저장하고, 인증 관련 값은 별도 정책으로 다루는 편이 안전하다.

같은 사이트인데도 저장된 값이 안 보이는 이유는 무엇인가

origin이 다르면 저장소가 분리되기 때문이다. 프로토콜, 도메인, 포트 중 하나라도 다르면 다른 저장소로 취급될 수 있어, 개발 환경의 포트 변경 같은 상황에서 특히 자주 발생한다.