브라우저 저장소 (쿠키, 웹스토리지, 로컬스토리지, 세션스토리지)

https://www.youtube.com/watch?v=5s--sLWzuZc

 

웹 개발자를 위한 브라우저 저장소 완벽 가이드: 쿠키, 로컬, 세션 스토리지 심층 분석

서론: 왜 브라우저 저장소를 알아야 하는가?

혹시 사용자의 장바구니가 탭을 닫았다는 이유만으로 사라지거나, 재부팅 후 웹사이트가 당신을 기억하지 못해 답답했던 경험이 있으신가요? 그 해답은 바로 브라우저 저장소에 있습니다. 그리고 이를 마스터하는 것은 모든 웹 개발자에게 협상 불가능한 필수 역량입니다.

웹 통신의 근간이 되는 HTTP 프로토콜은 본질적으로 '상태를 유지하지 않는(stateless)' 특성을 가집니다. 이는 각 요청이 독립적으로 처리되어, 서버는 이전 요청에 대한 정보를 기억하지 못한다는 의미입니다. 이러한 특성 때문에 페이지를 이동할 때마다 사용자는 로그인을 반복해야 하는 등 극심한 불편을 겪을 수 있습니다.

바로 이 문제를 해결하기 위해 등장한 핵심 기술이 브라우저 저장소입니다. 이 글에서는 웹 개발자라면 반드시 알아야 할 브라우저 저장소 기술인 쿠키, 로컬 스토리지, 세션 스토리지의 특징과 차이점을 심층적으로 분석하고, 실제 개발 상황에 맞는 최적의 기술을 선택하는 가이드를 제공하고자 합니다.

--------------------------------------------------------------------------------

1. HTTP 프로토콜의 한계와 상태 관리의 필요성

본격적으로 브라우저 저장소를 알아보기 전에, 왜 이 기술이 필요한지를 이해하는 것이 중요합니다. 그 중심에는 바로 HTTP 프로토콜의 본질적인 한계가 있습니다. HTTP 통신은 기본적으로 요청(Request) → 응답(Response) → 연결 종료라는 단순한 흐름으로 동작합니다. 서버가 클라이언트에게 응답을 보내는 순간, 둘 사이의 연결은 종료됩니다. 바로 이 **'연결 종료'**라는 특성 때문에, 서버는 방금 전의 요청을 포함한 그 어떤 과거의 통신 기록도 기억할 내장된 메커니즘을 가지고 있지 않습니다. 이것이 바로 HTTP가 '상태를 유지하지 않는다(stateless)'고 불리는 근본적인 이유입니다.

이러한 상태 비유지 특성은 장점과 단점을 명확하게 가집니다.

장점	단점
연결 상태를 유지하지 않아 자원 낭비가 적음	통신할 때마다 새로운 연결과 인증이 필요하여 비효율적임

이 단점은 실제 사용자 경험에 직접적인 영향을 미칩니다. 예를 들어, 사용자가 온라인 쇼핑몰에서 성공적으로 로그인했더라도, 다른 상품 페이지로 이동하는 순간 서버는 그 사용자가 누구인지 잊어버리게 됩니다. 결국, 사용자는 페이지를 옮길 때마다 반복적으로 로그인해야 하는 불편함을 감수해야 합니다.

이러한 문제를 해결하기 위해서는 사용자의 로그인 정보와 같은 **상태(State)**를 어딘가에 저장해두고, 필요할 때마다 꺼내 쓸 수 있는 메커니즘이 필요합니다. 그리고 이 역할을 수행하는 가장 대표적인 해결책이 바로 다음 섹션에서 다룰 브라우저 저장소입니다.

2. 브라우저 저장소의 종류: 쿠키와 웹 스토리지

브라우저 저장소란, 이름 그대로 **'브라우저의 저장 공간'**을 의미합니다. 웹사이트의 특정 데이터(예: 사용자 ID, 장바구니 목록 등)를 사용자의 컴퓨터 브라우저에 직접 저장하여, HTTP의 상태 비유지 특성을 보완하는 기술입니다.

