2nd/10_Wiki/Topics/Frontend_Mastery/React Context API.md

React Context API

📌 Brief Summary

React Context API는 하위 컴포넌트가 'Prop Drilling(프롭스 내리꽂기)' 과정 없이 데이터를 직접 소비하고 상태를 공유할 수 있게 해주는 기능입니다 [1, 2]. 컴파운드 컴포넌트(Compound Components) 패턴에서 내부적으로 상태를 암시적으로 공유하거나, 애플리케이션의 전역 상태 및 동적 테마를 관리하는 데 주로 사용됩니다 [3-5]. 하지만 서버 전용 실행 환경인 React Server Components(RSC)에서는 Context를 사용할 수 없으므로, 이를 활용하는 런타임 CSS-in-JS 라이브러리들과 구조적인 비호환성을 가집니다 [6, 7].

📖 Core Content

• 상태 공유 및 Prop Drilling 방지: Context API는 컴포넌트 트리 깊숙한 곳까지 상태와 데이터를 직접 전달하여 컴포넌트 간의 결합도를 낮춥니다 [1]. 예를 들어, styled-components의 ThemeProvider는 이 API를 통해 트리 하위의 모든 스타일드 컴포넌트에 테마 객체를 주입합니다 [8].
• 컴파운드 컴포넌트(Compound Components)의 내부 계약: 아코디언(Accordion)이나 모달(Modal) 같은 재사용 가능한 UI 컴포넌트를 설계할 때 Context는 내부 계약(Internal Contract)의 역할을 합니다 [3]. 최상위 루트 컴포넌트가 'Provider'로서 공유 상태를 관리하고, 자식 컴포넌트들은 각자 필요한 Context만을 구독하여 유연한 UI 구성을 가능하게 합니다 [9-11]. 성능 최적화를 위해 Context를 여러 개로 분리하여 불필요한 리렌더링을 방지하는 기법도 자주 활용됩니다 [12, 13].
• 런타임 테마 적용: 애플리케이션에 다크 모드나 다중 브랜드 테마를 동적으로 적용하기 위해 런타임 Context 주입 방식이 사용됩니다 [5]. styled-components나 Emotion 같은 CSS-in-JS 라이브러리들은 이 Context를 활용해 테마를 관리합니다 [8, 14].
• React Server Components(RSC) 환경에서의 한계: 모던 프론트엔드 아키텍처(예: Next.js App Router)에서는 서버 컴포넌트 내에 React Context가 존재하지 않습니다 [6]. 이로 인해 Context 기반의 테마를 사용하는 CSS-in-JS 라이브러리들은 RSC 환경과 근본적으로 호환되지 않습니다 [7, 14]. 이를 해결하기 위해 Context 대신 CSS 변수(CSS custom properties)를 활용하거나, 런타임 오버헤드가 없는 Tailwind CSS 또는 vanilla-extract 같은 정적 추출 방식의 아키텍처로 전환하는 추세입니다 [6, 15, 16].

🔗 Knowledge Connections

• Related Topics: Compound Components, React Server Components (RSC), Prop Drilling, CSS-in-JS, styled-components
• Projects/Contexts: Next.js App Router, Shopify Polaris, Radix UI
• Contradictions/Notes: 소스에 따르면, Context API는 복잡한 UI 구성 요소 간의 상태를 공유하고 런타임 테마를 관리하는 데 매우 유용한 패턴으로 권장되지만 [2, 17], 최신 렌더링 패러다임인 React Server Components(RSC)에서는 브라우저 외부에서 실행될 수 없다는 엄격한 제약 때문에 확장 가능한 프론트엔드 구축 시 사용에 주의가 요구됩니다 [6, 7].

---

Last updated: 2026-04-26