From 4cb32664b3073a0a9dbceb14ce10d0fafe35b748 Mon Sep 17 00:00:00 2001 From: Antigravity Agent Date: Sun, 26 Apr 2026 21:34:38 +0900 Subject: [PATCH] chore: Delete processed raw file (State Architecture) --- ...리 아키텍처(State Management Architecture).md | 30 ------------------- ...e-Management-Architecture-and-Ownership.md | 29 ++++++++++++++++++ 2 files changed, 29 insertions(+), 30 deletions(-) delete mode 100644 00_Raw/상태 관리 아키텍처(State Management Architecture).md create mode 100644 10_Wiki/Topics/AI/State-Management-Architecture-and-Ownership.md diff --git a/00_Raw/상태 관리 아키텍처(State Management Architecture).md b/00_Raw/상태 관리 아키텍처(State Management Architecture).md deleted file mode 100644 index 60b34b85..00000000 --- a/00_Raw/상태 관리 아키텍처(State Management Architecture).md +++ /dev/null @@ -1,30 +0,0 @@ -# [[상태 관리 아키텍처(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* \ No newline at end of file diff --git a/10_Wiki/Topics/AI/State-Management-Architecture-and-Ownership.md b/10_Wiki/Topics/AI/State-Management-Architecture-and-Ownership.md new file mode 100644 index 00000000..d328172d --- /dev/null +++ b/10_Wiki/Topics/AI/State-Management-Architecture-and-Ownership.md @@ -0,0 +1,29 @@ +--- +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]], [[Feature-Sliced-Design-FSD]], [[Zustand]], [[React-Context-API]], [[TanStack-Query]] +- **Raw Source:** [[00_Raw/상태 관리 아키텍처(State Management Architecture).md]]