div만 잔뜩 써도 사이트가 잘 돌아가는데, 굳이 시맨틱 태그로 바꿔야 할까요? 저도 한때 그렇게 생각했습니다. 그런데 Lighthouse 접근성 점수가 바닥을 치고, 애드센스 첫 신청이 거절당하고 나서야 생각이 바뀌었습니다. 시맨틱 HTML은 단순한 코드 스타일 문제가 아니라, 크롤러와 사람이 동시에 읽을 수 있는 구조를 만드는 문제였습니다.
접근성이 바닥이었던 이유, div 중첩 구조 때문이었습니다
처음 블로그를 만들 때 저는 wrap, container, content, post-area 이렇게 div를 4단 중첩으로 쌓았습니다. 기능은 멀쩡히 돌아갔습니다. 그런데 3개월 뒤 같은 코드를 다시 열었을 때, 어디가 본문이고 어디가 사이드바인지 파악하는 데 꽤 오래 걸렸습니다. 태그 이름에 정보가 없으니 클래스명만 보고 맥락을 유추해야 했습니다.
솔직히 말하면, 저는 당시에 "클래스명을 잘 붙이면 되지 않나?"라고 생각했습니다. post-area라고 써놨으면 본문인 줄 알겠지 하는 식이었습니다. 그런데 그건 사람이 읽는 주석과 크롤러가 읽는 구조는 전혀 다른 차원의 이야기라는 걸 몰랐기 때문입니다. 클래스명은 사람 눈에만 보이고, 크롤러는 태그 자체를 봅니다.
문제는 가독성만이 아니었습니다. div 중첩이 깊어질수록 CSS 선택자도 따라서 복잡해졌습니다. 나중에 레이아웃 하나 바꾸려고 손댔다가 전혀 관계없는 영역까지 스타일이 무너지는 경험을 여러 번 했습니다. 구조가 없으니 스타일도 따라서 엉켜갔습니다. 혼자 만든 코드인데도 그랬는데, 팀으로 작업했다면 훨씬 더 심각했을 겁니다.
시맨틱 태그(Semantic Tag)란 태그 이름 자체가 콘텐츠의 역할을 설명하는 HTML 요소를 말합니다. header, nav, main, aside, footer 같은 태그가 여기 해당하고, div나 span처럼 아무 의미 없이 영역만 구분하는 태그와 구별됩니다. HTML Living Standard 명세에서는 section, article, aside, nav 각각의 쓰임을 명확하게 정의하고 있습니다.
결국 시맨틱 태그는 브라우저를 위한 것이 아니라 코드를 읽는 사람을 위한 것이기도 합니다. 태그 이름 자체가 문서의 역할을 설명하면, 코드를 처음 보는 사람도 구조를 훨씬 빠르게 파악할 수 있습니다. 유지보수 비용을 줄이는 가장 쉬운 방법 중 하나입니다. 그리고 그 유지보수를 해야 하는 사람이 3개월 뒤의 자기 자신일 때, 그 고마움을 가장 먼저 느끼게 됩니다.
article과 section, 열 번 읽어도 헷갈렸던 이유
처음에 article과 section 구분이 정말 헷갈렸습니다. "독립적으로 배포 가능한 콘텐츠가 article이다"라는 설명을 열 번 읽어도 감이 안 왔습니다.
제가 결국 이해한 방식은 이렇습니다. article은 그 덩어리만 잘라서 다른 곳에 붙여도 의미가 통하는 것이고, section은 다른 내용과 묶여야 의미가 완성되는 것입니다. 블로그 포스팅 하나는 어디서 봐도 그 자체로 내용이 있으니 article이고, 그 포스팅 안의 소챕터는 포스팅 전체 맥락이 있어야 의미가 통하니 section입니다. 이렇게 생각하니 헷갈림이 많이 줄었습니다.
주의할 점이 있습니다. section에는 반드시 제목이 있어야 의미가 삽니다. 제목 없이 section만 쓰면 그건 그냥 div와 다를 바가 없습니다. MDN 명세에도 "section은 일반적으로 제목을 포함해야 한다"고 명시돼 있는데, 처음에는 이걸 놓치고 section을 레이아웃 구분 용도로만 남발했습니다. 시맨틱 태그를 쓴다고 했지만 실제로는 div를 section으로 이름만 바꾼 수준이었던 겁니다. 지금 생각해보면 그때 제가 한 일은 시맨틱 HTML이 아니라 시맨틱 흉내 HTML이었습니다.
각 태그의 올바른 쓰임
article은 블로그 포스팅, 뉴스 기사, 댓글처럼 단독으로 의미가 통하는 콘텐츠에 사용합니다.
section은 포스팅 내 소챕터처럼 전체 맥락과 묶여야 의미가 완성되는 구역에 사용합니다. 반드시 제목을 포함해야 합니다.
nav는 사이트 전체 메뉴처럼 핵심 내비게이션 블록에만 사용합니다. 소셜 버튼이나 관련 글 목록은 해당하지 않습니다.
aside는 본문과 관련은 있지만 독립적으로 분리 가능한 사이드바, 광고 영역에 사용합니다.
main은 페이지당 하나만 쓰고, 반복되는 헤더나 푸터 영역은 포함하지 않습니다.
WAI-ARIA와의 연결, 시맨틱 태그가 기본값을 제공합니다
WAI-ARIA(Web Accessibility Initiative - Accessible Rich Internet Applications)란 스크린 리더 같은 보조 기술이 웹 콘텐츠를 올바르게 해석하도록 도와주는 기술 명세입니다. 시맨틱 태그를 쓰면 별도의 ARIA 속성 없이도 스크린 리더가 각 영역의 역할을 파악할 수 있습니다. W3C HTML 접근성 매핑 문서에 따르면 nav 태그는 자동으로 navigation 역할을 부여받고, main 태그는 main 역할로 스크린 리더에 전달됩니다.
반대로 말하면, div로만 구성된 페이지에서 같은 효과를 내려면 ARIA 역할 속성을 일일이 붙여야 합니다. 할 수는 있지만, 시맨틱 태그를 쓰면 그 수고를 처음부터 안 해도 됩니다. 접근성이 올라가면 Lighthouse 점수가 올라가고, 이것이 SEO에 간접적으로 연결되는 경로입니다.
시맨틱 태그로 구조를 정리한 뒤 Lighthouse를 다시 돌려보니 접근성 항목 점수가 눈에 띄게 올랐습니다. Lighthouse의 SEO 감사 항목은 메타 태그, 구조화 데이터, 그리고 문서 구조의 논리성을 함께 봅니다. 시맨틱 구조가 잡혔을 때 관련 항목의 경고가 사라진 것을 직접 확인했습니다.
덧붙이고 싶은 건, 접근성이 단순히 "장애인을 위한 배려"로만 좁게 이해되는 경향이 있다는 점입니다. 물론 그것이 핵심이지만, 스크린 리더가 읽기 좋은 구조는 크롤러가 읽기 좋은 구조와 겹칩니다. 접근성을 높이는 게 곧 크롤러 친화적인 코드를 짜는 일이기도 하다는 것, 이 두 개념이 연결돼 있다는 걸 알게 된 게 저한테는 꽤 중요한 발견이었습니다.
크롤러가 본문을 못 찾으면 SEO도 없습니다
애드센스 첫 신청이 거절됐을 때 저는 콘텐츠 분량 문제겠거니 했습니다. 그런데 소스를 다시 뜯어보니 main 태그가 아예 없었습니다. 광고 자리, 사이드바, 본문이 같은 div 레벨에 나란히 쌓여 있는 구조였습니다. 크롤러 입장에서는 어디가 진짜 본문인지 파악하기 어려운 상황이었습니다.
크롤러(Crawler)란 검색 엔진이 웹페이지 내용을 수집하고 색인하기 위해 자동으로 사이트를 탐색하는 프로그램입니다. 구글의 크롤러인 Googlebot은 HTML 구조를 분석해 어느 영역이 본문인지, 어느 영역이 반복 요소인지 구분하려고 합니다. 시맨틱 태그가 명확하게 잡혀 있으면 크롤러가 main 영역을 빠르게 식별하고 핵심 콘텐츠에 집중할 수 있습니다.
인덱싱(Indexing)이란 크롤러가 수집한 페이지 내용을 검색 결과에 반영할 수 있도록 데이터베이스에 등록하는 과정입니다. 구조가 불분명한 페이지는 인덱싱 품질이 낮아질 수 있고, 이것이 검색 노출에 영향을 줄 가능성이 있습니다. 직접 인과를 단정하기는 어렵지만, 시맨틱 구조 정리 이후 애드센스 재신청에서 결과가 달라진 것을 경험했습니다.
nav 태그 오남용도 짚고 넘어갈 필요가 있습니다. 처음에 저는 소셜 공유 버튼 묶음, 관련 글 목록, 카테고리 링크 전부에 nav를 붙였습니다. nav는 사이트의 주요 탐색 블록에만 써야 하는 태그입니다. 소셜 버튼이나 관련 글 목록은 nav가 아니라 일반 목록 태그나 적절한 컨테이너로 처리하는 것이 맞습니다. 잘못 쓰면 구조를 오히려 더 망가뜨린다는 것을 직접 겪고 나서야 알았습니다.
이 경험에서 하나 더 배운 게 있습니다. 애드센스 심사는 "광고를 보여줄 만한 사이트인가"를 판단합니다. 그 판단의 일부가 콘텐츠의 식별 가능성에서 나옵니다. 본문이 명확히 식별되지 않으면 광고를 붙일 대상 자체가 모호해지는 거고, 그 모호함이 거절로 이어졌을 가능성이 높습니다. 콘텐츠 분량만 늘리는 데 집중했던 당시 제가 놓친 지점이었습니다.
시맨틱 태그가 SEO를 직접 올려준다는 주장에 동의하기 어려운 이유
이 부분에서 저는 인터넷에 퍼진 통설에 좀 더 비판적인 입장입니다.
구글은 시맨틱 HTML 사용 여부를 랭킹 직접 요소로 공식 발표한 적이 없습니다. 콘텐츠 품질이 나쁜데 div를 header로 바꾼다고 갑자기 검색 순위가 오르지는 않습니다. 실제로 div로만 가득 찬 블로그가 시맨틱 태그를 완벽하게 적용한 블로그보다 검색 순위가 높은 경우를 봤는데, 이유는 단순했습니다. 콘텐츠가 좋았기 때문입니다.
"시맨틱 태그가 SEO에 좋다"는 말이 널리 퍼진 데는 구조적 이유가 있습니다. 시맨틱 태그를 적용하는 개발자는 대체로 웹 표준과 접근성에 신경 쓰는 사람들입니다. 그런 사람들이 만든 사이트는 콘텐츠 품질도 높고, 로딩 속도도 신경 쓰고, 모바일 최적화도 잘 돼 있는 경우가 많습니다. 결국 검색 순위가 오른 것이 시맨틱 태그 때문인지, 아니면 그 사람이 전반적으로 사이트를 잘 만들기 때문인지 구분하기 어렵습니다. 상관관계를 인과관계로 오해하기 쉬운 지점입니다.
제가 이걸 특히 강조하는 이유는 SEO 콘텐츠 시장 자체가 이 오해를 먹고 자라기 때문입니다. "시맨틱 태그 적용하면 검색 순위 오릅니다"는 문장은 클릭이 잘 되는 제목입니다. 그래서 계속 생산됩니다. 하지만 그 문장 때문에 글을 부실하게 써도 태그만 잘 정리하면 된다는 착각을 하게 됩니다. 저도 그 착각에 한동안 빠져 있었습니다.
그렇다고 효과가 없다는 말은 아닙니다. 접근성 향상이 Lighthouse 점수 개선으로 이어지고, 크롤러의 본문 식별이 인덱싱 품질 향상으로 이어지는 간접 경로는 분명히 존재합니다. 직접 효과는 없지만 간접 효과는 있다는 것, 이 둘을 구분해서 이해하는 것이 중요합니다.
기본기를 갖추되, 거기서 멈추면 안 됩니다
시맨틱 태그는 기본기입니다. 기본기를 갖춘 상태에서 좋은 콘텐츠가 나와야 의미가 있습니다. HTML 구조를 아무리 완벽하게 짜도 글 자체가 부실하면 아무 의미가 없습니다. 순서를 바꾸면 안 됩니다.
저는 애드센스가 첫 신청에서 거절됐을 때 분량을 더 늘리는 쪽으로 먼저 접근했습니다. 그게 틀리진 않았지만 구조 문제를 나중에야 발견했고, 구조를 고친 다음 재신청이 통과됐습니다. 정확히 어느 쪽이 결정적이었는지 지금도 확신하기 어렵습니다. 하지만 둘 다 필요했다는 것만은 분명합니다.
지금 당장 소스를 열어서 div 개수를 세어보십시오. header, nav, main, aside, footer 중 없는 태그가 있다면 그게 시작점입니다. 작은 구조 정리가 코드 유지보수와 협업 효율부터 달라지게 만든다는 것, 그리고 3개월 뒤 자신이 쓴 코드를 다시 읽을 때 얼마나 고마운지, 제가 직접 경험한 가장 확실한 변화였습니다.
시맨틱 태그는 기반을 닦는 일이고, 그 위에 좋은 콘텐츠를 쌓는 것이 본게임입니다.