🎨 11. Context API의 한계와 렌더 워터폴 파괴

🎯 이 섹션을 읽고 나면:

• Context API를 리덕스(Redux)처럼 상태 관리 도구라고 부를 수 없는 근본적인 엔진 한계를 설명할 수 있다.
• Context 안의 값이 하나 바뀌었을 때 하위 트리가 전부 모조리 렌더링되는 폭포수(Waterfall) 참사를 목격한다.
• 값(Value)과 행동(Action)을 잘게 쪼개는 Context 쪼개기(Splitting) 방어술을 다룬다.

📋 목차

• 🤔 왜 알아야 하는가: Context는 무죄다, 당신이 남용했을 뿐
• 🏗️ 비유로 먼저 이해하기
• 🧩 렌더링 오염 차단술: 여러 개의 포탈로 쪼개기 (Splitting)
  • ✅ 영호의 리팩토링: 바구니 강제 분할 (Splitting Context)
• 💥 에러 해결 카탈로그
  • ❌ 매번 value에 쌩 객체를 쑤셔 넣는 최악의 행위

📌 이 문서를 읽기 전에

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

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

• 영철(신입): "Props 넘기는 거 너무 귀찮아요! 우리 커뮤니티의 테마(다크모드), 로그인한 유저 정보, 심지어 입력창 자동완성 키워드까지 싹 다 거대한 하나의 뚱뚱한 Context에 욱여넣고 전역에서 뽑아 쓸게요!"
• 영호(리드): "영철 님... Context는 쳐다만 봐도 죄악인 '렌더링 오염'을 내뿜는 폭탄 바구니입니다. 그걸 하나로 뭉쳐두면 안되죠."

🤔 왜 알아야 하는가: 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: "영철" });
 
  // 💣 뚱뚱한 객체(바구니) 하나 만들어서 통째로 투하!
  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 컴포넌트가 강제로 리렌더링되며 피격 데미지를 입습니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

1. Context는 거대한 스피커가 달린 마을회관 동네 방송국이야.
2. 동네 방송 주파수(useContext)를 꽂고 라디오를 듣는 집들이 100가구가 있어. (아바타 집, 프로필 집, 테마 세팅 집 등...)
3. 영철(이장님)이 마이크(Context Value)를 들고 방송을 켰어. "아아! 오늘부터 다크모드 실시!"
4. 아바타 컴포넌트는 사실 다크모드 따위 1도 관심 없어. 유저 아이디만 들으려 했거든. (난 user 정보만 뺐음)
5. 하지만 리액트는 자비가 없지. 방송국 마이크에서 어쨌든 어떤 소리든 단 하나라도 송출(Context Value 객체의 껍데기 변동)되면, 주파수를 구독 중인 100가구를 모조리 깨워내어 강제로 재조립(리렌더링) 시켜버려. "방송 나왔으니 다 다시 세팅해!" 이게 이른바 렌더링 오염 워터폴이야.

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

🧩 렌더링 오염 차단술: 여러 개의 포탈로 쪼개기 (Splitting)

우리가 이 렌더링 오염 지옥에서 탈출하는 가장 고상한 시니어의 방법은 포탈 바구니를 '기능 단위', 또는 '상태 vs 액션 단위'로 아주 잘게 찢어 놓는 거야.

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

유저 바구니랑 테마 바구니를 찢는 건 당연한 거고, 나아가서 5년 차들은 성능을 한계까지 끌어올리기 위해 "명사(값)" 과 "동사(바꾸는 함수)" 바구니조차 격리시켜 분단해 버리지.

// ✅ 우아한 고성능 아키텍처 (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 하나로 기워 버렸던 지난날의 비효율적인 코드들을 한 땀 한 땀 도려내고 싶어졌다. 집에 가서 맥주 한 캔 하면서 내 코드 상태 지옥도나 한 번 파헤쳐봐야겠다.