AI 준비성 (AI-readiness) 분야의 모든 스캐너는 llms.txt를 확인합니다. 검사에서 탈락하는 사이트의 절반은 파일이 없어서가 아니라, 잘못된 파일을 가지고 있기 때문에 탈락합니다. 알맹이 없는 내용으로 가득 찬 llms.txt에 대해 200 OK 응답을 보내는 것은 에이전트 (agent)에게 도움이 되지 않으며, 점수 산정 방식도 속일 수 없습니다. 이것은 제가 WordPress, Webflow, Shopify 및 정적 사이트 (static sites) 전반에 걸쳐 이러한 파일들을 실제로 배포하고 테스트하며 배운 내용입니다.

llms.txt의 실제 정체

사양 (spec)은 llmstxt.org에 정의되어 있습니다. 요약하자면: 사람이 아닌 LLM (Large Language Model)을 위해 작성된, 사이트 루트에 위치하여 LLM에게 사이트의 지도를 제공하는 마크다운 (markdown) 파일입니다. 법적 합의서가 아닙니다 (robots.txt와 agents.txt에 더 가깝습니다). 학습 데이터 제외 (training-data opt-out) 설정도 아닙니다. 이것은 발견 및 모호성 해소 (discovery and disambiguation)를 돕는 도구이며, 손으로 그린 지도가 위성 사진보다 낯선 사람에게 더 쉬운 것과 같은 원리입니다.

알아둘 가치가 있는 두 가지 파일이 있습니다:

• 루트의 llms.txt: 인덱스 (index). 표준 페이지 (canonical pages)로 연결되는 짧고 직접 선별된 링크들입니다.
• 루트의 llms-full.txt: 확장형 (expanded). LLM이 실제로 흡수하기를 원하는 페이지들의 내용을 하나로 합친 것입니다.

대부분의 사이트는 첫 번째 파일만 필요합니다. 문서 (docs) 비중이 높은 사이트는 두 가지 모두의 혜택을 받습니다.

높은 점수를 받는 파일의 구조

사양은 에이전트들이 실제로 사용하는 것보다 더 많은 것을 허용합니다. 실제로 중요한 섹션은 스캐너나 잘 동작하는 에이전트가 결정론적 (deterministically)으로 파싱할 수 있는 섹션들입니다.

# 사이트 이름

> 이 사이트가 무엇인지, 그리고 누구를 위한 것인지 설명하는 한 문장.
...

이 예시가 대부분의 사이트가 틀리는 부분 중 제대로 하고 있는 몇 가지 사항이 있습니다.

H1은 파일 제목이 아니라 사이트 이름이어야 합니다. 많은 생성기들이 # Example.com을 위한 llms.txt와 같은 결과물을 만들어냅니다. 이는 노이즈 (noise)입니다. H1은 LLM이 요약할 때 당신의 사이트 이름을 지정하기 위해 사용할 가능성이 가장 높은 요소입니다.

인용구 (blockquote)는 한 줄 요약입니다. 마케팅 문구가 아닙니다. 사람이 실제로 소리 내어 읽을 수 있는 단 한 문장이어야 합니다. 만약 에이전트가 당신의 사이트를 설명하기 위해 단 한 줄을 골라야 한다면, 바로 이 문장을 선택할 것입니다.

링크는 절대 경로(absolute)여야 합니다. 상대 경로(Relative links)는 파일의 기원(origin) 외부에서 파일을 소비하는 모든 경우에 작동하지 않으며, 이는 파일의 존재 목적(파일은 다른 곳에서 가져가고 처리하기 위해 존재함)에 어긋납니다.

