🧩 1️⃣ 먼저 전제부터: SSR 환경에는 window가 없습니다.
- window는 브라우저에서만 존재하는 객체예요.
(예: window.localStorage, window.document, window.alert 등) - 그런데 Next.js는 SSR을 지원하니까,
코드가 서버(Node.js) 위에서도 실행될 수 있습니다.
서버에는 브라우저가 없으니
window.localStorage 같은 건 존재하지 않아요.
즉, 이런 코드를 서버에서 실행하면:
localStorage.setItem('access_token', newToken);
➡️ “localStorage가 정의되어 있지 않음(undefined)” 에러가 발생합니다 ❌
🧩 2️⃣ 그래서 조건문으로 분리해 둔 거예요
if (typeof window !== 'undefined') { // ✅ 브라우저 환경 → localStorage 사용 가능
} else { // 🌐 서버 환경 → localStorage 사용 불가능 }
이 구조 덕분에,
서버에서는 localStorage 관련 코드를 건너뛰고,
대신 “최소한의 상태만 업데이트”하도록 만들어둔 거예요.
🧩 3️⃣ “단순히 상태만 바꿔준다”의 의미
이 부분이 핵심이에요 👇
set({ token: newToken, tokenExpiry: null, isAuthenticated: !!newToken });
이건 Zustand(전역 상태관리 라이브러리) 의 set() 함수예요.
즉, 브라우저 저장소(localStorage)에는 접근하지 않고,
메모리 안에서만 상태를 바꿔줍니다.
- token: 토큰 값을 넣거나(null로 초기화)
- tokenExpiry: SSR에서는 관리 안 하니까 null
- isAuthenticated: !!newToken → 토큰 있으면 true, 없으면 false
👉 즉, “현재 실행 중인 메모리 안에서만 로그인 상태로 인식하도록”
하는 일종의 임시 처리인 거예요.
🧭 4️⃣ 왜 이렇게 해도 프로그램이 안 멈추냐?
- localStorage에 접근하지 않으니까
❌ “ReferenceError: localStorage is not defined” 같은 에러를 방지함. - SSR에서는 “브라우저에 실제로 저장할 필요가 없어요.”
서버는 단지 “HTML을 렌더링해서 보내주는 역할”만 하니까요.
토큰은 이후 브라우저에서 실제 로그인 시 다시 저장됩니다. - 이렇게 “상태만 유지”해두면
클라이언트로 넘어간 뒤 하이드레이션(hydration) 과정에서
React가 자연스럽게 이어받아 렌더링을 계속할 수 있습니다.
🧠 쉽게 요약하자면
SSR(서버)에서는 localStorage를 쓸 수 없기 때문에
“에러 없이 HTML을 만들기 위해 임시로 상태만 바꿔둔다.”CSR(브라우저)로 넘어오면 그때 localStorage에 실제로 기록한다.
예를 들어서 이렇게 생각해보면 쉬워요 👇
단계실행 위치할 일
| SSR | 서버(Node.js) | 토큰 저장 불가 → 상태만 변경 (임시 로그인 표시) |
| CSR | 브라우저 | localStorage에 진짜로 저장 |
'Sprint_FESI11 > Project' 카테고리의 다른 글
| 웹이 SSR(서버가 코드를 해석해서 HTML을 만들어주는 구조) 를 유지하는 존재 이유 (0) | 2025.10.16 |
|---|---|
| JSP vs ASP vs SSR (0) | 2025.10.16 |
| 토큰 기반 렌더링 흐름 (0) | 2025.10.16 |
| 서버는 렌더링만 하는데, 왜 토큰을 가지고 있지? (0) | 2025.10.16 |
| 로그인 토큰을 저장하고 관리하는 함수 (0) | 2025.10.16 |