# [[Server State]]

## 📌 Brief Summary
Server State(서버 상태)는 API를 통해 서버로부터 가져온 데이터 상태로, 클라이언트 측의 일반적인 애플리케이션 상태(Application State)와 근본적으로 다른 특성을 지닙니다 [1]. 이러한 상태는 비동기적으로 동작하며, 데이터의 최신화(신선도 유지), 동기화, 캐싱, 로딩 및 에러 주기에 대한 처리를 필수로 요구합니다 [1]. 최근의 프론트엔드 아키텍처에서는 이 서버 상태를 전역 클라이언트 상태와 명확히 분리하여, 특화된 전용 도구를 사용해 관리하는 것이 표준으로 자리 잡았습니다 [1, 2].

## 📖 Core Content
* **상태 분리 아키텍처:** 과거 단일 스토어(예: Redux)에서 모든 상태를 관리하던 패러다임에서 벗어나, 현대의 React 시스템에서는 '서버 상태(Server State)'와 '애플리케이션 상태(Application State)'를 구분하는 것이 가장 중요한 상태 관리의 변화로 꼽힙니다 [1, 3].
* **Server State의 주요 요구사항:** 데이터가 외부(API)에 존재하므로, 이를 로컬에서 효율적으로 다루기 위해서는 중복 네트워크 요청을 줄이는 캐싱, 서버와의 데이터 동기화, 로딩 중이나 에러 발생 시의 UI 처리 사이클 관리가 필수적입니다 [1, 4].
* **주요 관리 도구:** TanStack Query(React Query)와 RTK Query가 서버 상태 관리를 위한 사실상의 표준(de facto standard) 라이브러리로 활용됩니다 [1, 5]. 이러한 도구들은 무한 스크롤링, 낙관적 업데이트(optimistic updates)와 같은 복잡한 기능을 단순화하고, 강력한 캐싱 레이어를 통해 데이터의 신선도를 보장합니다 [4]. RTK Query의 경우 캐싱, 데이터 중복 제거, 자동 리패칭(refetching) 및 캐시 무효화를 기본적으로 제공합니다 [5].
* **코드 구성 및 경계 설정:** 서버 상태를 다루는 API 레이어는 프로젝트 내에서 뚜렷한 경계로 구성되어야 합니다. 일반적으로 요청 선언부와 커스텀 훅(Custom Hooks)은 특정 기능(feature) 폴더 내에 함께 배치(colocated)되어, 네트워크 로직이 UI 컴포넌트와 분리되도록 설계해야 유지보수성이 높아집니다 [4].

## ⚖️ Trade-offs & Caveats
* **보일러플레이트 vs 일관성:** Zustand나 Context API처럼 매우 유연한 상태 관리 도구를 사용해 서버 상태 처리를 직접 구현할 경우, 캐싱이나 중복 제거 등의 기능을 직접 만들어야 하므로 수 주일의 작업이 낭비될 수 있으며, 팀원 간 비동기 로직 처리 방식이 파편화되는 부작용이 발생할 수 있습니다 [5-8]. 반면, RTK Query와 같은 도구를 사용하면 팀 내 일관성이 강제되지만, 초기 환경 설정에 대한 보일러플레이트 폭발 및 학습 곡선이라는 비용을 감수해야 합니다 [5, 9, 10].
* **복잡성 관리:** 전용 서버 상태 관리 라이브러리는 비동기 코드의 많은 부분을 자동화하지만 복잡성 자체를 완전히 제거하는 것은 아니므로, 정규화된 데이터 등 앱의 규모와 복잡성에 알맞은 도구를 신중하게 선택해야 합니다 [10].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처/기반 기술]
- [[Application State]]
  - 연결 이유: Server State와 대비되는 클라이언트 측 전역/지역 상태를 의미하며, 이 두 가지를 분리하는 것이 최신 프론트엔드 상태 관리의 핵심입니다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터를 그 성격(클라이언트 독자 데이터 vs 외부 시스템 종속 데이터)에 따라 왜 분리해서 다루어야 하는지 아키텍처적 근거를 이해할 수 있습니다.

#### [관계 유형 B: 구현/활용 도구]
- [[TanStack Query]]
  - 연결 이유: Server State 관리에 특화된 사실상의 표준(de facto standard) 라이브러리입니다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버 상태 캐싱, 동기화, 로딩/에러 사이클 처리, 낙관적 업데이트 등이 실제 코드에서 어떻게 최적화되어 구현되는지 이해할 수 있습니다 [4].
