섹셔닝 콘텐츠의 설계 의도는?

article, section, aside, nav 요소의 설계 의도와 사용 원칙을 이해하고, 콘텐츠 성격에 맞는 섹셔닝 요소를 올바르게 선택하는 방법을 학습합니다

입문 15분 article section aside nav

HTML에는 콘텐츠 영역을 나누기 위한 섹셔닝(sectioning) 요소들이 있습니다. <article>, <section>, <aside>, <nav>는 단순히 콘텐츠를 박스로 묶는 도구가 아니라, 각 영역이 문서 안에서 어떤 역할을 하는지를 브라우저와 보조 기술, 그리고 다른 개발자에게 명시적으로 선언하는 의미 요소입니다. 이 네 가지 요소는 비슷해 보이지만 설계 의도가 분명히 다르며, 잘못 사용하면 시맨틱 구조가 무너져 <div>만 가득한 문서와 다를 바 없어집니다. 어떤 요소를 선택할지는 “어떻게 보이는가”가 아니라 “이 콘텐츠가 문서 안에서 어떤 성격을 가지는가”라는 질문으로 결정해야 합니다.

핵심 특징

  • 📰 article - 독립적으로 배포 가능한 콘텐츠: 해당 요소를 페이지에서 떼어내어 다른 사이트나 RSS 피드에 그대로 게시해도 의미가 통하는 콘텐츠를 감싸는 요소입니다
  • 🗂 section - 주제 단위로 묶인 연관 콘텐츠: 문서 내에서 명확한 주제를 가진 하나의 챕터나 절을 나타내며, 독립적으로 존재하기보다 더 큰 맥락 안에서 의미를 갖는 영역입니다
  • aside - 본문과 간접적으로 연관된 부수 콘텐츠: 주요 내용 흐름에서 벗어난 보충 정보를 담으며, 제거되어도 본문 이해에 영향을 주지 않는 콘텐츠를 위한 요소입니다
  • nav - 사이트 또는 페이지 탐색을 위한 링크 묶음: 단순히 링크가 모여 있는 곳이 아니라, 사용자가 페이지를 이동하거나 섹션을 탐색하기 위한 주요 네비게이션을 담는 요소입니다
  • 아웃라인 알고리즘과 섹션 경계: 이 요소들은 문서의 아웃라인(outline)을 형성하며, 스크린 리더와 같은 보조 기술이 페이지 구조를 사용자에게 설명할 때 직접 활용됩니다

실무에서의 영향

섹셔닝 요소를 올바르게 사용하면 스크린 리더 사용자가 “다음 섹션으로 이동”, “탐색 영역으로 이동” 같은 키보드 단축키로 페이지를 효율적으로 탐색할 수 있습니다. 반면 모든 영역을 <div>로만 구성하면 시각적으로 구분이 되어 있더라도 보조 기술은 구조를 파악하지 못해 접근성이 크게 떨어집니다. 검색 엔진도 <article> 내부를 독립된 콘텐츠 단위로 인식하여 색인하기 때문에, 블로그 게시글이나 뉴스 기사를 <article>로 감싸면 SEO에 직접적인 이점이 생깁니다. <aside>를 올바르게 사용하면 광고나 관련 링크 같은 부수 콘텐츠가 본문과 구별되어, 크롤러가 핵심 콘텐츠와 부수 정보를 혼동 없이 처리할 수 있습니다. 실무에서 이 요소들을 무작위로 사용하거나 <div>와 구별 없이 사용하는 경우가 많은데, 각 요소의 설계 의도를 이해하면 코드 가독성과 접근성, SEO를 동시에 향상시키는 가장 비용 효율적인 방법이 됩니다.

핵심 개념

article과 section - 독립성과 맥락 의존성의 차이

입문

<article>과 <section>은 둘 다 콘텐츠 영역을 묶는 요소지만, 결정적인 차이가 하나 있어요. 그 콘텐츠가 “혼자서도 의미가 있냐”는 거예요!

