문서 구조(Document Structure)의 원칙은?

DOCTYPE, html, head, body 요소의 역할과 올바른 문서 구조 원칙을 이해하고, 표준에 맞는 HTML 문서를 작성하는 방법을 익힙니다

입문 15분 DOCTYPE html 요소 head body

모든 HTML 문서는 브라우저가 이해할 수 있는 특정한 구조를 갖추어야 합니다. DOCTYPE 선언, <html>, <head>, <body> 요소는 이 구조를 이루는 필수 뼈대로, 각각 고유한 역할과 존재 이유가 있습니다. 단순히 “규칙이니까 따라야 한다”는 수준을 넘어, 이 구조가 왜 이렇게 설계되었는지를 이해하면 브라우저가 HTML 문서를 처리하는 방식 자체를 이해하게 됩니다. 올바른 문서 구조를 갖추지 않으면 브라우저가 렌더링 모드를 잘못 선택하거나, 메타데이터를 인식하지 못하거나, 페이지 콘텐츠를 예상치 못한 방식으로 해석하는 문제가 발생할 수 있습니다. 문서 구조 원칙을 이해하는 것은 단순 암기가 아니라, HTML 표준이 브라우저와 개발자 사이에 맺은 계약을 파악하는 일입니다.

핵심 특징

  • 📄 DOCTYPE 선언의 역할: DOCTYPE은 단순한 형식 요소가 아니라, 브라우저에게 어떤 렌더링 모드(표준 모드 vs 쿼크 모드)로 문서를 처리할지를 지시하는 신호입니다
  • <html> 요소의 언어 선언: 루트 요소인 <html>은 문서 전체를 감싸며, lang 속성을 통해 문서의 언어를 스크린 리더와 검색 엔진에 알리는 중요한 역할을 합니다
  • 🔧 <head>의 메타데이터 컨테이너 역할: <head> 안의 정보는 화면에 직접 표시되지 않지만, 문자 인코딩, 뷰포트 설정, 문서 제목 등 브라우저와 외부 시스템이 페이지를 올바르게 처리하는 데 필수적인 정보를 담습니다
  • <body>와 렌더링 대상: <body>는 사용자에게 실제로 표시되는 콘텐츠 전체를 담는 컨테이너로, 브라우저 렌더링 파이프라인의 직접적인 입력 대상입니다
  • 구조 순서의 의미: <head>가 <body>보다 먼저 위치하는 것은 관례가 아니라 설계 원칙으로, 브라우저가 콘텐츠를 화면에 그리기 전에 필요한 모든 메타 정보를 먼저 파악할 수 있도록 보장합니다

실무에서의 영향

DOCTYPE 선언을 누락하거나 잘못 작성하면 브라우저가 쿼크 모드(quirks mode)로 전환되어 CSS 박스 모델이 예상과 다르게 동작하는 레이아웃 깨짐 현상이 발생할 수 있습니다. <html lang> 속성을 생략하면 스크린 리더가 잘못된 언어로 콘텐츠를 읽어 접근성 기준 미충족으로 이어질 수 있으며, 이는 법적 요구사항에 해당하는 경우도 있습니다. <head> 안의 <meta charset> 선언이 빠지면 한국어를 포함한 비ASCII 문자가 깨져 보이는 인코딩 오류가 발생합니다. 표준에 맞는 올바른 HTML 문서 구조는 크로스 브라우저 호환성의 가장 기본적인 토대이며, 프레임워크나 라이브러리를 사용하더라도 생성되는 HTML의 구조적 유효성은 개발자가 직접 책임져야 합니다. 문서 구조 원칙을 이해하고 습관화하면, 예측하기 어려운 렌더링 버그를 사전에 차단하고 접근성과 SEO를 동시에 강화하는 가장 비용 효율적인 방법이 됩니다.

핵심 개념

DOCTYPE 선언과 렌더링 모드

입문

HTML 파일 맨 위에 있는 <!DOCTYPE html>은 단순한 형식이 아니에요. 이 한 줄이 브라우저가 페이지를 그리는 방식 자체를 결정해요!

