🎧

https://tkdodo.eu/blog/the-useless-use-callback

원문

메모이제이션(memoization)에 대해서는 이제 충분히 다뤘다고 생각했는데, 요즘 자주 보이는 한 가지 패턴을 보면서 생각이 달라졌다.
그래서 오늘은 useCallback과, 부분적으로는 useMemo에 대해 이야기해보려 한다.
특히 내가 보기엔 정말 불필요하게 사용되는 경우들에 대해 말이다.

왜 메모이제이션을 사용할까?

보통 useCallback으로 함수를, useMemo로 값을 메모이제이션하는 이유는 단 두 가지뿐이다.

function Meh() {
  return (
    <MemoizedComponent
      value={{ hello: 'world' }}
      onChange={(result) => console.log('result')}
    />
  )
}

function Okay() {
  const value = useMemo(() => ({ hello: 'world' }), [])
  const onChange = useCallback((result) => console.log(result), [])

  return <MemoizedComponent value={value} onChange={onChange} />
}

물론 때로는 useMemo 내부의 계산 자체가 느릴 때가 있다.
이럴 땐 불필요한 재계산을 피하기 위해 메모이제이션을 사용하는데, 이런 경우의 useMemo 사용은 전혀 문제 없다.
하지만 솔직히 말하자면, 이런 경우가 대부분은 아니다.

2. Effect가 불필요하게 자주 실행되는 것을 막기 위해

no-memo

function Okay() {
  const value = useMemo(() => ({ hello: 'world' }), [])
  const onChange = useCallback((result) => console.log(result), [])

  return <Component value={value} onChange={onChange} />
}

차이점을 찾을 수 있는가? 맞다 — 이제 value와 onChange를 메모이제이션된 컴포넌트에 전달하지 않는다.
그냥 일반적인 React 함수형 컴포넌트일 뿐이다.

이런 상황은 특히 결국엔 값이 React의 기본(built-in) 컴포넌트로 전달될 때 자주 발생한다:

react-built-ins

function MyButton() {
  const onClick = useCallback(
    (event) => console.log(event.currentTarget.value),
    []
  )

  return <button onClick={onClick} />
}

여기서 onClick을 메모이제이션해도 아무런 효과가 없다.
왜냐하면 버튼 컴포넌트는 onClick이 참조가 안정적인지 여부를 신경 쓰지 않기 때문이다.

“아무 효과가 없다(Achieves nothing)”라고 표현했지만, 엄밀히 말하면 약간 잘못된 표현이다. 사실 내부적으로는 분명 무언가 일이 일어나고 있다.

React는 onClick 함수를 유지하기 위해 캐시를 만들어야 하고, 의존성을 추적하며 매 렌더링마다 비교를 수행한다. useCallback에 전달된 인라인 함수도 매 렌더마다 새로 생성되지만, 캐시된 버전이 반환되면 즉시 버려진다.

결과적으로, 기술적으로는 내부에 약간의 오버헤드가 생긴다. 하지만 나는 이 오버헤드에 너무 집중하고 싶진 않다. 왜냐하면 진짜 문제는 그게 아니기 때문이다.

function OhNo({ onChange }) {
  const handleChange = useCallback((e: React.ChangeEvent) => {
    trackAnalytics('changeEvent', e)
    onChange?.(e)
  }, [onChange])

  return <SomeMemoizedComponent onChange={handleChange} />
}

<OhNo onChange={() => props.doSomething()} />​

이건 무해한 사용 사례다. 전혀 문제될 게 없다.
사실 오히려 좋은 패턴이라고 볼 수 있다.
이벤트 핸들러와 관련된 동작을 한곳에 모아두어, 파일 상단으로 끌어올려서 길게 이름 붙인 handleChange 같은 함수를 만드는 일을 피할 수 있다.

이 코드를 작성한 개발자가 메모이제이션이 깨진다는 사실을 알 수 있는 유일한 방법은, 컴포넌트 내부를 깊이 파고 들어가 props가 어떻게 사용되는지 확인하는 것뿐이다.
솔직히 말해, 그건 끔찍하다.

다른 해결책으로는 “모든 걸 항상 메모이제이션한다”라는 정책을 세우거나,
참조 안정성이 필요한 props에는 mustBeMemoized 같은 엄격한 네이밍 규칙을 적용하는 방법이 있다.
하지만 이 둘 다 좋은 방법은 아니다.

실제 사례(Real Life Example)

지금 나는 Sentry 코드베이스에서 작업하고 있는데, 이건 오픈소스라서 🎉 실제 사용 사례를 쉽게 보여줄 수 있다.

내가 발견한 한 가지 상황은 useHotkeys 커스텀 훅이다.
핵심 부분은 대략 이렇게 생겼다:

useHotkeys

export function useHotkeys(hotkeys: Hotkey[]): {
  const onKeyDown = useCallback(() => ..., [hotkeys])

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [onKeyDown])
}

이 커스텀 훅은 hotKeys 배열을 인자로 받고,
그걸 기반으로 onKeyDown 함수를 메모이제이션한 뒤, 해당 함수를 effect에 넘긴다.

함수를 메모이제이션하는 이유는 명백하다: Effect가 너무 자주 실행되는 것을 방지하기 위해서다.

