🎨 11. Context API의 한계와 렌더 워터폴 줄이기

🎯 이 섹션을 읽고 나면:

• Context API를 리덕스(Redux)처럼 상태 관리 도구라고 부를 수 없는 근본적인 엔진 한계를 설명할 수 있다.
• Context 안의 값이 하나 바뀌었을 때 하위 트리가 함께 렌더링되는 폭포수(Waterfall) 현상을 이해한다.
• 값(Value)과 행동(Action)을 책임별로 나누는 Context 분리(Splitting) 전략을 다룬다.

📋 목차

• 🤔 왜 알아야 하는가: Context는 무죄다, 당신이 남용했을 뿐
• 🏗️ 비유로 먼저 이해하기
• 🧩 렌더링 오염 줄이기: 여러 개의 포탈로 나누기 (Splitting)
  • ✅ 영호의 리팩토링: 바구니 강제 분할 (Splitting Context)
• ⚠️ 에러 해결 카탈로그
  • ❌ 매번 value에 새 객체를 밀어 넣는 위험한 행위

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 6분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입): "Props 넘기는 거 너무 귀찮아요! 우리 커뮤니티의 테마, 로그인 유저 정보, 입력창 자동완성 키워드까지 하나의 큰 Context에 넣고 전역에서 꺼내 쓰면 어떨까요?"
• 영호(리드): "영철 님, Context는 편리하지만 value 참조가 바뀔 때 구독자가 함께 렌더링됩니다. 서로 다른 관심사를 하나로 묶으면 렌더링 범위가 지나치게 넓어져요."

🤔 왜 알아야 하는가: Context는 무죄다, 당신이 남용했을 뿐

많은 사람들이 Zustand, Recoil, Redux 같은 외부 상태 관리 라이브러리를 쓰기 전, 리액트 안에 내장된 Context API를 '전역 상태 관리 도구'처럼 사용하곤 합니다.

Context 자체는 상태(State)가 아니며 관리(Manage)하지도 않습니다. 부모의 값을 하위 트리로 전달(Dependency Injection, 의존성 주입) 해주는 파이프라인에 가깝습니다.

🤔 잠깐, 먼저 생각해봐
거대한 바구니(Context) 하나에 유저 정보(name)와 다크모드(isDark)를 다 넣었어. 버튼을 눌러 다크모드를 켰지. 그런데 왜 유저 정보만 보여주던 아바타 컴포넌트까지 함께 리렌더링될까?

// ❌ 영철이의 위험한 바구니 (Context 오남용)
const AppContext = createContext();
 
function AppProvider({ children }) {
  const [theme, setTheme] = useState("light");
  const [user, setUser] = useState({ name: "영철" });
 
  // theme만 바뀌어도 value 객체 참조가 새로 만들어진다.
  const value = { theme, setTheme, user, setUser };
 
  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}
 
// ------------------------------
// 아주 조그만 컴포넌트 A
function Avatar() {
  // 나는 'user'만 필요한데 어쩔 수 없이 거대 바구니를 뒤져 꺼낸다
  const { user } = useContext(AppContext);
  console.log("아바타 리렌더링됨!"); // 🚨 테마 버튼 누르면 나도 리렌더링 발생!
  return <div>{user.name}</div>;
}

결과: 유저가 setTheme("dark")를 눌러 다크모드를 전환하면, 로그인 이름만 표시하던 Avatar 컴포넌트도 같은 Context를 구독하고 있기 때문에 함께 리렌더링됩니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

1. Context는 거대한 스피커가 달린 마을회관 동네 방송국이야.
2. 동네 방송 주파수(useContext)를 꽂고 라디오를 듣는 집들이 100가구가 있어. (아바타 집, 프로필 집, 테마 세팅 집 등...)
3. 영철(이장님)이 마이크(Context Value)를 들고 방송을 켰어. "아아! 오늘부터 다크모드 실시!"
4. 아바타 컴포넌트는 사실 다크모드 따위 전혀 관심 없어. 유저 아이디만 들으려 했거든. (난 user 정보만 뺐음)
5. 방송국 마이크에서 어떤 소리든 새로 송출(Context Value 객체의 참조 변경)되면, 그 주파수를 구독 중인 집들이 함께 반응(리렌더링) 해. 이게 이른바 렌더링 오염 워터폴이야.

