AI 에이전트는 이미 당신의 사이트를 읽고 있다
이제 사이트의 첫 번째 방문자가 사람이 아닐 수 있다. ChatGPT, Claude, Perplexity 같은 AI 에이전트들은 끊임없이 웹을 크롤링하며 정보를 학습하고, 사용자의 질문에 당신의 콘텐츠를 인용할지 말지를 조용히 결정한다. 문제는, 대부분의 프론트엔드 개발자가 여전히 '사람이 보는 UI'만 최적화하고 있다는 점이다. AI 에이전트가 어떻게 당신의 페이지를 해석하는지에 대한 설계 기준은 아직 팀의 체크리스트에 없는 경우가 대부분이다.
점수 60점짜리 사이트가 의미하는 것
최근 GuardLabs 팀이 공개한 오픈소스 CLI 도구 agent-readiness-cli는 이 문제를 꽤 직접적으로 드러낸다. 한 줄 명령으로 사이트를 분석해 0~100점 사이의 'AI 에이전트 준비도 점수'를 돌려주는 도구인데, 측정 항목을 보면 프론트엔드 개발자에게 익숙한 것들이 뒤섞여 있다. llms.txt 존재 여부, JSON-LD 구조화 데이터의 완성도, robots.txt에서 GPTBot·ClaudeBot에 대한 명시적 처리, canonical과 hreflang 설정, 그리고 /.well-known/mcp.json까지.
흥미로운 건 가중치 배분이다. JSON-LD가 전체 점수의 25%를 차지하며 가장 높다. 그 이유가 명확하다—LLM이 페이지의 성격을 파악할 때 가장 신뢰하는 구조화된 신호가 바로 JSON-LD이기 때문이다. Article, Organization, BreadcrumbList 같은 @type을 얼마나 정확하게, 다양하게 선언하느냐가 AI 에이전트의 콘텐츠 이해도를 직접적으로 좌우한다. Core Web Vitals 점수가 아무리 좋아도 JSON-LD가 빠져 있으면 에이전트 입장에서는 '정체불명의 페이지'일 뿐이다.
시맨틱 HTML의 귀환—이번엔 AI를 위해
이 맥락에서 <details>와 <summary> 태그의 재발견은 단순한 CSS 트릭 이상의 의미를 가진다. dev.to에 소개된 모던 CSS 기법처럼, JavaScript 없이 interpolate-size 속성과 [open] 어트리뷰트 선택자만으로 완성도 높은 아코디언 UI를 구현하는 접근은 두 가지 가치를 동시에 제공한다.
첫째는 접근성이다. 과거의 '체크박스 해킹'이나 scrollHeight 계산 스크립트는 스크린 리더 사용자에게 혼란을 줬지만, 브라우저 네이티브 <details>는 열림/닫힘 상태를 시맨틱하게 전달한다. 둘째는 AI 에이전트의 콘텐츠 접근성이다. JavaScript로 렌더링하거나 숨긴 콘텐츠와 달리, <details> 내부의 텍스트는 DOM에 처음부터 존재한다. 크롤러와 LLM이 페이지를 파싱할 때 해당 콘텐츠를 즉시 읽을 수 있다는 뜻이다. FAQ 섹션을 <details>로 구현하면서 JSON-LD FAQPage 스키마를 함께 선언한다면—사람, 스크린 리더, AI 에이전트 모두를 위한 설계가 하나로 수렴한다.
조용히 쌓이는 메타 설계 부채
한편, Astro 사이트 세 곳에서 동일하게 발생한 og:type 중복 버그 사례는 또 다른 차원의 경고를 던진다. BaseLayout과 BlogLayout이 각각 og:type을 한 번씩 선언하면서, 소셜 플랫폼과 검색 엔진은 첫 번째 값인 website만 읽고 나머지를 무시했다. 블로그 포스트가 수개월 동안 '아티클'이 아닌 '웹사이트'로 분류된 채 유통된 것이다.
이 버그가 무서운 이유는 눈에 보이지 않기 때문이다. 페이지는 정상 렌더링되고, 빌드는 성공하며, 카드 미리보기도 얼추 작동한다. 그러나 AI 에이전트가 페이지 유형을 오분류하는 결과로 이어진다. agent-readiness-cli가 측정하는 meta 점수 항목—og:title, og:description, html lang—이 이 영역과 직결된다. 빌드 파이프라인에 dist/ 폴더를 순회하며 og:type 중복을 감지하는 단순 스크립트 하나를 추가하는 것만으로도 이런 부채는 사전에 차단된다. 도구는 단순할수록 실제로 쓰인다.
프론트엔드 설계의 새로운 기준선
세 가지 소스가 수렴하는 지점은 명확하다. AI 에이전트 시대의 프론트엔드 설계는 '사람이 보기 좋은 UI'를 넘어 '기계가 정확하게 읽을 수 있는 구조'를 동시에 요구한다. 이것은 별도의 작업이 아니다—시맨틱 HTML을 제대로 쓰고, 구조화 데이터를 정확하게 선언하며, 메타태그 중복을 빌드 단계에서 검증하는 것은 원래 웹 표준이 요구해온 것들이다. AI 에이전트의 등장은 우리가 오랫동안 미뤄온 기술 부채를 가시화하는 압력으로 작동하고 있을 뿐이다.
실무에서 시작하는 방법
지금 당장 할 수 있는 것은 세 가지다. 첫째, agent-readiness-cli로 현재 사이트 점수를 측정해보라. 어떤 항목이 가장 낮게 나오는지 확인하는 것이 출발점이다. 둘째, 아코디언·토글·FAQ처럼 JavaScript로 구현된 인터랙티브 컴포넌트를 <details>/<summary> 기반으로 전환할 수 있는지 검토하라—interpolate-size가 지원되는 환경이라면 CSS만으로 충분하다. 셋째, 빌드 스크립트에 메타태그 중복 검사를 추가하라. og:type뿐 아니라 canonical, meta[name=description], og:url도 페이지당 하나만 존재해야 한다.
전망: 구조 설계가 새로운 SEO다
llms.txt가 robots.txt의 AI 버전으로 자리잡아가고 있고, /.well-known/mcp.json이 에이전트 연동의 표준 진입점으로 논의되고 있다. 이 흐름은 프론트엔드 개발자에게 새로운 설계 영역이 생겼음을 의미한다. HTML 구조와 메타데이터 설계가 단순한 SEO 체크리스트가 아니라, AI 에이전트가 당신의 프로덕트를 얼마나 정확하게 이해하고 인용하느냐를 결정하는 핵심 인프라가 되고 있다. 빠르게 만드는 것만큼이나, 제대로 읽히도록 설계하는 것이 프론트엔드 개발자의 새로운 책임이 되는 시대다.