(번역) 시멘틱 HTML이 여전히 중요한 이유

원문: https://www.jonoalderson.com/conjecture/why-semantic-html-still-matters/

언제부턴가 우리는 HTML을 어떻게 작성해야 하는지, 그리고 그것이 왜 중요한지를 잊어버렸습니다.

최신 개발 워크플로우에서는 컴포넌트, 유틸리티 클래스, 자바스크립트 중심의 렌더링에 우선순위를 두고 있습니다. HTML은 기반이 아닌 부산물이 되어버렸습니다.

그리고 이런 변화는 성능, 접근성, 복원력은 물론 기계와 사람이 콘텐츠를 해석하는 방식에도 악영향을 미칩니다.

자바스크립트가 웹을 어떻게 죽이고 있는지 대해서는 다른 글에서 설명한 적이 있습니다. 하지만 해당 글에서 가장 쉽게 고칠 수 있으면서도 간과되는 부분은 시멘틱 HTML입니다.

이 글에서는 우리가 무엇을 잃었는지, 그리고 그것이 왜 여전히 중요한지에 대해 설명합니다.

시멘틱 HTML은 기계가 의미를 이해하는 방식이다.

HTML은 단순히 페이지에 요소를 배치하는 방식이 아닙니다. 의미를 표현하는 어휘가 있는 언어입니다.

<article>, <nav>, <section>과 같은 태그는 장식용이 아닌 의도를 표현하고, 계층 구조를 나타냅니다. 해당 태그들은 기계에게 당신의 콘텐츠가 무엇인지, 그리고 그것이 다른 모든 콘텐츠와 어떻게 연관되어 있는지 알려줍니다.

검색 엔진, 접근성 도구, AI 에이전트, 작업 기반 시스템은 모두 구조적 신호에 의존합니다. 때로는 명시적으로, 때로는 휴리스틱(경험적 추론) 방식으로 말입니다. 모든 시스템에 완벽한 마크업이 필요한 것은 아니지만, 시멘틱 HTML을 활용할 수 있는 경우, 그 구조와 뜻은 명확하게 전달될 수 있습니다. 체계적이지 않고 구조가 분명하지 않은 웹 환경에서, 구조와 의미가 뚜렷하게 드러나는 페이지는 오히려 더 많은 기회와 경쟁력을 가지게 됩니다.

시멘틱 마크업이 더 나은 색인(indexing)이나 추출을 보장하지는 않지만, 현재와 미래에 시스템이 활용할 수 있는 기반을 만들어 줍니다. 이는 품질, 구조, 의도를 나타내는 신호이기도 합니다.

모든 것이 <div> 또는 <span>으로만 이루어져 있다면, 아무 의미가 없습니다.

단순히 나쁜 HTML이 아니라, 의미 없는 마크업입니다.

이 문제를 단순히 '코드의 순수함'의 문제라고 치부한다면, <div>를 쓰든 <section>을 쓰든, 겉으로 보기에 멀쩡하면 그만이고 과연 누가 신경 쓸까요?

하지만 이건 꼼꼼함을 넘어선 문제입니다. 의미 없는 마크업은 단지 사이트를 읽기 어렵게 만드는 것을 넘어서, 렌더링(표현)이나 유지보수, 확장도 어렵게 만듭니다.

이런 추상화는 종종 다음과 같은 마크업을 만들어냅니다.

<div class="tw-bg-white tw-p-4 tw-shadow tw-rounded-md">
  <div class="tw-flex tw-flex-col tw-gap-2">
    <div class="tw-text-sm tw-font-semibold tw-uppercase tw-text-gray-500">
      ACME Widget
    </div>
    <div class="tw-text-xl tw-font-bold tw-text-blue-900">Blue Widget</div>
    <div class="tw-text-md tw-text-gray-700">
      Our best-selling widget for 2025. Lightweight, fast, and dependable.
    </div>
    <div class="tw-mt-4 tw-flex tw-items-center tw-justify-between">
      <div class="tw-text-lg tw-font-bold">$49.99</div>
      <button
        class="tw-bg-blue-600 tw-text-white tw-px-4 tw-py-2 tw-rounded hover:tw-bg-blue-700"
      >
        Buy now
      </button>
    </div>
  </div>
