Notes
10분 읽기AI & Tools

Karpathy의 LLM Wiki 패턴과 차세대 지식 운영

Karpathy가 제안한 LLM Wiki를 RAG, GraphRAG, 장기 메모리 흐름과 비교하고, 개인·팀 지식베이스에 적용할 운영 원칙을 정리한 노트.

Karpathy의 LLM Wiki 패턴과 차세대 지식 운영

한 줄 요약

LLM Wiki는 원본 자료를 불변으로 보관하고, LLM이 사람이 읽을 수 있는 Markdown 위키로 지식을 계속 컴파일하며, 출처·모순·갱신 이력·링크를 Git처럼 관리하는 agent-native knowledge base다.

먼저 읽을 결론

Karpathy의 LLM Wiki는 RAG를 대체하는 단일 기술이라기보다, LLM 시대의 지식관리 운영 방식에 가깝다. 일반 RAG가 질문마다 원문 chunk를 다시 찾아 답한다면, LLM Wiki는 자료를 한 번 읽고 지속적으로 갱신되는 Markdown 지식층으로 정리해둔다.

가장 좋은 기본형은 단순하다.

RAW는 불변.
Wiki는 컴파일된 지식.
모든 claim은 출처 필수.
모순은 숨기지 말고 tension page로 승격.
LLM은 synthesis 담당, 검증과 인덱싱은 가능한 한 deterministic하게.
Git diff로 사람이 승인.
검색은 전체 덤프가 아니라 search -> section expand.
오래된 기억은 decay / reverify / retire.

핵심 통찰은 "더 긴 컨텍스트"보다 더 신뢰할 수 있는 외부 기억이 중요해진다는 점이다. LLM Wiki, GraphRAG, long-term memory, MCP, Git-native review, self-evolving refinement가 합쳐지면 agent가 매번 처음부터 생각하는 시스템에서 이전 작업의 지식이 축적되고 검증되는 시스템으로 넘어간다.

다만 자동 요약이 사실처럼 굳어지는 위험이 크다. LLM Wiki를 제대로 쓰려면 source_id, claim_id, last_verified, review_after, tension page, lint, PR review가 필요하다.

왜 저장했나

Waitworthy 자체가 이미 sources/와 wiki/를 나누고, AI 연구 결과를 공개 Markdown 노트로 컴파일하는 구조다. Karpathy의 LLM Wiki 패턴은 이 저장소가 가려는 방향과 직접 맞닿아 있다.

이 노트는 LLM Wiki를 단순 노트 앱 아이디어가 아니라, agent가 유지하는 지식베이스의 운영 원칙으로 다시 보기 위해 저장했다.

정리한 질문

Karpathy가 말한 LLM Wiki는 무엇이며, 최근 RAG·GraphRAG·agent memory·커뮤니티 구현 흐름을 볼 때 개인이나 팀은 어떤 방식으로 운영하는 것이 좋은가?

LLM Wiki란 무엇인가

LLM Wiki는 LLM이 읽고, 요약하고, 연결하고, 갱신하는 개인 또는 팀 지식 위키다. Karpathy의 원문은 이를 "personal knowledge bases using LLMs"를 만드는 패턴으로 설명한다.

비유하면 일반 RAG는 필요할 때마다 창고에서 관련 박스를 찾아오는 방식이다. LLM Wiki는 그 박스를 사람이 읽기 좋은 설명서, 색인, 교차참조, 변경 로그가 있는 살아있는 백과사전으로 정리해두는 방식이다.

Karpathy가 제안한 기본 구조는 세 층이다.

층역할운영 원칙
Raw sources기사, 논문, 이미지, 데이터 파일, 회의록 같은 원본 자료불변 source of truth로 보관한다.
WikiLLM이 만든 Markdown 페이지, 요약, entity page, concept page, synthesisLLM이 만들고 갱신하지만 사람이 읽고 검토한다.
SchemaCLAUDE.md, AGENTS.md 같은 운영 규칙구조, 작성 규칙, 인용 규칙, ingest/query/lint 흐름을 정의한다.

