ChatGPT, Gemini, Perplexity가 읽을 수 있는 사이트를 만드는 개발자 가이드
요약
LLM 기반 검색 엔진(ChatGPT, Gemini, Perplexity 등)이 웹사이트 콘텐츠를 효율적으로 파싱할 수 있도록 만드는 기술적 구현 가이드를 제공합니다. 구조화된 데이터 활용과 llms.txt 배포 등 기계가 읽기 쉬운(machine-readable) 환경 구축 방법을 다룹니다.
핵심 포인트
- LLM 엔진은 실시간 요청 기반으로 작동하므로 클라이언트 사이드 렌더링 대응이 중요함
- Schema.org JSON-LD를 활용해 엔티티와 관계를 명확히 전달해야 함
- FAQPage, HowTo 등 특정 스키마는 답변 엔진의 정보 추출에 매우 효과적임
- llms.txt를 통해 LLM 전용 Markdown 기반 진입점을 제공할 것을 권장함
대부분의 "AI SEO" 콘텐츠는 좋은 콘텐츠를 작성하고, 권위를 구축하며, 최신 상태를 유지하라는 전략 단계에서 멈춥니다. 괜찮은 조언이지만, 개발자들이 실제로 신경 쓰는 부분, 즉 무엇을 _배포(ship)_할 것인가에 대한 부분은 놓치고 있습니다. 레포지토리(repo)에 어떤 파일을 추가해야 할까요? <head>에는 어떤 마크업(markup)을 넣어야 할까요? 그리고 AI 크롤러(crawler)가 클라이언트 사이드 렌더링(client-rendered) 방식의 SPA에서 막히지 않고 사이트를 실제로 파싱(parse)할 수 있도록 robots.txt에 무엇을 작성해야 할까요?
이것은 구현 계층(implementation layer)에 관한 이야기입니다. 군더더기 없이 LLM 기반 검색을 위해 사이트를 기계가 읽을 수 있게(machine-readable) 만드는 기술적인 요소들만 다룹니다.
이것이 SEO와 다른 문제인 이유
전통적인 검색 크롤러(search crawler)는 사이트 전체를 인덱싱(indexing)하고 저장하며 주기적으로 재방문합니다. 반면 LLM 기반 답변 엔진(answer engines)은 다르게 작동합니다. 대부분의 엔진은 요청 시(on demand) 콘텐츠를 가져오고, 이를 제한된 컨텍스트 윈도우(context window)에 유지하며, 귀하의 사이트에 대한 영구적인 인덱스(index)를 구축하지 않습니다. 이는 다음과 같은 의미를 갖습니다:
- Googlebot이 결국 인덱싱할 수 있는 무거운 클라이언트 사이드 렌더링(client-side rendering)은, 실시간으로 페이지를 가져오는 LLM에게는 해결되지 않은 상태로 남을 수 있습니다.
- 구조화되지 않은 HTML의 벽은 모델의 컨텍스트 예산(context budget)을 낭비합니다. 모델이 콘텐츠를 충분히 빨리 찾지 못하면 귀하의 가장 좋은 콘텐츠를 그냥 건너뛸 수도 있습니다.
- "크롤링 예산(crawl budget)" 회복이라는 개념이 없습니다. 가져오기(fetch)에 실패하거나 페이지를 읽을 수 없다면, 그것이 귀하에게 주어진 유일한 기회인 경우가 많습니다.
따라서 구현 목표는 다음과 같습니다: 귀하의 가장 좋은 콘텐츠로 향하는 기계가 읽을 수 있는(machine-readable) 경로를 가능한 한 짧고 명확하게 만드는 것입니다.
1. 실제로 사용되는 구조화된 데이터 (Structured Data)
Schema.org JSON-LD는 이제 단순히 리치 스니펫(rich snippets)만을 위한 것이 아닙니다. 이는 AI 시스템이 페이지의 엔티티(entities), 관계, 사실을 이해하기 위해 가질 수 있는 가장 명확한 신호 중 하나입니다. AEO/GEO를 위해 다음 유형들을 우선시하십시오:
<script type="application/ld+json">
{
"@context": "https://schema.org",
...
질문 중심의 페이지의 경우, FAQPage 스키마는 가장 영향력이 큰 추가 요소 중 하나입니다. 이는 답변 엔진이 개별적인 Q&A 쌍을 추출하는 방식과 직접적으로 매핑됩니다:
<script type="application/ld+json">
{
"@context": "https://schema.org",
...
관련이 있는 경우 HowTo, Product, Organization, 그리고 BreadcrumbList를 구현하는 것도 가치가 있습니다. 모든 것을 Google의 리치 결과 테스트 (Rich Results Test)로 검증하세요. 잘못된 스키마 (malformed schema)는 스키마가 없는 것보다 더 나쁠 때가 많습니다.
2. llms.txt 배포하기
llms.txt는 LLM에게 사이트의 큐레이션된 Markdown 기반 진입점을 제공하기 위해 제안된 (아직 공식적으로 표준화되지는 않은) 규약입니다. 이는 robots.txt나 sitemap.xml과 유사한 취지를 가지고 있지만, 크롤러 (crawler) 대신 모델을 위해 작성되었습니다. 이 파일은 사이트 루트에 위치합니다: https://yourdomain.com/llms.txt.
사양 (spec)은 의도적으로 최소한으로 구성되어 있습니다:
# 귀사의 회사 이름
> 회의실에서 피칭하듯 작성한, 귀사가 하는 일에 대한 한 문장 설명.
...
사람들의 예상보다 더 중요한 몇 가지 구현 참고 사항입니다:
- H1 태그는 반드시 첫 번째 줄이어야 하며, 그 위에 아무것도 있어서는 안 됩니다.
- 모든 것을 나열하지 말고 큐레이션된 상태를 유지하세요. 사이트의 모든 URL을 나열하는 파일은 목적에 어긋납니다. 모델이 이 파일을 읽었을 때 요약만으로도 귀하의 제품에 대한 정확한 멘탈 모델 (mental model)을 얻을 수 있어야 합니다.
noindex처리되었거나robots.txt에 의해 차단된 URL은 포함하지 마세요.- 전체 콘텐츠를 하나의 평탄화된 Markdown 내보내기로 만든
llms-full.txt라는 관련 변형이 있지만, 이는 일반적인 블로그보다는 문서 중심의 사이트에 주로 유용합니다.
채택 현황에 대해 솔직하게 말씀드리자면: 2026년 중반 기준으로, 주요 소비자용 LLM 크롤러 (ChatGPT, Gemini, Perplexity의 답변 봇)는 아직 llms.txt를 안정적으로 가져오지 않으며, 이를 보유한다고 해서 확인된 순위 상승이나 인용 이점이 있는 것도 아닙니다. 현재 이것이 실제로 사용되는 곳은 문서 사이트를 가리킬 때 /llms.txt를 확인하는 코딩 에이전트 (coding agents) 및 IDE 도구 (Claude Code, Cursor, Copilot 등)입니다. 이는 저비용의 미래 지향적인 추가 사항입니다. 이를 보장된 노출 레버 (visibility lever)가 아니라, 기술이 나아가는 방향을 위한 인프라로 취급하세요.
3. AI User-Agents를 위한 robots.txt 설정: 이것이 오늘날 실제로 중요한 부분입니다
이 글에서 단 한 가지만 실천해야 한다면, 바로 이것을 하세요. llms.txt와 달리, AI 크롤러(crawlers)는 현재 robots.txt의 User-Agent 규칙을 준수합니다. 이는 귀하의 콘텐츠가 가져와질 수 있는지, 학습에 사용될 수 있는지, 혹은 인용될 수 있는지를 직접적으로 제어합니다.
일반적인 패턴은 다음과 같습니다: 대량의 학습 데이터 스크래핑(scraping)은 차단하되, 온디맨드(on-demand) 방식의 "사용자가 질문을 했으니, 답변을 위해 이 페이지를 가져오라"는 봇은 허용하는 것입니다:
# 대량 학습 데이터 크롤러 차단
User-agent: GPTBot
Disallow: /
...
귀하의 목표가 AI 검색 노출(visibility)이라면, 기본 설정인 "모두 차단"을 선택하기보다 의도적으로 결정하십시오. ChatGPT-User나 PerplexityBot을 차단하는 것은 귀하의 콘텐츠나 스키마(schema)가 아무리 훌륭하더라도 결코 인용되지 않을 것임을 보장하는 것과 같습니다.
4. 온디맨드 페처(On-Demand Fetchers)를 위해 렌더링을 단순화하기
대부분의 AI 검색(retrieval)은 미리 구축된 인덱스(index)가 아니라 실시간으로 발생하기 때문에, JS 번들(bundle)이 실행될 때까지 기다려줄 용의가 있는 검색 엔진(search engine)에 비해 서버 사이드 렌더링(SSR, Server-Side Rendering) 또는 최소한 SSG/ISR이 여기서 더 중요합니다:
- 콘텐츠 페이지의 경우, 순수 클라이언트 렌더링 방식의 SPA(Single Page Application)보다는 Next.js/Nuxt/Astro 스타일의 SSR 또는 정적 생성(static generation)을 선호하세요.
useEffect를 통한 페치(fetch) 뒤에 주요 콘텐츠를 숨기지 마세요. 크롤러가 DOM을 읽는 시점에 페치가 완료되지 않았다면, 모델에게 그 콘텐츠는 존재하지 않는 것이나 다름없습니다.- 시맨틱 HTML(
<article>,<h1>–<h3>,<table>)을 온전하게 유지하세요. 제목(headings)을 스타일링된<div>로 재구성하지 마세요. 구조는 스크린 리더(screen reader)에 전달되는 것과 동일한 방식으로 모델에게 계층 구조를 전달합니다.
5. 컨텍스트 윈도우(Context-Window) 효율성을 위한 콘텐츠 구조화
질문에 답변하는 LLM은 페이지 전체를 읽는 것이 아니라, 질문에 답할 수 있는 가장 작은 청크(chunk)를 추출합니다. 추출 비용이 저렴하도록 Markdown/HTML을 구조화하세요:
- 섹션 상단, 세부 사항을 뒷받침하는 내용이 나오기 전의 명확하고 독립적인 답변.
- 비교 데이터를 위한 표(Table)를 사용하세요. 산문(prose) 형태보다 생성된 답변에 직접 복사하여 넣거나 파싱하기가 훨씬 쉽습니다.
- 설명적인
<h2>/<h3>텍스트 (예: "Step 3"보다는 "AI 크롤러를 위한 robots.txt 설정"과 같은 헤딩이 훨씬 더 잘 추출됩니다). - 짧은 단락. 밀집되고 끊김 없는 텍스트 블록은 추가되는 가치에 비해 파싱 비용이 많이 듭니다.
6. dateModified를 추가하고 정직함을 유지하세요
Perplexity와 같이 인용에 집중하는 엔진에는 최신성 신호(Freshness signals)가 중요하지만, dateModified는 그것이 사실일 때만 도움이 됩니다. 이를 수동으로 편집하지 말고 CMS나 git 커밋 히스토리에 연결하세요. 실제로 업데이트된 콘텐츠에 오래된 타임스탬프를 남기거나, 변경되지 않은 콘텐츠에 새로운 타임스탬프를 남기는 행위는 시간이 지남에 따라 신뢰 신호(trust signals)를 저해합니다.
7. 신뢰하기 전에 테스트하고 검증하세요
스키마(Schema)와 llms.txt 파일을 배포하더라도, 그것이 망가져 있다면 아무런 의미가 없습니다. 구조화된 데이터가 잘못되었더라도 페이지가 사람에게는 여전히 잘 보이기 때문에 이를 놓치기 쉽습니다. 배포 프로세스에 빠른 검증 단계를 구축하세요:
- 스키마 (Schema): 모든 템플릿 기반 페이지 유형을 Google의 리치 결과 테스트 (Rich Results Test)와 Schema.org 검증기 (validator)를 통해 실행하세요. 페이지 단위가 아닌 템플릿 단위로 수행해야 합니다.
Article컴포넌트의 버그는 단 하나의 포스트가 아니라 모든 포스트를 망가뜨리기 때문입니다. - 렌더링 (Rendering): 일반
curl이나fetch()를 사용하여 (브라우저나 JS 실행 없이) 자신의 페이지를 가져온 뒤, 주요 콘텐츠가 실제 원시 HTML(raw HTML)에 존재하는지 확인하세요. 만약 존재하지 않는다면, 온디맨드(on-demand) AI 페처(fetcher) 역시 이를 볼 수 없을 가능성이 높습니다:
curl -s https://yourdomain.com/blog/your-post | grep -A 5 "<article"
- robots.txt:
curl -A "GPTBot" https://yourdomain.com/your-page를 사용하여 특정 크롤러의 User-Agent (사용자 에이전트)를 시뮬레이션하고, 허용하려는 봇을 실수로 차단하고 있지는 않은지(또는 그 반대의 경우) 확인하십시오. - llms.txt: 브라우저에서
yourdomain.com/llms.txt를 직접 방문하여, 404 오류가 발생하거나 로그인 페이지로 리다이렉트되지 않고, 사이트 레이아웃에 감싸이지 않은 일반 텍스트 Markdown (마크다운) 형식으로200상태 코드를 반환하는지 확인하십시오.
이를 다른 회귀 테스트 대상(regression surface)과 동일하게 취급하십시오. 가능하다면 CI (지속적 통합)에 추가하거나, 최소한 렌더링 파이프라인, CMS (콘텐츠 관리 시스템), 또는 robots.txt를 변경한 후에는 반드시 재점검하십시오.
8. 이것들이 실제로 작동하는지 추적하기
대부분의 분석(analytics) 설정은 AI 답변 엔진이 사용자를 귀하의 사이트로 보냈는지 알지 못합니다. ChatGPT, Gemini, Perplexity로부터 오는 추천 트래픽 (referral traffic)은 종종 일관되지 않거나 누락된 리퍼러 헤더 (referrer headers)와 함께 도착하기 때문입니다. 몇 가지 실질적인 해결책은 다음과 같습니다:
- GA4 (또는 귀하가 사용하는 도구)에서 알려진 리퍼러 도메인(
chat.openai.com,chatgpt.com,perplexity.ai,gemini.google.com)을 필터링하는 세그먼트를 구축하십시오. 이는 실제 수치보다 적게 집계되지만 (많은 접속이 직접 트래픽 (direct traffic)으로 표시됨), 추측이 아닌 실제 최소 수치 (floor)를 제공합니다. - 3단계에서 허용한 AI User-Agent (
ChatGPT-User,PerplexityBot,Claude-User)에 대해 서버 로그를 모니터링하십시오. 여기서 급증이 발생한다면, 나중에 클릭으로 이어지는지 여부와 관계없이 봇이 귀하의 페이지를 활발하게 가져가고 있다는 것을 의미합니다. - Perplexity와 같이 인용 (citation) 중심의 엔진이 우선순위라면, 귀하의 콘텐츠가 답할 수 있는 질문으로 해당 엔진에 직접 주기적으로 쿼리(query)를 보내고 귀하가 인용되었는지 확인하십시오. 이는 현재 사용 가능한 수동 순위 확인 방법 중 가장 유사한 방식입니다. 아직 이를 위한 대시보드는 존재하지 않습니다.
- 이 수치들이 Google Analytics와 같을 것이라고 기대하지 마십시오. 2026년의 AI 추천 트래픽은 실재하지만 대부분의 사이트에는 여전히 적은 수준입니다. 이를 추적하는 목적은 트렌드의 방향성을 파악하는 것이지, 이번 분기에 집중하여 최적화해야 할 KPI (핵심 성과 지표)가 아닙니다.
9. 프레임워크별 빠른 시작
직접 구현하는 대신 위 사항들을 가장 빠르게 배포하고 싶다면:
Next.js (App Router) - 내장된 metadata API를 통한 스키마 (schema) 구성 및 JSON-LD를 위한 로우(raw) 스크립트 태그 추가:
// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
return {
...
llms.txt와 robots.txt를 public/ 디렉토리에서 정적 파일로 제공하세요. 별도의 라우트 핸들러 (route handler)는 필요하지 않습니다.
WordPress - Yoast SEO와 RankMath 모두 관련 필드를 채우면 Article/FAQPage 스키마를 자동으로 생성합니다. 현재 여러 SEO 플러그인들이 llms.txt도 자동으로 생성해주지만, 모든 포스트를 자동으로 덤프(dump)하는 것보다는 짧고 정제된 내용을 직접 작성하는 것이 대개 더 효과적입니다. robots.txt는 플러그인의 파일 에디터나 자식 테마 (child theme)를 통해 직접 수정할 수 있습니다.
Astro / 정적 사이트 (static sites) - 출력물이 기본적으로 서버 사이드 렌더링 (server-rendered)된 HTML이므로, 1단계와 4단계는 거의 공짜로 얻을 수 있습니다. JSON-LD를 공유 레이아웃 파셜 (shared layout partial)로 추가하고, llms.txt/robots.txt를 public/ 폴더에 바로 넣으세요.
종합하기
이 중 그 어떤 것도 좋은 글쓰기를 대체할 수는 없습니다. 얕고 부정확한 기사에 스키마 마크업 (schema markup)을 적용한다고 해서 인용 가치가 높아지지는 않습니다. 이는 단지 좋은 기사를 기계가 더 쉽게 파싱 (parse)하고 신뢰할 수 있게 만들 뿐입니다. 우선순위를 정한다면 다음 순서로 배포하세요:
robots.txtAI 유저 에이전트 (User-Agent) 규칙 (가장 높은 레버리지, 즉시 효과 발생)- 콘텐츠 페이지를 위한 서버 사이드 렌더링된 시맨틱 HTML (semantic HTML)
Article/FAQPageJSON-LD 스키마- 콘텐츠 구조 (제목, 표, 답변 우선 섹션)
- 검증 (Validation): 다음 단계로 넘어가기 전에 1~3단계가 제대로 작동하는지 실제로 확인
llms.txt(낮은 비용, 투기적 수익)- 유입 추적 (Referral tracking): 이 중 어떤 것이 실제 지표를 움직이고 있는지 파악
전략적 계층인 주제 권위 (topical authority), EEAT, 최신성 (freshness)이 여전히 핵심적인 역할을 수행합니다. 이것은 단지 당신이 들인 노력을 기계가 실제로 읽을 수 있도록 보장하는 장치일 뿐입니다.
AI 기반 검색에서의 가시성을 극대화하고 싶으신가요? 적절한 AI 모델을 선택한 후의 다음 단계는 AI 탐색(AI discovery)에 최적화하여 콘텐츠를 구성하는 것입니다. 답변 엔진 최적화 (AEO) 및 생성형 엔진 최적화 (GEO)에 관한 당사의 종합 가이드를 읽고, AI 생성 답변 및 검색 결과에 나타날 확률을 높이는 방법을 알아보세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기