📄 DOCTYPE이 뭔가요? DOCTYPE은 “이 파일은 HTML 문서예요”라고 브라우저에게 알려주는 신호예요. 마치 편지 맨 위에 “수신: 김철수”라고 쓰는 것처럼, 브라우저에게 “이 내용을 HTML 표준대로 읽어주세요”라고 요청하는 거예요. 이 신호가 없으면 브라우저가 어떻게 읽어야 할지 혼란스러워해요.

🔄 표준 모드 vs 쿼크 모드가 뭔가요? 브라우저에는 두 가지 읽기 모드가 있어요. 표준 모드(Standards Mode)는 현재 HTML/CSS 규칙대로 정확히 처리하는 방식이에요. 쿼크 모드(Quirks Mode)는 오래된 웹사이트도 깨지지 않게 하려고 예전 방식대로 처리하는 방식이에요. DOCTYPE이 있으면 표준 모드, 없으면 쿼크 모드로 작동해요.

🚨 쿼크 모드가 되면 어떤 문제가 생기나요? 쿼크 모드에서는 CSS 박스 크기 계산 방식이 달라져요. 예를 들어 가로 100픽셀로 만든 상자가 쿼크 모드에서는 더 크거나 작게 보일 수 있어요. 마치 같은 설계도를 가지고 건물을 짓는데, 어떤 건축사는 미터법으로, 어떤 건축사는 인치법으로 해석하는 것처럼 혼란이 생기는 거예요.

💡 왜 <!DOCTYPE html>이 이렇게 짧아졌나요? 예전 HTML 4.01 시절에는 DOCTYPE이 아주 길고 복잡했어요. HTML5로 오면서 “그냥 표준 모드로 해줘”라는 의미의 가장 단순한 형태 <!DOCTYPE html>으로 줄었어요. 짧아졌지만 역할은 더 명확해진 거예요.

🎯 현대 웹에서 DOCTYPE의 실제 역할 오늘날 DOCTYPE의 가장 중요한 역할은 딱 하나예요. “표준 모드로 렌더링해줘”라는 신호를 보내는 것이에요. 이 신호 하나로 브라우저가 최신 HTML/CSS 표준을 제대로 따르게 됩니다.

중급

<!DOCTYPE html>은 문서 유형 선언(Document Type Declaration)으로, 브라우저의 렌더링 모드를 결정하는 핵심 신호입니다. 브라우저는 DOCTYPE 선언의 유무와 형태에 따라 세 가지 렌더링 모드 중 하나를 선택합니다.

렌더링 모드의 세 가지 종류

  • 표준 모드(Standards Mode): <!DOCTYPE html> 선언 시 활성화. 현재 HTML/CSS 명세를 정확히 따름
  • 거의 표준 모드(Almost Standards Mode): 일부 구형 DOCTYPE 선언 시 활성화. 표준과 거의 동일하지만 이미지 레이아웃 등 일부 차이 존재
  • 쿼크 모드(Quirks Mode): DOCTYPE 선언 없거나 잘못된 경우. 구형 브라우저(IE 5.5 이전) 동작을 모방

쿼크 모드에서 가장 눈에 띄는 차이는 CSS 박스 모델(box model) 계산 방식입니다. 표준 모드는 W3C 박스 모델(content-box)을 사용하지만, 쿼크 모드는 IE 전통 박스 모델(border-box 유사)을 사용해 width와 height 계산이 달라집니다.

<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8">
    <title>문서 제목</title>
  </head>
  <body>
    <!-- 콘텐츠 -->
  </body>
</html>

DOCTYPE은 반드시 문서의 첫 번째 줄에 위치해야 합니다. DOCTYPE 앞에 공백, 주석, BOM(Byte Order Mark)이 있으면 일부 브라우저에서 쿼크 모드로 전환될 수 있습니다. HTML5의 <!DOCTYPE html>은 대소문자를 구분하지 않으므로 <!doctype html>도 유효합니다.

심화

DOCTYPE 선언의 렌더링 모드 전환 메커니즘은 WHATWG HTML Living Standard의 “The DOCTYPE” 섹션과 각 브라우저의 quirks mode 구현 명세에 의해 정의됩니다. 현대 브라우저에서 DOCTYPE의 역할은 역사적 호환성 맥락에서 이해해야 합니다.

