🏫 Ddingsroom의 세션 유지 구조 분석 ( + Local Storage, Session Storage, Cookie에 대해)

웹 개발을 하다 보면 “로그인 상태를 어떻게 유지할까?” 라는 문제를 반드시 마주하게 됩니다. 이때 사용하는 것이 바로 브라우저 저장소 (Web Storage)입니다.

이번 글에서는
1️⃣ Local Storage, Session Storage, Cookie 의 차이점
2️⃣ 그리고 실제로 제가 운영 중인 Ddingsroom 프로젝트에서 어떻게 세션을 관리하고 있는지
를 함께 살펴보겠습니다.

---

📦 Local Storage

Local Storage는 브라우저에 반영구적으로 데이터를 저장하는 저장소입니다.

• 유효 기간: 무기한 (사용자가 직접 삭제하지 않는 이상 남음)
• 용량: 약 5MB (브라우저별로 다름)
• 특징: 서버로 전송되지 않음, 클라이언트에서만 접근 가능

예시

localStorage.setItem("theme", "dark");
localStorage.getItem("theme"); // "dark"
localStorage.removeItem("theme");

주요 사용 예시

• 다크 모드 / 라이트 모드 설정
• 최근 본 상품, 선호 카테고리 저장

---

🔐 Session Storage

Session Storage는 탭 단위로 유지되는 임시 저장소입니다.
브라우저 탭을 닫으면 데이터가 삭제됩니다.

• 유효 기간: 브라우저 탭을 닫을 때까지
• 서버 전송: 자동 전송 안 됨
• 용량: 약 5MB

예시

sessionStorage.setItem("accessToken", "abc123");
sessionStorage.getItem("accessToken"); // "abc123"
sessionStorage.clear();

주요 사용 예시

• 로그인 세션 유지 (JWT 토큰 저장)
• 임시 입력 폼 데이터

---

🍪 Cookie

Cookie는 서버와 클라이언트가 자동으로 주고받을 수 있는 데이터 조각입니다.

• 유효 기간: 설정 가능 (max-age / expires)
• 용량: 약 4KB
• 서버 전송: 자동 전송
• 보안 옵션: Secure, HttpOnly, SameSite 등으로 강화 가능

예시

document.cookie = "user=Yujin; max-age=3600; path=/";

주요 사용 예시

• 자동 로그인, 세션 식별자 (session_id)
• 웹 분석, 광고 트래킹

---

세 저장소 비교

Cookie & LocalStorage 관계 시각화

---

🏫 Ddingsroom 프로젝트의 세션 유지 구조

간단하게 Local Storage, Session Storage, Cookie에 대해 알아봤으니 이제 실제 제가 운영중인 Ddingsroom 프로젝트에서 어떻게 세션을 유지하는지 살펴보도록 하겠습니다.
Ddingsroom은 JWT 기반 클라이언트 세션 관리를 사용하고 있습니다. 즉, 서버 세션이 아닌 토큰 기반 인증 방식입니다.

---

로그인 이후의 흐름

1️⃣ 로그인 성공 시 서버에서 accessToken, refreshToken, userId를 반환합니다.
2️⃣ 클라이언트에서 이를 sessionStorage에 저장합니다.
3️⃣ Axios 인스턴스가 모든 API 요청에 Authorization 헤더를 자동 추가합니다.

---

📁 관련 파일 구조

libs/
 └── api/
      ├── instance.js     ← axios 인스턴스 + 인터셉터
      ├── getUserId.js    ← 토큰 기반 유저 식별
      └── admin.js        ← 관리자용 API
stores/
 ├── useTokenStore.js     ← Zustand 전역 상태로 토큰 관리
 ├── useReservationStore.js
 └── useCommunityStore.js

---

1. axios 인스턴스 설정 (libs/api/instance.js)

import axios from 'axios';

const axiosInstance = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_BASE_URL,
  timeout: 10000,
});

axiosInstance.interceptors.request.use((config) => {
  const accessToken = sessionStorage.getItem('accessToken');
  if (accessToken) {
    config.headers.Authorization = `Bearer ${accessToken}`;
  }
  return config;
});

-> 인증이 필요한 모든 요청에 자동으로 토큰이 붙습니다.

---

2. 응답 인터셉터에서 만료 토큰 처리