브라우저 저장소는 크게 두 가지 카테고리로 나뉩니다.

 

1. 쿠키 (Cookie)

 

2. 웹 스토리지 (Web Storage)

웹 스토리지는 HTML5부터 등장한 기술로, 기존의 쿠키가 가진 여러 단점을 보완하기 위해 만들어졌습니다. 또한 웹 스토리지는 데이터의 '지속성'에 따라 다음과 같이 두 종류로 다시 구분됩니다.

• 로컬 스토리지 (Local Storage)

 

• 세션 스토리지 (Session Storage)

개발자는 크롬 브라우저의 개발자 도구(F12)를 열고 Application 탭으로 이동하면 이 세 가지 저장소를 직접 확인하고 관리할 수 있습니다.

이 세 가지 기술은 세부적인 특징에서 차이를 보이지만, **'특정 도메인에 대한 데이터를 브라우저에 저장한다'**는 공통점을 가집니다. 이제 각 저장소의 기술적 특성과 장단점을 자세히 살펴보겠습니다.

 

 

3. 각 저장소별 기술적 특성 및 장단점 심층 분석

쿠키, 로컬 스토리지, 세션 스토리지는 각각 고유한 특징과 생명 주기를 가지고 있습니다. 프로젝트의 요구사항에 맞는 최적의 기술을 선택하기 위해서는 이 차이점을 명확히 이해하는 것이 필수적입니다.

3.1. 쿠키 (Cookie)

쿠키는 가장 오래되고 전통적인 브라우저 저장소 기술입니다. 그 핵심 정체성은 **'서버가 클라이언트에게 전송하는 작은 데이터 파일'**이라 할 수 있습니다. 쿠키에는 이름, 값 외에도 데이터의 유효 기간과 접근 범위를 지정하는 도메인, 경로, 만료일시 등의 정보가 포함됩니다. 여기서 도메인(Domain)과 경로(Path) 속성은 쿠키의 활동 범위를 정의하는 스코프(scope) 역할을 합니다. 즉, 브라우저가 어떤 요청에 이 쿠키를 첨부해야 하는지를 결정하는 중요한 기준이 됩니다.

• 장점:

    ◦ 높은 호환성: 거의 모든 브라우저에서 지원되어 호환성 걱정이 없습니다.

• 단점:

    ◦ 불필요한 트래픽 유발: 매 HTTP 요청마다 쿠키 전체가 헤더에 담겨 서버로 전송됩니다. 마치 매번 입장권을 보여주는 대신 가방 속 모든 소지품을 꺼내 보여주는 것과 같습니다. 이는 특히 모바일 네트워크 환경에서 성능 저하의 주범이 될 수 있습니다.

    ◦ 작은 저장 용량: 저장 용량이 약 4KB로 매우 작아, 간단한 식별자나 설정 플래그 외의 데이터를 담기에는 부적합합니다.

    ◦ 보안 취약성: XSS(Cross-Site Scripting) 공격을 통해 세션 쿠키를 탈취당할 위험이 있습니다. 이 때문에 인증 토큰과 같은 민감한 데이터는 HttpOnly, Secure 플래그를 설정하여 보안을 강화하거나, 가급적 웹 스토리지를 사용하는 것이 권장됩니다.

3.2. 웹 스토리지: 로컬 스토리지와 세션 스토리지

HTML5부터 도입된 웹 스토리지는 쿠키와 기능적으로 유사하지만, 쿠키의 단점을 보완하는 결정적인 차이점을 가집니다.

웹 스토리지의 핵심 특징

1. 데이터를 클라이언트에만 저장하며, 매 요청마다 서버로 전송하지 않아 트래픽 낭비가 없습니다.

2. 간단한 키(Key)-값(Value) 형태로 데이터를 저장하여 사용이 매우 간편합니다.

웹 스토리지는 데이터가 얼마나 오래 유지되는지, 즉 '데이터의 지속성'을 기준으로 로컬 스토리지와 세션 스토리지로 나뉩니다.

3.2.1. 로컬 스토리지 (Local Storage): 데이터의 영속성