작업은 크게 ingest, query, lint로 나뉜다. ingest는 새 자료를 넣고 관련 페이지를 업데이트하는 과정이다. query는 위키를 읽고 답하는 과정이다. lint는 모순, 중복, 깨진 링크, 출처 누락, 오래된 주장을 검사하는 과정이다.

Karpathy의 강한 비유는 "Obsidian은 IDE, LLM은 프로그래머, wiki는 codebase"라는 것이다. 이 관점에서는 지식베이스도 코드처럼 diff, review, lint, log, index가 필요하다.

RAG, GraphRAG, Memory와의 차이

구분무엇을 저장하나읽는 방식강점약점
기본 RAG원문 chunk와 embeddingtop-k 유사도 검색구축이 빠르고 단순하다.관계, 모순, 시간 변화를 다루기 어렵다.
GraphRAG엔티티, 관계, 커뮤니티 요약그래프와 요약 기반 검색문서 사이의 연결과 전체 그림에 강하다.스키마와 구축 비용이 늘어난다.
장기 메모리사용자, 작업, 대화에서 추출한 기억저장, 갱신, 검색 루프개인화와 연속 작업에 강하다.기억 오염, 오래된 기억, 삭제 문제가 생긴다.
LLM Wiki사람이 읽을 수 있는 Markdown 지식층색인, 링크, 섹션, 출처 기반 탐색사람이 검토하고 Git으로 관리하기 좋다.관리 규칙이 없으면 hallucination이 정리된 지식처럼 굳어진다.

GraphRAG, LightRAG, HippoRAG2 같은 흐름은 검색을 더 구조화한다. LLM Wiki는 이들과 경쟁한다기보다, 사람이 검토 가능한 Markdown 지식층을 중심에 두고 필요하면 graph search, vector search, MCP, agent memory를 붙이는 상위 운영 패턴에 가깝다.

최근 연구 흐름

최근 흐름은 "긴 컨텍스트에 다 넣자"에서 "외부 기억을 구조화하고, 갱신하고, 검증하자"로 이동하고 있다.

Agent-native retrieval

LLM-Wiki: Retrieval as Reasoning 논문은 문서를 구조화된 위키 페이지와 양방향 링크로 컴파일하고, agent가 search, read, link-follow 같은 도구로 증거를 추적하는 방식을 제안한다. 원문은 HotpotQA, MuSiQue, 2WikiMultiHopQA 같은 multi-hop QA에서 HippoRAG2, LightRAG, GraphRAG보다 F1 기준 2.0~8.1점 높았다는 보고를 보존했다.

여기서 중요한 점은 retrieval을 단순 top-k 검색이 아니라 추론 과정 자체로 본다는 것이다.

Evolving memory

LLM-Wiki 논문은 실패한 질의를 Error Book에 저장해 다음 검색과 위키 개선에 반영한다. DeepRefine은 agent가 만든 지식베이스가 불완전, 부정확, 중복되기 쉽고 오류가 누적될 수 있다고 보고, 전체 재컴파일 대신 질의 기반 refinement를 제안한다.

Memory governance

Governing the Evolving Memory of LLM Agents는 장기 메모리에서 input poisoning, semantic drift, retrieval hallucination 같은 오류 루프가 생길 수 있다고 본다. 실행과 메모리 진화를 분리하고 일관성 검증, 시간 감쇠, 접근 제어를 두는 SSGM 구조를 제안한다.

Multi-graph memory

MAGMA는 semantic, temporal, causal, entity graph를 함께 쓰는 multi-graph memory를 제안한다. 단일 관계 타입만으로는 복잡한 장기 기억 질의에 부족하다는 문제의식이다. 다만 LLM 기반 추출 오류와 저장·엔지니어링 복잡성은 여전히 한계로 남는다.

Long-memory benchmarks

BEAM은 최대 1천만 토큰 규모의 긴 대화를 대상으로 평가한다. MEME는 evolving memory에서 의존성 추론, 삭제, 부재 정보가 어렵다고 보고한다. 이 흐름은 컨텍스트 길이만 늘리는 것으로 memory 문제가 해결되지 않는다는 점을 보여준다.

