3.5.2 LLM Wiki 방식별 상세 비교

6가지 카테고리에 속하는 주요 방식들을 하나씩 뜯어본다. 각 방식의 동작 원리, 장단점, 실제 채택 사례를 비교하고 마지막에 종합 의사결정 표로 정리한다. 업데이트: 2026-05-14


핵심 요약

구분내용
📖 정의1편에서 그린 지형도 위의 각 방식을 비교·평가
💡 핵심단일 정답은 없다. 위키 규모, 주 사용 에이전트, 공개 여부에 따라 조합이 달라진다
🎯 대상자신의 위키에 어떤 방식을 도입할지 결정해야 하는 사람
⚠️ 주의모든 방식을 다 도입할 필요는 없다. 진입점 1개 + 지침 파일 1개 + 작성 컨벤션이 최소 구성

문서 탐색


목차

  1. llms.txt — 사이트 진입점 표준
  2. AGENTS.md / CLAUDE.md — 에이전트 지침 파일
  3. Karpathy LLM Wiki — 개인 위키 패턴
  4. Markdown + RAG — 검색형 패턴
  5. MCP 연계 — 에이전트 직접 접근
  6. GraphRAG / LightRAG — 대규모 패턴
  7. 종합 비교 테이블

1. llms.txt — 사이트 진입점 표준

동작 원리

graph TD
    A["AI 에이전트<br/>(Cursor / Continue / Perplexity)"]
    B["사이트 루트<br/>/llms.txt"]
    C["llms.txt 내부<br/>마크다운 링크 트리"]
    D["원본 문서들<br/>.md 파일"]

    A -->|"1. fetch"| B
    B --> C
    A -->|"2. 필요한 링크만 follow"| D

사이트 루트의 /llms.txt 파일에 마크다운 링크 트리 형식으로 사이트의 핵심 문서 목록을 둔다. AI 에이전트는 이 파일을 가장 먼저 읽어 사이트 구조를 파악하고, 필요한 링크만 골라 본문을 가져간다.

형식 예시

# Anthropic Docs
 
> Anthropic은 안전성과 연구를 중심으로 한 AI 회사다.
 
## Docs
 
