LLM Wiki

• **LLM 위키(LLM Wiki)**는 LLM 에이전트가 직접 읽고·쓰고·유지보수하는 영속적 마크다운 지식 베이스 (Andrej Karpathy가 2026년 4월 제안한 패턴)
• 세션이 끝나도 사라지지 않고 소스·질문마다 쌓여가는 복리형(compounding) 지식 구조
• 질의 시점마다 원문을 다시 검색하는 RAG와 달리, 지식을 미리 정리해 두는 선(先)합성(pre-compiled) 방식
• 개념·엔티티마다 한 장의 마크다운 페이지를 두고 [[wiki-link]]로 잇는 위키피디아형 지식 그래프
• 사람은 소스를 큐레이션하고 LLM이 정리 노동을 맡는 역할 분업(Humans curate, LLMs maintain) 시스템

해당 개념이 필요한 이유

• LLM은 매 질문마다 원문에서 지식을 “처음부터 다시 발견”함 → 축적이 전혀 없는 stateless 구조
• 컨텍스트 한계(context-limit reset) 때문에 세션 사이의 맥락이 매번 증발함
• RAG는 검색은 하지만 교차 참조·모순 정리·합성 결과를 보존하지 못함
• 지식 정리(bookkeeping)는 지루해서 사람이 결국 포기하는 작업 → LLM이 지치지 않고 대신 수행

AS-IS — RAG: 매 질의마다 원문 재검색·재합성

sequenceDiagram
    autonumber
    actor U as 사용자
    participant L as LLM
    participant V as 벡터DB (원문 청크)
    U->>L: 질문
    L->>V: 관련 청크 검색
    V-->>L: 원문 청크 반환
    L->>L: 매번 처음부터 재합성 (교차참조·모순정리 소실)
    L-->>U: 답변 — 지식은 휘발, 축적 없음

TO-BE — LLM Wiki: 한 번 컴파일하고 계속 최신 유지

sequenceDiagram
    autonumber
    actor U as 사용자
    participant L as LLM
    participant W as 위키 (컴파일된 마크다운)
    U->>L: 새 소스 추가 (ingest)
    L->>W: 엔티티/개념 페이지 갱신 + 교차링크 + 모순 표시
    Note over W: 합성이 질의 이전에 이미 완료됨
    U->>L: 질문 (query)
    L->>W: 이미 합성된 페이지 조회
    W-->>L: 선합성된 지식 + 인용
    L-->>U: 답변 — 좋은 답변은 다시 위키로 환원(복리 축적)

RAG vs LLM Wiki

관점	RAG	LLM Wiki
영속성	질의마다 stateless	세션을 넘어 영속
합성 시점	질의 시점마다 재검색	사전 컴파일된 관계
모순 감지	없음	컴파일 시 표시
지식 성장	축적 안 됨	소스·질문마다 복리 축적

Flow

사용자 질의 → 답변까지의 흐름을 비교하면, 참고하는 외부 지식이 갱신되느냐에서 결정적으로 갈린다.

RAG — 원문 소스는 불변이고, 매 질의가 같은 곳에서 처음부터 다시 시작한다. 종합 결과는 답변에만 남고 소스로 되돌아가지 않는다.

sequenceDiagram
    autonumber
    actor U as 사용자
    participant LLM as LLM
    participant VS as 벡터 스토어<br/>(원문 청크·불변)
    U->>LLM: 질의
    LLM->>VS: 검색 요청
    VS-->>LLM: top-k 청크 반환
    LLM->>LLM: 청크를 종합해 답변 생성
    LLM-->>U: 답변
    Note over LLM,VS: 합성 결과를 스토어에 기록하지 않음 ✗ (축적 없음)

LLM Wiki — 답변하며 발견·종합한 결과를 위키에 다시 기록(file back)한다. 그 결과 참고하는 위키 자체가 질의마다 좋아지고, 다음 질의는 더 풍부한 페이지를 읽는다(복리).

sequenceDiagram
    autonumber
    actor U as 사용자
    participant LLM as LLM
    participant W as 위키<br/>(정리된 지식)
    U->>LLM: 질의
    LLM->>W: 조회 요청
    W-->>LLM: 정리된 지식 반환
    LLM-->>U: 답변
    LLM->>W: 발견·종합 결과 기록
    Note over LLM,W: 위키가 점점 풍부해짐 ↑ (다음 질의는 더 나은 지식을 참고)

RAG는 왜 “보존하지 못”하나

