시맨틱 HTML로 웹페이지 구조를 건물 안내판처럼 나누기

웹페이지를 만들다 보면 모든 구역을 div로 감싸도 화면은 그럴듯하게 나올 수 있습니다. 하지만 이름 없는 상자만 이어지면 메뉴와 본문과 보충 설명이 코드에서 같은 모습으로 보입니다. 나중에 고칠 사람뿐 아니라 화면 읽기 도구도 페이지의 큰 구조를 파악하기 어려워집니다.

시맨틱 HTML은 요소 이름으로 내용의 역할을 알려 주는 작성 방식입니다. 건물 입구, 안내 통로, 중앙 홀, 옆 자료실, 출구에 서로 다른 안내판을 붙이는 장면을 떠올려 보세요. 벽 색과 가구 배치는 바뀌어도 각 공간이 무엇을 위한 곳인지는 남아 있어야 길을 찾기 쉽습니다.

시맨틱 HTML은 모양이 아니라 역할을 적는다

header, nav, main, article, aside, footer 같은 요소는 기본 디자인을 예쁘게 만드는 부품이 아닙니다. 각각 머리말, 주요 탐색, 페이지의 중심 내용, 독립적으로 나눌 수 있는 글, 보충 내용, 바닥글이라는 뜻을 브라우저에 전달합니다. MDN은 이런 콘텐츠 구획 요소가 문서를 논리적인 조각으로 정리한다고 설명합니다.

반대로 div는 특별한 의미가 없는 일반 상자입니다. 단순히 CSS 배치나 스타일을 묶을 상자가 필요하다면 div가 맞습니다. 모든 div를 억지로 다른 요소로 바꾸는 것이 목표가 아니라, 역할이 분명한 큰 구역부터 알맞은 이름을 붙이는 것이 목표입니다.

건물 안내판처럼 큰 구역부터 나눈다

한 페이지의 구조를 건물로 보면 요소의 차이가 선명해집니다. 페이지 맨 위에서 사이트 이름과 공통 기능을 소개하는 header는 입구 안내 공간과 비슷합니다. 주요 링크를 모은 nav는 방문자가 목적지로 이동하는 안내 통로입니다. main은 그 페이지를 찾은 핵심 이유가 들어 있는 중앙 홀입니다.

• header는 페이지나 글의 도입부를 묶습니다.
• nav는 메뉴나 목차처럼 이동을 위한 링크 묶음에 씁니다.
• main은 현재 페이지의 중심 내용을 담습니다.
• article은 따로 공유해도 뜻이 통하는 글이나 항목에 어울립니다.
• aside는 중심 내용과 관련 있지만 떼어도 흐름이 유지되는 보충 구역입니다.
• footer는 작성자, 저작권, 관련 링크 같은 마무리 정보를 담습니다.

페이지의 모든 링크를 nav에 넣을 필요는 없습니다. 문장 속 참고 링크 하나는 탐색 구역이 아닙니다. 화면 오른쪽에 있다고 무조건 aside도 아닙니다. 위치가 아니라 내용의 역할을 기준으로 고릅니다.

짧은 코드에서 역할 차이를 읽어 본다

아래 예시는 요리 글 한 페이지를 큰 구역으로 나눈 모습입니다. CSS가 없어도 어떤 부분이 이동 메뉴이고 어디가 중심 글인지 이름만으로 짐작할 수 있습니다.

<header>
  <h1>초보 요리 노트</h1>
  <nav aria-label="주요 메뉴">...</nav>
</header>
<main>
  <article>
    <h2>토마토 수프 만들기</h2>
    <p>재료와 순서를 설명합니다.</p>
  </article>
  <aside>함께 보면 좋은 칼 사용법</aside>
</main>
<footer>작성자와 문의 링크</footer>

이 구조에서 main은 보통 페이지의 중심 내용 하나를 가리킵니다. article은 블로그 글처럼 독립적으로 읽을 수 있는 묶음이고, aside는 칼 사용법처럼 관련은 있지만 본문에서 잠시 떼어도 요리 순서가 이어지는 내용입니다. 제목 단계도 h1 다음에 큰 소제목을 h2로 두는 식으로 내용의 순서를 보여 줍니다.

랜드마크는 보조 기술이 찾는 큰 표지다

랜드마크는 페이지의 큰 구역을 프로그램이 구분할 수 있게 만든 표지입니다. 화면 읽기 도구는 화면 내용을 음성이나 점자로 전달하는 보조 기술이며, 랜드마크 사이를 이동해 사용자가 긴 페이지를 빠르게 훑도록 도울 수 있습니다. W3C WAI 문서는 main이 주요 내용, nav가 탐색 구역이라는 랜드마크를 자연스럽게 만든다고 안내합니다.

