React 성능 문제는 보통 렌더링이 아니라 State에서 시작됩니다

Source: Dev.to

왜 상태 설계가 성능 문제의 근원인가

React 애플리케이션이 느려지기 시작하면, 본능적으로 최적화 도구—메모이제이션, useCallback, useMemo, 프로파일링 세션—에 손을 뻗게 된다. 이러한 도구들은 유용하지만, 실제 문제의 시작점은 거의 여기서가 아니다. 대부분의 React 성능 문제는 렌더링 자체가 아니라 상태 설계에서 비롯된다.

React는 재렌더링을 매우 잘한다; 렌더링은 저렴하다. 비용이 많이 드는 것은 무엇이 재렌더링을 트리거하는가와 트리의 어느 정도가 영향을 받는가이다. 상태가 너무 높은 레벨에 끌어올려지거나, 과도하게 결합되었거나, 간접적으로 변형될 때, 작은 변화가 애플리케이션의 큰 부분에 파장을 일으킬 수 있다.

흔히 보이는 증상

전역 또는 최상위 레벨 상태

자주 나타나는 증상은 자주 변하는 전역 혹은 최상위 레벨 상태이다. 많은 컴포넌트가 동일한 상태 조각에 의존하면, React는 대부분의 컴포넌트가 실제로 변화에 관심이 없더라도 큰 서브트리를 재평가해야 한다. 결과는 렌더링 문제처럼 보이지만, 실제로는 데이터 소유권 문제이다.

조기 최적화

메모이제이션을 너무 일찍 적용하면, 근본 원인을 해결하지 못하고 복잡성만 증가시킨다. 의존성 관리, 오래된 값, 정신적 부담을 초래하며, 모두 불분명한 상태 경계에 대한 보상책에 불과하다.

상태 소유권에 대한 모범 사례

• 상태를 사용되는 곳에 가깝게 두라. 상태는 읽거나 쓰는 컴포넌트에 가능한 한 가깝게 위치해야 한다.
• 데이터를 로컬에서 파생시키라 전역에 저장하기보다 필요로 하는 컴포넌트 내부에서 파생값을 계산한다.
• 자유로운 재렌더링을 허용하라. 컴포넌트가 격리되고 가벼운 렌더링을 갖는다면, 재렌더링 비용은 무시할 수준이다.

도움이 되는 사고 전환

“이 컴포넌트가 재렌더링되지 않게 하려면 어떻게 해야 할까?” 대신에 “왜 이 상태 변화가 앱 전체에 이렇게 큰 영향을 미치는가?” 라고 물어보라. 답은 보통 직접적인 해결책을 가리킨다: 상태를 리팩터링해서 실제로 필요로 하는 컴포넌트만 그 변화에 구독하도록 만든다.

아키텍처적 초점

React 성능은 크게 아키텍처 문제이다. 상태 소유권과 데이터 흐름을 올바르게 잡으면, 렌더링은 스스로 해결되는 경우가 많다.