LLM Wiki — RAG의 재발견 한계를 넘는 개인 지식베이스 패턴

· 5분 읽기
목차

Karpathy의 LLM Wiki 제안 — RAG의 stateless 한계를 넘어 LLM이 지속 구축하는 개인 위키 | 3계층 아키텍처와 핵심 오퍼레이션 | 10개 구현체 동향 | 손실 압축과 스케일 한계

LLM Wiki 개인 지식베이스 패턴 커버 이미지

RAG(Retrieval-Augmented Generation)는 LLM에 외부 지식을 연결하는 사실상의 표준이다. 그러나 RAG는 stateless다 — 매 질문마다 원문에서 재검색·재조합할 뿐, 이전 질문에서 얻은 통찰이 축적되지 않는다. 같은 논문을 세 번째 질문할 때도 처음부터 다시 읽는 구조다.

2026년 4월 Andrej Karpathy가 “LLM Wiki”라는 아이디어를 공개하면서 이 한계에 대한 대안이 제시됐다. LLM이 직접 마크다운 위키를 구축하고 유지보수하는 패턴이다. 아이디어 파일(구체적 구현이 아닌 패턴 제안)임에도 5000+ Star, HN 296포인트를 기록했고, 1개월 만에 10여 개 구현체가 등장했다.

이 글은 LLM Wiki가 기존 RAG와 어떻게 다른지, 어떤 아키텍처와 오퍼레이션으로 구성되는지, 2026년 5월 기준 구현체들이 각각 어떤 문제를 푸는지, 그리고 어떤 본질적 비판이 존재하는지를 정리한다.

RAG vs LLM Wiki — 관찰되는 차이

두 접근의 핵심 차이는 지식의 축적 여부다.

구분RAGLLM Wiki
지식 형태원문 chunk + 임베딩LLM이 생성한 구조화된 마크다운
질문 시 동작검색 → 재조합 → 답변위키 페이지 검색 → 시스와 함께 답변
축적 여부없음 (stateless)있음 (compounding artifact)
교차 참조매번 새로 계산이미 연결되어 있음
모순 탐지불가새 소스 추가 시 자동 플래깅
유지 비용없음LLM 토큰 비용 (ingest 시)

RAG는 “질문 → 검색 → 답변”의 일회성 파이프라인이다. 반면 LLM Wiki는 지식을 지속적으로 축적하는(compounding) 산출물이다. 좋은 질문과 답변도 새 위키 페이지로 저장되어, 탐색 자체가 지식으로 축적된다.

이 차이의 의미는 사용 패턴에 따라 달라진다. 동일한 문서 집합에 대해 반복적으로 질문하는 연구자에게는 축적이 가치 있지만, 일회성 조회가 대부분인 환경에서는 RAG의 stateless 특성이 오히려 간단하다.

3계층 아키텍처

flowchart TD
    subgraph Layer 1 - Raw Sources
        R1[논문/기사/PDF]
        R2[이미지/데이터]
        R3[웹 클립/트랜스크립트]
    end

    subgraph Layer 2 - Wiki
        W1[index.md<br/>콘텐츠 카탈로그]
        W2[엔티티 페이지<br/>인물/조직/개념]
        W3[개념 페이지<br/>비교/종합/분석]
        W4[log.md<br/>시간순 변경 기록]
    end

    subgraph Layer 3 - Schema
        S[CLAUDE.md / AGENTS.md<br/>구조/규약/워크플로 정의]
    end

    R1 -->|읽기 전용| W2
    R2 -->|읽기 전용| W2
    R3 -->|읽기 전용| W2
    W2 --> W1
    W3 --> W1
    S -->|LLM에 지시| W2
    S -->|LLM에 지시| W3

Karpathy가 제안한 구조는 세 계층으로 나뉜다.

Layer 1 — Raw Sources: 원본 소스. 불변(immutable). LLM은 읽기만 하고 수정하지 않는다. 논문, 기사, PDF, 웹 클립, 트랜스크립트 등이 해당한다.

