🚀 19. 상태 관리의 권력 분립: 서버(Server) 상태 vs 클라이언트(Client) 상태

🎯 이 섹션을 읽고 나면:

• 과거 Redux-Thunk나 Saga로 게시글 목록을 불러오고 캐싱하던(보일러플레이트 지옥) 시대가 왜 종말을 맞이했는지 이해한다.
• 상태(State)의 '성질'을 파악하여, 내 데이터를 어디(Zustand vs TanStack Query)에 보관해야 할지 1초 만에 판별할 수 있다.
• 백엔드 DB의 캐시 복사본(서버 상태)을 프론트에 예쁘게 동기화하는 캐싱(Caching) 전략의 기초를 다진다.

📋 목차

• 🤔 왜 알아야 하는가: '전역 스토어 만능주의'의 폐해
• 🏗️ 비유로 먼저 이해하기
• 🧩 극의 체득: 두 왕좌의 분리 (Zustand & TanStack Query)
  • ✅ 1. 오직 "내(Client)" 데이터만 관리하는 초경량 스토어 (Zustand)
  • ✅ 2. 골치 아픈 "남(Server)"의 데이터 캐싱 매니저 (TanStack Query)

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 5분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영수(PM): "영철 님, 우리 앱은 게시글 목록 캐싱도 해야 하고, 다크모드 설정도 전역으로 기억해야 하고, 유저가 어떤 모달창을 띄워놨는지도 다 기억해야 하는데 어떻게 합쳐 놓으셨나요?"
• 영철(신입): "걱정 마세요! 만능 보따리 Redux Store 라는 거대한 스토어 하나 판 다음에 거기에다가 { isDarkMode, isModalOpen, postsList, isLoading, errorMsg } 싹 다 때려 박아 놨습니다! 액션(Action) 수십 개랑 리듀서(Reducer) 지옥만 거치면 꺼내 쓸 수 있어요 ㅎㅎ"
• 영호(리드): "영철 님, 그래서 당신의 스토어 코드가 5,000줄이 넘는 겁니다. 저 데이터들은 태생부터가 다른 남남입니다. 클라이언트(UI) 상태와 서버(API) 상태를 한 바구니에 담으면 부패합니다. 오늘 당장 권력 분립을 시작합시다."

🤔 왜 알아야 하는가: '전역 스토어 만능주의'의 폐해

2010년대 후반 프론트엔드는 "모든 중요한 데이터는 전역(Global - Redux)으로 빼자!"라는 사상에 미쳐있었습니다. 그래서 다음과 같은 기괴한 형태의 스토어가 탄생했습니다.

// ❌ 3년 전 흔했던 영철이의 "잡탕밥 전역 상태"
const globalRootStore = {
  // 🟢 클라이언트(UI) 고유 상태 - 새로고침하면 날아가거나 내 기기 기억에만 의존
  theme: 'dark',
  isSidebarOpen: false,
  cartFloatingXPosition: 150,
 
  // 🔴 서버(Server) 상태의 프록시 복사본 - 남(DB)의 데이터를 훔쳐온 것
  users: [{ id: 1, name: "영호" }, { id: 2, name: "영숙" }],
  isUsersLoading: false,
  usersError: null,
};

이 코드는 왜 끔찍할까요?

• **캐싱(Caching)**의 한계: 영숙이가 본명 닉네임을 "영숙_프로"로 바꿨다고 칩시다. 내 users 배열 객체(프론트 전역 스토어)는 10시간 전 서버에서 훔쳐온 "낡고 썩은 과거의 데이터(Stale Data)"입니다. 이걸 언제 무효화하고 다시 Fetch 할지, Redux의 순수 함수 덩어리 안에서 직접 로직 구현을 하려면 피를 토합니다.
• 수동 상태 관리(Boilerplate):isUsersLoading, usersError 같은 쓰레기 플래그 값들을 액션마다 수동으로 껐다 켰다(dispatch FETCH_START, FETCH_SUCCESS)해야 합니다. 액션 타입명 짓다가 날을 샙니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

1. 클라이언트 상태(UI State): 내 서랍에 있는 일기장이나 거울 각도입니다. **나(Front-end 브라우저)**만의 소유권과 통제권을 쥐고 있습니다. 내가 각도를 틀면 틀어지고, 다크모드 스위치를 끄면 꺼집니다. 내 마음대로 빠릿빠릿하게 다룰 수 있습니다.
2. 서버 상태(Server State): 도서관에서 어제 빌려온 백과사전입니다. 원본 소유권은 나(프론트)에게 없고 **도서관(Backend DB)**이 쥐고 있습니다.
   내가 그 책을 집에 들고 와서 읽는 동안, 도서관장이 책의 원래 내용(오타)을 수정했다면? 내 책은 즉시 거짓(Stale) 정보가 되어버립니다. 이걸 계속 눈치채고 새 버전으로 갈아치워 줘야 하는 엄청나게 피곤한 관리 대상입니다.

