llms.txt, 90일 후: 솔직한 회고
우리는 3개월 전 aat.ee 전반에 llms.txt를 배포했습니다. 그것이 무엇인지, 우리가 무엇을 출시했는지, 로그와 리퍼럴이 실제로 무엇을 보여주는지, 그리고 당신이 신경 써야 할지에 대한 솔직한 평가.
6월에 우리는 aat.ee 전반에 llms.txt를 배포했습니다. 라우트 파일 하나, 사이트의 핵심 콘텐츠를 담은 마크다운 맵을 aat.ee/llms.txt에서 제공하는 것이었죠. 한 시간 정도 걸렸습니다. 90일이 지난 지금, 이것이 무엇을 했고 무엇을 하지 않았는지 솔직하게 기록합니다. llms.txt에 대해 여러분이 읽게 될 대부분은 사양을 되풀이하거나 영업 멘트에 불과하고, 그 중간 지대 — 실제 프로덕션 사이트에서 측정한 결과 — 는 거의 없기 때문입니다.
llms.txt란 무엇인가, 한 문단으로
llms.txt는 제안된 관례입니다(표준이 아닙니다 — 이 점은 나중에 더 다룹니다). 도메인 루트에 위치한 마크다운 파일로, 언어 모델에게 사이트의 정리된 지도를 제공합니다. sitemap.xml이 크롤러를 위한 전체 URL 목록이라면, llms.txt는 어시스턴트를 위한 짧고 우선순위가 매겨진 읽기 목록 입니다 — 무엇이 중요한지, 무엇이라 불리는지, 어디에 있는지를 담습니다. 에이전트가 무작정 크롤링하기보다 정리된 요약을 선호할 것이라는 베팅이죠.
우리가 배포한 것
구현은 의도적으로 따분합니다. 하나의 동적 라우트가 세 가지를 조합합니다 — 정적인 크롤링 정책 서문, 최근 런칭 15개, 최근 발행 글 10개, 그리고 카테고리 목록 — 을 마크다운으로 만들고, 사용자가 제어하는 모든 것을 감싸는 이스케이프 함수 하나를 둡니다.
// User text (project names, article titles) must not break out of the
// markdown link or inject headings into an agent-facing file.
function mdSafe(text: string): string {
return text
.replace(/[\r\n]+/g, " ")
.replace(/[[\]()]/g, "")
.trim()
}
const projectLinks = recentProjects
.map((p) => `- [${mdSafe(p.name)}](${baseUrl}/projects/${p.slug})`)
.join("\n")// User text (project names, article titles) must not break out of the
// markdown link or inject headings into an agent-facing file.
function mdSafe(text: string): string {
return text
.replace(/[\r\n]+/g, " ")
.replace(/[[\]()]/g, "")
.trim()
}
const projectLinks = recentProjects
.map((p) => `- [${mdSafe(p.name)}](${baseUrl}/projects/${p.slug})`)
.join("\n")이 정제 단계가 유일하게 미묘한 부분입니다. 프로젝트 이름과 제목은 사용자와 LLM 파이프라인에서 나옵니다. 삽입된 개행이나 대괄호가 있으면, 어시스턴트가 지도로서 신뢰하도록 초대된 파일에 목록 하나가 제목이나 가짜 링크를 주입할 수 있습니다.
로그가 보여준 것
90일간의 서버 로그와 리퍼러 데이터에서 나온 세 가지 관찰입니다.
에이전트는 실제로 가져갑니다. 알려진 어시스턴트 크롤러 사용자 에이전트로부터 /llms.txt에 대한 주기적 요청이 보입니다. robots.txt보다 훨씬 낮은 빈도지만 꾸준히 존재합니다. 사양의 지위가 어떻든, 가져가는 행위 자체는 실재합니다.
측정 가능한 리퍼럴 기적은 없습니다. aat.ee로의 AI 어시스턴트 리퍼럴은 분기 동안 증가했습니다 — 하지만 그 성장은 llms.txt 배포가 아니라 우리의 발행 주기를 따라갑니다. 에이전트가 그 파일을 읽어서 발생한 세션을 단 하나도 귀속시킬 수 없으며, 여기서 긴밀한 귀속을 주장하는 사람은 의심스럽습니다. 어시스턴트는 가져온 뒤 여러 출처를 섞어 답하고, 인용에는 llms.txt 형태의 리퍼러가 거의 실리지 않습니다.
유용한 인벤토리를 강제했습니다. 예상치 못한 이점은 이것입니다. 정리된 지도를 작성한다는 것은 사이트의 최상단 이 실제로 무엇인지 결정하는 일입니다. 우리 라우트는 실시간 데이터를 렌더링하므로 파일은 최신 상태로 유지됩니다 — 하지만 "무엇이 읽기 목록에 속하는가"라는 규율은 파일 자체보다 카테고리 구조를 더 개선했습니다.
불편한 부분: 여전히 제안에 불과합니다
llms.txt에는 비준된 표준이 없습니다. MIME 타입도 논쟁 중이고(text/markdown 대 text/plain), 어시스턴트가 이를 읽는다고 문서화된 바도 없으며, 없어도 아무것도 깨지지 않습니다. 2026년에 이것이 "AI SEO에 필수"라고 말하는 글은 증거보다 앞서 나간 것입니다.
90일 후 우리의 입장: 비용이 너무 낮아 기대값은 여전히 양수입니다. 잘 정돈된 로비가 사무실 건물에 이로운 것과 같은 이치입니다. 그것만으로 결과를 만들어내지는 않겠지만, 에이전트가 방향을 찾아 나설 때 벽보다는 정리된 지도를 발견하는 편이 낫습니다.
만들어야 할까요?
솔직한 결정 표입니다:
- 사이트가 약 50페이지 미만이고 제목이 명확하다면 — 미미합니다. 사이트맵과 내비게이션이 이미 이야기를 다 해줍니다.
- 데이터 기반 사이트라면 (런칭, 목록, 글, 문서 — 매주 바뀌는 콘텐츠) — 그렇습니다. 생성된 llms.txt는 라우트 파일 하나이고, 자동으로 최신 상태를 유지하며, 사이트맵이 줄 수 없는 스팸 없는 요약을 어시스턴트에게 제공합니다.
- AI 순위를 올려준다는 말을 들었다면 — 아닙니다. 그것은 지도이지 메타 태그가 아닙니다.
위의 구현 패턴 — 조합하고, 정제하고, 제공하라 — 은 라우팅 계층이 있는 어떤 프레임워크에도 맞습니다. 손으로 쓰지 말고 생성된 상태로 유지하고, 사용자 텍스트는 정제된 상태로 유지하고, 기대치는 조정된 상태로 유지하세요.