llms.txt vs llms-full.txt: 차이점은 무엇인가? (2026)

이 글은 lab451.org/blog에서 가져온 교차 게시물입니다. 저는 몇 달 동안 llms.txt 표준을 위한 툴링 (tooling) 작업을 해왔으며, 제가 가장 자주 받는 질문은 "실제로 어떤 파일이 필요한가요"입니다. 이에 대한 자세한 답변을 아래에 정리했습니다.

두 파일은 거의 동일하게 들립니다. 사이트의 루트 (root) 디렉토리에 나란히 위치하며, 동일한 광범위한 대상에게 서비스를 제공합니다. 하지만 이들은 근본적으로 다른 역할을 수행합니다. 어떤 파일을 배포할지(또는 둘 다 배포할지)를 아는 것은 AI 모델이 당신의 사이트를 단순히 이해하는 것과, 사이트에 대해 실제로 질문에 답변하는 것 사이의 차이를 만듭니다.

이 페이지의 내용

• 요약 (TL;DR)
• 두 개의 파일, 두 개의 역할
• 나란히 비교하기
• 상세한 형식 차이
• 크기, 예산, 그리고 컨텍스트 윈도우 (context windows)
• 어떤 AI 모델이 어떤 파일을 읽는가
• llms.txt만 배포해야 할 때
• 둘 다 배포해야 할 때
• 추론 (inference) 시점에 어떻게 함께 작동하는가
• 정신을 잃지 않고 llms-full.txt를 생성하는 방법
• 흔한 실수들
• FAQ

요약 (TL;DR)

단 한 단락만 읽어야 한다면: llms.txt는 AI 모델에게 _당신의 사이트가 무엇인지, 그리고 중요한 페이지들이 어디에 있는지_를 알려주는 작은 Markdown 파일입니다. llms-full.txt는 이미 추출되고, 정제되었으며, 하나로 합쳐진 _해당 페이지들의 실제 텍스트_를 포함하는 훨씬 더 큰 Markdown 파일입니다. 첫 번째가 목차라면, 두 번째는 책입니다.

마케팅 사이트와 작은 블로그는 보통 llms.txt만 필요로 합니다. 문서 사이트, API 레퍼런스 (API references), 지식 베이스 (knowledge bases), 그리고 모델이 당신의 콘텐츠에 대해 실제로 질문에 답변할 수 있기를 원하는 모든 기술적인 사이트는 두 파일 모두를 배포해야 합니다.

두 개의 파일, 두 개의 역할

파일이 하나가 아니라 두 개인 이유는 모든 LLM이 직면해야 하는 트레이드오프 (tradeoff) 때문입니다: 컨텍스트 윈도우 (context window) 공간은 비싸지만, 페이지를 가져오는 것은 느리다는 점입니다. 상황에 따라 이 트레이드오프의 서로 다른 측면이 요구됩니다.

사용자가 ChatGPT에게 "Lab451이 무엇을 하나요?"라고 물을 때, 모델은 정확하게 답변하기 위해 가능한 한 가장 적은 양의 컨텍스트 (Context)를 필요로 합니다. 모델에게는 귀하의 전체 가격 페이지나 서비스 약관, 혹은 모든 블로그 게시물이 필요하지 않습니다. 단 한두 문장이면 충분합니다. llms.txt가 바로 그것입니다. 모델이 밀리초 단위로 가져오고, 몇 개의 토큰으로 파싱 (Parse)하여, 빠르고 정확한 한 단락의 답변을 제공하는 데 사용할 수 있는 아주 작은 파일입니다.

사용자가 ChatGPT에게 "500페이지 분량의 문서 사이트를 위해 llms-full.txt를 설정하는 가장 좋은 방법은 무엇인가요?"라고 물을 때, 모델은 훨씬 더 많은 것을 필요로 합니다. 모델은 귀하의 전체 문서를 이해하고, 관련 섹션을 찾고, 세부 사항을 종합해야 합니다. llms.txt에서 링크를 하나씩 따라가는 것은 10번 또는 20번의 별도 호출 (Fetch)을 의미하며, 많은 컨텍스트를 낭비하게 됩니다. llms-full.txt는 이러한 번거로운 과정을 건너뜁니다. 한 번에 다운로드하여 상세하게 답변합니다.

