요소 중첩 규칙을 어기면?

잘못된 요소 중첩이 발생했을 때 브라우저가 파싱 오류를 어떻게 자동 수정하는지 이해하고, 유효하지 않은 마크업이 렌더링에 미치는 영향을 학습합니다

중급 15분 중첩 위반 브라우저 파싱 오류 수정 유효하지 않은 마크업

HTML은 매우 관대한 언어입니다. 문법적으로 잘못된 마크업을 작성해도 브라우저는 오류 메시지 없이 페이지를 렌더링합니다. 그러나 이 “관대함”이 오히려 심각한 문제를 숨기는 원인이 됩니다. 요소 중첩 규칙을 위반하면 브라우저는 자체적인 오류 복구 알고리즘을 통해 DOM 트리를 재구성하는데, 이 과정에서 개발자가 의도한 구조와 전혀 다른 결과물이 만들어질 수 있습니다. 특히 같은 잘못된 마크업이라도 브라우저마다 다르게 해석될 수 있어, 크로스 브라우저 호환성 문제의 근본 원인이 되기도 합니다.

핵심 문제점

  • 🔍 암묵적 오류 수정: 브라우저가 잘못된 중첩을 자동으로 수정하지만, 그 결과가 개발자의 의도와 다를 수 있다
  • 🌐 브라우저 간 불일치: 동일한 잘못된 마크업이 Chrome, Firefox, Safari에서 서로 다른 DOM 구조로 변환될 수 있다
  • 🎨 CSS 선택자 깨짐: DOM 구조가 예상과 다르게 재구성되면 CSS 선택자가 의도한 요소를 찾지 못해 스타일이 적용되지 않는다
  • ⚡ JavaScript 동작 오류: DOM 트리 구조가 변경되면 querySelector나 이벤트 위임 등의 JavaScript 로직이 예상대로 동작하지 않는다
  • ♿ 접근성 손상: 잘못된 중첩으로 인해 스크린 리더가 콘텐츠의 의미와 구조를 올바르게 전달하지 못한다

왜 중요한가?

실무에서 요소 중첩 위반은 가장 디버깅하기 어려운 유형의 버그 중 하나입니다. HTML 소스 코드만 보면 문제가 없어 보이지만, 실제로 브라우저가 구성한 DOM은 완전히 다른 형태일 수 있기 때문입니다. 예를 들어 p 태그 안에 div를 넣으면 브라우저는 p를 강제로 닫고 div를 형제 요소로 분리하는데, 이로 인해 레이아웃이 깨지거나 이벤트 핸들러가 동작하지 않는 상황이 발생합니다. React나 Vue 같은 프레임워크를 사용하더라도 JSX나 템플릿에서 잘못된 중첩을 하면 동일한 문제가 발생합니다. 콘텐츠 모델의 중첩 규칙을 정확히 이해하면 이러한 “보이지 않는 버그”를 사전에 방지할 수 있고, W3C Validator를 통한 마크업 검증을 개발 프로세스에 포함시켜 팀 전체의 코드 품질을 향상시킬 수 있습니다.

핵심 개념

콘텐츠 모델과 중첩 규칙

입문

HTML 태그에는 ‘어떤 태그 안에 어떤 태그를 넣을 수 있는지’에 대한 규칙이 있어요. 이 규칙을 콘텐츠 모델이라고 해요.

📦 태그는 상자와 같아요 HTML 태그는 물건을 담는 상자라고 생각해보세요. 큰 상자(div) 안에는 작은 상자도 넣고, 장난감도 넣을 수 있어요. 하지만 모든 상자가 다 같은 건 아니에요. 어떤 상자는 특정 물건만 담을 수 있는 전용 상자예요.

🏠 방마다 규칙이 달라요 학교에서 과학실에는 실험 도구만 보관하고, 도서관에는 책만 보관하죠? HTML 태그도 마찬가지예요. 문단 태그(p)는 글자만 담을 수 있는 ‘글자 전용 상자’이고, 본문 태그(body)는 거의 모든 것을 담을 수 있는 ‘큰 창고’예요.