이처럼 "나 혼자만의 찰나의 기억(UI)"과 "남의 건물에서 훔쳐온 낡은 기억(Server API)"을 똑같은 서랍 바구니(Zustand, Redux)에 넣어 고인물로 썩게 놔둘 순 없습니다. 방식을 완전히 분리해야만 합니다.

🧩 극의 체득: 두 왕좌의 분리 (Zustand & TanStack Query)

최신 실무 팀(스타트업~토스, 당근, 배민 등)의 대부분은 전역 상태를 위해 딱 두 가지의 무기만을 꺼내 듭니다. 영철이의 거대한 잡탕 스토어가 2개로 찢어지는 기적을 봅시다.

✅ 1. 오직 "내(Client)" 데이터만 관리하는 초경량 스토어 (Zustand)

다크모드 끄고 켜기, 현재 켜져 있는 모달 ID 저장, 드래그 앤 드롭한 블록의 X,Y 좌표. 이들은 서버로 날아갈 일도 없고 캐시 될 필요도 없는 영원한 UI 휘발성/클라이언트 상태입니다.
단 몇 줄의 코드로 전역 변수를 조종할 수 있는 Zustand가 최고 존엄으로 등극했습니다.

// 🎯 오직 브라우저 UI 조작만을 담는 깔끔한 Zustand 
import { create } from 'zustand';
 
export const useUIStore = create((set) => ({
  theme: 'dark',
  toggleTheme: () => set((state) => ({ theme: state.theme === 'dark' ? 'light' : 'dark' })),
  
  activeHoverId: null,
  setHoverId: (id) => set({ activeHoverId: id }),
}));

(이 공간엔 절대 네트워크 fetch 결과물을 넣지 않습니다!)

✅ 2. 골치 아픈 "남(Server)"의 데이터 캐싱 매니저 (TanStack Query)

"서버야 돈 좀 줘"라고 요청하는 순간 벌어지는 로딩 처리, 실패 시 3번 자동 재요청(Retry), 유저가 창을 내렸다가 3분 뒤 켰을 때 (Focus) 뒤에서 몰래 새 데이터 갱신하기(Stale-While-Revalidate)...

이 끔찍한 잡무들을 알아서 백그라운드에서 캐싱 제국을 건설하여 다이렉트로 관리해 주는 것이 **React Query(TanStack Query)**입니다. 16강의 Suspense와도 영혼의 단짝입니다.

// 🎯 서버 상태: 프론트는 그저 Query Key로 구독(Subscribe)만 하고 꿀을 빤다.
import { useQuery } from '@tanstack/react-query';
 
function UserProfile({ userId }) {
  // Redux의 Dispatch, useSelector 그딴 건 잊으세요.
  // 이 훅 하나가 "캐싱, 로딩, 에러, 재갱신, 메모리 폐기"를 싹 혼자 관리해버림.
  const { data: user, isLoading, error } = useQuery({
    queryKey: ['user', userId], // 마치 캐시 창고의 바코드(이름표) 같은 것!
    queryFn: () => fetch(`/api/users/${userId}`).then(res => res.json()),
    staleTime: 1000 * 60 * 5, // "5분 동안은 도서관에 또 안 물어보고, 내 캐시 복사본 쓸게!"
  });
 
  if (isLoading) return <Spinner />;
  if (error) return <div>에러남!</div>;
 
  return <div>{user.name} 님 환영!</div>;
}

이렇게 하면 브라우저는 "서버 데이터를 보관하기 위한 상태 관리 도구"라는 망령에서 완전히 해방됩니다. 우리가 프론트엔드에서 바라보는 서버 데이터는, 상태(State)로 다루는 것이 아니라 그냥 Query에게"캐시 데이터 최신버전 복사본 좀 대신 꺼내서 잠시 보여줘"하고 빌려 쓰는 렌더링 스냅샷에 불과하게 되는 것입니다.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
"내 데이터는 Zustand에 숨기고, 남(서버)의 데이터는 Query에게 외주(Outsourcing) 줘버려라."
이 거대한 두 축만 명확히 갈라내도, 당신의 프론트엔드 설계 아키텍처는 토스나 카카오급 시니어의 시야를 갖춘 것과 다름없다.

