2nd/00_Raw/State Management.md

State Management

📌 Brief Summary

상태 관리(State Management)는 프론트엔드 애플리케이션에서 데이터의 흐름과 컴포넌트 간의 데이터 공유를 다루는 핵심 개념입니다 [1, 2]. 과거의 단일 스토어(monolithic) 방식에서 벗어나, 현대의 애플리케이션은 로컬 상태, 전역 애플리케이션 상태, 서버 상태 등을 분리하여 각각에 특화된 도구를 사용하는 방향으로 발전했습니다 [1]. 상태를 명확하게 분류하고 아키텍처 규칙을 준수하여 관리하는 것은 불필요한 리렌더링을 방지하고 앱의 성능과 확장성을 보장하는 데 필수적입니다 [3, 4].

📖 Core Content

• 상태의 분류와 소유권 (State Categories & Ownership) 애플리케이션이 커질수록 상태를 세 가지 주요 카테고리로 명확히 나누어 관리해야 합니다: 시각적 토글이나 입력값을 다루는 로컬 UI 상태, 특정 사용자 상호작용과 연결된 기능(Feature) 상태, 사용자나 상품과 같은 핵심 비즈니스 데이터를 다루는 엔티티(Entity) 상태입니다 [3]. FSD(Feature-Sliced Design) 아키텍처는 엔티티 상태는 entities 계층에, 기능 상태는 features 계층에, 전역 인프라 상태는 app 계층에 두는 등 명확한 소유권 규칙을 강제합니다 [5].
• 서버 상태와 애플리케이션 상태의 분리 API에서 가져온 데이터(서버 상태)는 클라이언트 측의 애플리케이션 상태와 근본적으로 다르며 캐싱, 동기화, 로딩 및 에러 사이클 처리가 필요합니다 [4, 6]. 이 때문에 2025년 프론트엔드 표준에서는 TanStack Query (React Query) 와 같은 라이브러리를 활용해 서버 상태를 전역 상태 관리도구와 분리하여 처리합니다 [4, 6-8].
• Context API의 특성과 한계 React에 내장된 Context API는 Props Drilling을 해결하기 위한 데이터 전송 메커니즘으로, 그 자체만으로는 상태 관리 솔루션이 아니며 useState나 useReducer와 함께 사용해야 합니다 [2, 9]. 테마, 로케일, 기능 플래그와 같이 드물게 변경되는 정적인 전역 상태를 구성하는 데 적합합니다 [10, 11]. 하지만, 상태 변경 시 이를 구독 중인 모든 컴포넌트가 불필요하게 리렌더링되는 "브로드캐스트 시스템"이므로 자주 변경되는 동적 데이터에는 적합하지 않습니다 [4, 12, 13].
• Zustand를 활용한 최적화 Zustand는 중소규모 앱(50-500개 컴포넌트)에 적합한 가볍고 유연한 전역 상태 라이브러리입니다 [14-16]. **"선택자(Selector) 패턴"**을 지원하여, 컴포넌트가 구독한 특정 상태 조각(slice)이 변경될 때만 리렌더링되도록 함으로써 Context API의 성능 한계를 극복합니다 [4, 17, 18]. 단, 규칙이 매우 자유롭기 때문에 비동기 패턴 처리에 대해 팀 내 엄격한 규칙이 없다면 코드베이스가 혼란스러워질 수 있는 단점이 있습니다 [15, 19, 20].
• 대규모 시스템을 위한 Redux Redux는 500개 이상의 컴포넌트를 가진 대규모 앱, 복잡한 파생/계산 상태, 10명 이상의 팀원이 협업하는 환경에서 산업 표준으로 사용됩니다 [21, 22]. 보일러플레이트가 많아 보일 수 있으나, 오히려 이러한 구조적 제약이 일관성을 부여하여 버그를 사전에 차단하고 RTK Query를 통해 복잡한 비동기 작업을 수월하게 처리할 수 있도록 돕습니다 [21, 23, 24]. 또한 Time-Travel 디버깅 같은 훌륭한 DevTools 통합 환경을 제공합니다 [22, 23, 25].

🔗 Knowledge Connections

• Related Topics: Context API, Zustand, Redux, TanStack Query, Feature-Sliced Design
• Projects/Contexts: Scalable React Architecture, React Performance Optimization
• Contradictions/Notes: 상태 관리 라이브러리의 선택에 있어, 번들 크기(Bundle Size)만을 기준으로 결정하는 것은 잘못된 최적화 방식이며, 앱의 사용 사례, 팀의 규모 및 상태의 복잡성을 기반으로 평가해야 합니다 [26, 27]. 또한, 한 프로젝트에서 두 가지 도구를 병행하여 사용하는 것도 훌륭한 접근법입니다(예: 정적 설정에는 Context API, 동적 앱 상태에는 Zustand) [28].

---

Last updated: 2026-04-26