Context API 기초

여러 하위 컴포넌트가 같은 값을 읽을 때 모든 중간 컴포넌트에 props를 되풀이해 넘기면, 값이 바뀌는 경로가 길어질 수 있습니다. React의 Context는 부모가 특정 하위 트리에 값을 제공하고, 그 아래의 컴포넌트가 깊이와 상관없이 그 값을 읽게 해 주는 전달 통로입니다. 다만 Context 객체 자체가 상태를 저장하거나 가지는 것은 아닙니다. 상태와 변경 함수는 여전히 컴포넌트의 useState나 useReducer, 또는 별도의 데이터 계층이 가지고, Context는 그 값을 필요한 범위에 전달할 뿐입니다. 4장에서 Context를 처음 다뤘다면, 이 글에서는 React 19의 Provider 문법과 기본값, 갱신의 규칙을 더 정확히 짚어 봅니다.

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

위 그림은 Context가 소유자의 값을 가장 가까운 Provider에서 전달하는 범위를 보여 줍니다. ThemeProvider가 소유자로서 theme과 toggleTheme을 가지고, ThemeContext는 그 값을 전달할 식별자(identity) 역할을 합니다. 같은 ThemeContext로 바깥에서 darkTheme을 제공하면 그 범위 안의 Page는 dark를 읽고, 안쪽에서 다시 lightTheme을 제공하면 그 범위의 Footer는 light를 읽습니다. Provider가 중첩되면 각 소비자는 바로 위에 있는 일치하는 Provider의 값을 받습니다.

그림의 오른쪽은 범위 밖의 두 조건을 따로 보여 줍니다. Provider가 아예 없으면 소비자는 기본값 null을 받고, 이 글의 커스텀 훅 useTheme이 오류를 냅니다. 반면 Provider가 value={undefined}를 제공하면 소비자는 기본값으로 돌아가지 않고 undefined를 그대로 받습니다. 그림 아래 칸들이 정리하듯 Context 객체는 값의 종류를 식별할 뿐 상태를 보관하거나 바꾸지 않고, React 19에서는 <ThemeContext value={value}>로 필요한 가장 작은 하위 트리를 감싸며, 중간의 컴포넌트는 props를 넘기거나 Context를 직접 읽지 않아도 됩니다. 다만 직접 구독하지 않는다는 것이 부모의 렌더링과 상관없다는 뜻은 아닙니다. 또 입력 필드의 값은 가까운 상태에, 경로와 검색 조건은 라우터에, 서버의 응답과 캐시의 수명은 데이터 계층에 그대로 두며, Context는 props를 생략하게 해 줄 뿐 소유를 대신하지 않습니다.

Context가 잘 맞는 경우

Context는 하나의 하위 트리에서 여러 컴포넌트가 읽는 값에 잘 맞습니다. 테마와 색상 모드, 현재 사용자와 권한에 따른 UI, 언어와 지역 설정, 특정 기능 영역의 상태와 변경 명령이 그 예입니다. 다만 앱의 규모만으로 Context를 쓸지 정하지는 않습니다. 값의 소유자와 필요한 소비자, Provider의 범위, 값이 바뀌는 빈도를 함께 보고 필요를 충족하는 가장 작은 범위를 고릅니다.

Context API의 세 역할

1. createContext: 통로의 식별자와 기본값 정의

createContext(defaultValue)는 컴포넌트가 제공하고 읽을 Context의 식별자를 만듭니다. 이 객체 자체에는 현재 상태가 들어 있지 않습니다. 이 파일에는 JSX가 없으므로 .js로 저장합니다.

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가 전혀 없을 때만 쓰는 정적인 마지막 대체값입니다. Provider가 value={undefined}를 제공하면 기본값으로 돌아가지 않고 undefined가 전달됩니다. 이 예제는 Provider가 빠진 것을 조용히 감추지 않도록 null을 표시용 값(sentinel)으로 두고, useTheme()에서 오류를 냅니다. 반대로 Provider 없이도 의미 있게 동작해야 하는 Context라면 'light'처럼 실제로 쓸 수 있는 기본값을 둘 수 있습니다.

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

