카파시의 LLM Wiki — AI를 검색기가 아니라 '쉬지 않는 편집자'로

테슬라 전 AI 디렉터이자 OpenAI 창립 멤버인 안드레이 카파시(Andrej Karpathy)가 짧은 메모 하나를 공개했습니다. 개인 지식 베이스를 LLM으로 관리하는 방법인데, 공개 하루 만에 조회수가 수백만을 넘길 만큼 반응이 컸습니다. 내용을 한 문장으로 줄이면 이렇습니다.

AI를 그때그때 찾아보는 검색기가 아니라, 지식을 계속 쌓고 정리하는 “쉬지 않는 편집자”로 쓴다.

이 글은 네 가지를 답합니다. 어떻게 동작하는지(이게 중심입니다), 왜 나왔는지, 무엇이 좋은지, 어떻게 운영하는지. 먼저 전체 구조를 한 장으로 보겠습니다.

LLM Wiki의 3계층 구조 — raw 원본, LLM 에이전트, wiki 정리본, 그리고 이를 다스리는 schema

원본 자료(raw)는 손대지 않고, LLM이 그걸 읽어 정리본(wiki)을 계속 고쳐 씁니다. 이 분리가 전부의 출발점입니다. 하나씩 풀어 보겠습니다.

1. 왜 LLM Wiki인가 — 풀려던 문제

개인 지식 관리(PKM)는 늘 같은 자리에서 실패합니다. 노트 앱에 스크랩과 메모는 계속 쌓이는데, 정작 그것들이 서로 연결되고 최신으로 유지되지는 않습니다. 한 달만 지나면 내가 뭘 저장했는지도 모릅니다.

카파시가 짚은 핵심은 이겁니다. 지식 베이스에서 정말 지루한 일은 읽기나 생각이 아니라 bookkeeping, 즉 정리하고, 연결하고, 갱신하고, 모순을 찾아내는 손품이라는 것. 사람은 이 손품에 금방 지칩니다. 그래서 위키는 방치되고, 노트는 무덤이 됩니다.

그럼 요즘 흔한 RAG는 어떨까요. RAG는 질문이 들어올 때마다 원본 문서를 임베딩으로 뒤져 관련 조각을 꺼내고, 그 자리에서 답을 합성합니다. 문제는 그렇게 만든 답을 매번 버린다는 점입니다. 같은 질문을 다시 하면 처음부터 또 발굴합니다. 지식이 누적되지 않습니다.

정리하면 세 가지 한계입니다.

개인 노트: 자료는 쌓이지만 연결과 갱신이 안 된다.
RAG: 매번 원본에서 다시 발굴하고, 결과를 버린다.
기존 위키: 유지보수가 통째로 사람 몫이라 금방 방치된다.

세 한계의 공통 원인은 하나입니다. 정리와 유지라는 지루한 일을 떠맡을 주체가 없다. LLM Wiki는 그 자리에 LLM을 앉힙니다.

2. 한 줄 아이디어 — 컴파일된 지식

LLM Wiki의 발상은 “derived(매번 유도)“를 “compiled(한 번 컴파일)“로 바꾸는 것입니다. RAG가 매 질문마다 원본에서 답을 새로 유도한다면, LLM Wiki는 지식을 미리 한 번 정리해 두고 그걸 꺼내 씁니다.

카파시는 이를 소프트웨어 빌드에 그대로 빗댑니다.

컴파일러로 본 LLM Wiki — raw는 소스 코드, LLM은 컴파일러, wiki는 실행 파일, lint는 테스트, query는 런타임

raw 원본 = 소스 코드. 사람이 모아 둔 원문, 절대 고치지 않는 진실의 출처.
LLM 에이전트 = 컴파일러. 소스를 읽어 산출물로 바꾸는 변환기.
wiki 정리본 = 실행 파일. 바로 꺼내 쓸 수 있는, 서로 링크된 결과물.
lint = 테스트. 모순, 끊긴 링크, 낡은 정보처럼 깨진 곳을 잡아냅니다.
query = 런타임. 실제 질문에 답하는 실행 단계.

한 번 컴파일해 두면, 질문은 “원본에서 다시 발굴”이 아니라 “이미 정리된 것을 실행”이 됩니다. 이 한 줄이 나머지 전부를 끌고 갑니다.

3. 어떻게 동작하는가 — 3계층 구조

맨 위에서 본 구조 그림으로 돌아갑니다. LLM Wiki는 세 계층으로 나뉩니다.

raw/ — 불변의 원본. 논문 PDF, 스크랩한 글, 내 메모, 이미지가 들어갑니다. LLM은 이 폴더를 읽기만 하고 절대 수정하지 않습니다. 그래야 “원본이 무엇이었나”가 늘 그대로 보존됩니다. 진실의 출처(source of truth)입니다.

