🎨 09. 렌더 최적화의 달콤한 거짓말 (useMemo, useCallback)

🎯 이 섹션을 읽고 나면:

• 최적화 훅(useMemo, useCallback)이 공짜가 아니며 오히려 컴포넌트를 병들게 하는 원리를 설명할 수 있다.
• React.memo와 결합되지 않은 useCallback이 얼마나 무의미한 짓인지 깨닫게 된다.
• "섣부른 최적화는 만악의 근원"이라는 원칙하에, 언제 진짜 이 훅들을 꺼내들어야 할지 명확한 기준을 확립한다.

📋 목차

• 🤔 왜 알아야 하는가: '최적화'라는 무형의 공포
• 🏗️ 비유로 먼저 이해하기
• 🧩 그럼 진짜는 어디에 쓰는가? (정확한 사용 타이밍)
  • 타이밍 1. [진짜 무거운] 연산의 캐싱 (useMemo)
  • 타이밍 2. 자식 컴포넌트의 렌더링 폭포수 방어 (useCallback + React.memo)
  • 타이밍 3. 남의 Effect의 의존성 변수로 던져질 때
• 💥 에러 해결 카탈로그
  • ❌ 객체와 배열을 React.memo 자식에게 생짜로 넘길 때

📌 이 문서를 읽기 전에

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

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

• 영철(신입):"선배님! 제가 우리 커뮤니티 앱을 엄청나게 최적화했어요. 모든 함수는 useCallback으로 감싸고, 모든 객체와 배열은 useMemo로 감쌌습니다! 이제 엄청 빠르겠죠?"
• 영호(리드): "영철 님... 지금 메모리를 두 배, 세 배로 깎아먹으면서 '최적화'라고 부르시는 건가요? 브라우저 메모리 탭이 터지기 직전입니다."

🤔 왜 알아야 하는가: '최적화'라는 무형의 공포

프론트엔드 실무 기술 면접에서 주니어들이 가장 많이 탈락하는 질문이 있습니다. "어느 상황에서 useMemo와 useCallback을 쓰나요?"
대부분은 "렌더링 성능을 높이기 위해서요", "매번 함수 새로 만들어지는 걸 막으려고요" 라고 답변합니다. 이 대답은 반은 맞고 반은 틀렸습니다 (사실 거의 틀렸습니다).

🤔 잠깐, 먼저 생각해봐
덧셈을 한 번 하는 함수가 있어. 이걸 useCallback으로 감싸는 게 그냥 생짜로 냅두는 것보다 더 빠를까?

// ❌ 영철이의 무지성 최적화 (Premature Optimization)
function Counter() {
  const [count, setCount] = useState(0);
 
  // 영철: "와! 함수가 자꾸 불필요하게 생성되는 걸 막아야 해!"
  const handleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []);
 
  return <button onClick={handleClick}>클릭 {count}</button>;
}

영철이는 이 코드를 짜고 스스로를 최적화 마스터라 뿌듯해하겠지만, 리액트 창시자들은 이 코드를 보면 혀를 끌쯧 찹니다. 이 코드는 훅을 안 쓴 코드보다 훨씬, 무조건 더 느리고 끔찍한 코드이기 때문입니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
일반 함수 정의하기: 엄마가 메모지에 "사과 사 오기"라고 가볍게 휘갈겨 써서 지갑에 넣어두는 것. (메모지 한 장짜리, 0.0001초면 씀)
useCallback 쓰기: "사과 사 오기"라는 메모지를 공증 사무소(React 엔진 내장 메모리 캐시 탐색 체계)에 가져가서, 도장을 쾅 찍고, 두꺼운 캐비닛(배열)을 열어 저번에 넣어둔 메모지랑 내용이 똑같은지 하나하나 대조해 본 뒤, 똑같으면 옛날 메모지를 꺼내주는 행위.

고작 "사과 하나 사 와"라는 1초짜리 계산식을 위해 저 거창한 공증 사무소를 방문하는 게 맞을까? 아니지. 배보다 배꼽이 훨씬 커지잖아. 그냥 1초 걸려서 메모지 쿨하게 찢고 새로 휘갈겨 쓰는 게 백만 배는 더 이득이야!

