id: FE-State-ARCH-001 category: Unified 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 (상태 관리 아키텍처와 소유권)

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

추출된 패턴: "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) 문제를 근본적으로 해결함.

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

Modern-React-Application-Architecture-Patterns, Feature-Sliced-Design-FSD, Zustand, React-Context-API, TanStack-Query
Raw Source: 00_Raw/상태 관리 아키텍처(State Management Architecture).md