🔥 Karpathy의 LLM Wiki, RAG 없이 지식을 쌓는 새로운 방법

4월 3일, Karpathy의 트윗 하나가 타임라인을 뒤집었다. "최근 토큰 처리량의 상당 부분이 코드가 아니라 지식 쪽으로 가고 있다." 1600만 뷰를 넘긴 이 트윗을 보고 나는 하던 작업을 멈췄다. Karpathy가 코딩을 줄였다고? 그래서 뭘 하고 있는 건데?

다음 날 올라온 GitHub Gist를 열었다. "LLM Wiki"라는 제목이 붙은, 의외로 짧은 마크다운 파일이었다.

Karpathy가 코드 대신 지식을 컴파일하기 시작했다

Karpathy가 공개한 건 라이브러리도 프레임워크도 아니었다. "아이디어 파일"이라고 스스로 말했다. LLM 에이전트에 복사해서 붙여넣으라고 설계된 패턴 문서. Claude Code든 OpenAI Codex든, 어떤 에이전트에도 적용할 수 있는 구조다.

핵심은 이렇다. 원본 자료(논문, 기사, 데이터셋 등)를 디렉토리에 넣으면, LLM이 그걸 읽고 마크다운 위키로 정리한다. 요약 페이지를 만들고, 개체(entity) 페이지를 생성하고, 개념 간 교차 참조를 걸고, 인덱스를 업데이트한다. 사람은 자료를 넣고 질문을 던질 뿐이다. 위키의 모든 글자를 LLM이 쓴다.

규모를 보면 감이 온다. 단일 연구 주제 하나에 소스 약 100편을 넣었더니, 수백 페이지 분량의 상호 연결된 위키가 만들어졌다. Karpathy 본인은 위키를 직접 쓰는 일이 거의 없었다고 한다.

아키텍처는 세 층이다. 첫째, 원본 소스를 보관하는 raw/ 디렉토리. 불변(immutable)이다. LLM은 읽기만 한다. 둘째, LLM이 전적으로 소유하는 위키 디렉토리. 마크다운 파일들의 모음이다. 셋째, 스키마 문서(CLAUDE.md 같은 것)로, 위키의 구조 규칙과 워크플로를 정의한다. 이 스키마를 사람과 LLM이 함께 발전시켜 나간다.

운영 모드도 간결하다. Ingest(자료 투입), Query(질문), Lint(정합성 점검). 자료를 넣으면 LLM이 10~15개 페이지를 한 번에 업데이트한다. 질문에 대한 좋은 답변이 나오면 그것도 위키에 다시 넣는다. 지식이 복리처럼 쌓인다.

RAG가 매번 처음부터 생각하는 이유

이 패턴이 나온 데는 RAG(Retrieval-Augmented Generation)에 대한 구체적인 불만이 있다.

대부분의 LLM 지식 관리 경험은 RAG처럼 생겼다. 파일을 올리면 벡터 DB에 청크로 쪼개져 저장되고, 질문할 때마다 관련 조각을 찾아서 답을 생성한다. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이 방식이다.

문제는 축적이 없다는 것이다. 다섯 개 문서를 종합해야 답할 수 있는 미묘한 질문을 던져보자. RAG는 매번 관련 조각을 찾고, 모순을 발견하고, 맥락을 조립하고, 형식을 맞추는 작업을 처음부터 반복한다. Karpathy는 이걸 "합성 비용(synthesis tax)"이라 부르지 않았지만, 커뮤니티가 그렇게 이름 붙였다. 같은 복잡한 질문을 세 번 하면, 그 비용을 세 번 지불한다.

LLM Wiki는 이 비용을 한 번만 낸다. 자료를 투입하는 시점에 종합이 일어난다. 교차 참조는 이미 만들어져 있다. 모순은 이미 표시돼 있다. 새 자료가 들어오면 기존 종합에 통합된다. 매번 날것의 조각에서 시작하는 게 아니라, 이미 정리된 지식 위에서 시작한다.

다만, 위키 전체가 컨텍스트 윈도우에 들어가야 한다. 개인 규모에서는 문제없지만 수천 개 문서를 다루는 엔터프라이즈에서는 RAG가 여전히 답이다. 커뮤니티 분석에 따르면 대략 수만 토큰 규모 아래에서 LLM Wiki가 빛나고, 그 위로는 RAG의 확장성이 이긴다. 둘 중 하나를 고르는 문제가 아니라, 규모에 따른 도구 선택이다.