같은 종류의 탐색 구역이 여러 개라면 목적을 구분하는 이름이 필요할 수 있습니다. 예를 들어 상단 메뉴와 글 안의 목차가 모두 nav라면 각각 무엇인지 알 수 있도록 짧은 이름을 붙입니다. 다만 보이는 제목으로 이미 설명할 수 있다면 그 제목을 연결하는 방법을 먼저 검토합니다. ARIA는 HTML에 보조 의미를 더하는 규칙이지만, 기본 HTML 요소가 이미 뜻을 제공할 때 같은 역할을 중복해서 붙일 필요는 없습니다.

section과 div는 남는 자리에 붙이는 이름이 아니다

section은 한 주제로 묶인 독립 구역이며 보통 그 구역을 설명하는 제목이 필요합니다. 단지 테두리나 배경색을 주기 위해 감싸는 상자라면 div가 더 정확할 수 있습니다. article과 section이 헷갈리면 “이 부분만 따로 배포해도 하나의 글로 통하는가”를 먼저 묻습니다. 그렇다면 article에 가깝고, 긴 글 안에서 한 주제를 나누는 장이라면 section에 가깝습니다.

태그를 많이 쓰는 것이 품질 점수는 아닙니다. 작은 소개 페이지라면 header, main, footer만으로도 충분할 수 있습니다. 랜드마크가 너무 많으면 오히려 이동 목록이 복잡해집니다. 먼저 눈에 보이는 큰 구역을 세고, 각 구역의 실제 목적을 한 문장으로 말할 수 있을 때만 이름을 붙입니다.

개발자 도구에서 구조를 읽기만 해 본다

Elements 패널에서 header, nav, main, footer를 검색하면 현재 DOM에 어떤 큰 구역이 있는지 볼 수 있습니다. DOM은 브라우저가 HTML을 읽어 만든 현재 화면 구조입니다. Elements에서 임시로 태그를 바꿔도 원본 파일이나 공개 사이트가 저장된 것은 아니므로 관찰 결과와 실제 수정 상태를 구분해야 합니다.

접근성 트리를 볼 수 있는 브라우저라면 선택한 요소가 어떤 역할과 이름으로 해석되는지도 확인할 수 있습니다. 다만 도구에 랜드마크가 보인다는 사실만으로 페이지 전체가 접근 가능하다고 단정하지 않습니다. 키보드 이동, 제목 순서, 링크 이름, 색 대비와 실제 화면 읽기 도구 사용성은 별도 점검이 필요합니다.

비밀값과 변경 명령은 구조 실습에서 건드리지 않는다

HTML 구조를 연습하는 데 서버 명령, 비밀키, 결제 정보, 데이터 삭제는 필요하지 않습니다. 출처를 모르는 코드를 Console에 붙여 넣거나, 의미를 모르는 설치·삭제 명령을 실행하지 마세요. 공개 페이지를 읽기 전용으로 살펴보는 것부터 시작하면 충분합니다.

운영 사이트 파일을 고칠 때는 변경 대상과 되돌릴 방법을 먼저 확인합니다. 로그인 토큰과 쿠키가 보이는 개발자 도구 화면을 그대로 공유하지 않고, 결제 버튼이나 삭제 기능을 구조 확인용으로 누르지 않습니다. 시맨틱 요소를 바꾼 뒤에는 모양만 보지 말고 링크와 키보드 이동과 모바일 화면이 그대로 작동하는지도 테스트합니다.

오늘 바로 해볼 작은 실습

로그인하지 않은 공개 페이지 한 곳을 열고 10분 동안 읽기만 해 봅니다.

1. 화면에서 머리말, 이동 메뉴, 중심 내용, 보충 내용, 바닥글을 눈으로 나눕니다.
2. 각 구역의 목적을 한 문장씩 적습니다.
3. 개발자 도구의 Elements에서 header, nav, main, aside, footer를 검색합니다.
4. 눈으로 나눈 구역과 실제 요소가 같은지 비교합니다.
5. div로만 된 큰 구역 하나를 골라 의미 있는 요소가 필요한지 질문합니다.
6. 같은 종류의 nav가 여러 개라면 서로 구분되는 이름이 있는지 봅니다.
7. 쿠키와 인증 정보는 열거나 복사하지 않고 개발자 도구를 닫습니다.

정답은 태그 개수가 많아지는 것이 아닙니다. 페이지에서 가장 중요한 내용이 무엇인지, 이동 링크와 보충 내용이 어디인지 코드 이름만으로 설명할 수 있으면 첫 구조 점검을 마친 것입니다. 다음 수정에서는 모양을 바꾸는 CSS와 역할을 바꾸는 HTML을 서로 다른 작업으로 나눠 보세요.