비교할 문제
대형 목록 성능에서 확인할 질문은 대형 React 목록에서 계산 비용과 실제 DOM node 수 중 어느 쪽이 병목인가입니다. 동일한 row, 정렬, keyboard 이동과 screen reader 의미를 유지하고 initial render와 update interaction을 분리합니다. 결과값, 순서, 오류 처리와 부수 효과가 다르면 같은 성능 비교가 아닙니다. 먼저 두 후보가 같은 일을 하는지 작은 입력으로 확인합니다.
원인 분석과 재현
React 목록 성능은 render 계산뿐 아니라 DOM node 수와 commit 비용에 좌우되므로 profiler와 virtualization을 함께 검토해야 합니다.
row 100·10,000개, viewport에 보이는 row 20·100개에서 DOM node 수, commit duration, input latency와 memory를 기록합니다. runtime version, 운영체제, CPU와 memory 제한도 결과와 함께 기록합니다.
비교 질문은 대형 React 목록에서 계산 비용과 실제 DOM node 수 중 어느 쪽이 병목인가입니다.
| 후보 | 유리한 조건 | 함께 치르는 비용 |
|---|---|---|
| 전체 render | 작고 단순한 목록 | 화면 밖 DOM과 update 비용 |
| pagination | page 단위 탐색이 제품 요구에 맞음 | page 이동과 server query 계약 |
| virtualization | 연속 scroll하는 큰 목록 | 동적 높이, focus와 접근성 구현 비용 |
<Profiler id="Rows" onRender={(_, phase, actualDuration) => {
samples.push({ phase, actualDuration, renderedRows: visibleRows.length });
}}>
<Rows items={visibleRows} />
</Profiler>
해결 방안과 판정
warm-up과 측정 구간을 나누고 여러 번 반복합니다. 서비스 지연은 median과 p95를, 처리량 비교는 단위 시간당 완료 수와 오류율을 함께 기록합니다. CPU time, allocation, RSS·heap, GC, I/O 중 이 작업에 직접 관련된 지표만 선택합니다. memo는 DOM node 수를 줄이지 않습니다. profiler에서 render 계산과 commit을 나누고 실제 요구가 허용할 때 pagination·virtualization을 검토합니다.
차이가 반복 실행의 흔들림보다 작다면 더 단순하고 읽기 쉬운 구현을 선택합니다. 차이가 충분히 크더라도 실제 요청 전체의 지연과 자원 사용이 개선되는지 확인한 뒤 적용합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.