Layer 2 — The Wiki: LLM이 소유하고 생성하고 유지보수하는 마크다운 파일들. 사용자는 읽기만 한다. 엔티티 페이지(인물/조직/개념), 개념 페이지(비교/종합/분석), index.md(콘텐츠 카탈로그), log.md(시간순 변경 기록)로 구성된다.

Layer 3 — The Schema: CLAUDE.md, AGENTS.md 같은 핵심 설정 파일. LLM이 “규율 있는 위키 관리자” 역할을 수행하도록 지시하는 계층이다. 사용자와 LLM이 공동으로 진화시킨다.

이 계층 분리의 핵심은 소유권 경계다. Raw는 불변이고, Wiki는 LLM 영역, Schema는 공동 영역이다. 이 경계가 없으면 LLM이 원본을 수정하거나, 사용자가 위키 구조를 임의로 변경하여 LLM의 일관성이 깨질 수 있다.

핵심 오퍼레이션

LLM Wiki는 세 가지 주요 오퍼레이션으로 동작한다.

Ingest — 소스 흡수

새 소스를 raw에 추가하면 LLM이 읽고 요약하여 위키 페이지를 생성하거나 업데이트한다. 하나의 소스가 10~15개 위키 페이지에 영향을 줄 수 있다. Karpathy는 한 번에 하나씩 처리하면서 사용자 개입을 선호한다고 밝혔다 — LLM Agent를 한 쪽에, Obsidian을 반대편에 열어두고 실시간으로 결과를 확인하는 워크플로다.

Query — 위키 기반 질의

위키를 대상으로 질문하면 LLM이 관련 페이지를 검색·조합하여 답변한다. 출처가 위키 페이지에 명시되어 있으므로 추적이 가능하다. 출력 형태는 마크다운, 비교 테이블, 슬라이드(Marp), 차트(matplotlib) 등 다양하다.

핵심은 좋은 질문과 답변도 새 위키 페이지로 저장된다는 점이다. 탐색이 지식으로 축적되는 구조다.

Lint — 건강 검진

주기적으로 모순, 유효하지 않은 주장, 고아 페이지, 빠진 교차 참조를 점검한다. 위키가 커질수록 중요해지는 오퍼레이션이다. LLM이 새로운 조사 질문이나 소스도 제안할 수 있다.

