🎨 여러분이 웹 브라우저(크롬, 엣지)를 열고 주소를 입력하는 순간, 화면에는 복잡한 코드가 아닌 아름다운 웹페이지가 나타납니다. 이 마법 같은 일이 순식간에 벌어지는 이유는 브라우저 안에 들어있는 **'렌더링 엔진(Rendering Engine)'**이라는 건축팀 덕분입니다. 렌더링 엔진은 서버에서 받아온 설계도(HTML/CSS/JS 코드)를 바탕으로, 벽돌을 쌓고 페인트를 칠하는 것처럼 체계적인 5단계를 거쳐 최종 웹페이지라는 **'집'**을 지어 올립니다. 오늘은 웹페이지가 완성되는 5단계 건축 과정을 비유로 쉽게 마스터해 봅시다!
✨ 핵심 원리: 웹 페이지 건축 설계도와 건축팀
웹페이지를 짓는 과정은 건축 현장과 매우 유사합니다.
- HTML: 집의 골격과 **구조(Structural)**를 정의하는 설계 도면입니다. (예: 방의 개수, 창문의 위치).
- CSS: 집의 장식과 **색상(Aesthetic)**을 정의하는 인테리어 디자인 도면입니다. (예: 벽의 색상, 가구의 배치).
- 렌더링 엔진 (브라우저): 설계도를 받아 집을 짓는 총괄 건축팀입니다.
👉 관련 글 : DNS는 왜 느려질까? 요청 단계별 병목 이해하기
DNS는 왜 느려질까? 요청 단계별 병목 이해하기
DNS(Domain Name System) 요청이 왜 느려지는지 단계별로 분석합니다. DNS 쿼리 과정에 대한 비유를 통해 Cache Miss, TTL 만료, Root/TLD 네임 서버의 과부하, 그리고 권한 있는 네임 서버의 설정 오류가 발생
praymeyer2025.tistory.com
🔥 1. 1단계: 설계도 해석 (Parsing & DOM/CSSOM Tree)
건축팀이 가장 먼저 할 일은 설계도를 해석하여 건축 가능한 형식으로 바꾸는 것입니다.
- HTML 해석 (DOM Tree): 🏗️ 건축팀은 HTML 설계도(코드)를 읽어, 집의 모든 요소(방, 문, 창문 등)를 부모-자식 관계의 **'구조적인 나무(DOM Tree)'**로 만듭니다. 이 나무는 집의 골조 순서를 나타냅니다. (비유: 설계 도면의 목록별 구조를 파악하는 과정)
- CSS 해석 (CSSOM Tree): 🌈 동시에 인테리어 디자이너들은 CSS 디자인 도면을 읽어, 각 구조에 어떤 스타일(색, 크기)을 적용할지 정리하는 또 하나의 **'스타일 나무(CSSOM Tree)'**를 만듭니다. (비유: 벽지, 페인트, 가구 등 디자인 요소를 파악하는 과정)
- 병목 요소: 💡 만약 HTML 중간에 외부 CSS 파일이 있다면, 브라우저는 그 CSS 파일 다운로드가 완료될 때까지 HTML 해석을 잠시 멈춥니다. (비유: 건축팀이 벽돌을 쌓다가 "벽지 색깔이 결정될 때까지 잠시 대기!"라고 외치는 상황)
🧘 2. 2단계: 건축 계획 수립 (Render Tree)
두 개의 나무(DOM Tree와 CSSOM Tree)가 완성되면, 건축팀은 이 둘을 합쳐서 **'실제로 지을 집의 모습'**을 결정합니다.
- Render Tree 생성: 🧘 DOM Tree의 모든 노드에 CSSOM Tree의 스타일을 결합하여 **'렌더 트리(Render Tree)'**를 만듭니다. 이 트리는 화면에 보여야 할 요소만 포함합니다. (비유: 벽지 색깔과 가구 크기까지 모두 적용된 최종 건축 계획서를 만드는 것)
- 무시되는 요소: display: none 속성처럼 화면에 보이지 않는 요소는 이 Render Tree에서 아예 제외됩니다. (비유: 설계도에 있었지만, 실제로는 짓지 않기로 결정된 창고 공간을 계획서에서 삭제하는 것)
💪 3. 3단계: 배치 (Layout/Reflow)
이제 집을 짓기 위한 각 요소의 정확한 위치와 크기를 계산합니다.
- Layout/Reflow: 💪 Render Tree의 각 요소(노드)가 화면의 어느 위치에 놓여야 하고, 가로/세로 크기는 얼마가 되어야 하는지 정확한 픽셀 값으로 계산합니다. (비유: 건축 현장에서 **'이 방은 가로 3m, 세로 4m', '창문은 바닥에서 1.5m 높이'**라고 줄자와 픽셀 단위로 정확히 재는 것)
- Reflow 현상: 💡 만약 페이지가 로드된 후 JavaScript가 어떤 요소의 크기를 바꾸면, 주변의 모든 요소가 다시 배치되어야 합니다. 이 과정을 **'리플로우(Reflow)'**라고 하며, 성능 저하의 주범입니다. (비유: 이미 지은 방 하나의 크기를 바꾸면, 옆 방, 복도, 심지어 지붕까지 모든 것을 다시 측정하고 재배치해야 하는 상황)
4. 4단계: 도색 준비 (Paint Setup)
위치와 크기가 결정되면, 이제 실제로 페인트를 칠하고 장식을 붙일 준비를 합니다.
- Paint: 🎨 레이아웃 단계에서 결정된 위치와 크기를 바탕으로, 각 요소를 색상, 테두리, 그림자 등 모든 시각적인 스타일로 채우기 시작합니다. (비유: 구조물에 벽지를 바르고, 페인트를 칠하고, 몰딩을 붙이는 작업)
- 레이어 분할 (Layering): 브라우저는 복잡한 요소를 효율적으로 처리하기 위해 페이지를 여러 개의 **레이어(Layer)**로 나눕니다. (비유: 배경 레이어, 메인 콘텐츠 레이어, 팝업 레이어 등 여러 장의 투명 필름에 나누어 그리는 것)
5. 5단계: 최종 조립 및 전시 (Compositing)
마지막 단계는 준비된 모든 요소를 사용자 화면에 보여주는 것입니다.
- Compositing: 🖼️ 페인트가 완료된 모든 레이어(투명 필름)를 정확한 순서대로 겹쳐서 하나의 최종 이미지를 만듭니다. (비유: 모든 인테리어가 끝난 여러 개의 투명 필름을 정확한 순서대로 합쳐서 하나의 완벽한 집을 완성하고 사용자에게 전시하는 것)
- 성능 최적화: 💡 이 합성(Compositing) 단계는 GPU(그래픽 처리 장치)를 사용하여 매우 빠르게 처리됩니다. 요소의 **위치만 움직이는 애니메이션(Translate)**은 레이아웃과 페인트를 다시 할 필요 없이 합성만 다시 하면 되므로 가장 빠릅니다. (비유: 집의 구조는 그대로 두고 가구의 위치만 살짝 옮기는 것이 가장 빠른 보수 작업인 것과 같습니다
✅ 요약 및 개선 팁! 💯
| 🏠 단계 | 🚀 비유적 표현 | 💡 핵심 역할 | ✨ 개선 팁 (성능 최적화) |
| 1. 설계도 해석 | 도면 및 디자인 파악 | DOM Tree와 CSSOM Tree 생성 | CSS를 HTML 상단에, JS를 HTML 하단에 배치(파싱 방지) |
| 2. 건축 계획 | 최종 계획서 작성 | Render Tree 생성 | 보이지 않는 요소(display: none)는 파악 단계에서 제외됨 |
| 3. 배치 | 줄자로 크기/위치 측정 | 요소의 정확한 픽셀 좌표 계산 | **리플로우(Reflow)**를 유발하는 width, height 변경 최소화 |
| 4. 도색 준비 | 투명 필름에 도색 | 레이어 분할 및 시각적 스타일 입히기 | 복잡한 스타일은 GPU 사용을 유도하는 CSS Transform 활용 |
| 5. 최종 조립 | 필름 겹쳐 전시 | 모든 레이어를 합쳐 화면에 출력 | transform: translate() 등 **합성(Compositing)**만 필요한 애니메이션 사용 |
📚 출처
- 브라우저 렌더링 엔진 내부 동작 원리 문서: Blink, Gecko 엔진 동작 방식
- 웹 성능 최적화(Web Performance Optimization) 가이드: Reflow 및 Repaint 최적화 기술
- HTML/CSS/JavaScript 표준 명세: 브라우저 파싱 및 스타일 계산 규약
브라우저의 렌더링 과정은 단순해 보이지만, 설계 해석, 계획, 배치, 도색, 조립이라는 복잡하고 체계적인 과정을 거칩니다. 이 건축 과정을 이해하면, 어떤 코드가 브라우저에 부담을 주는지 알게 되어 성능 좋은 웹페이지를 만들 수 있는 개발자 필수 역량을 갖추게 됩니다.
👉 이 글은
[당신이 모르는 인터넷! 이 3요소 없인 접속 불가능]
허브 글에서 인터넷 구조를 이해하기 위해 함께 읽으면 좋은 글입니다.
'💡 IT 핵심 지식 (Core) > 🔗 IT 근본 & 네트워크' 카테고리의 다른 글
| HTTP/2와 HTTP/3의 차이, 속도가 달라지는 이유 (0) | 2025.12.03 |
|---|---|
| NAT의 역할과 한계: 사설IP 시대의 숨은 구조 (0) | 2025.12.02 |
| DNS는 왜 느려질까? 요청 단계별 병목 이해하기 (0) | 2025.11.30 |
| 5G가 4G보다 빠른 진짜 이유: '고속도로 확장과 물류 혁신' (1) | 2025.11.13 |
| 로드 밸런서 vs 리버스 프록시: 트래픽 관리자의 역할 분담 (0) | 2025.11.11 |