GitHub와 도구 흐름

Karpathy gist 이후 구현체와 실험은 빠르게 늘었다.

도구 / 흐름핵심 아이디어판단
obsidian-wikiObsidian과 agent가 함께 쓰는 digital brain. /wiki-status, /wiki-rebuild, /wiki-query, /wiki-lint 같은 명령을 제공한다.Karpathy 패턴을 가장 직접적으로 구현한 축에 가깝다.
Synto로컬 LLM 중심의 raw notes -> interlinked wiki. vector DB 없이 개념별 wiki article을 컴파일한다.local-first와 privacy 중심 실험에 적합하다. MCP server 인증 주의가 필요하다.
AutoSciSciMem으로 장기 지식과 active research memory를 나누고, 연구 lifecycle을 자동화하려 한다.production보다 연구 자동화 패턴 참고용으로 보는 편이 안전하다.
Mem0동적 추출, 통합, 검색, graph memory를 통한 long-term memory layer.LLM Wiki와 결합 가능한 memory backend 흐름이다.
Zep / Graphititemporally-aware knowledge graph로 과거 관계와 시간 변화를 추적한다.시간성이 중요한 팀 메모리와 잘 맞는다.
MAGMAsemantic, temporal, causal, entity graph를 함께 쓰는 agentic memory.다음 세대 multi-graph memory 방향을 보여준다.

도구 선택보다 중요한 것은 canonical layer를 무엇으로 둘지다. 원문과 커뮤니티 논의는 Markdown vault를 canonical truth로 두고, SQLite/FTS/vector/graph index는 재생성 가능한 derived state로 두는 방향을 반복해서 강조한다.

커뮤니티 토론의 실전 교훈

커뮤니티 반응은 대체로 "방향은 맞지만 운영 규칙이 없으면 금방 망가진다"에 가깝다.

중요한 교훈은 네 가지다.

  1. Canonical Markdown과 derived index를 분리한다.
  2. Intake, index, validation, compact handoff 같은 결정론적 작업은 스크립트로 처리하고, synthesis와 judgment만 LLM에 맡긴다.
  3. 모순은 단순 edge가 아니라 tension 페이지처럼 독립된 객체로 관리한다.
  4. 검색은 전체 노트 덤프가 아니라 search -> section expand 방식으로 한다.

LLM Wiki는 편리한 자동 요약기가 아니다. 지식이 누적될수록 출처 없는 claim, duplicate concept drift, stale synthesis, hallucination 저장이 더 위험해진다.

Best Practice

최소 디렉터리 구조

작게 시작할 때는 vector DB나 graph DB를 붙이지 않아도 된다.

my-llm-wiki/
  RAW/
    papers/
    webclips/
    meetings/
    transcripts/
    screenshots/
  wiki/
    concepts/
    entities/
    decisions/
    projects/
    questions/
    syntheses/
    tensions/
    sources/
  index.md
  log.md
  AGENTS.md
  manifest.json

RAW는 원본 보관소다. 가능하면 수정하지 않는다. wiki는 LLM이 정리한 지식층이다. index.md는 사람과 agent가 함께 보는 목차이고, log.md는 ingest, query, lint의 변경 기록이다. AGENTS.md는 agent에게 주는 운영 규칙이다.

AGENTS.md 필수 규칙

# LLM Wiki Operating Rules

1. RAW files are immutable. Never rewrite RAW sources.
2. Wiki pages are compiled knowledge, not primary evidence.
3. Every factual claim must cite a source_id.
4. If sources conflict, create or update a page under wiki/tensions/.
5. Do not silently resolve contradictions.
6. Update index.md and log.md after every ingest.
7. Do not create duplicate concept pages; merge or add aliases.
8. Mark stale pages with last_verified and review_after.
9. Answers must distinguish confirmed facts, inferred synthesis, and open questions.
10. Derived indexes can be rebuilt; Markdown wiki is canonical.