📰 article은 혼자서도 완전한 콘텐츠예요 신문을 생각해보세요. 신문에서 기사 하나를 오려내서 친구에게 보내줘도, 그 기사는 혼자서 충분히 이해가 되잖아요. <article>이 바로 이런 콘텐츠를 담아요. 블로그 글, 뉴스 기사, 댓글 하나하나 같은 것들이에요. 페이지에서 떼어내도 다른 곳에서 그대로 쓸 수 있는 콘텐츠예요.

📚 section은 더 큰 내용의 한 챕터예요 책의 목차를 생각해보세요. “1장: 소개”, “2장: 기본 개념” 같은 챕터는 책 전체 맥락이 없으면 그 챕터만 보내줘도 의미가 반쪽이에요. <section>이 이런 콘텐츠를 담아요. 긴 페이지에서 “제품 소개”, “가격 정보”, “고객 후기” 같은 구역들이 좋은 예예요. 혼자서는 어딘가에 속한 일부라는 느낌이 들죠.

🔍 어떻게 구분하나요? 간단한 테스트가 있어요 이 콘텐츠를 RSS 피드나 다른 사이트에 그대로 올렸을 때 의미가 통하는가? 통한다면 <article>, 통하지 않는다면 <section>이에요. 마치 레고 블록 하나가 독립적으로도 쓸 수 있는 건지, 아니면 세트 전체와 함께야 의미 있는 조각인지를 생각하는 거예요.

🚨 이 둘을 잘못 쓰면 어떻게 되나요? 모든 영역에 <article>을 쓰면 보조 기술이 “독립된 콘텐츠 단위”가 너무 많다고 혼란스러워해요. 반대로 모든 곳에 <section>을 쓰면 정말로 독립적인 콘텐츠가 어딘가에 속한 것처럼 잘못 해석돼요. 요소 선택이 콘텐츠의 성격을 선언하는 행위이기 때문에 정확히 써야 해요.

중급

<article>과 <section>의 핵심 차이는 콘텐츠의 독립 배포 가능성(distributable)에 있습니다. 이 판단 기준을 이해하면 어떤 상황에서도 올바른 요소를 선택할 수 있습니다.

article - 독립적으로 배포 가능한 콘텐츠 <article>은 해당 콘텐츠를 페이지 맥락 없이도 다른 곳에 그대로 게시할 수 있을 때 사용합니다. HTML Living Standard는 “자급자족하는(self-contained) 구성”이라고 표현합니다. 블로그 게시글, 뉴스 기사, 포럼 게시물, 제품 카드, 개별 댓글이 대표적인 사례입니다.

section - 주제 단위로 묶인 맥락 의존 콘텐츠 <section>은 더 큰 문서 맥락 안에서 하나의 주제 단위를 형성할 때 사용합니다. 단독으로 배포하기보다 전체 페이지의 일부로서 의미를 갖는 콘텐츠입니다. 긴 문서의 챕터, 탭 인터페이스의 각 패널, 랜딩 페이지의 주제별 구역이 해당됩니다.

<!-- 블로그 페이지: 각 게시글이 독립적으로 배포 가능 → article -->
<main>
  <article>
    <h2>JavaScript 호이스팅 이해하기</h2>
    <p>게시글 본문...</p>
    <footer>작성자: 홍길동 | 날짜: 2026-03-09</footer>
  </article>

  <article>
    <h2>CSS Grid 완전 정복</h2>
    <p>게시글 본문...</p>
  </article>
</main>

<!-- 서비스 소개 페이지: 각 구역이 페이지 맥락에 의존 → section -->
<main>
  <section>
    <h2>서비스 소개</h2>
    <p>우리 서비스는...</p>
  </section>

  <section>
    <h2>주요 기능</h2>
    <ul>...</ul>
  </section>

  <section>
    <h2>요금제</h2>
    <!-- 가격 정보 -->
  </section>
</main>

article 안에 section이 들어갈 수 있습니다 긴 기사나 게시글은 내부적으로 주제별 구역으로 나뉠 수 있습니다. 이때 <article> 안에 <section>을 중첩하는 것은 올바른 사용입니다. 반대로 <section> 안에 독립 배포 가능한 콘텐츠가 있다면 <article>을 중첩할 수도 있습니다.

심화

