# [[상태 관리 아키텍처(State Management Architecture)]]

## 📌 Brief Summary
상태 관리 아키텍처는 프론트엔드 애플리케이션에서 컴포넌트 간 데이터를 저장, 갱신, 전달하는 방식을 체계화한 구조입니다. 현대의 React 생태계에서는 거대한 단일 스토어 방식에서 벗어나, 상태의 성격(로컬, 전역, 서버 상태 등)에 따라 가장 적합한 도구를 분할하여 사용하는 파편화(Fragmentation) 방식이 표준으로 자리 잡고 있습니다 [1, 2]. 이는 불필요한 컴포넌트 리렌더링을 방지하고, 유지보수성과 애플리케이션의 성능 확장성을 극대화하는 데 필수적인 역할을 합니다 [3, 4].

## 📖 Core Content
*   **상태의 분류와 파편화(Fragmentation)**
    2025년 기준, 확장 가능한 프론트엔드 시스템 구축을 위해 상태 관리는 기술적 목적에 맞게 철저히 분리됩니다 [1].
    *   **로컬 상태 (Local State):** 개별 UI 컴포넌트 내부의 상태(예: 시각적 토글, 입력값 등)는 React 내장 훅인 `useState`와 `useReducer`를 사용하여 관리합니다 [1, 5].
    *   **전역 애플리케이션 상태 (Global Application State):** 사용자 세션, 테마, 장바구니 등 여러 컴포넌트가 공유하는 상태입니다. 과거에는 Context API가 많이 쓰였으나, 성능 문제로 인해 점차 Zustand나 Jotai와 같은 경량 라이브러리로 대체되는 추세입니다 [1, 2].
    *   **서버 상태 (Server State):** 클라이언트 상태와 분리하여 처리해야 하는 가장 중요한 영역입니다. API를 통해 가져온 데이터는 캐싱, 동기화, 로딩 및 에러 상태 관리가 필요하므로 TanStack Query (React Query)나 RTK Query와 같은 전용 라이브러리를 사용하여 관리합니다 [2, 6, 7].

*   **주요 전역 상태 관리 도구 비교 (Context API vs Zustand vs Redux)**
    *   **Context API:** React에 내장된 데이터 전송 메커니즘으로, 상태 관리라기보다는 Prop Drilling을 방지하는 브로드캐스트 시스템에 가깝습니다 [8, 9]. 단점은 하위 컴포넌트가 자신이 구독하는 데이터가 변경되지 않았더라도 컨텍스트의 일부 값이 변하면 무조건 리렌더링된다는 것입니다 [4, 10]. 따라서 테마, 다국어 지원 등 변경이 거의 없는 정적 데이터 관리에 가장 적합합니다 [11, 12].
    *   **Zustand:** 스토어가 React 컴포넌트 트리 외부에 존재하는 독립적인 모듈로 동작합니다 [13]. 선택자(Selector) 패턴을 통해 컴포넌트가 구독한 특정 상태 조각(slice)이 변경될 때만 리렌더링을 트리거하는 스마트 알림 시스템 역할을 하여, Context API의 리렌더링 문제를 완벽히 해결합니다 [2, 10]. 잦은 상태 업데이트가 필요한 중규모 이상의 앱이나 장바구니, 알림 시스템 등에 이상적입니다 [14, 15].
    *   **Redux:** 방대한 보일러플레이트를 요구하지만, 매우 복잡한 파생 상태를 다루거나 규모가 큰 개발 팀(10명 이상)에서 일관된 패턴을 강제해야 할 때 필수적인 산업 표준입니다 [16-18]. 디버깅(Time-travel), 액션 히스토리 추적, 복잡한 비동기 로직 처리에 뛰어납니다 [17, 19, 20].

*   **Feature-Sliced Design (FSD) 원칙과 상태의 소유권**
    확장성을 위해 도입되는 FSD 아키텍처 내에서는 어떤 상태 관리 라이브러리를 사용하든 소유권에 대한 엄격한 규칙이 유지되어야 합니다 [21]. 
    *   핵심 비즈니스 데이터 모델과 관련된 '엔티티 상태'는 `entities` 레이어에 위치해야 합니다 [21].
    *   특정 사용자 상호작용 및 워크플로우에 종속된 '피처 상태'는 `features` 레이어에 격리되어야 합니다 [21].
    *   애플리케이션 전반에 영향을 미치는 인프라 상태 구성은 `app` 레이어에서 관리되어야 시스템간 결합도(Coupling)를 낮출 수 있습니다 [21].

## 🔗 Knowledge Connections
- **Related Topics:** [[React Context API]], [[Zustand]], [[Redux]], [[TanStack Query]], [[Feature-Sliced Design (FSD)]], [[Server State]]
- **Projects/Contexts:** [[Frontend Performance Optimization]], [[Engineering Scalable Frontend Systems]], [[React Architecture Setup]]
- **Contradictions/Notes:** 상태 관리 라이브러리를 선택할 때 패키지 번들 크기(예: Context 0KB vs Zustand 2.2KB vs Redux 4.3KB)만을 기준으로 삼는 것은 매우 위험합니다. 소스에 따르면, 단지 번들 크기를 아끼고자 Context API를 오용했다가 수백 개의 컴포넌트가 불필요하게 리렌더링되어 심각한 퍼포먼스 저하(대시보드 마비 등)를 겪은 사례가 존재합니다 [3, 11, 22]. 도구의 선택은 바이트(Bytes) 단위의 크기가 아니라 팀의 규모, 상태의 복잡성, 앱의 성능 요구사항에 따라 결정되어야 합니다 [23].

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