</div>

물론 이 코드는 잘 작동합니다. 스타일이 지정되었고, 렌더링도 됩니다. 하지만 의미론적으로 죽어있습니다.

이 콘텐츠는 제품 목록인가요? 블로그 게시물인가요? 아니면 클릭을 유도하는 컨텐츠인가요? 이 콘텐츠가 무엇인지 알 수 있는 단서가 전혀 없습니다.

스크린 리더, 크롤러 또는 가격 데이터를 추출하려는 에이전트 역시 한눈에 알 수 없습니다.

아래는 의미 있는 구조를 가진 동일한 내용입니다.

<article class="product-card">
  <header>
    <p class="product-brand">ACME Widget</p>
    <h1 class="product-name">Blue Widget</h1>
  </header>
  <p class="product-description">
    Our best-selling widget for 2025. Lightweight, fast, and dependable.
  </p>
  <footer class="product-footer">
    <span class="product-price">$49.99</span>
    <button class="buy-button">Buy now</button>
  </footer>
</article>

이제 마크업에선 구조가 생기고, 의도가 드러나는 스토리를 담고 있습니다. 당신의 CSS를 타깃 할 수 있고, 스크래퍼로 추출할 수 있으며, 스크린 리더기로 탐색할 수 있습니다. 이건 의미가 있는 거죠.

시멘틱 HTML은 접근성의 기반입니다. 구조와 의미가 없으면 보조 기술이 콘텐츠를 해석할 수 없게 됩니다. 스크린 리더기는 무엇을 읽어야 할지 모르고 키보드 사용자는 막히게 됩니다. 음성 인터페이스는 div 태그에 묻혀 있는 것을 찾을 수 없습니다. 깔끔하고 의미 있는 HTML은 단순히 좋은 관행이 아닙니다. 바로 사람들이 웹에 접근하는 방식입니다.

프레임워크 자체가 본질적으로 나쁘거나 접근성이 안 좋다는 말은 아닙니다. 테일윈드, 아토믹 클래스, 인라인 스타일은 특히 복잡한 프로젝트나 대규모 팀에서 매우 유용할 수 있습니다. 이런 것들은 인지적 부담을 덜어주고, 작업 속도를 향상 시킬 수 있습니다.

하지만 그것들은 도구일 뿐, 근본적인 해답은 아닙니다. 그리고 모든 구성 요소가 거의 동일한 유틸리티 클래스의 혼란스러운 집합체로 변하거나, 레이아웃이나 브레이크포인트 조정이 추가되면 목적이 흐려지게 되고, 구조가 사라지면 목적이 불분명해집니다.

이것은 추상화에 관한 이야기가 아닙니다. 그 과정에서 우리가 잃게 되는 것에 대한 이야기입니다.

그리고 그 손실은 의미론적 측면에만 영향을 미치는 것이 아닌 성능에도 영향을 미칩니다. 사실상 모던 웹은 어느 때보다 더 느리고, 더 무거우며, 더 취약하게 느껴지는 가장 큰 이유 중의 하나입니다.

의미론적 부패가 성능을 망가뜨립니다.

우리는 일반적으로 HTML이 단순히 렌더링 대상일 뿐이라고 생각해 왔습니다. 브라우저에 임의의 마크업을 던져 넣어도 알아서 처리해 줄 거라고 믿는 거죠. 그리고 실제로도 그렇습니다. 브라우저는 놀랍게도 우리가 엉망진창으로 만들어도 잘 고쳐줍니다.

그러나 그 관용에는 대가가 따릅니다.

렌더링 엔진은 결함-허용(fault-tolerant)으로 설계되었습니다. 역할 추론, 나쁜 구조 보완 등 의도한 대로 렌더링을 시도합니다. 그러나 매번 <div>의 난잡한 구조가 무엇을 의미하는지 추측할 때마다 시간이 소모됩니다. 이는 CPU 사이클과 GPU 시간을 의미합니다. 특히 모바일 환경에서는 전력 소모로 이어집니다.

이제 이런 비효율이 실제로 어디서, 어떻게 문제가 되어, 왜 신경 써야 하는지 차근차근 살펴봅시다.

큰 DOM은 렌더링 속도가 느립니다.