🚫 규칙을 어기면 어떻게 되나요? 만약 도서관에 축구공을 가져가면 선생님이 “이건 여기에 둘 수 없어”라고 하면서 체육관으로 옮기시겠죠? 브라우저도 비슷해요. 규칙에 맞지 않는 태그를 발견하면 자기가 알아서 위치를 바꿔버려요.

💡 왜 규칙을 알아야 하나요? 규칙을 모르면 브라우저가 우리 의도와 다르게 상자를 재배치해버려요. 우리는 빨간 상자 안에 파란 상자를 넣었다고 생각하지만, 실제로는 옆에 나란히 놓여있을 수 있어요. 그러면 화면이 이상하게 보이겠죠!

중급

HTML의 콘텐츠 모델(Content Model)은 각 요소가 자식으로 허용하는 콘텐츠 유형을 정의합니다. HTML 명세에서는 요소를 여러 카테고리로 분류하며, 각 요소의 “permitted content”가 어떤 카테고리에 속하는 요소만 허용하는지를 규정합니다.

주요 콘텐츠 카테고리와 중첩 규칙

  • Flow content: 대부분의 body 내 요소 (div, p, section 등)
  • Phrasing content: 텍스트 수준 요소 (span, a, strong, em 등)
  • 핵심 규칙: Phrasing content만 허용하는 요소(p, h1~h6 등) 안에 Flow content 요소(div, section 등)를 넣으면 중첩 위반
<!-- ✅ 유효: div는 Flow content를 허용 -->
<div>
  <p>문단 안의 텍스트</p>
  <div>중첩된 div</div>
</div>

<!-- ❌ 위반: p는 Phrasing content만 허용 -->
<p>
  <div>p 안에 div는 규칙 위반</div>
</p>

<!-- ❌ 위반: span은 Phrasing content만 허용 -->
<span>
  <div>span 안에 div는 규칙 위반</div>
</span>

자주 발생하는 중첩 위반 패턴

  • <p> 안에 <div>, <section>, <article> 등 블록 요소 배치
  • <a> 안에 다른 <a> 중첩 (인터랙티브 콘텐츠 중첩 금지)
  • <button> 안에 <a> 또는 다른 <button> 배치
  • <table> 안에 <tr> 없이 직접 <td> 배치

심화

콘텐츠 모델의 중첩 규칙은 HTML Living Standard의 각 요소 정의에 명시된 “Content model”과 “Contexts in which this element can be used” 속성에 의해 결정됩니다.

WHATWG HTML Living Standard의 콘텐츠 카테고리 체계 HTML Living Standard Section 3.2.5.2에서 정의하는 콘텐츠 카테고리는 계층적 포함 관계를 형성합니다. Metadata content, Flow content, Sectioning content, Heading content, Phrasing content, Embedded content, Interactive content의 7개 주요 카테고리가 있으며, 각 요소는 하나 이상의 카테고리에 속합니다.

중첩 유효성은 부모 요소의 Content model과 자식 요소가 속한 카테고리의 교집합으로 결정됩니다. 예를 들어 <p> 요소의 Content model은 “Phrasing content”로 정의되어 있으므로, Phrasing content 카테고리에 속하지 않는 <div>(Flow content only)는 <p>의 자식이 될 수 없습니다.

Transparent 콘텐츠 모델의 특수성 <a>, <ins>, <del>, <object> 등은 Transparent 콘텐츠 모델을 가집니다. 이는 해당 요소 자체가 콘텐츠 모델을 정의하지 않고, 부모 요소의 콘텐츠 모델을 상속(inherit)한다는 의미입니다. 따라서 <div> 안의 <a>는 Flow content를 포함할 수 있지만, <p> 안의 <a>는 Phrasing content만 포함할 수 있습니다. 이는 동일한 요소(<a>)의 허용 자식이 문맥에 따라 달라지는 독특한 메커니즘입니다.

브라우저의 오류 복구 파싱

입문

