Organizer 정리 산출물(From_RawData) + 이사 체크리스트 + 인덱스 갱신
- Raw_Data 자동 정리 산출물이 각 도메인 From_RawData/ 로 편입, 00_INDEX 연결 갱신 - 컴퓨터_이사_체크리스트.md 추가 (두뇌-상대 경로 규약 v2.2.304 — 새 컴퓨터에서 바꿀 절대 경로는 localBrainPath 1개) - Astra 세션 산출물(에피소드 기억·기능 인벤토리) 갱신 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,125 @@
|
||||
---
|
||||
id: react-context-api
|
||||
title: "React Context API"
|
||||
category: "Frontend"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Context API", "리액트 컨텍스트", "React Context", "useContext"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "A"
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-07-11
|
||||
updated_at: 2026-07-11
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "context 이해 규칙"]
|
||||
raw_sources: [
|
||||
"Blogged Answers: Why React Context is Not a 'State Management' Tool (and Why It Doesn't Replace Redux)",
|
||||
"Context - React",
|
||||
"초보자를 위한 리액트 Context - 완벽 가이드 (2021) - freeCodeCamp"
|
||||
]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[React Context API]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
React Context API는 상태를 직접 관리하는 도구가 아니라, 컴포넌트 트리를 관통하여 Prop-drilling 없이 데이터를 공유하고 의존성을 주입(Dependency Injection)하기 위한 전송 메커니즘이다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Prop-drilling 방지:** 상위 컴포넌트에서 깊게 중첩된 하위 컴포넌트로 데이터를 전달할 때, 중간 단계의 컴포넌트들을 거치지 않고 직접 데이터를 '방송(broadcast)'하는 기능.
|
||||
- **의존성 주입(Dependency Injection):** 하위 컴포넌트가 특정 타입의 데이터를 필요로 할 때, 컴포넌트 자체가 데이터를 생성하지 않고 런타임 시 상위 Provider가 해당 값을 주입하는 구조적 패턴.
|
||||
- **상태 전송(Transport Mechanism):** Context 자체는 상태를 저장, 읽기, 업데이트하는 '관리'를 수행하지 않으며, 단지 `useState`나 `useReducer` 등을 통해 이미 관리되고 있는 상태를 다른 컴포넌트와 '공유'하는 파이프 역할을 함.
|
||||
- **참조 동일성(Reference Identity)과 렌더링:** Provider의 `value`가 변경될 때마다 이를 구독하는 모든 하위 Consumer 컴포넌트가 강제 재렌더링됨.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Context + useReducer 패턴:** 중간 수준의 복잡도를 가진 상태를 관리(`useReducer`)하고 이를 트리에 배포(`Context`)하는 조합. 종종 Redux의 대안으로 오해받지만, Redux와 달리 성능 최적화(특정 조각만 구독하여 렌더링 방지) 기능이 부족함.
|
||||
- **컴포넌트 합성(Component Composition) 대안 패턴:** 단순히 Props를 여러 단계 넘기는 것을 피하기 위해 Context를 무조건 사용하기보다, 자식 컴포넌트 자체를 상위에서 렌더링하여 Prop으로 넘기는 제어의 역전(Inversion of control) 패턴.
|
||||
- **데이터와 업데이트 함수의 분리 패턴:** 불필요한 재렌더링을 막기 위해 상태 데이터(Data)를 제공하는 Context와 상태 업데이트 함수(Updater)를 제공하는 Context를 각각 별도로 구성하는 분할 패턴.
|
||||
|
||||
## ⚖️ 비교 및 선택 기준 (Comparison & decision criteria)
|
||||
|
||||
| 항목 (Option) | 장점 | 단점 | 언제 선택 |
|
||||
|---|---|---|---|
|
||||
| **React Context API** | 내장 API로 추가 라이브러리가 불필요함. Prop-drilling 문제를 쉽게 해결. | 값이 변경될 때마다 구독 중인 모든 하위 컴포넌트가 재렌더링됨. | 테마(다크 모드 등), 로케일(언어), 현재 인증된 사용자 정보 등 업데이트 빈도가 낮은 전역 데이터 공유 시 [S1, S3]. |
|
||||
| **Redux (+ React-Redux)** | 상태 변화 추적(DevTools) 용이. 미들웨어 사용 가능. 구독한 상태의 특정 조각이 바뀔 때만 재렌더링 되도록 최적화 지원. | 초기 설정(보일러플레이트)이 필요하고 추가적인 라이브러리 의존성이 발생함. | 중간 이상의 복잡한 전역 상태 관리, 상태가 시간에 따라 빈번하게 업데이트되는 규모가 큰 애플리케이션 [S1]. |
|
||||
| **Component Composition** | 코드 구조가 깔끔해지고 하위 컴포넌트의 유연성 증가. Context 없이도 Prop-drilling 해결 가능. | 상위 컴포넌트로 복잡도가 몰릴 수 있으며, 모든 상황에 적합하지는 않음. | 단순히 여러 레벨로 Props를 전달하는 것을 피하고, 제어권을 루트 컴포넌트에 부여하고 싶을 때 [S2]. |
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **Context의 진정한 목적:** React 16.3에서 도입된 `createContext` API는 데이터를 컴포넌트 트리에 수동으로 넘기는 수고를 덜기 위해 설계되었다 [S1, S2]. 주된 목적은 애플리케이션 내의 "전역적(global)" 데이터, 예를 들어 테마, 사용자 기본 설정, 캐시된 데이터 등을 공유하는 것이다 [S2, S3].
|
||||
- **오해: 상태 관리 도구로서의 Context:** 많은 이들이 Context를 "상태 관리 도구"로 부르며 Redux를 대체할 수 있다고 믿지만, 이는 근본적인 오해이다 [S1]. "상태 관리"란 초기 값을 저장하고, 읽고, 업데이트하며, 변화를 알리는 과정(`useState`나 `useReducer`가 담당)을 의미한다 [S1]. Context는 단지 이미 존재하는 상태를 컴포넌트 간에 **공유(Share)**하고 **전송(Transport)**하는 역할만을 수행한다 [S1, S3].
|
||||
- **동작 메커니즘:** `React.createContext()`로 Context 인스턴스를 생성하고, 상위 컴포넌트에서 `<Context.Provider value={...}>`를 사용하여 값을 트리에 공급한다. 하위 컴포넌트는 `<Context.Consumer>` 또는 `useContext()` 훅을 사용하여 해당 값을 읽어 들인다 [S2, S3].
|
||||
- **렌더링 성능과 한계 (Caveats):** Context는 참조 동일성(Reference identity)을 사용하여 리렌더링 여부를 결정한다. 만약 Provider의 `value` prop에 객체 리터럴을 직접 생성하여 전달하면, 부모 컴포넌트가 렌더링될 때마다 새로운 객체 참조가 만들어져 Context를 소비하는 모든 자식 컴포넌트가 불필요하게 재렌더링되는 문제가 발생한다 [S2, S3]. 이를 피하기 위해서는 Provider로 전달할 값을 부모의 state로 끌어올리거나 메모이제이션 처리해야 한다 [S2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **업계의 흔한 오해 vs 기술적 사실:** React 커뮤니티에서는 종종 "Context가 Redux를 대체한다"거나 "Context로 상태 관리를 한다"는 주장이 있지만, Redux의 메인테이너(Mark Erikson)는 Context가 단지 의존성 주입과 prop-drilling을 피하기 위한 웜홀(Wormhole)일 뿐이며, 상태 관리는 훅(`useState`, `useReducer`)이 전담하므로 이 두 가지를 비교하는 것은 목적과 용도가 다른 도구의 오해에서 비롯된 것이라 지적한다 [S1].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
현재 발견된 실제 적용 사례가 없습니다. (소스 데이터 내에 특정 파일 경로, Git 커밋 해시, 결정 사항 레코드가 명시되어 있지 않음)
|
||||
|
||||
## 💻 코드 패턴 (Code patterns)
|
||||
```javascript
|
||||
// 1. Context 생성
|
||||
const UserContext = React.createContext();
|
||||
|
||||
// 2. Provider를 통한 데이터 공급
|
||||
export default function App() {
|
||||
return (
|
||||
<UserContext.Provider value="Reed">
|
||||
<User />
|
||||
</UserContext.Provider>
|
||||
);
|
||||
}
|
||||
|
||||
// 3. useContext 훅을 통한 데이터 소비
|
||||
function User() {
|
||||
const value = React.useContext(UserContext);
|
||||
return <h1>{value}</h1>;
|
||||
}
|
||||
```
|
||||
위 코드는 `React.createContext`를 초기화하고, `Provider`를 통해 문자열 데이터를 하위 트리에 전달한 후, 자식 컴포넌트에서 `useContext` 훅을 사용해 prop-drilling 없이 데이터를 성공적으로 읽어오는 최소 실행 패턴이다 [S3].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** A
|
||||
- **신뢰 점수:** 0.95
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
|
||||
### 상위/유사 개념
|
||||
- [[Prop-drilling]] — Context API가 등장하여 해결하고자 한 핵심 안티 패턴.
|
||||
- [[Redux]] — Context+useReducer 조합과 자주 비교되는, 구조화된 상태 전이 및 로깅을 지원하는 상태 관리 라이브러리.
|
||||
- [[Component Composition]] — 단순히 Props 전달의 번거로움을 피할 목적이라면 Context보다 우선적으로 고려될 수 있는 React 아키텍처 패턴.
|
||||
- [[useContext]] — Context 객체의 값을 함수형 컴포넌트에서 직접 읽을 수 있게 해주는 React Hook.
|
||||
|
||||
### 심층 후속 질문 (Deeper Research Questions)
|
||||
- Context API와 React-Redux가 내부적으로 Context를 사용하는 방식에는 어떤 기술적 차이가 있는가?
|
||||
- Provider의 `value`에 객체를 넘길 때 불필요한 재렌더링을 방지하기 위한 React.memo 및 useMemo의 최적의 결합 방식은 무엇인가?
|
||||
- 상태 관리를 위해 다중 Context(Multiple Contexts)를 분리할 때 발생하는 Provider Hell의 한계는 어떻게 극복할 수 있는가?
|
||||
- Context API를 의존성 주입(Dependency Injection) 컨테이너로 활용하는 고급 엔터프라이즈급 패턴은 무엇인가?
|
||||
- React 18+의 동시성 모드(Concurrent Mode)에서 Context API의 렌더링 방식은 기존과 어떻게 달라지는가?
|
||||
|
||||
### 실무 적용 맥락 (Practical Application Contexts)
|
||||
- **Implementation:** 앱 내에서 다크/라이트 테마 변경 기능이나 로그인 유저 인증 상태 세션을 전역 하위 컴포넌트에 배포할 때 구현.
|
||||
- **System Design:** 빈번하게 바뀌는 주식 호가 데이터 등은 Context로 분리하지 않고, 잘 변하지 않는 환경 설정만 Context로 올리는 데이터 분류 설계.
|
||||
- **Operation / Maintenance:** 성능 저하 리포트 수신 시, Context value의 참조 재생성으로 인한 대규모 렌더링 누수가 없는지 React Profiler로 진단.
|
||||
- **Learning Path:** Props -> Prop Drilling의 한계 체감 -> Component Composition -> Context API 도입 -> Global State Management (Redux/Zustand 등)의 차이점 인지 순으로 학습.
|
||||
|
||||
### 인접 주변 주제 (Adjacent Topics)
|
||||
- [[상태 관리(State Management)]] — Context와 혼동되기 쉽지만 실제로 로직이 수행되어야 하는 본질적 영역으로 확장.
|
||||
- [[Dependency Injection]] — 프론트엔드 환경에서 런타임에 서비스 인스턴스를 주입하기 위한 설계 개념으로 확장.
|
||||
|
||||
|
||||
## 🔗 지식 그래프 (Knowledge Graph)
|
||||
- **상위/루트:** [[context 이해 규칙]]
|
||||
- **관련 개념:** [[React Context API]], [[Redux]], [[의존성 주입(Dependency Injection)]]
|
||||
- **참조 맥락:** 컴포넌트 간 데이터 파이프라인 구축 및 React 생태계 내에서의 올바른 상태 관리 도구 채택 의사결정에 참조.
|
||||
|
||||
## 📚 출처 (Sources)
|
||||
- [S1] Blogged Answers: Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)
|
||||
- [S2] Context - React
|
||||
- [S3] 초보자를 위한 리액트 Context - 완벽 가이드 (2021) - freeCodeCamp
|
||||
Reference in New Issue
Block a user