useContext: 본질, 컨텍스트 액세스 훅 및 React의 프로바이더

React에서 useContext란

useContext는 React 16.8에서 다른 훅들과 함께 추가된, React 컨텍스트에서 값을 읽을 수 있게 해주는 훅입니다. 컨텍스트는 각 수준에서 수동으로 props를 전달할 필요 없이 컴포넌트 트리를 통해 데이터를 전달하도록 설계된 React 내장 메커니즘입니다. useContext는 이전 Context API의 Consumer 컴포넌트를 대체하며 코드를 더 간결하고 읽기 쉽게 만듭니다.

컨텍스트의 일반적인 사용 사례에는 테마(라이트/다크), 로케일 및 번역(i18n), 사용자 인증, 애플리케이션 설정 및 다양한 중첩 수준의 많은 컴포넌트가 필요로 하는 기타 글로벌 데이터가 포함됩니다. React 팀은 컴포넌트 서브트리에 대해 전역적인 데이터에는 컨텍스트를 사용하지만, 전체 애플리케이션에 대해서는 사용하지 않도록 권장합니다.

React Team — 컨텍스트 문서 (2025)에 따르면, 컨텍스트의 잘못된 사용은 React 애플리케이션에서 성능 문제의 주요 원인 중 하나입니다. Provider의 값이 변경될 때마다 데이터의 어떤 부분이 변경되었는지와 관계없이 모든 소비자가 재렌더링됩니다. useMemo를 통한 최적화와 컨텍스트 분할이 이 문제를 해결합니다.

import { createContext, useContext } from 'react';

// 기본값으로 컨텍스트 생성
const ThemeContext = createContext('라이트');

function ThemedButton() {
    const theme = useContext(ThemeContext);
    return <button className={`btn-${theme}`}>Click</button>;
}

React에서 컨텍스트의 작동 방식

React의 컨텍스트 메커니즘은 Provider-Consumer 패턴을 통해 구현됩니다. createContext는 두 엔티티를 가진 객체를 반환합니다: Provider — 값을 전달하는 컴포넌트, 그리고 useContext에서 사용되는 컨텍스트 객체 자체입니다. Provider는 컴포넌트 트리에 마운트되며 중첩 깊이에 관계없이 모든 자식 요소에 값을 전달합니다.

React가 useContext 호출을 만나면 파이버 트리를 탐색하여 해당 컨텍스트에 가장 가까운 Provider를 찾습니다. Provider가 발견되면 그 값이 반환됩니다. Provider가 발견되지 않으면 createContext에 전달된 기본값이 반환됩니다. 이 검색은 모든 렌더링에서 발생하지만 파이버 노드 메모이제이션 덕분에 매우 빠르며 성능에 영향을 미치지 않습니다.

React — 컨텍스트 내부 구조 (2024)에 따르면, useContext의 내부 구현은 useState와 유사하게 훅의 연결 리스트를 사용합니다. 각 훅은 파이버 노드에 대한 참조를 저장하여 React가 어떤 Provider가 해당 컨텍스트에 해당하는지 빠르게 결정할 수 있도록 합니다. Provider가 값을 업데이트하면 React는 해당 컨텍스트를 사용하는 모든 파이버 노드를 재렌더링용으로 표시합니다.

Provider와 중첩 컨텍스트

Provider 컴포넌트는 서로 중첩되어 컨텍스트의 계층 구조를 만들 수 있습니다. 각 자식 Provider는 자체 서브트리에 대해 부모의 값을 재정의합니다. 이는 한 화면에서 라이트 테마가 필요하고 중첩된 모달 창에서 다크 테마가 필요할 때 유용합니다. useContext는 항상 트리 상단에서 가장 가까운 Provider의 값을 반환합니다.

const UserContext = createContext(null);
const ThemeContext = createContext('라이트');

function App() {
    return (
        <UserContext.Provider value={{ name: 'Alice' }}>
            <ThemeContext.Provider value='dark'>
                <Profile />
            </ThemeContext.Provider>
        </UserContext.Provider>
    );
}

createContext로 Provider 만들기

createContext(defaultValue) 함수는 컨텍스트 객체를 생성합니다. defaultValue 매개변수는 컴포넌트가 useContext를 호출했지만 트리 상단에 해당 Provider가 없을 때 사용됩니다. defaultValue가 없으면 useContext는 undefined를 반환하며, 이는 예기치 않은 오류로 이어질 수 있습니다. 항상 의미 있는 기본값이나 null을 전달하는 것이 좋습니다.

사용자 정의 Provider를 만드는 것은 컨텍스트 로직을 캡슐화하는 일반적인 패턴입니다. 이러한 Provider 내부에서는 상태가(useState 또는 useReducer를 통해) 저장되고 Provider의 value prop을 통해 제공됩니다. 이는 소비자 컴포넌트로부터 구현 세부 사항을 숨기고 컨텍스트 관리 로직을 한 곳에 집중시킵니다.

// 상태 관리가 있는 사용자 정의 Provider
const AuthContext = createContext(null);

