Context API 기초

여러 하위 컴포넌트가 같은 값을 읽을 때 모든 중간 컴포넌트에 props를 반복해서 전달하면 변경 경로가 길어질 수 있습니다.

React Context는 부모가 특정 하위 트리에 값을 제공하고, 그 아래 컴포넌트가 깊이와 관계없이 그 값을 읽게 하는 전달 채널입니다.

Context 객체 자체가 상태를 저장하거나 소유하는 것은 아닙니다. 상태와 변경 함수는 여전히 컴포넌트의 useState, useReducer 또는 별도 데이터 계층이 소유하고, Context는 그 값을 필요한 범위에 전달합니다.

바깥 Provider: darkTheme → Page
안쪽 Provider: lightTheme → Footer
Provider 없음 → null → useTheme 오류
value = undefined → undefined

Context가 잘 맞는 경우

Context는 다음처럼 하나의 하위 트리에서 여러 컴포넌트가 읽는 값에 잘 맞습니다.

• 테마와 색상 모드
• 현재 사용자와 권한 UI
• 언어와 지역 설정
• 특정 기능 영역의 상태와 변경 명령

앱의 규모만으로 Context 사용 여부를 정하지는 않습니다. 값의 소유자, 필요한 소비자, Provider 범위, 변경 빈도를 함께 보고 필요를 충족하는 최소 범위를 선택합니다.

Context API의 세 역할

1. createContext: 채널 identity와 fallback 정의

createContext(defaultValue)는 컴포넌트가 제공하고 읽을 Context identity를 만듭니다. 이 객체 자체에는 현재 상태가 들어 있지 않습니다.

import { createContext, useContext } from 'react';

const ThemeContext = createContext(null);

export function useTheme() {
  const value = useContext(ThemeContext);

  if (value === null) {
    throw new Error('useTheme must be used within ThemeProvider');
  }

  return value;
}

export default ThemeContext;

기본값은 위쪽 트리에 일치하는 Provider가 전혀 없을 때만 쓰는 정적인 마지막 fallback입니다. Provider가 value={undefined}를 제공하면 기본값으로 돌아가지 않고 undefined가 전달됩니다.

이 예제는 Provider 누락을 조용히 숨기지 않도록 null을 sentinel로 두고 useTheme()에서 오류를 냅니다. 반대로 Provider 없이도 의미 있게 동작해야 하는 Context라면 'light'처럼 실제 fallback 값을 사용할 수 있습니다.

2. Provider: 상태 소유자가 현재 값을 제공

설치된 React 19에서는 Context 객체 자체를 Provider로 렌더링합니다. 이전 버전의 <ThemeContext.Provider> 문법도 동작하지만 React 19 공식 문서에서는 legacy 방식입니다.

import { useCallback, useMemo, useState } from 'react';
import ThemeContext from './ThemeContext';

export default function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  const toggleTheme = useCallback(() => {
    setTheme(current => (current === 'light' ? 'dark' : 'light'));
  }, []);

  const value = useMemo(
    () => ({ theme, toggleTheme }),
    [theme, toggleTheme],
  );

  return (
    <ThemeContext value={value}>
      {children}
    </ThemeContext>
  );
}

ThemeProvider 컴포넌트가 theme 상태와 toggleTheme 동작을 소유합니다. ThemeContext는 이 값을 전달할 채널 identity입니다.

useCallback과 useMemo는 정확성을 위한 필수 요소가 아니라 성능 최적화입니다. 여기서는 Provider가 다른 이유로 다시 렌더될 때 같은 theme에 대해 새 함수와 새 객체를 만들지 않게 합니다. theme가 실제로 바뀌면 value도 바뀌어야 합니다.

3. useContext: 가장 가까운 Provider의 값 구독

import { useTheme } from '../contexts/ThemeContext';