두 파일은 경쟁 관계가 아니라 서로를 보완합니다. 모델은 질문에 따라 적절한 도구를 선택하여 가져올 수 있습니다. 어떤 모델은 두 파일을 순차적으로 확인하며, 어떤 모델은 쿼리 (Query)의 깊이에 따라 하나를 선택합니다. 어떤 방식이든, 두 파일이 모두 준비되어 있다는 것은 트레이드오프 (Tradeoff)의 양 끝단을 모두 커버했음을 의미합니다.

나란히 비교하기

	llms.txt	llms-full.txt
목적	사이트의 지도 (Map)	사이트의 전체 텍스트
...

형식 차이 상세 분석

두 파일 모두 마크다운 (Markdown)이며, 모두 일반 텍스트 (Plain text)이고, 모두 도메인의 루트 (Root)에 위치합니다. 차이점은 구조적인 면에 있습니다.

llms.txt: 규정된 구조

llms.txt는 엄격하고 파싱 가능한 형태를 따릅니다. 정확히 하나의 H1 태그, 선택 사항인 인용구 (Blockquote) 요약, 선택 사항인 자유 형식의 마크다운, 그리고 링크 목록만을 포함하는 H2 섹션들로 구성됩니다. 규격을 준수하는 파서 (Parser)는 이러한 요소들을 결정론적으로 추출할 수 있습니다. 표준적인 형태는 다음과 같습니다:

# Lab451

> Lab451은 llms.txt, llms-full.txt, sitemap.xml, 그리고 robots.txt를 생성합니다
...

거기에 없는 것이 무엇인지 주목하세요: 페이지 콘텐츠가 없습니다. '시작하기 (Getting Started)' 문서의 문단도 없습니다. API 레퍼런스의 코드 샘플도 없습니다. 오직 제목, URL, 그리고 한 줄짜리 설명뿐입니다. 이 파일은 페이지 그 자체가 아니라, 페이지를 가리키는 손가락 역할을 합니다.

llms-full.txt: 규정된 콘텐츠, 유연한 구조

llms-full.txt는 다른 접근 방식을 취합니다. 형식은 훨씬 더 느슨하여 — 정해진 형태가 없지만 — 콘텐츠 (content) 요구 사항은 더 엄격합니다. 다음을 포함해야 합니다:

• 사이트의 모든 중요한 페이지의 전체 텍스트
• 내비게이션 (navigation), 헤더 (headers), 푸터 (footers), 쿠키 배너 (cookie banners), 그리고 크롬 (chrome, 브라우저 UI 요소)을 제거한 상태
• 깔끔한 마크다운 (Markdown)으로 변환 (또는 최소한 구조화된 일반 텍스트)
• 페이지 사이에 명확한 섹션 구분자를 두어 하나의 파일로 결합

실제 사용 사례를 축약한 예시는 다음과 같습니다:

# Lab451 — 전체 문서 (Full Documentation)

---
...

섹션 사이의 --- 수평선은 관례일 뿐 필수 사항은 아닙니다. 중요한 것은 각 페이지가 고유한 청크 (chunk)로 식별될 수 있어야 하며, 헤딩 (headings)이 원본 페이지의 계층 구조를 반영해야 하고, 모델이 H2 및 H3 태그를 스캔하여 어떤 하위 섹션으로든 탐색할 수 있어야 한다는 점입니다.

크기, 비용, 그리고 컨텍스트 윈도우 (context windows)

두 파일 사이의 크기 차이는 엄청나며, 이는 모델이 이를 소비하는 방식에 실질적인 영향을 미칩니다.

중소규모 사이트의 전형적인 llms.txt 파일은 1 KB에서 10 KB 사이입니다. 이는 대략 250~2,500 토큰 (tokens) 정도로, 현대적인 모델의 컨텍스트 윈도우 (context window)에서 아주 작은 부분에 불과합니다. llms.txt를 읽는 것은 사실상 비용이 들지 않으며, 이것이 모델이 귀하의 도메인과 관련된 거의 모든 쿼리에서 기꺼이 이 파일을 가져오는 이유입니다.

