100개 문서, 40만 단어 — 직접 쓴 건 한 줄도 없다

2026년 4월 3일, Andrej Karpathy가 X에 올린 한 포스트가 1,200만 조회를 기록했다. 내용은 단순했다: “RAG 대신 LLM에게 위키를 쓰게 하라.” GitHub Gist는 5,000 스타를 넘겼고, 일주일 만에 9개 이상의 오픈소스 구현체가 등장했다.

Karpathy 자신은 100개 기사에서 40만 단어 분량의 위키를 구축했다. 물론 40만 단어 전체를 한 번에 컨텍스트에 넣는 것이 아니다. LLM이 소스를 읽을 때마다 기존 위키 페이지에 정보를 통합하고, 질문 시에는 관련 페이지만 참조하는 구조다. 위키 전체가 아닌 관련 부분만 로드하기 때문에 컨텍스트 윈도우를 넘어서는 규모도 운영 가능하다.

무슨 아이디어가 이런 반응을 이끌어냈을까?

RAG의 진짜 문제

RAG(Retrieval Augmented Generation)는 대규모 문서에서 관련 정보를 검색해 LLM에 주입하는 방식이다. 작동은 한다. 하지만 실전에서 계속 부딪히는 문제가 있다:

• 매번 처음부터: 같은 질문을 해도 매번 벡터 검색부터 다시 시작한다. 이전에 정리한 지식이 축적되지 않는다
• 단편화: 검색된 청크들이 서로 맥락 없이 조합된다. “이 개념과 저 개념이 어떻게 연결되는지”를 알 수 없다
• 블랙박스 벡터: 임베딩이 왜 그 문서를 가져왔는지 설명할 수 없다
• 인프라 복잡도: 벡터 DB, 임베딩 모델, 청킹 전략, 리랭킹 — 파이프라인이 길어진다

2026년 기준으로 엔터프라이즈 AI 프로젝트 65%가 “컨텍스트 드리프트”와 “메모리 손실”로 실패한다는 데이터가 있다. RAG가 해결하지 못하는 영역이다.

LLM Wiki 패턴이란

Karpathy의 제안은 발상의 전환이다:

“Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스”

LLM이 새 자료를 읽을 때마다 구조화된 마크다운 위키를 점진적으로 구축하고 유지한다. 검색이 아니라 사전 통합이다.

3계층 구조

핵심 오퍼레이션 3가지

ingest — 새 소스를 읽고 관련 위키 페이지에 정보를 통합한다. 소스 하나당 평균 10~15개 페이지가 업데이트된다.

query — 위키를 검색해 질문에 답변한다. 답변 과정에서 새로운 지식이 생기면 페이지로 저장한다.

lint — 모순, 오래된 정보, 고아 페이지, 누락된 상호 참조를 점검한다.

RAG vs LLM Wiki vs GraphRAG

결론: 규모가 작고 지식의 깊이가 중요한 경우 LLM Wiki. 대용량 + 소스 어트리뷰션이 필수인 경우 RAG. 현실적으로는 하이브리드(시스템 프롬프트에 LLM Wiki + RAG로 동적 콘텐츠)가 가장 많이 쓰인다.

솔직한 한계: RAG에는 없는 리스크

LLM Wiki가 장점만 있는 건 아니다. RAG와 비교해 고유한 리스크가 있다:

환각의 전파

RAG는 매번 원본을 검색하므로 “신선한” 추론을 한다. 반면 LLM Wiki는 위키에 한 번 오류가 섞이면 이후 모든 query가 오염된 정보를 기반으로 작동한다. lint 단계에서 소스 대조(Source Grounding)를 주기적으로 수행해야 하는 이유다.

Write 토큰 비용

RAG는 Read 위주다. 검색만 하면 된다. LLM Wiki는 소스를 읽을 때마다 위키 페이지를 업데이트(Write)한다. 빈번한 업데이트가 발생하는 환경에서는 API 비용이 RAG보다 높을 수 있다.

Lost in the Middle

