3.5.1 LLM-friendly 지식 Wiki 지형도

위키는 더 이상 사람만 읽는 문서가 아니다. 에이전트가 직접 읽고 작업하는 시대에 맞춰 새로운 표준 파일들과 작성 컨벤션이 등장했다. 어떤 방식들이 존재하는지 전체 지도를 그려본다. 업데이트: 2026-05-14


핵심 요약

구분내용
📖 정의LLM과 AI 에이전트가 사람보다 잘 활용할 수 있도록 구조·메타데이터·진입점이 설계된 지식 베이스
🚀 흐름2024-09 llms.txt 제안 → 2025 중반 AGENTS.md 사실상 표준 수렴 → 2026-04 Karpathy LLM Wiki 패턴 확산
💡 핵심”사람용 문서를 LLM에 던지는” 시대는 끝났다. 진입점(llms.txt) + 지침(AGENTS.md) + 구조화된 청크가 기본
🎯 대상개인 wiki·팀 docs·공개 문서 사이트·코드베이스를 LLM/에이전트가 잘 활용하도록 만들고 싶은 사람
⚠️ 주의단일 정답은 없다. 위키의 성격(개인/팀/공개)과 주 사용 에이전트(Claude Code / Cursor / Web LLM)에 따라 조합이 달라진다

문서 탐색


목차

  1. 왜 “LLM-friendly” 위키가 필요한가
  2. 일반 위키와 LLM 위키의 차이
  3. 전체 지형 지도 — 6가지 카테고리
  4. 주요 플레이어 현황
  5. 세 가지 큰 흐름 — 어디로 가고 있는가

1. 왜 “LLM-friendly” 위키가 필요한가

변화한 독자

시기주 독자글쓰기 방식
~2022사람산문, 이미지, 인터랙티브 UI
2023~2024사람 + LLM(가끔)사람용 + 검색엔진 최적화(SEO)
2025~사람 + LLM(상시) + 에이전트LLM 친화 메타데이터 + 진입점 표준화 + 청크 단위 구조

2024년까지는 LLM이 위키 콘텐츠를 학습 단계에서만 활용했다. 2025년부터는 에이전트가 런타임에 위키를 직접 읽어 작업한다. Claude Code, Cursor, Codex, Gemini CLI 같은 코딩 에이전트는 매 세션마다 저장소 루트의 지침 파일을 읽어들이며, 검색 도구(RAG, MCP)로 위키 본문도 호출한다.

사람용 문서를 그대로 던지면 생기는 문제

문제구체적 영향
진입점 부재사이트 전체에서 LLM이 어디부터 읽어야 할지 단서 없음 — 사이드바를 읽지 못함
HTML 노이즈광고·내비게이션·스타일 토큰이 본문 정보를 묻음 (Markdown 대비 토큰 5~10배)
컨텍스트 단절청크 단위로 잘렸을 때 “이 문서가 무엇인지” 알 수 없음 (frontmatter 부재)
링크 그래프 단절일반 HTML 링크는 LLM이 따라가지 않음. wikilink/명시적 참조 필요
의도 미전달이 저장소·이 폴더에서 무엇을 해야 하는지 LLM은 모름 (지침 파일 부재)

2. 일반 위키와 LLM 위키의 차이

graph TD
    subgraph 일반["일반 위키 (사람 중심)"]
        H1["사이드바 + 검색창"]
        H2["풍부한 이미지·UI"]
        H3["HTML 렌더링"]
        H4["디자인 강조"]
    end

    subgraph LLM["LLM-friendly 위키"]
        L1["llms.txt<br/>진입점 명시"]
        L2["AGENTS.md / CLAUDE.md<br/>지침 파일"]
        L3["Markdown 원본<br/>토큰 효율"]
        L4["frontmatter<br/>메타데이터"]
        L5["짧은 단락<br/>+ 명시적 링크"]
        L6["청크 단위 구조<br/>한 섹션 = 한 개념"]
    end
항목일반 위키LLM 위키
주 형식HTML 렌더링Markdown 원본 노출
진입점메인 페이지(시각적)llms.txt / AGENTS.md (텍스트 인덱스)
메타데이터<title>, OG 태그frontmatter(title, description, tags, date)
링크내비게이션 메뉴본문 내 마크다운/wikilink + sitemap
청크 단위페이지 전체섹션(H2) 단위 독립 청크
에이전트 인터페이스없음MCP 서버, 파일시스템 직접 접근

핵심은 LLM이 토큰을 적게 쓰고도 정확한 정보를 찾을 수 있도록 구조화하는 것이다. Fern의 분석에 따르면 Markdown은 같은 정보를 HTML 대비 80~90% 적은 토큰으로 표현한다.


3. 전체 지형 지도 — 6가지 카테고리