브라우저는 잘못된 HTML을 발견해도 멈추지 않아요. 대신 스스로 “고쳐서” 화면에 보여주는데, 이 고치는 방식이 우리가 원한 것과 다를 수 있어요.

🔧 자동 수리 기사처럼 행동해요 집에 배관 문제가 생겼을 때, 전문 수리 기사가 와서 고쳐주면 좋겠죠? 브라우저도 비슷해요. 잘못된 HTML을 발견하면 자동으로 고쳐줘요. 문제는 수리 기사가 집주인한테 물어보지 않고 마음대로 고친다는 거예요!

📋 규칙에 따라 고쳐요 브라우저는 아무렇게나 고치는 게 아니라 정해진 규칙에 따라 고쳐요. 예를 들어 글자 전용 상자(p 태그) 안에 큰 상자(div 태그)가 들어오면, “글자 전용 상자를 먼저 닫고, 큰 상자는 밖에 놓자”라고 판단해요.

🤔 왜 문제가 되나요? 여러분이 “A 상자 안에 B 상자를 넣어주세요”라고 했는데, 브라우저가 “아, 이건 안 되니까 A 상자를 닫고 B 상자는 옆에 놓을게요”라고 바꿔버리면 어떨까요? 물건 배치가 완전히 달라져서 원래 의도했던 모양이 나오지 않겠죠!

🌐 브라우저마다 다르게 고칠 수도 있어요 Chrome, Firefox, Safari 같은 브라우저들이 있는데, 같은 잘못된 HTML을 봐도 각자 다르게 고칠 수 있어요. 그래서 어떤 브라우저에서는 괜찮아 보이는데 다른 브라우저에서는 이상하게 보일 수 있어요.

중급

HTML 파서는 잘못된 마크업을 만나도 파싱을 중단하지 않습니다. 대신 명세에 정의된 오류 복구(error recovery) 알고리즘에 따라 DOM 트리를 자동으로 재구성합니다. 이 과정은 “Tree Construction” 단계에서 발생하며, 개발자에게 별도의 경고 없이 수행됩니다.

<!-- 개발자가 작성한 코드 -->
<p>첫 번째 문단
  <div>블록 요소</div>
  계속되는 텍스트
</p>

<!-- 브라우저가 실제로 구성하는 DOM -->
<p>첫 번째 문단</p>
<div>블록 요소</div>
계속되는 텍스트
<p></p>

오류 복구의 핵심 동작 패턴

  1. 암묵적 닫힘(Implicit Closing): 허용되지 않는 자식 요소를 만나면 부모 요소를 강제로 닫음
  2. Foster Parenting: <table> 내부에서 허용되지 않는 요소를 테이블 앞으로 이동
  3. Adoption Agency Algorithm: 잘못 중첩된 서식 요소(b, i, em 등)를 재배치
// 소스 코드와 실제 DOM의 차이 확인
document.querySelector('p').innerHTML;
// 예상: "첫 번째 문단<div>블록 요소</div>계속되는 텍스트"
// 실제: "첫 번째 문단"

// DOM 구조 확인
document.querySelector('p').nextSibling;
// <div>블록 요소</div> — p의 자식이 아니라 형제로 이동됨

심화

HTML 파서의 오류 복구는 WHATWG HTML Living Standard Section 13.2 “Parsing HTML documents”에서 상세히 정의된 상태 기계(State Machine) 기반 알고리즘입니다.

Tree Construction 단계의 오류 처리 메커니즘 HTML 파서는 토큰화(Tokenization) 단계와 트리 구성(Tree Construction) 단계를 거칩니다. 중첩 위반은 트리 구성 단계에서 감지되며, 파서의 삽입 모드(Insertion Mode)에 따라 오류 복구 전략이 결정됩니다.

파서는 “open elements stack”(열린 요소 스택)을 유지하며, 새로운 토큰이 현재 스택의 최상위 요소에서 허용되지 않는 경우 오류 복구를 실행합니다. 예를 들어 “In Body” 삽입 모드에서 <p> 요소가 열린 상태일 때 <div> 시작 태그를 만나면, 명세는 “If the stack of open elements has a p element in button scope, then close a p element”라는 규칙을 적용합니다. 이로 인해 <p>가 암묵적으로 닫히고, <div>는 <p>의 형제로 삽입됩니다.