export default function Header() {
  const { theme, toggleTheme } = useTheme();

  return (
    <header className={`header header--${theme}`}>
      <p>현재 테마: {theme}</p>
      <button type="button" onClick={toggleTheme}>
        테마 전환
      </button>
    </header>
  );
}

useContext(ThemeContext)는 호출한 컴포넌트 위쪽에서 가장 가까운 ThemeContext Provider를 찾습니다. 같은 컴포넌트가 반환하는 Provider는 그 컴포넌트 안의 useContext 호출에 적용되지 않으므로 Provider는 소비자보다 위에 있어야 합니다.

ThemeContext.Consumer도 남아 있지만 새 함수 컴포넌트에서는 useContext가 권장됩니다.

props 없이 통과하는 중간 컴포넌트

Context를 직접 읽지 않는 컴포넌트는 Context 갱신의 직접 구독자가 아닙니다.

import ThemeProvider from './contexts/ThemeProvider';
import Header from './components/Header';
import MainContent from './components/MainContent';

export default function App() {
  return (
    <ThemeProvider>
      <Header />
      <MainContent />
    </ThemeProvider>
  );
}

import ContentSection from './ContentSection';

export default function MainContent() {
  return (
    <main>
      <ContentSection />
    </main>
  );
}

import { useTheme } from '../contexts/ThemeContext';

export default function ContentSection() {
  const { theme } = useTheme();

  return <section className={`content content--${theme}`}>본문</section>;
}

MainContent는 ThemeContext를 직접 읽지 않지만 ContentSection은 읽습니다. 따라서 MainContent가 Context 전파를 위해 props를 중계할 필요는 없습니다.

다만 “Context를 읽지 않는다”가 “절대 다시 렌더되지 않는다”는 뜻은 아닙니다. 부모가 다시 렌더되면 일반적인 부모-자식 렌더 경로로 실행될 수 있고, element identity나 memoization에 따른 bailout이 일부 작업을 건너뛸 수도 있습니다. 직접 Context 구독과 부모 렌더 경로를 구분해서 관찰해야 합니다.

가장 가까운 Provider와 override

Provider를 중첩하면 소비자는 위쪽에서 가장 가까운 Provider의 값을 받습니다.

<ThemeContext value={darkTheme}>
  <Page />

  <ThemeContext value={lightTheme}>
    <Footer />
  </ThemeContext>
</ThemeContext>

Page 아래 소비자는 darkTheme을, 안쪽 Provider 아래 Footer 소비자는 lightTheme을 읽습니다. Provider 범위는 가능한 한 값을 실제로 필요로 하는 가장 작은 하위 트리에 둡니다.

Context 갱신과 렌더 계약

React는 Provider의 이전 value와 다음 value를 Object.is로 비교합니다.

• 비교 결과가 다르면 그 Context를 읽는 소비자에게 새 값을 전달하고 다시 렌더링합니다.
• 객체와 함수는 내용이 같아 보여도 새 identity이면 다른 값입니다.
• memo는 props에 대한 부모 렌더 최적화이므로, 컴포넌트가 직접 읽는 Context의 갱신을 막지 않습니다.
• Context를 읽는 바깥 컴포넌트와 필요한 값만 props로 받는 memoized 자식을 분리하는 방식은 별도의 최적화 경계가 될 수 있습니다.

a = { theme: "light" }
b = { theme: "light" }
Object.is(a, b) → false
Object.is(a, a) → true

a = { theme: "light" }
b = { theme: "light" }
Object.is(a, b) → false
Object.is(a, a) → true

value identity 안정화

Provider가 매번 value={{ theme, toggleTheme }}처럼 새 객체와 새 함수를 만들면, 상태가 그대로여도 Provider의 다른 렌더 때문에 소비자가 갱신될 수 있습니다.

측정 결과 이 비용이 의미 있을 때 useCallback으로 함수를, useMemo로 객체 identity를 안정화합니다. 메모이제이션을 무조건 추가하지 말고 React Profiler로 어떤 Provider 변경이 어떤 소비자 렌더를 만들었는지 먼저 확인합니다.

