헤딩 계층 구조가 왜 중요할까?

h1-h6 헤딩 요소의 아웃라인 알고리즘과 계층 구조의 중요성을 이해하고, 문서 접근성과 검색엔진 최적화를 고려한 올바른 헤딩 사용법을 익힙니다

HTML의 h1부터 h6까지의 헤딩 요소는 단순히 글자 크기를 조절하는 도구가 아닙니다. 헤딩은 문서의 아웃라인(outline)을 형성하는 구조적 신호이며, 브라우저, 스크린 리더, 검색 엔진이 문서의 계층적 의미를 파악하는 핵심 수단입니다. h1이 문서 전체의 주제를 나타내고 h2, h3가 순서대로 세부 주제를 나타내는 계층 구조는 시각적 표현의 문제가 아니라 콘텐츠의 논리적 관계를 기계와 사람 모두에게 명확히 전달하는 설계 결정입니다. 헤딩 계층을 잘못 사용하면 문서 아웃라인이 무너지고, 그 결과는 단순한 코드 품질 저하를 넘어 접근성과 검색 노출 모두에 실질적인 손해를 가져옵니다.

핵심 특징

📋 아웃라인 알고리즘과 문서 계층: 브라우저와 보조 기술은 h1-h6를 순서대로 읽어 문서의 논리적 목차(아웃라인)를 자동으로 구성하며, 이 아웃라인이 곧 문서의 구조적 골격이 됩니다
♿ 스크린 리더 탐색의 핵심 경로: 시각 장애 사용자는 스크린 리더의 헤딩 탐색 기능을 이용해 페이지 전체를 훑고 원하는 섹션으로 이동하는데, 헤딩이 없거나 잘못된 계층이면 이 탐색 자체가 불가능해집니다
🔍 검색 엔진의 콘텐츠 이해 신호: 검색 엔진은 h1을 문서의 핵심 주제로, h2-h3를 세부 토픽으로 인식하여 콘텐츠 색인에 활용하므로, 헤딩 계층은 SEO에 직접적인 영향을 미칩니다
계층 건너뜀의 문제점: h1 다음에 h3를 바로 사용하거나 헤딩 레벨을 시각적 크기 조절 목적으로 선택하면 아웃라인에 논리적 공백이 생겨 보조 기술과 크롤러 모두 혼란을 겪습니다
h1은 페이지당 하나의 원칙: 각 페이지에는 전체 주제를 대표하는 h1이 단 하나여야 하며, 복수의 h1은 문서의 주제가 무엇인지 모호하게 만들어 SEO와 접근성 양쪽에 부정적인 영향을 줍니다

실무에서의 영향

스크린 리더 사용자의 약 70%가 헤딩 탐색 기능을 사용해 페이지의 내용을 먼저 파악한다는 점에서, 헤딩 계층은 접근성의 가장 기본적인 기반입니다. 헤딩이 올바르게 구성된 페이지에서는 “다음 헤딩으로 이동”, “2단계 헤딩 목록 보기” 같은 단축키만으로 콘텐츠 구조를 즉시 파악할 수 있지만, 헤딩이 시각적 스타일링 목적으로 무작위로 사용된 경우에는 이 탐색이 완전히 실패합니다. 검색 최적화 측면에서도 h1에 페이지 핵심 키워드가 포함되고 h2-h3에 관련 주제가 계층적으로 연결될 때 콘텐츠의 주제 관련성 점수가 높아지며, 반대로 디자인 이유로 h1을 여러 번 사용하거나 h4를 h2처럼 크게 스타일링해 사용하면 크롤러의 콘텐츠 이해를 방해합니다. 실무에서 가장 흔한 실수는 CSS로 글자 크기를 조절하기 번거롭다는 이유로 의미에 맞지 않는 헤딩 레벨을 선택하는 것인데, 헤딩 레벨은 항상 문서 내 계층적 위치로 결정하고 시각적 크기는 CSS로 별도 관리해야 합니다. 올바른 헤딩 계층 구조는 추가 비용 없이 접근성 준수와 SEO 개선을 동시에 달성할 수 있는 가장 기초적이고 효과적인 시맨틱 HTML 실천입니다.