각 링크에는 콜론(:)으로 구분된 설명이 있어야 합니다. 에이전트는 왜 해당 링크를 따라가야 하는지 알아야 합니다. - [Getting started](https://example.com/docs/start)만으로는 정보가 부족합니다. 콜론 뒤의 설명은 에이전트가 링크를 가져오기(fetching) 전에 순위를 매길 수 있도록 충분한 문맥(context)을 제공합니다.

섹션은 미적(aesthetic) 요소가 아닌 의미론적(semantic) 요소여야 합니다. ## Docs, ## Products, ## API, ## Optional과 같이 구성하세요. ## Everything you need to know와 같은 장식적인 헤딩(heading)은 피하십시오. 스캐너는 ##를 기준으로 분할하며, H2는 메타데이터(metadata) 역할을 합니다.

실제 사례에서 발생하는 문제점

직업적으로 사이트들을 스캔하면서 계속해서 목격하는 여섯 가지 실수입니다:

1. JavaScript로 렌더링되는 llms.txt. 잘못된 Content-Type을 가진 API 핸들러를 통해 llms.txt를 제공하는 Next.js 또는 Nuxt 라우트가 이에 해당합니다. 에이전트는 JS가 없는 최소한의 HTTP 클라이언트로 데이터를 가져옵니다. 파일을 정적(statically)으로, text/plain; charset=utf-8로 제공하십시오. 만약 사용 중인 프레임워크가 이를 방해한다면, /public 디렉토리나 CDN에 배치하십시오.

2. CDN의 오래된 버전 캐싱. 파일을 2시간 전에 업데이트했음에도 스캐너는 여전히 어제의 버전을 보고 있는 경우입니다. 수정할 때마다 캐시를 퍼지(Purge)하십시오. Cloudflare 사용자는 { "purge_everything": true }와 함께 POST /zones/:id/purge_cache를 호출하거나 URL별로 퍼지할 수 있습니다.

3. robots.txt와의 불일치. llms.txt는 "여기 내 콘텐츠가 있으니 와서 보세요"라고 말하는데, robots.txt는 GPTBot이나 ClaudeBot을 차단하고 있는 경우입니다. robots.txt를 준수하는 에이전트는 귀하의 llms.txt를 읽지 않을 것입니다. 하나를 결정하십시오. AI 트래픽을 원하는지, 그리고 크롤러를 허용할 것인지, 아니면 원하지 않는지 말입니다. 두 가지 신호를 동시에 보내지 마십시오.

4. 1MB보다 큰 llms-full.txt를 gzip으로만 제공하는 경우. 일부 에이전트는 accept-encoding을 지원하지 않는 클라이언트로 파일을 가져옵니다. identity-encoded 방식으로도 제공하고, 전체 크기를 몇 MB 이내로 유지하며, 크기가 더 커져야 한다면 주제별 파일로 분할하십시오.

5. Canonical URL(표준 URL) 불일치. llms.txt의 링크는 LLM이 실제로 가져올(fetch) URL과 일치해야 합니다.

만약 llms.txt가 example.com/docs를 링크하고 있지만, 실제 문서가 docs.example.com에 있다면, 에이전트(agents)는 리다이렉트(redirect)를 겪게 되고 문맥(context)을 놓치게 됩니다. 사이트의 나머지 부분에서 선언하는 표준 URL(canonicals)과 일치시키세요.

6. 사실이 있어야 할 자리에 들어간 마케팅 문구. "현대적인 팀을 위한 업계 최고 수준의 AI 기반 플랫폼"과 같은 문구는 llms.txt에서 무용지물보다 더 나쁩니다. 이를 흡수(ingesting)하는 LLM은 이를 그대로 인용하거나(나쁨), 무시하게 됩니다(더 나쁨, 이제 요약 정보조차 없기 때문입니다). 담백하게 작성하세요. 사이트가 무엇을 하는지, 누구를 위한 것인지, 비용은 얼마인지 작성하십시오.

에이전트가 실제로 이를 읽는지 테스트하는 방법

추측하며 오후 시간을 보낼 수도 있고, 직접 확인할 수도 있습니다.

정적 점검 (Static check). curl -sSI https://yoursite.com/llms.txt를 실행하여 다음을 확인하세요: 200, Content-Type: text/plain, 유의미한 Content-Length, 최근의 Last-Modified. 그 다음 curl -s https://yoursite.com/llms.txt | head -60을 실행하여 눈으로 직접 확인하십시오.

에이전트 점검 (Agent check). 실제 에이전트에게 물어보세요. Claude, 브라우징 기능이 있는 ChatGPT, 또는 Perplexity를 엽니다. 프롬프트: "https://yoursite.com/llms.txt를 가져와서, 오직 해당 파일에만 기반하여 이 사이트가 무엇인지 한 문장으로 요약해줘." 만약 답변이 인용구(blockquote)에 작성한 내용과 유사하다면 성공입니다. 답변이 일반적이거나 틀렸다면, 파일이 제 역할을 하지 못하고 있는 것입니다.

스캐너 점검 (Scanner check). radar.cloudflare.com/scan에 있는 Cloudflare의 URL Scanner는 llms.txt에 부분적으로 의존하는 에이전트 준비 점수(Agent Readiness Score)를 보여줍니다. agentgrade.com의 AgentGrade는 완전히 무료이며 세부 점수와 함께 등급(letter grade)을 부여합니다. 제가 만든 agentfix.pro 도구는 33개의 신호(signals)를 실행하고 신호별 통과/실패 여부를 보여줍니다. 이는 무엇을 수정해야 할지 알려주지 않는 점수들에 지쳤을 때 제가 직접 만든 것입니다.

업계가 나아가는 방향

향후 6개월 동안 주목할 만한 두 가지 사항이 있습니다.

agents.txt가 안정화되고 있습니다. 이는 권한과 약관을 명시함으로써 llms.txt를 보완하며, 정신적으로는 robots.txt에 더 가깝지만 가격 책정(pricing), 속도 제한(rate limits), 상업적 이용을 위한 선호 연락처(preferred contact)와 같은 구조화된 필드를 포함합니다. 스캐너(scanners)들이 곧 이를 하나의 신호(signal)로 추가할 것으로 예상됩니다.

llms.txt와 함께 제공되는 MCP 엔드포인트 (endpoints). 일부 사이트들은 이미 llms.txt 내부에 Model Context Protocol (MCP) 서버를 가리키는 mcp 링크를 광고하고 있습니다. 이것이 바로 "에이전트가 당신의 사이트를 읽을 수 있다"에서 "에이전트가 당신의 사이트에서 무언가를 수행할 수 있다"로 넘어가는 실질적인 가교(bridge)입니다. 만약 당신이 무언가를 판매하고 있다면, 바로 이 지점에 진정한 레버리지(leverage)가 존재합니다.

맺음말

llms.txt 파일은 작성하는 데 20분이 걸리고, 제공(serve)하는 데 5분이 걸립니다. 에이전트가 방문할 가능성이 있는 모든 사이트 운영자에게, 올바르게 작성하는 것은 그 25분의 가치가 충분합니다. 2026년경에는 거의 모든 사이트가 그 대상이 될 것이기 때문입니다. 흥미로운 질문은 작성 여부가 아니라, 당신이 이미 작성한 파일이 당신이 의도한 대로 작동하고 있는가 하는 점입니다.

자신의 파일에 대해 제2의 의견을 듣고 싶다면, 위에 언급된 도구들이 알려줄 것입니다. 만약 바로 적용할 수 있는 파일 형태의 해결책을 원한다면, 제가 agentfix.pro에서 WordPress, Webflow, Shopify, 그리고 Tilda를 위해 구축해 온 것이 바로 그것입니다. 어떤 방식이든, 당신의 llms.txt를 마치 당신이 에이전트인 것처럼 직접 읽어보기 전까지는 스캐너 점수를 신뢰하지 마세요.

_ agentfix.pro에서 교차 게시됨. _