Context 분리

관련 없는 값을 한 객체에 넣으면 한 필드만 바뀌어도 그 Context를 읽는 모든 소비자가 새 값을 받습니다.

다음 기준이 다르면 Context를 나눌 수 있습니다.

• 값을 읽는 소비자 집합
• 변경 빈도와 변경 이유
• 상태를 읽는 컴포넌트와 안정적인 변경 명령만 필요한 컴포넌트
• Provider가 필요한 하위 트리 범위

state와 dispatch를 별도 Context로 나누는 것도 한 예입니다. 다만 작은 테마 객체처럼 비용이 문제가 되지 않는 경우에는 단순한 하나의 Context가 더 읽기 쉽습니다.

Context에 넣지 않을 상태

Context는 모든 상태의 기본 목적지가 아닙니다.

• 한 입력 필드나 작은 컴포넌트만 쓰는 값은 가까운 local state에 둡니다.
• URL 경로와 검색 조건은 router가 소유합니다.
• 서버 응답, 로딩, 재검증, 캐시 수명은 server/cache 데이터 계층에 둡니다.
• Context는 이 원본들을 UI store로 복제하는 수단이 아닙니다.

Provider 범위와 객체 비교를 따로 확인하기

위 테마 파일을 앱에 연결하면 첫 Header 문구는 현재 테마: light이고 전환 뒤 dark가 됩니다. MainContent에 테마 props를 추가하지 않아도 ContentSection은 같은 Context 값을 읽습니다. 원 예제에는 .header--dark와 .content--dark의 CSS 정의가 없으므로 클래스 이름이 바뀌는 것과 실제 색상이 바뀌는 것은 별개의 확인입니다. 색상까지 연결하는 완전한 실습은 테마 변경 기능 구현에서 진행합니다.

객체 비교는 React 화면 없이도 JavaScript 콘솔에서 먼저 확인할 수 있습니다.

const a = { theme: 'light' };
const b = { theme: 'light' };
const same = a;

console.log(Object.is(a, b));    // false: 새 객체
console.log(Object.is(a, same)); // true: 같은 객체

내용과 identity를 구별한 다음에야 어떤 Provider 렌더가 새 value를 만들었는지 추적할 수 있습니다. 이 비교만으로 실제 소비자의 렌더 횟수를 측정한 것은 아닙니다.

같은 Context의 세 가지 경계 풀기

모든 소비자는 위의 useTheme을 사용하고, Provider에 주는 정상 값은 { theme, toggleTheme } 객체입니다. 다음 상황을 각각 독립적으로 읽습니다.

1. 바깥 Provider의 theme은 dark, 안쪽 Provider의 theme은 light입니다. 안쪽에 있는 Footer와 바깥에만 있는 Header는 무엇을 읽을까요?
2. Header를 모든 Provider 밖으로 옮기면 위 custom Hook의 어떤 분기가 실행될까요?
3. Provider는 있지만 value={undefined}라면 기본값 null이 대신 전달될까요? 위 Hook의 value === null 검사와 Header의 구조 분해는 어떻게 될까요?

정리

Context 설계의 핵심은 “얼마나 전역적인가”보다 다음 질문에 답하는 것입니다.

1. 누가 상태와 변경 규칙을 소유하는가?
2. 어느 하위 트리의 소비자가 값을 읽는가?
3. Provider value는 어떤 이유로 identity가 바뀌는가?
4. 직접 Context 구독과 부모 렌더 경로가 어떻게 다른가?
5. 변경 주기와 소비자 집합이 다른 값은 분리해야 하는가?

다음 절에서는 useReducer가 복잡한 업데이트 규칙을 한 소유자에 모으고, Context가 state와 dispatch를 하위 트리에 전달하는 구조를 살펴봅니다.