DOM의 모든 단일 노드는 오버헤드를 발생합니다. 렌더링 과정에서 브라우저는 DOM 트리를 탐색하고, CSSOM을 구축하며, 스타일을 계산하고, 레이아웃을 해결하며, 픽셀 단위로 그리게 됩니다. 많은 노드는 각 단계에서 더 많은 작업을 수행한다는 의미가 됩니다.

단순히 다운로드 크기만의 문제는 아닙니다(물론 그것도 중요하고, 마크업이 많을수록 바이트 수가 증가하고 잠재적으로 압축 효율이 떨어질 수 있습니다). 이는 렌더링 성능에 관한 것입니다.
크기가 커진 DOM은 더 긴 레이아웃 및 페인트 단계, 더 많은 메모리 사용량 그리고 더 높은 에너지 사용을 의미합니다.

심지어 모달을 열거나 리스트를 확장하는 간단한 상호작용도 거대해진 DOM을 크롤링하여 리플로우를 유발할 수 있습니다. 그리고 갑자기 "단순한" 페이지가 지연되거나 끊기거나 버벅거리게 됩니다.

이는 크롬 개발자 도구에서 확인할 수 있습니다. Performane탭을 열고 추적을 기록한 다음 레이아웃 엔진이 작동할 때마다 플레임 차트가 활성화되는 모습을 확인하세요.

재밌는 사실: 파싱은 병목이 아닙니다. 크로미움 같은 브라우저는 최신 CPU에서 HTML을 초당 수십 GB 속도로 처리할 수 있습니다. 진짜 비용은 CSSOM 구축, 레이아웃, 페인트, 합성 단계에서 발생합니다. 또한 HTML 파싱은 비지연 처리(non-deferred)된 <script>나 렌더링 차단 스타일 시트를 만나야만 차단됩니다. 이는 깔끔한 마크업이 여전히 중요하지만, 동시에 똑똑한 로딩 순서도 필요하다는 점을 다시 한번 강조합니다.

복잡한 트리는 레이아웃 스래싱을 유발합니다.

중요한 것은 단순히 마크업의 양이 아니라 구조입니다. 깊게 중첩된 구조, 불필요한 래퍼, 지나치게 추상화된 컴포넌트는 이해하기 어렵고 렌더링 비용이 높은 DOM 트리를 생성합니다. 브라우저는 변경 사항이 어떤 부분에 영향을 미치는지 파악하기 위해 더 많은 노력을 기울여야 하며, 그 지점에서 문제가 발생하기 시작합니다.

단일 클래스를 토글 하면, 뷰포트 전체의 레이아웃이 무효화될 수 있습니다. 이 변경 사항을 부모-자식 간의 체이닝을 통해 연쇄적으로 전달되어 레이아웃 이동과 시각적 불안정성을 유발합니다. 컴포넌트가 예상하지 못하게 재배치됩니다. 스크롤 고정 기능이 실패하고 사용자는 상호작용 도중에 위치 정보를 잃게 됩니다. 이는 전체적인 사용자 경험을 불안정하게 만듭니다.

이 모든 작업이 실시간으로 모든 상호작용할 때마다 발생하기 때문에 프레임 예산에 영향을 미칩니다. 60 fps를 목표로 한다면? 프레임당 약 16ms 밖에 주어지지 않습니다. 이 예산을 초과하면 사용자는 곧바로 지연됨을 느끼게 됩니다.

크롬 개발자 도구에서 "레이아웃 이동 영역(Layout Shift Regions)"이나 누락된 프레임이 쌓이는 "프레임(Frame)" 그래프에서 확인할 수 있습니다.

DOM을 변경할 때 브라우저가 항상 전체 트리 레이아웃을 다시 처리 않습니다. 점진적 레이아웃 처리가 이루어지죠. 하지만 깊게 중첩되거나 모호한 마크업은 여전히 비용이 많이 드는 상위 요소 검사를 유발합니다. 페이스북의 "Spineless Traversal" 같은 프로젝트는 많은 노드를 검사해야 할 때 브라우저가 여전히 성능 저하를 겪는다는 점을 보여줍니다.

중복 CSS는 재계산 비용을 증가시킵니다.

거대해진 DOM도 충분히 나쁘지만, 거대해진 스타일 시트는 상황을 더욱 악화시킵니다.

