브라우저 렌더링 엔진의 무거운 발걸음
웹 브라우저가 화면을 그리는 과정은 꽤 많은 연산이 수반됩니다. HTML을 파싱해 DOM 트리를 만들고, CSS를 파싱해 CSSOM 트리를 생성한 뒤 두 개를 합쳐 Render 트리를 구성합니다. 이어서 요소들의 크기와 위치를 정하는 Layout(Reflow)과 실제 픽셀을 채우는 Paint(Repaint) 과정을 겪습니다.
문제는 자바스크립트로 직접 DOM 노드를 자주 추가하거나 삭제할 때마다 이러한 렌더링 파이프라인 전체가 반복 실행되면서 심각한 병목 현상이 발생한다는 것입니다.
가상 DOM(Virtual DOM)의 등장
React는 실제 DOM 조작 대신 메모리 상의 가상의 DOM 트리를 운용하는 영리한 방식을 택했습니다. UI 상태 변화가 감지되면, 먼저 메모리 공간 내의 가상 DOM을 완전히 새로 작성합니다.
그다음 이전의 가상 DOM과 현재 가상 DOM을 비교 분석(Diffing)하여 실제로 변경 사항이 생긴 최소한의 차이 요소만 추려냅니다. 그리고 이 변화된 부분만 실제 DOM에 일괄 전달(Batch Update)하여 브라우저의 레이아웃 재연산을 단 한 번으로 일괄 압축합니다.
리액트의 최적화 핵심 요약
가상 DOM은 단순히 연산의 속도 자체를 물리적으로 높이기보다는, 개발자가 브라우저 렌더링 최적화 로직을 직접 복잡하게 구현하지 않더라도 선언적이고 안전한 고성능 컴포넌트 라이프사이클을 즐길 수 있게 프레임워크 수준에서 선제 관리해 준다는 데 가치가 있습니다.
가상 DOM을 오해하지 않는 법
가상 DOM은 항상 실제 DOM보다 빠르다는 뜻이 아닙니다. 핵심은 UI를 선언적으로 작성하면서 변경 범위를 예측 가능하게 만들고, 프레임워크가 업데이트를 묶어서 처리할 수 있게 한다는 점입니다.
성능 저하를 막는 습관
- 목록 렌더링에서는 안정적인
key를 사용해 불필요한 재생성을 줄입니다. - 부모 상태 변경으로 모든 자식이 다시 계산되는 구조를 피합니다.
- 측정 없이
memo를 남발하지 말고, Profiler로 병목 컴포넌트를 먼저 찾습니다.
React 성능 최적화는 DOM 이론보다 상태 설계에서 더 많이 갈립니다. 데이터 흐름이 단순하면 렌더링 비용도 자연스럽게 예측 가능해집니다.
참고 자료와 업데이트 기준
이 글은 실무 적용 관점에서 작성했으며, 관련 기술의 공식 문서와 브라우저 지원 현황이 바뀌면 내용을 다시 점검합니다. 특히 프레임워크 버전, API 정책, 성능 측정 방식은 시간이 지나며 달라질 수 있으므로 배포 전에는 최신 문서를 함께 확인하는 것을 권장합니다.
- MDN Web Docs에서 웹 표준과 브라우저 동작을 확인합니다.
- web.dev에서 성능, 접근성, 사용자 경험 기준을 확인합니다.
- React 공식 문서에서 React 관련 API와 권장 패턴을 확인합니다.
