llms.txt를 알아보자

/llms.txt

1. llms.txt가 뭔데?

웹사이트 루트(/llms.txt)에 두는, LLM을 위한 사이트 안내 및 사용설명서.
사람이 아니라 LLM이 추론 시점에 읽도록, 사이트의 핵심 정보와 상세 문서 링크를 정해진 마크다운 포맷으로 모아둔다. robots.txt·sitemap.xml처럼 약속된 경로에 두는 표준 제안.

비유하자면 AI에게 건네는 명함이다. 같은 "약속된 경로" 파일이라도 역할이 다르다 — robots.txt = 접근 제어, sitemap.xml = URL 전수 나열, llms.txt = 친절한 설명(큐레이션). (Mintlify가 지원하면서 빠르게 퍼졌고 Anthropic·Cursor 같은 곳도 도입 중.)

말 그대로 제안, 제레미 하워드라는 사람이 제안을 했고 퍼져 실제 표준처럼 되어버렸다.

---

2. 왜 만들어야 하나?

• 컨텍스트 한계: LLM은 컨텍스트 윈도우가 작아 웹사이트를 통째로 못 읽는다.
• HTML은 지저분함: 내비게이션·광고·JS가 섞인 HTML을 LLM용 평문으로 바꾸는 건 어렵고 부정확하다.
• 해결: 핵심 정보와 문서 링크를 한 곳에, 깔끔한 마크다운으로 미리 정리해두면 LLM이 정확·빠르게 활용한다. (특히 개발 문서·API 참조에 유용)
• robots.txt/sitemap.xml과 목적이 다름 — 검색 인덱싱이 아니라 LLM 추론 지원.

---

3. 어떻게 만드나?

1. 사이트 루트에 /llms.txt 파일 생성 (마크다운).
2. 아래 포맷(4번)대로 이름·요약·문서 링크를 작성.
3. (권장) LLM이 읽을 페이지는 같은 URL + .md 버전도 함께 제공. (파일명 없는 URL은 index.html.md)
4. llms_txt2ctx 같은 도구로 컨텍스트 파일로 펼쳐, 여러 LLM이 내 콘텐츠 질문에 답하는지 테스트.

작성 팁: 간결·명확하게 / 링크마다 짧은 설명 / 모호한 전문용어 지양.

---

4. txt 내부 포맷 — 순서와 각 섹션의 역할

정해진 순서대로 작성한다. 필수는 H1 하나뿐, 나머지는 선택:

