Anthropic도, Cloudflare도 쓴다는 llms.txt — 그런데 Google은 "안 쓴다"고 말했다

결론부터 — llms.txt는 "써야 하나 말아야 하나"의 문제가 아니라 "왜, 누가, 어떤 형태로 쓰는가"의 문제다...

2024년 11월, Jeremy Howard(Answer.AI 공동창업자)가 github.com/AnswerDotAI/llms-txt 저장소에 하나의 제안서를 올렸다. 웹사이트의 가장 중요한 콘텐츠를 마크다운으로 정리해 루트 디렉토리에 /llms.txt로 노출하자는 것이다. LLM은 웹사이트 전체를 크롤링하지 않고 이 파일만 읽어도 해당 사이트를 이해할 수 있다. 그 로직이 먹혔다. 1년 만에 BuiltWith 기준 2,000개에 불과했던 도입 사이트는 84만 개를 돌파했다. Anthropic, Cloudflare, Vercel, Stripe, Coinbase, Supabase, Cursor — AI 네이티브 기업 대부분이 참전했다. New York Times, CNN, Reuters 같은 주류 언론사도 뒤를 이었다.

그런데 같은 기간, 정반대의 신호가 쏟아졌다. Google의 John Mueller는 "llms.txt는 예전 keywords meta tag와 같다 — 사이트 소유자의 주장일 뿐, 검증할 수 없으니 AI가 신뢰할 이유가 없다"고 공개적으로 깎아내렸다. 2025년 7월 Search Central Live에서 Gary Illyes는 "Google은 llms.txt를 지원하지 않으며, 지원 계획도 없다"고 못박았다. SE Ranking이 300,000개 도메인을 분석한 결과, llms.txt 도입과 AI 인용 빈도 사이에는 통계적으로 유의미한 상관관계가 없었다. XGBoost 모델에서는 llms.txt 변수를 제거했을 때 오히려 정확도가 개선됐다. ALLMO.ai가 94,000개 이상의 인용 URL을 분석한 연구에서도 결론은 같았다.

모순이다. 그리고 이 모순이 바로 GEO(Generative Engine Optimization) 실무자가 반드시 이해해야 할 지점이다. llms.txt를 "쓸지 말지"의 이분법으로 접근하면 답이 안 나온다. 질문을 다시 던져야 한다. 누가, 어떤 목적으로, 어떤 형태로 썼을 때 의미가 있는가. 이 글은 2024년 이후 축적된 연구 데이터와 실제 구현 사례를 교차 분석해, 한국의 대학·공공기관·SaaS가 판단할 수 있는 구체적 의사결정 프레임워크를 제시한다.

1. llms.txt란 무엇인가 — robots.txt와 sitemap.xml 사이의 제3의 파일

기술적 정의

llms.txt는 웹사이트 루트 디렉토리(https://example.com/llms.txt)에 위치하는 마크다운 형식의 파일이다. LLM이 웹사이트를 이해할 때 참고할 수 있도록, 가장 중요한 페이지의 링크와 간단한 설명을 구조화된 형태로 제공한다. 2024년 9월 Jeremy Howard가 공식 스펙 초안을 공개했고, 현재 llmstxt.org에서 문서화를 유지하고 있다.

llms.txt의 기본 구조는 다음과 같다.

# Site Name
> 사이트를 한 문장으로 요약한 블록쿼트.

추가 맥락 설명을 여기에 작성한다.

## Documentation
- [페이지 제목](URL): 페이지 설명
- [페이지 제목](URL): 페이지 설명

## Examples
- [페이지 제목](URL): 페이지 설명

## Optional
- [페이지 제목](URL): 컨텍스트 제약 시 스킵 가능한 저우선 페이지

llms.txt와 llms-full.txt의 차이

실무에서 자주 혼동되는 부분이다. 두 파일은 목적이 다르다.

llms.txt는 인덱스 파일이다. 가장 중요한 페이지로 가는 링크와 간단한 설명만 담는다. 마치 사이트맵의 큐레이션 버전처럼 작동한다. 용량은 대체로 작고(수 KB~수십 KB), LLM이 "이 사이트에는 뭐가 있지?"를 빠르게 파악하는 용도다.

llms-full.txt는 콘텐츠 덤프 파일이다. 링크만 나열하는 것이 아니라, 해당 페이지의 본문 내용 자체를 마크다운으로 평탄화(flatten)해서 한 파일에 담는다. 대형 구현체는 수십만 단어에 달할 수 있다. 실제 사례에서는 약 115,378 단어(966KB) 규모까지 기록됐다. 이는 IDE 확장 프로그램의 인덱싱이나 벡터화 파이프라인에 통째로 투입되는 용도로 최적화된 형태다.

Cloudflare의 실제 구현을 보면 이 패턴이 명확하다. Cloudflare는 developers.cloudflare.com/llms.txt에 제품별 인덱스를 두고, developers.cloudflare.com/llms-full.txt에 전체 문서 아카이브를 두었다. 각 제품(Workers, AI Gateway, Sandbox, Cloudflare One 등)별로도 llms.txt와 llms-full.txt를 각각 운영한다.

robots.txt·sitemap.xml과의 역할 구분

llms.txt를 "LLM용 robots.txt"로 이해하는 경우가 많지만, 이는 100% 오해다. 세 파일은 목적이 완전히 다르다.

robots.txt는 크롤러의 접근을 제어한다. "이 봇은 들어와도 되고, 저 봇은 안 된다"를 선언한다. sitemap.xml은 사이트에 존재하는 모든 페이지를 나열한다. 검색엔진이 발견 가능한 URL의 완전한 목록이다. llms.txt는 "이 중에서 가장 중요한 것은 이것이다"를 큐레이션한다. 접근을 막지도, 전체를 나열하지도 않는다. 우선순위를 신호한다.

즉, robots.txt는 정책, sitemap.xml은 지도, llms.txt는 가이드북이다. 세 파일은 서로를 대체하지 않으며, 보완 관계에 있다. AI 봇을 제어하려면 robots.txt가 필요하고, 색인을 위해서는 sitemap.xml이 필요하며, AI가 중요한 콘텐츠를 놓치지 않기를 원한다면 llms.txt가 필요하다 — 이론적으로는 그렇다.

2. "그런데 Google은 안 쓴다고 말했다" — 공식 부정의 전말

John Mueller의 keywords meta tag 비유

llms.txt 논쟁의 전환점은 2025년 4월이었다. Reddit의 한 사용자가 "llms.txt를 블로그 루트에 올렸는데 크롤링 로그에 아무 변화가 없다"는 질문을 올렸고, 20,000개 이상의 도메인을 운영한다는 한 호스팅 관리자가 "주요 AI 봇 중 어느 것도 llms.txt를 요청하지 않는다. BuiltWith 같은 니치 봇만 가져간다"고 답했다.

여기에 Google의 John Mueller가 개입했다. 그의 발언을 정리하면 이렇다. "내가 아는 한, 주요 AI 서비스 중 어느 곳도 llms.txt를 사용하지 않는다. 서버 로그를 보면 아예 체크조차 하지 않는다는 것을 확인할 수 있다. llms.txt는 keywords meta tag와 유사하다 — 사이트 소유자가 자기 콘텐츠에 대해 주장하는 것일 뿐, AI가 사이트를 직접 확인할 수 있는데 왜 그 주장을 신뢰해야 하는가?"

여기서 keywords meta tag는 1990년대 HTML 표준에 존재했던, 페이지의 키워드를 사이트 소유자가 직접 선언하는 태그다. SEO 조작이 너무 쉬워서 검색엔진이 2009년 공식적으로 랭킹 신호에서 제외했다. Mueller의 비유는 "llms.txt도 같은 운명이 될 것"이라는 예측에 가깝다.

Gary Illyes의 쐐기

2025년 7월 Search Central Live 행사에서, Google의 또 다른 대변인 Gary Illyes는 더 직접적으로 못박았다. "Google은 llms.txt를 지원하지 않으며, 지원할 계획도 없다." 같은 시점에 Google의 개발자 문서 일부(ai.google.dev/api/llms.txt)에 llms.txt가 배포된 것을 두고 "이것이 Google의 승인인가?"라는 질문이 나왔지만, Mueller는 Bluesky에서 "내가 비꼬는 말을 하고 싶을 정도다. 직설적으로 답하면 — 아니다"라고 답했다. CMS 플랫폼이 기능을 추가했을 때 다른 팀들이 무관심하게 방치한 것이지, 공식 채택이 아니라는 설명이다.

데이터가 뒷받침하는 부정

Google만의 시각이 아니다. 세 개의 대규모 연구가 같은 결론에 수렴한다.

SE Ranking 연구(2025년, 300,000개 도메인 분석): 도입률은 10.13%. 흥미로운 패턴은 트래픽 계층별 도입률이 거의 평탄하다는 것이다. 저트래픽 사이트(0~100 방문/월) 9.88%, 중트래픽(1,001~5,000) 10.54%, 고트래픽(100,001+) 8.27%. 오히려 대형·권위 사이트가 덜 도입하는 역전 현상이 관측됐다. 핵심은 "도메인 레벨 AI 인용 빈도와 llms.txt 보유 여부 사이에 통계적 상관관계가 없다"는 결론이다. 머신러닝 모델에서 llms.txt 변수를 제거했을 때 오히려 예측 정확도가 향상됐다 — 노이즈를 제거한 셈이다.

ALLMO.ai 연구(2026년 1월, 94,000개 인용 URL 분석): ChatGPT, Claude, Gemini, Grok, Perplexity 5개 플랫폼의 실제 인용 URL을 추적했을 때, /llms.txt URL이 인용 소스로 등장한 사례는 거의 없었다. LLM이 라이브 웹 검색으로 그라운딩할 때 llms.txt를 선호한다는 증거가 발견되지 않았다는 결론이다.

Search Engine Land 소규모 실험: 9개 사이트에 llms.txt를 구현한 뒤 트래픽 변화를 추적했을 때, 8개 사이트는 측정 가능한 변화가 없었다. 1개 사이트에서 미미한 변화가 관측됐지만 통계적으로 유의미하다고 보기 어려웠다.

Web Almanac 2025 데이터 역시 비슷한 그림을 보여준다. llms.txt 채택률은 상승세이지만, 그 상승이 Yoast·Rank Math 같은 WordPress SEO 플러그인의 자동 생성 기능 때문인지, 사이트 소유자의 의도적 선택인지 구분하기 어렵다는 분석이다.

3. "그런데 Cloudflare는, Anthropic은, Vercel은 왜 쓰는가" — 반대편의 논리

84만 도메인의 전개

BuiltWith 추적 데이터에 따르면, llms.txt를 노출하는 사이트 수는 2024년 초 거의 0개에서 2025년 말 기준 84만 개 이상으로 급증했다. SE Ranking 연구가 측정한 10.13%의 도입률과 이 절대 숫자를 함께 읽으면, 상위 기술 스택 사이트에서 유독 빠르게 확산되고 있다는 그림이 보인다.

대표 구현 사례를 정리하면 이렇다. Anthropic은 자사 문서 사이트에 llms.txt를 운영한다. Cloudflare는 전사 통합 /llms.txt와 20개 이상 제품별 /llms.txt, 그리고 동등한 수의 /llms-full.txt를 운영한다. Vercel·Stripe·Supabase·Coinbase·Cursor는 모두 자체 구현을 공개했다. Mintlify는 자사 문서 플랫폼 사용 기업(수백 개)에 자동 생성 기능을 제공한다. Fern도 llms.txt·llms-full.txt 자동 생성·유지 기능을 표준화했다.

미디어 측면에서도 유의미한 움직임이 있다. The New York Times, CNN, Reuters가 llms.txt를 도입한 것으로 보고된다. 이들에게 llms.txt는 SEO 도구가 아니라 "AI 시대에 대한 공개적 입장 표명"에 가깝다.

Yoast의 반박 — "keywords meta tag 비유는 틀렸다"

Google의 부정에 대한 가장 정교한 반박은 Yoast의 SEO·AI 전략가 Carolyn Shelby에게서 나왔다. 그의 주장은 세 가지 축이다.

첫째, keywords meta tag와 llms.txt의 구조는 다르다. keywords meta tag는 페이지에 관한 검증 불가능한 주장이었다. 반면 llms.txt는 실제 URL로 연결되는 링크이기 때문에, AI가 그 링크를 따라가서 실제 페이지의 내용을 확인할 수 있다. 주장이 아니라 이정표다.

둘째, LLM의 크롤링 방식은 Google Bot과 다르다. 기존 검색엔진은 사이트 전체를 크롤링하고 색인한다. 하지만 LLM 에이전트는 "Mission Impossible 방식"으로, 필요한 특정 콘텐츠 조각에 침투해 핵심만 취하고 빠져나온다. 이 맥락에서 llms.txt는 "먼저 이 지도를 확인하고 가장 적합한 페이지부터 가라"는 힌트로 기능할 수 있다. Mueller가 지적한 "어차피 봇은 전체 페이지를 다운받는다"는 비판은 Google-Bing 패러다임에는 맞지만, LLM 에이전트 패러다임에는 맞지 않다.

셋째, 웹 표준은 모두 초기에는 "아직 아무도 안 쓴다"고 불렸다. robots.txt(1994), sitemap.xml(2005), Schema.org(2011) 모두 초기 몇 년간은 "왜 쓰는지 모르겠다"는 반응을 받았다. 지금의 llms.txt를 같은 위치로 볼 수 있는가는 별개의 문제지만, "현재 미사용"이 "영구히 무용"을 의미하지는 않는다는 것이 요점이다.

도발적인 케이스 스터디 — llms.txt가 Google AI Mode의 #1 인용 소스로

2026년 2월, dev5310(Magnolia DXP 기반의 개발 에이전시)은 도발적인 실험 결과를 공개했다. 자사 llms.txt 파일을 Google Search Console에 직접 제출한 결과, 수 시간 내에 Google이 이를 색인했고, 1일 후 첫 AI 인용이 등장했으며, 4개의 서로 다른 쿼리에서 18일간 일관되게 인용됐다. 특히 Google AI가 자사 도메인에 대한 모든 소스를 나열하라는 요청을 받았을 때, llms.txt가 #1 소스로 랭크됐다. 단일 4일 구간에 6개의 서로 다른 AI·검색 봇이 이 파일을 히트했고, Google AI Mode는 요청받지 않은 상태에서도 이 파일의 목적을 사용자에게 설명했다.

다만 이 사례는 하나의 중요한 전제 위에 서 있다. 해당 사이트는 이미 탄탄한 구조화 데이터(JSON-LD)와 깨끗한 콘텐츠 모델을 보유하고 있었고, Magnolia DXP가 llms.txt를 자동 생성·유지하고 있었다. 즉, "llms.txt 자체가 마법을 부렸다"가 아니라, "기존의 기술적 건강성이 준비된 사이트에서 llms.txt가 추가 시그널로 작동했다"는 해석이 정확하다. 그럼에도 "파일을 올렸지만 아무 반응이 없었다"는 다수 사례와, "올렸더니 AI 인용 #1이 됐다"는 이 사례가 공존한다는 사실 자체가 llms.txt의 현주소를 보여준다.

4. 양측 주장의 평행 비교 — 무엇이 진짜 의견 차이인가

llms.txt에 대한 Google 진영과 도입 진영의 논쟁을 다섯 개 축으로 정리하면 다음과 같다.

① 파일의 성격

Google: "검증 불가능한 주장 — keywords meta tag와 같다." | 도입 진영: "실제 URL로 연결되는 큐레이션 — AI가 직접 검증 가능하다."

② LLM의 크롤링 방식에 대한 전제

Google: "봇은 어차피 전체 페이지를 다운로드한다. 별도 파일이 왜 필요한가?" | 도입 진영: "LLM 에이전트는 타겟 콘텐츠만 정밀 추출한다. 가이드가 필요하다."

③ 클로킹 위험

Google: "llms.txt에 사용자용 페이지와 다른 내용을 넣으면 클로킹이 된다." | 도입 진영: "llms.txt는 실제 페이지의 마크다운 요약·링크이지 대체가 아니다. 정직하게 유지하면 클로킹이 아니다."

④ 현재 채택률

Google: "서버 로그상 메이저 AI 봇이 요청조차 하지 않는다." | 도입 진영: "현재 채택 수준은 낮지만 모든 웹 표준이 그렇게 시작했다. 84만 사이트는 유의미한 초기 채택이다."

⑤ 리스크·수익 비율

Google: "측정 가능한 효익 없음 + 클로킹·크롤링 부담 등 부작용 가능성." | 도입 진영: "구현 비용 1~4시간, 유지 비용 0에 수렴. 최악이어도 무해하고, 최선일 경우 초기 우위."

중요한 것은 둘 다 부분적으로 맞다는 점이다. Google의 비판은 "현재 시점의 메이저 AI 봇 행태"에 대한 관찰로는 정확하다. 도입 진영의 주장은 "웹 표준의 장기 진화 패턴"과 "특정 조건에서의 실제 효과 관측"에 기반하면 타당하다. 두 주장은 시간 축이 다르다.

5. 한국의 현실 — 네이버 생태계와 공공·대학의 특수성

네이버 AI 생태계에서 llms.txt는 어떻게 작동하는가

국내 검색 점유율 62.86%의 네이버는 AI 브리핑을 전체 쿼리의 20% 이상에 적용하고 있고, 2026년 상반기 AI 탭 출시를 앞두고 있다. 문제는 네이버가 llms.txt에 대한 공식 입장을 내놓지 않았다는 것이다. Yeti봇의 크롤링 행태에서도 llms.txt 요청은 관측되지 않는다.

현재까지의 관측으로 보면, 네이버 AI 브리핑은 C-Rank와 DIA 기반의 전통적 신호(문서 품질, 사용자 참여, 도메인 권위)에 의존하며, llms.txt의 영향은 제한적으로 판단된다. 한국 시장 중심의 조직이라면, llms.txt 도입에 앞서 C-Rank 점수를 끌어올리는 작업이 우선순위다.

다만 ChatGPT, Perplexity, Claude, Gemini의 글로벌 AI 답변에서 한국 콘텐츠가 인용될 가능성은 llms.txt 구현과 무관하지 않다. 글로벌 AI 답변을 겨냥하는 조직(특히 영어권 타겟이 있는 B2B SaaS, 국제 학술·연구 기관)에게는 llms.txt가 글로벌 쪽 레이어에서 작동할 가능성이 있다.

대학 — 입학홍보처의 계산

서울대 컴퓨터공학부처럼, ChatGPT가 공식 홈페이지가 아닌 나무위키와 블로그를 인용하는 현실이 한국 대학 GEO의 출발점이다. 이 문제에서 llms.txt가 해결사 역할을 할 수 있는가?

직접적 해법은 아니다. 나무위키가 ChatGPT에 인용되는 이유는 구조화된 정보, 깊이 있는 내용, 외부 인용 패턴이 축적됐기 때문이지, llms.txt 때문이 아니다. 대학이 해야 할 1순위는 홈페이지 콘텐츠의 구조화(학과 소개, 교수진, 연구 성과, 입학 정보의 Schema.org 적용)와 깊이 있는 자체 서술이다.

다만 "기본을 갖춘 뒤" 추가 시그널로는 의미가 있을 수 있다. 특히 llms-full.txt 형태로 전체 입학 정보·학과 소개를 한 파일에 통합해둔다면, AI가 해당 대학 콘텐츠를 참조할 때 컨텍스트 효율이 올라갈 수 있다. 단, 이 효익을 실증하는 국내 데이터는 아직 없다. "하면 좋을 수도 있는 것"에 해당한다.

공공기관 — 신뢰 시그널로서의 가치

공공기관의 경우 llms.txt의 가치는 기술적 SEO 효과보다 "공식 채널이 여기 있다"는 신뢰 시그널에 더 가깝다. 정부 부처의 정책 정보가 AI 답변에서 블로그에 밀리는 현실에서, llms.txt는 공식 정보원이 어디인지를 AI에게 명시하는 최소한의 장치다.

특히 정책 발표·개정·집행 단계별 정보를 구조화한 llms-full.txt가 있다면, AI가 해당 정책을 설명할 때 참조 가능성이 올라간다. 공공기관에게 중요한 것은 "AI가 인용할 때 민간 블로그가 아니라 공식 발표를 참조하게 만드는 것"이며, 이 목적에는 llms.txt가 보조 수단으로는 기능할 수 있다.

SaaS — 가장 뚜렷한 효익 구간

아이러니하게도 llms.txt가 가장 명확한 효익을 보이는 곳은 개발자 문서를 가진 B2B SaaS다. 이유는 두 가지다.

첫째, 개발자가 AI 도구로 통합 가이드를 찾는 빈도가 매우 높다. Cursor, Claude Code, GitHub Copilot을 쓰는 개발자가 "이 API 어떻게 연동해?"라고 물었을 때, LLM이 해당 SaaS의 llms-full.txt를 레퍼런스로 활용할 수 있다면 통합 속도가 직접적으로 향상된다. Cloudflare가 전체 문서를 /llms-full.txt로 제공하는 이유가 이것이다.

둘째, 개발자 대상 AI 도구가 llms.txt를 명시적으로 지원하기 시작했다. VS Code의 PagePilot 확장, Drupal의 llms.txt recipe, WordPress의 Yoast·Rank Math 플러그인이 대표적이다. AI 코딩 에이전트가 특정 문서의 llms.txt를 프롬프트 컨텍스트에 주입하는 기능도 표준화되고 있다. Cloudflare는 자사 문서 프롬프트 가이드에서 "AI 에이전트를 프롬프팅할 때 developers.cloudflare.com/workers/llms.txt를 링크하라"고 명시적으로 안내한다.

한국 SaaS 중 이 기회를 잡은 곳은 손에 꼽는다. 개발자 문서가 있는 B2B SaaS라면, llms.txt와 llms-full.txt 도입은 "해도 그만"이 아니라 "하지 않을 이유가 없는" 구간이다.

6. 의사결정 프레임워크 — 당신 조직은 llms.txt를 써야 하는가

체크리스트 A — 선행 조건

llms.txt를 고려하기 전에, 다음 네 가지가 먼저 해결되어 있어야 한다. 이 네 가지가 안 된 상태에서 llms.txt만 올리는 것은 지붕 위에 기와를 얹기 전에 지붕 없는 방에 창문만 다는 것과 같다.

① robots.txt가 AI 봇을 합리적으로 제어하고 있는가? GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended 등 주요 AI 크롤러의 접근 정책이 명시되어 있어야 한다.

② Schema.org 구조화 데이터(JSON-LD)가 핵심 페이지에 적용되어 있는가? Organization, Article, FAQPage, HowTo, Course 등 콘텐츠 성격에 맞는 타입이 적용되어 있어야 한다.

③ sitemap.xml이 정확하고 최신인가? 이것조차 없으면 llms.txt는 검토 대상이 아니다.

④ 자체 콘텐츠의 품질이 E-E-A-T 기준을 충족하는가? 전문성, 경험, 권위, 신뢰를 담은 자체 서술이 있어야 한다. llms.txt는 좋은 콘텐츠의 증폭기이지, 나쁜 콘텐츠의 치료제가 아니다.

체크리스트 B — 조직 유형별 판단

개발자 문서를 가진 B2B SaaS · 테크 플랫폼: 도입 권장. llms.txt와 llms-full.txt 모두 의미가 있다. 특히 llms-full.txt는 AI 코딩 도구의 직접 참조 대상이 될 가능성이 구체적이다.

공공기관 · 정책 기관: 조건부 도입. 선행 조건이 모두 충족된 상태에서, 공식 정보원의 신뢰 시그널로 활용하는 것은 합리적이다. 단, "효과 측정"보다 "신뢰 시그널"의 관점으로 접근해야 한다.

대학 · 교육 기관: 하위 우선순위. 학과 소개·교수 프로필·입학 정보의 구조화가 훨씬 더 시급하다. llms.txt는 그 이후 단계다. 단, 글로벌 학생 모집을 목표로 하는 대학이라면 글로벌 AI 답변에서의 존재감 확보 차원에서 고려 가치가 있다.

영리 기업(일반): 현시점 우선순위 낮음. 리소스가 충분하고 기본 GEO가 완료된 대기업이 아니라면, Schema Markup·콘텐츠 품질·robots.txt 정책 개선에 리소스를 먼저 투입하는 것이 합리적이다.

언론사 · 미디어: 선언적 도입 고려. NYT·CNN·Reuters 사례처럼, 기술적 효익보다 "AI 시대에 대한 공식 입장"으로서의 가치가 크다. 저작권·학습 허용 정책을 공개하는 수단으로 활용할 수 있다.

체크리스트 C — 도입 시 실무 원칙

도입을 결정했다면, 다음 다섯 가지 원칙을 따른다.

① llms.txt와 llms-full.txt를 모두 운영: 인덱스 용도와 컨텍스트 덤프 용도는 분리되어야 한다. 단일 파일만 운영하면 한쪽 유스케이스를 놓친다. Cloudflare·LangGraph·Vercel이 모두 이 이중 패턴을 따른다.

② 자동 생성 파이프라인 구축: 수동 유지는 지속 불가능하다. Mintlify·Fern·Yoast·Rank Math·Drupal의 자동 생성 기능을 활용하거나, CMS 커스텀 빌드에 llms.txt 생성 로직을 포함시킨다. 수동 생성은 도입 후 3개월 내 반드시 낡은 상태가 된다.

③ noindex 헤더 적용: John Mueller의 2025년 7월 권고다. llms.txt 파일 자체가 Google 검색 결과에 노출되면 사용자 경험이 저해된다. HTTP 헤더에 X-Robots-Tag: noindex를 추가해 AI 봇에게는 접근 가능하지만 사용자 검색 결과에는 노출되지 않도록 한다.

④ 정직성 유지: llms.txt에 담긴 내용은 실제 페이지 내용과 일치해야 한다. "AI 봇에게는 이 내용을, 사용자에게는 저 내용을"이라는 이중 콘텐츠는 클로킹으로 간주될 리스크가 있다. llms.txt는 대체가 아니라 요약·큐레이션이다.

⑤ 효과 측정은 별도 지표로: 도입 즉시 AI 인용이 급증할 것이라는 기대는 금물이다. AI 봇 크롤링 로그(BuiltWith·GPTBot·ClaudeBot의 /llms.txt 요청), AI 답변에서의 인용 빈도 변화, 개발자 커뮤니티의 참조 언급을 6개월 단위로 추적한다.

7. 한국 기술 스택별 구현 레퍼런스

Next.js 프로젝트에서의 구현

Lumiscan 같은 Next.js 기반 서비스에서는 /public/llms.txt에 정적 파일을 두거나, app/llms.txt/route.ts에서 동적으로 생성하는 두 가지 방식이 있다. 블로그 섹션이 있는 사이트라면 동적 생성이 권장된다 — 포스트가 추가될 때마다 자동 반영되기 때문이다.

// app/llms.txt/route.ts (Next.js 14+ App Router)
import { getAllPosts } from '@/lib/blog';

export async function GET() {
  const posts = await getAllPosts();
  const content = `# Lumiscan
> AI 검색 최적화(GEO) 분석 플랫폼. 
웹사이트가 ChatGPT·Claude·Perplexity·Gemini에 어떻게 보이는지 진단한다.

## 핵심 문서
- [서비스 소개](https://lumiscan.live): 플랫폼 개요와 4대 진단 카테고리
- [가격 정책](https://lumiscan.live/pricing): 플랜별 기능과 요금
- [MCP 연동 가이드](https://lumiscan.live/mcp): AI 도구에서 직접 분석 요청하는 방법

## 블로그
${posts.map(p => `- [${p.title}](${p.url}): ${p.excerpt}`).join('\n')}

## Optional
- [회사 소개](https://lumiscan.live/about)
- [문의](https://lumiscan.live/contact)
`;
  return new Response(content, {
    headers: {
      'Content-Type': 'text/markdown; charset=utf-8',
      'X-Robots-Tag': 'noindex',
    },
  });
}

WordPress 사이트의 구현

WordPress 사이트라면 Yoast SEO 또는 Rank Math의 최신 버전이 llms.txt 자동 생성을 지원한다. 관리자 메뉴에서 "AI" 또는 "LLM" 섹션을 찾으면 활성화 옵션이 있다. 포함할 포스트 타입, 카테고리, 최대 아이템 수를 지정할 수 있다.

Webflow · Wix · 한국 CMS(이미 웹 · 식스샵 등)

Webflow는 2025년 말부터 llms.txt 업로드 기능을 공식 지원한다. Wix·식스샵·이미 웹 같은 폐쇄형 CMS는 현재 공식 지원이 없으므로, 네이티브 기능 도입을 기다리거나 외부 프록시를 통한 우회 구성이 필요하다. 기업 사이트 리뉴얼 시점에 Next.js·Astro·Hugo 같은 제어 가능한 스택으로의 전환도 고려할 만한 요인이다.

8. 2026년~2027년 전망 — llms.txt는 어디로 가는가

시나리오 A — 비공식 표준화

가장 가능성 높은 경로다. Google이 공식 지원을 거부하더라도, Anthropic·OpenAI·Perplexity 중 하나가 llms.txt를 명시적으로 활용하기 시작하면 판도가 바뀐다. 특히 Anthropic의 Claude는 자사 문서에 이미 llms.txt를 운영하고 있어, Claude의 에이전틱 워크플로우에서 llms.txt를 우선 참조하도록 하는 업데이트가 나올 가능성이 있다. 업계 표준이 "Google이 인정한 것"에서 "AI 네이티브 기업들이 합의한 것"으로 이동하는 흐름이다.

시나리오 B — 영속적 비주류

llms.txt가 일부 개발자 문서·기술 SaaS 생태계에서는 사실상 표준이 되지만, 일반 웹 전반에서는 끝내 주류화되지 못하는 시나리오다. 이 경우에도 개발자 대상 서비스에게는 가치가 유지되며, 일반 웹사이트에게는 "필수 아님"이 지속된다.

시나리오 C — 대체 프로토콜의 등장

llms.txt의 개념 자체(LLM을 위한 큐레이션 레이어)는 유효하지만, 실제 구현은 다른 형태로 진화할 가능성도 있다. Google이 이미 보유한 AI Web Publisher Controls, MCP(Model Context Protocol) 기반의 사이트 연결, Agent2Agent 프로토콜 같은 대체재가 llms.txt 유스케이스를 흡수할 수 있다. 이 경우 llms.txt는 과도기적 산물로 남는다.

세 시나리오 중 어느 쪽으로 가든, 지금 llms.txt를 구현하는 비용은 1~4시간이고, 유지 비용은 자동화 시 0에 수렴한다는 사실은 변하지 않는다. 시나리오 A가 현실화되면 선행 우위를, 시나리오 B에서도 개발자 대상 서비스에게는 가치 유지를, 시나리오 C에서도 전이 비용은 최소한에 그친다. 실리적 관점에서는 "선행 조건이 충족된 조직의 경우, 도입 반대의 근거가 도입 찬성의 근거보다 크지 않다"는 것이 현재의 합리적 결론이다.

9. 결론 — "무엇을 아느냐"가 아니라 "어떻게 판단하느냐"의 문제

llms.txt 논쟁의 교훈은 llms.txt 자체보다 크다. AI 시대의 기술 SEO 결정은 "공식 지원 여부"에 의존해서는 늦다는 것이다. Google이 "안 쓴다"고 선언한 파일을 Anthropic·Cloudflare·Vercel이 운영하고, dev5310 같은 사이트가 실제 AI 인용 상승을 경험하는 상황이다. 한쪽만 듣고 판단하면 기회를 놓치거나, 리소스를 잘못 배분한다.

진짜 질문은 이것이다. 당신의 조직은 AI 답변에서 인용되기 위한 기본기(robots.txt, Schema, sitemap, 콘텐츠 품질)를 먼저 갖췄는가? 갖추지 못했다면, llms.txt는 아직 당신의 문제가 아니다. 갖췄다면, llms.txt 도입에 들어가는 1~4시간의 비용은 가장 낮은 리스크의 실험이다.

루미스캔의 관점은 분명하다. llms.txt는 은총알이 아니지만, AI에게 사이트를 설명하는 여러 레이어 중 하나로 설계되어야 한다. 단일 파일에 의존하는 전략이 아니라, robots.txt(접근 제어) + sitemap.xml(지도) + Schema Markup(의미 구조) + 콘텐츠 품질(E-E-A-T) + llms.txt(큐레이션)의 다층 시그널이 AI 답변 시대의 합리적 아키텍처다.

당신의 사이트는 AI에게 어떻게 보이는가

llms.txt 도입을 고민하기 전에, 당신의 사이트가 현재 AI에게 어떻게 인식되는지를 먼저 측정해야 한다. robots.txt 설정이 주요 AI 크롤러를 제대로 허용하고 있는지, Schema Markup이 핵심 페이지에 적용되어 있는지, 실제 AI 답변에서 당신의 콘텐츠가 어떻게 등장하는지 — 이 기본기를 먼저 진단한 후에야 llms.txt의 도입 여부를 합리적으로 판단할 수 있다.

Lumiscan은 AI 검색 시대에 당신의 웹사이트가 어떻게 평가되는지를 4대 카테고리(Technical SEO, Content Quality, AI Crawler Access, Citation Readiness)로 진단하고, 구조화된 개선 방향을 제시하는 GEO 분석 플랫폼이다. llms.txt를 비롯한 모든 시그널을 종합해, "무엇을 먼저 해야 하는지"를 데이터로 확인할 수 있다.

2026년, AI가 당신의 사이트를 인용할지 결정하는 시간은 점점 짧아지고 있다. 그 판단이 내려지기 전에, 당신이 먼저 준비되어 있어야 한다.