핵심은 "LLM이 보기 좋게 정리한 문장"을 곧바로 사실로 믿지 않는 것이다. 원본은 RAW, 해석은 wiki, 검증 상태는 metadata로 분리한다.

Frontmatter 스키마

---
type: concept
title: "LLM Wiki"
aliases: ["agentic wiki", "AI-maintained wiki"]
status: active
confidence: medium
last_verified: 2026-06-26
sources:
  - source_id: karpathy-gist-2026
  - source_id: llm-wiki-paper-2026
related:
  - "[[RAG]]"
  - "[[GraphRAG]]"
  - "[[Long-term memory]]"
open_questions:
  - "How should contradictions be resolved across time-sensitive sources?"
---

last_verified, review_after, confidence, sources, open_questions가 있어야 agent가 오래된 정보와 검증된 정보를 구분할 수 있다.

Ingest 프로세스

  1. 원본을 RAW/에 저장한다.
  2. manifest.json에 파일명, 해시, 출처 URL, 수집일, 라이선스, 민감도를 기록한다.
  3. LLM이 source summary를 만든다.
  4. 기존 wiki에서 관련 페이지를 찾는다.
  5. 새 개념이면 새 페이지를 만들고, 기존 개념이면 기존 페이지를 갱신한다.
  6. 인용 없는 factual claim을 금지한다.
  7. 모순이 있으면 wiki/tensions/에 기록한다.
  8. index.md와 log.md를 갱신한다.
  9. lint를 실행한다.
  10. Git diff를 보고 사람이 승인한다.

Query 프로세스

질문 수신
-> index.md 읽기
-> 관련 페이지 검색
-> 관련 섹션만 확장
-> RAW source 또는 source summary 확인
-> 답변 작성
-> 확실한 사실 / 추론 / 불확실성 구분
-> 필요하면 "wiki에 반영할 업데이트" 제안

전체 vault를 통째로 context에 넣지 않는 것이 중요하다. 검색 후 필요한 섹션만 확장해야 비용과 품질을 동시에 잡을 수 있다.

Lint 프로세스

최소 lint는 다음을 봐야 한다.

- 출처 없는 factual claim
- 깨진 wikilink
- orphan page
- 중복 concept
- alias 충돌
- 오래된 last_verified
- unresolved hard contradiction
- frontmatter 스키마 위반
- RAW에는 있는데 wiki에 반영되지 않은 source
- wiki에는 있는데 RAW 출처가 없는 claim

실전에서는 변경된 노드와 1~2-hop 이웃을 먼저 검사하고, 큰 ingest 이후나 명시 요청 시 전체 sweep을 돌리는 방식이 현실적이다.

도구 조합

개인 지식관리나 빠른 실험은 **Obsidian + Git + Claude Code 또는 Codex + AGENTS.md**만으로 시작할 수 있다.

로컬·프라이버시 중심이면 Synto 같은 local-first 접근이 맞다. 다만 MCP 서버를 붙일 때는 인증과 네트워크 노출을 주의해야 한다.

팀·프로젝트 지식베이스라면 Markdown + YAML frontmatter + wikilinks를 repo에 두고, 변경은 PR이나 "Brain Diff"로 리뷰하는 구조가 좋다.

대규모 검색이나 제품화 단계에서는 Markdown vault를 canonical source로 두고, SQLite FTS5, BM25, vector index, graph index를 derived index로 재생성하는 편이 안전하다.

연구 자동화는 AutoSci, LLM-Wiki, DeepRefine, MAGMA 같은 최신 연구를 참고하되, 처음부터 전체 lifecycle 자동화를 맡기기보다 문헌 ingest, 가설 생성, 실험 계획, 결과 정리 중 일부 단계부터 적용하는 편이 낫다.

다음 세대 인사이트

문서 검색에서 기억 운영체제로

다음 세대 LLM Wiki는 문서 요약기가 아니라 memory operating system에 가까워질 가능성이 크다. 핵심 질문도 바뀐다.

