브라우저의 렌더링 과정

나는 지금 React, TypeScript로 웹 페이지를 개발하고 있어.

프론트앤드 개발자라면 이 기술을 정말 많이 사용하고 있을거야.

 

그러다 문득 내가 지금 사용하는 기술을 '왜' 사용하는건지 그 이유가 궁금해졌어.

이를 이해하려면 (살짝 진부하지만) 웹 개발의 역사를 알아야 돼.

 

내가 사용자(User)의 입장이 되어볼게.

크롬 브라우저를 열었다, 주소창에 URL을 입력했어. (www.naver.com)
네이버 홈 화면이 열렸어! 마치 해당 페이지로 이동한 것처럼 말이야.

 

사실은 실제로 해당 페이지로 이동한 게 아니라 내가 요청한 주소에 대한 응답을 받은거야.

이러한 일련의 과정을 브라우저가 렌더링(Rendering) 한다고 표현해.

 

브라우저는 사용자가 요청한 URL에 대한 HTTP 요청을 서버에 보내고, 서버는 HTML 문서로 응답해.

브라우저를 구성하는 요소는 HTML임을 우리는 알고 있어!

그런데 브라우저의 동작을 제어하는 자바스크립트는 HTML을 보고 이해하지 못해.

브라우저가 이해할 수 있도록 변환해주는 과정이 필요한데, 이를 파싱(Parsing)한다고 해.

 

파싱을 담당하는 파서(Parser)는 HTML 문서를 의미 단위로 쪼개는데 (이를 토큰화 한다고 해) HTML 문서를 이루고 있는 요소들을 DOM(Document Object Model) 노드로 만드는거야. DOM 노드가 결합된 DOM(Document Object Model) 트리는 곧 HTML 문서의 구조야.

 

파싱 과정에서 외부 리소스(CSS, JS)를 만나면 파싱을 중단해.

CSS는 CSSOM으로 변환하고 DOM 트리와 결합해 렌더 트리를 생성해. 렌더 트리는 실제 브라우저에 보여지는 요소들만 담겨있어. 

(참고로 JS는 스크립트를 실행한 후 다시 HTML 파싱을 진행해)

 

렌더 트리로 요소들의 각 위치와 크기를 계산하고(레이아웃), 스타일을 적용시켜(페인트).

이렇게 쌓인 여러개의 레이어들을 결합하는 과정을 거쳐 최종 화면을 렌더링 해.

이렇게 요약할 수 있겠다!
- HTML 파싱 및 DOM 트리 생성
- CSS 파싱 및 JS 실행
- 레이아웃 계산 및 페인팅
- 합성 및 최적화

 

순수 자바스크립트로 DOM을 조작하는 과정은 다음과 같았어. 

// 버튼 클릭 시 메시지 출력
const button = document.getElementById( 'myButton');
button.addEventListener('click', () => {
	alert('버튼이 클릭되었습니다. ');
}) ;

// 요소 스타일 변경
const myElement = document.getElementById('myElement');

 

위의 예시는 단순하지만 순수 자바스크립트를 사용하면 다수의 각각의 DOM 요소를 참조하고 이벤트를 바인딩해주어야 해.

DOM 조작을 단순화 하기 위해 등장한 게 jQuery야.

<script>
    // VanillaJS
    document.addEventListener('DOMContentLoaded', function() {
        const element = document.getElementById('first');
        element.style.color = 'red';
    });

    // jQuery
    $(document).ready(function(){
        $("#first").css("color", "red");
    });
</script>

 

우리 윗 세대의 개발자들은 jQuery로 개발을 했대.

순서대로 표현하면 VanillaJS ->.jQuery -> React, Vue.js 이런 흐름이지.

요즘 초등생들은 손으로 전화기를 표현할 때 이렇게 한대. 🤚(스마트폰) 나 때는 🤙(집 전화기) 이거인데 충격이었어. 이런 기분이겠지?

 

jQuery가 요즘 보이지 않는 이유가 뭘까?

과거에는 정적인 페이지가 주를 이루었지만, SPA(Single Page Application)와 같은 동적인 웹 애플리케이션이 등장하면서 복잡한 UI 업데이트가 필요해졌어. 실제 DOM 조작은 리렌더링 과정에서 Reflow와 Repaint를 유발하며 성능 저하의 주요 원인이 되었어.

 

DOM을 리렌더링 하는 과정에서 요소의 크기 및 위치를 다시 계산(Reflow)하고, 스타일을 적용(Repaint) 하는 과정은 많은 계산을 필요로 하기 때문이야. 따라서 직접 DOM을 제어하는 대신 비교군을 두게 된거야.

 

가상 DOM(Virtual DOM)은 실제 DOM을 추상화 한 것으로, DOM을 직접 제어했을 때 생기는 여러 문제를 해결했어.

 

초기 렌더링 시, 실제 DOM을 기반으로 가상 DOM(1)이 생성돼.

데이터가 변경되면 새로운 가상 DOM(2)을 생성하고 (1)과 (2)를 비교해서 변경된 부분만 실제 DOM에 반영하는거지.

비교하는 알고리즘을 Diffing 알고리즘이라고 하는데, 배치 알고리즘을 사용하기 때문에 매우 빠르대.

 

이렇게 요약할 수 있겠다!
- jQuery는 간단한 API와 크로스 브라우징 문제 해결로 순수 자바스크립트보다 편리했지만, 현대에는 React와 같은 프레임워크가 대체하고 있어.
- Virtual DOM은 성능 최적화와 효율적인 UI 업데이트를 가능하게 하며, SPA 및 대규모 애플리케이션에서 사용자 경험(UX)을 크게 향상시키며 현대 웹 개발의 핵심 기술로 자리 잡았다.

 

React와 Vue.js 같은 프레임워크는 가상 DOM을 활용해 복잡한 상태 변화와 UI 업데이트를 효율적으로 관리해.

이는 SPA 및 대규모 애플리케이션에서 사용자 경험(UX)을 크게 향상시키며 현대 웹 개발의 핵심 기술로 자리 잡았어.

 

여기까지 React를 '왜' 사용하는건지 그 이유를 웹 개발의 역사를 살펴보면서 이해할 수 있었어.

이렇게 편리하게 웹 개발을 할 수 있게 된 것에 감사하다 :)

 

다음에는 TypeScript를 사용하는 이유에 대해 알아볼게!