29 lines
1.9 KiB
Markdown
29 lines
1.9 KiB
Markdown
---
|
|
title: 전략적 상태 관리 가이드 (Global & Server [[State|State]])
|
|
category: Dev
|
|
tags: [State [[Management|Management]], React Query, SSOT, Architecture]
|
|
created: 2026-04-20
|
|
---
|
|
|
|
# [[React_State_Management_Strategy|React_State_Management_Strategy]] (상태 관리 전략)
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 상태는 '어디든' 있을 수 있지만, '아무데나' 있어서는 안 된다. 상태의 생명주기와 전파 범위에 따라 명확한 거주지를 결정하라.
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **상태의 3대 거주지**:
|
|
1. **Local State (거주형)**: `useState`. 특정 컴포넌트 내부에서만 알고 있는 '사생활' (예: 드롭다운 열림 여부).
|
|
2. **Global State (공용)**: `Zustand`, `Redux`. 온 동네가 알아야 하는 '공공 정보' (예: 로그인 유저, 다크모드).
|
|
3. **Server State (빌려온 것)**: `React Query`. 서버에서 잠시 빌려와서 화면에 보여주는 '외부 데이터'.
|
|
- **Server State의 독립**:
|
|
- 과거엔 Redux에 서버 데이터를 담으려 했으나, 이제는 캐싱, 재시도, 로딩 관리를 전담하는 **React Query/SWR**로 분리하는 것이 세계적인 추세다.
|
|
- **상태의 최소화 원칙**:
|
|
- 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.
|
|
|
|
## ⚠️ 모순 및 업데이트 (RL Update)
|
|
- 무조건적인 전역 상태 지상주의는 '[[Prop Drilling|Prop Drilling]]'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- Related: [[Single_Source_of_Truth|Single_Source_of_Truth]] , [[API_Communication_Patterns|API_Communication_Patterns]]
|
|
- Foundation: [[React_Hooks_Deep_Dive|React_Hooks_Deep_Dive]]
|