- [Get started with the Claude API](https://docs.anthropic.com/en/api/getting-started.md)
- [Models overview](https://docs.anthropic.com/en/docs/models-overview.md)
 
## Optional
 
- [Glossary](https://docs.anthropic.com/en/docs/glossary.md)

변형 — llms-full.txt

/llms-full.txt는 모든 문서를 단일 파일로 통합한 버전이다. 컨텍스트 윈도우가 충분히 큰 LLM이 통째로 로드해 처리할 수 있다.

장단점

장점단점
표준화되어 있음 (llmstxt.org 사양)주요 LLM 크롤러(OpenAI/Anthropic)는 아직 적극 활용 안 함
정적 사이트에 추가하기 쉬움수동 관리하면 사이트 구조 변경 시 동기화 부담
Mintlify·Docusaurus 자동 생성 지원”공개 사이트” 전제 — 개인 로컬 vault에는 부적합
Cursor·Continue·Perplexity가 활용결국 본문도 마크다운으로 노출해야 함 (page.md 별도 발행)

실제 채택 사례

사이트비고
docs.anthropic.com/llms.txt, /llms-full.txt 둘 다 운영
docs.stripe.comllms.txt 운영
cloudflare.comllms.txt 운영
mintlify.com자체 플랫폼에서 자동 생성

채택 현황: 2025-10 기준 약 84만 사이트 (directory.llmstxt.cloud 집계).


2. AGENTS.md / CLAUDE.md — 에이전트 지침 파일

동작 원리

graph TD
    A["코딩 에이전트<br/>세션 시작"]
    B{"저장소 루트<br/>스캔"}
    C["AGENTS.md<br/>(범용)"]
    D["CLAUDE.md<br/>(Claude Code)"]
    E[".cursor/rules/*.mdc<br/>(Cursor)"]

    A --> B
    B --> C
    B --> D
    B --> E
    C -->|"세션 컨텍스트에<br/>자동 로드"| F["LLM 호출에 항상 포함"]
    D --> F
    E --> F

에이전트는 세션을 시작할 때 저장소 루트의 지침 파일들을 자동으로 시스템 프롬프트에 주입한다. 이 파일들은 “이 저장소에서는 어떤 명령을 실행하면 안 된다”, “이 코딩 스타일을 따라라”, “이 폴더 구조를 지켜라” 같은 지침을 담는다.

일반적인 AGENTS.md 구조

# AGENTS.md
 
## Project context
간단한 프로젝트 설명. 기술 스택.
 
## Build & test
```bash
npm install
npm test

Code style

  • 들여쓰기 2 스페이스
  • 함수형 우선
  • React: 컴포넌트는 PascalCase

Conventions

  • 커밋 메시지: Conventional Commits
  • PR 타이틀: [scope] description

Don’t

  • npm publish 실행 금지
  • main 브랜치 직접 push 금지

### 도구별 파일 비교

| 파일 | 적용 범위 | 우선순위 | 특이사항 |
|---|---|---|---|
| **AGENTS.md** | 범용 마스터 | 최상위 | OpenAI/Google/Vercel/Anthropic 공동 지지 |
| **CLAUDE.md** | Claude Code 전용 | AGENTS.md보다 후순위 권장 | 심링크로 AGENTS.md 가리키는 패턴 권장 |
| **.cursor/rules/*.mdc** | Cursor IDE | 글롭 패턴별 적용 | 파일 패턴(`*.ts`)에 따라 다른 규칙 적용 |
| **GEMINI.md** | Gemini CLI | — | Google 전용 |
| **.windsurfrules** | Windsurf | — | Codeium 전용 |

### 권장 패턴 — 심링크로 단일 진실 소스 유지

```bash
# Unix/macOS
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md

# Windows (PowerShell, 관리자 필요)
New-Item -ItemType SymbolicLink -Path CLAUDE.md -Target AGENTS.md

장단점

장점단점
에이전트가 자동 로드 — 매번 알려줄 필요 없음너무 길면 컨텍스트 낭비 (보통 1~3K 토큰 권장)
표준 수렴 진행 중 (AGENTS.md)도구별 차이 여전히 존재
위키뿐 아니라 코드베이스 전반에 적용자주 갱신 안 하면 stale

실제 채택 사례

  • OpenAI의 codex 저장소들 — AGENTS.md 사용
  • Vercel의 v0 관련 저장소 — AGENTS.md 가이드 공식 발행
  • Anthropic의 anthropic-cookbook — CLAUDE.md 사용
  • 수많은 오픈소스 — AGENTS.md/CLAUDE.md 채택 확산 중

3. Karpathy LLM Wiki — 개인 위키 패턴

동작 원리

Andrej Karpathy가 2026-04-04 GitHub Gist로 공개한 패턴이다. RAG 없이 순수 마크다운 파일을 컨텍스트 윈도우에 직접 로드한다.

graph TD
    subgraph 폴더["폴더 구조"]
        Raw["raw/<br/>(불변 소스)"]
        Wiki["wiki/<br/>(LLM이 작성·관리)"]
        Claude["CLAUDE.md<br/>(스키마 + 지침)"]
        Log["log.md<br/>(작업 이력)"]
    end

    User["사용자"] -->|"새 자료 투입"| Raw
    Raw -->|"Ingest"| Agent["LLM 에이전트"]
    Agent -->|"구조화하여 작성"| Wiki
    Agent -->|"기록"| Log
    Claude -->|"매 세션 로드"| Agent

    User -->|"질문"| Agent
    Wiki -->|"Query"| Agent

폴더 구조

my-wiki/
├── CLAUDE.md       # 스키마, 폴더 규칙, 에이전트 지침
├── log.md          # 작업 이력 (에이전트가 누적 기록)
├── raw/            # 불변 소스
│   ├── papers/     # PDF, 논문 텍스트
│   ├── urls.md     # 북마크
│   └── notes/      # 손으로 쓴 메모
└── wiki/           # LLM이 정돈한 구조화 페이지
    ├── topic-a.md
    └── topic-b.md

에이전트의 3가지 작업

작업입력출력
Ingestraw/ 신규 자료wiki/ 페이지 생성·갱신
Query사용자 질문wiki/ 검색 후 답변
Lint전체 wiki/중복·모순·stale 항목 리포트

Karpathy의 주장

“개인 위키 규모(수백~수천 파일)에서는 RAG보다 70배 효율적이다. 임베딩·벡터 DB·청크 전략을 모두 우회하고, 그냥 마크다운을 컨텍스트에 넣으면 된다.”

핵심은 컨텍스트 윈도우가 100K~1M 토큰으로 커지면서 개인 규모 지식은 통째로 로드 가능해졌다는 점이다.

장단점

장점단점
인프라 0 — 폴더와 마크다운만 있으면 됨위키 규모 한계 (보통 수백 파일)
임베딩·벡터 DB·청크 튜닝 불필요매 쿼리마다 컨텍스트 비용 발생
에이전트가 직접 read/write — 누적 학습팀 협업·동시 편집에 약함
CLAUDE.md로 스키마 강제 가능검색 가능성은 LLM의 long-context 능력에 의존

적합 사용처

  • 개인 학습 노트
  • 1인 연구자의 문헌 관리
  • 작은 팀의 내부 핸드북

4. Markdown + RAG — 검색형 패턴

동작 원리

graph TD
    subgraph 인덱싱["인덱싱 단계"]
        MD["Markdown 파일들"]
        Split["MarkdownHeaderTextSplitter<br/>H1/H2/H3 기준 분할"]
        Embed["임베딩 모델"]
        VDB["Vector DB<br/>(Chroma·LanceDB 등)"]
        MD --> Split --> Embed --> VDB
    end

    subgraph 검색["검색 단계"]
        Q["사용자 질문"]
        QE["질문 임베딩"]
        Search["유사도 검색<br/>+ BM25"]
        Topk["Top-k 청크"]
        LLM["LLM"]
        Ans["답변"]

        Q --> QE --> Search
        VDB --> Search
        Search --> Topk --> LLM --> Ans
    end

위키의 마크다운을 청크로 잘라 벡터 DB에 임베딩하고, 질문마다 의미 검색으로 관련 청크를 가져와 LLM에 전달한다.

권장 청크 설정 (2026 기준)

항목권장값근거
청크 크기512 토큰Firecrawl·LangChain 권장값
오버랩1020% (50100 토큰)문맥 연속성
분할 기준Markdown 헤딩MarkdownHeaderTextSplitter 사용
임베딩 모델text-embedding-3-small 또는 BGE-M3비용·품질 균형
검색 방식Hybrid (BM25 + Vector)단일 방식 대비 정확도 향상

MarkdownHeaderTextSplitter 사용 예 (Python)

from langchain.text_splitter import MarkdownHeaderTextSplitter
 
headers_to_split_on = [
    ("#", "Header 1"),
    ("##", "Header 2"),
    ("###", "Header 3"),
]
 
splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=headers_to_split_on,
    strip_headers=False,
)
 
with open("wiki/topic-a.md") as f:
    docs = splitter.split_text(f.read())
 
# 각 청크에 헤딩 경로가 메타데이터로 자동 첨부됨
# 예: {"Header 1": "MCP란", "Header 2": "핵심 아키텍처"}

장단점

장점단점
대규모 위키(수만 문서)에 확장 가능인프라 필요 — 벡터 DB, 임베딩 비용
정확도 튜닝 폭이 넓음청크 전략·임베딩 모델 선택에 따라 품질 편차 큼
메타데이터 필터링 강력동기화 필요 — 위키 갱신마다 재인덱싱
산업 표준, 도구 풍부Karpathy 주장: 개인 규모에선 과한 인프라

적합 사용처

  • 팀 위키 (Notion, Confluence)
  • 공개 문서 사이트의 검색 기능
  • 챗봇 백엔드 (고객 지원, 사내 봇)

5. MCP 연계 — 에이전트 직접 접근

동작 원리

MCP 서버를 통해 에이전트가 위키 파일에 직접 read/write 접근한다.

graph TD
    Agent["에이전트<br/>(Claude Desktop / Code)"]
    MCP["MCP Client"]
    FS["filesystem-mcp<br/>또는<br/>obsidian-mcp-server"]
    Vault["로컬 위키 폴더<br/>(Obsidian vault)"]

    Agent --> MCP
    MCP <-->|"read_file / write_file<br/>search / list"| FS
    FS <--> Vault

주요 MCP 서버

MCP 서버제공 도구비고
filesystem (Anthropic 공식)read_file, write_file, list_directory, search_files가장 범용
obsidian-mcp-server (cyanheads)search, backlinks, tags, frontmatter 조회Obsidian REST API 연계
memory (Anthropic 공식)knowledge graph 조작세션 간 메모리 누적
notion페이지·블록 조작Notion 전용

Claude Desktop 설정 예 (filesystem MCP)

{
  "mcpServers": {
    "wiki": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\user\\my-wiki"
      ]
    }
  }
}