<article>과 <section>의 구분은 WHATWG HTML Living Standard의 섹셔닝 콘텐츠(sectioning content) 분류에서 비롯되며, 두 요소 모두 문서 아웃라인(document outline) 형성에 참여하지만 의미론적 계약이 다릅니다.

HTML Living Standard의 article 정의와 자급자족성 원칙 HTML Living Standard Section 4.3.2는 <article>을 “자급자족하는 구성(self-contained composition)“으로 정의하며, 이 맥락에서 “자급자족”은 RSS 피드, 뉴스 애그리게이터, 기타 배포 채널을 통해 독립적으로 배포하거나 재사용해도 의미가 유지되는 것을 의미합니다. 이는 단순히 시각적 구역이 아닌 콘텐츠의 식별 가능한 단위(identifiable unit)임을 선언하는 행위입니다.

섹셔닝 알고리즘과 암묵적 아웃라인 HTML Living Standard는 헤딩 기반의 아웃라인 알고리즘을 정의합니다. <article>, <section>, <aside>, <nav>는 모두 섹셔닝 콘텐츠로서 각각 새로운 섹션 루트(section root) 또는 암묵적 섹션(implied section)을 생성합니다. 보조 기술은 이 아웃라인을 활용하여 사용자에게 페이지 구조를 제공합니다.

<article> 내부의 헤딩은 상위 문서의 헤딩 계층과 독립적인 아웃라인을 형성할 수 있습니다. 이는 동일한 페이지에 여러 <article>이 있을 때 각각 <h1>으로 시작하는 것이 명세상 허용되는 근거입니다. 반면 <section>의 헤딩은 상위 문서의 아웃라인과 연속성을 유지합니다.

ARIA Landmark와의 관계 접근성 트리(Accessibility Tree)에서 <article>은 ARIA role article에 매핑되고, <section>은 접근 가능한 이름(accessible name)이 있을 때에만 ARIA role region에 매핑됩니다. 이름 없는 <section>은 일반 컨테이너로 처리됩니다. 이는 <section> 사용 시 aria-labelledby 또는 aria-label 속성이나 내부 헤딩 요소가 중요한 이유입니다.

스크린 리더(NVDA, JAWS, VoiceOver)는 <article> 경계에서 “기사” 또는 “article” 랜드마크를 사용자에게 알립니다. 반면 이름 있는 <section>은 “지역(region)” 랜드마크로 공지됩니다. 이 차이가 보조 기술 사용자의 탐색 경험에 직접적인 영향을 미칩니다.

aside와 nav의 설계 의도

입문

<aside>와 <nav>는 각각 완전히 다른 목적으로 만들어졌어요. 이름만 봐도 힌트가 있어요. aside는 “옆에”, nav는 “navigate(이동하다)“에서 왔거든요!

📌 aside는 “참고로 알아두면 좋은 것”이에요 책을 읽다 보면 본문 옆에 작은 글씨로 “참고: 이 개념은 3장에도 나옵니다” 같은 내용이 있죠? 이게 바로 aside의 역할이에요. 본문에서 다루는 주제와 관련은 있지만, 없어도 본문을 이해하는 데 문제가 없는 부수 정보를 담아요. 관련 기사 추천, 작가 소개, 용어 해설 상자 같은 게 여기에 해당해요.

🗺 nav는 “어디로 이동할지 안내하는 지도”예요 <nav>는 사용자가 다른 페이지나 같은 페이지의 다른 부분으로 이동할 수 있는 주요 링크 묶음을 담아요. 웹사이트 상단의 주 메뉴, 페이지 내 목차, 빵 부스러기 경로(breadcrumb) 같은 것들이 <nav> 안에 들어가요. 페이지 안에 있는 모든 링크 묶음을 <nav>로 감쌀 필요는 없어요. 사용자가 탐색을 위해 주로 사용하는 의미 있는 네비게이션만 담으면 돼요.

🤔 aside를 잘못 쓰는 경우는요? aside를 그냥 오른쪽 사이드바처럼 “레이아웃 용도”로 사용하는 경우가 많아요. 하지만 aside는 위치가 아니라 콘텐츠의 성격을 나타내요. 사이드바에 있다고 다 aside가 아니에요. 사이드바 안에 주요 네비게이션이 있다면 <nav>, 독립 기사가 있다면 <article>이 더 적합할 수 있어요.