모던 CSS 워크플로우는 특히 컴포넌트화된 시스템에서는 종종 중복이 발생합니다. 각 컴포넌트가 자체 스타일을 선언하는데, 심지어 반복되는 경우에도 마찬가지입니다. 연쇄적이지 않고 공유된 문맥도 없습니다. 특수성은 혼란스러워지고, 오버라이드가 기본이 되겠죠.

예를 들어, 흔히 다음과 같습니다.

/* button.css */
.btn {
  background-color: #006;
  color: #fff;
  font-weight: bold;
}

/* header.css */
.header .btn {
  background-color: #005;
}

/* card.css */
.card .btn {
  background-color: #004;
}

각 파일은 동일한 요소를 재정의합니다. 브라우저가 이 모든 것들을 파싱하고 수행하고 재조정해야 합니다. 이를 수백 개 컴포넌트로 확대하면 CSSOM(브라우저의 모든 CSS 규칙을 내부적으로 모델링한 구조)이 풍선처럼 불어나게 됩니다.

무언가 변경될 때마다(클래스 토글과 같은), 브라우저는 어떤 규칙이 어디에 적용되는지 재평가해야 합니다. 더 많은 규칙은 더 많은 재개산을 해야 합니다. 그리고 저사양 기기에는 이 과정으로 인해 병목 현상이 발생하게 됩니다.

테일윈드 같은 아토믹 CSS 시스템은 파일 크기를 줄이고 재사용성을 높일 수 있습니다. 하지만 의도적으로 사용할 때만 그렇습니다. 모든 컴포넌트가 수십 개의 유틸리티 클래스로 감싸지고, 각 유틸리티가 조금씩 수정될 때마다(여기는 여백, 저기는 폰트) 결국 수천 개의 고유한 조합이 생겨납니다. 그중 상당수는 거의 똑같습니다.

문제는 단순히 크기만이 아닙니다. 그것은 변동성입니다.

브라우저는 선택자를 오른쪽에서 왼쪽으로 일치시킵니다(예: div.card p span -> 부모 -> 기타 순으로 확인). 이는 명확하고 구체적인 선택자에게는 효율적이지만 거대해진 깊은 트리나 일반적인 연쇄 규칙은 많은 오버 캐싱을 유발합니다.

자동 생성된 클래스는 캐싱 및 타겟팅을 무효화합니다.

.sc-a12bc, .jsx-392hf, .tw-abc123 같은 클래스 이름을 흔히 볼 수 있습니다. 이는 종종 CSS-in-JS 시스템, 범위 지정 스타일, 빌드 해싱의 결과물입니다. 의도는 명확합니다. 전역 충돌을 피하기 위해 스타일을 로컬화한 것이죠. 나쁜 생각은 아닙니다.

하지만 이 접근법은 또 다른 종류의 취약점을 가져옵니다.

만약 클래스가 일시적이거나 빌드마다 변경된다면 다음과 같은 문제가 발생합니다.

• 분석 태그가 깨집니다.
• e2e 테스트 시 지속적인 유지보수가 필요합니다.
• 캐싱 전략이 무너집니다.
• 마크업 차이점을 읽을 수 없습니다.
• CSS는 기본적으로 재사용이 불가능해집니다.

성능 관점에서 마지막 요점이 매우 중요합니다. 캐싱은 오직 예측 가능한 상황에서만 효과적입니다. 브라우저의 능력은 파싱 된 스타일시트를 캐싱하고 재사용할 수 있는 일관된 선택자에 의해 의존됩니다. 모든 컴포넌트, 모든 빌드, 모든 배포마다 클래스 이름이 변경된다면 브라우저는 모든 요소를 재파싱하고 재적용해야 합니다.

더 나쁜 점은, 이런 구조가 외부 도구들에 취약한 임시방편에 의존하게 된다는 것입니다. 태그 매니저를 통해 결제 프로세스 내 버튼을 타겟팅하고 싶으신가요? 해시 처리된 컴포넌트가 세 겹으로 감싸져 있다면, 행운을 빌어야 할 것입니다.

