# [[React State Management]]

## 📌 Brief Summary
React 상태 관리(State Management)는 애플리케이션의 데이터 흐름과 UI 업데이트를 제어하는 핵심 메커니즘이다. 과거의 단일 스토어 방식에서 벗어나, 최근에는 상태의 성격(로컬, 전역, 서버 캐시 등)에 따라 가장 적합한 도구를 결합하여 사용하는 파편화(Fragmentation) 접근법이 표준으로 자리 잡았다 [1, 2]. 개발자는 앱의 규모, 팀의 크기, 상태 변경의 빈도에 맞춰 Context API, Zustand, Redux, TanStack Query 등을 전략적으로 선택하여 확장성을 높이고 성능 저하를 방지해야 한다 [1, 3].

## 📖 Core 소스 Content
*   **상태의 분류와 파편화 (Fragmentation of State)**
    *   현재 프론트엔드 아키텍처에서는 상태를 로컬 컴포넌트 상태, 전역 애플리케이션 상태, 서버 캐시 상태, URL 상태로 명확히 구분한다 [1].
    *   **로컬 상태:** React 내장 훅인 `useState`와 `useReducer`를 주로 사용하지만, 지나치게 복잡한 상태를 `useState`로만 관리하려는 잘못된 패턴은 피해야 한다 [1, 4].
    *   **서버 상태:** API 계층에서 가져온 데이터는 클라이언트 상태와 근본적으로 다르므로 캐싱, 동기화, 로딩 및 에러 처리가 필요하다 [2]. 이를 위해 TanStack Query(React Query)와 같은 라이브러리가 업계 표준으로 사용되며, 중복 네트워크 요청을 줄이고 무한 스크롤 등을 단순화한다 [2, 5]. RTK Query 또한 캐싱, 중복 제거, 자동 리패칭 등을 제공해 비동기 작업의 복잡성을 크게 줄여준다 [6].

*   **Context API의 한계와 적합성**
    *   **적합한 사례:** 종속성 추가 없이(Zero dependencies) 테마 변경(다크/라이트 모드), 다국어 설정, 피처 플래그 등 변경이 드물고 정적인 전역 상태를 관리하는 데 적합하다 [7, 8].
    *   **한계:** 특정 값이 변경될 때마다 Context를 구독하는 모든 컴포넌트가 불필요하게 리렌더링되는 성능 문제(Re-render storm)를 유발한다 [9, 10]. 또한, Redux와 달리 상태 변경 기록을 추적하는 Time-Travel 디버깅 도구를 지원하지 않는다 [11]. 

*   **Zustand를 활용한 최적화**
    *   **작동 방식:** Context API의 리렌더링 문제를 해결하기 위해 도입된 경량 상태 관리 라이브러리다. 스토어가 React의 컴포넌트 트리 외부에 위치하며, '선택자(Selector pattern)'를 사용해 컴포넌트가 의존하는 특정 상태(Slice)가 변경될 때만 리렌더링을 트리거한다 [2, 12, 13].
    *   **장단점:** 설정이 단순하고 속도가 빨라 5~15명 규모의 팀과 중간 규모 애플리케이션에 매우 적합하다 [14]. 단, 구조가 너무 유연하여 엄격한 규율이 없을 경우 팀원마다 비동기 호출이나 상태 관리 패턴이 일관성 없이 파편화될 위험이 있다 [15, 16].

*   **Redux (Redux Toolkit)와 대규모 애플리케이션**
    *   Redux는 불변성 업데이트와 액션 디스패치, 리듀서를 통해 일관되고 예측 가능한 상태 컨테이너를 제공하는 산업 표준이다 [17]. 
    *   복잡한 파생 상태 관리가 필요하고 500개 이상의 컴포넌트를 다루거나, 10명 이상의 개발자가 협업하는 대규모 미션 크리티컬 애플리케이션에 적합하다 [18]. 강력한 구조를 강제하여 버그를 사전에 방지하며, Redux DevTools를 통해 복잡한 비동기 상태 에러를 빠르게 추적하고 디버깅할 수 있다 [19, 20].

*   **아키텍처 관점에서의 상태 위치 (Feature-Sliced Design)**
    *   Feature-Sliced Design (FSD) 아키텍처에서는 상태 관리 라이브러리의 종류와 무관하게 상태의 소유권을 명확히 제한한다. 엔티티 상태는 `entities` 레이어에, 특정 유저 시나리오의 상태는 `features` 레이어에, 글로벌 인프라 상태는 `app` 레이어에 두어 결합도를 낮춰야 한다 [21, 22].

## 🔗 Knowledge Connections
- **Related Topics:** [[Frontend Performance Optimization]], [[Feature-Sliced Design]], [[React Hooks]], [[Clean Code Principles]]
- **Projects/Contexts:** [[Redux Toolkit]], [[Zustand]], [[TanStack Query]], [[React Context API]]
- **Contradictions/Notes:** 상태 관리 라이브러리를 선택할 때 단순히 번들 크기(Context 0KB, Zustand 2.2KB, Redux 4.3KB)만을 비교하는 것은 잘못된 접근이라고 지적된다. 번들 크기가 작더라도 Context API를 잘못 사용할 경우 디버깅과 리렌더링 최적화에 막대한 개발 시간이 낭비될 수 있으므로, 팀 규모와 기능의 복잡성을 기준으로 선택해야 한다 [7, 9, 23].

---
*Last updated: 2026-04-26*