LLM Wiki: 위키 유지보수를 LLM에게 맡기다
“내 문서들에 AI 검색 붙이면 되겠지”라는 생각으로 RAG를 써본 적 있으신가요. 처음엔 그럴듯해 보이지만 금방 한계가 드러집니다. 원본 문서에서 매번 검색할 뿐, 지식이 쌓이지 않는다는 점이요. Andrej Karpathy가 4월에 공개한 LLM Wiki Gist는 이 문제에 다른 방향으로 접근합니다. LLM이 위키를 직접 소유하고 유지보수하게 하는 거죠.
세 계층 아키텍처
LLM Wiki는 세 개의 레이어로 구성됩니다.
my-wiki/
├── raw/ # 원본 자료 (논문, 글, 데이터) — 불변, LLM이 읽기만 함
├── wiki/ # LLM이 생성·수정하는 마크다운 파일들
│ ├── overview.md
│ ├── concepts/
│ └── entities/
└── CLAUDE.md # Schema — 위키 구조와 워크플로우를 LLM에게 설명하는 설정 파일Raw sources는 여러분이 관리하는 원본 자료입니다. 논문, 아티클, 데이터 파일 등 어떤 형태든 상관없습니다. LLM이 읽기는 하지만 절대 수정하지 않아요. 여러분의 소스 오브 트루스입니다.
Wiki는 LLM이 완전히 소유하는 영역입니다. 요약 페이지, 개념 설명, 엔티티 페이지, 교차참조가 모두 여기 마크다운 파일로 쌓입니다. 새 원본이 들어오면 LLM이 관련 페이지를 업데이트하고, 상충하는 정보가 생기면 직접 메모를 남기고, 일관성을 스스로 유지합니다.
Schema가 핵심입니다. CLAUDE.md (Claude Code용) 또는 AGENTS.md (Codex용) 형태로 작성하는 이 설정 파일이 LLM에게 “위키를 어떻게 구조화할 건지”, “새 원본이 들어오면 어떤 순서로 처리할 건지”를 알려줍니다. 이게 없으면 LLM은 그냥 일반 챗봇이고, 이게 있으면 훈련된 위키 메인테이너가 됩니다.
RAG와 무엇이 다른가
RAG는 질문이 들어올 때마다 원본 문서를 검색해 컨텍스트로 넣어주는 방식입니다. 상태가 없어요. 어제 처리한 문서든 오늘 새로 들어온 문서든 매번 같은 검색을 반복합니다. 지식이 누적되지 않고, 세션 사이에 아무것도 남지 않습니다.
LLM Wiki는 반대입니다. LLM이 원본을 읽고 위키 페이지를 만들어두면 — 그 페이지 자체가 압축된 지식이 됩니다. 다음에 같은 주제가 들어왔을 때 LLM은 원본을 다시 뒤지는 게 아니라, 이미 정리된 위키를 읽고 거기에 새 정보를 통합합니다. 시간이 지날수록 위키가 더 풍부해지는 구조죠.
| RAG | LLM Wiki | |
|---|---|---|
| 상태 | Stateless | 누적·성장 |
| 처리 방식 | 매번 검색 | 위키 업데이트 |
| 소유자 | 검색 시스템 | LLM |
| 교차참조 | 수동 | LLM이 자동 유지 |
왜 위키는 죽고, LLM은 살리는가
위키가 망하는 이유는 하나입니다. 관리 비용이 가치 창출 속도보다 빠르게 증가하기 때문이에요. 교차참조를 업데이트하고, 요약을 최신 상태로 유지하고, 새 자료와 기존 내용이 충돌하는지 확인하는 일은 지루하고 반복적입니다. 사람은 결국 포기합니다.
LLM은 지루함을 모릅니다. 교차참조 15개를 한 번에 업데이트하고, 새 자료가 기존 위키 내용과 충돌하는지 확인하고, 모순이 생기면 직접 메모를 달아둡니다. 관리 비용이 사실상 0에 수렴하니까 위키가 계속 살아있을 수 있어요.
Karpathy는 이 아이디어를 Vannevar Bush의 Memex(1945)와 연결합니다. Bush가 상상했던 건 개인이 큐레이션한 지식 저장소 — 문서 간 연상 연결고리가 문서 자체만큼 중요한 시스템이었습니다. 그가 해결하지 못한 문제는 “누가 유지보수를 하느냐”였고, LLM이 그 답이 됩니다.
직접 써보는 방법
Gist 자체가 “idea file”로 설계되어 있습니다. 파일 내용을 Claude Code, Codex, 또는 OpenCode 같은 코딩 에이전트에 그대로 붙여넣으면 에이전트가 여러분의 도메인에 맞는 구체적인 구현을 함께 만들어줍니다.
Gist가 공개된 이후 한 달 사이에 커뮤니티에서 여러 파생 구현이 나왔습니다:
- llmwiki-cli — 에이전트가 읽고 쓸 마크다운 파일 시스템을 관리하는 CLI. LLM API 호출 없이 순수하게 파일 매니저 역할만 담당
- VLM-wiki — 텍스트뿐 아니라 사진·영상도 처리하도록 멀티모달로 확장한 버전
- llm-wiki-studio — 원본 검색 레이어와 wiki 레이어를 결합한 하이브리드 접근
패턴 자체가 워낙 단순해서 — 마크다운 파일 + 설정 파일 하나 — 도메인에 맞게 손쉽게 변형할 수 있다는 게 장점입니다.
저도 이 패턴으로 직접 뭔가 만들어볼까 생각 중입니다. 어떤 도메인에 적용하면 좋을지, 어떤 스택으로 시작할지는 다음 글에서 의논해볼게요.
참고 자료