맞습니다. useCallback 버전이 좀 더 많은 일을 한다는 것 빼고 두 코드는 정확히 같습니다. 함수를 정의해야 하는 것 뿐만 아니라 배열을 정의하고 프로퍼티를 설정하고 논리적인 표현을 통해 실행되는 React.useCallback을 호출해야 합니다.
따라서 두 가지 경우 모두 JavaScript는 렌더링 때마다 함수 정의에 대한 메모리를 할당해야 하고 어떻게 useCallback이 구현되는지에 따라 함수 정의에 대해 더 많은 할당이 필요할 수 있습니다. (이 경우에 해당하지는 않지만 제 말의 요점은 여전합니다) 제가 트위터 투표를 통해 전달하고자 했던 내용은 다음과 같습니다.
정답을 알고 있지만 제가 말을 서툴게 해서 틀린 답을 선택하셨다면 죄송합니다.
컴포넌트의 두 번째 렌더링 때 원래 있던 dispense 함수는 가비지 콜렉터가 수집하고(메모리 공간도 풀리죠) 새로운 함수가 생성될 것입니다. 그러나 useCallback를 사용하게 되면 원래 있던 dispense 함수는 수집되지 않고 새로운 함수가 생성되므로 메모리 측면에서도 좋지 않다는 것을 말씀드리고 싶었습니다.
관련해서 useCallback의 dependency가 있는 경우 React가 이전 함수에 대한 참조로 그 값들을 계속 가지고 있을 겁니다. 메모이제이션은 이전에 주어졌던 dependency 값들이 동일한 경우 이전 값들을 그대로 리턴해주기 때문입니다.특히 눈치가 빠른 분들이라면 React가 dependency 값들의 동일성 체크를 위해 해당 값들의 참조를 가지고 있어야 한다는 것을 알아차리셨을 겁니다.
그렇다면 useMemo는 어떻게 다른가요?
useMemo는 함수 뿐만 아니라 어떤 타입의 값이든 메모이제이션을 할 수 있다는 것 외에 useCallback과 유사합니다. 값을 반환하는 함수를 받으면 함수는 값이 반환되어야 할 때만 호출됩니다. (보통 렌더 시 dependency 배열 내 값들이 변경될 때마다 한번 발생합니다.)
그래서 렌더링 때마다 initialCandies 배열을 다시 만들기 싫다면 이렇게 코드를 바꾸어야 합니다.
그러나 값들이 props로 넘어오거나 함수 바디에서 초기화되는 다른 값들이 필요하면 이렇게 작성할 수 없을 겁니다.
제가 말하고자 하는 바는 결국 코드를 최적화할 때 얻는 베네핏이 매우 미미하기 때문에 어떻게 프로젝트를 개선할 수 있을지를 생각하는 것이 더 낫다는 것입니다.
그래서 요점이 뭔가요?
결국 이 글의 요점을 말씀드리자면, 성능 최적화는 공짜가 아닙니다. 성능 최적화는 언제나 비용을 동반하지만 항상 비용만큼의 베네핏을 가져다주는 것은 아니라는 겁니다.
그러니 책임감을 갖고 최적화하세요.
그럼 언제 useMemo와 useCallback을 사용해야 하나요?
두 hook이 React에 내장되어 있는 분명한 이유가 있습니다.
참조 동일성 (Referential equality)
비용이 많이 드는 연산 (Computationally expensive calculations)
참조 동일성 (Referential equality)
여러분이 JavaScript나 프로그래밍 초보라 할지라도, 왜 이런 결과가 나오는지 금방 알 겁니다.
true === true // true
false === false // true
1 === 1 // true
'a' === 'a' // true
{} === {} // false
[] === [] // false
() => {} === () => {} // false
const z = {}
z === z // true
// NOTE: React actually uses Object.is, but it's very similar to ===
이 코드에 대해 깊게 얘기하지는 않게지만, 여러분이 React 함수형 컴포넌트 내부에서 객체를 선언할 때 같은 객체가 정의된 마지막 시간과 참조가 동일하지 않을 겁니다. (동일한 프로퍼티과 값을 가지고 있다고 해도 말이죠.)
React에서 참조 동일성이 중요한 두 가지 상황이 있는데 하나씩 살펴봅시다.
Dependencies Lists
다음 예시를 봅시다.
경고 : 부자연스러운 코드가 보이더라도 컨셉에 집중해주세요!
function Foo({bar, baz}) {
const options = {bar, baz}
React.useEffect(() => {
buzz(options)
}, [options]) // we want this to re-run if bar or baz change
return <div>foobar</div>
}
function Blub() {
return <Foo bar="bar value" baz={3} />
}
이 코드가 문제인 이유는 useEffect가 렌더링 시점마다 options에 대한 참조 동일성 확인을 해야 하고 JavaScript의 동작 방식에 의해 options는 모든 시점에서 새로운 참조를 갖기 때문입니다. 그러면 결국 React는 항상 options가 변경되었다고 평가할 겁니다. 그렇다면 useEffect의 콜백함수는 bar와 baz가 변경될 때만 호출되는 것이 아니라 매 렌더링 때마다 호출됩니다.
이 문제를 해결하는 두 가지가 있습니다.
// option 1
function Foo({bar, baz}) {
React.useEffect(() => {
const options = {bar, baz}
buzz(options)
}, [bar, baz]) // we want this to re-run if bar or baz change
return <div>foobar</div>
}
이 방법은 아주 좋습니다. 실제로 제가 해결한 방법이죠.
그러나 이 방법으로 해결할 수 없는 한 가지 상황이 있습니다. bar나 baz가 원시값이 아닌 객체/배열/함수 등일 때입니다.
여러분이 버튼을 클릭할 때마다 DualCounter의 상태값은 변경되어 리렌더링이 발생하여 CountButton 컴포넌트들도 리렌더링됩니다. 그러나 실제로는 클릭된 버튼만 다시 렌더링이 되어야 하지 않을까요? 첫 번째 버튼을 클릭했을 때, 두 번째 버튼이 다시 렌더링되는데 변경되는 것은 없습니다. 우리는 이런 상황을 "불필요한 리렌더"라고 합니다.
불필요한 렌더링을 최적화하는데 너무 많은 시간을 쓰지 마세요. React는 굉장히 빠르기 때문에 이것을 최적화하는 것보다 더 중요한 일들이 많습니다. 실제로 Paypal 제품을 작업하는 3년동안 말 그대로 3년동안, 그리고 React로 작업한 기간동안 할 필요가 없었답니다.
그러나 인터랙티브한 그래프, 차트, 애니메이션 등 렌더링에 많은 시간이 소요되는 경우가 있습니다. 다행히 React의 실용주의적인 특성 덕분에 비상구가 존재합니다.
이제 React는 props가 변경될 때 CountButton만을 리렌더링 할 겁니다! 그러나 아직 할 일이 남았습니다. 아까 얘기했던 참조 동일성을 기억하시나요? DualCounter 컴포넌트에서 increment1과 increment2 함수를 정의했는데, DualCounter가 리렌더링될 때마다 이 함수들은 새로 생성되어 CountButton들을 다시 렌더링하게 될 겁니다.
이제 우리는 CountButton 컴포넌트의 "불필요한 리렌더링"을 피할 수 있게 됐습니다.
다시 말하지만 저는 React.memo(나 비슷한 PureComponent, ShouldComponentUpdate)를 기준없이 사용하지 않는 것을 권고합니다. 최적화를 했을 때의 비용과 얻을 수 있는 이점이 있는지 확인하는 것이 필요합니다. 위에서 살펴본 것처럼 최적화를 했을 때 얻는 이점이 없을 수도 있습니다.
비용이 많이 드는 연산
React에서 useMemo가 내장된 또 다른 이유가 있습니다.(useCallback은 해당되지 않습니다.) useMemo의 장점은 아래처럼 값을 사용할 수 있다는 겁니다.
const a = {b: props.b}
이 값을 lazy하게 해볼까요.
const a = React.useMemo(() => ({b: props.b}), [props.b])
이것은 위의 케이스처럼 유용한 것은 아니지만 여러분이 동기적으로 복잡한 값을 계산하는 함수가 있다고 가정해보세요.
이 방법이 효과적인 이유는 모든 렌더링 때마다 소수를 계산하는 함수를 정의했다고 하더라도 React는 필요한 값이 있을 때만 함수를 호출한다는 겁니다. React는 이전의 값들을 저장하고 같은 입력값이 들어오면 이전 값들을 반환합니다. 메모이제이션이 동작하는 방식입니다.
결론
모든 추상화(와 성능 최적화)는 비용이 든다는 사실을 말씀드리면서 글을 마무리하고자 합니다. AHA 프로그래밍 원칙을 적용하고 추상화/최적화가 정말 필요할 때만 적용시킨다면 이점이 없이 비용만 드는 상황에서 벗어날 수 있을 겁니다.
특히 useCallback과 useMemo는 여러분의 코드를 복잡하게 만드는 비용을 가집니다. 또한 dependencies 배열에 실수를 한다면 여러분은 내장된 hooks을 호출하거나 가비지 콜렉터가 값을 수집하지 못하게 하여 성능을 나쁘게 만들 수도 있습니다. 얻고자 하는 이익이 있을 때 발생하는 비용은 괜찮지만, 먼저 확인해보는 것이 중요합니다.
추신. 여러분이 hook으로 옮기는 것과 클래스로 선언하던 것들을 함수형 컴포넌트로 정의해야 하는 거에 걱정하고 있는 분 중에 한 명이라면 메소드를 render 단계에서 정의하고 있었다는 사실을 고려해보시길 권합니다.
class FavoriteNumbers extends React.Component {
render() {
return (
<ul>
{this.props.favoriteNumbers.map(number => (
// TADA! This is a function defined in the render method!
// Hooks did not introduce this concept.
// We've been doing this all along.
<li key={number}>{number}</li>
))}
</ul>
)
}
}
성능최적화는 언제나 비용이 들지만 항상 좋은 건 아닙니다. useMemo와 useCallback의 비용과 장점에 대해 이야기해봅시다.
여기에 사탕 디스펜서가 있습니다.
어떻게 구현했는지 봅시다.
그럼 이제 여러분들에게 질문을 할 겁니다. 앞으로 나아가기 전에 여러분들이 제 질문에 대해 잘 생각해보길 바랍니다. 이 코드를 수정할 건데 어떤 것이 더 나은 성능을 가질 수 있는지 알려주세요.
제가 바꿀 것은
dispense
함수는React.useCallback
으로 감싸는 것입니다.원래 코드는 이렇습니다.
이 상황에서 원래 코드와 변경된 코드 중 어떤 것이 성능에 더 좋을까요? 여러분의 생각을 알려주세요.
왜
useCallback
을 쓰는게 더 안좋은가요?성능을 향상시키고 "인라인 함수는 성능에 문제가 있다"고 하기 때문에
React.useCallback
을 사용해야 한다고 많이 들으셨을 겁니다. 그런데 왜useCallback
을 사용하지 않는게 왜 더 좋은 코드일까요?아까 봤던 예시에서 한 발짝 물러나 React 코드를 작성할 때도 실행되는 코드의 모든 라인은 비용이 든다는 점을 고려하세요. 이제
useCallback
예시를 명확하게 설명하고자 좀 더 살펴보겠습니다. (실제 변화는 없지만 약간의 이동만 합니다)원본 코드를 다시 보여드리죠.
두 코드에 대해 뭔가 알아차리셨나요? 차이점을 살펴봅시다.
맞습니다.
useCallback
버전이 좀 더 많은 일을 한다는 것 빼고 두 코드는 정확히 같습니다. 함수를 정의해야 하는 것 뿐만 아니라 배열을 정의하고 프로퍼티를 설정하고 논리적인 표현을 통해 실행되는React.useCallback
을 호출해야 합니다.따라서 두 가지 경우 모두 JavaScript는 렌더링 때마다 함수 정의에 대한 메모리를 할당해야 하고 어떻게
useCallback
이 구현되는지에 따라 함수 정의에 대해 더 많은 할당이 필요할 수 있습니다. (이 경우에 해당하지는 않지만 제 말의 요점은 여전합니다) 제가 트위터 투표를 통해 전달하고자 했던 내용은 다음과 같습니다.컴포넌트의 두 번째 렌더링 때 원래 있던
dispense
함수는 가비지 콜렉터가 수집하고(메모리 공간도 풀리죠) 새로운 함수가 생성될 것입니다. 그러나useCallback
를 사용하게 되면 원래 있던dispense
함수는 수집되지 않고 새로운 함수가 생성되므로 메모리 측면에서도 좋지 않다는 것을 말씀드리고 싶었습니다.관련해서
useCallback
의 dependency가 있는 경우 React가 이전 함수에 대한 참조로 그 값들을 계속 가지고 있을 겁니다. 메모이제이션은 이전에 주어졌던 dependency 값들이 동일한 경우 이전 값들을 그대로 리턴해주기 때문입니다.특히 눈치가 빠른 분들이라면 React가 dependency 값들의 동일성 체크를 위해 해당 값들의 참조를 가지고 있어야 한다는 것을 알아차리셨을 겁니다.그렇다면
useMemo
는 어떻게 다른가요?useMemo
는 함수 뿐만 아니라 어떤 타입의 값이든 메모이제이션을 할 수 있다는 것 외에useCallback
과 유사합니다. 값을 반환하는 함수를 받으면 함수는 값이 반환되어야 할 때만 호출됩니다. (보통 렌더 시 dependency 배열 내 값들이 변경될 때마다 한번 발생합니다.)그래서 렌더링 때마다
initialCandies
배열을 다시 만들기 싫다면 이렇게 코드를 바꾸어야 합니다.그러면 그 문제는 피할 수 있겠지만, 저장된 값들이 너무 작아서 코드를 복잡하게 하는 것만큼의 가치가 있지 않습니다. 사실 이렇게
useMemo
를 사용하면 함수를 호출하면서 프로퍼티 할당 등을 해야 하기 때문에 좋지 않습니다.이 예시에서는 이렇게 코드를 바꾸는 것이 좋습니다.
그러나 값들이 props로 넘어오거나 함수 바디에서 초기화되는 다른 값들이 필요하면 이렇게 작성할 수 없을 겁니다.
제가 말하고자 하는 바는 결국 코드를 최적화할 때 얻는 베네핏이 매우 미미하기 때문에 어떻게 프로젝트를 개선할 수 있을지를 생각하는 것이 더 낫다는 것입니다.
그래서 요점이 뭔가요?
결국 이 글의 요점을 말씀드리자면, 성능 최적화는 공짜가 아닙니다. 성능 최적화는 언제나 비용을 동반하지만 항상 비용만큼의 베네핏을 가져다주는 것은 아니라는 겁니다.
그러니 책임감을 갖고 최적화하세요.
그럼 언제
useMemo
와useCallback
을 사용해야 하나요?두 hook이 React에 내장되어 있는 분명한 이유가 있습니다.
참조 동일성 (Referential equality)
여러분이 JavaScript나 프로그래밍 초보라 할지라도, 왜 이런 결과가 나오는지 금방 알 겁니다.
이 코드에 대해 깊게 얘기하지는 않게지만, 여러분이 React 함수형 컴포넌트 내부에서 객체를 선언할 때 같은 객체가 정의된 마지막 시간과 참조가 동일하지 않을 겁니다. (동일한 프로퍼티과 값을 가지고 있다고 해도 말이죠.)
React에서 참조 동일성이 중요한 두 가지 상황이 있는데 하나씩 살펴봅시다.
Dependencies Lists
다음 예시를 봅시다.
이 코드가 문제인 이유는
useEffect
가 렌더링 시점마다options
에 대한 참조 동일성 확인을 해야 하고 JavaScript의 동작 방식에 의해options
는 모든 시점에서 새로운 참조를 갖기 때문입니다. 그러면 결국 React는 항상options
가 변경되었다고 평가할 겁니다. 그렇다면useEffect
의 콜백함수는bar
와baz
가 변경될 때만 호출되는 것이 아니라 매 렌더링 때마다 호출됩니다.이 문제를 해결하는 두 가지가 있습니다.
이 방법은 아주 좋습니다. 실제로 제가 해결한 방법이죠.
그러나 이 방법으로 해결할 수 없는 한 가지 상황이 있습니다.
bar
나baz
가 원시값이 아닌 객체/배열/함수 등일 때입니다.이런 경우가
useCallback
과useMemo
의 존재 이유를 보여주는 때입니다. 어떻게 수정할까요?참고로
useEffect
,useLayoutEffect
,useCallback
,useMemo
에 사용되는 dependencies 배열에 동일하게 적용됩니다.React.memo
이 코드를 볼까요?
여러분이 버튼을 클릭할 때마다
DualCounter
의 상태값은 변경되어 리렌더링이 발생하여CountButton
컴포넌트들도 리렌더링됩니다. 그러나 실제로는 클릭된 버튼만 다시 렌더링이 되어야 하지 않을까요? 첫 번째 버튼을 클릭했을 때, 두 번째 버튼이 다시 렌더링되는데 변경되는 것은 없습니다. 우리는 이런 상황을 "불필요한 리렌더"라고 합니다.불필요한 렌더링을 최적화하는데 너무 많은 시간을 쓰지 마세요. React는 굉장히 빠르기 때문에 이것을 최적화하는 것보다 더 중요한 일들이 많습니다. 실제로 Paypal 제품을 작업하는 3년동안 말 그대로 3년동안, 그리고 React로 작업한 기간동안 할 필요가 없었답니다.
그러나 인터랙티브한 그래프, 차트, 애니메이션 등 렌더링에 많은 시간이 소요되는 경우가 있습니다. 다행히 React의 실용주의적인 특성 덕분에 비상구가 존재합니다.
이제 React는 props가 변경될 때
CountButton
만을 리렌더링 할 겁니다! 그러나 아직 할 일이 남았습니다. 아까 얘기했던 참조 동일성을 기억하시나요?DualCounter
컴포넌트에서increment1
과increment2
함수를 정의했는데,DualCounter
가 리렌더링될 때마다 이 함수들은 새로 생성되어CountButton
들을 다시 렌더링하게 될 겁니다.이런 경우가
useCallback
과useMemo
가 도움이 되는 또 다른 상황입니다.이제 우리는
CountButton
컴포넌트의 "불필요한 리렌더링"을 피할 수 있게 됐습니다.다시 말하지만 저는
React.memo
(나 비슷한PureComponent
,ShouldComponentUpdate
)를 기준없이 사용하지 않는 것을 권고합니다. 최적화를 했을 때의 비용과 얻을 수 있는 이점이 있는지 확인하는 것이 필요합니다. 위에서 살펴본 것처럼 최적화를 했을 때 얻는 이점이 없을 수도 있습니다.비용이 많이 드는 연산
React에서
useMemo
가 내장된 또 다른 이유가 있습니다.(useCallback
은 해당되지 않습니다.)useMemo
의 장점은 아래처럼 값을 사용할 수 있다는 겁니다.이 값을 lazy하게 해볼까요.
이것은 위의 케이스처럼 유용한 것은 아니지만 여러분이 동기적으로 복잡한 값을 계산하는 함수가 있다고 가정해보세요.
iterations
나multiplier
를 생각해보면 연산 속도가 꽤 느릴 거라는 것을 알 수 있습니다. 이 문제에 대해 할 것은 딱히 없고, 하드웨어를 자동적으로 빠르게 만들 순 없습니다. 그러나 같은 값을 두 번 계산하지 않도록 할 수는 있습니다.이 방법이 효과적인 이유는 모든 렌더링 때마다 소수를 계산하는 함수를 정의했다고 하더라도 React는 필요한 값이 있을 때만 함수를 호출한다는 겁니다. React는 이전의 값들을 저장하고 같은 입력값이 들어오면 이전 값들을 반환합니다. 메모이제이션이 동작하는 방식입니다.
결론
모든 추상화(와 성능 최적화)는 비용이 든다는 사실을 말씀드리면서 글을 마무리하고자 합니다. AHA 프로그래밍 원칙을 적용하고 추상화/최적화가 정말 필요할 때만 적용시킨다면 이점이 없이 비용만 드는 상황에서 벗어날 수 있을 겁니다.
특히
useCallback
과useMemo
는 여러분의 코드를 복잡하게 만드는 비용을 가집니다. 또한 dependencies 배열에 실수를 한다면 여러분은 내장된 hooks을 호출하거나 가비지 콜렉터가 값을 수집하지 못하게 하여 성능을 나쁘게 만들 수도 있습니다. 얻고자 하는 이익이 있을 때 발생하는 비용은 괜찮지만, 먼저 확인해보는 것이 중요합니다.관련되어 읽어볼만한 것들입니다.
추신. 여러분이 hook으로 옮기는 것과 클래스로 선언하던 것들을 함수형 컴포넌트로 정의해야 하는 거에 걱정하고 있는 분 중에 한 명이라면 메소드를 render 단계에서 정의하고 있었다는 사실을 고려해보시길 권합니다.