---
id: FE-STATE-ARCH-001
category: "10_Wiki/💡 Topics/AI"
confidence_score: 1.0
tags: [state-management, architecture, ownership, react, zustand, redux, context-api, fsd]
last_reinforced: 2026-04-26
---

# State Management Architecture and Ownership (상태 관리 아키텍처와 소유권)

## 📌 한 줄 통찰 (The Karpathy Summary)
> "상태의 '양'보다 '위치'와 '소유권'이 더 중요하다. 도메인별(Entities), 기능별(Features), 그리고 인프라별(App)로 상태의 영토를 명확히 획정하여, 불필요한 리렌더링의 연쇄 폭발을 방지하라" — 예측 가능한 상태 흐름을 위한 계층적 관리 전략.

## 📖 구조화된 지식 (Synthesized Content)
- **추출된 패턴:** "Ownership-Based State Partitioning" — 상태의 영향 범위와 생명주기에 따라 `Global`, `Server`, `Local`, `URL` 상태로 분류하고, 각 레이어(Entities, Features, App)에 소유권을 할당하는 패턴.
- **핵심 아키텍처 규칙:**
    - **Entity State (Entities):** 핵심 비즈니스 데이터(사용자 정보, 상품 목록 등)의 원천은 `entities` 레이어에서 관리.
    - **Feature State (Features):** 특정 화면이나 상호작용에 종속된 상태(모달 열림 여부, 입력 폼 데이터 등)는 해당 `features` 레이어에 격리.
    - **Infrastructure State (App):** 인증 토큰, 테마, 언어 설정 등 앱 전반에 걸친 상태는 `app` 레이어에서 중앙 제어.
    - **Derived State:** 원본 데이터를 가공한 상태는 별도 변수로 관리하지 말고 `useMemo`나 Selector를 통해 실시간 산출.
- **의의:** 상태 변경 시 영향 범위를 한 눈에 파악할 수 있으며, 데이터 불일치(Inconsistency) 문제를 근본적으로 해결함.

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 과거에는 '단일 진실 공급원(Single Source of Truth)' 정책을 위해 모든 것을 하나의 Store에 넣었으나, 현대 정책은 '책임 범위에 따른 파편화된 진실 정책'을 통해 성능과 가독성을 동시에 확보함.
- **정책 변화:** Antigravity 프로젝트는 상태 관리 도구 선택 시 번들 크기보다 'Selector 최적화 기능 정책'을 우선하며, 빈번한 업데이트 상태에 대한 Context API 사용 금지 정책을 시행함.

## 🔗 지식 연결 (Graph)
- [[Modern-React-Application-Architecture-Patterns|Modern-React-Application-Architecture-Patterns]], Feature-Sliced-Design-FSD, Zustand, [[React-Context-API|React-Context-API]], TanStack-Query
- **Raw Source:** 00_Raw/상태 관리 아키텍처(State Management Architecture).md