🌐 01. HTML 멘탈 모델: '그냥 태그 아닌가요?'에서 탈출하기

2026년 3월 5일 수정됨

📋 개요

HTML 파싱 원리, DOM 트리 생성, Critical Rendering Path까지 — 브라우저가 HTML을 어떻게 읽고 그리는지 5년 차의 언어로 설명합니다.

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분 / 핵심 파트만: 8분

🗺️ 이 문서의 흐름

[HTML이란 무엇인가] → [브라우저 파싱 원리] → [DOM 트리 생성] → [Critical Rendering Path] → [React와의 연결]

🎯 이 문서를 다 읽으면 할 수 있는 것

HTML이 단순 마크업이 아니라 브라우저와의 '계약서'임을 설명할 수 있다.
브라우저가 HTML을 DOM 트리로 바꾸는 파싱 과정을 순서대로 그릴 수 있다.
script 태그 위치가 왜 성능에 영향을 주는지 원리로 설명할 수 있다.
React가 DOM을 어떻게 활용하는지 연결 지을 수 있다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

🐣 영철 ( 신입 ): "영호 님, 저 HTML은 알죠. <div> 쓰고, <p> 쓰고, CSS 입히면 되는 거 아닌가요? 근데 오늘 코드 리뷰에서 '파싱 블로킹'이라는 말을 들었는데... 파싱이 뭐예요? 블로킹은 또 뭐고요. 태그 순서가 성능이랑 무슨 상관인지 전혀 모르겠어서요. 그냥 화면에 잘 나오면 된 거 아닌가요?"
🦁 영호 ( 리드 ): "영철 님, 그게 딱 '기능 구현자'와 '엔지니어'의 경계선이에요. HTML 파일 한 줄 한 줄이 브라우저한테 내리는 명령어거든요. 브라우저가 그걸 어떤 순서로 읽고, 어디서 멈추고, 어떻게 화면을 그리는지 알아야 진짜 최적화를 할 수 있어요."

🤔 왜 알아야 하는가

영수네 커뮤니티 서비스 출시 하루 전, 영철이는 Lighthouse 점수를 처음 돌려봤다.

Performance 점수: 42점. 🔴

영수(PM): "영철 님, 이거 왜 이렇게 느려요? 사용자가 3초 안에 첫 화면 못 보면 바로 나가요."

영철이의 index.html은 이랬다:

<!-- ❌ 영철이의 최초 코드: 스크립트가 head 안에 덕지덕지 -->
<head>
  <script src="analytics.js"></script>
  <script src="heavy-library.js"></script>
  <script src="app.js"></script>
</head>
<body>
  <h1>영수네 커뮤니티</h1>
  ...
</body>

🦁 영호 리드: "영철 님, 브라우저는 HTML을 위에서 아래로 한 줄씩 읽어요. <script> 태그를 만나는 순간 파싱을 '완전히 멈추고' 그 스크립트를 다 받아서 실행한 다음에야 다시 읽거든요. 지금 <h1> 태그보다 <script> 세 개가 먼저 실행되고 있어요. 사용자 눈에 아무것도 안 보이는 시간이 몇 초씩 낭비되는 거예요."

이 문제를 진짜로 이해하려면, 브라우저가 HTML을 어떻게 처리하는지 멘탈 모델을 갖춰야 한다.

🌐 1. HTML은 '마크업'이 아니라 '계약서'다

HTML은 단순히 화면을 꾸미는 언어가 아니야. 브라우저에게 "이 문서의 구조와 의미(Semantics)는 이거야" 라고 선언하는 계약서에 가까워.

브라우저는 이 계약서(HTML)를 읽고, DOM(Document Object Model) 이라는 데이터 구조로 변환해서 화면을 그리거든.

🧒 5살에게 설명한다면?
레고 설명서(HTML)가 있으면, 레고 조립 결과물(DOM)이 만들어지는 거야.
설명서대로 레고를 조립하면 살아있는 모형(화면에 보이는 UI)이 되는 거지.
설명서를 잘못 쓰면? 레고가 이상하게 조립돼.

HTML 문서의 뼈대 구조:

<!doctype html>       <!-- 브라우저에게: "이건 현대 HTML5 표준이야" -->
<html lang="ko">      <!-- 루트 요소: 이 계약서의 시작 -->
  <head>              <!-- 기계용 메타데이터: 브라우저·검색엔진이 읽는 정보 -->
    <meta charset="UTF-8" />
    <title>영수네 커뮤니티</title>
  </head>
  <body>              <!-- 사람용 콘텐츠: 실제 화면에 보이는 부분 -->
    <h1>안녕하세요</h1>
  </body>
