등장 배경

앞의 브라우저 동작 원리, Reflow, Repaint, Layer, Composite 글에서 언급했던 내용이다. Virtual DOM이 왜 등장했는지 이해하려면 DOM이 어떻게 화면에 그려지고 변화가 발생할 때 어떻게 내부적으로 동작하는지 알면 이해하기 수월하다.

옛날 정적인 페이지에서는 직접 DOM 을 컨트롤해도 문제가 없었다.
SPA가 등장하고 거대한 프로젝트들이 등장하면서 몇번의 DOM 컨트롤로 발생하는 layout(reflow), paint(repaint) 과정에서 성능을 저하시키기 시작했다.

즉, DOM 조작에 대한 복잡도가 증가하고 있으며 DOM 변화가 아주 많이 발생한다는 것.

Virtual DOM

그래서 Virtual DOM은 뭐냐
Real DOM을 추상화한 가상의 객체, Real DOM의 사본이라 생각하면 된다. DOM을 조작하는 액션이 발생하면 새 Virtual DOM을 만들고 이전 상태의 Virtual DOM과 비교해서 변경된 사항을 한번에 묶어서 실제 DOM에 반영하는 것이다.
Virtual DOM은 메모리에 저장돼있어 변화를 비교하는데 빠르기도하다.
예를 들어, DOM 1000개에 대한 변화가 생겼다. 그럼 reflow, repaint 과정을 1000번해야한다. 하지만 Virtual DOM을 적용하면 한번의 reflow, repaint의 양은 커지겠지만, 한번만 수행하면 되기에 훨씬 성능이 최적화 된다.

근데 작은 규모 프로젝트에서는 Virtual DOM으로 얻는 성능 이점이 크진 않다. React, Vue 등 프레임워크의 다른 기능들에서 얻는 개발 편의성과 속도는 있겠지만, Virtual DOM 한정해서 생각해보면 성능 이점은 크지 않을 것 같다.