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

Context API

📌 Brief Summary

Context API는 React에서 프롭 드릴링(prop drilling) 없이 하위 컴포넌트가 공유 데이터나 상태를 직접 소비할 수 있게 해주는 기능이다 [1], [2]. 이는 styled-components의 ThemeProvider와 같은 테마 적용 기능이나, 상태를 암시적으로 공유하는 합성 컴포넌트(Compound Components) 패턴을 구축하는 데 핵심적으로 사용된다 [3], [4]. 하지만 최근의 React Server Components(RSC) 아키텍처에서는 서버에 Context 환경이 존재하지 않기 때문에 런타임 CSS-in-JS 라이브러리 등과 함께 사용할 때 근본적으로 호환되지 않는 한계를 지닌다 [5], [6].

📖 Core Content

• 합성 컴포넌트(Compound Components)의 내부 규약: Context API는 컴포넌트의 내부 상태를 외부로 노출하지 않으면서도 관련된 하위 컴포넌트들 간에 상태를 공유하기 위한 내부 규약(Internal Contract)으로 자주 활용된다 [7], [8]. 소비자(Consumer)가 글로벌 상태를 직접 관리할 필요 없이, 자식 컴포넌트들이 프롭 드릴링 없이 공유 상태에 접근하여 유연하고 응집력 있는 UI를 구성할 수 있도록 돕는다 [2].
• 테마 및 전역 스타일 관리: styled-components와 같은 CSS-in-JS 라이브러리에서 ThemeProvider는 Context API를 통해 컴포넌트 트리 하위에 있는 모든 컴포넌트에 테마 객체를 주입한다 [3]. 컴포넌트 트리 내부에서 동적 테마 접근을 가능하게 하는 ThemeConsumer 역시 React.createContext를 기반으로 만들어졌다 [9].
• 성능 최적화와 리렌더링 관리: Context의 상태가 변경되면 해당 Context를 소비하는 모든 하위 컴포넌트가 리렌더링된다 [10]. 따라서 복잡하거나 재사용성이 높은 UI 컴포넌트를 구축할 때는 불필요한 리렌더링을 방지하기 위해 자주 변경되는 상태의 Context와 정적인 구성(Configuration)을 담당하는 Context를 분리(Split Contexts)하여 관리하는 것이 성능 최적화 기법으로 권장된다 [10], [11].
• React Server Components(RSC) 환경에서의 한계: Next.js App Router와 같은 서버 컴포넌트 실행 환경에서는 브라우저의 React Context를 사용할 수 없다 [5], [6]. 이로 인해 Context 기반의 테마를 사용하는 styled-components나 Emotion 같은 라이브러리는 RSC에서 ThemeProvider가 아무 기능도 하지 못하게 되며(no-op) [3], [12], 대신 CSS 사용자 지정 속성(CSS Variables)을 활용하거나 빌드 타임에 정적 CSS를 생성하는 방식(Zero-runtime)으로 전환해야 한다 [13], [5], [12].

🔗 Knowledge Connections

• Related Topics: Compound Components, React Server Components (RSC), Prop Drilling, Styled Components
• Projects/Contexts: Next.js App Router, Shopify Polaris
• Contradictions/Notes: 기존 CSS-in-JS 생태계에서는 동적 테마 제공을 위해 Context API에 전적으로 의존했으나, React Server Components(RSC) 환경에서는 서버에 Context가 존재하지 않는다는 모순이 발생하여 CSS-in-JS가 RSC와 근본적으로 호환되지 않는 문제를 낳았으며, 이에 따라 CSS 변수를 사용하는 방식으로 설계 방향이 이동하고 있다 [3], [5], [6], [12].

---

Last updated: 2026-04-26