Adoption Agency Algorithm의 복잡성 Section 13.2.6.4.7에 정의된 Adoption Agency Algorithm은 서식 요소(<b>, <i>, <em>, <strong>, <a> 등)의 잘못된 중첩을 처리하는 가장 복잡한 오류 복구 메커니즘입니다. 이 알고리즘은 “active formatting elements” 목록과 “open elements stack”을 동시에 조작하여, 겹쳐진 서식을 분리하고 재적용합니다. 예를 들어 <b><i></b></i>라는 잘못된 중첩은 <b><i></i></b><i></i>로 재구성되며, 이 과정에서 최대 8회의 반복(outer loop)과 3회의 내부 반복이 수행됩니다.

암묵적 태그 닫힘

입문

어떤 HTML 태그는 다른 태그가 시작되면 자동으로 닫혀요. 우리가 닫는 태그를 쓰지 않아도 브라우저가 알아서 닫아버리는 거예요.

🚪 자동문처럼 작동해요 마트의 자동문을 생각해보세요. 사람이 나가면 자동으로 닫히죠? HTML의 일부 태그도 이런 자동문과 비슷해요. 새로운 태그가 시작되면 이전 태그가 자동으로 닫혀버려요.

📝 어떤 태그가 자동으로 닫히나요? 문단 태그(p)가 대표적이에요. 새로운 문단이 시작되면 이전 문단이 자동으로 닫혀요. 목록 항목(li)도 마찬가지로, 새로운 항목이 시작되면 이전 항목이 자동으로 닫혀요. 테이블의 칸(td)이나 줄(tr)도 같은 방식으로 동작해요.

🎯 의도적인 것과 실수의 차이 자동 닫힘이 편할 때도 있지만, 문제가 될 때도 있어요. 예를 들어 문단 안에 큰 상자(div)를 넣으려고 했는데, 문단이 먼저 자동으로 닫혀버리면 큰 상자는 문단 바깥에 놓이게 돼요. 우리가 원한 결과가 아닌 거죠.

⚠️ 닫는 태그를 항상 쓰는 게 좋아요 자동 닫힘에 의존하면 예상치 못한 결과가 생길 수 있어요. 그래서 HTML 태그의 닫는 태그를 명시적으로 써주는 것이 좋은 습관이에요. 그래야 브라우저가 우리 의도대로 화면을 만들어줘요.

중급

HTML 명세는 특정 요소들에 대해 종료 태그의 생략을 허용합니다. 이러한 요소는 특정 조건에서 암묵적으로 닫히며(implicitly closed), 이는 오류가 아니라 명세에 의한 정상적인 동작입니다. 문제는 개발자가 이 동작을 인지하지 못할 때 발생합니다.

Optional End Tag를 가진 요소

  • <p>: 다음 형제로 블록 레벨 요소가 시작되면 자동 닫힘
  • <li>: 다음 <li> 시작 시 또는 부모 <ul>/<ol> 닫힘 시 자동 닫힘
  • <td>, <th>: 다음 <td>, <th> 시작 시 자동 닫힘
  • <tr>: 다음 <tr> 시작 시 자동 닫힘
  • <head>: <body> 시작 시 자동 닫힘
<!-- 의도: 하나의 리스트 아이템 안에 제목과 설명 -->
<ul>
  <li>항목 1
    <p>설명 1</p>
  <li>항목 2  <!-- li가 암묵적으로 닫힘 — 정상 동작 -->
    <p>설명 2</p>
</ul>

<!-- 의도: p 안에서 줄바꿈 후 이미지 -->
<p>설명 텍스트
<figure>  <!-- p가 암묵적으로 닫힘 — 의도하지 않은 동작 -->
  <img src="photo.jpg" alt="사진">
</figure>
이어지는 설명</p>

<!-- 실제 DOM: p, figure, 텍스트가 모두 형제 요소 -->