graph TD
    Root["LLM-friendly 지식 베이스"]

    Root --> A["A. 진입점 표준 파일"]
    Root --> B["B. 에이전트 지침 파일"]
    Root --> C["C. 작성 컨벤션"]
    Root --> D["D. 검색·인덱싱<br/>(RAG)"]
    Root --> E["E. 에이전트 접근 채널<br/>(MCP)"]
    Root --> F["F. 통합 패턴"]

    A --> A1["llms.txt"]
    A --> A2["llms-full.txt"]
    A --> A3["sitemap.xml<br/>+ robots.txt"]

    B --> B1["AGENTS.md<br/>(범용 표준)"]
    B --> B2["CLAUDE.md<br/>(Claude Code)"]
    B --> B3[".cursor/rules/*.mdc<br/>(Cursor)"]
    B --> B4["GEMINI.md<br/>(Gemini CLI)"]

    C --> C1["frontmatter 메타데이터"]
    C --> C2["heading 계층 일관성"]
    C --> C3["청크 친화 단락"]
    C --> C4["명시적 링크<br/>+ 약어 풀어쓰기"]

    D --> D1["Semantic chunking"]
    D --> D2["MarkdownHeaderTextSplitter"]
    D --> D3["Hybrid search<br/>(BM25 + Vector)"]
    D --> D4["Vector DB<br/>Chroma·LanceDB·Pinecone"]

    E --> E1["filesystem MCP"]
    E --> E2["obsidian-mcp-server"]
    E --> E3["notion-mcp"]
    E --> E4["memory MCP"]

    F --> F1["Karpathy LLM Wiki<br/>(개인용)"]
    F --> F2["Mintlify Docs<br/>(공개 사이트)"]
    F --> F3["GraphRAG / LightRAG<br/>(대규모)"]

A. 진입점 표준 파일

LLM/에이전트가 “이 사이트에서 어디부터 읽어야 하는가”를 알려주는 진입 파일이다.

파일위치역할제안 시점
llms.txt사이트 루트 /llms.txt사이트의 LLM용 목차(마크다운 링크 트리)2024-09, Jeremy Howard
llms-full.txt사이트 루트 /llms-full.txt전체 문서를 단일 파일로 통합2024-09, 같은 제안
sitemap.xml사이트 루트 /sitemap.xml전통적 SEO 사이트맵 (LLM도 활용)

현실: llms.txt는 2025-10 기준 84만+ 사이트가 채택했지만, OpenAI/Anthropic 같은 주요 LLM 크롤러는 아직 적극 활용하지 않는다. 실제 사용처는 Cursor·Continue 같은 IDE 에이전트와 Perplexity 같은 검색형 AI다.

B. 에이전트 지침 파일

저장소·프로젝트 단위에서 에이전트의 행동을 지시하는 파일이다.

