llms.txt를 만들어야 한다는 제안을 받았습니다 — 구글은 안 쓴다는데 라이트하우스는 왜 검사하나

이번 주에만 같은 문의를 세 건 받았습니다. "AI 검색에 잡히려면 llms.txt를 넣어야 한다는데 견적을 받아봐도 되겠냐"는 것입니다. 결론부터 말씀드리면 그 파일은 구글 검색 순위에도, AI 개요 노출에도 영향을 주지 않습니다. 다만 "그러니 만들지 마라"로 끝나는 이야기도 아닙니다. 쓸모가 있는 자리가 따로 있고, 그 자리에 해당하지 않는 사이트가 대부분입니다.

구글의 답은 이미 공식 문서에 적혀 있습니다

추측할 필요가 없습니다. 구글 검색 센트럴의 AI 기능 안내 문서에 문장으로 박혀 있습니다. "AI 개요나 AI 모드에 표시되기 위한 추가 요건은 없다", "새로운 기계 판독용 파일이나 AI 텍스트 파일, 마크업을 만들 필요가 없다", "따로 추가해야 하는 특별한 schema.org 구조화 데이터도 없다"는 세 문장입니다. 업계 보도로는 이 문구가 2026년 6월 문서 갱신 때 커뮤니티 질문에 답하려고 추가됐다고 합니다.

이유도 납득이 갑니다. 구글 쪽에서 나온 설명은 이 파일을 예전 keywords 메타태그에 빗댑니다. 사이트 운영자가 자기 사이트를 스스로 소개하는 신호는, 좋은 사이트와 나쁜 사이트를 가르는 데 쓸 수 없다는 것입니다. 검색엔진이 20년 전에 이미 버린 종류의 신호라는 뜻입니다.

대신 같은 문서가 권하는 것은 평범합니다. robots.txt와 서버가 크롤링을 막지 않을 것, 내부링크로 페이지가 발견되게 할 것, 중요한 내용을 이미지가 아닌 텍스트로 둘 것, 구조화 데이터가 화면에 보이는 내용과 일치할 것. 노출을 제한하고 싶다면 nosnippet·max-snippet·noindex 같은 기존 제어를 쓰라고 합니다. 이 제어들을 어디까지 건드릴지는 AI 검색 제외 판단에서 따로 정리했습니다.

그런데 라이트하우스 리포트에는 그 항목이 뜹니다

혼란의 진짜 출처가 여기입니다. 라이트하우스 13.3.0(2026년 5월 배포)에서 '에이전틱 브라우징' 카테고리가 기본 구성에 들어갔습니다. 그 뒤로는 평범하게 리포트를 돌려도 llms.txt 존재 여부, WebMCP 연동, 에이전트 접근성, 레이아웃 이동이 함께 측정됩니다. PageSpeed Insights와 크롬 개발자도구에도 이어서 반영됐습니다.

사장님이 개발사 리포트에서 이 줄을 보고 "우리 사이트에 없는 게 있다"고 놀라는 경우가 실제로 있습니다. 확인하셔야 할 것은 하나입니다. 파일이 없으면 결과가 감점(FAIL)이 아니라 해당 없음(N/A)으로 표시됩니다. 서버가 404를 정상적으로 돌려주면 N/A, 500 같은 서버 오류를 뱉을 때만 FAIL입니다. 즉 이 항목은 "안 만들어서 깎였다"가 아니라 "측정 대상이 아니다"에 가깝습니다.

그 파일을 실제로 읽는 쪽은 따로 있습니다

검색 크롤러와 AI 검색 크롤러는 이 파일을 거의 요청하지 않습니다. 반면 개발 도구 계열 에이전트는 다릅니다. Cursor, GitHub Copilot, Continue, Aider 같은 도구가 문서 사이트를 훑을 때 이 파일을 실제로 가져다 씁니다. 목차 역할을 하기 때문입니다.

채택률 조사도 갈립니다. SE Ranking이 30만 도메인을 본 결과는 약 10% 수준, Rankability가 전 세계 상위 1,000개 사이트를 훑었을 때는 세 곳에 불과했습니다. 표본이 다르니 숫자가 다른 것이고, 어느 쪽이든 "안 하면 뒤처진다"고 말할 근거는 되지 않습니다.

이 차이를 우리 사이트 기준으로 확인하는 방법도 간단합니다. 액세스 로그에서 llms.txt 문자열만 세어보면 됩니다. 한 달 치를 뒤져 요청이 0건이라면, 만들어 두더라도 아무도 열어보지 않는 파일을 하나 더 관리하게 되는 것입니다. 반대로 개발 도구 계열 사용자 에이전트가 반복해서 두드리고 있다면 그때는 판단이 달라집니다. 남의 통계보다 우리 로그가 언제나 먼저입니다.

그래서 만들까 말까 — 세 줄로 끊습니다

첫째, 개발자용 문서·API 레퍼런스를 운영한다면 만드십시오. 코딩 에이전트가 우리 문서를 인용하게 만드는 실익이 있습니다. SaaS나 개발 도구를 파는 회사라면 그 인용이 곧 도입 검토로 이어지기 때문에, 검색 순위와 별개로 값이 나가는 작업입니다. 둘째, 쇼핑몰·병원·지역 서비스·기업 소개 사이트라면 지금은 순위와 무관한 작업입니다. 셋째, 만들기로 했다면 손으로 관리할 수 있는 분량만 넣으십시오. 내용이 낡은 목차는 없는 것만 못합니다.

비용 판단도 여기서 갈립니다. 이 파일 하나로 AI 검색 노출을 보장한다는 제안서는 근거가 공식 문서와 정면으로 어긋납니다. 같은 예산이면 AI 답변에 인용될 확률을 실제로 움직이는 요소, 그러니까 인용되게 만드는 조건과 실제로 표시되는 구조화 데이터부터 손대는 편이 낫습니다.

점검 순서 요약

제안서를 받았을 때 이 순서로 확인하시면 됩니다.

1) 제안서가 근거로 든 문서가 구글 공식 안내인지, 대행사 블로그인지 확인합니다. 2) 라이트하우스를 직접 한 번 돌려 해당 항목이 FAIL인지 N/A인지 눈으로 봅니다. N/A라면 급한 일이 아닙니다. 3) 서버 로그에서 /llms.txt 요청이 실제로 들어오는지 셉니다. 0건이면 수요 자체가 없는 것입니다. 4) 우리 사이트가 개발자 문서를 제공하는지 판단합니다. 아니라면 뒤로 미룹니다. 5) 그 예산으로 색인·내부링크·구조화 데이터 중 무엇이 비어 있는지 먼저 봅니다.

새 파일 하나가 판을 뒤집는 일은 거의 없습니다. 지난 몇 년 동안 이 자리에 왔다 간 이름만 여러 개입니다. 문서에 적힌 것부터 맞추는 쪽이 언제나 빨랐습니다.