Void Elements와의 구분 <br>, <img>, <input>, <hr> 등의 Void elements는 종료 태그를 가질 수 없는 요소로, 암묵적 닫힘과는 다른 개념입니다. Void elements는 콘텐츠를 포함할 수 없으므로 종료 태그 자체가 존재하지 않습니다.

심화

암묵적 태그 닫힘은 HTML Living Standard Section 13.2.6의 Tree Construction 알고리즘에서 각 삽입 모드(Insertion Mode)의 토큰 처리 규칙으로 구현됩니다.

Optional Tag Omission 규칙의 명세적 정의 HTML Living Standard Section 13.1.2.4 “Optional tags”는 종료 태그 생략이 허용되는 정확한 조건을 정의합니다. <p> 요소의 경우, 종료 태그는 다음 조건에서 생략 가능합니다: “바로 다음에 address, article, aside, blockquote, details, dialog, div, dl, fieldset, figcaption, figure, footer, form, h1~h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, ul 요소가 시작되거나, 부모 요소에 더 이상의 콘텐츠가 없고 부모가 a, audio, del, ins, map, noscript, video가 아닌 경우.”

이 규칙은 파서의 “In Body” 삽입 모드에서 구현됩니다. 예를 들어 <div> 시작 태그 토큰을 처리할 때, 파서는 “If the stack of open elements has a p element in button scope”를 검사하고, 해당되면 “close a p element” 단계를 수행합니다. 이 “close a p element” 단계는 열린 요소 스택에서 <p> 위에 있는 모든 요소를 제거(pop)하고, <p> 자체도 제거하여 암묵적 닫힘을 완성합니다.

“In Button Scope” 검사의 의미 “Has an element in button scope”는 열린 요소 스택을 최상위부터 탐색하여 대상 요소를 찾되, applet, caption, html, table, td, th, marquee, object, template 등의 경계 요소(Scope Marker)를 만나면 탐색을 중단하는 알고리즘입니다. 이 경계 메커니즘은 테이블이나 템플릿 내부에서 외부의 <p>가 영향받지 않도록 보호합니다.

DOM 트리 불일치와 실무 영향

입문

HTML 코드와 브라우저가 실제로 만든 화면 구조가 다를 수 있어요. 이런 차이 때문에 CSS 스타일이나 JavaScript 동작이 이상해질 수 있어요.

🗺️ 지도와 실제 길이 달라요 여러분이 보물 지도를 그렸다고 생각해보세요. 지도에는 “큰 나무 아래에 보물이 있다”고 표시했어요. 그런데 실제로 가보니 나무가 다른 곳에 있어서 보물을 못 찾는 거예요. HTML 코드(지도)와 실제 DOM(현실)이 다르면 이런 일이 일어나요.

🎨 옷을 입히려는데 사람이 없어요 CSS는 HTML 요소에 예쁜 옷(스타일)을 입히는 거예요. 그런데 브라우저가 HTML 구조를 바꿔버리면, CSS가 “여기 있을 거야”라고 생각한 자리에 요소가 없을 수 있어요. 그러면 옷을 입힐 대상을 못 찾아서 스타일이 적용되지 않아요.

🎮 리모컨 버튼이 안 먹어요 JavaScript는 HTML 요소를 찾아서 동작하게 만드는 리모컨 같아요. 그런데 DOM 구조가 바뀌면 리모컨이 엉뚱한 곳을 가리키게 돼요. 버튼을 눌러도 아무 일이 일어나지 않는 상황이 생기는 거예요.

🔍 문제를 찾기가 정말 어려워요 가장 큰 문제는 이런 버그가 눈에 잘 보이지 않는다는 거예요. HTML 코드를 아무리 봐도 틀린 게 없어 보이거든요. 브라우저가 몰래 바꿔버린 것이니까요. 그래서 개발자 도구로 실제 DOM을 확인하는 습관이 중요해요.

중급

소스 코드의 HTML과 브라우저가 구성한 실제 DOM이 다를 때, CSS 선택자와 JavaScript DOM 조작 로직이 예상대로 동작하지 않는 실무적 문제가 발생합니다.

