이 파일은 844,000개의 웹사이트에 배포되었습니다 (BuiltWith, 2025년 10월 25일 기준). GPTBot, ClaudeBot 또는 PerplexityBot이 실제로 이 파일을 가져가는지는 오직 자신의 서버 로그(Server-Log)만이 답할 수 있는 문제입니다. 이 포스트는 그 방법론을 제공합니다.

TLDR

• 2024년 9월부터 표준이 존재함: Jeremy Howard (Answer.AI / fast.ai)가 제안하였으며, llmstxt.org에 문서화되어 있습니다.
• 확산은 증가하고 있으나 사용은 증명되지 않음: BuiltWith에 따르면 844,000개의 사이트가 존재하지만, 어떤 주요 AI 제공업체도 해당 콘텐츠가 추론 (Inference)에 사용된다고 공식적으로 확인하지 않았습니다.
• Google의 입장: John Mueller는 2025년 4월에 llms.txt를 과거의 keywords 메타 태그와 비교하며, 서버 로그(Server-Logs)를 확인한 결과 AI 서비스들이 이 파일을 요청조차 하지 않는다고 언급했습니다.
• Search Engine Land의 Semrush 실험 (2025년 8월~10월): 10주 동안 llms.txt에 대한 GPTBot, ClaudeBot, PerplexityBot 또는 Google-Extended의 방문이 0건이었습니다.
• 실질적인 결론: 저렴한 대비책으로서 구현하는 것은 여전히 의미가 있지만, 효과에 대한 증거 수준은 현재 전무합니다. 자체적인 검증은 도구 대시보드가 아닌 서버 로그(Server-Log)를 통해 이루어져야 합니다.

하이프(Hype)와 그 한계

llms.txt는 12개월 만에 한 개인의 제안에서 거의 모든 GEO 및 AI SEO 기사의 표준 권장 사항이 되었습니다. Ahrefs, Semrush, Yoast, Neil Patel 및 수십 개의 에이전시가 설정 가이드를 발행하고 있습니다. BuiltWith는 2025년 10월 25일 기준으로 루트 디렉토리에 llms.txt를 가진 도메인이 844,000개 이상이라고 집계했습니다. 비교하자면, robots.txt는 대략 1억 개 이상의 사이트에서 제공되는 것으로 추정되므로 아직 두 자릿수 규모 차이가 나지만, 분기별 증가율은 가파릅니다.

모순점: 채택(Adoption)이 늘어나는 것과 병행하여, OpenAI, Anthropic 또는 Google이 자사 시스템이 추론(Inference)이나 학습(Training)을 위해 이 파일을 사용한다는 공개적인 성명을 발표한 사례는 단 하나도 없습니다. Anthropic 자체적으로 docs.anthropic.com 아래에 llms.txt를 호스팅하고 있기는 하지만, 이는 클라이언트 측(문서 호스팅)일 뿐 서버 측(크롤링 및 활용)에 대한 공식적인 지원은 아닙니다.

이러한 하이프(Hype)와 증거 사이의 비대칭성이 바로 이 포스트가 다루고자 하는 문제입니다. 방법론적 초점은 다음과 같습니다: 도구 판매업체(Tool-vendor)의 발표에 의존하지 않고, 실제 효과를 어떻게 직접 검증할 수 있는가?

llms.txt란 무엇이며 무엇을 약속하는가

입문자를 위한 짧은 요약입니다. 파일 구조, 예시 및 베스트 프랙티스(Best Practices)에 대한 심층 내용은 llms.txt 메인 가이드에서 확인할 수 있습니다.

llms.txt는 example.com/llms.txt 경로에 배치되는 Markdown 형식의 텍텍스트 파일입니다. Jeremy Howard는 2024년 9월 3일에 이 표준을 제안했습니다. llmstxt.org에 따른 목적은 다음과 같습니다: "추론(Inference) 시점에 LLM이 웹사이트를 사용하는 데 도움이 되는 정보를 제공하는 것". 이 파일에는 제목, 요약, 그리고 짧은 설명이 포함된 주요 하위 페이지로의 큐레이션된 링크가 포함되어 있습니다.

약속된 기능: 브랜드나 산업에 관한 질문에 답하는 AI 시스템이 llms.txt를 컨텍스트 신호(Context signal)로 읽어 들여, 웹사이트를 더 빠르게 이해하고, 올바른 콘텐츠의 우선순위를 정하며, 출처를 더 정확하게 인용한다는 것입니다. 메커니즘은 타당해 보이지만, 실증적 근거(Empirie)가 부족합니다.

증거의 공백

Google은 첫 번째 주요 플레이어로서 명시적인 입장을 밝혔습니다. John Mueller는 2025년 4월 Reddit에 글을 남겼으며, 이는 Search Engine Journal에서 인용되었습니다:

"내가 알기로는(AFAIK) 어떤 AI 서비스도 LLMs.TXT를 사용한다고 말한 적이 없습니다 (그리고 서버 로그를 살펴보면 그들이 이 파일을 확인조차 하지 않는다는 것을 알 수 있습니다). 저에게 이것은 키워드 메타 태그(Keywords meta tag)와 유사하게 느껴집니다."

키워드 메타 태그(keywords meta tag)와의 비교가 적절한 이유가 여기에 있습니다. 이 태그는 1990년대 후반에 웹마스터들에게 검색 엔진을 위한 선언적 인터페이스(declarative interface)를 제공하려는 시도였습니다. Google은 조작이 너무 쉽고 실제 페이지 콘텐츠와의 교차 검증(cross-check)이 필수적이라는 이유로, 늦어도 2009년에는 이를 랭킹 시그널(ranking signal)에서 제외했습니다. Mueller의 요점은 다음과 같습니다: llms.txt 역시 스스로 선언하는 파일이라는 점입니다. AI 시스템은 이 정보를 실제 페이지 콘텐츠와 대조하여 검증해야 하며, 그렇지 않으면 조작의 통로가 될 수 있습니다. 이러한 검증 오버헤드(verification overhead)가 이 파일을 불필요하게(redundant) 만듭니다.

