llms.txt를 만들기 전에 알아야 할 것: 기대할 수 있는 일과 없는 일

llms.txt는 표준 보증서가 아니라 공개 제안이다

llms.txt는 사이트 운영자가 LLM에 유용한 문서와 짧은 설명을 루트의 텍스트 파일에 정리하자는 제안입니다. 사람이 README를 보고 프로젝트 구조를 파악하듯, 모델이나 에이전트가 사이트의 핵심 문서를 찾기 쉽게 하자는 취지입니다. llms.txt 제안에는 권장 형식과 예시가 공개돼 있습니다.

문제는 모든 검색·AI 서비스가 이 파일을 읽고 순위나 인용에 사용한다고 보장하지 않는다는 점입니다. 파일을 추가한 직후 ‘AI 가시성이 오른다’고 말할 근거도 부족합니다. 구현 여부, 소비 방식, 갱신 주기는 서비스마다 다를 수 있습니다.

이 파일이 해결하지 못하는 문제부터 확인한다

추가 가치가 있는 사이트는 따로 있다

문서가 수백 개이고 API 버전, SDK, 튜토리얼, 정책 페이지가 나뉜 개발자 제품은 핵심 경로를 압축해서 안내할 가치가 있습니다. 공개 지식베이스가 크고 Markdown 원본을 함께 제공하는 사이트도 후보입니다. 반면 랜딩 페이지와 가격·가이드 몇 개뿐인 사이트는 좋은 내비게이션과 사이트맵이 더 직접적인 개선일 수 있습니다.

의사결정은 ‘경쟁사가 만들었는가’가 아니라 ‘우리 문서 구조에서 어떤 탐색 비용을 줄이는가’로 내려야 합니다. 실제 사용 주체와 로그를 확인할 수 없다면 실험 기능으로 취급하세요.

만든다면 최소한 이렇게 관리한다

모든 블로그 글을 나열하면 또 하나의 거대한 사이트맵이 될 뿐입니다. 제품·가격·방법론·가이드처럼 답변의 근거가 되는 원본을 중심으로 구성하고, 세부 콘텐츠는 해당 허브에서 찾게 하는 편이 낫습니다.

• 루트의 안정적인 URL에서 text/plain 또는 읽기 쉬운 텍스트로 제공한다.
• 서비스 한 줄 설명과 가장 중요한 공식 문서만 고른다.
• 각 링크의 역할을 짧게 설명하고 중복·폐기 URL을 넣지 않는다.
• 로그인 전용 문서나 공개하면 안 되는 경로를 안내하지 않는다.
• 사이트 개편 시 링크 유효성과 설명의 최신성을 자동 검사한다.
• robots.txt, sitemap, canonical과 모순되는 URL이 없는지 확인한다.

배포 전에는 사람과 기계 두 관점에서 검사한다

효과는 요청 로그와 결과 변화로 따로 본다

서버 로그에서 llms.txt 요청이 실제로 들어오는지, 어떤 사용자 에이전트가 언제 가져가는지 확인할 수 있습니다. 요청이 있다는 사실은 소비되거나 인용에 영향을 줬다는 증거가 아닙니다. 접근, 사용, 결과를 서로 다른 단계로 기록하세요.

같은 질문군에서 인용 URL과 설명 정확도를 배포 전후로 비교할 수는 있지만, 파일 하나 때문에 변했다고 확정하기는 어렵습니다. 모델 변경, 검색 색인, 사이트 콘텐츠 수정이 함께 작용합니다. 실험하려면 다른 대규모 변경과 시기를 분리하세요.

우선순위는 늘 실제 페이지에 있다

llms.txt를 만드는 데 한 시간이 든다면 그 전에 핵심 페이지 다섯 곳을 열어 보세요. 제목과 첫 문단이 고객 질문에 답하는지, 가격과 기능이 최신인지, 내부 링크로 다음 근거를 찾을 수 있는지 확인합니다. 여기서 문제가 발견되면 그 수정이 먼저입니다.

보조 파일은 잘 정리된 사이트를 더 쉽게 안내할 수는 있어도 부실한 사이트를 신뢰할 만하게 만들지는 못합니다. 추가하더라도 작은 실험으로 운영하고, 지원 현황이 바뀌면 역할을 다시 판단하세요.