30 lines
2.6 KiB
Markdown
30 lines
2.6 KiB
Markdown
---
|
|
id: DEV-STATE-MGMT-001
|
|
category: "10_Wiki/💡 Topics/AI"
|
|
confidence_score: 1.0
|
|
tags: [frontend, software-architecture, state-management, redux, flux, zustand, react, design-patterns]
|
|
last_reinforced: 2026-04-26
|
|
---
|
|
|
|
# State Management Patterns (상태 관리 패턴)
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> "애플리케이션의 흩어진 기억(State)을 '단일 진실 공급원(Single Source of Truth)'으로 통합하고, 예측 가능한 규칙(Action)에 의해서만 변화를 허용하여 혼돈을 통제하라" — 복잡한 사용자 인터페이스에서 데이터의 흐름과 상태의 변화를 체계적으로 관리하기 위한 설계 패턴들의 총합.
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **추출된 패턴:** "Unidirectional Data Flow and Centralized Store" — 데이터가 위에서 아래로만 흐르게 하고(Prop Drilling 해결), 상태 변경은 오직 명시적인 요청(Dispatch)을 통해서만 발생하게 함으로써 앱의 현재 모습이 왜 그렇게 되었는지 완벽히 추적 가능하게 만드는 패턴.
|
|
- **주요 관리 패턴:**
|
|
- **Flux/Redux:** Action-Dispatcher-Store-View 순환 구조. 엄격하고 추적성이 높음.
|
|
- **Atomic (Recoil/Jotai):** 상태를 작은 단위(Atom)로 쪼개어 필요한 컴포넌트만 구독. 유연함.
|
|
- **Proxy-based (MobX/Valtio):** 상태를 관찰 가능한 객체로 만들어 변경 시 자동으로 UI 업데이트. 직관적임.
|
|
- **Simple Stores (Zustand):** 복잡한 보일러플레이트를 줄이고 핵심 기능에 집중한 경량화 패턴.
|
|
- **의의:** 컴포넌트가 수백 개로 늘어나도 데이터가 꼬이지 않게 하며, 디버깅과 테스트가 용이한 '예측 가능한 앱'을 구축하는 핵심 기둥.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 무조건 전역 상태 관리 도구(Redux 등)를 써야 한다는 강박에서 벗어나, 이제는 서버 데이터는 전용 라이브러리(React Query)에 맡기고 로컬 UI 상태는 컴포넌트 내부 상태(useState)나 가벼운 도구로 해결하는 '상태의 성격에 따른 분리'가 현대의 표준임.
|
|
- **정책 변화:** Antigravity 프로젝트의 프런트엔드 아키텍처는 복잡도를 낮추고 성능을 극대화하기 위해, 서버 지식 데이터와 로컬 UI 상태를 엄격히 분리하여 관리하는 하이브리드 상태 관리 전략을 채택함.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- [[Software-Architecture-Patterns]], Frontend-App-Development, [[Service-oriented-Architecture]], [[Modern-Website-Architecture]]
|
|
- **Raw Source:** 10_Wiki/Topics/AI/State-Management-Patterns.md
|