</html>

<!doctype html> 이 한 줄이 중요해. 이게 없으면 브라우저는 "이 문서가 구버전 HTML인가?" 하며 Quirks Mode (호환성 모드)로 진입해서 오래된 렌더링 규칙을 적용해버려. CSS 레이아웃이 이상하게 깨지는 원인이 되기도 하지.

🔍 2. 브라우저의 HTML 파싱 과정

브라우저가 HTML 파일을 받으면 어떤 일이 일어나는지 단계별로 살펴보자.

2-1. 바이트 → 문자 → 토큰 → 노드 → DOM 트리

[서버] HTML 바이트 스트림 전송
  ↓
[브라우저 파서] 바이트 → 문자(Character) 디코딩 (UTF-8 등)
  ↓
[토크나이저] 문자열 → 토큰(Token) 분리 (<html>, <head>, <body> 등)
  ↓
[노드 생성] 각 토큰 → DOM 노드(객체) 생성
  ↓
[트리 구성] 노드들의 부모-자식 관계 연결 → DOM 트리 완성

<!-- 이 HTML이 -->
<html>
  <body>
    <p>영수네 <strong>커뮤니티</strong></p>
  </body>
</html>

<!-- 이런 DOM 트리가 된다 -->
Document
  └── html
        └── body
              └── p
                    ├── "영수네 " (텍스트 노드)
                    └── strong
                          └── "커뮤니티" (텍스트 노드)

DOM 트리는 자바스크립트에서 document.querySelector() 로 접근할 수 있는 바로 그 객체 구조야. HTML 파일이 DOM이 되는 거지, DOM 자체가 HTML은 아니야.

2-2. `<script>` 가 파싱을 막는 이유

🐣 영철: "그럼 <script> 태그를 만나면 왜 파싱이 멈추는 거예요?"

🦁 영호 리드: "자바스크립트가 DOM을 실시간으로 수정할 수 있기 때문이에요. document.write() 같은 함수로 HTML 자체를 동적으로 바꿀 수 있거든요. 브라우저 파서 입장에서는 스크립트를 실행해보기 전까지 '이 스크립트가 뒤에 올 HTML을 바꿀지 안 바꿀지' 알 수가 없어요. 그래서 안전하게, 스크립트 완전히 실행하고 나서야 다음 HTML을 읽는 거죠."

<!-- ❌ 파싱 블로킹 패턴 (Render-Blocking) -->
<head>
  <script src="heavy-library.js"></script> <!-- 여기서 파싱 STOP -->
</head>
<body> <!-- heavy-library.js 다 받고 실행될 때까지 이 부분은 읽지도 않음 -->
  <h1>영수네 커뮤니티</h1>
</body>

<!-- ✅ 5년 차의 해결법: defer/async 활용 -->
<head>
  <!-- defer: 파싱 계속 진행, 파싱 완료 후 순서대로 실행 -->
  <script src="app.js" defer></script>
  <!-- async: 파싱 계속 진행, 스크립트 받으면 즉시 실행 (순서 보장 X) -->
  <script src="analytics.js" async></script>
</head>

속성	파싱 블로킹	실행 시점	실행 순서	사용 케이스
없음	O (블로킹)	즉시	선언 순서	절대 비추천
`defer`	X	DOM 파싱 완료 후	선언 순서 보장	앱 메인 스크립트
`async`	X	다운로드 완료 즉시	순서 보장 안됨	독립적인 분석 스크립트

🏗️ 3. Critical Rendering Path: 화면이 그려지기까지

DOM 트리가 만들어졌다고 바로 화면이 그려지는 게 아니야. Critical Rendering Path 라는 6단계를 거쳐야 해.

HTML 파싱 → DOM 트리
CSS 파싱 → CSSOM 트리
     ↓
DOM + CSSOM = Render Tree (화면에 실제로 보일 노드만 선택)
     ↓
Layout (Reflow): 각 요소의 위치·크기 계산
     ↓
Paint: 실제 픽셀로 색칠
     ↓
Compositing: 레이어 합성 → 최종 화면

🦁 영호 리드: "CSS도 파싱 블로킹이에요. <link rel='stylesheet'> 를 만나면 브라우저는 CSSOM 을 다 만들 때까지 Render Tree 생성을 기다려요. 그래서 CSS는 항상 <head> 상단에 넣는 게 맞는 거예요. JS 는 하단, CSS 는 상단 — 이게 5년 차의 기본 습관이에요."

