시멘틱 태그는 어렵지 않다, 다만 div가 많을 뿐
사용자를 고려하는 개발자가 되어보자 !
2025년 9월 7일
<div>의 늪에 빠진 나.. 🏊🏻♀️
UMC 워크북을 하면서 시맨틱 태그를 정리한 적이 있었고, 각 태그의 역할도 알고 있었습니다. 하지만 막상 레이아웃을 작성할 때는 습관적으로 div만 사용하는 경우가 많았습니다.
이전에 만든 랜딩 페이지를 다시 열어보니 끝없이 이어진 div만 남아 있었습니다.
상명대 UMC 사이트 디자인을 개편하면서 시맨틱 태그를 다시 떠올리게 됐습니다.
시맨틱 태그, 가끔 난 너무 헷갈려.. 🥹
시맨틱(semantic)은 "의미를 가진다"는 뜻입니다. 시맨틱 태그는 단순히 구조를 나타내는 것이 아니라 태그 자체로 콘텐츠의 성격을 설명합니다.
이론은 간단하지만 실제 코드에서는 헷갈리는 순간이 있습니다. <article>을 언제 사용해야 하는지, <ul> <li> 구조가 필요한데 그냥 div로 작성해버린 경우가 있었습니다.
<article>은 이럴 때!
<article>은 내용만 따로 떼어내도 독립적으로 의미를 가질 수 있을 때 사용합니다. 블로그 포스트, 제품 리뷰 등이 대표적인 예시입니다.
다만 이때도 혼란스러운 순간이 생깁니다. 리뷰 리스트를 생각해보면, 리뷰 하나는 독립적인 콘텐츠라서 <article>처럼 보이지만, 동시에 "리스트 안의 아이템"이라는 점에서 <li>처럼 보이기도 합니다.
<article> vs. <li> 뭐가 맞을까?
리뷰가 3개 있다고 생각했을 때, 리뷰 하나는 독립적인 의미를 가지므로 <article>이 맞아 보입니다. 하지만 댓글 리스트 - 댓글 아이템 관계로 생각하면 <li>에 담는 것도 맞습니다.
이 부분에서 인프런의 접근 방식이 좋은 참고가 됐습니다.
인프런은 강의 목록을 <ul>로 감싸고, 각 강의를 <li>로 표현한 뒤 그 안에 <article>을 넣었습니다.
이 구조가 좋은 이유:
<ul> <li>구조로 스크린 리더가 "목록이며, 항목이 몇 개 있다"고 인식<article>로 각 항목이 독립적인 콘텐츠임을 전달
구조와 의미를 동시에 담을 수 있는 조합입니다.
<p> vs <span>은 뭐가 다를까?
텍스트를 다룰 때 <p>와 <span>도 혼동되는 경우가 있습니다. 단순히 블록/인라인 요소의 차이로만 이해하기 쉽지만, 두 태그는 담고 있는 내용의 성격이 다릅니다.
<p>
<p>는 문단(paragraph)을 표현하는 블록 레벨 요소입니다. 하나의 완결된 의미를 가진 텍스트 덩어리에 사용합니다.
스크린 리더는 <p>를 만나면 문단 단위로 읽어주기 때문에 콘텐츠 흐름을 이해하는 데 도움이 됩니다.
- 사용 시점: 블로그 글, 기사, 상품 설명 등 여러 문장으로 구성된 하나의 주제
- 주의할 점: 줄바꿈을 위해
<br>을 여러 번 사용하는 대신<p>로 문단 구분
<span>
<span>은 의미 없는 인라인 컨테이너입니다. 줄바꿈 없이 문장 내 특정 부분에 스타일이나 스크립트를 적용할 때 사용합니다.
- 사용 시점: 문장 내 특정 단어나 구절을 강조하거나 기능 부여
- 예시: 키워드 색상 변경, 툴팁 추가
시맨틱 태그로 부족할 때, 더 나은 접근성을 위해
인프런 사례에서 보았듯이 시맨틱 태그는 콘텐츠의 의미를 명확하게 전달하는 데 중요합니다. 하지만 시맨틱 태그만으로 접근성을 모두 보장할 수는 없습니다.
예를 들어 아래 버튼은 스크린 리더에서 단순히 "버튼"이라고만 읽힙니다.
이 경우 alt="검색"과 같은 명확한 설명이 필요합니다.
처음 개발할 때 alt 속성을 비워두거나 의미 없는 내용을 담는 경우가 많습니다. 접근성은 사용자를 얼마나 고려했는지 드러나는 부분입니다. 처음에는 크게 중요하지 않아 보일 수 있지만, 실제 사용자 경험에서는 매우 중요한 요소입니다.
토스의 접근성 문서를 보면서 개발자와 일반 사용자 모두에게 왜 중요한지 새삼 느낄 수 있었습니다.
프로젝트 개선기: AI와 함께 💻
상명대 UMC 사이트 디자인을 개편하면서 시맨틱 태그와 접근성 가이드라인을 프로젝트에 적용하고자 했습니다. 이미 작성된 코드가 많았고 시간이 한정적이어서 빠르게 수정할 필요가 있었습니다.
진행 방식:
- 디자인 우선 적용
- 시맨틱 태그 및 접근성 가이드라인 별도 정리
- AI를 활용해 전체 프로젝트에 일괄 적용
eslint로 해결하는 방법도 있지만 클로드를 한번 사용해보고 싶었어요..
클로드가 수정한 결과, 다양한 부분에서 도움을 받았습니다.
완벽한 가이드라인을 제공하지 못해 AI 결과물이 100% 원하는 형태는 아니었지만, 일정 수준 이상의 일관성을 확보할 수 있었습니다. 가이드라인을 보완해 나가면 접근성 개선을 더 효율적으로 적용할 수 있을 것 같습니다.
마치며
다음 프로젝트에서는 <div>를 작성하기 전에 잠시 멈추고, "이 태그가 어떤 의미를 가질 수 있을까?"를 고민하는 습관을 길러보려고 합니다.
AI나 ESLint 같은 도구를 활용해 프로젝트 전체에서 접근성을 지켜나가는 방법도 시도해보면서, 사용자와 개발자 모두에게 좋은 서비스를 만들기 위해 노력해보겠습니다.
작은 습관과 도구의 힘으로 조금씩 더 나은 코드를 만들어 봅시다!! 🌀