llms.txt v2 공개: 무엇이 바뀌었고 무엇을 업데이트해야 하나
2026년 8월 10일, Jeremy Howard가 llms.txt 제안의 v2를 공개했습니다. 2024년 9월 이 형식이 나온 이후 첫 개정입니다. 2년간의 도입 과정에서 빠져 있던 것, 모호했던 것, 그리고 명세가 가정한 방식대로 쓰이지 않던 것이 분명하게 드러났습니다.
먼저 안심할 만한 이야기부터. 기존 llms.txt 파일은 그대로 유효합니다. 파일 형식 자체는 바뀌지 않았습니다. 바뀐 것은 파일을 둘러싼 모든 것, 특히 수천 명의 도입자가 계속 물어온 질문에 대한 답입니다.
v2가 해결하는 문제
v1은 링크로 채운 llms.txt를 공개하고, 페이지의 깔끔한 Markdown 버전을 page.html.md로 제공하라고 했습니다. 하지만 이 두 축을 연결해 주지는 않았습니다.
Howard의 표현을 빌리면, 이 파일은 “에이전트를 페이지로 안내했지만, 명세 어디에도 Markdown 버전이 실제로 어디 있는지 알려주는 부분이 없었다”는 것입니다.
그래서 https://example.com/docs/auth에 도착한 에이전트는 두 가지 기본적인 질문에 확실히 답할 수 없었습니다.
- 이 페이지의 Markdown 버전이 있는가, 있다면 어디에?
- 이 페이지를 커버하는
llms.txt가 있는가, 있다면 어디에?
남은 방법은 추측뿐이었습니다. .md를 붙여보고, 루트의 /llms.txt를 시도해보고, 잘 되기를 바라는 것. v2는 이 추측을 명시적 선언으로 대체합니다.
변경 1: 링크 관계(link relation)로 Markdown을 발견 가능하게
가장 핵심적인 변경입니다. v2는 두 가지 표준 HTML 링크 관계를 권장합니다.
rel="alternate" type="text/markdown"은 페이지에서 해당 Markdown 버전을 가리킵니다rel="describedby"는 페이지에서 그 페이지를 커버하는llms.txt를 가리킵니다
<head> 안의 <link> 요소로 제공할 수 있습니다.
<link rel="alternate" type="text/markdown" href="/docs/page.html.md" />
<link rel="describedby" href="/docs/llms.txt" />또는 대부분의 팀에게 더 나은 방법으로, HTTP 응답 헤더 Link: 로 제공할 수도 있습니다.
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"헤더 방식이 중요한 이유는 템플릿을 단 하나도 건드리지 않고 웹 서버나 CDN 설정만으로 추가할 수 있기 때문입니다. HTML이 아닌 리소스, 즉 Markdown 파일 자체에도 적용됩니다. Cloudflare, Netlify, Vercel, nginx를 쓰고 있다면 이건 마이그레이션이 아니라 설정 변경입니다.
참고로 새로 만들어낸 관례가 아닙니다. alternate와 describedby는 이미 IANA에 등록된 링크 관계입니다. v2는 새 배관을 발명하는 대신 웹의 기존 배관을 재사용하기로 한 것입니다.
변경 2: 두 가지 Markdown URL 패턴을 모두 인정
v1은 하나의 관례만 규정했습니다. 전체 URL에 .md를 덧붙이는 방식으로, /docs/tutorial.html은 /docs/tutorial.html.md가 됩니다.
그런데 실제로는 많은 퍼블리싱 도구가 또 다른 자연스러운 방법, 즉 확장자를 교체하는 방식(/docs/tutorial.md)을 택했습니다. v2는 둘 다 허용합니다.
| 패턴 | 원본 | Markdown 버전 |
|---|---|---|
.md 덧붙이기 | /docs/tutorial.html | /docs/tutorial.html.md |
| 확장자 교체 | /docs/tutorial.html | /docs/tutorial.md |
| 확장자 없는 URL | /docs/tutorial/ | /docs/tutorial/index.html.md 또는 /docs/tutorial/index.md |
명세 자체의 표현은 이렇습니다. 실무가 “축복할 만한 방식으로 v1에서 갈라졌다”. 표준을 운영하는 건강한 태도입니다. 어느 패턴도 우선되지 않으니, 여러분의 스택이 자연스럽게 만들어내는 쪽을 쓰고 rel="alternate"로 선언하세요.
변경 3: 하위 경로 적용 범위가 명확히 정의됨
llms.txt 파일은 자신의 경로 아래 URL을 커버하며, 여러 파일이 해당될 때 에이전트는 가장 구체적인 것을 사용해야 합니다. 즉 /docs/llms.txt는 /docs/ 아래 전부를 커버하고, 해당 페이지들에 대해서는 루트의 /llms.txt보다 우선합니다.
이는 단순한 설명 보완 이상입니다. llms.txt가 /.well-known/(RFC 8615)이 아니라 경로에 위치하는 이유가 바로 여기 있습니다. well-known URI는 오리진 루트에만 존재할 수 있는데, 하위 디렉터리만 통제할 수 있는 작성자가 아주 많습니다. GitHub Pages 프로젝트 사이트, 공유 호스트의 문서 폴더, 기업 도메인 안의 팀 섹션 같은 경우죠. v2에서는 어떤 경로에 파일을 올릴 수 있는 사람이라면 그 경로의 llms.txt도 올릴 수 있습니다.
한 도메인에서 문서, 블로그, 마케팅 사이트를 함께 운영한다면, 이제 각각에 범위를 좁힌 파일을 두고 어느 것이 우선하는지도 확실히 알 수 있습니다.
변경 4: llms_txt2ctx 제거, “Optional”의 기계적 의미도 제거
v1에는 llms_txt2ctx라는 CLI 도구가 함께 있었고, llms.txt를 하나의 큰 컨텍스트 덩어리로 확장했습니다. 이때 ## Optional 섹션에는 기계적 의미(컨텍스트가 빠듯하면 건너뛰라)가 부여돼 있었습니다.
v2는 둘 다 명세에서 삭제했습니다. 컨텍스트 확장이 나빠서가 아니라, 에이전트가 실제로 그렇게 동작하지 않기 때문입니다. 실제 에이전트는 llms.txt를 보거나 검색한 뒤 필요한 링크만 따라갑니다. 파일은 컨텍스트에 들어갈 만큼 작게 유지되고, 세부 내용은 링크 뒤에 있다가 필요할 때 가져와집니다.
## Optional은 여전히 존재하지만 이제 순수한 관례입니다. 짧은 컨텍스트가 필요할 때 에이전트가 건너뛸 수 있는 부차적 링크일 뿐, 도구상의 의미는 없습니다.
변경 5: 서술이 현실을 따라잡음
2024년의 배경 섹션은 예측이었습니다. 에이전트가 웹사이트를 일상적으로 읽게 되리라는 예측이죠. v2는 이를 사실 서술로 다시 썼습니다. 이제 그건 그냥 평범한 일상이니까요.
명세는 근거도 제시합니다. 수천 개 사이트가 이 파일을 공개하고, 문서 플랫폼이 자동으로 생성하며, Chrome의 Lighthouse가 에이전트 브라우징 점검 항목으로 감사하고, AI 연구소들도 직접 공개합니다. OpenAI, Anthropic, Google Gemini 팀 모두 개발자 문서에 llms.txt를 제공합니다.
형식이 여전히 요구하는 것 (변경 없음)
이 부분이 사람들이 가장 자주 틀리는 곳이고 v2에서 하나도 바뀌지 않았으니 다시 짚어둡니다.
- 선택적인 바이트 순서 표식(BOM)
- 프로젝트나 사이트 이름을 담은 H1. 유일한 필수 요소입니다
- 나머지 내용을 이해하는 데 필요한 핵심 정보를 담은 짧은 요약 blockquote
- 더 자세한 정보를 담은 0개 이상의 Markdown 섹션(문단, 목록 등 제목을 제외한 무엇이든)
- 파일 목록을 담은 0개 이상의 H2 구분 섹션
각 파일 목록은 Markdown 목록이며, 각 항목에는 필수 링크가 있고 선택적으로 : 뒤에 설명을 붙입니다.
# 제목
> 선택적 설명은 여기에
선택적 상세 내용은 여기에
## 섹션 이름
- [링크 제목](https://link_url): 선택적 링크 설명
## Optional
- [링크 제목](https://link_url)v2 체크리스트
- 기존 파일을 그대로 두세요. 여전히 명세를 충족합니다. 다시 쓸 필요 없습니다.
- 중요한 페이지의 Markdown 버전을 제공하세요. 두 URL 패턴 중 아무거나 괜찮습니다.
- 두 개의 링크 관계를 추가하세요. 가능하면 CDN이나 서버 레벨의 HTTP
Link:헤더로 하면 템플릿 수정이 전혀 필요 없습니다. - 한 도메인에 여러 독립 영역이 있다면 경로별로 파일 범위를 나누세요.
- 링크는 HTML이 아니라 Markdown을 가리키게 하세요.
llms.txt안의 링크는 LLM 친화적인 콘텐츠로 이어져야 합니다. v1에서도 그랬고, 가장 흔한 실수입니다. - 배포 전에 검증하세요. 실제로 파싱되는 파일을 내보내기 위해서입니다.
v2가 바꾸지 않은 것 하나
llms.txt는 여전히 제안이지 비준된 웹 표준이 아니며, 여전히 Google 랭킹 요소가 아닙니다. Google은 이 파일을 사용하지 않는다고 분명히 밝혔습니다. v2는 실제로 이 파일을 읽는 에이전트들에게 형식을 더 유용하게 만들 뿐이고, 그 집단은 실재하며 커지고 있지만, 파일이 SEO 지렛대가 되는 것은 아닙니다.
누군가 v2를 랭킹 개선 수단으로 판다면 먼저 llms.txt는 Google 랭킹 요소인가?를 읽어보세요.
정리
v2는 v1의 유일한 구조적 공백을 메우는 작고 합리적인 개정입니다. 에이전트는 여러분의 파일을 읽을 수는 있었지만 찾을 수 없었고, 그 파일이 가리키는 Markdown도 찾을 수 없었습니다. 두 개의 링크 관계가 그 공백을 메우며, 그중 하나는 CDN 설정 한 줄이면 끝납니다.
업데이트할 준비가 되셨나요? llms.txt 생성기로 명세에 맞는 파일을 만들고, llms.txt 검증기로 형식을 확인하세요. 이 파일이 여러분 사이트에 필요한지 아직 고민 중이라면 llms.txt가 필요한 경우부터 읽어보세요.