💡 nav 안에 모든 링크를 넣어야 하나요? 아니에요! 푸터의 약관 링크나 소셜 미디어 아이콘 링크까지 모두 <nav>로 감쌀 필요는 없어요. <nav>는 페이지의 주요 탐색 구조를 나타낼 때만 써야 해요. 너무 많이 쓰면 스크린 리더 사용자가 “탐색 영역이 너무 많다”며 혼란스러워할 수 있어요.

중급

<aside>와 <nav>는 콘텐츠의 역할을 구체적으로 선언하는 요소입니다. 두 요소 모두 본문 흐름과의 관계를 기준으로 사용 여부를 결정해야 합니다.

aside - 간접 연관 부수 콘텐츠 HTML Living Standard는 <aside>를 “해당 요소를 둘러싼 콘텐츠와 간접적으로만 연관된 콘텐츠”로 정의합니다. 핵심 기준은 “제거되어도 본문 이해에 영향을 주지 않는가”입니다. 관련 기사 목록, 사이드바 광고, 작가 소개, 용어 해설 상자, 관련 링크 묶음이 대표적인 사례입니다.

nav - 주요 탐색 링크 묶음 <nav>는 단순한 링크 집합이 아닌, 사이트나 페이지의 주요 탐색 구조를 위한 요소입니다. 페이지 내 모든 링크 묶음에 사용하지 않아야 하며, 사용자가 페이지를 탐색하기 위해 주로 사용하는 링크 그룹에만 적용합니다.

<!-- nav: 주요 탐색 메뉴 -->
<header>
  <nav aria-label="주 메뉴">
    <ul>
      <li><a href="/">홈</a></li>
      <li><a href="/about">소개</a></li>
      <li><a href="/blog">블로그</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <h1>JavaScript 클로저 이해하기</h1>
    <p>본문 내용...</p>

    <!-- aside: 본문과 관련 있지만 없어도 이해에 지장 없음 -->
    <aside>
      <h2>관련 개념</h2>
      <ul>
        <li><a href="/scope">스코프란?</a></li>
        <li><a href="/hoisting">호이스팅</a></li>
      </ul>
    </aside>
  </article>
</main>

<!-- 푸터 링크: 주요 탐색이 아님 → nav 불필요 -->
<footer>
  <p><a href="/privacy">개인정보처리방침</a> | <a href="/terms">이용약관</a></p>
</footer>

<nav>는 페이지에 여러 개 존재할 수 있습니다 상단 주 메뉴, 본문 내 목차, 페이지 이동 페이지네이션 등 여러 <nav>가 공존할 수 있습니다. 이때 각 <nav>를 구분하려면 aria-label 속성으로 이름을 부여하는 것이 접근성 모범 사례입니다.

심화

<aside>와 <nav>는 WHATWG HTML Living Standard에서 각각 Section 4.3.5와 Section 4.3.4에 정의되며, 두 요소는 서로 다른 ARIA landmark role에 암묵적으로 매핑됩니다. 이 매핑이 보조 기술의 탐색 경험에 직접 영향을 미칩니다.

aside의 ARIA complementary 매핑과 맥락 의존 해석 <aside> 요소는 암묵적으로 ARIA role complementary에 매핑됩니다. WAI-ARIA 1.2 명세에서 complementary 역할은 “메인 콘텐츠를 보완하지만 분리되었을 때도 의미가 있는” 섹션을 나타냅니다. 이는 <article> 내부에 있는 <aside>와 <article> 외부(페이지 레벨)의 <aside>가 의미상 다름을 시사합니다. <article> 내부의 <aside>는 해당 기사와의 관계를 나타내고, 외부의 <aside>는 페이지 전체와의 관계를 나타냅니다.

주요 스크린 리더(NVDA, JAWS, VoiceOver)는 <aside> 경계에서 “보완(complementary)” 랜드마크를 공지합니다. 사용자는 단축키로 랜드마크 간 이동이 가능하므로, <aside>가 너무 많으면 탐색 효율이 저하됩니다.