<!-- ✅ 5년 차의 HTML 기본 뼈대 -->
<!doctype html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>영수네 커뮤니티</title>
    <!-- CSS는 head 상단: CSSOM 먼저 만들어야 Render Tree 생성 가능 -->
    <link rel="stylesheet" href="styles.css" />
    <!-- 앱 중요 스크립트는 defer: DOM 완성 후 순서대로 실행 -->
    <script src="app.js" defer></script>
  </head>
  <body>
    <!-- 콘텐츠가 먼저 파싱되어 사용자에게 빠르게 보임 -->
    <h1>환영합니다!</h1>
  </body>
</html>

⚛️ 4. React와 DOM의 관계

🐣 영철: "그럼 React를 쓰면 이 DOM 트리 얘기는 상관없는 거 아닌가요? React가 알아서 다 해주잖아요."

🦁 영호 리드: "정반대예요. React는 Virtual DOM으로 DOM을 더 영리하게 다루는 도구지, DOM에서 독립돼 있는 게 아니에요. React 앱도 결국 브라우저의 실제 DOM을 조작하는 것으로 끝나요. 그래서 DOM을 모르면 React 성능 문제나 Hydration 에러를 절대 못 잡아요."

<!-- React 앱의 진짜 HTML 뼈대 (index.html) -->
<!doctype html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <title>영수네 커뮤니티</title>
  </head>
  <body>
    <!-- React 앱이 마운트될 단 하나의 DOM 노드 -->
    <div id="root"></div>
    <!-- React JS: defer로 DOM 파싱 완료 후 실행 -->
    <script type="module" src="/src/main.tsx" defer></script>
  </body>
</html>

React는 <div id="root"> 라는 빈 껍데기 를 진입점으로 삼아, 그 안에 Virtual DOM을 계산한 결과를 실제 DOM으로 찍어내(Mount)는 거야. 그래서 React 앱의 HTML 뼈대는 사실상 저게 전부야.

🔗 연결 고리
Next.js는 이 과정을 SSR(Server-Side Rendering)로 발전시켜요.
서버에서 미리 HTML을 생성해서 보내주면 → 브라우저가 <div id="root"> 에 빈 껍데기가 아닌 실제 콘텐츠가 담긴 HTML을 받게 돼요. 그래서 사용자가 JavaScript 로딩 전에도 콘텐츠를 볼 수 있는 거예요 (FCP 개선).

🏁 핵심 패턴 총정리

개념	내가 이해한 의미	5년 차의 설명
DOM	HTML의 객체 변환본	브라우저 파서가 HTML 태그를 읽어 메모리 상에 생성한 노드 트리. JS가 조작하는 대상.
파싱 블로킹	`<script>` 의 멈춤	JS는 DOM을 수정할 수 있어서, 브라우저는 `<script>` 실행 완료 전까지 뒤의 HTML을 읽지 않음.
`defer`	비동기 로드, 순서 보장	DOM 파싱을 막지 않고 백그라운드에서 다운로드, 파싱 완료 후 선언 순서대로 실행.
CRP	화면 렌더링 파이프라인	HTML→DOM, CSS→CSSOM → Render Tree → Layout → Paint → Composite 의 6단계 과정.
`<!doctype html>`	표준 모드 선언	없으면 브라우저가 Quirks Mode로 진입해 오래된 렌더링 규칙 적용. 항상 첫 줄에 필수.

📝 마무리 퀴즈

Q1. 다음 중 브라우저의 HTML 파싱을 막아 초기 렌더링을 지연시키는 원인은?

A) <link rel="stylesheet" href="style.css"> 를 <head> 에 선언
B) <script src="app.js"></script> 를 <head> 에 defer 없이 선언
가) <img> 태그에 alt 속성 누락
라) <meta charset="UTF-8"> 을 <head> 첫 줄에 선언

✅ 정답: B

💡 상세 해설:

원리 설명: <script> 를 defer 나 async 없이 선언하면 브라우저 파서는 그 지점에서 파싱을 완전히 중단합니다. 스크립트 파일을 네트워크에서 다운로드하고, 실행까지 완료한 뒤에야 다음 HTML을 읽어요. <head> 가 본문보다 먼저 처리되므로, 사용자는 스크립트 실행이 끝날 때까지 화면에 아무것도 볼 수 없습니다.
오답 피드백: A는 CSS 파싱으로 CSSOM을 만드는 과정으로 Render Tree 생성에 필요하지만, HTML 파싱 자체를 막지는 않습니다. 가/라는 성능과 무관한 항목입니다.
📌 핵심 기억법: <script> 는 defer 없으면 브라우저에 '빨간불(STOP)' — <link rel=stylesheet> 는 CSSOM 생성용으로 <head> 상단에 둬야 정상.