🐣 영철이의 퇴근 일기

Redux 하나에 모든 세상의 짐을 다 짊어지게 하던 내 코드가 얼마나 미련했는지 깨달았다. 클라이언트 데이터랑 서버 데이터가 애초에 유효기간부터 다른 남남이었다니.

💡 "명심하자. 내 앱의 순수 UI 상태(Zustand)와 서버에서 빌려온 장부 복사본(TanStack Query)은 완전히 분리해서 관리해야 한다."

이 '권력 분립' 패턴대로면 보일러플레이트 코드 수백 줄이 그냥 날아간다. 당장 내일 출근해서 그 무겁고 느린 Redux 걷어내고 Zustand랑 React Query 도입하자고 기안서부터 올려야겠다. 토스나 당근에서 왜 이 조합을 쓰는지 알 것 같아 속이 뻥 뚫린다.

📝 마무리 퀴즈

Q1. 당신이 쇼핑몰 장바구니 페이지를 설계해야 합니다. 각 장바구니 아이템의 수량을 '증가(+)/감소(-)'시키는 버튼을 눌렀을 때 벌어지는 일을 설계할 것입니다. "UI 상태"와 "서버 상태"의 분리 원칙에 비추어 볼 때, 가장 올바른 멘탈 모델이나 행동 방식은 무엇인가요?

• A) [+] 버튼을 누른 즉시 Zustand 상태 변수로 cartItems[0].quantity + 1을 때려 박아 전역 상태를 오염시키고, 굳이 DB 서버로 재전송하지 않은 채 유저가 결제 창으로 넘어갈 때만 API를 호출한다.
• B) [+] 버튼을 누르면 이건 명백히 백엔드 장바구니 DB 테이블(Server State)을 수정해야 하는 지시이므로, TanStack Query의 Mutation 기능 등을 활용해 서버로 명령을 날린다. 성공 응답이 떨어지면, 얽혀있는 해당 '장바구니 쿼리 무효화(Invalidation)'를 때려서 서버의 최신 데이터를 다시 스물스물 받아와 화면에 새 숫자를 렌더링한다.
• C) 이 상태는 클라이언트의 통제를 따르므로 LocalStorage에 저장하여 캐시 매니저 대신 브라우저 엔진에 온전히 위임해야 한다.

✅ 정답: B

💡 상세 해설: 훌륭한 권력 분립 설계입니다. 장바구니 수량은 결국 유저의 지갑(결제)과 연결될 "남의 통제(서버 장부)" 데이터이므로, 내가 로컬 상태(UI)로 함부로 즉시 수정하여 떵떵거리면 안 됩니다. 무조건 서버에게 "하나 더 늘려주세요"라고 허락(mutate)을 구하고, 원본 장부(DB)가 수정된 후 그 최신 데이터(Query)를 새로고침(Invalidate)시켜 화면에 반영하는 흐름이 안전한 동기화의 기본입니다. (물론 Optimistic Update라는 기법도 있지만, 이념적 본질은 일맥상통합니다.)

Q2. 신입인 영철이가 Context API의 내장 기능만으로 쇼핑몰 전체의 상품 목록(10만 개 데이터)을 로딩/캐싱/기억하는 시스템을 개발해 왔습니다. 영호 시니어가 이를 보고 호통치며 TanStack Query로 바꾸라고 한 치명적인 단점들을 모두 나열하고, Query도구들이 이런 문제 덩어리를 어떻게 해결해주는지 직접 주관식으로 설명해보세요.

✅ 정답 및 주관식 해설:
"영철이 방식의 치명적인 단점은, Context API에 내려받은 10만 개 데이터 배열은 시간이 지나면 '신선도'를 잃어버리는 일회성 바구니에 불과하다는 점입니다. 다른 유저가 재고를 다 사가서 0개가 되었는데, 영철이의 캐시(Context state)는 100개가 남았다고 **거짓말(Stale)**을 칠 것입니다.
이걸 해결하려면 영철이가 직접 setTimeOut이나 스크롤 백그라운드 이벤트 로직 등을 모조리 수백 줄 손으로 짜야 하죠. TanStack Query는 단지 staleTime: 5000 한 줄 옵션만 넘겨주면, 포커스가 돌아왔을 때나, 5초가 지났을 때 자기 혼자서 알아서 뒤에서 몰래 통신하고(Background Fetching) 썩은 부분을 최신화된 서버 데이터로 완벽하게 버무려 캐싱(Caching)까지 대행해주는 선언적 갱신(Revalidate)의 악마이기 때문입니다."