비교할 문제
memo 오용에서 확인할 질문은 React memo의 prop 비교 비용보다 건너뛴 render 비용이 큰 조건은 무엇인가입니다. memo 적용 전후 UI, event와 state update 결과를 같게 하고 stable prop과 매번 새로 만든 prop을 분리합니다. 결과값, 순서, 오류 처리와 부수 효과가 다르면 같은 성능 비교가 아닙니다. 먼저 두 후보가 같은 일을 하는지 작은 입력으로 확인합니다.
원인 분석과 재현
memo는 prop 비교 비용을 추가하는 성능 최적화이며 state·context update와 correctness 문제를 막는 장치가 아닙니다.
child render 비용을 작음·큼으로, prop 변경률을 0%·10%·100%로 나눠 production profiling build의 actualDuration과 commit 수를 봅니다. runtime version, 운영체제, CPU와 memory 제한도 결과와 함께 기록합니다.
비교 질문은 React memo의 prop 비교 비용보다 건너뛴 render 비용이 큰 조건은 무엇인가입니다.
| 후보 | 유리한 조건 | 함께 치르는 비용 |
|---|---|---|
| memo 없음 | render가 싸거나 prop이 자주 바뀜 | parent update마다 child render |
| memo | render가 비싸고 prop이 자주 같음 | 매 update의 shallow comparison과 복잡성 |
| state·component 경계 조정 | 불필요한 update source를 구조적으로 좁힘 | component API 재설계 비용 |
<Profiler id="Results" onRender={(_, phase, actualDuration, baseDuration) => {
metrics.push({ phase, actualDuration, baseDuration });
}}>
<Results items={items} />
</Profiler>
해결 방안과 판정
warm-up과 측정 구간을 나누고 여러 번 반복합니다. 서비스 지연은 median과 p95를, 처리량 비교는 단위 시간당 완료 수와 오류율을 함께 기록합니다. CPU time, allocation, RSS·heap, GC, I/O 중 이 작업에 직접 관련된 지표만 선택합니다. memoization은 correctness 장치가 아닙니다. prop이 대부분 바뀌거나 render가 싸면 비교 비용과 복잡성만 늘 수 있으므로 실제 interaction에서 반복 개선되는지 봅니다.
차이가 반복 실행의 흔들림보다 작다면 더 단순하고 읽기 쉬운 구현을 선택합니다. 차이가 충분히 크더라도 실제 요청 전체의 지연과 자원 사용이 개선되는지 확인한 뒤 적용합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.