llms-full.txt는 차원이 다른 문제입니다. 의미 있는 콘텐츠가 200페이지에 달하는 문서 사이트의 경우 500 KB 파일, 즉 약 125,000 토큰을 생성할 수 있습니다. 이는 현대적인 롱 컨텍스트 (long-context) 모델(GPT-4o, Claude 4, Gemini 2.5 Pro 모두 쉽게 처리 가능)에 여유롭게 들어가지만, 모델이 대화 중 다른 모든 정보와 함께 고려해야 하는 상당한 양의 컨텍스트 (context)입니다.

2026년 중반 기준 실질적인 한계는 다음과 같습니다:

파일 크기	토큰 환산 (Token equivalent)	상태
50 KB 미만	~12,500 토큰	모든 주요 모델이 전체를 읽음
...

솔직한 결론은 다음과 같습니다: 만약 귀하의 llms-full.txt가 1MB를 초과한다면, 실질적인 한계치에 도달하고 있는 것입니다. 그 범위를 넘어서면 모델들은 전체를 통합적으로 읽기보다는 검색 방식의 소비(관련 청크(chunk)를 grep으로 찾는 방식)로 점점 더 회귀하게 됩니다. 이것이 반드시 나쁜 것은 아니며 — 여전히 작동은 합니다 — 하지만 계산 방식이 달라집니다. 규모가 큰 사이트의 경우, 정답은 "더 큰 llms-full.txt"가 아니라 "더 스마트한 청킹 (chunking)과 잘 명명된 섹션"입니다.

💡 경험 법칙 (Rule of thumb): 가능하다면 llms-full.txt를 500 KB 미만으로 유지하는 것을 목표로 하세요. 만약 이를 초과한다면, 실제로 그 안에 무엇이 들어있는지 면밀히 검토하십시오. 오래된 블로그 포스트, 더 이상 사용되지 않는 문서 (deprecated docs), 서비스 약관, 그리고 변경 로그 (changelogs)는 그 자리에 있을 가치가 거의 없습니다. 핵심은 귀하가 지금까지 발행한 모든 단어를 제공하는 것이 아니라, 실제로 질문에 답할 수 있는 콘텐츠를 모델에게 제공하는 것입니다.

어떤 AI 모델이 어떤 파일을 읽는가

2026년 중반 기준으로 상황은 불균형하지만 점차 수렴하고 있습니다. 일부 크롤러 (crawler)는 두 파일을 명시적으로 가져오고, 일부는 llms.txt만 가져오며, 일부는 명시적으로 링크되었을 때만 llms-full.txt를 준수합니다. 실질적인 현황은 다음과 같습니다:

크롤러 (Crawler)	llms.txt	llms-full.txt
ChatGPT (GPTBot, OAI-SearchBot)	예	예 (발견 가능한 경우)
...

"예"는 크롤러가 파일을 안정적으로 가져오며 그것이 사용된다는 합리적인 증거가 있음을 의미합니다. "색인됨 (Indexed)"은 파일이 다른 사이트 콘텐츠와 함께 색인되지만 구체적인 사용 여부는 불분명함을 의미합니다. "부분적 (Partial)"은 가져오기가 수행되지만 모든 쿼리에 대해 일관되지는 않음을 의미합니다.

실용적인 결론: llms.txt를 가져오는 모든 크롤러는 만약 '선택 사항 (Optional)' 섹션에 링크가 나열되어 있다면, 그 링크를 따라 llms-full.txt로 이동할 것입니다. 따라서 모델이 잘 알려진 URL로서 llms-full.txt를 크롤링하지 않더라도, llms.txt에서 이를 언급해 두면 발견될 수 있음을 보장할 수 있습니다.

언제 llms.txt만 배포해야 하는가

llms-full.txt를 완전히 건너뛰어야 할 타당한 이유들이 있습니다. 다음 중 하나라도 해당된다면 llms.txt만 배포하십시오:

• 마케팅 사이트인 경우. 홈페이지, 소개(About), 가격(Pricing), 문의(Contact) 페이지를 AI 모델이 상세하게 읽을 필요는 없습니다. 당신에 대해 AI에게 묻는 사용자들은 한 단락 정도의 요약을 원하며, llms.txt가 이를 완벽하게 제공합니다.
• 소규모 블로그인 경우. 개별 포스트는 원래의 맥락(분석 도구, 광고, 관련 포스트 위젯 등이 있는 곳)에서 읽히는 것이 더 좋습니다. llms.txt를 통해 모델을 포스트로 안내하는 것만으로 충분하며, llms-full.txt에서 텍스트를 다시 제공하는 것은 전략적 이득 없이 콘텐츠를 중복할 뿐입니다.
• 콘텐츠가 빠르게 변하는 경우. 뉴스 사이트, 주식 추적기(stock-tracker), 또는 라이브 이벤트 대시보드는 llms-full.txt를 끊임없이 재생성해야 합니다. 유지 관리 오버헤드가 이점보다 크므로, 크롤러가 llms.txt를 통해 라이브 페이지에 접속하도록 하는 것이 더 낫습니다.
• 콘텐츠가 유료/제한된 경우 (Gated). 대부분의 페이지가 인증이나 결제를 필요로 한다면, 그 전체 텍스트를 공개적으로 서비스되는 llms-full.txt에 담을 수 없습니다. llms.txt에 공개적인 요약본을 나열하는 것이 적절한 정보 공개 수준입니다.
• 콘텐츠가 주로 시각적이거나 상호작용적인 경우. 도구(Tools), 계산기(Calculators), 설정기(Configurators), 데이터 시각화(Data visualizations) 등은 텍스트로 잘 변환되지 않습니다. llms.txt를 통해 모델을 도구 URL로 안내하는 것은 괜찮지만, llms-full.txt에서 UI를 설명하려고 시도하는 것은 보통 아무것도 없는 것보다 못합니다.

두 가지 모두를 배포해야 할 때

두 가지를 모두 배포하는 것이 가장 강력한 근거를 갖는 경우는, 가치가 '구체적인 세부 사항(specifics)' — 정확한 API 파라미터(parameters), 정확한 설치 단계, 정확한 설정 구문(configuration syntax) — 에 있는 텍스트 중심의 콘텐츠를 보유했을 때입니다. 구체적으로, 다음과 같은 경우에 두 가지를 모두 배포하십시오:

• 문서(Documentation)가 있는 경우. 사용자가 AI에게 "당신의 제품으로 X를 어떻게 하나요?"라고 물었을 때, 그 답변이 특정 함수 시그니처(function signatures), 명령 플래그(command flags), 또는 정확한 설정 구문(configuration syntax)을 가리켜야 한다면 llms-full.txt가 필요합니다. 모델은 사용자의 질문에 답변하기 위해 귀하의 문서를 인용할 것입니다. 이때 모델이 신뢰할 수 있는 표준적이고 깨끗한 소스(canonical, clean source)를 인용하기를 원해야 합니다.
• API가 있는 경우. API 레퍼런스(API references)는 llms-full.txt에서 빛을 발합니다. 핵심은 모델이 단 한 번의 호출(fetch)로 엔드포인트 테이블(endpoint table), 파라미터 목록(parameter list), 응답 형식(response format)을 모두 가져와 질문에 정확하게 답변할 수 있다는 점입니다.
• 지식 베이스(Knowledge base) 또는 도움말 센터(Help center)가 있는 경우. 지원 문서(Support articles)는 현재 AI 어시스턴트가 귀하를 대신하여 처리하게 될 "X를 어떻게 하나요?"라는 질문에 대한 답을 제공하는 경우가 많습니다. 이를 llms-full.txt에 포함하면 AI가 귀하의 지원 팀이 제공하는 것과 동일한 답변을 하게 됩니다.
• 변하지 않는 기술 콘텐츠(Evergreen technical content)가 있는 경우. 튜토리얼(Tutorials), 가이드(Guides), 단계별 안내(Walkthroughs)는 동일한 이유로 llms-full.txt에 포함될 때 이점을 얻습니다. 가치는 구체적인 세부 사항에 있으며, 모델이 오래된 의역(stale paraphrase)이 아닌 귀하의 버전을 인용하기를 원하기 때문입니다.
• 특정 주제에 대한 표준 소스(Canonical source)가 되고 싶은 경우. llms-full.txt에 포함되어 있으면 모델이 해당 주제를 요약할 때 귀하의 표현을 인용할 확률이 높아집니다. 만약 귀하가 어떤 주제에 대해 결정적인 가이드(definitive guide)를 작성했다면, 이를 llms-full.txt에 포함하는 것은 "Lab451에 따르면"과 "어디선가 읽은 가이드에 따르면"의 차이를 만듭니다.