✅ 핵심 원리:
09. 최적화의 거짓말에서 객체의 참조가 달라지면 React가 다른 값으로 본다고 배웠죠?
AppProvider에서 렌더링이 돌면, value에 전달한 { theme, user... } 묶음 객체의 참조가 새로 만들어집니다.
useContext를 선언한 모든 하위 컴포넌트는 자신이 꺼내 쓴 값이 뭐든지 간에, "아! 저 공장의 포장지(value 주소값)가 새로 바뀌었군! 내부는 안 봐도 새로 렌더링해야지!" 라며 무조건 렌더링 스냅샷을 돌려버리는 구조적인 한계점을 가집니다.
(이게 Redux 같은 외부 상태 툴이 개별 최적화를 구사하는 것과 Context의 가장 큰 차이입니다.)

🧩 렌더링 오염 줄이기: 여러 개의 포탈로 나누기 (Splitting)

이 렌더링 오염 문제를 줄이는 실무적인 방법은 포탈 바구니를 '기능 단위', 또는 '상태 vs 액션 단위'로 책임별로 나누는 것입니다.

✅ 영호의 리팩토링: 바구니 강제 분할 (Splitting Context)

유저 바구니와 테마 바구니를 나누는 것은 기본입니다. 더 나아가 실무에서는 "명사(값)" 과 "동사(바꾸는 함수)" 바구니까지 분리해 렌더링 범위를 더 좁힙니다.

// ✅ 우아한 고성능 아키텍처 (Pro Approach)
// 1. 값(Value) 전용 포탈
const ThemeStateContext = createContext();
// 2. 행동(Action/Dispatch) 전용 포탈
const ThemeDispatchContext = createContext();
 
function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");
 
  // 이 변경 버튼 함수들은 아무리 렌더링해도 영원히 똑같은 주소(포장지)여야 함!
  const dispatch = useMemo(() => ({
    toggleToDark: () => setTheme("dark"),
    toggleToLight: () => setTheme("light")
  }), []);
 
  return (
    <ThemeStateContext.Provider value={theme}>
      {/* 🎯 행동 포탈 아래에 값 포탈을 중첩 설계 */}
      <ThemeDispatchContext.Provider value={dispatch}>
        {children}
      </ThemeDispatchContext.Provider>
    </ThemeStateContext.Provider>
  );
}
 
// ------------------------------
// 어떤 컴포넌트 B (다크모드 변경 버튼)
function DarkModeToggleButton() {
  // 🎯 이 컴포넌트는 오직 '누르는 동작'만 필요하다.
  // '상태(테마 값)'를 보지 않으므로 StateContext를 수신(useContext)하지 않음!
  const { toggleToDark } = useContext(ThemeDispatchContext);
 
  // 😭 렌더링 범위 확인: 버튼을 눌러 테마가 계속 바뀌어도,
  // 이 버튼 컴포넌트 자신은 불필요하게 리렌더링되지 않는다.
  // 상태 포탈 구독을 포기하고 액션 포탈만 꺼내 썼기 때문.
  return <button onClick={toggleToDark}>어둠이여 내게 오라</button>;
}

이 압도적 설계(Context Splitting)를 보십시오.
테마 값을 구독(수신)하는 하위 컴포넌트들은 색이 바뀌면 다시 렌더링되어야 합니다.
하지만! 단순히 테마를 바꾸는 '스위치' 역할만 하던, 굳이 자기가 재렌더링되며 깜빡거릴 필요가 없는 컴포넌트들은 완전히 격리된 DispatchContext만 조용히 꺼내 씁니다. 렌더링 오염 파동을 완벽하게 피해 가는 최고의 컴포넌트 생존기법이죠.