핵심 개념

헤딩과 문서 아웃라인 알고리즘

입문

h1부터 h6까지의 헤딩 요소는 글자를 크게 만드는 도구가 아니에요. 이 요소들은 문서의 “목차”를 만드는 신호예요!

📚 책의 목차를 생각해보세요 두꺼운 교과서를 펼쳤을 때 맨 앞에 목차가 있죠? “1장 - 지구의 구조”, “1.1절 - 지각”, “1.2절 - 맨틀” 이런 식으로요. 웹페이지의 헤딩도 똑같이 브라우저와 보조 도구들이 자동으로 목차를 만드는 데 쓰여요. h1이 1장, h2가 1.1절, h3이 1.1.1항이 되는 거예요.

😵 목차가 없거나 순서가 뒤죽박죽이면? 만약 교과서 목차에서 1장 다음에 바로 3장이 나온다면 엄청 혼란스럽겠죠? 웹페이지에서도 h1 다음에 h4를 쓰거나, h2를 여러 개 섞어 쓰면 컴퓨터와 사람 모두 “이 문서가 어떤 구조인지” 파악하기 어려워요.

🤖 브라우저와 보조 도구가 자동으로 읽어요 브라우저, 스크린 리더(시각 장애인이 사용하는 프로그램), 구글 같은 검색 엔진은 헤딩을 읽어서 “이 페이지의 내용이 무엇인지” 파악해요. 올바른 순서로 헤딩을 쓰면 이 도구들이 문서를 훨씬 잘 이해할 수 있어요.

🏗️ 계층이 중요한 이유 h1은 페이지 전체의 주제, h2는 큰 섹션, h3는 그 안의 소주제 이런 식으로 계층이 있어야 해요. 마치 건물을 지을 때 기초-기둥-벽-지붕 순서로 쌓아가는 것처럼, 헤딩도 논리적인 순서로 계층을 만들어야 튼튼한 문서 구조가 만들어져요.

중급

h1-h6 헤딩 요소는 브라우저와 보조 기술이 문서의 논리적 아웃라인(outline)을 구성하는 데 사용하는 구조적 신호입니다. 아웃라인 알고리즘은 헤딩의 레벨 순서를 읽어 문서의 계층 구조를 자동으로 파악합니다.

올바른 헤딩 계층 구조의 원칙

h1은 페이지당 하나, 문서 전체의 주제를 나타냄
h2는 주요 섹션, h3는 h2의 하위 항목으로 순서대로 사용
헤딩 레벨을 건너뛰면(h1 → h3) 아웃라인에 논리적 공백이 생김

<!-- 올바른 예: 계층이 순서대로 이어짐 -->
<h1>JavaScript 완전 정복</h1>
  <h2>1. 변수와 데이터 타입</h2>
    <h3>1.1 var, let, const의 차이</h3>
    <h3>1.2 원시 타입과 참조 타입</h3>
  <h2>2. 함수</h2>
    <h3>2.1 선언식과 표현식</h3>

<!-- 잘못된 예: h1 다음에 h4를 바로 사용 -->
<h1>JavaScript 완전 정복</h1>
  <h4>변수란 무엇인가</h4>  <!-- h2, h3를 건너뜀 -->

아웃라인 알고리즘이 생성하는 문서 구조 올바른 헤딩 구조는 다음과 같은 계층형 아웃라인을 만들어냅니다:

JavaScript 완전 정복 (h1)
├── 1. 변수와 데이터 타입 (h2)
│   ├── 1.1 var, let, const의 차이 (h3)
│   └── 1.2 원시 타입과 참조 타입 (h3)
└── 2. 함수 (h2)
    └── 2.1 선언식과 표현식 (h3)

이 아웃라인은 스크린 리더의 탐색 메뉴, 검색 엔진의 콘텐츠 색인, 브라우저 확장 프로그램의 목차 생성에 그대로 활용됩니다.

