프론트엔드 개발에서는 일반적으로 직접적인 DOM 조작을 피하는 것이 권장됩니다. 그 이유를 이해하기 위해서는 DOM(Document Object Model)에 대한 이해가 필요합니다. DOM은 문서의 구조를 표현하는 트리 모델로, HTML 문서의 요소(element)들을 표현합니다.
직접적인 DOM 조작은 다음과 같은 이유로 지양되어야 합니다.
성능 문제: DOM 조작은 브라우저의 레이아웃 계산과 리페인트를 유발할 수 있습니다. 특히 대규모 애플리케이션에서는 이러한 작업이 성능에 부담을 줄 수 있습니다.
유지보수의 어려움: 직접 DOM을 조작하는 코드는 복잡하고 이해하기 어려울 수 있습니다. 또한 DOM 구조가 변경될 때마다 코드도 변경되어야 하므로 유지보수가 어려워집니다.
크로스 브라우징 문제: 각 브라우저는 DOM 조작에 대해 서로 다른 방식을 지원할 수 있습니다. 이로 인해 크로스 브라우징 이슈가 발생할 수 있습니다.
보안 취약점: 사용자 입력에 따라 동적으로 DOM을 조작하는 경우 XSS(Cross-Site Scripting) 공격에 취약해질 수 있습니다.
따라서, 현대의 프론트엔드 개발에서는 상태(state)와 뷰(view)를 분리하여 상태 관리 라이브러리 또는 프레임워크를 사용하여 상태를 관리하고, 이를 통해 자동으로 DOM을 업데이트하는 방식을 선호합니다. 이러한 방식은 성능을 최적화하고 유지보수성을 높이며, 보안 문제를 방지하는 데 도움이 됩니다.
과거에는 SPA 프레임워크가 흔하지 않았으며, 대부분의 웹 애플리케이션은 서버 측 렌더링(SSR)을 사용하여 HTML을 동적으로 생성하여 브라우저에 전달했습니다. 그래서 클라이언트 측에서는 DOM 조작보다는 HTML을 다시 로드하는 것이 일반적이었습니다.
이전에는 jQuery가 많이 사용되었습니다. jQuery는 DOM 조작을 단순화하고 편리하게 만들어 주었기 때문에 개발자들이 DOM 조작을 더 쉽게 할 수 있었습니다. 그래서 많은 퍼블리셔들이 jQuery를 즐겨 사용했던 것 같습니다.
그러나 jQuery를 사용하면서도 DOM 조작이 성능에 부정적인 영향을 미치는 것을 인지하지 못한 경우가 많았습니다. 실제로 DOM을 조작하면 브라우저가 레이아웃을 다시 계산하고 리페인트를 수행해야 하므로 성능이 저하될 수 있습니다. 특히 요소의 스타일이 변경될 때마다 브라우저는 레이아웃을 다시 계산하고 리페인트를 수행해야 하므로 이러한 작업은 브라우저에 부하를 줄 수 있고 성능 저하로 이어질 수 있습니다.
이러한 이유로 SPA 프레임워크가 등장하면서 가상 DOM을 사용하여 성능을 최적화하고 DOM 조작을 최소화하는 것이 중요해졌습니다. 가상 DOM은 상태 변경 시 변경된 부분만을 실제 DOM에 반영하여 성능을 최적화하는 방법으로, 이를 통해 전체적인 웹 애플리케이션의 성능과 사용자 경험을 향상시킵니다. 이를 통해 개발자들은 DOM 조작을 직접 처리하는 것보다 더욱 효율적으로 웹 애플리케이션을 개발할 수 있게 되었습니다.
SPA 프레임워크에서 사용되는 가상 DOM은 메모리에 저장되며, 상태가 변경되면 이전 가상 DOM과 현재 가상 DOM을 비교하여 변경된 부분만을 찾아 실제 DOM에 반영합니다. 이를 통해 DOM 조작으로 인한 성능 문제를 효과적으로 해결하고, 유지보수성과 개발 효율성을 향상시킵니다. 따라서, 매번 전체 렌더링을 다시 수행할 필요가 없어지는 것이죠. 이는 작은 변경 사항이 있더라도 처음부터 모든 요소를 다시 렌더링할 필요가 없게 됨을 의미합니다. 이렇게 함으로써, DOM 조작을 최소화하고 프레임워크가 가상 DOM을 관리하도록 함으로써 성능을 최적화할 수 있습니다.
