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