UI state와 server state를 왜 구분해야 하나요?

Question

Accepted Answer

**UI state**는 앱이 로컬에서 소유하고 제어하는 데이터입니다(토글, 폼 입력, 선택된 탭). **Server state**는 서버에 존재하며 클라이언트에는 단지 *캐시*된 데이터입니다(가져온 사용자, 상품, 게시물). 둘은 근본적으로 다른 특성을 가지며 서로 다른 도구가 필요합니다.

## 핵심 차이

```text
                  UI state                    Server state
소유권            앱이 소유(클라이언트)        서버가 소유; 클라이언트는 캐시
신선도            항상 최신                    오래될(stale) 수 있음(서버가 바꿈)
동기화 필요?      아니오                       예 — refetch, invalidate, revalidate
공유됨?           보통 한 클라이언트           사용자/기기/탭 간 공유
관심사            그냥 set/read               캐싱, 로딩, 에러, 재시도, 중복 제거
```

## 서버 데이터를 UI state처럼 다루면 잘못되는 이유

```jsx
// ❌ 서버 데이터를 일반 local state로 다루기 — 모든 것을 직접 만들어야 함
function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

useEffect(() => {
    fetch("/api/users")
      .then(r => r.json()).then(setUsers)
      .catch(setError).finally(() => setLoading(false));
  }, []);
  // 그리고 이제: 캐싱? 포커스 시 refetch? 중복 제거? 재시도? 오래된 데이터? 전부 수동 😓
}
```

결국 로딩/에러 추적, 캐싱, refetch, 중복 제거, 신선도 처리를 모든 fetch마다 직접 다시 구현하게 됩니다.

## 올바른 도구: server-state 라이브러리

```jsx
// ✅ React Query / SWR / RTK Query가 캐싱, 로딩, 에러, refetch를 처리해 줌
function Users() {
  const { data: users, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: () => fetch("/api/users").then(r => r.json()),
  });
  // 자동: 캐싱, 백그라운드 refetch, 중복 제거, 재시도, stale-while-revalidate
}
```

이 라이브러리들은 server-state 문제를 위해 특별히 만들어졌습니다. 로컬 캐시를 원격 출처와 동기화하는 일입니다.

## 실무적인 구분

```text
UI state     → useState / Zustand / Context / Redux
Server state → React Query / SWR / RTK Query / Apollo(GraphQL용)
```

## 왜 중요한가

server state가 일반 local state가 아니라 **원격 데이터의 캐시**라는 것을 인식하는 것은 현대 프런트엔드 아키텍처의 중요한 통찰입니다.

이는 API 데이터를 Redux/useState에 쏟아붓는 것이 왜 산더미 같은 수동 캐싱/로딩 코드로 이어지는지, 그리고 왜 전용 server-state 라이브러리(React Query, SWR)가 존재하며 그토록 널리 채택되는지를 설명합니다.

둘을 분리하면 — UI state는 로컬 store에, server state는 캐싱 라이브러리에 — 데이터 중심 앱이 극적으로 단순해지고 방대한 보일러플레이트와 신선도 버그가 사라집니다.