RAG의 동작을 한 단계씩 보면 한계의 이유가 분명해진다.

1. 질문이 들어오면 그 질문을 벡터로 바꿔, 원문 청크 저장소에서 가장 비슷한 top-k 청크만 골라온다.
2. 그 청크들을 프롬프트에 붙여 LLM이 답을 생성한다.
3. 답이 끝나면 그 과정에서 일어난 모든 것(교차참조 발견·모순 지적·합성)은 그 한 번의 응답 안에만 남는다. 저장소는 여전히 원래 원문 청크 그대로다 — 아무것도 갱신되지 않는다.

즉 RAG의 “지식”은 언제나 가공되지 않은 원문 청크이고, LLM이 답변하며 만들어낸 통찰은 채팅 기록에 흩어질 뿐 저장소로 되돌아가 쌓이지 않는다. 그래서 다음 질문에서 LLM은 같은 원문에서 처음부터 다시 발견해야 한다(혹은 top-k에 안 걸리면 아예 놓친다).

추론 ≠ 학습 (흔한 오해)

• LLM은 추론 시점에 학습하지 않는다 — 가중치는 얼어 있고(frozen), 검색한 내용은 컨텍스트 윈도우에만 잠깐 올라왔다 세션이 끝나면 증발
• LLM 위키는 이 종합 결과를 마크다운으로 **외재화(externalize)**해 모델 밖에 영속시킴
• 그래서 위키가 쌓일수록 답이 좋아지는 이유는 모델이 똑똑해진 게 아니라, 참고하는 외부 지식이 더 좋아진 것 — “더 똑똑한 모델”이 아니라 “더 잘 정리된 참고서를 든 같은 모델”

구체 예 — 오사카 여행을 준비하며 블로그·후기 여러 개를 모아 “3월에 우산 챙겨야 해?”라고 물었을 때:

• RAG: 3월 날씨를 언급한 후기 몇 개를 검색 → LLM이 “후기 A는 비가 잦다고, 후기 C는 건조하다고 한다”며 엇갈림을 짚어 답한다. 하지만 이 “두 후기가 상충한다”는 발견은 그 답변에만 남고 저장소엔 흔적이 없다. 다음 날 “3월 옷차림은?”이라고 물으면 그 상충 정보는 사라져 다시 찾아야 한다.
• LLM Wiki: 후기들을 ingest할 때 LLM이 오사카-3월 페이지에 “⚠️ 강수 정보 상충: 후기 A(잦음) ↔ 후기 C(건조)“라고 직접 써 넣는다. 이 메모는 영구히 남아 이후 어떤 질문에서든 즉시 활용된다.

또한 RAG는 top-k 검색이라, 답에 필요한 정보가 여러 청크에 흩어져 있으면 일부만 떠올라 문서 간 합성이 불완전해지기 쉽다. LLM 위키는 이 문서 간 합성을 ingest 시점에 한 번 미리 해 두므로 질의 때 다시 조립할 필요가 없다.

3계층 아키텍처

• Raw sources (불변 원본) — 사용자가 큐레이션한 문서·논문·데이터. LLM이 절대 수정하지 않는 진실의 출처(source of truth)
• The wiki (LLM 소유 계층) — 요약·엔티티·개념·비교 페이지. “LLM이 이 계층을 전적으로 소유”하며 교차참조와 일관성을 유지
• The schema (설정 문서) — CLAUDE.md 같은 문서. 위키 구조·규칙·워크플로우를 정의해 LLM을 “일반 챗봇이 아닌 규율 있는 위키 관리자”로 만듦. 사용자와 함께 co-evolve

핵심 워크플로우 3개

Ingest (수집·컴파일)

새 소스를 읽고 → 요약 페이지 작성 → index 갱신 → 관련 엔티티/개념 페이지 수정(한 번에 10~15 페이지까지 건드림) → log에 기록 추가.

Query (질의)

위키 페이지를 검색해 인용과 함께 답변 합성. 핵심은 “좋은 답변은 새 페이지로 다시 위키에 편입(file back)” → 탐색이 영속 자산으로 전환됨.

Lint (건강 검진)

소프트웨어 린팅처럼 주기적으로 모순·오래된 주장·고아 페이지(inbound link 없음)·누락된 교차참조·데이터 공백을 스캔하고, 조사할 새 질문을 제안. (예: “20 페이지마다 린트 실행”)

폴더 구조