Semrush는 자체적으로 이 가설을 테스트했습니다. 자매 매체인 Search Engine Land에서 2025년 8월 중순부터 10월 말 사이에 llms.txt를 배포했습니다. Semrush 블로그에 따른 결과는 다음과 같습니다: 관찰 기간 전체 동안 Google-Extended, GPTBot, PerplexityBot, ClaudeBot의 방문 횟수는 0회였습니다. Googlebot과 Bingbot은 해당 파일을 호출했지만, 특별한 지위(special status)를 부여하지 않고 처리했습니다.

Ahrefs 또한 같은 기간 동안 동일한 결론을 내렸습니다. 콘텐츠 마케팅 디렉터인 Ryan Law는

직접 확인하기: 서버 로그 방법론

자신이 소유한 도메인에 대한 가장 신뢰할 수 있는 증거는 자체 액세스 로그(Access Log)에서 나옵니다. 툴 대시보드, 다른 블로그 게시물, 공급업체 진술은 이를 대체할 수 없습니다. 왜냐하면 봇 행동은 도메인과 기간별로 다르기 때문입니다. 다음 방법론은 Combined-Log 형식의 Apache, Nginx 및 CDN 로그에 적용 가능합니다.

단계 1: 목표 사용자 에이전트(User-Agents) 정의

대형 AI 제공업체의 공개적으로 문서화된 봇 중 로그 증거가 유용한 대상:

이 목록은 완전하지 않습니다. Microsoft의 Bingbot은 Copilot에서 Bing 결과가 반영되기 때문에 일부 감사(audit)에서는 AI 봇으로 포함됩니다. BuiltWith와 같은 디스커버리 크롤러 또는 다양한 에이전시 스캐너도 나타나며, 이는 종종

Combined-Log-Format을 사용하는 Apache 또는 Nginx 설치 환경에서 가장 간단한 시작 방법은 다음과 같습니다:

# 지난 30일간의 llms.txt에 대한 모든 접속 기록
grep "llms.txt" /var/log/nginx/access.log | awk -F" '{print $6}' | sort | uniq -c | sort -rn

...

로그 로테이션(rotated logs, access.log.1.gz, access.log.2.gz 등)이 적용된 경우, grep을 zgrep으로 교체하거나 루프(loop)를 사용하여 반복 처리합니다. CDN (Cloudflare, Fastly, CloudFront)의 경우 로그 경로가 다르지만, 원리는 동일합니다: llms.txt에 대한 경로 필터링을 수행한 다음, User-Agent 필터링을 적용합니다.

단계 3: 유사한 페이지와의 대조 실험

핵심적인 지점은 대조 실험(counter-test)입니다. llms.txt에 대한 결과가 0이라면, 이는 AI 봇들이 해당 도메인의 다른 곳에는 나타나는지를 확인했을 때만 해석이 가능합니다. 따라서 이와 병행하여 유사한 URL (robots.txt, sitemap.xml 또는 전형적인 콘텐츠 페이지)을 확인해야 합니다:

# 대조 실험: robots.txt에 대한 동일한 봇들의 접속 확인
grep "robots.txt" /var/log/nginx/access.log | \
  grep -oE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Google-Extended|Applebot-Extended|CCBot|Bytespider" | \
...

만약 GPTBot이 도메인을 100번 크롤링했는데 llms.txt는 0번이라면, 이는 관심이 없다는 명확한 증거입니다. 반대로 GPTBot이 도메인을 아예 크롤링하지 않았다면, llms.txt에 대한 결과가 0이라는 사실은 큰 의미가 없습니다. 결과는 반드시 적절한 상관관계 내에 있어야 하며, 그렇지 않으면 방법론적으로 가치가 없습니다.

단계 4: 관찰 기간

LLM 봇은 Googlebot보다 크롤링 빈도가 낮습니다. 14일 미만의 관찰 기간은 불충분합니다. Semrush의 실험은 10주 이상 진행되었으며, 이는 유의미한 최소 규모입니다. 더 나은 방법은 60일에서 90일 정도를 관찰하는 것이며, 이상적으로는 특정 게시 이벤트(새로운 콘텐츠 페이지 게시, 주요 링크 연결 등)를 트리거(trigger)로 결합하는 것입니다.

단계 5: Reverse-DNS를 통한 검증

User-Agent 문자열은 임의로 조작될 수 있습니다. 정말로 깔끔하게 작업하고 싶다면, 나타나는 봇들의 IP 범위(IP-Range)를 Reverse-DNS를 통해 검증해야 합니다. OpenAI는 GPTBot의 IP를 공개적으로 문서화하고 있으며 (해당 범위는 openai.com/gptbot.json에 있습니다), Anthropic 또한 마찬가지입니다 (IP 목록은 claude.com/crawling/bots.json에 있습니다). 스위스 중소기업(Mittelstand)의 대부분의 설정에서는 이는 과잉 엔지니어링 (Over-Engineering)이지만, 감사(Audit)나 피치(Pitch)에서 서버 로그 결과를 사용하는 사람이라면 이 단계를 계획에 포함해야 합니다.

공식 툴 벤더들의 입장

시장 상황은 갈려 있습니다. 크게 세 진영으로 나뉩니다:

진영의 분포는 보이는 것보다 더 흥미롭습니다. 구현 찬성 측은 거의 전적으로 규범적(