wiki/ — LLM이 쓰고 유지하는 정리본. 전부 마크다운이고, 서로 [[위키링크]]로 엮입니다. 폴더 구성은 대략 이렇습니다.

index.md — 모든 페이지의 목록과 한 줄 요약. 질문할 때 LLM이 가장 먼저 읽는 지도.
log.md — 언제 무엇을 했는지 기록.
entities/ — 사람, 사물처럼 개체 단위 페이지.
concepts/ — 개념과 주제별 페이지.
comparisons/ — 둘 이상을 견주는 비교 분석.
synthesis/ — 여러 자료를 묶어 낸 종합 페이지.

schema — 규칙. 페이지 형식(프론트매터 필수 등), 모순을 어떻게 표기할지, 자료를 넣을 때 어떤 순서로 처리할지 같은 작업 흐름을 정의합니다. 에이전트가 읽는 규칙 파일 한 장이 이 역할을 합니다(Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md). 위 두 계층은 이 규칙을 따라 움직입니다.

핵심은 raw와 wiki를 갈라 둔 것입니다. 원본은 버전관리되는 불변 자료, 위키는 계속 고쳐 쓰는 living document. 이 둘을 섞지 않기 때문에, 위키가 틀렸어도 언제든 원본으로 되짚어 고칠 수 있습니다.

4. 세 가지 동작 — Ingest, Query, Lint

구조가 정해지면, 그 위에서 도는 동작은 세 가지뿐입니다.

LLM Wiki의 세 가지 동작 — 자료를 넣는 Ingest, 질문하는 Query, 점검하는 Lint

Ingest(자료 추가) 가 가장 중요한 동작입니다. 새 자료를 위키에 “녹여 넣는” 일인데, 한 번의 Ingest가 페이지 하나만 건드리는 게 아닙니다.

자료 한 편이 위키로 퍼지는 과정 — 투입, 추출, 10~15개 페이지 동시 갱신, log 기록

논문 한 편을 넣으면 LLM은 핵심 주장과 등장 개념을 뽑아낸 뒤, 관련된 10~15개 페이지를 한꺼번에 손봅니다. 새 개체 페이지를 만들고, 기존 개념 페이지를 개정하고, 서로 링크를 잇고, 기존 내용과 어긋나면 모순으로 표시합니다. 예를 들어 “A 저자는 X라 했는데, 이 논문은 Y라고 한다”를 양쪽 원본 인용과 함께 남기고, 어느 쪽이 맞는지는 사람이 판단하도록 넘깁니다. 마지막으로 log.md에 무엇을 바꿨는지 기록합니다. 사람이 15개 파일을 일관되게 고치는 건 고역이지만, LLM은 군말 없이 합니다.

Query(질문) 는 index.md로 관련 페이지를 찾아, 이미 정리되고 링크된 내용을 읽어 종합한 뒤 인용을 달아 답합니다. 그리고 좋은 답은 다시 새 위키 페이지로 저장합니다. 좋은 분석 하나가 영구 자산이 되고, 다음 질문은 더 싸집니다.

Lint(건강 점검) 는 위키가 썩지 않도록 검사합니다. 서로 어긋나는 진술(모순), 아무도 링크하지 않은 페이지(고아), 오래된 정보(낡음), 언급은 되는데 페이지가 없는 항목(누락), 존재하지 않는 페이지를 가리키는 깨진 링크를 찾아 고치자고 제안합니다.

5. RAG와 무엇이 다른가

여기까지 보면 “그거 RAG랑 비슷한 거 아냐?”는 의문이 들 수 있습니다. 결정적으로 다릅니다.

RAG vs LLM Wiki — 매번 발굴하느냐, 한 번 정리해 두고 쓰느냐

RAG는 질문마다 원본을 임베딩으로 검색하고, 조각을 모아 그 자리에서 합성하고, 답을 내고는 결과를 버립니다. 다음 질문이 오면 처음부터 다시 합니다. 매번 “원본에서 발굴”입니다.

LLM Wiki는 그 합성을 미리, 한 번 해 둡니다. 질문이 오면 이미 정리되고 링크된 페이지를 읽기만 하면 됩니다. 모순도 이미 표시돼 있습니다. 매번 “이미 정리된 것 활용”입니다. 그래서 지식이 복리로 쌓입니다.

다만 둘은 대립이 아니라 보완 관계입니다. 위키가 커지면 그 안에서 페이지를 찾을 때 RAG식 검색을 써도 됩니다. 차이는 “검색을 쓰느냐”가 아니라 “합성 결과를 버리느냐, 남겨서 쌓느냐” 에 있습니다.

6. 무엇이 유용한가