이것은 가상의 문제가 아닙니다. 현대 프런트엔드 스택에서 흔히 발생하는 문제점이며, 코드, 툴링, 렌더링 경로 등 모든 것을 불필요하게 거대하게 만드는 원인입니다.

예측 가능하고, 의미론적 클래스 이름은 단순히 여러분의 작업을 편리하게 할 뿐만 아니라 웹을 더 빠르게 만듭니다.

시멘틱 태그는 레이아웃 힌트를 제공할 수 있습니다.

시멘틱 HTML은 의미론적, 접근성에 관한 것이 아닙니다. 이것은 스케폴딩과 구조입니다. 그리고 그 구조는 당신과 브라우저 모두에게 작업할 수 있는 기반을 제공합니다.

<main>, <nav>, <aside>, <footer>와 같은 태그는 단순히 의미론적 뿐 아니라 기본적으로 블록 레벨 요소이며, 자연스럽게 페이지를 분할해 줍니다. 이런 분할은 종종 브라우저가 콘텐츠를 처리하고 렌더링 하는 방식과 일치합니다. 성능 향상을 보장하지는 않지만, 그 조건을 마련해 줍니다.

레이아웃에 명확한 경계가 있을 때 브라우저는 작업을 보다 효율적으로 범위 지정할 수 있습니다. 스타일 재계산을 분리하고 불필요한 재흐름을 방지하며 스크롤 컨테이너나 고정 요소 같은 요소를 더 잘 관리할 수 있습니다.

더 중요한 것은 페인트와 합성 단계에서 브라우저는 브라우저가 렌더링 작업을 멀티 스레드에 분산시킬 수 있다는 것입니다. GPU 합성 파이프라인의은 잘 구조화된 DOM 영역으로부터 이점을 얻습니다. 특히 contain: paint 또는 will-change: transform같은 속성과 함께 사용될 때 더욱 그렇습니다. 격리된 레이어를 생성함으로써 페이지의 거대한 부분을 다시 래스터화 하는 오버헤드를 줄일 수 있습니다.

만약 중첩된 거대한 <div>들로 되어있다면, 다양한 종류의 격리를 명확히 할 기회가 없어지게 됩니다. 모든 상호작용, 애니메이션 또는 리아시즈 이벤트는 전체 트리에 영향을 미치는 리플로우와 리페인트를 유발할 위험이 있습니다. 단순히 자신에게만 어려움을 주는 것이 아니라 렌더링 엔진의 병목 현상을 일으키는 것입니다.

간단히 말해서: 시멘틱 태그는 브라우저와 싸우는 대신에 당신의 작업을 도와주게 됩니다. 마법은 아니지만 마법이 가능하도록 만드는 것입니다.

애니메이션과 합성 재앙

애니메이션을 잘 구조화된 HTML이 빛을 발하거나... 아니면 재앙을 겪게 됩니다.

모던 브라우저는 애니메이션 작업을 GPU로 오프로드하려고 합니다. 이는 60 fps 이상의 부드러운 전환을 가능하게 하는 비결입니다. 하지만 이를 위해서는 브라우저가 애니메이션 요소를 별도의 합성 레이어로 분리해야 합니다. 특정 CSS 속성만이 이러한 GPU 가속 처리를 받을 수 있는데, 특히 transfomr과 opacity 속성이 대표적입니다.

top, left, width, margin과 같은 요소를 애니메이션 하면 레이아웃 엔진이 작동됩니다. 이는 변경된 요소 아래에 있는 모든 요소의 레이아웃을 재계산한다는 뜻이며, 메인 스레드 작업으로 이어지는 비용이 많이 드는 작업입니다.

간단한 페이지라면? 어쩌면 괜찮을 수도 있습니다.

수십 개의 형제 요소와 종속성을 가진 깊게 중첩된 컴포넌트라면? 모든 애니메이션의 레이아웃 스레싱를 유발하게 됩니다. 그리고 애니메이션 프레인 예산이 16ms(60 fps의 한계)를 초과하면 상황이 불안정해집니다. 애니메이션이 끊기고, 상호작용이 지연되며, 스크롤이 느려집니다.

개발자 도구의 성능 패널에서 이를 확인할 수 있습니다. 레이아웃 재계산, 스타일 무효화, 페인트 작업이 플레임 차트를 불타오르게 하죠.