심화

HTML Living Standard의 아웃라인 알고리즘은 헤딩 요소(h1-h6)가 문서의 암시적 섹션(implied section)을 형성하는 방식을 정의합니다. 이 알고리즘은 시맨틱 구조와 브라우저/보조 기술의 콘텐츠 해석 방식에 직접적인 영향을 미칩니다.

HTML Living Standard 아웃라인 알고리즘의 역사와 현황 WHATWG HTML Living Standard는 원래 섹셔닝 콘텐츠(<section>, <article>, <aside>, <nav>)와 헤딩을 결합한 복잡한 아웃라인 알고리즘을 명세했습니다. 이 알고리즘에서는 <section> 내부의 <h1>이 논리적으로 해당 섹션의 최상위 헤딩처럼 동작하도록 설계되었습니다.

그러나 이 알고리즘은 실제로 어떤 주요 브라우저나 스크린 리더에도 구현되지 않았습니다. 2022년 WHATWG는 이 알고리즘을 명세에서 제거하고, 현재 구현된 방식(헤딩 레벨 숫자만으로 계층 결정)을 공식 명세로 채택했습니다(WHATWG HTML, “The HTML element”, revision history 참조).

실제 브라우저와 보조 기술의 아웃라인 처리 방식 현재 모든 브라우저와 스크린 리더는 헤딩의 숫자 레벨(1-6)만을 기준으로 아웃라인을 구성합니다. <section> 안에 <h1>을 여러 개 써도 각각 최상위 레벨(rank 1)로 처리됩니다. 이는 섹셔닝 콘텐츠가 아웃라인 계층에 영향을 주지 않음을 의미합니다.

접근성 트리(Accessibility Tree)에서 헤딩은 role="heading"과 aria-level 속성으로 표현됩니다. ARIA in HTML 명세(W3C)에 따르면 h1은 aria-level="1", h6는 aria-level="6"으로 암시적으로 매핑됩니다.

섹셔닝 콘텐츠와의 관계 <section>, <article> 등의 섹셔닝 콘텐츠는 아웃라인 알고리즘과 무관하게 접근성 랜드마크(landmark)로서의 역할을 가집니다. 헤딩 계층은 이 섹셔닝 요소와 독립적으로 문서 전체를 기준으로 판단해야 하며, 올바른 패턴은 각 섹셔닝 요소 내부에서도 문서 전체의 계층 순서를 유지하는 것입니다.

헤딩 계층과 접근성

입문

눈이 보이지 않는 사람들은 웹페이지를 어떻게 탐색할까요? 바로 “스크린 리더”라는 프로그램이 화면의 내용을 소리로 읽어주는데, 헤딩이 이 탐색의 핵심이에요!

🛗 엘리베이터의 층 안내판을 생각해보세요 백화점 엘리베이터에는 “1층 - 식품관”, “2층 - 의류”, “3층 - 가전제품” 이런 안내가 있어요. 눈을 감고 있어도 버튼을 눌러 원하는 층으로 갈 수 있죠. 웹페이지의 헤딩도 똑같아요. 스크린 리더 사용자는 “다음 헤딩으로 이동” 키를 눌러 페이지를 탐색하고, 헤딩 목록을 보면서 어디로 갈지 결정해요.

❌ 헤딩이 없거나 잘못되면 어떻게 될까요? 만약 백화점 층 안내판이 없거나, 1층에 “3층 버튼”이 있다면 얼마나 혼란스럽겠어요? 헤딩이 없는 웹페이지는 스크린 리더 사용자에게 그런 느낌이에요. 원하는 내용을 찾으려면 페이지 전체를 처음부터 끝까지 다 들어야 해요.

✅ 헤딩이 올바르면 어떻게 될까요? 헤딩이 올바르게 있으면 스크린 리더 사용자는 “h2 목록 보기”를 눌러 큰 섹션들을 훑어본 다음, 원하는 섹션으로 바로 이동할 수 있어요. 마치 목차에서 원하는 장을 찾아 바로 넘어가는 것처럼요. 이것이 웹 접근성의 가장 기본적인 부분이에요.

🌍 접근성은 특별한 사람만을 위한 게 아니에요 접근성이란 모든 사람이 웹을 편리하게 사용할 수 있도록 만드는 것이에요. 눈이 잘 보이는 사람도 키보드만으로 탐색하거나, 빠르게 내용을 훑어봐야 할 때 잘 정리된 헤딩 구조에서 큰 도움을 받아요.

중급

스크린 리더(NVDA, JAWS, VoiceOver 등)는 헤딩을 페이지 탐색의 기본 수단으로 사용합니다. 사용자가 H 키를 누르면 다음 헤딩으로 이동하고, 1-6 숫자 키로 특정 레벨의 헤딩만 탐색할 수 있습니다. NVDA WebAIM 설문(2021)에 따르면 스크린 리더 사용자의 67.7%가 헤딩 탐색을 주요 페이지 탐색 방법으로 사용합니다.

계층 건너뜀이 접근성에 미치는 영향 WCAG 2.1 성공 기준 1.3.1 (정보와 관계, Level A)은 정보, 구조, 관계가 프로그래밍 방식으로 결정될 수 있어야 함을 요구합니다. 헤딩 레벨을 건너뛰면(h1 → h3) 스크린 리더 사용자는 “h2 레벨 콘텐츠가 있어야 할 곳에 없다”는 혼란을 겪습니다.

<!-- 올바른 예: 계층이 명확하고 탐색 가능 -->
<main>
  <h1>온라인 쇼핑몰 이용 가이드</h1>

  <section>
    <h2>회원가입과 로그인</h2>
    <h3>이메일로 가입하기</h3>
    <h3>소셜 계정으로 가입하기</h3>
  </section>

  <section>
    <h2>상품 주문하기</h2>
    <h3>장바구니 담기</h3>
    <h3>결제 방법 선택</h3>
  </section>
</main>

<!-- 잘못된 예: 계층 건너뜀과 시각적 목적 사용 -->
<main>
  <h1>온라인 쇼핑몰 이용 가이드</h1>
  <h3>회원가입과 로그인</h3>  <!-- h2를 건너뜀 -->
  <h5>이메일로 가입하기</h5>  <!-- 시각적 크기 때문에 선택 -->
</main>

WCAG와 헤딩 관련 성공 기준

2.4.6 (헤딩과 레이블, Level AA): 헤딩과 레이블이 주제나 목적을 설명해야 함
1.3.1 (정보와 관계, Level A): 헤딩 구조가 프로그래밍 방식으로 인식 가능해야 함

헤딩 레벨의 건너뜀 자체는 WCAG 실패 기준이 아니지만, axe-core와 Lighthouse는 이를 접근성 경고로 보고합니다. 특히 h1 누락이나 중복 h1은 접근성 감사에서 오류로 분류됩니다.

심화

헤딩 요소는 접근성 트리(Accessibility Tree)에서 role="heading"과 aria-level 속성을 가진 노드로 표현되며, 이는 보조 기술(AT, Assistive Technology)이 탐색과 콘텐츠 이해에 활용하는 핵심 시맨틱 정보입니다.

접근성 트리에서의 헤딩 처리 ARIA in HTML 명세(W3C, 2023)에 따르면 h1-h6 요소는 암시적으로 role="heading"을 가지며, 각각 aria-level 값이 1-6으로 매핑됩니다. 브라우저는 DOM에서 접근성 트리를 생성할 때 이 매핑을 적용하고, AT(스크린 리더 등)는 접근성 API(Windows: UIA, macOS: NSAccessibility, Linux: AT-SPI)를 통해 이 정보를 읽습니다.

aria-level 속성을 명시적으로 사용하면 시각적 헤딩 레벨과 의미론적 레벨을 분리할 수 있습니다:

<h2 aria-level="3">이 요소는 h2이지만 레벨 3으로 처리됨</h2>

그러나 이 패턴은 DOM 구조와 접근성 트리의 불일치를 야기하므로 권장되지 않습니다. 올바른 HTML 헤딩 레벨을 사용하는 것이 원칙입니다.

자동화 접근성 검사 도구의 헤딩 규칙 axe-core(Deque Systems)는 헤딩 관련 규칙으로 page-has-heading-one(h1 존재 여부), heading-order(헤딩 순서 건너뜀 검사), empty-heading(빈 헤딩 검사)을 포함합니다. Lighthouse(Google)는 접근성 감사에서 이와 유사한 규칙을 적용하며, WCAG 2.1 성공 기준 1.3.1과 2.4.6에 매핑합니다.

ARIA heading role의 직접 사용 role="heading"과 aria-level을 조합하면 헤딩이 아닌 요소를 접근성 트리에서 헤딩으로 표현할 수 있습니다. 그러나 이는 HTML 시맨틱을 우회하는 방법으로, 브라우저 내장 아웃라인 도구나 SEO 크롤러에는 반영되지 않으며 AT에만 영향을 미칩니다. ARIA 명세는 네이티브 HTML 요소를 사용할 수 있는 경우 ARIA role 사용을 권장하지 않습니다(“First Rule of ARIA Use”).

헤딩과 SEO - 검색 엔진의 콘텐츠 이해

입문

구글 같은 검색 엔진은 어떻게 “이 페이지가 어떤 내용인지” 알 수 있을까요? 로봇(크롤러)이 페이지를 읽고 분석하는데, 헤딩은 그 로봇에게 가장 중요한 신호예요!

📖 책의 제목과 부제를 생각해보세요 서점에서 책을 고를 때 제목을 먼저 보죠? “파이썬으로 시작하는 데이터 분석”이라는 제목을 보면 이 책이 어떤 내용인지 바로 알 수 있어요. 웹페이지의 h1도 바로 그 “책 제목”이에요. 구글 로봇은 h1을 읽고 “이 페이지의 핵심 주제가 이거구나”라고 파악해요.

🔍 h2, h3는 목차의 챕터들이에요 책의 목차에 챕터들이 있듯이, h2와 h3는 페이지의 세부 주제들을 알려줘요. 구글은 h2를 읽고 “이 페이지는 이런 내용들을 다루는구나”라고 이해해요. 그러면 관련 검색어를 입력한 사람에게 이 페이지를 보여줄 확률이 높아져요.

⚠️ h1을 두 개 쓰면 어떻게 될까요? 만약 책에 제목이 두 개라면 “이 책이 도대체 뭐에 관한 거야?”라고 혼란스럽겠죠? h1도 마찬가지예요. 한 페이지에 h1이 두 개 이상이면 구글 로봇이 “이 페이지의 핵심 주제가 뭔지 모르겠다”고 판단해서 검색 순위가 낮아질 수 있어요.

🎨 헤딩 크기는 CSS로 조절해요 “h1이 너무 크고 h3이 딱 내가 원하는 크기야”라는 이유로 h3를 제목으로 쓰면 안 돼요! 헤딩 레벨은 문서의 계층 위치로 정하고, 글자 크기나 색깔 같은 시각적인 부분은 CSS로 따로 조절하면 돼요. 이렇게 하면 모양도 예쁘고 구글 로봇도 만족해요.

중급

검색 엔진 크롤러는 헤딩 구조를 콘텐츠의 주제 관련성(topical relevance)을 판단하는 주요 신호로 활용합니다. h1은 페이지의 핵심 주제를 나타내고, h2-h3는 주제와 관련된 세부 토픽을 계층적으로 제공합니다. 이 구조가 명확할수록 크롤러가 콘텐츠를 정확하게 색인(index)할 수 있습니다.

h1 단일 원칙 페이지당 h1은 하나여야 합니다. 복수의 h1은 페이지의 주제를 모호하게 만들어 SEO에 부정적인 영향을 줄 수 있습니다. h1에는 페이지의 핵심 키워드를 포함시키되, 자연스러운 문장으로 작성해야 합니다.