하지만 입력값인 hotkeys가 배열이기 때문에, 사용하는 쪽에서 직접 hotkeys를 메모이제이션해주어야 한다.

그래서 나는 useHotkeys가 실제 코드에서 어떻게 쓰이고 있는지 전수 조사를 해봤다.
놀랍게도 거의 대부분(한 곳을 제외하고)은 입력값을 메모이제이션하고 있었다.

하지만 이야기는 여기서 끝나지 않는다.
더 깊이 들어가 보면, 결국에는 여전히 문제가 생기기 쉬운 구조라는 걸 알 수 있다.
예를 들어, 다음과 같은 사용 사례를 보자.

paginateHotKeys

const paginateHotkeys = useMemo(() => {
  return [
    { match: 'right', callback: () => paginateItems(1) },
    { match: 'left', callback: () => paginateItems(-1) },
  ]
}, [paginateItems])

useHotkeys(paginateHotkeys)

useHotKeys는 메모이제이션된 paginateHotkeys를 전달한다.
그런데 이 paginateHotkeys는 paginateItems에 의존한다.

그럼 paginateItems는 어디서 올까?

바로 또 다른 useCallback이고, 이 콜백은 screenshots와 currentAttachmentIndex에 의존한다.

그렇다면 screenshots는 어디서 오는 걸까?

breaking-memoization

const screenshots = attachments.filter(({ name }) =>
  name.includes('screenshot')
)

screenshots는 메모이제이션되지 않은 attachments.filter 함수에서 생성된다.
이 함수는 매번 새로운 배열(Array)을 생성하므로, downstream에 있는 모든 메모이제이션이 깨진다.

결과적으로 모든 메모이제이션이 무용지물이 된다.

즉, paginateItems, paginateHotkeys, onKeyDown
이 세 가지 메모이제이션이 매 렌더링마다 다시 실행되며,
마치 아예 작성하지 않은 것과 동일한 상황이 된다! (이렇게 되면 우리가 했던 메모이제이션은 전부 무용지물이 된다)

이 예시가 내가 왜 메모이제이션 적용에 반대하는 입장인지 잘 보여줬으면 한다.
내 경험상, 메모이제이션은 너무 자주 깨지고, 그럴 가치가 없다.

게다가 코드 전체에 엄청난 오버헤드와 복잡성을 추가한다.

여기서 해결책이 screenshots까지 메모이제이션하는 것은 아니다.

그렇게 하면 책임이 결국 컴포넌트의 prop인 attachments로 넘어가게 된다.
세 가지 호출 지점(call-side) 모두에서 실제로 메모이제이션이 필요한 useHotkeys와는 최소 두 단계 이상 떨어져 있게 된다.

이건 코드를 탐색하기 악몽 같은 상황을 만들며, 결국 아무도 메모이제이션 하나를 제거하지 못하게 된다.
왜냐하면 그 메모이제이션이 실제로 무엇을 하고 있는지 알 수 없기 때문이다.

실제로는, 이런 문제를 해결하려면 컴파일러에게 모든 걸 맡기는 것이 가장 좋다.

모든 환경에서 잘 작동한다면 정말 훌륭하다.
하지만 그 전까지는, 참조 안정성(referential stability) 필요성의 한계를 우회할 패턴을 찾아야 한다.

최신 Ref 패턴(The Latest Ref Pattern)

이 패턴에 대해서는 이전에 언급한 적이 있다.
핵심 아이디어는, Effect 안에서 즉시 접근하고 싶은 값을 ref 안에 저장해두고,
또 다른 Effect를 통해 의도적으로 매 렌더링마다 값을 업데이트하는 것이다.

the-latest-ref

export function useHotkeys(hotkeys: Hotkey[]): {
  const hotkeysRef = useRef(hotkeys)

  useEffect(() => {
    hotkeysRef.current = hotkeys
  })

  const onKeyDown = useCallback(() => ..., [])

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [])
}

그렇게 하면 hotkeysRef를 Effect 안에서 바로 사용할 수 있다.
의존성 배열에 추가할 필요도 없고, 단순히 린터를 무시하다가 발생할 수 있는 stale closure 문제도 걱정하지 않아도 된다.

실제로 React Query도 이 패턴을 사용한다.

예를 들어 PersistQueryClientProvider나 useMutationState에서 최신 옵션(latest options)을 추적할 때 그렇다.
즉, 검증된(tried-and-true) 패턴이라고 볼 수 있다.
만약 라이브러리가 사용자가 옵션을 직접 메모이제이션하도록 강제한다면 얼마나 귀찮을지 상상해보라.

UseEffectEvent

좋은 소식이 하나 더 있다.
React 팀은 대부분의 경우, 리액티브 Effect 안에서 최신 값을 명령형(imperative)으로 접근할 필요가 있지만, Effect를 명시적으로 다시 실행하고 싶지 않은 상황이 있다는 것을 인식했다.

그래서 이 패턴을 위한 1급 프리미티브(first-class primitive), useEffectEvent를 새로 추가할 예정이다.

이 훅이 도입되면, 기존 코드를 보다 깔끔하고 안전하게 리팩터링할 수 있게 된다:

the-latest-ref

export function useHotkeys(hotkeys: Hotkey[]): {
  const onKeyDown = useEffectEvent(() => ...)

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [])
}