추론 시(Inference time) 두 파일이 함께 작동하는 방식

두 파일 모두를 트리거하는 쿼리를 실제 모델이 처리하는 과정을 살펴보는 것은 유익합니다. "Next.js 사이트에 llms.txt를 어떻게 추가하나요?"와 같은 요청이 두 파일을 모두 지원하는 시스템을 통해 어떻게 흐르는지에 대한 간소화된 추적(trace)은 다음과 같습니다:

1. 모델은 특정 기술 질문에 답변해야 합니다. 모델은 잠재적으로 관련이 있는 사이트(Lab451 포함)를 식별합니다.
2. 모델은 먼저 lab451.org/llms.txt를 가져옵니다 — 작고, 빠르며, 비용이 저렴합니다. 이를 통해 모델은 Lab451이 llms.txt 생성기이며, 관련 페이지를 포함하는 "Docs" 섹션이 있다는 것을 학습합니다.
3. 모델은 llms.txt의 Optional (선택 사항) 섹션에 /llms-full.txt가 언급되어 있음을 확인합니다. 모델은 쿼리 복잡도 (query complexity)에 따라 이를 가져오기로 결정합니다.
4. 모델은 lab451.org/llms-full.txt를 다운로드하여 "Adding llms.txt to your site" 섹션을 찾고, Next.js 예제를 찾아 관련 설정을 직접 인용합니다.
5. 사용자는 lab451.org를 가리키는 인용(citation)과 함께 정확한 답변을 얻습니다.

llms-full.txt가 없다면, 3단계는 대신 일련의 가져오기(fetches) 과정을 트리거하게 됩니다 — 먼저 Docs 인덱스, 그다음 "Adding llms.txt" 페이지, 그다음 Next.js 페이지 순으로 진행되며, 각 단계는 자체적인 HTML 파싱 (parsing), 내비게이션 크롬 제거 (navigation chrome stripping), 그리고 컨텍스트 비용 (context cost)이 발생하는 별도의 요청이 됩니다. 모델이 결국 목적지에 도달할 수는 있겠지만, 시간이 더 오래 걸리고, 더 많은 컨텍스트 비용이 들며, 그 과정에서 잘못된 콘텐츠를 가져올 가능성이 더 높습니다.

두 파일 모두 도구입니다. llms.txt는 쿼리의 80%를 처리하는 저렴하고 빠른 도구입니다. llms-full.txt는 구체적인 정보가 중요한 나머지 20%를 처리하는 더 무거운 도구입니다. 두 파일을 모두 제공한다는 것은 모델이 적절한 것을 선택할 수 있음을 의미합니다.

정신을 잃지 않고 llms-full.txt 생성하기

많은 사이트가 llms.txt만 제공하는 이유는 두 가지를 모두 원하지 않아서가 아닙니다. llms-full.txt를 수동으로 유지 관리하는 것이 매우 고통스럽기 때문입니다. 모든 페이지의 콘텐츠를 하나의 파일로 연결(concatenating)하고, 내비게이션과 크롬을 제거하며, 사이트가 발전함에 따라 동기화를 유지하는 작업은 사람이 아닌 스크립트(script)가 해야 할 일입니다.

몇 가지 실질적인 접근 방식은 다음과 같습니다: