llms.txt는 정말 필요할까? 구글의 2026년 입장 총정리

결론부터 말한다. llms.txt는 지금 구글 검색에서 아무 역할도 하지 않는다. 구글 담당자가 2026년에만 세 차례, 공개된 자리에서 직접 이렇게 확인했다. 새 파일 하나 더 만드는 데 시간을 쓸지 고민하고 있다면, 그 고민은 이 글 하나로 끝내도 된다.

llms.txt란 AI가 웹사이트 내용을 더 잘 이해하도록 돕기 위해 만드는 마크다운 요약 파일이다. 2024년 등장 이후 "이것도 안 만들면 AI 검색에서 뒤처진다"는 불안 섞인 마케팅이 꾸준히 따라붙었다. 그런데 정작 이 파일을 가장 많이 쓸 것으로 기대됐던 구글은, 정반대의 이야기를 반복해서 하고 있다.

이 글은 홈페이지·쇼핑몰을 운영하며 "AI 검색에 대응하려면 무엇부터 해야 하나"를 고민하는 사업주와 마케팅 담당자를 위해 쓴다. 결론이 이미 나와 있는 사안에 예산과 시간을 계속 쓰고 있지는 않은지, 지금 확인해 보자.

특히 이 주제는 검증 없이 소비되기 쉬운 영역이다. "AI 시대에는 이것도 해야 한다"는 조언이 매일 쏟아지는데, 정작 그 조언이 실제 데이터나 공식 발언에 근거하는지 확인하는 사람은 많지 않다. 이 글은 추측이나 유행이 아니라, 구글이 직접 남긴 발언의 원문과 날짜, 그리고 13만 개가 넘는 도메인을 대상으로 한 실측 조사만을 근거로 삼는다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• llms.txt가 무엇이고 왜 만들어졌는지, 2024년 원래 제안의 취지
• 구글이 2026년 세 차례 공개적으로 남긴 정확한 발언과 날짜
• 13만 개가 넘는 도메인을 조사한 실제 데이터 — 게시율과 방치율
• llms.txt가 통하지 않은 구조적인 이유(검색 색인과 LLM 학습·에이전트의 차이)
• 실제 llms.txt 예시로 보는 좋은 예 vs 나쁜 예
• 그렇다면 지금 시간을 써야 할 진짜 대안 세 가지
• 예외적으로 llms.txt가 여전히 쓸모 있는 좁은 영역과 WebMCP라는 새 표준
• 이미 만든 llms.txt를 지워야 하는지에 대한 실전 답

용어부터 짚어 보자. 어려운 말은 나오는 자리에서 바로 풀어 쓴다. 예를 들어 이 글에서 자주 나오는 "크롤링"은 검색엔진이나 AI가 웹페이지를 자동으로 읽어 가는 행위를 뜻하고, "색인"은 그렇게 읽은 내용을 검색이 가능하도록 데이터베이스에 정리해 두는 과정을 말한다. 이 구분을 기억해 두면 이후 설명이 훨씬 쉽게 읽힌다.

llms.txt란 정확히 무엇인가?

llms.txt는 웹사이트 루트 경로(/llms.txt)에 두는 마크다운 문서로, AI가 사이트의 핵심 콘텐츠를 빠르게 파악하도록 돕기 위해 고안된 요약·링크 목록이다. 검색엔진이 오래전부터 써 온 robots.txt와 이름이 비슷해 같은 계열의 표준으로 오해하기 쉽지만, 둘은 태생부터 다르다.

robots.txt는 구글·네이버 같은 검색엔진이 20년 넘게 실제로 읽고 지키는 공식 규약이다. 반면 llms.txt는 2024년 9월, AI 스타트업 Answer.AI의 제레미 하워드가 개인적으로 제안한 아이디어에서 출발했다. 당시 제안의 문제의식은 이랬다. AI에게 사이트 맥락을 알려주려 할 때 "사이트맵을 통째로 크롤링해 모든 페이지를 넣어야 하나, 아니면 일부만 골라 넣어야 하나"가 애매하다는 것이었다.

이 애매함을 풀기 위해 하워드가 제시한 형식은 단순하다. 사이트 이름을 담은 제목 한 줄, 짧은 요약, 그리고 섹션별로 정리한 핵심 페이지 링크 목록. 최소한의 예시를 보면 이렇다.

# 이루웹

> 홈페이지·쇼핑몰 제작과 SEO를 함께 다루는 제작사