파일대상 에이전트핵심
AGENTS.md범용 (OpenAI Codex, Google, Anthropic, Cursor 공동 지지)2025 중반 사실상 표준으로 수렴. 코딩 에이전트의 마스터 지침
CLAUDE.mdClaude Code, Claude DesktopAnthropic 공식. AGENTS.md를 심링크로 두는 패턴 권장
.cursor/rules/*.mdcCursor IDE세분화된 규칙 파일, 글롭 패턴별로 다른 규칙 적용 가능
GEMINI.mdGemini CLIGoogle 에이전트 전용
.windsurfrulesWindsurfCodeium 에이전트 전용

권장 패턴: AGENTS.md를 단일 진실 소스(SSOT)로 두고 CLAUDE.md·GEMINI.md는 심링크로 연결한다.

C. 작성 컨벤션 (LLM-friendly Markdown)

문서 본문 자체를 LLM이 잘 파싱하도록 작성하는 규칙이다.

규칙이유
frontmatter 필수 (title, description, date, tags)청크 단위로 잘렸을 때도 문서 정체성 유지
H1 한 개, H2/H3 계층 일관성MarkdownHeaderTextSplitter 같은 도구가 의미 단위로 청크 분할
한 섹션 = 한 개념독립 청크로 잘려도 자체 완결
짧은 단락 (3~5문장)토큰 효율, 임베딩 정밀도
약어 첫 등장 시 풀어쓰기RAG(Retrieval-Augmented Generation)
코드 블록 언어 명시```python (LLM이 언어 컨텍스트 보존)
명시적 링크”위 문서” 대신 [3.5.2 방식별 비교](3.5.2.llmWikiComparison.md)
표·리스트 적극 활용LLM이 산문보다 정형 구조에서 정보 추출이 정확

D. 검색·인덱싱 (RAG 친화)

기법핵심권장값
Fixed-size chunking토큰 수로 자르는 가장 단순한 방식512 토큰, 10~20% 오버랩
Semantic chunking의미 단위(문단·섹션)로 자르기Markdown은 헤딩 기준 권장
MarkdownHeaderTextSplitterLangChain 도구, H1/H2/H3 기준 분할Markdown 위키의 단일 최대 개선책
Hybrid searchBM25(키워드) + Vector(의미) 결합Reciprocal Rank Fusion으로 결합
메타데이터 필터frontmatter의 tags·date로 필터링위키 규모 커질수록 필수

E. 에이전트 접근 채널 (MCP)

위키를 에이전트가 직접 읽고 쓸 수 있는 채널이다.

MCP 서버대상용도
filesystem-mcp로컬 파일 시스템위키 폴더 직접 read/write
obsidian-mcp-serverObsidian vault백링크·태그·search API 노출
notion-mcpNotion페이지·블록 단위 접근
memory-mcp영구 메모리세션 간 지식 누적

자세한 내용은 MCP 시리즈 참조.

F. 통합 패턴

패턴규모특징
Karpathy LLM Wiki개인 (~수백 파일)raw/ + wiki/ + CLAUDE.md. RAG 없이 컨텍스트 직접 로드
Mintlify Docs공개 사이트llms.txt 자동 생성, MDX 기반
Quartz + AGENTS.md개인/팀 공개 wikiObsidian → 정적 사이트 + LLM 진입점
GraphRAG / LightRAG대규모 기업 (~수만 문서)지식 그래프 + 벡터 검색 결합

4. 주요 플레이어 현황

플레이어미는 표준자사 도구특징
AnthropicCLAUDE.md, MCP, SkillsClaude Code, Claude DesktopMCP 프로토콜 창시. AGENTS.md도 지지
OpenAIAGENTS.mdCodex, ChatGPT memoryAGENTS.md 명명·표준화 주도
GoogleAGENTS.md, GEMINI.mdGemini CLI, JulesAGENTS.md 공동 지지
Cursor.cursor/rules, AGENTS.mdCursor IDE.cursorrules 단일 파일에서 .cursor/rules 다중 파일로 진화
Mintlifyllms.txtMintlify docs platformllms.txt 자동 생성 기능 내장
VercelAGENTS.mdv0, Vercel AI SDKAGENTS.md 공식 가이드 발행
Continue.devllms.txt, MCPContinue IDE 확장오픈소스 코딩 에이전트
ApifyLLM-friendly docs 가이드Apify 플랫폼크롤링 결과를 LLM 친화 마크다운으로 출력

채택 현황 (2025-10 기준)

표준채택 사이트/저장소 수
llms.txt약 844,000+ (directory.llmstxt.cloud 집계)
AGENTS.mdOpenAI/Google/Vercel/Cursor/Anthropic 공식 지지, GitHub 검색 시 수만 저장소
CLAUDE.mdClaude Code 사용자 저장소 다수
MCP 서버 공개1,000+ 개 (modelcontextprotocol.io 디렉토리)

5. 세 가지 큰 흐름 — 어디로 가고 있는가

흐름 ① 표준 수렴 (AGENTS.md)

2024년까지 .cursorrules, .windsurfrules, CLAUDE.md 등 도구별 파편화가 심했다. 2025 중반 OpenAI 주도로 AGENTS.md가 단일 마스터 지침 파일로 합의되면서 수렴이 시작됐다. 도구별 파일은 AGENTS.md의 심링크 또는 확장으로 남는다.

흐름 ② RAG에서 컨텍스트 직접 로드로

LLM 컨텍스트 윈도우가 100K~1M 토큰으로 커지면서, 개인·소규모 위키는 RAG를 거치지 않고 통째로 로드하는 방식이 유리해졌다. Karpathy가 2026-04 공개한 LLM Wiki 패턴이 대표적이며, 그는 개인 위키 규모에서 RAG 대비 70배 효율이라고 평가했다.

graph TD
    Old["~2024 패턴<br/>RAG 중심"]
    New["2026 패턴<br/>이중화"]

    Old --> O1["모든 위키 → 벡터 DB"]
    Old --> O2["질문 → 청크 검색 → LLM"]

    New --> N1["개인/소규모<br/>전체 → 컨텍스트 직접 로드"]
    New --> N2["팀/대규모<br/>RAG + GraphRAG 유지"]
    New --> N3["에이전트 접근<br/>MCP로 read/write"]

흐름 ③ 정적 사이트 + LLM 진입점

Mintlify, Docusaurus, MkDocs Material, Quartz 같은 정적 사이트 생성기에 llms.txt 자동 생성 기능이 표준 탑재되고 있다. 사람용 HTML과 LLM용 텍스트 진입점을 동시에 발행하는 패턴이 자리잡는 중이다.


문서 탐색


참고 자료