axiosInstance.interceptors.response.use(
  (response) => response,
  (error) => {
    const { response } = error;
    if (response && (response.status === 401 || response.status === 403)) {
      sessionStorage.removeItem('accessToken');
    }
    return Promise.reject(error);
  }
);

-> 토큰이 만료되면 자동으로 세션이 종료되어 재로그인을 유도합니다.

---

3. Zustand를 통한 전역 세션 관리 (useTokenStore.js)

import { create } from 'zustand';

const useTokenStore = create((set) => ({
  accessToken: sessionStorage.getItem('accessToken') || '',
  refreshToken: sessionStorage.getItem('refreshToken') || '',
  userId: parseInt(sessionStorage.getItem('userId')) || null,

  setAccessToken: (token) => {
    set({ accessToken: token });
    sessionStorage.setItem('accessToken', token);
  },
  clearTokens: () => {
    set({ accessToken: '', refreshToken: '', userId: null });
    sessionStorage.clear();
  },
}));

-> Zustand와 sessionStorage를 양방향 동기화하여, 새로고침해도 세션이 유지됩니다.

---

왜 Session Storage를 선택했을까?

• 보안성: 토큰이 HTTP 요청마다 자동 전송되지 않아 XSS에만 주의하면 안전하다 판단했습니다.
• 유지 기간: 브라우저 탭 단위로 로그인 시간이 유지되기에 공용 PC 등에서 자동 로그아웃이 가능합니다.
• UX 향상: 새로고침 시에도 Zustand의 rehydrate()로 세션 유지가 가능합니다.
• 간결함: 복잡한 서버 세션 관리 대신 클라이언트 단에서 간단하게 구현이 가능합니다.

---

세션 구조 다이어그램

[서버] 
  ↓ (로그인 응답)
  accessToken, refreshToken, userId
  ↓
[클라이언트]
 ┌──────────────────────────┐
 │ sessionStorage            │
 │  ├ accessToken            │
 │  ├ refreshToken           │
 │  └ userId                 │
 └──────────────────────────┘
         │
         ▼
 [useTokenStore.js] ← Zustand 전역 상태
         │
         ▼
 [axiosInstance] → Authorization 헤더 자동 부착

---

결론 — 실서비스에서 드러난 문제와 개선 방향

Ddingsroom은 JWT + Session Storage 기반 세션 유지 구조를 사용합니다.

• 서버 세션 대신 클라이언트 중심의 토큰 인증
• Axios 인터셉터로 인증 헤더 자동 부착
• Zustand로 전역 상태 동기화
  = 탭 단위의 보안 중심 UX

그러나 최근 실제 서비스 운영 중 다음과 같은 사용자 피드백이 접수되었습니다.

---

🗣️ 사용자 피드백 사례

“자꾸 예약 내역이 사라집니다.
전날 예약했는데 다음날 들어와 보니 예약이 안 되어 있어서 너무 곤란했습니다.
오늘도 또 그러네요. 왜 그런 건가요?”

_실제 서비스에 접수된 건의 내역 화면 캡쳐본_

이 피드백은 “예약이 정상적으로 완료되지 않은 것처럼 보인다”는 내용이었지만,
서버 로그를 분석해보니 예약 API 자체가 백엔드로 전송되지 않았거나, 인증 실패(401) 로 처리된 경우였습니다.

---

Access Token이 만료된 상태에서 사용자가 예약 버튼을 누르면 요청이 서버로 전달되지 않거나 401 Unauthorized로 거절되지만, UI에는 별다른 오류 안내가 표시되지 않아 사용자는 예약이 된 줄 착각하게 됩니다.
결국 예약 데이터가 DB에 저장되지 않은 채 사라지는 현상이 발생한 것입니다.

---

이를 해결하기 위해 현재

• Access Token 사전 갱신 (Preemptive Refresh)
• 401 응답 시 자동 재발급 및 재시도 로직
• HttpOnly 쿠키 기반 Refresh Token 보관
• 멀티탭 동기화 구조 개선
  등의 개선을 진행 중에 있습니다.

이 개선이 적용되면, 사용자는 토큰 만료를 인식하지 않고도 서비스 내에서 로그인 상태가 끊김 없이 유지될 것 입니다.

💡 다음 포스트에서는 이 Refresh Token 로직을 실제 코드 레벨에서 어떻게 구현했는지, Axios 인터셉터와 Network Interceptor 기반으로 자세히 다뤄보겠습니다.