nav의 ARIA navigation 매핑과 다중 nav 처리 <nav> 요소는 암묵적으로 ARIA role navigation에 매핑됩니다. WCAG 2.1 성공 기준 2.4.1(블록 건너뛰기)과 2.4.6(제목과 레이블)을 충족하려면, 페이지에 여러 <nav>가 있을 경우 각각 구별 가능한 레이블이 필요합니다. aria-label 또는 aria-labelledby로 이름을 부여하는 것이 명세 준수와 접근성 모두를 위한 방법입니다.

HTML Living Standard는 <nav>에 “주요(major)” 탐색 블록만 포함해야 한다고 명시합니다. 이를 보조 기술 관점에서 해석하면, 과도한 <nav> 사용은 사용자가 탐색 랜드마크를 통해 페이지를 효율적으로 이동하는 능력을 저해합니다.

Accessibility Tree에서의 landmark 구조 접근성 트리에서 랜드마크 역할을 하는 요소들(<header>, <main>, <nav>, <aside>, <footer>)은 스크린 리더가 제공하는 “랜드마크 목록” 기능을 구성합니다. 이 목록은 시각 장애인이 페이지를 처음 방문할 때 구조를 파악하기 위해 사용하는 핵심 수단입니다. 각 랜드마크에 의미 있는 이름이 있고 적절한 수로 유지될 때 이 기능이 유효하게 작동합니다.

섹셔닝 요소 선택 기준과 실전 판단법

입문

article, section, aside, nav 중 어떤 걸 써야 할지 헷갈릴 때, 순서대로 물어보면 항상 답이 나오는 방법이 있어요!

🧭 먼저 “이 콘텐츠가 어디로 이동시키나요?” 물어보세요 이 영역의 목적이 다른 페이지나 섹션으로 이동하는 링크를 제공하는 것이라면 → <nav>예요. 사용자를 어딘가로 안내하는 지도 역할이라면 nav가 맞아요.

📎 “이 콘텐츠가 본문에 없어도 되나요?” 물어보세요 본문에서 없어도 내용 이해에 문제없는 부수 정보라면 → <aside>예요. “참고로 알아두면 좋은 것”이라면 aside가 맞아요.

📰 “이 콘텐츠를 다른 사이트에 그대로 올릴 수 있나요?” 물어보세요 페이지 맥락 없이도 독립적으로 의미가 완결된다면 → <article>이에요. 블로그 글, 뉴스 기사처럼 그 자체로 완결된 내용이에요.

📚 “이 콘텐츠가 페이지의 한 주제 구역인가요?” 물어보세요 위 셋 중 어디에도 해당하지 않고, 명확한 주제를 가진 구역이라면 → <section>이에요. 단, 주제를 표현하는 헤딩(<h2> 등)이 없다면 그냥 <div>를 쓰는 게 나을 수 있어요.

🚫 마지막 선택지는 <div>예요 위 네 가지 중 어디에도 해당하지 않는다면 의미 없는 컨테이너 <div>를 쓰세요. 시맨틱 의미 없이 레이아웃만을 위한 묶음에 억지로 섹셔닝 요소를 쓰면 오히려 혼란을 줘요.

중급

섹셔닝 요소 선택은 “콘텐츠가 어떻게 보이는가”가 아닌 “콘텐츠가 문서에서 어떤 역할을 하는가”를 기준으로 결정합니다. 다음 우선순위 판단 흐름이 실전에서 효과적입니다.

선택 우선순위 흐름

  1. 탐색 링크 묶음인가? → <nav>
  2. 본문 없이도 이해 가능한 부수 정보인가? → <aside>
  3. 독립적으로 배포 가능한 콘텐츠인가? → <article>
  4. 명확한 주제를 가진 문서의 한 구역인가? → <section> (헤딩 필수)
  5. 해당 없음 → <div>

section 사용 시 헤딩 요구사항 <section>은 반드시 헤딩 요소(<h1>~<h6>)로 이름을 가져야 합니다. 헤딩 없는 <section>은 접근성 트리에서 이름 없는 region이 되어 스크린 리더 사용자가 그 목적을 파악하기 어렵습니다. 헤딩을 붙이기 어려운 콘텐츠 구역은 <div>가 더 적합합니다.