💥 에러 해결 카탈로그

❌ 매번 value에 객체를 넣는 위험한 행위

상황: "나는 size를 Context에 넣지도 않았는데 왜 하위 트리가 다 오류가 발생할까?"

const DataContext = createContext(null);
 
function Layout() {
  const [info, setInfo] = useState('data');
  const size = useWindowSize(); // 🚨 범인: 창 크기 1px만 변해도 Layout을 리렌더링시킴
 
  return (
    // 💥 성능 장애의 주범: {{ ... }} 중괄호 두 개
    <DataContext.Provider value={{ info, setInfo }}>
      <PageArea />
    </DataContext.Provider>
  )
}

🔍 왜 '성능 장애'인가? (핵심 요약):

1. 즉석 붕어빵 구워내기: value={{ info, setInfo }}는 리액트에게 **"렌더링 때마다 매번 새로운 객체 주소를 생성하라"**고 명령하는 것입니다.
2. 참조값 불일치 문제: info 값이 털끝 하나 안 바뀌었어도, 객체 주소(0x001 -> 0x002) 가 바뀌게 되고, 리액트 Context 엔진은 "데이터가 변했다"고 판단합니다.
3. 불필요한 렌더링 확산: DataContext를 구독하는 하위의 여러 컴포넌트들은 부모가 창 크기 조절(size)로 흔들릴 때마다 함께 리렌더링 됩니다.

✅ 해결책: 냉동 동결 (useMemo)

// 🧊 [info]가 변하지 않는 한, 객체의 주소를 메모리에 저장합니다.
const memoizedValue = useMemo(() => ({ info, setInfo }), [info]);
 
return <DataContext.Provider value={memoizedValue}>{children}</DataContext.Provider>;

이렇게 해야 부모가 아무리 리렌더링해도, 하위 트리는 평온을 유지할 수 있습니다.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
Context는 우버이츠, 배민과 같다. 안에 치킨(유저 정보)과 피자(다크모드)를 다 우겨넣고 포장해서 배달하면, 피자에 관심 없는 치킨러버 컴포넌트까지 포장지(메모리 껍데기 주소) 개봉에 휩쓸려 무조건 리렌더링 노동을 뛰게 된다.
그러므로 Context는 상태의 단위, 나아가 읽기(State)와 쓰기(Dispatch) 단위로 잘게 도려내 파이프 여러 개로 내려꽂는 것이 시니어의 기초 소양이다.

📝 마무리 퀴즈

Q1. useContext의 동작 원리를 가장 정확하게 설명한 명제를 고르세요.

• A) "Context는 구독 중인 하위 컴포넌트들에게 바구니 내부 속성(Property) 중 내가 쓰는 값이 변했을 때만 렌더링을 멈춰주는 내장 메모이제이션을 품고 있다."
• B) "Context Provider의 value로 던져지는 객체의 참조 주소(Object.is)가 변경되는 순간, 그것을 듣고 있는 하위의 모든 컴포넌트들은 강제로 리렌더링된다."
• C) "Context 안에 상태(State)가 너무 복잡하게 얽히면 브라우저 성능이 저하되므로, 리액트가 데이터를 강제로 백그라운드 서버로 옮긴다."
• D) "Context API는 단방향 데이터 바인딩을 허물기 위한 양방향 이벤트 트리거 전용 도구다."

✅ 정답: B

💡 상세 해설: 리액트 Context 폭포수(Waterfall) 원리의 핵심입니다. Redux나 Zustand의 셀렉터(selector) 기법과 다르게, 내장 Context는 내부 데이터 속성이 변했는지를 개별적으로 파악하지 못합니다. 그저 제공자(Provider)의 value로 전달된 객체 주소(참조값) 자체가 바뀌면 하위 구독 컴포넌트를 모두 다시 그리는 단순한 의존성 주입 도구에 가깝습니다.