my-wiki/
├── sources/        # 불변 원본 (PDF, 기사, 노트)
├── wiki/           # LLM이 유지보수하는 마크다운
│   ├── index.md    # 카테고리별 카탈로그 + 한 줄 요약 (탐색 시작점)
│   ├── log.md      # append-only 연대기 (## [2026-04-02] ingest | Title 형식, grep 파싱용)
│   └── [엔티티·개념·비교 페이지들]
└── CLAUDE.md        # schema / 설정

지식 그래프로서의 위키

LLM 위키는 단순한 파일 묶음이 아니라 노드-엣지 구조의 지식 그래프다.

• 노드(node) = 마크다운 페이지 한 장 (하나의 개념·엔티티)
• 엣지(edge) = [[wiki-link]]로 만든 페이지 간 연결

그래프는 도구가 아니라 링크가 정의한다. 각 페이지 본문에 적어 둔 [[wiki-link]]가 그대로 엣지가 되며, 이 연결 관계는 마크다운 파일 안에 이미 존재한다. Obsidian은 이 그래프를 시각화해 주는 대표 도구로, graph view를 켜면 페이지들이 점으로, 링크가 선으로 그려져 개념 간 관계가 한눈에 보인다. 도구를 바꿔도(예: VS Code, 다른 뷰어) 링크로 정의된 그래프 자체는 동일하다.

예를 들어 각 페이지가 아래처럼 서로를 링크하면:

# wiki/llm-wiki.md
RAG의 매 질의 재검색 한계를 극복하려는 패턴이다. [[rag]]와 비교된다.
정신적 조상은 [[memex]]이며, 페이지들은 [[knowledge-graph]] 형태로 연결된다.
 
# wiki/rag.md
질의 시점에 [[vector-embedding]]으로 원문 청크를 검색한다.
 
# wiki/memex.md
Vannevar Bush의 개념. 오늘날 [[wiki-link]]의 원형이다.

Obsidian graph view에는 다음과 같은 연결 그래프로 렌더링된다:

graph LR
    LW["llm-wiki"] --> RAG["rag"]
    LW --> MEMEX["memex"]
    LW --> KG["knowledge-graph"]
    RAG --> VE["vector-embedding"]
    MEMEX --> WL["wiki-link"]

이 그래프 관점이 **Lint(건강 검진)**와 직접 연결된다. 린트가 잡아내는 **고아 페이지(orphan page)**는 곧 “들어오는 엣지가 하나도 없는 노드”를 의미한다. 즉 그래프에서 고립된 지점을 찾아 교차링크로 다시 이어주는 작업이 위키의 연결성을 유지하는 핵심이다. RAG의 평평한 청크 목록에는 이런 관계 구조 자체가 없다.

Memex 계보

LLM 위키의 정신적 조상은 Vannevar Bush가 1945년 에세이 *“As We May Think”*에서 제안한 Memex다.

• Memex는 개인이 문서와 자료를 저장하고, 항목 사이에 **연상 경로(associative trails)**를 직접 이어 탐색하는 가상의 기계 — 오늘날의 하이퍼링크·[[wiki-link]]의 원형
• 핵심 아이디어(“개인이 큐레이션한 지식 + 연결된 경로”)는 LLM 위키와 동일함
• 그러나 Bush의 구상에는 결정적 미해결 문제가 있었음: 연결·정리를 사람이 손수 유지해야 하는 부담. 사람은 이 지루한 정리 노동을 결국 포기함
• LLM 위키는 바로 이 유지보수 부담을 LLM에게 위임함으로써 80년 묵은 병목을 해소함 — “The LLM handles that”

핵심 원칙

• “Humans curate, LLMs maintain” — 사람은 소스를 고르고 방향을 정하고, LLM은 교차참조·일관성·갱신이라는 잡일을 담당
• “Never (or rarely) write the wiki yourself” — 저자는 LLM, 사용자는 큐레이터
• 선합성이 핵심 이득 — 질의 시점엔 교차참조·모순 표시·합성이 이미 끝나 있어, 답변이 매번 재발견되지 않고 복리로 쌓임

실제로 구현하려면

개념을 동작하는 시스템으로 옮기는 폴더·스키마·워크플로우 구성, ingest 자동화 스펙트럼, append-only 함정과 write-back, 이 환경에서 바로 시작하는 절차는 LLM Wiki 실전 구현에 별도로 정리했다.

참고 문서

• karpathy/llm-wiki (원본 Gist)
• Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG (VentureBeat)
• LLM Wiki Tutorial (Data Science Dojo)