llms.txt 완전 가이드 — 작성·운영과 실효성

llms.txt는 사이트 루트에 두는 Markdown 파일로, 대규모 언어 모델(LLM)이 그 사이트의 핵심 페이지를 빠르게 찾도록 정돈된 링크 목록을 제공하자는 제안이다. 2024년 llmstxt.org ↗에서 제안됐다.^[1] 이름은 robots.txt와 sitemap.xml을 연상시키지만, 목적과 동작은 둘 모두와 다르다. 이 글은 llms.txt가 풀려는 문제, 작성법, robots.txt와의 관계, 그리고 실효성을 둘러싼 논쟁을 함께 정리한다.

왜 llms.txt가 제안됐나 — 문제와 해결

LLM이 웹페이지를 읽을 때 부딪히는 문제는 두 가지다. 첫째, 일반 HTML 페이지에는 내비게이션 바, 광고, 쿠키 배너, 자바스크립트가 본문과 뒤섞여 있다. 둘째, LLM의 컨텍스트 창은 유한해서, 잡음이 많을수록 정작 중요한 본문에 쓸 공간이 줄어든다. 원인은 "사람용으로 만든 페이지를 기계가 그대로 읽는" 구조적 불일치이고, 그 영향은 LLM이 핵심을 놓치거나 엉뚱한 부분을 인용하는 결과로 나타난다.

llms.txt의 해결책은 단순하다. 잡음을 걷어낸 Markdown으로 "이 사이트에서 중요한 페이지는 여기다"라는 목록을 한곳에 모아 두는 것이다. 가능하면 각 링크 대상도 깨끗한 Markdown(.md) 형태로 함께 제공하기를 권한다. 사람이 보는 화려한 페이지와, 기계가 읽기 좋은 정돈된 텍스트를 분리하자는 발상이다. 이 접근의 배경은 GEO/AEO 기술 축 방법론에서 다루는 "AI가 읽을 수 있게 만드는" 단계와 직접 맞닿는다.

작성법과 예시

llmstxt.org가 제시하는 형식은 Markdown 헤딩 규칙을 그대로 따른다.^[1] 맨 위에 H1으로 사이트나 프로젝트 이름을 쓰고, 인용구(>)로 한 줄 요약을 단다. 이어 H2 섹션마다 관련 링크를 목록으로 묶는다. 링크 형식은 [제목](URL): 짧은 설명 이다. 마지막에 ## Optional 섹션을 두면, 컨텍스트가 빠듯할 때 생략해도 되는 보조 링크를 표시할 수 있다.

# 회사 도움말 센터

> 제품 사용법과 API 문서를 정리한 안내 모음입니다.

## 문서
- [시작하기](https://example.com/start.md): 설치와 첫 설정
- [API 레퍼런스](https://example.com/api.md): 엔드포인트 전체 목록

## Optional
- [변경 이력](https://example.com/changelog.md): 버전별 변경 사항

본문 전체를 링크 너머가 아니라 한 파일에 직접 담은 변형이 llms-full.txt다. LLM이 링크를 따라가는 추가 요청 없이 본문을 곧바로 읽도록 하려는 의도다. 문서 수가 많으면 파일이 커져 컨텍스트를 오히려 잡아먹을 수 있어, 보통 llms.txt(목차형)와 llms-full.txt(본문형)를 함께 둔다.

두 파일 모두 사이트 루트(https도메인/llms.txt)에 둔다. 하위 경로가 아니라 루트에 있어야 도구가 관례적으로 찾는다.

robots.txt·sitemap과의 관계

이름이 비슷해 혼동하기 쉽지만 역할이 다르다. robots.txt ↗는 크롤러의 접근을 허용하거나 차단하는 규칙 파일이다.^[2] AI 크롤러를 막고 싶다면 robots.txt에서 GPTBot ↗이나 Google-Extended ↗ 같은 사용자 에이전트를 지정해 차단한다.^[3][4] sitemap.xml은 색인 대상 URL을 빠짐없이 나열하는 기계용 목록이다.

llms.txt는 이 둘 어느 쪽도 대체하지 않는다. 접근을 통제하지도, 모든 URL을 나열하지도 않는다. 대신 "수많은 페이지 중 LLM이 우선 읽어야 할 것은 이것"이라고 큐레이션한다. 따라서 세 파일은 경쟁이 아니라 분업이다. robots.txt로 접근 정책을 정하고, sitemap으로 색인 범위를 알리고, llms.txt로 핵심을 안내한다. AI 크롤러 차단·허용을 더 깊게 다루려면 AI 크롤러 관리를, 기계가 읽는 구조화 데이터는 구조화 데이터·스키마를 참고하면 된다.

실효성 논쟁과 한계

llms.txt를 둘러싼 가장 큰 쟁점은 "정말 읽히는가"다. 2026년 현재까지 주요 AI 엔진이 llms.txt를 공식적으로 읽어 답변에 반영한다고 확정 발표한 사례는 분명하지 않다. llms.txt는 어디까지나 커뮤니티 제안이며 공식 표준이 아니다. 일부 개발자 도구와 문서 사이트가 자발적으로 채택해 왔지만, 채택이 곧 엔진의 소비를 보장하지는 않는다.

그럼에도 만들 가치가 있다고 보는 근거는 비용 대비 위험이 낮다는 점이다. 파일 하나를 추가하는 작업이라 손해가 거의 없고, 사이트의 핵심 구조를 정리하는 부수 효과가 있으며, 향후 엔진이 지원하면 즉시 이득을 본다. 반대로 과신은 금물이다. llms.txt는 인용을 직접 만들어 내는 장치가 아니라, LLM이 본문을 효율적으로 읽도록 돕는 보조 장치다. 인용은 결국 콘텐츠의 구조와 신뢰도, 크롤러 접근성이 함께 작용한 결과다.

실무 체크

• 루트 경로 확인: 도메인/llms.txt로 직접 열리는지 본다. 하위 경로면 도구가 찾지 못한다.
• 링크 대상의 가독성: 가능하면 링크 대상도 Markdown(.md)이나 본문이 또렷한 페이지로 둔다.
• 큐레이션: 모든 페이지를 넣지 말고, LLM이 우선 읽어야 할 핵심만 추린다. 잡음 제거가 목적이다.
• robots.txt 점검: AI 크롤러를 차단해 두고 llms.txt만 두면 무의미하다. 접근 정책과 안내가 어긋나지 않게 맞춘다.
• 갱신: 문서가 바뀌면 llms.txt도 갱신한다. 죽은 링크는 오히려 신뢰를 떨어뜨린다.

정리

llms.txt는 LLM이 사이트의 핵심을 효율적으로 읽도록 돕는 Markdown 안내 파일이다. robots.txt(접근 통제)·sitemap(색인 목록)과 역할이 겹치지 않으며, 본문을 통째로 담는 llms-full.txt 변형도 있다. 아직 공식 표준이나 보편적 엔진 지원이 확정되지 않은 제안 단계라 만능은 아니지만, 추가 비용이 작고 사이트 정리 효과가 있어 시도할 가치는 있다. 핵심은 과신하지 않되, 접근 정책과 콘텐츠 구조를 함께 정돈하는 것이다.