## 핵심 페이지
- [서비스 소개](https://iruweb.com/services): 제작 상품 전체 목록
- [블로그](https://iruweb.com/blog): SEO·AI 검색 실전 가이드

## Optional
- [회사 소개](https://iruweb.com/about): 부가 정보, 생략 가능

형식만 보면 사람이 읽기에도 깔끔하고, 기계가 파싱하기에도 규칙적이다. 문제는 이 형식이 "잘 만들어졌는가"가 아니라 "누군가 이걸 실제로 읽는가"에 있다는 점이며, 이는 뒤에서 데이터로 확인한다.

llms.txt를 robots.txt·사이트맵·JSON-LD 같은 다른 파일들과 나란히 놓으면 위상 차이가 분명해진다.

구분	등장 시점	제정 주체	검색엔진 실사용 여부
robots.txt	1994년	업계 합의 표준(현재 IETF 표준)	사용함(20년 넘게 공식 규약)
sitemap.xml	2005년	구글·야후·MS 공동 제안	사용함(구글 공식 지원)
JSON-LD 구조화 데이터	2011년(스키마.org)	구글·MS·야후·얀덱스 공동	사용함(리치 결과에 직접 반영)
llms.txt	2024년 9월	개인 제안(Answer.AI)	구글이 공개적으로 사용 부인

llms.txt는 표준이 아니라 제안이다. 특정 기관이 아닌 개인 제안에서 시작됐고, 구글·오픈AI 같은 주요 플랫폼 어느 쪽도 이를 공식 표준으로 채택한 적이 없다.

이 구분이 중요한 이유는 명확하다. robots.txt·사이트맵·구조화 데이터는 안 만들면 손해지만, llms.txt는 안 만들어도 원래 아무 의무가 없던 파일이기 때문이다. 문제는 이 넷이 이름의 유사성과 등장 방식 때문에 실무 현장에서 비슷한 무게로 취급되는 경우가 많았다는 점이다. 이어지는 항목에서 구글이 이 오해를 어떻게 직접 정리했는지 시간순으로 살펴본다.

구글은 llms.txt에 대해 정확히 뭐라고 말했나?

결론은 명확하다. 구글 검색팀은 2026년에만 공개된 자리에서 세 번, llms.txt에 대해 부정적인 입장을 직접 확인했다. 담당자는 존 뮬러(John Mueller), 구글의 오랜 서치 애드보킷이다.

첫 번째는 2026년 1월 20일, 블루스카이(Bluesky)에서 나왔다. 한 이용자가 "구글의 여러 프로퍼티(개발자 문서 사이트 등)에 llms.txt 파일이 올라와 있는데, 이게 구글의 공식 지지를 뜻하느냐"고 물었다. 뮬러의 답은 짧고 직접적이었다.

"이 질문이 워낙 자주 나와서 뭔가 시니컬하게 답하고 싶은 유혹이 들지만, 직접적으로 말하면 — 아니다(no)."

배경을 조금 더 보면 이렇다. 구글의 콘텐츠관리시스템(CMS)이 llms.txt 지원 기능을 추가하면서 일부 구글 개발자 문서 사이트에 이 파일이 자동으로 올라간 적이 있다. 이후 구글 검색팀은 자신들이 관리하는 문서에서는 이를 빼냈지만, 다른 팀이 관리하는 사이트 몇 곳에는 그대로 남아 있었다. 이 잔재가 "구글도 쓰는 것 아니냐"는 오해를 계속 낳았고, 뮬러가 이를 정면으로 부인한 것이다.

두 번째는 2026년 6월 2일, 레딧(Reddit)에서 나왔다. 구글 서치 센트럴 문서와 크롬 라이트하우스(Lighthouse) 문서가 llms.txt에 대해 서로 다른 뉘앙스를 담고 있는 것처럼 보인다는 지적에, 뮬러는 이렇게 답했다.

"누구도 정확히는 모른다고 생각한다 — 지금은 순전히 추측일 뿐이다(이 파일은 수년째 존재해 왔는데, 어떤 AI 시스템도 이를 쓰지 않는다 — 이게 무슨 의미겠나)."

이 발언에서 눈여겨봐야 할 부분은 두 가지다. 첫째, "수년째 존재했지만 어떤 AI 시스템도 쓰지 않는다"는 문장 자체가 이미 결론을 담고 있다. 둘째, 뮬러는 이 자리에서 대안까지 제시했다. AI가 굳이 사람이 미리 요약해 둔 llms.txt를 읽기보다는, AI 에이전트가 웹사이트의 실제 기능(장바구니 담기, 폼 작성, 상품 비교 등)을 직접 호출하도록 하는 방식이 더 유용하다는 취지였다. 이때 언급된 개념이 구글이 미는 새 표준인 WebMCP이며, 이는 뒤에서 별도로 다룬다.

세 번째는 불과 보름 뒤인 2026년 6월 17일, 구글의 공식 팟캐스트 "Search Off the Record"에서 나왔다. 이번에는 조금 더 근본적인 지적이었다. 뮬러는 llms.txt가 결국 사이트 운영자가 스스로 작성하는 자기 신고형 정보라는 점을 짚었다.

"이건 기본적으로 이 시스템들에게 '내가 최고의 웹사이트야'라고 스스로 말하는 것과 같다."

이 비유는 llms.txt의 근본적인 한계를 정확히 짚는다. 검색 순위는 제3자(검색엔진)가 객관적으로 평가한 결과여야 신뢰할 수 있는데, llms.txt는 사이트 주인이 자기 입으로 "나는 훌륭하다"고 적어 넣는 파일이라는 것이다. 다만 뮬러는 이 자리에서 완전히 쓸모없다고 선을 긋지는 않았다. AI 에이전트가 이미 그 사이트에 들어와 있는 상태에서 특정 페이지로 이동하거나 작업을 마무리하는 데는 제한적으로 도움이 될 수 있다는 여지는 남겼다. 다만 이는 "검색에서 발견되고 인용되는 것"과는 전혀 다른, 훨씬 좁은 역할이라는 점을 분명히 했다.

세 발언을 나란히 놓고 보면 다음과 같이 정리된다.

시점	채널	핵심 발언	의미
2024년 9월	Answer.AI 블로그	제레미 하워드, llms.txt 최초 제안	표준이 아닌 개인 제안으로 시작
2026년 1월 20일	블루스카이	"직접적으로 말하면, 아니다"	구글 검색팀의 공식 지지 여부를 명시적으로 부인
2026년 6월 2일	레딧	"순전히 추측일 뿐 — 어떤 AI도 쓰지 않는다"	실효성 자체에 의문 제기 + WebMCP 대안 제시
2026년 6월 17일	구글 공식 팟캐스트	"내가 최고의 웹사이트라고 스스로 말하는 것"	자기 신고형 정보라는 구조적 한계 지적

세 발언 모두 "구글이 나쁘게 본다"는 인상 정도가 아니라, "실제로 아무 시스템도 쓰지 않고, 쓰더라도 신뢰할 근거가 약하다"는 관찰에 가깝다는 점이 중요하다. 다음 항목에서는 이 관찰이 실제 데이터로도 확인되는지 살펴본다.

이 발언들이 나올 때마다 서치 엔진 저널, 서치 엔진 랜드 같은 해외 주요 SEO 매체는 물론 국내 여러 마케팅 매체까지 곧바로 이를 보도했다. 짧은 발언 하나에 이 정도로 관심이 쏠린 것 자체가, 그만큼 업계에 llms.txt를 둘러싼 불안과 궁금증이 컸다는 방증이기도 하다. 동시에 세 발언 모두 같은 결론을 반복해서 확인해 줬다는 점에서, 이번만큼은 실무자들이 비교적 명확한 기준을 얻은 셈이다.

실제로 AI가 llms.txt를 읽고 있나?

구글의 발언만으로는 "구글이 안 쓴다"는 사실만 알 수 있다. 그렇다면 다른 AI 서비스들은 실제로 이 파일을 읽고 있을까. 2026년 5월, 이 질문에 대한 대규모 실측 데이터가 나왔다.

Ahrefs가 자사 웹 분석 트래픽을 보유한 도메인 137,210개의 서버 로그를 직접 분석한 결과다. 단순히 파일이 존재하는지만 본 것이 아니라, 실제로 이 파일에 어떤 요청이 얼마나 들어오는지까지 확인했다는 점에서 지금까지 나온 조사 중 가장 신뢰도가 높다.

결과부터 보면 이렇다. 조사 대상의 28%(38,360개 도메인)가 유효한 llms.txt 파일을 게시하고 있었다. 1년 전 조사 대비 여덟 배 넘게 늘어난 수치다. 얼핏 보면 빠르게 확산되는 것처럼 보인다. 다만 이 표본은 Ahrefs 도구를 쓰는, 기술·SEO에 밝은 사이트 쪽으로 치우쳐 있어 28%도 상한선에 가깝다는 점은 감안해야 한다.

비슷한 시기 다른 조사도 이를 뒷받침한다. 리랭커빌리티(Rankability)가 트란코(Tranco) 상위 1,000개 도메인만 따로 추적한 2026년 6월 조사에서는 8.7%만 llms.txt를 게시하고 있었다(접속이 가능한 사이트만 따지면 15.8%). 표본과 방법론은 다르지만, "만들어는 두지만 다수는 아니다"라는 방향은 두 조사가 일치한다.

하지만 진짜 중요한 숫자는 그다음이다. 이렇게 게시된 파일 가운데 97%가 2026년 5월 한 달 동안 단 한 건의 요청도 받지 못했다. 요청이 있었던 파일은 전체의 3%, 약 1,100개 도메인에 불과했다. 그리고 그 얼마 안 되는 요청조차 대부분 AI가 아니었다.

요청 주체	비중(요청이 있었던 파일 기준)
SEO 점검 도구	21.7%
일반 크롤러·프로파일링 봇	약 25%
llms.txt 자체를 연구하는 업계 조사	12%
실제 AI 검색봇	1.1%
AI 봇 전체(코딩 에이전트 포함)	19.5%
사람이 직접 접속	4%

여기서 흥미로운 예외 하나가 있다. 코딩 에이전트(예: 개발 보조 AI 도구)가 만들어 낸 요청이 AI 검색봇의 요청보다 많았다는 점이다. 이는 llms.txt가 검색 노출과는 무관하더라도, 개발 문서나 API 사이트에서 코딩 도구를 돕는 좁은 용도로는 일부 쓰일 수 있다는 뜻이다. 이 예외는 뒤에서 다시 다룬다.

이 통계를 SEO 실무자 입장에서 풀어 쓰면 다음과 같다. 파일을 만드는 것 자체는 쉽지만, 만든다고 누군가 읽어 준다는 보장은 전혀 없다. 게시율이 늘어난 것은 "다들 만드니까 나도 만든다"는 유행에 가깝지, 실제 효용이 검증돼서 늘어난 것이 아니라는 뜻이다.

왜 llms.txt는 통하지 않았나?

구조적인 이유를 이해하면 이 결과가 우연이 아니라는 것이 보인다. 핵심은 하나다. 구글 검색과 AI 오버뷰는 이미 자체 크롤러와 색인 시스템을 갖고 있고, 그 시스템은 사람이 미리 요약해 준 파일이 아니라 페이지 원문 전체를 대상으로 작동한다는 점이다.

구글의 AI 검색 기능(AI 오버뷰·AI 모드)은 RAG(검색증강생성, Retrieval-Augmented Generation)라는 방식으로 작동한다. 쉽게 말해 사용자의 질문이 들어오면, 먼저 구글이 이미 갖고 있는 검색 색인에서 관련성 높은 페이지를 찾아낸 다음, 그 페이지들의 실제 내용을 근거로 답을 생성하는 구조다. 이 과정에서 참고하는 것은 이미 색인된 페이지 원문이지, 사이트 운영자가 별도로 만들어 둔 요약 파일이 아니다.

비유하면 이렇다. 호텔에 이미 자체 안내 데스크와 정확한 객실 목록이 있는데, 손님이 굳이 로비 한쪽에 붙여 둔 "제가 직접 요약한 저희 호텔 소개문"을 참고할 이유는 없다. 안내 데스크(검색 색인)가 이미 모든 객실 정보를 정확히 알고 있기 때문이다.

다시 말해 llms.txt가 노렸던 문제, 즉 "AI가 사이트의 어떤 페이지를 봐야 할지 애매하다"는 문제는 구글 입장에서는 이미 크롤링·색인 단계에서 해결된 문제다. 검색엔진은 20년 넘게 이 문제를 풀어 온 시스템을 갖고 있고, 그 위에 새로운 AI 기능을 얹었을 뿐이다. 그러니 굳이 별도 요약 파일을 추가로 참고할 유인이 없다.

여기에 더해 실무적인 장벽도 있다. 사이트 하나에 페이지가 수백, 수천 개라면 llms.txt 안에 어떤 페이지를 넣고 뺄지 사람이 일일이 판단해야 한다. 이 판단 자체가 이미 검색엔진이 크롤링·품질 평가로 자동화해 놓은 일을 손으로 다시 하는 셈이라, 효율이 떨어진다. 뮬러가 6월 2일 레딧에서 지적한 "AI로 llms.txt를 생성하게 하느니 AI 에이전트가 알아서 만들면 되는 것 아니냐"는 취지의 언급도 이 지점을 겨냥한 것이고, 6월 17일 팟캐스트의 "자기 신고형 정보"라는 지적도 같은 맥락이다. 사이트 주인이 직접 쓴 요약은 객관적인 검증을 거치지 않았기 때문에, 랭킹의 근거로 삼기에는 애초에 신뢰도가 낮다.

llms.txt는 크롤링·색인이라는, 검색엔진이 이미 갖고 있는 인프라를 사람이 손으로 대신하려는 시도였고, 정작 그 인프라의 주인인 구글은 이를 쓸 이유가 없었다는 것이 이번 항목의 핵심이다.

여기에 더해 짚어 둘 사실이 하나 더 있다. 구글뿐 아니라 오픈AI의 GPTBot, 앤트로픽의 ClaudeBot, 퍼플렉시티의 PerplexityBot처럼 주요 AI 회사들도 각자 자체 크롤러를 운영하며 웹페이지의 HTML 원문 전체를 직접 가져간다. 이 크롤러들 역시 llms.txt라는 별도 요약 파일을 우선 참조하도록 설계돼 있지 않다. 결국 llms.txt는 구글 하나만의 문제가 아니라, 지금 웹을 실제로 읽어 가는 대부분의 AI 크롤러 구조와 애초에 접점이 적은 파일이었던 셈이다.

여기서 크롤 예산(crawl budget)이라는 개념도 함께 알아 두면 도움이 된다. 크롤 예산이란 검색엔진이 한 사이트를 방문해 한 번에 읽어 갈 수 있는 페이지 수의 한도를 뜻한다. 사이트 구조가 명확하고 불필요한 페이지가 적을수록 이 예산이 중요한 페이지에 집중된다. 이 예산 배분에 실제로 영향을 미치는 것은 robots.txt의 크롤링 규칙과 사이트맵의 우선순위 설정이지, llms.txt가 아니다. 그러니 "AI가 우리 사이트를 효율적으로 읽게 만들고 싶다"는 목표라면, 이 예산 관리에 직접 관여하는 두 파일부터 손보는 것이 순서에 맞다.

이 조사 결과, 어디까지 믿을 수 있나?

숫자를 인용하기 전에 근거의 무게를 따져 보는 것도 중요하다. 이번 글이 근거로 삼은 Ahrefs 조사는 자체 웹 분석 서비스 이용자의 실제 서버 로그를 분석한 1차 데이터라는 점에서 신뢰도가 높다. 설문이나 추정이 아니라, 실제로 어떤 봇이 언제 어떤 파일에 접속했는지를 로그 단위로 확인했기 때문이다.

다만 한계도 분명히 짚어야 공정하다. 이 조사는 Ahrefs 도구를 쓰는 사이트, 즉 SEO에 어느 정도 신경 쓰는 운영자의 사이트로 표본이 치우쳐 있다. 그래서 28%라는 게시율은 웹 전체 평균보다는 높게 나온 수치일 가능성이 크고, 실제 웹 전체로 보면 게시율은 이보다 낮을 것으로 추정하는 편이 안전하다. 반대로 리랭커빌리티가 별도로 조사한 상위 1,000개 사이트 대상 8.7%라는 수치는 표본이 다르지만 방향은 같다는 점에서, 서로 다른 두 조사가 같은 결론을 향하고 있다는 점이 오히려 신뢰도를 뒷받침한다.

숫자 하나만 보고 결론을 내리기보다, 서로 다른 방법론의 조사가 같은 방향을 가리키는지 확인하는 것이 팩트체크의 기본이다. 이 글은 그 원칙에 따라 최소 두 개 이상의 독립된 자료로 교차 확인했다.

실제 llms.txt 파일은 어떻게 생겼나? 좋은 예 vs 나쁜 예

만들지 않는 편이 낫다고 해도, 이미 만들었거나 예외적인 이유로 만들어야 한다면 형식만큼은 제대로 지키는 것이 좋다. 형식이 틀리면 파일이 아예 파싱되지 않아, 그나마의 부수적 효과(코딩 에이전트 참조 등)조차 기대할 수 없기 때문이다.

나쁜 예부터 보자. 아래는 실제로 흔히 발견되는 잘못된 패턴이다.

llms.txt 안 좋은 예:
- 제목(H1) 없이 본문부터 시작
- 링크 목록 대신 광고성 문구 나열("업계 1위!", "최고의 선택!")
- 사이트의 모든 페이지 수백 개를 필터 없이 통째로 나열
- 마지막 수정일도, 섹션 구분도 없이 텍스트 뭉치로 방치

이런 파일은 형식 오류로 아예 인식되지 않거나, 인식되더라도 정보 밀도가 낮아 코딩 에이전트조차 활용하기 어렵다. 무엇보다 뮬러가 지적한 "자기 신고형 과장"의 전형적인 예다.

좋은 예는 이 글 앞부분에서 소개한 형식처럼, 제목과 요약 한 줄, 그리고 핵심 페이지 몇 개만 간결하게 링크하는 것이다. 굳이 만든다면 다음 원칙을 지킨다.

페이지 수가 10개 안팎으로 적고, 실제로 개발자·AI 에이전트가 반복적으로 참조할 문서·API 성격의 사이트가 아니라면, 이 파일에 형식을 고민할 시간 자체를 아예 쓰지 않는 것이 낫다.

그래도 지금 만들어두면 손해는 아니지 않나?

"밑져야 본전 아니냐"는 질문이 자주 나온다. 답은 "완전한 손해는 아니지만, 우선순위를 잘못 잡을 위험이 크다"는 것이다. 아래 비교로 실제 시간 배분의 차이를 보자.

llms.txt 하나 만드는 데 걸리는 시간 자체는 크지 않다. 문제는 이 파일을 "AI 대응의 핵심 과제"로 착각해 우선순위 맨 위에 두는 경우다. 실제로 일부 대행사는 "AI 검색 최적화 패키지"라는 이름으로 llms.txt 제작을 유료 항목에 넣어 판매하기도 했는데, 이는 구글이 이미 부인한 효과를 근거로 비용을 청구하는 셈이다.

이미 비용을 들여 llms.txt를 만들었다고 해서, 그 매몰비용 때문에 계속 이 파일에 힘을 쏟을 필요는 없다. 이미 쓴 시간은 되돌릴 수 없지만, 앞으로 쓸 시간은 지금부터 다시 정할 수 있다.

반대로 같은 시간을 구조화 데이터 정비나 사이트맵 점검에 쓰면, 그 결과는 구글이 실제로 사용을 확인한 시스템에 곧바로 반영된다. JSON-LD 구조화 데이터는 리치 결과(별점·가격 등이 검색 결과에 함께 표시되는 것)에 직접 관여하고, 사이트맵은 색인 여부와 직결된다. 이 차이가 표에 정리한 두 갈래 시나리오의 핵심이다.

실제 상담에서도 비슷한 장면이 자주 반복된다. "AI 검색 시대라는데 우리도 뭔가 해야 하지 않느냐"는 질문을 받고 사이트를 살펴보면, 정작 사이트맵이 반년 넘게 갱신되지 않았거나, 상품 페이지에 구조화 데이터가 아예 없는 경우가 많다. 이런 상태에서 llms.txt부터 만드는 것은 기초 공사가 안 된 건물에 간판만 새로 다는 것과 같다. 우선순위를 거꾸로 잡으면 들인 시간에 비해 남는 결과가 없다.

llms.txt 대신 무엇에 시간을 써야 하나?

답은 셋으로 정리된다. 첫째 구조화 데이터, 둘째 사이트맵과 크롤링 접근성, 셋째 품질 콘텐츠다. 모두 구글이 공식 문서에서 실제 사용을 확인한 요소들이다.

첫째, JSON-LD 구조화 데이터다. 페이지 내용을 스키마.org가 정한 표준 용어로 마크업해 두면, 구글은 이를 통해 이 페이지가 글인지 상품인지 조직 정보인지를 코드 차원에서 명확히 구분한다. 리치 결과 노출은 물론, AI 오버뷰가 답을 구성할 때도 근거로 삼기 쉬운 형태다. 이 구조화 데이터를 처음부터 정리하는 방법은 JSON-LD 스키마 마크업 가이드에서 코드 예시와 함께 다뤘다.

둘째, 사이트맵(sitemap.xml)과 robots.txt 점검이다. 사이트맵은 검색엔진에게 "우리 사이트에 이런 페이지들이 있다"고 알려주는 공식 목록이고, robots.txt는 크롤러의 접근을 허용·차단하는 규칙이다. 둘 다 20년 넘게 검색엔진이 실제로 읽고 지키는 표준이라는 점에서 llms.txt와는 근본적으로 무게가 다르다. 사이트맵을 아직 제대로 갖추지 못했다면 사이트맵 만드는 법과 robots.txt 설정 가이드부터 먼저 챙기는 편이 llms.txt보다 우선한다.

셋째, 품질 콘텐츠다. 결국 AI 오버뷰든 일반 검색 순위든, 근본적으로 참고하는 것은 그 페이지 자체의 완성도다. 남들과 다른 실제 경험, 구체적인 수치와 사례, 명확한 정의 문장이 담긴 콘텐츠가 인용될 확률을 높인다. 이 원칙과 구글의 최신 공식 가이드 전반은 구글 첫 공식 AI 검색 최적화 가이드에서 자세히 정리했고, AI가 사이트를 인용하게 만드는 콘텐츠 전략은 GEO 생성형엔진최적화 가이드에서 폭넓게 다뤘다.

아래 체크리스트로 오늘 바로 점검할 수 있다.

업종별로 어떻게 적용해야 하나?

원칙은 같지만 우선순위 비중은 업종마다 다르다. 아래 표로 정리했다.

업종	우선 점검 항목	이유
쇼핑몰·이커머스	상품 스키마(JSON-LD)·재고·가격 정보 최신화	리치 결과와 AI 오버뷰 모두 상품 정보를 구조화 데이터에서 우선 참조
병원·법률 등 전문 서비스	실제 경험·자격 정보(E-E-A-T) 콘텐츠	신뢰도가 인용 여부를 좌우하는 대표적인 YMYL(민감) 분야
로컬 비즈니스	구글 비즈니스 프로필·지역 스키마	검색·지도·AI 답변 모두 위치 정보의 정확성에 직접 좌우됨
콘텐츠·미디어 사이트	사이트맵 최신화·내부 링크 구조	페이지 수가 많을수록 색인 누락을 막는 기초 작업의 효과가 큼
개발 도구·API 문서 사이트	(예외적으로) llms.txt 부수 게시 고려	코딩 에이전트가 실제로 참조하는 좁은 사례가 관찰됨

쇼핑몰이라면 상품 하나하나에 가격·재고·리뷰 점수 같은 정보를 JSON-LD로 정확히 마크업해 두는 것이 llms.txt보다 훨씬 먼저다. 이 정보가 정확해야 검색 결과에 별점·가격이 함께 뜨는 리치 결과가 생기고, AI 오버뷰도 상품을 비교해 답할 때 이 데이터를 근거로 쓴다.

병원·법률처럼 결과가 사람의 건강이나 자산에 영향을 미치는 분야는 구글이 특히 신뢰도를 까다롭게 본다. 실제 자격증·경력·사례 같은 구체적인 근거가 담긴 콘텐츠가 llms.txt 같은 요약 파일보다 인용 확률을 훨씬 크게 높인다.

로컬 비즈니스는 지도 검색과 AI 답변 모두에서 위치 정보 정확성이 핵심이다. 구글 비즈니스 프로필의 주소·영업시간·전화번호가 실제와 다르면, 아무리 좋은 콘텐츠를 써도 손님이 헛걸음하게 된다.

콘텐츠·미디어 사이트처럼 페이지 수가 많은 경우, 사이트맵이 최신 상태로 유지되지 않으면 새 글이 색인에서 누락되는 일이 흔하다. 이 기초 작업의 효과가 llms.txt보다 훨씬 직접적이고 크다.

표의 마지막 줄이 중요하다. 개발 문서나 API 레퍼런스 사이트라면 llms.txt를 완전히 배제할 필요까지는 없다. 앞서 살펴본 Ahrefs 조사에서도 코딩 에이전트발 요청이 관찰됐기 때문이다. 다만 일반적인 홈페이지·쇼핑몰·블로그라면 이 예외에 해당하지 않는다.

오늘부터 4주, 어떤 순서로 챙기면 되나?

막연한 "AI 대응"을 실제로 반복 가능한 업무로 바꾸려면 순서를 정해 두는 것이 좋다. 업종에 관계없이 대체로 아래 순서가 효율적이다.

주차	초점	구체적으로 할 일
1주차	접근성 점검	robots.txt에서 주요 AI 크롤러를 실수로 차단하고 있지 않은지 확인
2주차	색인 기반 정비	서치 콘솔에서 사이트맵 제출 상태와 색인 오류 확인·수정
3주차	구조화 데이터	핵심 페이지(상품·서비스·조직 정보)에 JSON-LD 마크업 추가
4주차	콘텐츠 보강	방문자가 많은 페이지부터 실제 경험·구체적 수치로 내용 보강

이렇게 4주를 한 바퀴 돌리고 나면, 다음 달에는 우선순위가 낮았던 페이지로 범위를 넓혀 같은 순서를 반복하면 된다. 중요한 것은 매달 이 네 항목을 습관처럼 점검하는 루틴이지, 한 번에 완벽하게 끝내는 것이 아니다.

WebMCP는 무엇이고 지금 신경 써야 하나?

결론부터 말하면 대부분의 홈페이지 운영자에게는 아직 급하지 않다. WebMCP(Web Model Context Protocol)는 뮬러가 llms.txt의 대안으로 언급한 개념으로, AI 에이전트가 웹사이트의 실제 기능(장바구니에 담기, 예약 폼 제출, 상품 옵션 비교 등)을 사람이 클릭하듯 흉내 내는 대신 표준화된 방식으로 직접 호출하도록 만드는 브라우저·웹 표준이다.

쉽게 비유하면 이렇다. 지금까지 AI 에이전트가 쇼핑몰에서 물건을 대신 주문하려면, 사람이 보는 것과 똑같은 HTML 화면을 해석해 버튼 위치를 추측하며 클릭해야 했다. WebMCP는 이 과정을 없애고, 웹사이트가 다음과 같은 기능 자체를 AI가 바로 호출할 수 있는 형태로 미리 공개해 두는 방식이다.

• 장바구니에 상품 담기(수량·옵션 지정 포함)
• 예약 가능 시간 조회 및 예약 확정
• 배송 상태·주문 내역 조회
• 상품 옵션·가격 비교

이 개념은 구글이 2026년에 제안한 비교적 새로운 표준이라, 아직 실무에서 표준적으로 적용해야 할 만큼 성숙하지는 않았다. 다만 에이전트가 실제로 결제·예약 같은 행동을 대신 수행하는 상거래·예약 중심 사이트라면 앞으로의 방향으로 눈여겨볼 가치는 있다. 반대로 정보 제공이 목적인 블로그·소개 페이지라면 지금 당장 이 표준까지 챙길 필요는 없다.

구조화 데이터에 이미 익숙하다면 WebMCP를 "행동(action)을 위한 구조화 데이터"라고 이해하면 쉽다. 지금까지 JSON-LD 구조화 데이터가 "이 페이지는 무엇에 관한 것인가"라는 정보를 AI에게 알려주는 역할이었다면, WebMCP는 "이 페이지에서 무엇을 할 수 있는가"라는 행동을 AI에게 알려주는 역할을 맡는다는 차이가 있다. 다만 이 표준은 아직 초기 단계라 실제 도입 사례가 많지 않으므로, 지금은 개념만 알아 두고 상거래 플랫폼을 운영한다면 향후 지원 여부를 지켜보는 정도로 충분하다.

그럼 llms.txt는 완전히 쓸모없나?

아니다. 검색 노출이라는 목적에는 쓸모가 없다는 뜻이지, 모든 상황에서 무가치하다는 뜻은 아니다. 이 구분을 정확히 해 두는 것이 이 글의 핵심 갈림길이다.

앞서 확인했듯 코딩 에이전트가 개발 문서 사이트의 llms.txt를 참조하는 사례는 실제로 관찰됐다. 오픈소스 라이브러리 문서, API 레퍼런스처럼 개발자가 AI 코딩 도구와 함께 작업하는 성격의 사이트라면, 부수적으로 llms.txt를 게시해 둘 여지는 있다. 뮬러도 6월 17일 팟캐스트에서 "이미 사이트에 들어와 있는 에이전트가 특정 작업을 마무리하는 데는" 제한적으로 도움이 될 수 있다고 인정했다. 다만 이 경우에도 핵심 우선순위가 아니라 여유가 있을 때 하는 부가 작업이라는 위치는 바뀌지 않는다.

일반 홈페이지·쇼핑몰·블로그 운영자에게는 결론이 다르다. 검색 노출을 위해 llms.txt를 만들 필요는 없다. 구글이 세 차례 공개적으로 확인했고, 13만 개 넘는 도메인 실측 데이터도 이를 뒷받침한다. 이미 다른 우선순위 작업이 밀려 있다면, llms.txt는 그 뒤로 미뤄도 된다.

llms.txt 논쟁이 처음이 아니다

이런 패턴이 낯설지 않다면 맞다. 검색엔진 역사에서 "만들어 두면 좋을 것 같은 파일이, 알고 보니 아무 효과가 없었다"는 사례는 이번이 처음이 아니다. 대표적인 예가 메타 키워드 태그다.

한때 웹페이지의 <head> 안에 핵심 키워드를 나열해 두는 메타 키워드 태그가 순위에 영향을 준다고 널리 알려졌던 시절이 있었다. 하지만 검색엔진들은 이미 오래전부터 공식적으로 이 태그를 순위에 반영하지 않는다고 밝혔다. 이유는 llms.txt와 놀랍도록 닮아 있다. 사이트 운영자가 스스로 적어 넣는 자기 신고형 정보는 조작하기 쉬워, 객관적인 신뢰의 근거로 삼기 어렵다는 것이다.

두 사례를 나란히 놓고 보면 패턴이 더 뚜렷하게 보인다.

구분	메타 키워드 태그	llms.txt
처음 퍼진 이유	"키워드만 나열하면 순위가 오른다"는 기대	"AI에게 요약을 주면 잘 이해할 것"이라는 기대
실제 문제	누구나 아무 단어나 채워 넣을 수 있어 신뢰 불가	사이트 주인이 스스로 "좋은 사이트"라고 적는 구조
검색엔진의 대응	순위 요인에서 공식 배제	사용 안 함을 공개 발언으로 확인
지금도 남은 오해	아직도 채워 넣어야 한다고 믿는 운영자가 있음	"안 만들면 뒤처진다"는 불안이 여전히 존재

새로운 기술이 등장할 때마다 "이 파일 하나만 더 만들면 안전하다"는 불안이 반복되고, 그때마다 검증 안 된 상품이 그 불안을 파고든다는 것이 이 역사가 주는 교훈이다. llms.txt 역시 이 패턴에서 크게 벗어나지 않았다. 다른 점이 있다면, 이번에는 구글이 훨씬 이른 시점에, 그것도 세 차례나 반복해서 명확히 선을 그어 줬다는 것 정도다.

이미 만든 llms.txt는 지워야 하나?

급하게 지울 필요는 없다. 구글은 "역효과가 있다"고 말한 것이 아니라 "효과가 없다"고 말했다. 이미 만들어 둔 파일이 검색 순위에 해를 끼치지는 않는다.

다만 관리 부담이 있다면 정리하는 것도 합리적인 선택이다. 페이지가 자주 바뀌는 사이트라면 llms.txt 안의 링크 목록도 함께 최신화해야 하는데, 아무도 읽지 않는 파일을 위해 이 유지보수 부담을 계속 지는 것은 비효율적이다. 만약 유지보수 리소스가 부족하다면, 검색엔진에 굳이 노출시키고 싶지 않은 페이지에 흔히 쓰는 방식처럼 noindex 처리를 고려할 수 있다는 것이 구글 쪽에서 나온 언급이기도 하다.

정리하면 이렇다. 새로 만들 필요는 없고, 이미 있다면 급히 지울 필요도 없다. 다만 유지보수 시간을 아깝게 쓰고 있다면 그 시간을 구조화 데이터나 콘텐츠 품질 쪽으로 옮기는 편이 낫다.

자주 묻는 질문

llms.txt를 만들면 AI 검색 노출에 조금이라도 도움이 되나?

현재로서는 확인된 효과가 없다. 구글은 2026년 세 차례에 걸쳐 이 파일을 검색 랭킹에 쓰지 않는다고 공개적으로 밝혔고, 13만 개 넘는 도메인 실측 조사에서도 AI 검색봇의 요청 비중은 1.1%에 그쳤다. 노출을 목적으로 이 파일을 만드는 것은 권장되지 않는다.

그렇다면 llms.txt는 완전한 사기였나?

그렇게 보기는 어렵다. 2024년 제안 당시에는 AI가 사이트 맥락을 이해하는 방법이 지금보다 훨씬 불투명했고, 이를 풀어 보려는 선의의 시도였다. 다만 이후 검색엔진들이 이미 갖고 있던 크롤링·색인 인프라로 같은 문제를 더 잘 풀어내면서, 결과적으로 이 제안의 실효성이 낮아진 것에 가깝다.

오픈AI나 퍼플렉시티 같은 다른 AI 서비스는 llms.txt를 쓰나?

공식적으로 사용을 확인한 주요 AI 서비스는 아직 없다. 뮬러가 지적했듯 "이 파일은 수년째 존재했지만 어떤 AI 시스템도 쓰지 않는다"는 관찰이 이를 뒷받침한다. 각 서비스가 향후 입장을 바꿀 가능성 자체를 완전히 배제할 수는 없지만, 현재 시점에 노출 목적으로 우선순위를 둘 근거는 부족하다.

llms.txt와 robots.txt는 같은 성격의 파일인가?

아니다. robots.txt는 검색엔진이 실제로 읽고 지키는 20년 넘은 공식 규약이고, llms.txt는 특정 기관이 아닌 개인이 2024년에 제안한 아이디어다. 이름이 비슷하다는 이유로 같은 무게로 다뤄서는 안 된다.

llms.txt를 만드는 데 비용을 청구받았다면 어떻게 봐야 하나?

효과가 검증되지 않은 항목에 예산을 쓰고 있는 것은 아닌지 점검해 볼 필요가 있다. 구글이 이미 공개적으로 효과를 부인한 파일을 "AI 검색 최적화 필수 작업"이라는 이름으로 판매하는 경우, 그 근거를 구체적으로 물어보는 것이 합리적이다.

개발 문서 사이트라면 예외인가?

부분적으로 그렇다. 코딩 에이전트가 API 문서나 개발자 레퍼런스의 llms.txt를 참조하는 사례가 실측 데이터에서 관찰됐다. 다만 이 경우에도 핵심 우선순위가 아니라 여유가 될 때 하는 부가 작업 정도로 위치를 잡는 것이 맞다.

WebMCP는 지금 당장 준비해야 하나?

대부분의 사업자에게는 아직 이르다. AI 에이전트가 결제·예약처럼 실제 동작을 대신 수행해야 하는 상거래·예약 중심 사이트라면 앞으로의 방향으로 지켜볼 가치는 있지만, 일반적인 소개 페이지·블로그라면 지금 챙길 우선순위는 아니다.

llms.txt가 앞으로 다시 중요해질 가능성은 없나?

완전히 배제할 수는 없지만, 지금 근거로는 낮다. AI 검색 생태계는 빠르게 바뀌고 있어 구글의 입장이 미래에 달라질 여지는 이론적으로 있다. 다만 세 차례에 걸친 공식 발언과 실측 데이터가 모두 같은 방향을 가리키고 있는 지금 시점에서는, 이 파일에 선제적으로 투자할 근거가 부족하다는 것이 합리적인 판단이다.

네이버 검색에도 이 결론이 그대로 적용되나?

네이버는 llms.txt에 대해 공식 입장을 낸 적이 없다. 이 글의 결론은 어디까지나 구글의 공개 발언과 구글 생태계 데이터를 근거로 한다. 다만 네이버 역시 자체 크롤러와 색인 시스템, 그리고 AI 브리핑 같은 자체 생성형 검색 기능을 이미 갖추고 있다는 점을 고려하면, "사람이 미리 요약해 둔 파일보다 검색엔진 자체의 크롤링·색인이 우선한다"는 구조적 원리는 크게 다르지 않을 가능성이 높다. 다만 이는 유추일 뿐 네이버의 공식 확인은 아니라는 점은 분명히 해 둘 필요가 있다.

그렇다면 오늘부터 무엇을 먼저 해야 하나?

구조화 데이터, 사이트맵·robots.txt, 콘텐츠 품질 이 셋부터다. 이 글의 체크리스트에 정리된 순서대로 하나씩 점검하는 것이 가장 확실한 시작점이다.

마무리

llms.txt를 둘러싼 소동은 새로운 기술이 등장할 때마다 반복되는 패턴을 그대로 보여준다. 불확실성이 큰 시기일수록 "일단 만들어 두면 안전하다"는 심리가 퍼지고, 그 틈을 검증되지 않은 상품이 파고든다. 이번에는 구글이 직접, 그것도 세 차례나 나서서 그 틈을 정리해 줬다는 점에서 오히려 실무자 입장에서는 다행스러운 일이다.

결국 남는 질문은 "무엇을 더 할 것인가"가 아니라 "무엇을 그만하고 어디에 시간을 옮길 것인가"다. 구조화 데이터, 사이트맵과 크롤링 접근성, 그리고 실제 경험이 담긴 콘텐츠. 이 세 가지는 구글이 지금까지 한 번도 부인한 적 없는, 오래되고 검증된 우선순위다.

이런 우선순위 판단과 실제 적용은 혼자 하기에 품이 많이 드는 작업일 수 있습니다. 이루웹은 구조화 데이터부터 사이트 전반의 SEO 기본기까지 함께 점검해 드리고 있으니, SEO 최적화 홈페이지 제작이나 전체 서비스를 살펴보시고 편하게 상담을 요청해 주시면 지금 사이트에 정말 필요한 것과 미뤄도 되는 것을 함께 가려 드리겠습니다.