<!-- 올바른 예: h1 하나, 계층적 h2-h3 -->
<article>
  <h1>TypeScript로 React 앱 만들기</h1>

  <section>
    <h2>환경 설정</h2>
    <h3>Node.js 설치</h3>
    <h3>TypeScript 설정</h3>
  </section>

  <section>
    <h2>컴포넌트 작성</h2>
    <h3>Props 타입 정의</h3>
  </section>
</article>

<!-- CSS로 시각적 크기 분리 -->
<style>
  /* 헤딩 레벨은 의미, 크기는 CSS가 담당 */
  h2 { font-size: 1.5rem; }
  h3 { font-size: 1.2rem; }

  /* 필요시 특정 h2를 더 작게 표시 가능 */
  .sidebar h2 { font-size: 1rem; }
</style>

헤딩 레벨과 시각적 크기의 분리가 중요한 이유 “h4가 시각적으로 딱 맞는 크기라서 h4를 썼다”는 이유로 잘못된 레벨을 선택하는 것이 가장 흔한 실수입니다. 헤딩 레벨은 반드시 문서 내 계층적 위치로 결정하고, 시각적 크기는 CSS font-size로 독립적으로 관리해야 합니다. 이 원칙을 지키면 접근성과 SEO를 동시에 만족시킬 수 있습니다.

심화

구글을 비롯한 검색 엔진은 헤딩을 콘텐츠의 주제 구조를 파악하는 신호로 활용하지만, 헤딩만으로 순위가 결정되지는 않습니다. 헤딩은 콘텐츠 관련성 신호의 일부이며, 구조화된 데이터(Schema.org)와 결합할 때 더 정교한 콘텐츠 이해가 가능합니다.

구글의 헤딩 처리 방식 구글 공식 문서(Google Search Central)에 따르면 제목 태그(<title>)와 h1은 페이지 주제를 파악하는 핵심 신호입니다. 구글은 h1을 검색 결과 스니펫 생성에 활용하며, h2-h3의 내용을 “People Also Ask” 박스와 Featured Snippet 후보로 고려합니다. 그러나 구글은 키워드 밀집(keyword stuffing)과 시각적 스타일 목적의 헤딩 남용을 스팸 신호로 처리합니다.

구조화된 데이터와의 관계 Schema.org Article 타입은 headline(h1에 대응), articleSection(h2에 대응하는 논리적 섹션)을 속성으로 가집니다. JSON-LD로 이 정보를 제공하면 크롤러가 헤딩 구조를 명세 기반으로 해석할 수 있어 Rich Results(리치 결과) 생성 가능성이 높아집니다.

h1 복수 사용 문제 복수의 h1이 SEO에 미치는 영향은 구글 공식 입장(2021년 John Mueller 발언)에 따르면 직접적인 순위 하락 요인은 아닙니다. 그러나 콘텐츠 주제 명확성 측면에서 단일 h1이 권장되며, 특히 SPA(Single Page Application)에서 클라이언트 사이드 라우팅으로 h1이 동적으로 교체되는 경우 크롤러가 각 라우트의 주제를 정확히 파악하기 어려울 수 있습니다. 이 경우 SSR(서버 사이드 렌더링) 또는 정적 생성(Static Generation)을 통해 각 페이지의 h1이 초기 HTML에 포함되도록 해야 합니다.

Core Web Vitals와 헤딩의 간접적 관계 헤딩 구조 자체는 Core Web Vitals(LCP, FID, CLS) 측정값에 직접적인 영향을 주지 않습니다. 그러나 의미 없는 헤딩 남용이나 대용량 헤딩 이미지 사용은 렌더링 성능에 영향을 줄 수 있습니다. SEO 관점에서 헤딩의 주요 역할은 콘텐츠 관련성 신호이며, 이는 페이지 경험 점수(Page Experience Score)와는 독립적으로 평가됩니다.