대규모 목록 렌더링 문제

1만 개의 항목으로 이루어진 배열을 순회해 각각 li 요소로 렌더링한다고 가정해 보겠습니다. 화면에는 한 번에 수십 개만 들어가더라도 React는 성실하게 DOM 노드 1만 개를 만듭니다.

대부분의 노드는 화면 밖에 있어 보이지 않지만, 브라우저는 여전히 모든 노드를 만들고 배치하며 관리해야 합니다.

브라우저는 대규모 DOM 트리에 실제 비용을 지불합니다. 레이아웃, 스타일 재계산, 메모리는 모두 노드 수에 따라 증가하므로, 지나치게 큰 목록은 초기 렌더링을 느리게 하고 메모리 사용량을 늘립니다.

엔진이 추적하고 다시 배치해야 할 노드가 수만 개에 이르면 간단한 상호 작용도 끊길 수 있습니다.

사용자가 가장 큰 불편을 느끼는 부분은 거대한 목록을 스크롤할 때입니다. 콘텐츠가 이동하면 브라우저가 다시 그리거나 레이아웃을 다시 계산할 수 있으며, 노드가 너무 많으면 프레임 속도가 매끄러운 수준 아래로 떨어집니다.

그 결과 스크롤이 끊기고 지연되어, 앱의 나머지 부분이 아무리 빨라도 인터페이스가 반응하지 않는 것처럼 느껴집니다.

페이지의 DOM 노드 수를 보여 주는 브라우저 DevTools 메모리 패널에서 이 문제를 확인할 수 있습니다. 수천 개의 노드를 만드는 목록은 이곳에 분명하게 나타납니다.

항목을 더 렌더링할수록 노드 수가 급증하는 모습을 관찰하면 DOM 크기가 병목이라는 구체적인 증거를 얻을 수 있습니다.

가상화는 윈도잉이라고도 하며, 전체 목록 대신 현재 보이는 항목과 작은 버퍼만 렌더링합니다. 스크롤하면 화면에 들어오는 항목은 마운트되고 화면에서 벗어나는 항목은 마운트 해제됩니다.

이렇게 하면 데이터에 항목이 몇 개 있든 실제 DOM을 작게 유지하여 DOM 크기와 데이터 집합 크기를 분리할 수 있습니다.

표시 영역은 스크롤 위치, 컨테이너 높이, 항목 높이에서 계산됩니다. 화면 영역의 높이를 항목 높이로 나누면 들어갈 수 있는 행의 대략적인 수를 알 수 있고, 스크롤 위치로 해당 행을 확인할 수 있습니다.

라이브러리는 이 수치를 사용해 어느 순간에 어떤 항목 조각을 정확히 렌더링할지 결정합니다.

윈도잉을 구현하는 라이브러리는 여러 가지가 있습니다. react-virtualized는 기능이 풍부하지만 규모가 더 크고, react-window는 같은 작성자가 만든 더 작고 목적이 분명한 재작성 버전이며, TanStack Virtual은 최신 헤드리스 옵션입니다.

대부분의 목록에서 react-window는 단순성과 성능의 균형이 뛰어나므로, 이 과정에서는 이를 중점적으로 다룹니다.

목록이 대략 수백 개 이상의 행으로 길거나, 이미지와 중첩 구성 요소로 행이 무거운 경우에는 가상화가 효과적입니다. 이런 경우에는 DOM 크기가 실제로 성능을 저해합니다.

무한 피드, 대규모 데이터 표, 채팅 기록은 윈도잉이 선택 사항이 아니라 필수가 되는 대표적인 상황입니다.

단순한 항목 몇십 개로 이루어진 짧은 목록에서는 가상화가 의미 있는 이점 없이 복잡성만 더합니다. 절대 위치 지정과 측정에 드는 비용 때문에 오히려 전체 성능이 나빠질 수도 있습니다.

윈도잉은 실제로 큰 데이터 집합에만 사용하고, 작은 데이터 집합에는 일반적인 배열 순회가 더 단순하면서도 충분히 빠릅니다.

윈도잉을 사용하면 항목 10만 개로 이루어진 목록도 화면에 보이는 소수의 항목만 DOM에 유지하므로 초기 렌더링이 빠르고 메모리 사용량이 적으며 스크롤이 부드럽습니다.

설정 과정에서 약간의 복잡성을 감수하는 대신 데이터의 양에 좌우되지 않는 성능을 얻을 수 있으며, 이것이 가상화의 핵심 약속입니다.

가상화가 유용한 시점을 판단해 보십시오.

DOM 노드를 수천 개 렌더링하면 레이아웃 비용과 메모리 사용량이 늘고 스크롤이 끊기며, DevTools의 노드 수를 통해 이를 확인할 수 있습니다. 가상화는 버퍼를 포함한 표시 영역만 렌더링하여 DOM을 작게 유지합니다.

react-window는 react-virtualized와 TanStack Virtual 중에서 목적이 분명하고 가벼운 선택지입니다. 크거나 무거운 목록에는 사용하고, 짧고 단순한 목록에는 사용하지 마십시오.