탐색 보조 파일로 index.md(콘텐츠 중심 카탈로그, ~100소스/수백 페이지 규모에서 잘 동작)와 log.md(시간순 변경 기록, ## [2026-04-02] ingest | Article Title 형식으로 unix 도구 파싱 가능)가 있다.

구현체 동향 (2026-05 기준)

Karpathy의 아이디어 파일 이후 1개월 만에 10여 개 구현체가 등장했다. 각각이 푸는 문제가 다르며, Star 수는 커뮤니티 관심도를 나타낼 뿐 프로덕션 검증을 의미하지는 않는다.

프로젝트핵심 차별점검증 수준적합 시나리오
Synthadoc v0.3.08개 LLM 프로바이더, YouTube 전사, CJK, MCP/Obsidian 플러그인활성 개발, 다국어 커뮤니티다국어·다소스 환경
llmwiki (1K+ Star)claim-level 출처(^[paper.md:42-58]), BM25 재순위, --review 승인 플로우출처 provenance 메커니즘 검증 가능규제 산업, 출처 추적 필수 환경
OmegaWiki (543+ Star)23개 Claude Code 스킬, 9개 typed entity/edge, 중영 이원언어Claude Code 생태계 통합Claude Code 사용자
SwarmVault v3.12그래프 병합, 비디오 ingest, Neo4j export, 대화형 채팅90+ 릴리즈, 가장 활발대규모 소스, 그래프 분석
OpenClerk신선도 상태 관리, doc_id/chunk_id 출처 계약, 평가 게이트평가 게이트 메커니즘엔터프라이즈급 검증
Eshel소프트웨어 엔지니어링 특화 (아키텍처/의사결정/기술부채)도메인 특화소프트웨어 팀
KeelmacOS 네이티브 앱, 로컬 우선, 모델 교체 가능로컬 퍼스트 철학개인 연구자
NEXUS6개 AI 에이전트 VPS, Weaviate + Ollama + Wiki.js자체 호스팅 인프라VPS 자체 운영 가능한 팀
LinkMCP 서버, 그래프 뷰, 대시보드, Homebrew 설치도구로서의 위키기존 도구 체인에 통합
SeekLink대규모 위키용 PATH:LINE 단위 라인 앵커 검색스케일 문제 직접 대응대규모 위키 (1000+ 페이지)

구현체 간의 계보를 관찰하면 세 가지 응답 방향이 보인다. 손실 압축 비판에는 llmwiki(claim-level 출처)와 OpenClerk(출처 계약)이 직접 응답한다. 스케일 한계에는 SeekLink(라인 앵커 검색)와 SwarmVault(Neo4j export)가 대응한다. 그리고 프로덕션 미해결 과제 중 로컬 퍼스트 요구에는 Keel(macOS 네이티브)이, 다중 LLM 환경에는 Synthadoc(8개 프로바이더)이 각각 접근한다.

비판적 시각

LLM Wiki 패턴에 대한 비판은 크게 세 가지 관점에서 관찰된다.

손실 압축 + 환각 위험

원문을 위키 페이지로 변환하는 과정에서 주의사항, 날짜, 소수 의견, 정확한 표현, 엣지 케이스가 누락될 수 있다. 위키를 원본 대신 조회하면 요약 오류가 지식 베이스의 일부가 된다. 여기에 LLM 환각(hallucination) 위험이 추가된다 — 그럴듯하지만 틀린 사실이 위키 페이지로 생성되면, 이후 질의에서도 해당 오류가 참으로 인용된다.

llmwiki의 claim-level 출처(^[paper.md:42-58])로 완화를 시도하고 있고, OpenClerk은 평가 게이트로 검증 단계를 추가한다. 근본적 한계는 남지만, 위키를 원본 대체가 아닌 “컴파일된 뷰”로 보는 관점이 실무적으로 유의미하다 — 원본은 Layer 1에 불변으로 남아 있으므로, 위키가 컴파일된 인덱스 역할을 하고 상세 조회는 원본으로 돌아가는 구조다.

스케일 한계

하나의 새 소스가 수많은 엔티티/개념/타임라인/인덱스에 영향을 미친다. 변경 감지, 충돌 해결, 중복 방지, provenance 보존, 고아 페이지 방지 등 그래프 유지보수 비용이 증가한다.

규모가 커지면 결국 검색/순위/인덱싱/재순위/청킹이 필요해진다. 이 지점에서 마크다운 위키는 또 하나의 인덱스된 코퍼스일 뿐이며, RAG가 해결하려 했던 것과 동일한 문제에 직면한다. SeekLink(PATH:LINE 단위 검색)가 이 문제에 직접 대응하려 시도 중이다.

프로덕션 미해결 과제

권한, 멀티유저 편집, 감사 로그, 롤백, 삭제, 민감 데이터, 동시성, 컴플라이언스, 비용 등 엔터프라이즈 요구사항이 미해결이다. 벤치마크, 태스크 정의, 스케일 커브, baselines 비교도 부재하다.

이 비판을 종합하면, LLM Wiki는 “소~중규모, 느리게 변하는, 개인 큐레이션 연구 폴더”에는 유용한 워크플로로 관찰된다. 대규모, 빠르게 변하는, 고위험, 멀티유저, 엔터프라이즈 지식베이스에는 아직 미흡하다. RAG를 대체하는 아키텍처라는 주장은 시기상조라는 평가가 있다.

출처

이어서 읽기