function AuthProvider({ children }) {
    const [user, setUser] = useState(null);

    const login = useCallback(async (email, pass) => {
        const u = await loginApi(email, pass);
        setUser(u);
    }, []);

    return (
        <AuthContext.Provider value={{ user, login }}>
            {children}
        </AuthContext.Provider>
    );
}

자식 컴포넌트에서 useContext 사용

함수형 컴포넌트에서 useContext는 컨텍스트에 액세스하는 유일한 방법입니다. 이는 render-prop 패턴이 필요했던 이전 Context API의 Consumer 컴포넌트를 대체합니다: <ThemeContext.Consumer>{value => ...}</ThemeContext.Consumer>. useContext는 코드를 더 선형적이고 읽기 쉽게 만들며, 특히 하나의 컴포넌트에서 여러 컨텍스트를 사용할 때 유용합니다.

하나의 컴포넌트에서 여러 컨텍스트를 사용할 때는 각 컨텍스트에 대해 useContext를 여러 번 호출하면 됩니다. 각 호출은 해당 Provider의 값을 반환합니다. 각 컨텍스트는 독립적인 엔티티이므로 호출 순서는 중요하지 않습니다. React는 동일한 파이버 참조 시스템을 통해 여러 호출을 최적화합니다.

function Dashboard() {
    const { user } = useContext(AuthContext);
    const theme = useContext(ThemeContext);
    const { locale } = useContext(I18nContext);

    return (
        <div className={`dashboard-${theme}`}>
            <h1>{locale.greeting}, {user.name}</h1>
        </div>
    );
}

useContext vs Redux: 언제 무엇을 선택할까

useContext와 Redux 사이의 선택은 상태 관리의 규모와 복잡성에 따라 달라집니다. useContext + useReducer는 소규모 및 중간 규모 애플리케이션을 위한 Redux의 경량 대체재입니다. 외부 라이브러리 설치가 필요 없고, 배우기 쉬우며, 대부분의 작업에 충분합니다. Redux는 미들웨어, 개발자 도구 및 불변 업데이트를 포함한 엄격한 아키텍처가 필요할 때 정당화됩니다.

useContext에 비한 Redux의 주요 장점은 재렌더링 최적화입니다. 기본적으로 Provider의 값이 변경되면 모든 컨텍스트 소비자가 재렌더링됩니다. Redux는 useSelector와 shallowEqual을 사용하여 컴포넌트가 상태의 특정 부분만 구독할 수 있도록 하여 대규모 애플리케이션에서 재렌더링 횟수를 크게 줄입니다. 컨텍스트도 여러 개의 작은 컨텍스트로 분할하여 최적화할 수 있습니다.

Redux 관리자 — Redux 사용 시기 (2024)에 따르면, React 애플리케이션의 70%는 Redux가 필요하지 않습니다. 컴포넌트가 50개 미만이고 상태에 캐싱, 디바운스 및 사이드 이펙트를 포함한 복잡한 로직이 없는 경우 — useContext + useReducer로 충분합니다. Redux는 보일러플레이트를 추가하므로 신중하게 사용해야 합니다.

useContext의 흔한 실수

가장 흔한 실수는 모든 Provider 렌더링에서 value 객체를 다시 생성하는 것입니다. Provider에 value={{ user, login }}을 전달하면 Provider가 렌더링될 때마다 새 객체가 생성되어 데이터가 변경되지 않았어도 모든 소비자가 재렌더링됩니다. 해결책은 useMemo로 값을 메모이제이션하거나 자주 변경되는 데이터와 드물게 변경되는 데이터에 별도의 컨텍스트를 사용하는 것입니다.

• 불필요한 재렌더링 — 매 Provider 렌더링마다 새 value 객체. useMemo로 값을 메모이제이션.
• 너무 큰 컨텍스트 — 수십 개의 필드를 가진 하나의 Provider는 필드 하나만 변경되어도 모든 자식 컴포넌트 재렌더링. 의미별로 여러 컨텍스트로 분할.
• defaultValue 부재 — Provider가 없으면 useContext는 defaultValue 반환, undefined면 모든 호출에서 TypeError 발생.
• 동일 타입의 중첩 Provider — 깊은 수준에서 컨텍스트 재정의는 혼란을 일으키고 예기치 않은 값을 초래할 수 있음.

// ❌ 모든 렌더링에서 새 객체 — 모든 소비자 재렌더링
<AuthContext.Provider value={{ user, login }}>{children}</AuthContext.Provider>

// ✅ 메모이제이션된 값 — user 또는 login이 변경될 때만 재렌더링
const authValue = useMemo(() => ({ user, login }), [user, login]);
<AuthContext.Provider value={authValue}>{children}</AuthContext.Provider>

“큰 컨텍스트” 문제를 해결하려면 전역 상태를 논리적 그룹으로 분할하세요: AuthContext, ThemeContext, I18nContext. 각 컨텍스트는 자체 영역을 담당하며 독립적으로 업데이트됩니다. 이는 useMemo를 통해 하나의 거대한 컨텍스트를 최적화하려는 것보다 간단하며 더 예측 가능한 재렌더링 동작을 제공합니다.