무엇을 기억으로 승격할 것인가?
무엇은 시간이 지나면 약화할 것인가?
무엇은 삭제해야 하는가?
무엇은 모순 상태로 남겨야 하는가?
어떤 agent가 어떤 memory를 수정할 권한이 있는가?

Contradiction은 1급 객체가 된다

가격, 정책, API, 논문 결과, 회사 전략은 시간이 지나며 바뀐다. 좋은 LLM Wiki는 이렇게 답해야 한다.

A 문서는 2025년 기준 X라고 말한다.
B 문서는 2026년 기준 Y라고 말한다.
두 문서는 scope가 다르거나 시간이 다르다.
현재 답변에는 Y를 쓰되, X는 historical note로 유지한다.

이게 가능하려면 모든 claim에 source_id, date, scope, status가 있어야 한다.

더 많이 기억하기보다 잘 잊기가 중요하다

오래된 정보를 자동으로 약화시키고, 재검증을 요구하고, 더 이상 유효하지 않은 정보를 은퇴시키는 정책이 필요하다.

last_verified: 2026-06-26
review_after: 2026-07-26
staleness_policy: "recheck monthly"

Agent는 top-k chunk보다 탐색 경로가 필요하다

다음 세대 시스템은 검색 결과 몇 개를 던지는 것보다 agent가 탐색할 수 있는 환경을 제공해야 한다.

search(query)
read_page(page_id)
read_section(page_id, heading)
follow_links(page_id, relation_type)
find_contradictions(entity_id)
show_sources(claim_id)
update_page_with_review(diff)
record_failed_path(question, reason)

Git-native memory가 강력해진다

지식베이스가 자동으로 바뀐다면 변경 이력과 리뷰가 필수다. Git은 누가 어떤 claim을 추가했는지, 어떤 source에서 왔는지, 어떤 모순이 생겼는지, 어떤 agent가 잘못된 업데이트를 했는지 추적하기 좋다.

Memory 평가가 필요하다

LLM Wiki는 "답이 그럴듯한가"만 보면 안 된다. regression set이 필요하다.

- 단일 문서에서 바로 답하는 질문
- 여러 문서를 연결해야 하는 질문
- 시간 순서를 따라야 하는 질문
- 삭제/철회된 정보를 반영해야 하는 질문
- 답이 없어야 하는 질문
- 서로 모순되는 자료를 구분해야 하는 질문
- 과거에는 맞았지만 지금은 틀린 질문

바로 적용할 운영 레시피

1주차:
- Obsidian vault 생성
- Git repo 연결
- RAW/wiki/index.md/log.md/AGENTS.md 생성
- 논문 5개 또는 프로젝트 문서 20개 이하로만 실험
- vector DB 없이 Markdown 검색과 LLM만 사용

2주차:
- ingest prompt 고정
- frontmatter 스키마 고정
- citation rule 강제
- duplicate concept lint 추가
- Git diff review 습관화

3~4주차:
- 질문 30개짜리 regression set 작성
- query workflow 정리
- stale page / contradiction / unresolved question 관리
- 필요할 때만 FTS 또는 vector index 추가

그 이후:
- MCP 서버화
- team review flow 도입
- graph edge, entity page, tension page 확장
- 자동 refresh와 scheduled lint 도입

개인 지식관리라면 Obsidian + Git + Claude Code/Codex + AGENTS.md만으로 충분히 시작할 수 있다. 팀이나 제품화 목적이면 처음부터 source_id, claim_id, last_verified, review_after, tension page, lint, PR review를 넣어야 한다.

Skill Artifact

이 노트는 독립 skill 저장소가 아니라, LLM Wiki를 유지하는 agent에게 줄 수 있는 운영 지침으로 쓴다.

Agent는 이 페이지를 다음 상황에서 참고한다.

  • 새 source를 RAW/ 또는 sources/에 넣고 public wiki page로 컴파일할 때
  • 오래된 지식 페이지의 last_verified, review_after, confidence를 점검할 때
  • 서로 충돌하는 자료를 발견해 tension 또는 claims to verify로 분리해야 할 때
  • Markdown vault, Obsidian, Git, MCP, search index를 함께 쓰는 지식베이스를 설계할 때