✅ 핵심 원리:
useMemo와 useCallback은 공짜 마법이 아닙니다. 해당 훅을 실행하기 위해 리액트는 의존성 배열([])에 들어간 값들을 루프를 돌며 이전 값과 일일이 비교(Object.is)해야 하고, 힙 메모리의 특수한 캐시 공간을 별도로 점유해야 합니다.
즉, "훅을 실행하고 계산을 캐싱하는 비용(Overhead)"이 "매 렌더링마다 단순히 자바스크립트 함수/객체를 하나 새로 붕어빵 찍어내고 가비지 컬렉터(GC)에 버리는 비용"보다 압도적으로 비쌉니다. 자바스크립트의 V8 엔진은 함수 할당과 쓰레기 처리를 상상을 초월할 정도로 미친 듯이 잘합니다.

🧩 그럼 진짜는 어디에 쓰는가? (정확한 사용 타이밍)

타이밍 1. [진짜 무거운] 연산의 캐싱 (useMemo)

100원짜리 덧셈(버튼 클릭 함수 등)은 그냥 렌더링마다 새로 버리고 만드세요.
하지만 "상품 데이터 1만 개 정렬", "3D WebGL 파싱 데이터 계산" 같은 것들은 무조건 캐싱해야 합니다.

// ✅ 올바른 타이밍: CPU가 비명을 지르는 연산 (Pro Approach)
function AnalyticsDashboard({ userData }) {
  const [tab, setTab] = useState('chart');
 
  // userData가 바뀔 때만 이 지옥의 1초짜리 루프 연산을 수행하고,
  // 탭(tab)이 바뀔 때는 이 연산을 쏙 피해서 캐시된 이전 결과를 재활용한다!
  const heavyProcessedData = useMemo(() => {
    return runHeavyMathAlgorithm(userData); // 실행에 500ms 걸리는 미친 함수
  }, [userData]);
 
  return <div>...</div>;
}

타이밍 2. 자식 컴포넌트의 렌더링 폭포수 방어 (useCallback + React.memo)

가장 흔하게 useCallback을 오남용하는 케이스가, "그냥 자식 요소한테 인라인 함수 안 넘기려고요"입니다.
onClick={handlePlay}로 함수를 그냥 넘기든 useCallback으로 감싸서 넘기든, 자식 컴포넌트인 <Button />은 부모 렌더링 시 무.조.건 똑같이 리렌더링됩니다!

useCallback이 진짜 힘을 발휘하려면, 받는 자식 컴포넌트가 React.memo라는 철갑을 두르고 있어야 비로소 유효타가 들어갑니다.

// 🎯 자식 컴포넌트에 철갑(React.memo)을 둘렀다!
// props가 똑같다면 내 렌더링은 절대 안 할 거야!
const HeavyChart = React.memo(({ onZoom }) => {
  return <div>초고해상도 무거운 차트</div>;
});
 
function Dashboard() {
  const [text, setText] = useState('');
 
  // ✅ 완벽한 최적화:
  // 1. useCallback으로 onZoom 함수의 껍데기(주소값)를 얼린다.
  // 2. HeavyChart는 React.memo 덕분에 onZoom 주소값이 그대로이므로 렌더링을 멈춘다!
  // 결과: 텍스트 박스에 글을 칠 때마다 이 무거운 차트가 렌더링되는 대재앙을 완벽히 방어!
  const handleZoom = useCallback((level) => {
    console.log("줌 시도!", level);
  }, []);
 
  return (
    <>
      <input value={text} onChange={e => setText(e.target.value)} />
      <HeavyChart onZoom={handleZoom} />
    </>
  );
}

타이밍 3. 남의 Effect의 의존성 변수로 던져질 때

이건 이전 가이드 06에서 배웠지? 객체나 함수를 만들어서 자식 컴포넌트의 useEffect 의존성 배열([ ])로 던져버리면 무한 루프 폭탄이 터질 수 있어. 이때 그걸 방어하기 위한 방패막이용으로 useMemo/useCallback을 사용해 참조를 얼려주는 거지.