커뮤니티 반응도 이 점을 정확히 갈랐다. 엔지니어링 트위터의 절반은 "RAG에 단계만 추가한 것 아니냐"고 했고, 나머지 절반은 바로 구현에 들어갔다. 한 연구팀은 이 패턴을 연구 파이프라인 전체의 허브로 확장한 ΩmegaWiki를 만들었고, rohitg00이라는 개발자는 agentmemory 엔진의 교훈을 결합한 LLM Wiki v2를 공개했다.

Memex에서 LLM Wiki까지, 80년의 거리

Karpathy 본인이 글 말미에 Vannevar Bush의 Memex(1945)를 언급한 건 우연이 아닐 것이다.

1945년 7월, Bush는 The Atlantic에 "As We May Think"라는 에세이를 실었다. 2차 세계대전이 끝나가던 시점이었다. 그가 상상한 Memex는 개인의 모든 책, 기록, 통신을 저장하고, "극도의 속도와 유연성으로 검색할 수 있는" 전자기계식 장치였다. 핵심은 문서 사이의 "연상 경로(associative trails)"를 만들어 연결하는 것이었다.

이 에세이가 Douglas Engelbart에게 영감을 줬고, Ted Nelson이 1965년 "하이퍼텍스트"라는 용어를 만들 때도 Memex를 긴 분량으로 인용했다. 웹의 사상적 기원이라 할 수 있다.

그런데 웹은 Bush의 비전과 다른 방향으로 갔다. Bush가 상상한 건 개인적이고, 능동적으로 큐레이션되며, 문서 사이의 연결이 문서 자체만큼 가치 있는 시스템이었다. 웹은 공개적이고, 방대하고, 연결의 질보다 양을 택했다.

Karpathy가 짚어낸 한 문장이 계속 머릿속에 남는다. "Bush가 풀지 못한 건 누가 유지보수를 하느냐였다." 개인 지식 베이스가 실패하는 이유는 구축이 어려워서가 아니다. 유지가 어려워서다. 교차 참조를 업데이트하고, 새 정보가 기존 주장과 충돌하는지 확인하고, 수십 개 페이지의 일관성을 유지하는 작업. 사람은 그 유지보수 부담이 가치보다 빨리 커지니까 포기한다.

LLM은 지루해하지 않는다. 교차 참조 업데이트를 빼먹지 않는다. 한 번의 패스로 15개 파일을 건드릴 수 있다. 유지보수 비용이 거의 0에 수렴하니까, 위키가 실제로 유지된다.

80년 전 Bush가 꿈꿨던 그 시스템이, 유지보수 담당자가 LLM으로 바뀌면서 드디어 작동하기 시작한 것이다.

이번 주말에 만들어보려 한다

솔직히 이 글을 읽고 가장 먼저 든 생각은 "나도 해봐야겠다"였다.

내가 매일 쓰는 도구가 이미 이 패턴에 가깝기 때문이다. Obsidian에서 마크다운을 쓰고, Claude Code로 작업하고, qmd로 로컬 검색을 돌린다. Karpathy가 추천하는 도구 셋과 거의 겹친다. qmd는 Shopify 창업자 Tobi Lütke가 만든 로컬 마크다운 검색 엔진으로, BM25 풀텍스트 검색과 벡터 시맨틱 검색, LLM 리랭킹을 모두 로컬에서 처리한다. 외부 API 호출 없이 SQLite 하나로 동작한다.

Karpathy의 패턴에서 내가 가장 마음에 드는 부분은 "좋은 답변을 위키에 다시 넣는다"는 아이디어다. 질문에서 나온 분석, 비교, 발견한 연결고리가 채팅 히스토리에서 사라지지 않고 지식으로 남는다. 탐구 자체가 지식 베이스를 키우는 행위가 된다.

아직 프로덕션 규모에서 이게 작동할 거라는 확신은 없다. 컨텍스트 윈도우가 커지고 있다고 해도 한계는 존재하고, 인덱스 파일 기반 탐색이 수백 개 페이지에서도 버틸 수 있을지 모르겠다. Karpathy가 "~100 소스, ~수백 페이지"에서 잘 작동한다고 했으니 그 규모까지는 검증된 셈인데, 그 너머는 아직 미지수다.

그래도 이건 시도해볼 가치가 있다. 지금 진행 중인 사이드 프로젝트의 리서치 노트를 이 패턴으로 정리해볼 생각이다. 원본 논문과 기사를 raw/에 넣고, CLAUDE.md에 스키마를 정의하고, Claude Code에게 위키를 맡기는 것부터 시작하면 된다. Bush가 80년 전에 꿈꿨던 걸, 마크다운 파일 몇 개와 LLM 하나로 실험해볼 수 있다니. 살기 좋은 시대다.