범위는 운영 원칙과 체크리스트다. 특정 벤치마크 성능, 최신 repo 기능, arXiv 주장, 커뮤니티 의견은 원문 기준일 이후 바뀔 수 있으므로, 중요한 의사결정에는 원문 source와 현재 공식 문서를 다시 확인한다.

주의점

  • 자동 요약이 사실처럼 굳어지는 문제를 막아야 한다. 출처 없는 wiki 문장은 금지하는 편이 안전하다.
  • API, 가격, 법률, 정책, 논문 SOTA, 회사 정보처럼 빠르게 변하는 항목은 last_verified와 review_after 없이 쓰면 위험하다.
  • 작은 지식베이스에 과설계하지 않는다. 문서가 적을 때는 Markdown, Git, 명확한 prompt, 수동 리뷰만으로 충분하다.
  • MCP나 HTTP server를 붙이면 보안 문제가 생긴다. 특히 로컬 wiki를 네트워크로 열 때는 인증, reverse proxy, firewall, allowed host 설정을 확인한다.
  • 논문과 커뮤니티 구현은 성숙도가 다르다. production 운영 규칙은 공식 문서, source code, 실제 eval로 다시 검증해야 한다.

검증이 필요한 주장

  • LLM-Wiki: Retrieval as Reasoning 논문의 F1 2.0~8.1점 개선은 특정 benchmark와 설정의 결과이므로 일반 RAG 시스템 전체에 그대로 일반화하면 안 된다.
  • BEAM의 최대 1천만 토큰 평가, MEME의 cascade/absence 태스크 난이도, MAGMA·Mem0·Zep의 성능 주장은 논문·구현 버전과 평가 데이터셋을 확인해야 한다.
  • obsidian-wiki, Synto, AutoSci, MAGMA 같은 repo의 기능과 안정성은 빠르게 바뀔 수 있다.
  • 커뮤니티 댓글의 운영 패턴은 실전 신호로 유용하지만, 기술적 사실을 단독으로 증명하지는 않는다.
  • MCP 서버 보안, 인증, 네트워크 노출 위험은 각 구현의 현재 문서를 다시 확인해야 한다.

Source Fidelity Notes

  • Preserved key numbers: source date 2026-06-26, Karpathy gist creation date April 4, 2026, 한 source가 1015개 wiki page를 touch할 수 있다는 운영 예시, moderate scale에서 약 100 sources와 hundreds of pages까지 index.md가 유용하다는 gist 설명, LLM-Wiki 논문의 F1 2.08.1점 개선 주장, BEAM의 최대 1천만 토큰 평가, 1주차/2주차/3~4주차 rollout, 논문 5개 또는 프로젝트 문서 20개 이하 실험, 질문 30개 regression set.
  • Preserved frameworks / models: Raw sources / wiki / schema 3층 구조, ingest/query/lint, RAG·GraphRAG·장기 메모리·LLM Wiki 비교, agent-native retrieval, evolving memory, SSGM, multi-graph memory, long-memory benchmarks, canonical Markdown vs derived index, search -> section expand, tension page, memory operating system, Git-native memory.
  • Preserved templates / checklists: LLM Wiki directory structure, AGENTS.md operating rules, frontmatter schema, ingest process, query process, lint checklist, next-generation tool API sketch, rollout recipe, Skill Artifact usage scope.
  • Omitted or compressed: 원문의 긴 논문별 설명, 일부 repo 홍보 문구, 커뮤니티 댓글의 세부 문맥, 중복되는 결론 문장, 모든 참고 링크의 상세 해설은 줄였다.
  • Interpretation risk: 공개 노트는 운영 원칙을 보존하지만, 각 논문·repo·커뮤니티 claim의 최신 상태를 모두 재검증한 결과는 아니다. 원문 전체는 sources/ layer에 보존했다.

출처 / 참고자료