💥 에러 해결 카탈로그

❌ 객체와 배열을 React.memo 자식에게 생짜로 넘길 때

상황: 영철이가 차트 컴포넌트를 React.memo로 기껏 감싸놨어. 그런데도 차트가 계속 리렌더링이 된대!

const Chart = React.memo(({ data, options }) => { ... });
 
function Dashboard() {
  const [count, setCount] = useState(0);
 
  return (
    <div>
      <button onClick={() => setCount(c => c+1)}>업뎃</button>
      {/* 🚨 버튼을 누르면 Chart가 여전히 미친듯이 리렌더링 됨! */}
      <Chart
        data={[1, 2, 3]}
        options={{ color: 'red' }}
      />
    </div>
  );
}

원인: React.memo는 props를 얕은 비교(Object.is)해.
버튼을 눌러서 렌더링 스냅샷이 갱신될 때마다, 부모 트리의 JSX 코드 안에 적혀 있던 [1, 2, 3]이라는 놈은 메모리(Heap)에 완전히 새로운 주소를 가진 배열로 재탄생해! options 객체도 마찬가지야.
React.memo 봇: "앗! data(배열 껍데기) 주소가 바뀌었네! 다시 그려!" 방어막이 종잇장처럼 무너진 거야.

해결책:
객체 배열을 영구 동결시켜 넘겨라!

  // ✅ 밖으로 빼내거나(정적 데이터)
  const CHART_DATA = [1, 2, 3];
 
  // ✅ 내부에서 써야 한다면 useMemo로 얼리기
  const chartOptions = useMemo(() => ({ color: 'red' }), []);
 
  return <Chart data={CHART_DATA} options={chartOptions} />;

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
"섣부른 최적화는 만악의 근원이다." (도널드 크누스)
useMemo와 useCallback은 내 컴포넌트가 버벅거려서 도저히 못 봐주겠을 때, 프로파일러(Profiler)를 켜서 렌더링 범인을 찾아낸 뒤에만 허가되는 병기(Weapon)다. 방어구(기본 장비)가 절대 아니다.

🐣 영철이의 퇴근 일기

내가 온 사방에 발라둔 useCallback이 사실은 앱을 더 느리게 만들고 있었다니... 함수 새로 만드는 게 공증 사무소 가는 것보다 백만 배 이득이라는 비유가 뼈를 때렸다.

💡 "훅(Hook)은 공짜가 아니다! 정말 무거운 연산을 캐싱하거나, React.memo를 두른 자식에게 껍데기를 보존해서 넘길 때만 꺼내드는 비장의 무기다."

최적화랍시고 떡칠했던 코드들이 사실은 메모리의 무덤이었다니 얼굴이 화끈거린다. 그래도 영호님 덕에 "진짜 타격 판정"을 배웠으니까 아깝지 않다. 내일 당장 쓰레기 훅들 죄다 찢어서 버려버리고 바닐라의 스피드를 느껴봐야겠다.

📝 마무리 퀴즈

Q1. 영철이가 다음처럼 useCallback을 남발했습니다. 이 코드가 생짜로 함수를 만드는 코드보다 성능이 오히려 '안 좋은(악화된)' 이유를 가장 정확히 설명한 것은?

function SimpleCard() {
  const [like, setLike] = useState(false);
 
  const toggleLike = useCallback(() => {
    setLike(!like);
  }, [like]);
 
  return <button onClick={toggleLike}>좋아요</button>;
}

• A) useCallback은 브라우저의 전역 GPU 가속을 쓸데없이 호출하기 때문.
• B) 이 함수는 [like] 의존성을 가지고 있으므로 유저가 버튼을 누를 때마다(상태가 변하므로) 어차피 계속 "함수를 새로 생성"해야 한다. 이때 기존 함수 생성을 파괴하는 폼(기본 동작)에 덧붙여 의존성 배열을 루프 돌며 비교하는 오버헤드 연산까지 덤으로 떠안았기 때문.
• C) useCallback이 불리는 순간 자식 컴포넌트들의 모든 리렌더링 파이프라인이 정지되기 때문.
• D) useCallback 안에서는 불변성 위배(!like)가 감지되어 에러를 뱉기 때문.