장단점

장점단점
에이전트가 위키를 능동적으로 갱신MCP 클라이언트(Claude Desktop 등) 필요
실시간 — 인덱싱 동기화 불필요권한 관리 필수 (잘못된 write 위험)
다른 도구(웹 검색, 코드 실행)와 결합대규모 위키는 LLM이 검색 시 토큰 부담
위키를 “에이전트의 작업 메모리”로 활용MCP 자체 학습 비용

적합 사용처

  • Karpathy 패턴과 결합 — 에이전트가 직접 wiki/ 작성·갱신
  • 개인 지식베이스 + Claude Desktop 워크플로
  • Obsidian vault를 에이전트와 공유

6. GraphRAG / LightRAG — 대규모 패턴

동작 원리

graph TD
    MD["대규모 문서<br/>(수만 페이지)"]
    NER["엔티티 추출<br/>+ 관계 추출"]
    KG["지식 그래프<br/>(노드 + 엣지)"]
    Vec["벡터 인덱스"]

    MD --> NER
    NER --> KG
    NER --> Vec

    Q["복잡한 질문<br/>(다중 hop)"]
    Q --> KG
    Q --> Vec
    KG --> Combine["그래프 탐색<br/>+ 벡터 검색 결합"]
    Vec --> Combine
    Combine --> LLM --> Ans["답변"]