Q2. 브라우저의 Critical Rendering Path 순서를 올바르게 나열한 것은?

A) DOM → Layout → CSSOM → Render Tree → Paint → Composite
B) DOM + CSSOM → Render Tree → Layout → Paint → Composite
가) DOM → Paint → Layout → CSSOM → Render Tree → Composite
라) CSSOM → DOM → Paint → Render Tree → Layout → Composite

✅ 정답: B

💡 상세 해설:

원리 설명: HTML을 파싱해 DOM을, CSS를 파싱해 CSSOM을 만들어요. 이 둘을 합쳐 실제 화면에 표시될 노드만 담은 Render Tree 를 구성합니다. 그 다음 각 노드의 위치와 크기를 계산하는 Layout(Reflow), 픽셀로 색칠하는 Paint, 레이어를 합성하는 Composite 순으로 진행돼요.
오답 피드백: Layout 이전에 Render Tree 가 반드시 있어야 해요. Render Tree 없이는 무엇을 어디에 그려야 할지 알 수 없거든요.
📌 핵심 기억법: "DOM + CSSOM = 결혼 → Render Tree 자녀 → 자녀 위치(Layout) → 색칠(Paint) → 사진 합성(Composite)"

Q3. 영철이의 테스트 타임

영철이는 새로운 기능으로 외부 지도 API를 연동해야 한다. 이 스크립트는 용량이 크고,
지도가 표시되는 페이지에서만 사용된다. 영수(PM)는 "홈 화면 로딩이 느려지면 안 된다"고 못 박았다.
영철이가 <script src="map-api.js"> 를 선언할 때, 가장 적절한 방법은?

✅ 정답: <script src="map-api.js" defer></script> 를 <head> 에 선언하거나, 지도가 필요한 시점에 JavaScript로 동적 로드

💡 상세 해설:

원리 설명: defer 를 쓰면 HTML 파싱을 막지 않고 백그라운드에서 스크립트를 다운로드해요. DOM 파싱 완료 후 순서대로 실행되니 지도 초기화도 안전하게 할 수 있습니다. 더 나아가 지도 페이지에 방문할 때만 스크립트를 동적으로 삽입하면 홈 화면에는 아예 스크립트를 안 불러올 수 있어요.
오답 피드백: 영철 님, async 도 파싱은 안 막지만 실행 순서 보장이 안 돼요. 지도 API처럼 DOM이 완성된 후에 실행돼야 하는 스크립트에는 defer 가 더 안전해요.
📌 핵심 기억법: "용량 큰 스크립트 = 반드시 defer 또는 동적 로드 (Dynamic Import)"

🐣 영철이의 퇴근 일기

오늘은 진짜 뇌가 업그레이드된 느낌이다. 사실 HTML은 너무 쉬운 거라 따로 공부할 게 없다고 생각했는데, 파싱 블로킹이라는 개념 하나가 내 <script> 습관 전체를 날려버렸다. 생각해보면 나는 그냥 "돌아가면 OK" 수준이었던 거잖아. 영호 리드 님이 내 코드 리뷰에서 "왜 <head>에 defer 없는 스크립트가 세 개씩이나 있어요?" 라는 말을 들었을 때 아무 말도 못 했던 게 너무 창피했다.

💡 "HTML은 단순 마크업이 아니라 브라우저와의 계약서다. <script> 위치 하나, defer 속성 하나가 사용자가 화면을 보기까지의 시간을 좌우한다."

퇴근하면서 지하철에서 계속 머릿속으로 파싱 파이프라인을 되새겨봤다. DOM 트리 → CSSOM 트리 → Render Tree → Layout → Paint → Composite. 이걸 외워서가 아니라 진짜로 이해한 것 같아서 기분이 이상하게 좋다. 집 가서 Lighthouse 한 번 돌려봐야겠다. Lighthouse 점수가 올라가는 걸 직접 보고 싶어!

🔗 더 알아보기

🌐 01. HTML 멘탈 모델: '그냥 태그 아닌가요?'에서 탈출하기

📌 이 문서를 읽기 전에

🤔 왜 알아야 하는가

🌐 1. HTML은 '마크업'이 아니라 '계약서'다

🔍 2. 브라우저의 HTML 파싱 과정

2-1. 바이트 → 문자 → 토큰 → 노드 → DOM 트리

2-2. <script> 가 파싱을 막는 이유

🏗️ 3. Critical Rendering Path: 화면이 그려지기까지

⚛️ 4. React와 DOM의 관계

🏁 핵심 패턴 총정리

📝 마무리 퀴즈

🐣 영철이의 퇴근 일기

2-2. `<script>` 가 파싱을 막는 이유