🧩 1️⃣ SSR의 본질부터 다시 보기
SSR(Server-Side Rendering)은
“서버가 HTML을 미리 만들어서 브라우저에게 보내주는 과정”이에요.
즉,
- 서버는 React 컴포넌트를 실행해서
- 거기서 나오는 HTML 문자열만 만들어서 반환합니다.
(이 시점엔 사용자의 화면에 아무것도 보이지 않아요.)
그런데 서버가 HTML을 만들려면,
“이 사용자가 로그인한 상태인지 아닌지” 알아야
로그인 버튼/로그아웃 버튼, 프로필 영역 등을 다르게 렌더링할 수 있죠.
➡️ 그래서 서버가 잠깐 ‘토큰’을 인식할 필요가 생깁니다.
🧩 2️⃣ 서버가 “토큰을 저장”하는 게 아니라, “참조만” 합니다
여기서 중요한 구분은 👇
✅ “서버가 토큰을 가지고 있는 것”이 아니라
❌ “서버가 토큰을 잠깐 읽어서 렌더링만 하는 것”이에요.
즉, 서버는
- localStorage 같은 브라우저 저장소에는 접근하지 않아요.
- 대신 요청 헤더나 쿠키 안의 토큰을 읽어서
“이 유저는 로그인 중이네?” 정도만 판단합니다.
그 후에는 👇
- 그 정보를 바탕으로 HTML을 만들어서 브라우저로 보냄
- 브라우저가 그걸 받은 뒤,
자기 localStorage나 쿠키에 토큰을 저장하고 실제 로그인 상태로 이어감
🧩 3️⃣ 그래서 setToken()의 SSR 분기 코드는 “안전장치”예요
else { // SSR 안전 처리 set({ token: newToken, tokenExpiry: null, isAuthenticated: !!newToken }); }
이건 이런 뜻이에요 👇
“서버에서도 토큰이 전달되긴 했지만,
localStorage가 없으니까 단순히 ‘이 사용자는 로그인 상태야’ 정도만 표시해줘.
브라우저에서 렌더링이 이어질 때(localStorage가 생길 때)
진짜 저장은 그때 해줄게.”
즉, SSR 렌더링 단계에서 화면이 깨지지 않게 임시로 상태를 맞춰주는 처리예요.
(브라우저에서는 이 상태가 곧 “진짜 로그인 상태”로 이어집니다.)
🧠 핵심 요약
| 항목 | 설명 |
| 서버는 토큰을 “저장”하지 않음 | 브라우저에 localStorage가 없기 때문 |
| 서버는 토큰을 “읽을 수 있음” | 요청 헤더나 쿠키에서 확인 가능 |
| setToken SSR 분기 | 에러 없이 로그인 UI만 임시 표시 |
| 실제 저장 | 브라우저로 전환(CSR) 후 localStorage에서 수행 |
즉, 한 줄로 요약하면 👇
서버는 토큰을 “가지고 있는 것”이 아니라,
“토큰을 참고해서 HTML을 만들어줄 뿐”이에요.
이후 실제 토큰 관리(저장/삭제)는 브라우저(localStorage) 가 담당합니다.
'Sprint_FESI11 > Project' 카테고리의 다른 글
| 웹이 SSR(서버가 코드를 해석해서 HTML을 만들어주는 구조) 를 유지하는 존재 이유 (0) | 2025.10.16 |
|---|---|
| JSP vs ASP vs SSR (0) | 2025.10.16 |
| 토큰 기반 렌더링 흐름 (0) | 2025.10.16 |
| SSR 환경에서 단순히 상태만 바꿔준다는 것의 의미 (0) | 2025.10.16 |
| 로그인 토큰을 저장하고 관리하는 함수 (0) | 2025.10.16 |