문서에서 엔티티·관계를 추출해 지식 그래프를 구축하고, 질문에 대해 그래프 탐색과 벡터 검색을 결합한다.

GraphRAG vs LightRAG

항목GraphRAG (Microsoft)LightRAG
인덱싱 비용매우 높음 (LLM으로 엔티티·관계 추출)중간 (이중 레벨 검색)
인덱싱 시간수 시간~수일수십 분
품질복잡한 다중 hop 질문에 강함일반 RAG보다 우수, GraphRAG보다 가벼움
갱신비싸다 (재인덱싱)증분 갱신 지원
대상 규모수만~수십만 문서수천~수만 문서

장단점

장점단점
다중 hop 추론에 강함인프라·비용 부담 큼
엔티티 관계 활용 — 깊은 통찰개인 위키에는 과잉
기업 대규모 지식베이스에 적합운영 복잡도 높음

적합 사용처

  • 기업 내부 대규모 위키
  • 법률·의료 등 깊은 도메인 지식이 필요한 챗봇
  • 연구 기관의 문헌 검색

7. 종합 비교 테이블

방식강점약점적합 상황주요 사용처
llms.txt표준화, 자동 생성 지원주요 LLM 크롤러는 아직 활용 미미공개 docs 사이트Anthropic, Stripe, Mintlify 고객사
AGENTS.md / CLAUDE.md에이전트 자동 로드, 표준 수렴 중도구별 미세 차이 존재코딩 에이전트가 자주 들어오는 저장소OpenAI/Vercel/Anthropic 저장소 다수
Karpathy LLM Wiki인프라 0, 빠른 시작위키 규모 한계 (~수백 파일)개인 학습 노트, 1인 연구Karpathy 본인, 개인 사용자 확산 중
Markdown + RAG대규모 확장, 정밀 튜닝 가능인프라·동기화 부담팀 위키, 챗봇 백엔드Notion AI, Confluence, 사내 챗봇
MCP 연계실시간 read/write, 능동 갱신MCP 클라이언트 필요개인 wiki + 데스크톱 에이전트Claude Desktop + Obsidian 사용자
GraphRAG / LightRAG다중 hop 추론, 깊은 도메인인프라 큼, 운영 복잡대규모 기업 KB, 법률·의료Microsoft, 대형 컨설팅사

조합 패턴 (실전에선 단일 방식 사용 안 함)

시나리오권장 조합
개인 Obsidian + Claude DesktopKarpathy 패턴 + CLAUDE.md + filesystem MCP
개인 Quartz 공개 wikiKarpathy 패턴 + AGENTS.md + llms.txt 자동 생성
팀 docs 사이트 (Mintlify)llms.txt + AGENTS.md + 메타데이터 frontmatter 강화
사내 챗봇 (수만 문서)Markdown + RAG (Hybrid search) + GraphRAG (필요 시)
코드베이스 + 위키AGENTS.md + 코드베이스 README + MCP filesystem

상황별 권장 구성과 실제 설정 방법은 다음 문서 3.5.3 구축 가이드에서 다룬다.


문서 탐색


참고 자료