React 19에서는 Context 객체 자체를 Provider로 렌더링합니다. 이전 버전의 <ThemeContext.Provider> 문법도 동작하지만, React 19 공식 문서에서는 예전 방식으로 소개합니다(React 문서의 createContext).

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는 이 값을 전달할 통로의 식별자입니다. 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를 권합니다(React 문서의 useContext).

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

Context를 직접 읽지 않는 컴포넌트는 Context 갱신의 직접적인 구독자가 아닙니다. 아래 세 파일에서 App은 Provider 안에 두 컴포넌트를 배치하고, MainContent는 props 없이 ContentSection을 렌더링하며, 맨 안쪽의 ContentSection만 useTheme()으로 Context를 읽습니다. 중간에 있는 MainContent의 코드에는 테마와 관련된 이름이 하나도 나오지 않는다는 점을 눈여겨봅니다.

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의 식별자나 메모이제이션에 따른 건너뛰기가 일부 작업을 생략할 수도 있습니다. 직접적인 Context 구독과 부모의 렌더링 경로를 구분해서 살펴봐야 합니다.

이 테마 파일들을 앱에 연결하면 처음 Header의 문구는 “현재 테마: light”이고, 전환한 뒤에는 “dark”가 됩니다. MainContent에 테마 props를 더하지 않아도 ContentSection은 같은 Context의 값을 읽습니다. 다만 이 예제에는 .header--dark와 .content--dark의 CSS가 정의되어 있지 않으므로, 클래스 이름이 바뀌는 것과 실제 색이 바뀌는 것은 따로 확인해야 합니다. 색까지 잇는 완전한 실습은 테마 변경 기능 구현에서 진행합니다.

가장 가까운 Provider와 override

Provider를 중첩하면 소비자는 위쪽에서 가장 가까운 Provider의 값을 받습니다. 아래 코드는 React 19부터 쓸 수 있는 <ThemeContext value={...}> 형태로 Provider를 렌더링합니다. 바깥 Provider는 darkTheme을 주고, 그 안에서 Footer만 다시 lightTheme을 주는 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를 읽는 소비자에게 새 값을 전달하고 다시 렌더링합니다. 객체와 함수는 내용이 같아 보여도 새로 만든 것이면 다른 값입니다. memo는 props에 대해 부모의 렌더링을 줄이는 최적화이므로, 컴포넌트가 직접 읽는 Context의 갱신을 막지 못합니다. 대신 Context를 읽는 바깥 컴포넌트와, 필요한 값만 props로 받는 메모이제이션된 자식을 나누는 방식은 별도의 최적화 지점이 될 수 있습니다.

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

위 그림은 같은 내용의 새 객체도 Context value의 변경이라는 점과, 소비자의 갱신을 살펴보는 순서를 보여 줍니다. 위쪽의 흐름처럼 상태를 가진 컴포넌트가 Provider에 value A를 넘겼다가 다시 A를 넘기면 Object.is가 같은 참조로 보지만, 내용이 같은 light이더라도 새 객체 B를 넘기면 변경으로 봅니다. 그러면 useContext로 직접 구독하는 일반 소비자와 memo로 감싼 소비자가 모두 새 값을 받아 다시 렌더링됩니다.

그림 아래의 표는 갱신을 줄이는 일곱 단계의 질문입니다. 어느 하위 트리가 값을 읽는지 보고 Provider를 그 소비자를 품는 가장 작은 범위에 두며, 상태와 바꾸는 규칙은 컴포넌트의 useState나 useReducer가 가지게 합니다. 이전 값과 다음 값을 Object.is로 비교해 같은지 확인하고, 객체나 함수가 이유 없이 새로 만들어진다면 측정한 비용이 있을 때 useCallback과 useMemo로 줄입니다. 그다음 누가 이 Context를 직접 읽는지 확인하며, memo가 Context의 갱신을 막지 못한다는 점과, 소비자의 집합과 바뀌는 주기가 다른 값이나 state와 안정적인 dispatch는 Context를 나눌 수 있다는 점을 고려합니다.