HTML Living Standard의 DOCTYPE 처리 명세 WHATWG HTML Living Standard의 파싱 알고리즘(Section 13.2.6.4)은 DOCTYPE 토큰 처리 방법을 규정합니다. 파서는 DOCTYPE 이름, 공개 식별자(public identifier), 시스템 식별자(system identifier)를 추출하고, 이 조합에 따라 문서의 compatMode 속성을 결정합니다.

  • <!DOCTYPE html> 또는 이름이 “html”인 DOCTYPE → document.compatMode = "CSS1Compat" (표준 모드)
  • DOCTYPE 없음 또는 인식 불가 → document.compatMode = "BackCompat" (쿼크 모드)

WHATWG Quirks Mode 명세와 CSS 박스 모델 차이 W3C와 WHATWG는 공동으로 Quirks Mode 명세(https://quirks.spec.whatwg.org)를 관리합니다. 이 명세는 쿼크 모드에서 발생하는 구체적인 동작 차이를 정의합니다. 핵심 차이 중 하나는 CSS 박스 크기 계산입니다. 쿼크 모드에서 width와 height 속성은 padding과 border를 포함한 크기를 의미하는 IE 전통 방식을 따르는 반면, 표준 모드는 content-box 방식을 사용합니다. 이는 CSS box-sizing: border-box와 유사한 동작이지만, 쿼크 모드에서만 암묵적으로 적용됩니다.

HTML5 이전 DOCTYPE의 복잡성과 단순화의 역사 HTML 4.01 시절 DOCTYPE은 SGML DTD(Document Type Definition) 참조를 포함했습니다. 예를 들어 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> 형태로, 브라우저가 해당 DTD에 따라 문서를 유효성 검사하도록 설계되었습니다. HTML5 명세 설계자들은 브라우저가 실제로 DTD를 다운로드하거나 파싱하지 않는다는 사실을 인식하고, DOCTYPE을 렌더링 모드 전환 신호로만 역할을 축소하여 <!DOCTYPE html>로 단순화했습니다. 이는 하위 호환성을 유지하면서 불필요한 복잡성을 제거한 실용적 설계 결정입니다.

Blink 엔진의 DOCTYPE 처리 Chromium Blink 엔진의 HTMLDocumentParser는 DOCTYPE 토큰을 처리할 때 Document::setCompatibilityMode()를 호출합니다. 이 메서드는 Document::CompatibilityMode 열거형 값(NoQuirksMode, QuirksMode, LimitedQuirksMode)을 설정하며, 이후 CSS 레이아웃 계산 전반에 걸쳐 참조됩니다. 특히 RenderStyle과 LayoutBox 클래스에서 호환 모드 여부에 따른 분기 처리가 이루어집니다.

html, head, body의 역할 분담

입문

HTML 문서 안에는 반드시 세 가지 큰 구역이 있어요. <html>, <head>, <body>인데, 각각 완전히 다른 역할을 담당해요. 건물에 비유하면 이해하기 쉬워요!

🏠 html 요소는 건물 전체예요 <html> 태그는 HTML 문서 전체를 감싸는 최상위 요소예요. 건물로 비유하면 건물 전체를 감싸는 담장 같은 역할이에요. 그리고 lang="ko" 속성을 붙이면 “이 건물은 한국어로 지어진 건물이에요”라고 알려주는 것과 같아요. 이 언어 정보는 스크린 리더와 검색 엔진에게 중요한 신호가 돼요.

📋 head는 건물의 설계 도면이에요 <head> 안의 내용은 화면에 직접 보이지 않아요. 하지만 문서를 올바르게 처리하는 데 꼭 필요한 정보들이 담겨 있어요. 마치 건물의 설계 도면처럼, 사람들이 직접 보는 게 아니지만 건물을 제대로 짓고 관리하는 데 없어서는 안 돼요. 문자 인코딩, 페이지 제목, 연결할 스타일시트 등이 여기에 들어가요.

👀 body는 사람들이 실제로 보는 공간이에요 <body> 안의 내용은 브라우저 화면에 실제로 표시돼요. 텍스트, 이미지, 버튼, 메뉴 등 사용자가 보고 클릭하는 모든 것이 여기에 들어가요. 건물로 비유하면 사람들이 실제로 생활하는 내부 공간이에요.

🔢 왜 head가 body보다 먼저인가요? <head>가 <body>보다 먼저 나오는 건 단순한 관례가 아니에요. 브라우저가 화면에 내용을 그리기 전에 먼저 문자 인코딩, 스타일시트 같은 필요한 정보를 알아야 하기 때문이에요. 마치 요리를 시작하기 전에 레시피와 재료를 먼저 준비하는 것과 같아요.

중급

<html>, <head>, <body> 세 요소는 HTML 문서의 필수 구조를 형성합니다. 각 요소는 명확히 구분된 역할을 담당하며, HTML Living Standard에서 그 위치와 용도가 규범적으로 정의됩니다.

각 요소의 역할 요약

  • <html>: 문서의 루트 요소(root element). lang 속성으로 문서 언어를 선언하여 스크린 리더와 검색 엔진에 언어 정보를 제공
  • <head>: 기계 처리 전용 메타데이터 컨테이너. 화면에 직접 렌더링되지 않음. <meta charset>, <title>, <link>, <script>, <style> 등을 포함
  • <body>: 브라우저 렌더링의 직접 대상인 콘텐츠 컨테이너. 사용자에게 실제로 표시되는 모든 요소를 포함
<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>페이지 제목</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <h1>화면에 보이는 콘텐츠</h1>
    <p>사용자가 실제로 읽는 내용입니다.</p>
  </body>
</html>

lang 속성은 특히 접근성 측면에서 중요합니다. WCAG 2.1 성공 기준 3.1.1은 페이지의 기본 언어를 프로그래밍 방식으로 결정할 수 있어야 한다고 요구하며, <html lang="ko">가 이 기준을 충족하는 가장 직접적인 방법입니다. 언어 선언이 없으면 스크린 리더가 잘못된 언어 음성 엔진으로 내용을 읽을 수 있습니다.

<!-- 문제: 스크린 리더가 잘못된 언어로 읽을 수 있음 -->
<html>
  <head>...</head>
  <body>한국어 콘텐츠...</body>
</html>

<!-- 올바른 방식 -->
<html lang="ko">
  <head>...</head>
  <body>한국어 콘텐츠...</body>
</html>

심화

<html>, <head>, <body> 요소의 구조는 WHATWG HTML Living Standard의 “The document element”(Section 4.1.1), “The head element”(Section 4.2.1), “The body element”(Section 4.3.1)에서 규범적으로 정의됩니다. 각 요소는 단순한 컨테이너를 넘어 브라우저 파싱, 접근성, 국제화에 걸친 다층적 역할을 수행합니다.

html 요소와 언어 태그 처리 lang 속성의 값은 BCP 47(Best Current Practice 47, IETF RFC 5646) 언어 태그 규약을 따릅니다. "ko"는 ISO 639-1 언어 코드, "ko-KR"은 언어 + 지역 조합입니다. 브라우저는 이 값을 기반으로 연결 단어(character break) 알고리즘, 텍스트 정렬 방향(dir 속성과 결합), 하이픈 처리 규칙을 결정합니다.

WHATWG HTML Living Standard는 lang 속성이 없는 경우 “언어를 알 수 없음(unknown)“으로 처리하도록 명세합니다. 접근성 API 관점에서 html 요소의 lang 값은 IAccessible2::get_language(), NSAccessibility::AXLanguage를 통해 보조 기술에 전달됩니다.

head 요소의 메타데이터 처리 순서 브라우저의 HTML 파서는 <head> 요소를 처리하면서 특정 순서로 메타데이터를 처리합니다. 특히 <meta charset> 선언은 HTML Living Standard에 따라 문서의 처음 1024바이트 이내에 위치해야 효력을 발휘합니다. 이는 파서가 문자 인코딩을 결정하기 전에 이미 일부 바이트를 디코딩해야 하는 기술적 제약 때문입니다.

<link rel="stylesheet"> 요소는 렌더링 차단 리소스(render-blocking resource)입니다. Blink 엔진은 CSSOM(CSS Object Model)이 완성될 때까지 <body> 렌더링을 지연시켜 FOUC(Flash of Unstyled Content)를 방지합니다. 이 동작은 <head> 내 <link> 처리의 핵심 설계 의도입니다.

body 요소와 렌더링 파이프라인 진입점 <body> 요소는 브라우저 렌더링 파이프라인의 실질적 진입점입니다. Blink의 HTMLBodyElement는 window의 이벤트 핸들러 속성(onload, onresize 등)의 바인딩 대상으로도 기능합니다. WHATWG HTML Living Standard Section 8.1.7.1은 <body> 요소의 이벤트 핸들러가 Window 객체에 반영되는 메커니즘을 정의합니다.

<head>와 <body>의 순서는 HTML 파서의 삽입 모드(insertion mode) 상태 기계에 의해 제어됩니다. “before head” 모드에서 컨텐츠 토큰이 감지되면 암묵적으로 <head>를 닫고 “after head” 모드로 전환됩니다. 이 오류 복구(error recovery) 메커니즘 덕분에 <head> 없이 작성된 HTML도 파싱되지만, 이는 명세의 관용(forgiving) 파싱 특성이지 권장 방식이 아닙니다.

문서 구조의 설계 원칙 - 왜 이렇게 설계되었을까?

입문

DOCTYPE, html, head, body 구조는 누군가 임의로 만든 규칙이 아니에요. 브라우저가 웹 문서를 가장 효율적으로 처리하기 위해 설계된 논리적인 구조예요. 왜 이렇게 설계됐는지 알면 절대 잊어버리지 않을 거예요!

🔖 신호 먼저, 내용 나중 좋은 문서는 항상 “이게 어떤 문서인지”를 먼저 알려줘요. 책도 표지에 제목과 저자를 먼저 쓰고, 편지도 발신인과 수신인을 먼저 쓰잖아요. HTML도 마찬가지로 DOCTYPE으로 문서 유형을 먼저 알리고, head로 처리 방법을 먼저 설명한 다음에 body에서 실제 내용을 시작해요.

⚡ 브라우저가 화면을 그리기 전에 준비해야 해요 브라우저가 <body> 내용을 화면에 그리려면 먼저 알아야 할 게 있어요. “글자를 어떤 방식으로 해석하지?”, “어떤 디자인을 적용하지?” 같은 정보들이요. 이 정보가 <head>에 미리 담겨 있기 때문에 브라우저가 준비를 마치고 화면을 그릴 수 있는 거예요. 만약 이 순서가 뒤바뀌면 글자가 깨지거나 스타일이 적용되기 전의 모습이 잠깐 보이는 문제가 생겨요.

🌍 문서 구조는 웹의 공통 언어예요 전 세계 모든 브라우저(크롬, 파이어폭스, 사파리 등)가 같은 HTML 표준을 따르기 때문에, 어디서나 같은 구조로 문서를 작성하면 어떤 브라우저에서도 올바르게 표시돼요. 이 공통 구조가 없으면 웹 개발자는 브라우저마다 다른 방식으로 코드를 짜야 했을 거예요.

🔧 프레임워크도 이 구조를 만들어줘요 React, Vue, Next.js 같은 프레임워크를 사용해도 결국 브라우저에 전달되는 것은 HTML이에요. 이 프레임워크들도 모두 DOCTYPE, html, head, body 구조를 올바르게 생성해요. 문서 구조 원칙을 이해하면 프레임워크가 왜 그렇게 동작하는지도 이해할 수 있어요.

중급

HTML 문서 구조의 설계 원칙은 세 가지 핵심 개념으로 요약됩니다. 첫째, 처리 정보 우선(Metadata First), 둘째, 렌더링 차단 방지(Avoiding Render Blocking), 셋째, 표준화된 파싱 계약(Standardized Parsing Contract)입니다.

처리 정보 우선 원칙 브라우저는 문서를 위에서 아래로 순차적으로 파싱합니다. <head> 내 <meta charset> 선언이 먼저 처리되어야 이후 텍스트를 올바르게 디코딩할 수 있습니다. <link rel="stylesheet">도 <head>에 위치해야 렌더링이 시작되기 전에 스타일 정보를 확보할 수 있습니다.

표준 계약 HTML 구조 원칙은 브라우저와 개발자 사이의 계약입니다. 올바른 구조로 작성하면 브라우저가 표준 방식으로 문서를 처리하는 것을 보장합니다. 이 계약이 깨지면(DOCTYPE 누락, 잘못된 중첩 등) 브라우저는 오류 복구 알고리즘을 실행하며 예측 불가능한 결과가 발생할 수 있습니다.

<!-- 잘못된 구조: charset 없음, lang 없음, DOCTYPE 없음 -->
<html>
  <head>
    <title>문제 있는 문서</title>
  </head>
  <body>
    <p>한국어 텍스트가 깨질 수 있음 ???</p>
  </body>
</html>

<!-- 올바른 구조: 모든 필수 요소 포함 -->
<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>올바른 문서</title>
  </head>
  <body>
    <p>한국어 텍스트가 정상 표시됩니다.</p>
  </body>
</html>

문서 구조 원칙을 준수하는 것은 단순히 “규칙을 따르는 것”이 아니라, 브라우저의 처리 파이프라인과 올바르게 협력하기 위한 기술적 토대입니다. 프레임워크(React, Vue, Next.js 등)와 정적 사이트 생성기(Gatsby, Astro 등)도 모두 이 구조를 정확히 생성합니다.

심화

HTML 문서 구조의 설계 원칙은 WHATWG HTML Living Standard의 파싱 알고리즘(Section 13)과 브라우저 렌더링 파이프라인의 상호작용에서 비롯됩니다. 이 구조는 웹의 역사적 발전 과정에서 기술적 필요에 의해 형성된 것입니다.

파싱 알고리즘의 관용(Forgiving) 설계 철학 WHATWG HTML 파싱 명세는 오류에 관용적(error-tolerant)인 파서를 정의합니다. DOCTYPE 누락, <html> 요소 생략, <head> 생략 등의 경우에도 파서는 암묵적으로 이를 추가하여 처리합니다. 이는 초기 웹의 수많은 비표준 문서도 브라우저에서 표시되어야 했던 현실적 필요에서 비롯된 설계입니다.

그러나 관용적 파싱은 결과를 예측 가능하게 보장하지 않습니다. 오류 복구 알고리즘은 브라우저마다 구현이 다를 수 있으며, 표준 명세는 구체적인 오류 복구 결과를 완전히 명시하지 않습니다. 이 때문에 표준에 맞는 문서 구조 작성이 크로스 브라우저 일관성의 유일한 보장 방법입니다.

Character Encoding Detection과 head의 처리 우선순위 HTML Living Standard는 문자 인코딩 결정 알고리즘(Section 13.2.3.3)을 정의합니다. 브라우저는 다음 우선순위로 인코딩을 결정합니다:

  1. HTTP Content-Type 헤더의 charset 매개변수
  2. BOM(Byte Order Mark)
  3. <meta charset> 또는 <meta http-equiv="Content-Type"> (첫 1024바이트 이내)
  4. 브라우저의 prescan/sniffing 알고리즘

<meta charset="UTF-8">이 <head>의 첫 번째 자식 요소로 위치해야 하는 이유는 이 처리 순서 때문입니다. 파서가 1024바이트를 초과하여 진행되면 charset 선언을 발견하더라도 이미 처리된 바이트에 대한 재파싱(re-parsing)이 발생할 수 있으며, 이는 성능 비용을 발생시킵니다.

렌더링 파이프라인과 임계 렌더링 경로(Critical Rendering Path) 브라우저 렌더링 파이프라인에서 <head> 처리와 <body> 렌더링의 분리는 임계 렌더링 경로(Critical Rendering Path, CRP) 최적화의 기반입니다. Blink 엔진은 CSSOM이 완성될 때까지 렌더링 트리(Render Tree) 구성을 지연합니다. 이는 <head>의 <link rel="stylesheet">가 렌더링 차단 리소스로 분류되는 이유입니다.

반면, <body> 하단에 위치한 <script> 요소는 HTML 파싱 이후에 실행되어 초기 렌더링을 차단하지 않습니다. 이는 전통적인 성능 최적화 패턴(<script> 태그를 </body> 직전에 배치)의 기술적 근거이며, 현재는 defer/async 속성으로 대체되었습니다. 문서 구조 원칙의 이해는 이러한 성능 최적화 결정의 기반이 됩니다.