시멘틱 HTML도 여기서 도움이 됩니다. 적절한 구조적 경계는 모던 CSS 컨테이너 전략을 더 효과적으로 활용할 수 있게 합니다.

contain: layout;은 브라우저에게 해당 요소 외부 레이아웃 재계산이 필요 없음을 알립니다.
will-change: transform;은 합성 레이어가 필요함을 암시합니다.
isolation: isolate;와 contain: paint;는 시각적 파급 효과 방지 및 GPU 레이어 강제 적용에 도움이 됩니다.

하지만 이런 기술은 DOM 구조가 합리적일 때만 효과적입니다. 만약 애니메이션 컴포넌트가 예측 불가능한 일반 <div> 요소들 사이에 중첩되어 있다면, 브라우저는 이를 깨끗하게 격리할 수 없습니다. 어떤 요소가 영향을 받을지 알 수 없기 때문에 안전하게 모든 것들을 재계산합니다.

이는 브라우저의 결함이 아니라 개발자의 실패입니다.

애니메이션은 단순히 무엇을 움직이는지에 관한 것이 아니라 움직여서는 안 되는 것에 관한 것입니다.

렌더링과 페인팅은 모던 엔진에서 병렬 작업으로 이루어집니다. 하지만 DOM/CSS 변경은 종종 메인 스레드 동기화를 강제하여 이 장점들을 없애버립니다.

will-change: transform 또는 최신 layer() 구문을 통한 CSS 레이어링은 GPU에 합성 작업을 별도로 처리하도록 지시합니다. 이는 메인 스레드에서의 레이아웃 및 페인팅을 피하게 하지만, DOM 구조가 별개의 레이어링 컨테이너를 허용할 때에만 가능합니다.

CSS 컨테이너 및 가시성: 강력하지만 취약합니다.

모던 CSS는 성능 관리를 위한 강력한 도구를 제공하지만, HTML이 숨 쉴 공간을 마련해 줄 때만 효과적입니다.

예를 들어 contain은 contain: layout, paint 또는 심지어 size를 사용해 브라우저에 "이 박스 밖을 보지 마라 - 여기 있는 것을 페이지의 나머지 부분에 영향을 미치지 않는다"고 말할 수 있습니다. 특히 동적 인터페이스에서 레이아웃 재계산 비용을 크게 줄일 수 있습니다.

하지만 이는 마크업에 명확한 구조적 경계가 있을 때만 작동합니다.

콘텐츠가 의미론적이지 않은 래퍼의 얽힌 구조에 갇혀 있거나, 컨테이너가 예상치 못한 스타일이나 종속성을 상속받는다면, 컨테이너 기능은 신뢰할 수 없게 됩니다. 격리할 수 없는 요소는 안전하게 컨테이너로 감싸지 못하기에 브라우저는 그 위험을 감수하지 않을 것입니다.

마찬가지로 content-visibility: auto는 모던 CSS 도구 중 가장 과소평가된 기능 중 하나입니다. 이 기능은 화면에 표시되지 않는 요소의 렌더링을 브라우저가 건너뛰도록 하여 효과적으로 "가상화(virtualising)"합니다. 이는 긴 페이지, 피드 또는 무한 스크롤 컴포넌트에 매우 유용합니다.

하지만 주의사항이 따릅니다. 예측 가능한 레이아웃, 스크롤 고정, 구조적 일관성이 필요합니다. DOM이 지저분하거나 컴포넌트 트리가 상하로 스타일과 종속성을 누출하면 역효과가 나타납니다. 레이아웃 점프, 렌더링 버그, 포커스 상태 오류가 발생하죠.

이것들은 만능 해결책이 아닙니다. 성능 계약이죠. 지저분한 마크업은 그 계약을 깨드리게 됩니다.

시멘틱 HTML과 깔끔하게 잘 구조화된 DOM이 바로 이러한 도구들을 가능하게 하는 근본적인 요소입니다.

MDN 문서에서는 contain: content(layout+patin+style 단축형)이 브라우저가 전체 하위 트리를 독립적으로 최적화할 수 있게 하는 방식을 설명합니다. 실제 A/B 테스트 결과, content-visibility: auto를 사용한 전자상거래 페이지에서 INP 지연 시간이 개선된 것으로 나타났습니다.

