Karpathy LLM Wiki

한 줄 요약: 질문할 때마다 원본에서 다시 찾는 RAG 대신, LLM 에이전트가 원본을 읽어 마크다운 위키를 계속 쌓고 고쳐 나가게 하면 지식이 복리로 누적된다는 패턴 설명서.

원본 정보#

원본 파일: karpathy-llm-wiki
제목: LLM Wiki — "A pattern for building personal knowledge bases using LLMs"
저자: Andrej Karpathy (파일 이름과 이 위키 스키마 CLAUDE.md에 적힌 출처 기준. 원본 본문에는 저자 이름이 없다)
URL: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f (새 창) (스키마 CLAUDE.md 기준)
작성일: 원본 날짜 미상. 수집일 2026-10-16
성격: 구현 명세가 아니라 "아이디어 파일"이다. 자기 LLM 에이전트(OpenAI Codex, Claude Code, OpenCode / Pi 등)에 그대로 붙여 넣고, 세부 구현은 에이전트와 함께 만들어 가라고 쓴 글이다.

RAG는 축적이 없다. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG는 질문할 때마다 조각을 다시 찾아 짜 맞춘다. LLM Wiki는 지식을 한 번 정리(compile)해 두고 계속 최신으로 유지한다. → LLM Wiki
3개 레이어로 나눈다. 수정하지 않는 원본(raw), LLM이 전부 쓰고 고치는 위키, 구조와 워크플로를 정한 스키마(Claude Code의 CLAUDE.md, Codex의 AGENTS.md). 스키마가 LLM을 "범용 챗봇"이 아니라 "규율 있는 위키 관리자"로 만든다. → 스키마 파일
작업은 수집·질의·점검 세 가지다. 자료 하나가 위키 10~15개 페이지를 건드릴 수 있고, 좋은 질의 답변은 다시 위키 페이지로 저장한다. → LLM Wiki 수집(Ingest), LLM Wiki 질의(Query), LLM Wiki 점검(Lint)
index.md와 log.md 두 파일로 길을 찾는다. index는 내용 카탈로그, log는 시간순 기록이다. 저자는 중간 규모(원본 약 100개, 페이지 수백 개)에서도 index만으로 임베딩 기반 RAG 없이 "놀랄 만큼 잘 돌아간다"고 예를 든다. 상한이나 전환점을 말한 것은 아니다. → index·log 운영
이 방식이 버티는 이유는 유지비가 거의 0이기 때문이다. 사람이 위키를 포기하는 건 유지 부담이 가치보다 빨리 커지기 때문인데, LLM은 지루해하지 않고 교차 참조를 잊지 않으며 한 번에 15개 파일을 고칠 수 있다.

자료 1건이 건드리는 위키 페이지: 10~15개
index만으로 잘 돌아간다고 저자가 예로 든 규모(moderate scale): 원본 약 100개, 페이지 수백 개
저자의 작업 환경: 한쪽에 LLM 에이전트, 다른 쪽에 Obsidian을 띄워 놓고 실시간으로 결과를 본다. "Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스"
적용 분야 예시: 개인(목표·건강·심리 기록), 리서치(수주~수개월 주제 심화), 책 읽기(챕터별로 인물·주제 페이지 구축, 예: Tolkien Gateway 같은 팬 위키), 업무·팀(Slack 스레드·회의록·고객 통화로 채우는 사내 위키), 경쟁 분석·실사·여행 계획·강의 노트
사상적 뿌리: Vannevar Bush의 Memex(1945). 문서 사이의 연결을 문서만큼 가치 있게 본 개인용 지식 저장소였지만, "누가 유지하는가"를 풀지 못했다. LLM이 그 몫을 맡는다.