<!DOCTYPE html>
<html lang="ko">
<body>

  <!-- 사이트 탐색: nav -->
  <header>
    <nav aria-label="주 메뉴">
      <a href="/">홈</a>
      <a href="/blog">블로그</a>
    </nav>
  </header>

  <main>
    <!-- 독립 배포 가능한 콘텐츠: article -->
    <article>
      <h1>React Hooks 완전 정복</h1>

      <!-- article 내 주제 구역: section -->
      <section>
        <h2>useState 이해하기</h2>
        <p>...</p>
      </section>

      <section>
        <h2>useEffect 이해하기</h2>
        <p>...</p>
      </section>

      <!-- 본문 이해에 불필요한 부수 정보: aside -->
      <aside>
        <h2>관련 글</h2>
        <ul>
          <li><a href="/redux">Redux vs Context API</a></li>
        </ul>
      </aside>
    </article>
  </main>

  <!-- 레이아웃 전용 컨테이너: div -->
  <div class="ad-container">
    <!-- 광고 배너: aside 고려 가능하지만 div도 무방 -->
  </div>

</body>
</html>

중첩 구조에서의 판단 <article> 안에 <section>, <section> 안에 <article> 모두 허용됩니다. 댓글 목록을 예로 들면, 댓글 전체 구역은 <section>, 각 댓글은 <article>로 처리할 수 있습니다. 중첩 깊이보다 각 요소가 선언하는 의미적 역할이 올바른지가 중요합니다.

심화

섹셔닝 요소 선택은 단순한 시맨틱 코드 작성을 넘어 접근성 트리 구조, 문서 아웃라인, ARIA 랜드마크 설계에 직접 영향을 미칩니다. 이 관점에서 각 요소의 선택 기준을 명확히 이해해야 합니다.

섹셔닝 콘텐츠와 섹셔닝 루트의 구분 HTML Living Standard는 섹셔닝 콘텐츠(sectioning content: <article>, <section>, <aside>, <nav>)와 섹셔닝 루트(sectioning root: <body>, <blockquote>, <details>, <fieldset>, <figure>, <td>)를 구분합니다. 섹셔닝 콘텐츠 내의 헤딩은 문서 아웃라인에 참여하지만, 섹셔닝 루트 내의 헤딩은 상위 아웃라인에서 분리됩니다. 이 차이가 복잡한 페이지 구조에서 아웃라인을 올바르게 설계하는 데 중요합니다.

ARIA 랜드마크 오남용의 접근성 영향 WAI-ARIA Authoring Practices Guide(APG)는 랜드마크 역할을 “주요 콘텐츠 영역”에만 적용하도록 권고합니다. 실제 스크린 리더 사용 연구(WebAIM Screen Reader User Survey)에 따르면, 사용자의 상당수가 랜드마크 탐색을 통해 페이지를 이동합니다. 랜드마크가 너무 많으면 이 탐색 효율이 저하됩니다.

구체적으로, 하나의 페이지에 <nav> 요소가 과도하게 많을 경우 스크린 리더 사용자는 랜드마크 목록에서 어느 <nav>가 주요 탐색인지 파악하기 어렵습니다. WCAG 2.1 성공 기준 2.4.6은 레이블이 설명적이어야 한다고 요구하므로, aria-label을 통한 명확한 이름 부여가 필수입니다.

section과 div 선택의 실용적 기준 HTML Living Standard Section 4.3.3은 <section>이 적절한 헤딩을 가져야 한다고 명시합니다. 헤딩이 없는 <section>은 ARIA role region이 아닌 일반 컨테이너로 처리되며, 접근성 트리에서 의미 있는 구조를 제공하지 못합니다. axe-core, Lighthouse 같은 접근성 검사 도구는 이름 없는 <section> 사용을 경고로 처리합니다. 순수 레이아웃 목적의 컨테이너라면 <div>가 명세상 올바른 선택이며, 불필요한 ARIA 랜드마크를 생성하지 않아 접근성 트리를 단순하게 유지합니다.