로컬 스토리지의 가장 중요한 특징은 **데이터의 영속성(Persistence)**입니다. 데이터가 사용자의 브라우저 자체에 저장되므로, 브라우저를 종료했다가 다시 열어도 데이터가 그대로 유지됩니다. 사용자가 직접 데이터를 삭제하지 않는 한 사라지지 않습니다.

3.2.2. 세션 스토리지 (Session Storage)

세션 스토리지는 데이터의 생명 주기가 매우 독특합니다. 데이터가 **'탭(Tab) 또는 윈도우(Window) 단위'**로 생성되고 관리됩니다. 즉, 사용자가 웹사이트를 보고 있는 탭을 닫으면 해당 탭에 저장되었던 데이터는 즉시 삭제됩니다. 같은 웹사이트라도 다른 탭에서 열면 새로운 세션이 시작되어 데이터가 공유되지 않습니다.

4. 상황별 최적의 저장소 선택 가이드

지금까지 분석한 각 저장소의 기술적 특성을 바탕으로, 실제 개발 시나리오에서 어떤 저장소를 선택하는 것이 가장 효율적인지 알아보겠습니다. 올바른 기술 선택은 애플리케이션의 성능을 최적화하고 사용자 경험을 극대화하는 첫걸음입니다.

시나리오 1: 자동 로그인 유지

• 추천 기술: 로컬 스토리지 (Local Storage)

• 선택 이유: 사용자가 브라우저를 닫았다가 며칠 뒤에 다시 방문해도 로그인 상태가 유지되어야 합니다. 이처럼 반영구적으로 데이터를 보존해야 하는 기능에는 브라우저를 종료해도 데이터가 사라지지 않는 로컬 스토리지가 가장 적합합니다.

시나리오 2: 비로그인 장바구니, 입력 폼 임시 저장

• 추천 기술: 세션 스토리지 (Session Storage)

• 선택 이유: 사용자가 현재 보고 있는 탭 내에서만 유지되면 충분한 데이터들입니다. 글을 작성하다 잠시 다른 페이지를 보고 돌아왔을 때 입력 내용이 남아있어야 하지만, 탭을 닫으면 보존할 필요는 없죠. 이처럼 현재의 브라우징 세션에 한정된 데이터를 다룰 때는 탭을 닫으면 자동으로 데이터가 정리되는 세션 스토리지가 이상적입니다.

시나리오 3: "오늘 하루 보지 않기" 팝업

• 추천 기술: 쿠키 (Cookie)

• 선택 이유: 이 기능의 핵심 요구사항은 '시간 기반의 만료'입니다. 로컬 스토리지나 세션 스토리지는 이런 기능을 네이티브로 제공하지 않습니다. 반면 쿠키는 내장된 만료일시(Expires) 속성을 통해 이 작업을 완벽하게 수행할 수 있는, 이 시나리오를 위한 최적의 도구입니다.

이처럼 각 저장소의 고유한 특성을 이해하고 상황에 맞게 적용하면, 불필요한 데이터를 남기지 않고 네트워크 자원을 효율적으로 사용하며, 사용자에게는 더욱 편리하고 직관적인 경험을 제공할 수 있습니다.

5. 결론: 현명한 개발자를 위한 제언

지금까지 웹 개발의 필수 지식인 브라우저 저장소 기술, 쿠키, 로컬 스토리지, 세션 스토리지에 대해 알아보았습니다. 세 기술의 핵심적인 차이를 다시 한번 요약하면 다음과 같습니다.

• 쿠키: 만료일 설정이 가능하고 서버와 통신하지만, 용량이 작고 매 요청 시 전송됩니다.

• 로컬 스토리지: 반영구적으로 데이터를 저장하며, 서버로 전송되지 않습니다.

• 세션 스토리지: 탭/윈도우 단위로 데이터를 저장하며, 해당 탭을 닫으면 데이터가 삭제됩니다.

주니어에서 시니어 개발자로 성장한다는 것은 모든 최신 프레임워크를 아는 것보다, 오히려 이러한 기초적인 개념을 깊이 있게 마스터하는 것에 있습니다. 쿠키, 로컬 스토리지, 세션 스토리지 사이에서 올바른 선택을 내리는 것은 사소해 보이지만, 애플리케이션의 성능, 보안, 그리고 사용자 경험에 지대한 영향을 미치는 결정입니다. 현명하게 선택하십시오.

 

 

 

 

---

Q. 쿠키는 같은 호스트끼리만  소통이 되는지?

A. 결론부터 말하면 쿠키(Cookie)는 “같은 도메인(호스트)” 또는 “허용된 도메인 범위” 내에서만 자동 전송됩니다.

 

🔹 기본 원칙

• 쿠키는 “도메인 단위”로 구분돼요.
  예를 들어 example.com 에서 발급된 쿠키는 브라우저가 example.com 으로 요청을 보낼 때만 자동으로 전송돼요.
• 따라서 a.example.com 과 b.example.com 은 서브도메인이 달라서 기본적으로는 서로의 쿠키를 못 봅니다.

---

🔹 단, Domain 속성을 지정하면 공유 가능

쿠키를 설정할 때 이렇게 하면 ↓

 

Set-Cookie: name=value; Domain=.example.com; Path=/;

• a.example.com, b.example.com, example.com 모두에서 접근 가능해집니다.
• Domain 앞의 점(.)이 “이 도메인과 그 하위 도메인 전부”를 의미해요.

하지만 이렇게 설정한 쿠키는 보안상 취약할 수 있어서, 최근에는 SameSite 정책 등으로 제한이 많아요.

---

🔹 호스트가 다를 때 (예: example.com ↔ another.com)

• 완전히 다른 도메인이면 쿠키는 절대 자동으로 공유되지 않아요.
  즉, example.com 의 쿠키는 another.com 에서 접근할 수 없습니다.
• 만약 공유해야 한다면,
  • 백엔드 서버 간 토큰 전달,
  • OAuth 인증 방식,
  • postMessage + localStorage 브리지 같은 기법을 써야 해요.

---

🔹 요약

상황쿠키 전송 여부

동일 도메인 (example.com)	✅ 가능
서브도메인 (a.example.com ↔ b.example.com)	⚠️ Domain=.example.com 설정 시 가능
완전히 다른 도메인 (example.com ↔ another.com)	❌ 불가능

---

원하신다면 “다른 도메인 간 로그인 유지(SSO)”처럼 쿠키를 우회적으로 공유하는 구조도 예시 코드로 보여드릴 수 있어요. 보여드릴까요?

 

 

 

---

 

 

🧩 1. 도메인 vs 서브도메인 차이

구분설명예시

도메인	돈 주고 직접 등록하는 주소	example.com, mybrand.co.kr
서브도메인	이미 가진 도메인에 “접두어”를 붙여서 만드는 하위 주소	api.example.com, shop.mybrand.co.kr

즉, 서브도메인은 **기존 도메인 안에서 무료로 무한히 만들 수 있는 “하위 주소”**야.
새 도메인을 따로 사는 게 아니라, DNS 설정으로 추가하는 거야.

---

🛠️ 2. 서브도메인 만드는 법 (개념적으로)

1. 네가 이미 example.com을 가지고 있다고 치면,
2. DNS 관리 페이지(도메인 구입한 곳에서) 들어가서
   api.example.com 이라는 A레코드나 CNAME 레코드를 추가해.
3. 그걸 특정 서버 IP나 다른 도메인으로 연결하면 끝.

👉 예시:

 

Type: A Name: api Value: 123.45.67.89

이러면 api.example.com이 그 IP 서버로 연결돼.

---

💡 3. 정리하자면

• 서브도메인은 새 도메인 “구매”가 아님.
• 이미 있는 도메인(example.com)의 하위 주소를 DNS 레코드로 직접 만드는 것.
• api, shop, dev, test 같은 이름을 붙여 여러 개 만들어도 추가 요금 없음.

---

원하면 실제 예시로
👉 “내가 구입한 도메인이 myservice.kr인데, 백엔드는 api.myservice.kr, 프론트는 app.myservice.kr로 나누고 싶다”