Q2. 성능 최적화 패턴인 "상태/액션 분리법(Splitting)"을 적용했을 때, 다크모드를 전환하는 스위치 버튼 컴포넌트가 얻는 이점은 무엇인가요?

• A) 토글 버튼 컴포넌트 자체가 전역 상태 캐시에 들어가 브라우저 새로고침을 해도 영구 저장된다.
• B) 오직 동작(Action) 포탈만 구독하므로 렌더링 원인인 상태(State) 포탈과 격리되어, 전역 테마 값이 변하더라도 스위치 버튼 자신은 불필요한 리렌더링을 겪지 않는다.
• C) 액션 함수 자체가 웹 워커(Web Worker) 내부 백그라운드로 밀려가 버튼의 반응 속도가 현저하게 단축된다.

✅ 정답: B

💡 상세 해설: 상태(값)와 액션(함수) Context를 물리적으로 쪼개면, 값을 화면에 그릴 필요가 없고 단지 액션만 실행하는 컴포넌트(예: 버튼)는 '액션 Context'만 구독하면 됩니다. 결과적으로 상태 값 변경으로 인해 발생하는 렌더링 파동을 완벽하게 피해 갈 수 있는 깔끔한 격리막이 형성됩니다.

Q3. 영철이는 "Props 계층을 따라 데이터를 넘기는 것(Props Drilling)이 피곤하니, 앞으로는 로그인 데이터든 검색어든 묻지도 따지지도 않고 무조건 Context API에 담아서 쓰겠다"라고 말합니다. Context 남용 시 초래되는 기능 외적인 '설계 구조적(아키텍처) 문제'를 구체적으로 서술하시오.

✅ 정답 및 주관식 해설:

영철님처럼 컴포넌트 깊이가 조금 깊다고 모든 데이터를 Context 파이프라인에 연결해 버리면, '컴포넌트의 독립성과 재사용성(Coupling 문제)' 이 크게 훼손됩니다.
우리가 <UserCard> 컴포넌트를 예쁘게 분리하는 이유는 나중에 사이드바 메뉴나 다른 라우트 페이지에서 그대로 재사용하기 위함입니다. 그런데 그 <UserCard> 안에 특정 페이지 최상단에만 존재하는 UserContext를 직접 구독하도록 로직(useContext)을 하드코딩해 버린다면?
그 컴포넌트는 무조건 영철님이 세팅한 특정 Context 우산 밖에서는 에러를 뿜으며 동작하지 않게 됩니다. 재사용 불가능한 의존적인 덩어리가 되는 것이죠.
따라서 부모에서 자식으로 2~3단계 정도의 얕은 계층이라면, 약간 번거롭더라도 명시적으로 Props를 따라 데이터를 내려주는 것이 컴포넌트의 독립성(합성/재사용)을 우아하게 유지하는 리액트의 정석 설계입니다.

🐣 영철이의 퇴근 일기

Redux 깔기 귀찮아서 그냥 useContext 안에 모든 정보 모두 넣고 편하게 살려 했는데, 그것 때문에 상관도 없는 컴포넌트 100개가 다 렌더링 노동을 뛰고 있었다니 등에 땀이 쭉 났다.

💡 "명사(값)와 동사(함수) 바구니조차 분리하라! 껍데기만 바뀌어도 하위 트리 전체가 불필요하게 흔들리는 렌더링 오염을 막는 최고의 전술이다."

다크모드 스위치 버튼 하나 때문에 버튼 자신까지 깜빡거리지 않게 만들려고 Dispatch 전용 포탈을 뚫는 기법은 완전 예술이었다. 무작정 글로벌 상태라고 Context 하나로 기워 버렸던 지난날의 비효율적인 코드들을 한 땀 한 땀 도려내고 싶어졌다. 집에 가서 맥주 한 캔 하면서 내 코드 상태 문제 상황나 한 번 파헤쳐봐야겠다.