[React] useMemo와 useCallback은 언제 정말로 성능을 개선할까? (측정 기준)

리액트(React) 생태계에서 성능 최적화는 언제나 뜨거운 감자입니다. 특히 useMemo와 useCallback은 리액트 개발자라면 반드시 마주하게 되는 도구이지만, 동시에 가장 오용되기 쉬운 도구이기도 합니다. 많은 개발자가 "성능에 좋겠지"라는 막연한 추측으로 모든 함수와 연산에 이 훅들을 적용하곤 합니다.

하지만 리액트 팀의 댄 아브라모프(Dan Abramov)를 비롯한 수많은 시니어 엔지니어들은 "섣부른 최적화(Premature Optimization)는 만악의 근원"이라고 경고합니다. 오늘은 useMemo와 useCallback의 내부 메커니즘을 낱낱이 파헤치고, 실무에서 성능 이득을 정량적으로 측정하여 적용하는 기준을 제시하겠습니다.

---

1. 메모이제이션(Memoization)의 배신: 공짜 점심은 없다

우선 우리가 사용하는 이 훅들이 공짜가 아니라는 점을 명확히 인지해야 합니다. useMemo나 useCallback을 호출할 때마다 리액트 내부에서는 다음과 같은 비용이 발생합니다.

1.1 메모리 비용 (Memory Overhead)

메모이제이션은 기본적으로 '메모리를 써서 시간을 사는' 행위입니다. 이전 계산 결과나 함수 참조를 메모리에 유지해야 하므로, 앱의 전체적인 메모리 사용량이 늘어납니다. 아주 미미해 보일 수 있지만, 수백 개의 컴포넌트에서 무분별하게 사용될 경우 가비지 컬렉션(GC)에 부담을 줄 수 있습니다.

1.2 비교 비용 (Comparison Overhead)

리액트는 매 렌더링마다 의존성 배열(deps)의 요소들을 하나씩 꺼내 이전 값과 비교하는 얕은 비교(Shallow Compare)를 수행합니다.

• 만약 연산 자체가 매우 단순하다면(예: 두 숫자의 합), 그 연산을 다시 하는 것보다 의존성 배열을 순회하며 비교하는 비용이 더 클 수 있습니다.

---

2. useMemo: 무거운 연산의 기준과 참조 동일성

useMemo는 특정 연산의 결괏값을 저장합니다. 이 훅의 적용 기준은 크게 두 가지로 나뉩니다.

2.1 연산의 복잡도 (Computational Expense)

가장 흔한 오해는 모든 배열 처리(filter, map, reduce)에 useMemo를 써야 한다는 생각입니다. 하지만 자바스크립트 엔진은 생각보다 훨씬 빠릅니다.

성능 측정 기법: performance.now() 어떤 연산이 useMemo를 쓸 만큼 무거운지 알고 싶다면, 브라우저 콘솔에서 직접 측정해 보세요.

JavaScript

 

const startTime = performance.now();
doSomethingExpensive(data);
const endTime = performance.now();
console.log(`연산 소요 시간: ${endTime - startTime}ms`);

일반적으로 1ms 이상 소요되는 연산은 useMemo를 고려할 만한 '유의미한' 비용으로 간주합니다. 만약 0.1ms 미만의 연산이라면 useMemo를 사용하는 것이 오히려 손해일 가능성이 높습니다.

2.2 참조 동일성 유지 (Referential Identity)

연산 속도보다 실무에서 더 중요한 이유는 참조값 고정입니다. 리액트에서 객체({})나 배열([])은 내용이 같아도 매번 새로운 참조를 가집니다.

• 이 값이 useEffect의 의존성 배열에 들어간다면? -> 무한 루프나 불필요한 이펙트 실행의 원인이 됩니다.
• 이 값이 React.memo로 감싸진 자식 컴포넌트의 Props로 전달된다면? -> 자식은 내용이 변하지 않았음에도 리렌더링 됩니다.

이런 경우, 연산의 복잡도와 상관없이 참조를 일관되게 유지하기 위해 useMemo를 반드시 사용해야 합니다.

---

3. useCallback: 함수 리렌더링과 자식 컴포넌트의 관계

useCallback은 함수 참조를 고정합니다. 많은 초보자가 "함수 생성을 방지해서 성능을 높인다"라고 생각하지만, 자바스크립트에서 함수를 새로 생성하는 비용은 현대 브라우저에서 거의 무시해도 될 수준입니다.

3.1 React.memo와의 환상적인 조합

useCallback이 효과를 발휘하는 유일한 시점은 자식 컴포넌트가 리렌더링을 방어하고 있을 때입니다.

JavaScript

 

// 자식 컴포넌트가 memo로 최적화되어 있음
const ExpensiveList = React.memo(({ onItemClick }) => {
  console.log("목록 리렌더링 중...");
  return (
    <ul>
      {/* 복잡한 리스트 아이템들 */}
    </ul>
  );
});

const Parent = () => {
  const [text, setText] = useState("");

  // 이 함수가 useCallback으로 감싸져 있지 않다면,
  // 부모가 글자를 입력할 때마다 참조가 바뀌어 ExpensiveList가 리렌더링됨
  const handleClick = useCallback((id) => {
    console.log(id);
  }, []); // 의존성이 없으므로 단 한 번만 생성됨

  return (
    <>
      <input value={text} onChange={(e) => setText(e.target.value)} />
      <ExpensiveList onItemClick={handleClick} />
    </>
  );
};

만약 ExpensiveList가 React.memo로 감싸져 있지 않다면, 부모가 렌더링 될 때 자식도 어차피 렌더링 되므로 useCallback은 메모리만 낭비하는 꼴이 됩니다.

---

4. 실무 트러블슈팅: 최적화가 오히려 성능을 해치는 신호

블로그 독자들에게 실질적인 도움을 주기 위해, 최적화 훅을 제거해야 할 때의 신호를 정리해 봅니다.

1. 의존성 배열이 너무 빈번하게 바뀜: deps에 포함된 값이 렌더링마다 바뀐다면 메모이제이션은 작동하지 않고 비교 연산만 추가될 뿐입니다.
2. 기본형 데이터 타입에 사용: 문자열, 숫자, 불리언은 값을 직접 비교하므로 참조 고정이 필요 없습니다.
3. 컴포넌트 하위 계층이 단순함: 자식 컴포넌트들이 매우 가볍다면, 리렌더링 되는 비용이 최적화 로직을 타는 비용보다 저렴합니다.

---

5. 정량적 측정: React Profiler 활용하기

"느낌적인 느낌"으로 코드를 짜지 마세요. 리액트 개발자 도구의 Profiler 탭은 가장 강력한 무기입니다.

1. Record 버튼을 누르고 서비스의 주요 동작(클릭, 입력 등)을 수행합니다.
2. Flamegraph 차트를 확인합니다.
3. "Why did this render?" 섹션을 통해 특정 컴포넌트가 리렌더링 된 이유가 단순히 Props의 참조값 변화 때문인지 확인합니다.

만약 참조값 변화가 원인이라면, 그때가 바로 useMemo나 useCallback을 투입할 "골든 타임"입니다.

---

6. 결론: 유연하고 영리한 최적화 전략

프런트엔드 성능 최적화는 기술이라기보다 '트레이드오프(Trade-off)'에 가깝습니다. 가독성을 희생하고 메모리를 더 써서 렌더링 성능을 얻을 것인가, 아니면 약간의 렌더링을 허용하고 깔끔한 코드를 유지할 것인가의 선택이죠.