✅ 정답: B

💡 상세 해설: 최적화의 역설을 찌르는 마스터피스 설계 문제입니다! 영철이는 함수 생성을 막겠답시고 저걸 썼지만, 버튼을 클릭할 때마다 like 값이 바뀝니다. 의존성 배열 [like]가 바뀌었으므로 리액트는 어차피 기존 캐시를 버리고 함수를 또 새로 만듭니다(캐싱 실패).
결국 이 짓은 1. 함수 새로 만들기 + 2. 이전 like와 지금 like 비교하는 추가 연산하기 라는 더블 페널티를 물게 됩니다. 아무 이득 없이 메모리와 CPU 시간만 파먹는 최악의 행위입니다.

Q2. useMemo를 반드시, 무조건적으로 도입해야 하는 유일한(가장 확실한) 타이밍을 골라보세요.

• A) 배열의 map 메서드로 UI 리스트(<li/>)를 10여 개 순회해서 그려낼 때.
• B) 백엔드에서 받아온 거대한 10,000줄의 JSON 배열을 재가공하고 클라이언트단에서 정렬(Sort) 알고리즘을 태울 때.
• C) <input> 창에서 유저가 타이핑할 때마다 그 state 값을 추적해야 할 때.
• D) 외부의 React Router 경로(useLocation)의 변경을 감지해야 할 때.

✅ 정답: B

💡 상세 해설: B처럼 명백하게 고비용 병목 연산("Expensive Calculation")을 처리할 때가 바로 useMemo의 진정한 무대입니다. A의 자잘한 그리기, C의 단순 상태 추적 등은 그냥 렌더링 단계에서 날것으로 던져주세요. 자바스크립트는 당신이 생각하는 것보다 수백 배 빠릅니다. 쓸데없이 다 useMemo 처리하면 메모리 공간 릭(Leak)만 발생합니다.

Q3. 다음의 '최적화 실패' 케이스를 보고, React.memo와 useCallback은 왜 서로 떼래야 뗄 수 없는 세트 무기인지를 설명해보세요.

// 1. 자식: React.memo() 없이 날것의 컴포넌트
function ChildButton({ onClick }) {
  console.log("자식 리렌더링 됨!");
  return <button onClick={onClick}>나를 눌러요</button>;
}
 
// 2. 부모:
function Parent() {
  const [val, setVal] = useState('');
 
  // 영철: "와하하! useCallback으로 함수 참조값을 완벽히 동결시켰으니,
  // 입력창에 타이핑(val 갱신)해도 자식은 절대 리렌더링 안 되겠지?"
  const handleClick = useCallback(() => console.log('눌렷따'), []);
 
  return (
    <div>
      <input value={val} onChange={e => setVal(e.target.value)} />
      <ChildButton onClick={handleClick} />
    </div>
  );
}

✅ 정답 및 주관식 해설:

영철이의 예상과 달리, 인풋 창에 글자를 칠 때마다 콘솔에는 **"자식 리렌더링 됨!"**이 미친 듯이 찍힙니다.
이유(Why): 리액트의 기본 렌더링 규칙 1조 1항, **"부모 컴포넌트(Parent)의 state가 바뀌어 렌더링이 돌면, 그 자식(Child)들은 프롭스가 변했든 안 변했든 묻지도 따지지도 않고 무조건 싹 다 강제 리렌더링된다"**라는 대원칙 때문입니다.
부모가 useCallback으로 기껏 onClick의 주소값(포장지)을 그대로 유지해서 넘겨줬더라도, 자식인 <ChildButton>이 그 포장지가 예전과 같은지 다른지 동등성 검사를 막아내는 방패(React.memo)를 입고 있지 않다면, 그냥 무지성으로 쓸려 내려가 새로 렌더링을 뜁니다!
따라서 부모의 useCallback은 반드시 자식의 React.memo라는 방어막 위젯과 쌍으로 결합되었을 때만 비로소 '렌더링 최적화 콤보'로서 작동합니다. 반쪽짜리 최적화는 거대한 함정일 뿐입니다.