순서	요소	필수?	역할(무엇을 쓰나)
1	# 제목 (H1)	✅ 필수	프로젝트/사이트 이름
2	> 요약 (blockquote)	선택	나머지를 이해하는 데 필요한 핵심 요약
3	일반 마크다운 (문단·목록)	선택	상세 설명·파일 해석 방법. 단 헤딩(##)은 여기 못 씀
4	## 섹션 + 링크 목록	선택(여러 개 가능)	상세 문서 URL 목록. 각 항목은 - [이름](url): 설명
5	## Optional	선택	특별 취급 — 컨텍스트가 부족하면 건너뛰어도 되는 2차 정보

• 링크 목록의 각 줄: [name](url)은 필수, 뒤에 : + 설명(notes)은 선택.
• ## Optional 섹션 이름은 예약된 의미가 있음 → 짧은 컨텍스트가 필요할 때 생략 가능한 자료를 여기 둔다.

형식 뼈대:

# 제목

> 선택: 프로젝트 한 줄 요약

선택: 상세 설명 문단 (헤딩 없이)

## 섹션 이름

- [링크 제목](https://url): 선택 설명

## Optional

- [링크 제목](https://url)

예시 (가상의 날씨 API 서비스 "SkyCast"):

# SkyCast

> 전 세계 실시간 날씨와 예보 데이터를 REST/Webhook으로 제공하는 API 서비스.

참고:
- 모든 응답은 JSON이며 시간은 UTC 기준입니다.
- 무료 플랜은 분당 60회로 호출이 제한됩니다.

## 시작하기
- [API 키 발급](/docs/get-key): 가입 후 5분 안에 첫 요청 보내기
- [인증](/docs/auth): Bearer 토큰 사용법

## API 레퍼런스
- [현재 날씨](/docs/api/current): 좌표·도시명으로 실시간 날씨 조회
- [주간 예보](/docs/api/forecast): 최대 14일 예보
- [기상 특보 Webhook](/docs/api/webhook): 특보 발생 시 콜백 수신

## 예제
- [cURL 빠른 예제](/examples/curl): 복붙용 첫 요청
- [Node.js SDK](/examples/node): @skycast/sdk 연동 예제

## Optional
- [요금제·쿼터](/pricing): 플랜별 호출 한도
- [서비스 상태](/status): 장애·점검 이력

---

5. llms.txt vs llms-full.txt

같은 계열이지만 담는 범위가 다르다.

	llms.txt	llms-full.txt
역할	사이트의 '목차'	사이트의 '본문 전체'
내용	핵심 섹션 + 주요 페이지 링크만	모든 문서·콘텐츠를 하나의 마크다운으로 통째 컴파일
접근 방식	링크를 따라가 개별 문서 참조	단일 URL로 전체 내용을 한 번에
표준 여부	공식 제안	비공식 확장 (공식 표준 아님)
장점	가볍고 선별적, 컨텍스트 절약	링크 안 타도 전부 들어옴
단점	LLM이 링크를 추가로 읽어야 함	파일이 크고 무거움 — 컨텍스트를 많이 먹음

• llms.txt = 목차(index), llms-full.txt = 본문 전체(compiled).
• full은 "링크만 주면 LLM이 안 따라갈 수도 있으니, 내용 자체를 한 파일에 다 넣어주자"는 발상.
• 다만 full은 커질수록 컨텍스트를 많이 잡아먹으니, 용량과 용도의 균형을 봐야 한다. (문서량이 방대하면 full은 오히려 부담)

---

6. Google AI 검색에도 효과가 있을까?

Google 검색(생성형 AI 기능 포함)을 위해 llms.txt를 만드는 건 의미가 없다.

• Google 검색은 llms.txt를 사용 안 함. HTML 등 일반 파일을 그대로 크롤링·색인한다. (다른 서비스용으론 만들 수 있으나 Google엔 영향 없음)
• 즉 "Google AI 검색 노출을 노리고 llms.txt를 넣는다"는 건 효과 전혀 없다. Google 최적화는 결국 정통 SEO + 좋은 콘텐츠다.
• llms.txt는 이를 지원하는 특정 LLM/도구·서비스가 소비할 때만 의미가 있다.
• 출처: Google 검색 생성형 AI 최적화 가이드 — "효과 없는 AEO/GEO 해킹"으로 llms.txt를 명시.

---

근데 진짜 이거 넣으면 좋은 거 맞아?

크롬 개발자 센터에서 Lighthouse 설명쪽에 llms.txt 내용이 추가되었을 정도로, 점점 많은 사이트들이 llms.txt를 추가하고 있는 추세이다. 다만, 6번처럼 구글 AI 검색 노출에 최적화하기 위해서라는 의도로는 전혀 맞지 않는다. 구글은 llms.txt를 읽지도 않으니, 그 목적으로 넣는 건 유행만 허겁지겁 쫓아가는 바보인 셈.

결국 중요한 건 용도에 맞게 잘 쓰는 것이다. llms.txt는 "이걸 실제로 읽고 활용하는 LLM·도구·서비스"가 있을 때에만 의미가 생긴다. 그러니 남들 한다고 그냥 박아두기 전에, 우리 사이트를 어떤 AI가 참조하길 원하는지 — 그 소비 주체부터 정하고 거기에 맞춰 선별해서 넣어야 한다. "무엇을 넣느냐"보다 "왜, 누구를 위해 넣느냐"가 먼저인 듯하다.

근데 실제로 읽히긴 하나?

찾아보니 "진짜로 대형 LLM들이 이걸 읽는다" 라는 공식적인 입장은 아직 없는 듯하다. 조사하면 할수록 원효대사 해골물인가 싶기도 했다.

안 읽던데?

• LLM들이 서버의 llms.txt나 AGENTS.md를 실제로는 안 읽는다는 주장. 여러 플랫폼에서 로그를 분석해봤는데 OVH·Google Cloud의 크롤러만 접근하고, ChatGPT·Claude는 요청 자체를 안 하더라는 것.
• Bun(Anthropic이 인수한 런타임)도 llms.txt를 제공하던데, 정작 Claude가 그걸 실제로 쓰는지는 공식 Docs 사이트에도 없고 사람들의 추측일 뿐.

읽게하면 되지?

• llms.txt는 애초에 대형 LLM용이 아니라 개인별 에이전트용이라는 반론. 대형 검색/크롤러가 안 읽는 게 당연하다는 것.
• 실제로 "내 에이전트들이 항상 이 파일을 읽도록 설정했더니, 그 뒤로 훨씬 빠르고 토큰 효율적으로 작동한다. 매일 직접 쓰고 있어서 확실히 읽힌다고 말할 수 있다"는 경험담만 존재한다.

→ 정리하면 앞의 결론과 같은 얘기다. "웹에 던져두면 대형 LLM이 알아서 읽어주겠지"는 의미가없고, 내가 사용하는 에이전트/도구가 명시적으로 읽게 작성했을때 효과가 난다는 쪽이 지금까지 나온 의견 중에서는 제일 맞는 것 같다.