마크다운 구조라 해도 컨텍스트가 10만 토큰에 가까워지면 LLM의 “중간 부분 망각” 현상이 발생한다. 이 때문에 위키를 계층적으로 분리하고 관련 페이지만 선택적으로 로드하는 설계가 필수다.

v2 확장: 신뢰도 점수와 타입드 엔티티

rohitg00의 agentmemory 프로젝트에서 시작된 v2 확장이 주목할 만하다:

신뢰도 점수

모든 사실에 메타데이터를 붙인다:

• 소스 수: 몇 개의 독립 출처가 확인했는가
• 마지막 확인 날짜: 언제 마지막으로 검증되었는가
• 모순 여부: 상충하는 정보가 있는가

시간이 지나면 점수가 감쇠하고, 새 소스가 확인하면 강화된다. “이 정보를 얼마나 신뢰할 수 있는가”를 정량화하는 것이다.

타입드 엔티티 추출

ingest 시 단순 텍스트가 아니라 people, projects, libraries, concepts, decisions를 타입·속성·관계로 구조적으로 추출한다. 마크다운 위에 지식 그래프 레이어를 올리는 셈이다.

구현체 생태계: 9개 프로젝트 비교

Karpathy의 제안 이후 일주일 만에 다양한 철학의 구현체들이 등장했다:

어떤 걸 선택할까

• 대규모 코드베이스: graphify — AST 기반 증분 추출로 전문 주입 대비 71.5배 토큰 절감
• 학술·연구: sage-wiki 또는 quicky-wiki — 엄격한 파싱과 신뢰도 추적
• 팀 협업: nvk-llm-wiki, wiki-skills — Claude Code 통합
• 멀티 LLM: llm-wiki-agent — 프로바이더 자유롭게 전환
• 빠른 시작: wiki-skills — 모듈식, 설정 최소

실전 적용 팁

직접 LLM Wiki를 운영하면서 얻은 교훈:

1. Schema-first로 시작하라

위키를 만들기 전에 구조를 먼저 정의하라. 페이지 타입(topic, entity, project), 필수 섹션, 태그 체계를 schema 파일에 명시한다. LLM은 구조가 명확할수록 일관된 결과를 낸다.

2. Raw 소스는 절대 수정하지 마라

원본 자료는 불변이다. 위키 페이지가 원본을 참조하되, 원본 자체를 편집하면 출처 추적이 불가능해진다.

3. 크기 경계를 인식하라

LLM Wiki는 ~10만 토큰까지 효율적이다. 이를 넘어가면 RAG와 하이브리드로 전환해야 한다. 시스템 프롬프트에 위키 핵심 지식을 넣고, RAG로 동적 콘텐츠를 보완하는 구조가 프로덕션에서 가장 현실적이다.

4. 주기적으로 lint하라

위키가 커질수록 모순과 누락이 생긴다. 정기적인 lint로 비일관성, 고아 페이지, 새로운 연결을 탐지한다.

누가 주목해야 하나

• AI 에이전트 개발자: 에이전트에 장기 메모리를 부여하고 싶다면 LLM Wiki가 가장 가벼운 시작점이다
• 개인 지식 관리자: Obsidian이나 Logseq 사용자라면 기존 vault에 바로 적용 가능하다
• 소규모 팀: RAG 인프라 구축 전에 마크다운 위키로 충분한지 먼저 검토할 가치가 있다
• 리서치 엔지니어: 논문·아티클을 쏟아넣고 자동 정리되는 지식 베이스가 필요하다면

참고 자료

• Karpathy 원본 Gist — 원본 제안과 토론
• LLM Wiki v2 (agentmemory) — 신뢰도 점수, 타입드 엔티티 확장
• VentureBeat 기사 — 생태계 개요

관련 글

• LLM이 읽고 쓰는 Obsidian vault 설계 (1편) — Karpathy LLM Wiki 패턴 적용기
• Ollama를 멈춰야 할 이유와 2026년 로컬 LLM 대안 가이드
• 2026 오픈소스 위기론: Cal.com 클로즈드 전환과 Strix 반박 해부