에이전트는 새로운 사용자이며 구조를 중요하게 생각합니다.

웹은 더 이상 인간만을 위한 공간이 아닙니다.

검색 엔진이 첫 번째 물결이었습니다. 콘텐츠를 분석하고 의미를 추출하여 구조와 의미론에 기반해 순위를 매겼죠. 하지만 이제 우리는 AI 에이전트, 어시스턴트, 스크래퍼, 태스크 실행기, 대규모 언어 모델 기반 자동화의 시대에 접어들고 있습니다. 이 시스템들은 사이트를 둘러보지 않습니다. 스크롤하지도, 클릭도 하지 않죠. 다만 분석만 할 뿐입니다.

그들은 당신의 마크업을 보고 묻습니다.

• 이것은 무엇인가?
• 어떻게 구조화되어 있는가?
• 무엇이 중요한가?
• 다른 모든 것과 어떻게 연관되는가?

깨끗하고 의미론적인 DOM은 이러한 질문에 명확히 답합니다. 뒤엉킨 div의 집합은 그렇지 않습니다.

이러한 에이전트들이 동일한 위젯을 판매한다고 주장하는 열 개의 사이트 중에서 선택해야 할 때, 해석하고 추출하며 요약하기 쉬운 사이트가 승리할 것입니다.

이는 가설이 아닙니다. 구글 쇼핑 시스템, 퍼플렉시티 같은 요약 에이전트, 아크 같은 AI 브라우저, 접근성 보조 도구 등이 모두 이러한 변화의 사례입니다. 귀하의 사이트는 더 이상 시각적 경험이 아닙니다. 인터페이스이며, API이고, 데이터셋일 뿐입니다.

당신의 마크업이 이를 지원하지 못한다면? 당신은 그들의 대화에서 배제됩니다.

물론, 스마트 시스템은 필요할 때 구조를 추론할 수 있고 실제로 그렇게 합니다. 하지만 이는 추가 작업이고 부정확하며, 위험합니다.

경쟁 환경에서 잘 구조화된 마크업은 단순한 최적화가 아니라 차별화 요소입니다.

구조는 회복탄력성이다.

시멘틱 HTML은 단순히 기계가 콘텐츠를 이해하도록 돕는 것이 아닙니다. 압박 속에서도 견딜 수 있는 인터페이스를 구축하는 것입니다.

이는 단순히 좋은 관행이 아니라 현실 세계를 위한 소프트웨어를 구축하는 방식입니다.

왜냐하면 실제 사용자는 불안정한 연결을 가지며, 실제 기기는 제한된 성능을 가집니다. 실제 세션에는 테스트하지 않은 극단적 사례가 포함되어 있기 때문입니다.

의미론적 마크업은 기준점이면서, 대체 수단이자 기반이 됩니다.

구조는 선택 사항이 아닙니다.

성능, 접근성, 검색 가능성 또는 복원력을 위해 구축과 사이트가 빠르고 이해하기 쉬우며 적응력이 있기를 원한다면, 의미 있는 HTML로 시작하세요.

마크업을 사후 고려사항으로 취급하지 마세요. 도구가 구조를 묻어버리게 두지 마세요. 별들이 정렬되고 자바스크립트가 로드될 때만 작동하는 인터페이스를 구축하지 마세요.

테일윈드를 사용하는 걸 막지 않겠습니다. 리액트를 사용하는 걸 막지도 않겠습니다. 하지만 신중하게 접근하라고 요구합니다. 의도를 담아 구조를 설계하라고. 단순히 인간에게만이 아니라 브라우저, 봇, 에이전트 모두에게 이야기를 전하는 코드를 작성하라고.

이것은 향수가 아닙니다. 이것은 인프라입니다.

그리고 웹이 다가올 복잡성, 자동화, 기대의 물결을 견뎌내려면 우리는 웹을 제대로 구축하는 방법을 기억해야 합니다.

그것은 HTML을 작성하는 방법을 기억하는 것에서 시작됩니다. 그리고 우리가 왜 그런 방식으로 작성하는지 이해하는 것에서 시작됩니다. 자바스크립트의 부산물이나 도구의 산물이 아니라, 그 이후 모든 것의 기초로서 말입니다.