🎨 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에 쌩 객체를 쑤셔 넣는 최악의 행위

상황:

const DataContext = createContext(null);
 
function Layout() {
  const [info, setInfo] = useState('data');
  const size = useWindowSize(); // 훅(창 크기 감지)
  
  // 💥 Layout이 렌더링(창 크기 축소 등) 돌 때마다 이 { 안의 } 괴물 같은 객체 포장지가 새로 생성되어 살포된다.
  return (
    <DataContext.Provider value={{ info, setInfo }}>
      <PageArea />
    </DataContext.Provider>
  )
}

원인: useWindowSize 때문에 브라우저 화면이 1px라도 좁아지거나 조작 이벤트가 일어날 때마다 Layout 껍데기 컴포넌트가 리렌더링을 돕니다. 그럴 때마다 저 value={{ info, setInfo }} 구문이 들이박히면서 완전히 새로운 메모리 더미 붕어빵 껍질 객체 100만 개가 복사 발사됩니다. info는 털끝하나 바뀌지 않았음에도, DataContext를 수신하는 모든 하위 트리 백만 대군이 쓸데없이 학살당합니다.

해결책:
Context를 하나로 기워 쓰지 말고, 찢어내는 위 방법이 최선입니다. 만약 굳이 여러 개를 묶어야겠다면 최후의 보루인 방어기재(useMemo)를 바르십시오.
<DataContext.Provider value={useMemo(() => ({info, setInfo}), [info])}> 로 포장지를 강제 동결시키면 그나마 아비규환은 막을 수 있습니다.

🏁 이번에 배운 내용 총정리

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

🐣 영철이의 퇴근 일기

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

💡 "명사(값)와 동사(함수) 바구니조차 찢어 버려라! 껍데기만 바뀌어도 하위 트리 전체가 잿더미가 되는 Context 방사능을 막는 최고의 전술이다."

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

📝 마무리 퀴즈

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

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

✅ 정답: B

💡 상세 해설: 리액트 Context 폭포수(Waterfall) 원리의 핵심입니다. 리덕스(Redux)나 쥬스탠드(Zustand)의 셀렉터(selector) 기법과 다르게, 내장 Context는 내부 데이터 속성이 무엇인지 전혀 알지 못하고 파악할 지능도 없습니다. 그저 마이크 제공자(Provider)의 value라는 커다란 통(객체 주소) 자체가 바뀌면 그냥 하위에 있는 추종자 컴포넌트를 무지성으로 전원 멱살 끌고 렌더링 링으로 끌고 나오는 무식하지만 단순 무식한 의존성 주입관에 불과합니다. (그래서 함부로 남용하면 최하위에 헬게이트가 열립니다.)

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

• A) 토글 버튼 컴포넌트 자체가 전역 상태 캐시에 들어가 브라우저 새로고침을 해도 영구 저장되는 마법.
• B) 토글 버튼을 10번 광적으로 클릭해서 전역 테마 State가 요동쳐도, 이 버튼 컴포넌트 자기 자신은 어차피 State 포탈을 파내지 않았고 통제권(Dispatch 액션 포탈) 공간만 잡고 있으므로, 본인 스스로의 불필요한 리렌더링 번쩍임(깜박임 연산)을 100% 모면하고 무적 상태가 된다는 기적.
• C) 액션 함수 자체가 웹 워커(Web Worker) 내부 백그라운드로 밀려가 버튼의 레이턴시(속도)가 현저하게 단축되는 점.

✅ 정답: B

💡 상세 해설: 포탈로 찢고 오로지 액션 주사기(Dispatch)만 꽂아서 쓰면, 저 밑에 상태가 어떻게 타오르든 말든 이 버튼 놈은 그 방사능을 맞지 않는 깔끔한 격리막이 형성됩니다.

Q3. 영철이는 "Props Drilling이 너무 지겹고 컴포넌트 몇 깊이 이상 타는 거 꼴도 보기 싫어요. 앞으론 로그인 데이터든, 검색창 검색어든 컴포넌트 넘기는 건 싹 다 무조건 Context API를 쓸래요." 라고 당돌하게 외칩니다. 영호가 Context의 무분별 남용 시 초래되는 '컴포넌트의 설계 미학적 붕괴 측면(재사용성 박살)'을 들어 조용히 반박하는 말을 주관식으로 적으시오. (단순 성능 저하 이슈가 아님!)

✅ 정답 및 주관식 해설:

"영철 님, 프롭스 구멍 뚫기가 싫다고 모든 걸 Context 파이프라인에 연결하면 생기는 가장 치명적 독소는 바로 '컴포넌트의 재사용 불가능(Coupling 지옥)' 에 있습니다.
우리가 컴포넌트(<Button>, <UserCard>)를 이쁘게 포장해서 분리하는 건 나중에 저쪽 B 사이드바 메뉴나 옆 동네 프로젝트에서 쏙 떼다가 그대로 재조립(재사용)을 하려는 목적이죠. 만약 그 <UserCard> 안에 강제로 컴포넌트 최상단 옥상에 있는 뚱뚱한 특정 UserContext를 뜯어먹도록 파이프라인(useContext 로직)을 심어놔 버렸다면?
그 컴포넌트는 무조건 영철님이 세팅한 특정 Context.Provider 우산 이불 밑에서만 살아남는 노예가 됩니다. 떼어다 딴 곳에 놔두면 파이프가 끊겨 즉사(Error)해버리고 종속성 스파게티가 파탄나버립니다.
그저 부모에서 자식으로 얕은 수준인 2~3단계 레벨의 프롭스 연판이라면, 더 더러워 보여도 솔직하게 구멍을 뚫고 짐(Props)을 쥐여 넘겨주는 것이 훨씬 컴포넌트의 탈부착(합성/재사용)을 아름답고 순수하게 놔두는 정석입니다."