- [[RTK Query]]
  - 연결 이유: Redux 생태계에서 비동기 서버 상태의 캐싱, 중복 제거, 캐시 무효화 등을 즉시 제공하여 보일러플레이트를 대폭 줄여주는 도구입니다 [5].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: API 통신이 매우 많고 복잡한 앱 환경에서 비동기 로직의 일관성을 어떻게 확보하는지 배울 수 있습니다 [5, 9].
- [[Zustand]]
  - 연결 이유: Server State 전용 라이브러리를 도입한 후, 남은 클라이언트 전역 상태(Application State) 관리를 위해 함께 결합하여 사용하는 것이 권장되는 경량 라이브러리입니다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버 상태와 클라이언트 상태를 각각 적합한 도구로 어떻게 조화롭게 운영할지 파악할 수 있습니다.

### Deeper Research Questions
- Server State와 Application State를 한 곳에서 관리할 때 생기는 성능 저하 및 유지보수성 하락의 구체적인 메커니즘은 무엇인가?
- TanStack Query나 RTK Query는 내부적으로 캐시된 Server State 데이터의 신선도(freshness)를 어떻게 평가하고 만료(invalidate)시키는가?
- Server State 도구를 사용해 무한 스크롤(Infinite Scrolling)과 낙관적 업데이트(Optimistic Updates)를 구현할 때의 데이터 흐름과 오류 복구(Rollback) 전략은 어떻게 구성되는가?
- 비동기 데이터 통신 시 빈번하게 발생하는 로딩 및 에러 상태를 React의 Error Boundaries 및 Suspense와 결합하여 어떻게 우아하게(Graceful) 처리할 수 있는가?
- 유연한 상태 관리 라이브러리(Zustand 등)를 이용해 Server State 캐싱 메커니즘을 직접 구현하려 할 때 겪는 메모리 누수 및 재렌더링 최적화의 한계는 무엇인가?

### Practical Application Contexts
- **Implementation:** React 컴포넌트 내에서 수동으로 `useEffect`와 `useState`를 조합해 데이터를 패칭하던 방식을 폐기하고, TanStack Query를 도입해 비동기 상태의 캐싱 및 라이프사이클 관리를 자동화합니다 [1, 2, 11, 12].
- **System Design:** Feature-Sliced Design(FSD)과 같은 디렉토리 아키텍처에서, 도메인(Feature) 폴더 내부에 `api/` 또는 `hooks/` 폴더를 구성하여 해당 도메인에 속하는 Server State 요청 로직을 캡슐화합니다 [4, 13].
- **Operation / Maintenance:** 브라우저 DevTools와 전용 도구(예: Redux DevTools)를 통해 어느 시점에 액션이 발생하고 네트워크 요청이 중복 제거되었는지 쉽게 추적 및 디버깅할 수 있습니다 [9, 14].
- **Learning Path:** 클라이언트 전역 상태 관리(Context, Zustand)의 한계와 과도한 렌더링 문제를 학습한 뒤, API 호출 데이터를 관리하기 위한 Server State 패러다임 분리 필요성을 익히고, 최종적으로 TanStack Query 등의 최적화 도구를 학습합니다 [1, 3].
- **My Project Relevance:** React 코드베이스 리팩토링 작업을 수행할 때, 기존 Redux 보일러플레이트 중 비동기 API 호출 부분을 TanStack Query로 전환(Server State)하고, 남은 클라이언트 전역 상태만 Zustand로 분리하여 코드의 복잡성을 낮추는 구조 개선에 직접 활용 가능합니다 [2].

### Adjacent Topics
- [[React Error Boundaries]]
  - 확장 방향: Server State에서 API 요청 실패 등 런타임 에러가 발생했을 때, 애플리케이션 전체가 충돌하여 빈 화면이 나오지 않도록 폴백(Fallback) UI를 표시하고 복구하는 에러 처리 방법론으로 확장 [15, 16].
- [[Feature-Sliced Design]]
  - 확장 방향: 캡슐화된 Server State 훅과 API 레이어를 포함하여 프론트엔드 프로젝트의 전체 폴더 구조를 어떻게 도메인/기능 중심으로 확장성 있게 설계할 것인지에 대한 아키텍처 논의로 확장 [4, 17].

---
*Last updated: 2026-04-30*