지식이 복리로 쌓인다. 한 번 정리한 분석이 사라지지 않고, 다음 질문의 출발점이 됩니다.
유지보수 비용이 거의 0이다. 사람은 15개 파일 동시 갱신에 지치지만, LLM은 지루함을 모릅니다. 정리, 연결, 모순 점검 같은 손품이 LLM에게는 같은 비용입니다.
모순과 일관성이 자동으로 관리된다. 새 자료가 기존과 부딪히면 그 자리에서 표시되니, 어긋남을 나중에 우연히 발견하는 일이 줄어듭니다.
좋은 질문의 답이 자산이 된다. Query 결과를 페이지로 남기는 순간, 한 번의 고민이 두고두고 재사용됩니다.

요약하면 읽고 판단하는 일은 사람이, 정리하고 유지하는 일은 LLM이 맡는 분업입니다.

7. 직접 만들고 운영하기

카파시의 메모는 완성된 제품이 아니라 에이전트에게 복사해 붙여 넣는 “아이디어 파일” 입니다. Claude Code나 Codex 같은 에이전트에 건네면, 세부는 에이전트가 나와 함께 만들어 갑니다. 실제 셋업은 대략 이렇습니다.

도구 스택

LLM 에이전트: 파일을 직접 읽고 쓰는 코딩 에이전트면 됩니다 — Claude Code, Codex, OpenCode, Pi 등. 카파시 본인은 Claude Code를 썼지만, 이 패턴은 특정 도구에 묶이지 않습니다.
뷰어/편집기: Obsidian. 마크다운을 그래프로 보여 줘서 지식 연결이 한눈에 들어옵니다. 웹 클리퍼로 글을 raw에 담기도 좋습니다.
선택: 버전관리용 git, 마크다운 검색용 qmd 같은 CLI.

부트스트랩

raw/, wiki/, 그리고 규칙을 담을 CLAUDE.md(schema)를 만듭니다.
카파시의 아이디어 파일을 schema에 붙여 넣고, 내 주제에 맞게 폴더 규칙과 모순 표기 방식을 손봅니다.
첫 자료 몇 개를 raw/에 넣고 “Ingest 해 줘”라고 시켜, 위키가 어떻게 만들어지는지 확인합니다.

운영 루틴

정기 Ingest: 읽은 글, 받은 자료를 그때그때 raw에 넣고 위키에 녹입니다.
주기적 Lint: 가끔 “건강 점검 해 줘”로 모순과 고아 페이지를 청소합니다.
모순 리뷰: LLM이 표시한 모순은 사람이 직접 판단해 정리합니다.

사람의 몫은 분명합니다. 무엇을 넣을지 고르고(큐레이션), 무엇을 물을지 정하고(질문), 모순 앞에서 무엇이 맞는지 판단하는 일(검토)은 사람이 합니다. 그 사이의 손품만 LLM에게 넘깁니다.

8. 한계와 주의점

잘못된 통합 위험. LLM이 자료를 녹이다 사실을 비틀 수 있습니다. 그래서 schema에 원본 직접 인용을 강제해, 위키의 모든 주장이 raw로 되짚어지게 만드는 것이 중요합니다.
사람 검토 없이는 신뢰가 무너진다. 모순 판단, 종합의 타당성은 결국 사람이 봐야 합니다. 자동화는 손품까지입니다.
규모가 커지면 탐색 전략이 필요하다. 페이지가 수백 장이 되면 index.md만으로는 부족해지고, 검색 보조가 필요해집니다.
모든 지식에 맞지는 않는다. 개념과 개체가 또렷하고 서로 엮이는 주제에 강하고, 단발성 사실이나 빠르게 휘발되는 정보에는 과합니다.

9. 더 큰 그림

이 발상은 새것이 아닙니다. 1945년 배니바 부시(Vannevar Bush)가 그린 Memex, 즉 자료를 서로 연결해 생각의 길을 남기는 개인용 기계의 꿈을 LLM 시대에 와서야 실제로 굴릴 수 있게 된 것에 가깝습니다. 그동안 막혔던 지점은 늘 똑같았습니다. 연결하고 유지하는 손품을 아무도 떠맡지 않았다.

LLM은 그 손품을 지치지 않고 합니다. 그래서 “세컨드 브레인”이라는 오래된 약속이 이번에는 방치되지 않을 가능성이 생겼습니다. 다음 단계는 팀 단위 위키, 나아가 에이전트가 스스로 굴리며 사람은 방향만 주는 지식 베이스일 것입니다.

마무리

LLM Wiki의 핵심은 도구가 아니라 태도의 전환입니다. AI를 답을 꺼내 쓰고 버리는 검색기로 두지 말고, 내 지식을 대신 쌓고 정리하는 편집자로 두자는 것. raw와 wiki를 가르고, Ingest, Query, Lint 세 동작을 돌리는 단순한 틀 하나면 시작할 수 있습니다.

raw/, wiki/, CLAUDE.md 세 폴더를 만들고, 오늘 읽은 글 한 편을 넣어 “Ingest 해 줘”라고 말해 보는 것. 거기서부터입니다.