그림 위쪽의 예처럼 a = { theme: "light" }와 b = { theme: "light" }에서 Object.is(a, b)는 false, Object.is(a, a)는 true입니다. 그림의 설명처럼 실제로 테마가 바뀌었다면 새 값이 필요하고, useMemo와 useCallback은 불필요한 식별자 변경의 측정된 비용을 줄이는 최적화일 뿐입니다. 마지막 두 칸이 덧붙이듯, Context를 읽지 않는 중간 컴포넌트도 부모의 렌더링 때문에 실행될 수 있으므로, Profiler로 Provider의 범위와 value의 식별자, 직접 소비자, 부모의 렌더링을 구분해 기록한 뒤 가장 작은 변경을 적용합니다.

객체 비교는 React 화면 없이도 자바스크립트 Console에서 먼저 확인할 수 있습니다.

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: 같은 객체

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

value의 식별자 고정하기

Provider가 매번 value={{ theme, toggleTheme }}처럼 새 객체와 새 함수를 만들면, 상태가 그대로여도 Provider의 다른 렌더링 때문에 소비자가 갱신될 수 있습니다. 측정해 보니 이 비용이 의미 있다면 useCallback으로 함수를, useMemo로 객체의 식별자를 고정합니다. 메모이제이션을 무조건 더하지 말고, React Profiler로 어떤 Provider의 변경이 어떤 소비자의 렌더링을 일으켰는지 먼저 확인합니다.

Context 나누기

관련 없는 값을 한 객체에 넣으면 한 필드만 바뀌어도 그 Context를 읽는 모든 소비자가 새 값을 받습니다. 그 값을 읽는 소비자의 집합이 다르거나, 바뀌는 빈도와 이유가 다르거나, 상태를 읽는 컴포넌트와 안정적인 변경 명령만 필요한 컴포넌트가 나뉘거나, Provider가 필요한 하위 트리의 범위가 다르다면 Context를 나눌 수 있습니다. state와 dispatch를 별도의 Context로 나누는 것도 한 예입니다. 다만 작은 테마 객체처럼 비용이 문제가 되지 않는 경우에는 하나의 단순한 Context가 더 읽기 쉽습니다.

Context에 넣지 않을 상태

Context가 모든 상태의 기본 목적지는 아닙니다. 입력 필드 하나나 작은 컴포넌트만 쓰는 값은 가까운 지역 상태에 두고, URL의 경로와 검색 조건은 라우터가, 서버의 응답과 로딩, 재검증, 캐시의 수명은 서버·캐시 데이터 계층이 가집니다. Context는 이런 원래의 값을 UI용 저장소로 복제하는 수단이 아닙니다.

정리

• Context는 소유자가 가진 값을 하위 트리에 전달하는 통로이며, 객체 자체가 상태를 가지지는 않습니다.
• createContext(defaultValue)의 기본값은 Provider가 아예 없을 때만 쓰이고, value={undefined}를 제공하면 undefined가 그대로 전달됩니다.
• React 19에서는 <ThemeContext value={value}>로 Context 자체를 Provider로 렌더링하며, 소비자는 useContext로 가장 가까운 Provider의 값을 읽습니다.
• React는 value를 Object.is로 비교하므로 같은 내용의 새 객체도 변경이며, memo는 직접 읽는 Context의 갱신을 막지 못합니다.
• 측정해서 비용이 확인되면 useMemo와 useCallback으로 value를 고정하고, 소비자와 바뀌는 주기가 다른 값은 Context를 나눕니다.
• 지역 상태와 URL, 서버·캐시의 값은 Context로 복제하지 않고 원래의 자리에 둡니다.

연습 문제

모든 소비자는 앞의 useTheme을 쓰고, Provider에 주는 정상적인 값은 { theme, toggleTheme } 객체라고 가정합니다. 다음 상황을 각각 따로 판단해 보세요.

1. 중첩된 두 Provider

바깥 Provider의 theme은 dark, 안쪽 Provider의 theme은 light입니다. 안쪽에 있는 Footer와 바깥에만 있는 Header는 각각 무엇을 읽을까요?

2. Provider 밖의 Header

Header를 모든 Provider 밖으로 옮기면 useTheme의 어떤 분기가 실행될까요?

3. value가 undefined인 Provider

Provider는 있지만 value={undefined}라면 기본값 null이 대신 전달될까요? useTheme의 value === null 검사와 Header의 구조 분해는 어떻게 될까요?

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