<!-- 소스 코드 -->
<p class="container">
  <div class="highlight">중요 내용</div>
</p>

<style>
/* 의도: container 안의 highlight에 스타일 적용 */
.container .highlight {
  background: yellow;  /* ❌ 적용 안 됨! */
}

/* 실제 DOM에서는 .highlight가 .container의 자식이 아닌 형제 */
/* .container + .highlight 선택자가 필요 */
</style>
// 의도: p.container에 이벤트 위임
document.querySelector('.container').addEventListener('click', (e) => {
  if (e.target.classList.contains('highlight')) {
    console.log('클릭!');  // ❌ 절대 실행되지 않음
    // .highlight는 .container의 자식이 아니므로
    // 이벤트가 .container로 버블링되지 않음
  }
});

React/Vue에서의 중첩 위반 프레임워크 사용 시에도 동일한 문제가 발생합니다. React는 개발 모드에서 “validateDOMNesting” 경고를 콘솔에 출력하지만, 프로덕션에서는 경고 없이 잘못된 DOM이 생성됩니다. SSR(Server-Side Rendering) 환경에서는 서버에서 생성한 HTML과 클라이언트에서 hydration한 DOM이 불일치하여 hydration mismatch 오류가 발생할 수 있습니다.

// ⚠️ 개발 모드에서 경고 발생
function Card() {
  return (
    <p>
      {/* Warning: validateDOMNesting(...):
          <div> cannot appear as a descendant of <p> */}
      <div className="card-body">내용</div>
    </p>
  );
}

// ✅ 올바른 수정
function Card() {
  return (
    <div>
      <div className="card-body">내용</div>
    </div>
  );
}

심화

DOM 트리 불일치는 HTML 파서의 오류 복구와 CSSOM, JavaScript DOM API 간의 의미론적 불일치(semantic mismatch)로 인해 발생하며, 특히 현대 프레임워크의 가상 DOM과 실제 DOM 간의 동기화에 심각한 영향을 미칩니다.

CSS Selector Matching과 DOM 구조 의존성 CSS Selectors Level 4 명세에 따르면, 후손 결합자(descendant combinator, 공백)와 자식 결합자(child combinator, >)는 DOM 트리의 실제 구조를 기반으로 매칭됩니다. 소스 코드의 중첩이 아닌 파서가 구성한 최종 DOM 구조가 매칭 대상입니다.

이는 브라우저의 렌더링 파이프라인과 직접 관련됩니다. HTML 파서가 DOM을 구성한 후, CSSOM(CSS Object Model)이 구축되고, 두 트리가 결합되어 렌더 트리(Render Tree)를 형성합니다. DOM 구조가 예상과 다르면 CSSOM의 선택자 매칭 결과가 달라지고, 이는 레이아웃(Layout/Reflow)과 페인트(Paint) 단계에 연쇄적으로 영향을 미칩니다.

Hydration Mismatch와 프레임워크 런타임 영향 React의 경우, ReactDOMServer가 서버에서 생성한 HTML 문자열은 브라우저 파서를 거치면서 오류 복구가 적용될 수 있습니다. 이후 클라이언트에서 ReactDOM.hydrateRoot()가 실행되면, React의 Fiber 트리(가상 DOM)와 실제 DOM 노드를 매칭하는 과정에서 불일치가 감지됩니다. React 18 이상에서는 이 불일치 발생 시 전체 서브트리를 클라이언트에서 다시 렌더링(full client re-render)하며, 이는 First Contentful Paint(FCP)와 Time to Interactive(TTI) 메트릭에 부정적 영향을 줍니다.

Vue 3의 Vapor Mode나 Svelte의 컴파일 타임 접근에서도 유사한 문제가 발생합니다. 컴파일러가 정적 분석한 템플릿 구조와 브라우저 파서의 오류 복구 결과가 다를 경우, 바인딩 대상 노드의 인덱스가 어긋나 런타임 오류로 이어질 수 있습니다.