LLM Wiki는 RAG를 대체할까?

목차

1. 개요
2. 두 구조는 무엇이 다른가
3. 비용 구조와 손익분기점
4. 지연·정확성·최신성
5. 위키는 어떻게 썩는가
6. 무엇을 어느 쪽에 둘 것인가
7. 맺음말

개요

LLM Wiki라는 패턴

LLM Wiki는 Andrej Karpathy가 2026년 4월 GitHub Gist로 공개한 지식 베이스 패턴입니다. 핵심 주장은 한 문장으로 요약됩니다. 질의할 때마다 원문에서 청크를 다시 끌어오는 대신, LLM이 원문을 한 번 컴파일해 상호 링크된 마크다운 위키를 만들어 두고, 이후에는 원문이 아니라 그 위키에 질문하자는 것입니다.

기존 방식은 배고플 때마다 매번 처음부터 요리하는 쪽에 가깝습니다. RAG(Retrieval-Augmented Generation)에서는 질의마다 검색이 다시 돌고, 합성이 다시 일어나고, 그렇게 만들어진 답은 응답과 함께 사라집니다. 열 번째 같은 질문에 드는 비용이 첫 번째와 똑같습니다. 축적되는 것이 없습니다.

LLM Wiki는 그 반대를 제안합니다. Gist의 표현을 그대로 옮기면 "the wiki is a persistent, compounding artifact" — 위키는 지속되며 누적되는 산출물입니다. 지식은 한 번 컴파일되어 남고, 다음 질의는 그 결과 위에서 출발합니다.

이 글은 LLM Wiki를 RAG의 상위 호환으로 소개하지 않습니다. 두 구조는 비용이 발생하는 시점과 정확성이 깨지는 지점이 서로 다르고, 그 차이가 선택 기준이 됩니다.

이 글에서 다루는 것

Gist 자체는 의도적으로 추상적입니다. Karpathy는 "Everything mentioned above is optional and modular"라고 못 박으며, 디렉터리 구조나 페이지 형식은 도메인에 따라 달라진다고 말합니다. 따라서 이 글은 패턴 소개에 지면을 오래 쓰지 않고, RAG와의 비교에 무게를 둡니다. 비용이 어디서 발생하는지, 지연과 정확성이 어떻게 갈리는지, 위키가 시간이 지나며 어떻게 망가지는지, 그래서 무엇을 어느 쪽에 둘지를 다룹니다.

RAG 자체의 구현은 이 블로그의 RAG 임베딩 모델 선택 글과 RAG API와 자체 호스팅 비용 비교 글에서 다뤘습니다. 에이전트가 세션 사이에 무엇을 기억해야 하는가라는 질문은 AI Agent 메모리 레이어 설계 글과 이어집니다.

두 구조는 무엇이 다른가

질의 시점 합성과 수집 시점 컴파일

가장 근본적인 차이는 합성이 언제 일어나는가입니다.

RAG에서 합성은 질의 시점에 일어납니다. 사용자가 질문하면 질문을 임베딩하고, 벡터 인덱스에서 유사 청크 상위 N개를 꺼내고, 그 청크들을 프롬프트에 붙여 LLM이 답을 만듭니다. 원문은 조각난 상태로 저장되어 있고, 조각을 다시 이어 붙이는 일은 매번 반복됩니다.

LLM Wiki에서 합성은 수집 시점에 일어납니다. 원문을 넣는 순간 LLM이 그것을 읽고, 요약 페이지를 쓰고, 관련된 엔티티 페이지를 갱신하고, 상호 참조를 다시 겁니다. 질의 시점에는 이미 정리된 페이지를 읽을 뿐입니다.

RAG는 질의마다 같은 경로를 반복하고, LLM Wiki는 수집 때 한 번 컴파일한 결과를 질의마다 재사용합니다.

세 개의 계층

Karpathy가 제시한 구조는 세 계층입니다.

raw — 원문입니다. 기사, PDF, 데이터 덤프 같은 것들이 그대로 들어갑니다. 불변이고, LLM은 읽기만 할 뿐 절대 수정하지 않습니다. 위키에 오류가 생겼을 때 돌아갈 기준점이 여기입니다.

wiki — LLM이 생성하고 소유하는 마크다운 페이지들입니다. 요약, 엔티티 페이지, 개념 페이지, 상호 참조가 모두 여기 있습니다. 일관성 유지의 책임이 사람이 아니라 LLM에 있다는 것이 이 계층의 전제입니다.

schema — CLAUDE.md나 AGENTS.md 같은 규약 문서입니다. 페이지를 어떤 형식으로 쓸지, 링크를 어떻게 걸지, 색인을 언제 갱신할지가 여기 적힙니다. Karpathy는 이것을 사람과 에이전트 사이의 계약이라고 부릅니다. 세 계층 중 사람이 직접 쓰고 관리하는 유일한 곳입니다.

여기에 두 개의 보조 파일이 붙습니다. index.md는 모든 페이지를 분류별로 모은 목차로, 수집이 일어날 때마다 갱신됩니다. log.md는 추가만 가능한 시간순 기록으로, 최근에 무슨 일이 있었는지를 grep 한 번으로 확인하게 해 줍니다.

세 개의 연산

연산도 셋입니다.

ingest — 원문을 넣으면 LLM이 읽고, 요약 페이지를 만들고, 영향받는 엔티티 페이지를 갱신하고, 상호 참조를 정리합니다. Karpathy는 원문 하나가 위키 페이지 10~15개를 건드릴 수 있다고 말합니다. 이것이 이 패턴에서 가장 비싼 연산입니다.

query — 위키에 질문합니다. LLM이 관련 페이지를 찾아 답을 합성하고, 그 답이 쓸 만하다면 다시 위키 페이지로 편입시킵니다. 질의가 위키를 키우는 되먹임이 여기서 생깁니다.

lint — 주기적인 건강 검진입니다. 모순되는 서술, 낡은 주장, 고아 페이지, 빠진 상호 참조를 찾아냅니다. 뒤에서 따로 다루겠지만, 이 연산이 있느냐 없느냐가 위키의 수명을 가릅니다.

원문 하나가 들어오면 요약 페이지가 새로 생기고, 그 내용이 걸쳐 있는 기존 엔티티 페이지들이 함께 수정되며, 색인과 로그가 갱신됩니다.

비용 구조와 손익분기점

돈이 나가는 시점이 다르다

RAG의 비용은 질의 횟수에 비례합니다. 질의마다 청크 N개가 프롬프트에 들어가므로, 입력 토큰이 질의마다 그대로 발생합니다. 질의가 늘면 비용이 선형으로 늘고, 같은 질문을 반복해도 할인은 없습니다.

LLM Wiki의 비용은 수집 시점에 몰립니다. 원문 전체를 읽고 페이지를 여러 개 쓰는 작업이라 출력 토큰까지 크게 발생합니다. 대신 질의는 잘 정리된 페이지 한두 개만 읽으므로 입력 토큰이 작습니다.

즉 이 비교는 "어느 쪽이 싸냐"가 아니라 **"질의를 몇 번 할 것이냐"**의 문제입니다.

계산해 보기

기준을 고정합니다. 이 블로그의 다른 비용 글과 동일하게 환율은 1,340원/$1, VAT는 별도입니다. 모델 단가는 Claude Opus 5 기준으로 입력 100만 토큰당 $5.00, 출력 100만 토큰당 $25.00을 씁니다(2026년 6월 기준). 문서는 200건, 평균 3,000토큰으로 원문 총량은 60만 토큰이라고 두겠습니다.

RAG 질의 1회

LLM Wiki 질의 1회

LLM Wiki 최초 수집

질의당 차액이 $0.011이므로 손익분기점은 약 900회입니다. 하루 30회씩 묻는다면 한 달쯤 지나 역전됩니다. 문서가 한 번 들어오고 오래 유지되는 지식 베이스라면 충분히 넘길 수 있는 숫자이고, 원문이 주마다 통째로 갈리는 자료라면 영영 못 넘깁니다.

이 계산이 감추는 것

세 가지를 덧붙여야 공평합니다.

첫째, 프롬프트 캐싱을 쓰면 RAG 쪽도 싸집니다. 청크 조합이 반복되는 구간에 캐시를 걸면 입력 비용이 10분의 1 수준으로 떨어집니다. 다만 RAG는 질의마다 청크 조합이 달라지는 것이 정상이라 캐시 적중률을 올리기 어렵습니다. 반대로 위키는 같은 페이지를 반복해서 읽으므로 캐싱과 궁합이 좋습니다.

둘째, 재수집 비용이 빠져 있습니다. 원문이 바뀌면 수집을 다시 해야 하고, 이때 비용은 다시 발생합니다. 원문 교체율이 높을수록 손익분기점은 뒤로 밀립니다.

셋째, 비용은 이 패턴의 핵심 논거가 아닙니다. Karpathy가 강조한 것은 절감이 아니라 누적입니다. 같은 질문을 두 번째 던질 때 RAG는 첫 번째와 똑같은 일을 하지만, 위키에는 이미 그 답이 페이지로 존재합니다. 비용 계산은 그 누적의 부수 효과일 뿐입니다.

지연·정확성·최신성

지연

질의 경로가 짧은 쪽이 유리합니다. RAG는 임베딩 호출 → 벡터 검색 → 긴 컨텍스트 합성을 거칩니다. 위키는 파일 검색 → 짧은 컨텍스트 합성으로 끝납니다. 컨텍스트가 절반 이하이므로 첫 토큰까지의 시간도 짧아집니다.

다만 위키의 검색은 대개 grep이나 색인 훑기라서, 페이지 수가 수천 단위로 늘면 오히려 느려질 수 있습니다. 이 지점에서 위키에도 결국 인덱스가 필요해지고, 구조가 RAG 쪽으로 한 걸음 되돌아갑니다.

정확성과 추적성 — 위키의 가장 큰 약점

여기가 이 비교의 핵심입니다.

RAG가 인용하는 것은 원문 조각입니다. 답이 이상하면 그 청크를 열어 확인하면 됩니다. 검색이 엉뚱한 청크를 물어 오는 실패는 잦지만, 그 실패는 질의 하나에서 끝나고 다음 질의에 전염되지 않습니다.

LLM Wiki가 인용하는 것은 LLM이 요약한 2차 산출물입니다. 수집 시점에 요약이 한 번 잘못되면, 그 오류는 페이지에 고정되고 이후 모든 질의가 그 위에서 답합니다. 더 나쁜 것은 그 잘못된 페이지를 근거로 다른 페이지가 갱신되면서 오류가 위키 전체로 번진다는 점입니다. RAG의 오류가 일회성이라면, 위키의 오류는 복리로 쌓입니다.

그래서 실무에서 이 패턴을 쓸 때 타협 불가능한 규칙이 하나 생깁니다. 모든 주장에 원문 출처를 남기는 것입니다. 페이지 형식을 이렇게 강제하면 오류가 났을 때 원문까지 되짚을 수 있습니다.

---
name: semantic-cache
type: concept
sources:
  - raw/2026-04-02-cache-paper.pdf#p12
  - raw/2026-05-11-vendor-docs.md#L88-L120
updated: 2026-09-23
---

임베딩 유사도로 의미가 같은 질문에 저장된 응답을 재사용하는 캐시.
임계값은 도메인에 따라 0.88~0.95 사이에서 정한다. [^1]

[^1]: raw/2026-04-02-cache-paper.pdf#p12 — 표 3의 도메인별 측정값

출처가 없는 문장은 위키에 남기지 않는다는 규칙 하나가, 이 패턴의 가장 큰 위험을 관리 가능한 수준으로 낮춥니다.

최신성

원문이 바뀌었을 때 RAG는 인덱스만 다시 만들면 즉시 반영됩니다. 위키는 재수집이 돌기 전까지 낡은 상태로 남습니다. 그리고 낡았다는 사실이 겉으로 드러나지 않습니다. 페이지는 여전히 자신만만한 문장으로 쓰여 있고, 질의자는 그것이 3주 전 기준이라는 것을 알 수 없습니다.

그래서 페이지에 updated 같은 시각 정보를 남기고, 오래된 페이지를 주기적으로 훑는 장치가 필요합니다. 앞의 예시에서 frontmatter에 updated를 둔 이유가 이것입니다.

위키는 어떻게 썩는가

사람이 위키를 버리는 이유

Karpathy의 논지에서 가장 설득력 있는 대목은 여기입니다. 위키가 실패해 온 이유는 쓰기가 어려워서가 아니라 유지하기가 지겨워서입니다. 문서 하나를 고치면 그것을 참조하던 다른 문서들이 어긋나고, 상호 참조를 따라다니며 고치는 일은 가치보다 빠르게 늘어납니다. 그래서 사람은 결국 손을 놓습니다.

Karpathy는 그 부담을 LLM에 넘깁니다. 지겨움을 느끼지 않고, 갱신을 잊지 않는다는 것이 근거입니다. 사람은 원문을 고르고, 분석 방향을 정하고, 질문을 던집니다. 나머지는 LLM이 합니다.

lint가 실제로 잡아야 하는 것

다만 "LLM이 알아서 한다"는 것은 자동으로 되는 일이 아니라 주기적으로 돌려야 하는 연산입니다. lint가 잡아야 하는 것은 대략 이렇습니다.

앞의 세 가지는 기계적으로 검사할 수 있습니다. 링크를 파싱해 대상이 있는지 보고, 색인에 없는 파일을 찾고, 들어오는 링크가 0인 페이지를 세면 됩니다. 이 부분은 LLM 없이 스크립트로 처리하는 편이 빠르고 확실합니다.

# 깨진 [[링크]]와 색인 누락을 기계적으로 찾는다
grep -oh '\[\[[^]]*\]\]' wiki/*.md | sort -u | tr -d '[]' | while read -r n; do
  [ -f "wiki/$n.md" ] || echo "깨진 링크: $n"
done

ls wiki/*.md | while read -r f; do
  grep -q "$(basename "$f" .md)" wiki/index.md || echo "색인 누락: $f"
done

뒤의 두 가지 — 모순과 낡음 — 는 의미를 읽어야 하므로 LLM이 필요합니다. 그리고 이쪽이 훨씬 비쌉니다. 위키 전체를 다시 읽어야 하기 때문입니다. 실무에서는 log.md를 근거로 최근 수집이 건드린 페이지 주변만 검사 범위로 잡는 편이 현실적입니다.

쓰기 권한이라는 문제

RAG는 읽기 전용입니다. 검색이 아무리 엉뚱해도 원본은 그대로입니다. LLM Wiki는 에이전트가 파일을 씁니다. 이는 운영 관점에서 성격이 다른 문제를 만듭니다. 잘못된 수집 한 번이 페이지 열 개를 오염시킬 수 있고, 그것을 되돌리려면 변경 이력이 있어야 합니다.

그래서 위키 디렉터리는 Git으로 관리하는 것이 사실상 전제 조건입니다. 수집 한 번을 커밋 하나로 묶으면, 오염이 발견됐을 때 그 커밋만 되돌릴 수 있습니다. raw를 불변으로 두라는 Karpathy의 규칙도 같은 맥락입니다. 되돌아갈 기준점이 오염되지 않아야 복구가 가능합니다.

무엇을 어느 쪽에 둘 것인가

판단 기준

두 구조를 가르는 변수는 셋입니다. 원문이 얼마나 자주 바뀌는가, 같은 주제를 얼마나 반복해서 묻는가, 출처를 원문 단위로 대야 하는가.

정리하면 이렇습니다.

섞어 쓰기

실제로는 둘 중 하나를 고르는 문제가 아닌 경우가 많습니다. 위키를 1차 조회 경로로 두고, 위키가 답하지 못할 때 원문 RAG로 폴백하는 구성이 자연스럽습니다. 자주 묻는 것은 컴파일된 페이지가 싸고 빠르게 처리하고, 드물고 구체적인 질문은 원문을 뒤집니다.

이때 폴백이 일어났다는 사실 자체가 유용한 신호입니다. 위키에 빠진 주제가 무엇인지 알려 주기 때문입니다. 폴백 로그를 모아 다음 수집 대상을 정하면, 위키가 실제 질의 분포를 따라 자랍니다.

이미 쓰고 있었을지도 모른다

한 가지 덧붙이자면, 이 패턴은 생각보다 이미 가까이 있습니다. 코딩 에이전트에 붙이는 CLAUDE.md나 AGENTS.md는 schema 계층 그 자체이고, 에이전트가 프로젝트별로 남기는 메모리 디렉터리는 사실상 wiki 계층입니다. 사실 하나를 파일 하나에 담고, frontmatter로 이름과 성격을 적고, 본문에서 [[다른-항목]]으로 연결하고, 색인 파일 하나가 전체를 가리키는 구조 — Karpathy가 Gist에 적은 것과 같은 모양입니다.

이 블로그 저장소도 그렇습니다. 최상위 AGENTS.md가 에이전트와의 계약을 적어 두고, 에이전트가 세션을 넘겨 기억해야 할 사실은 별도 메모리 파일로 쌓입니다. 규모가 작아 lint를 따로 돌릴 일은 아직 없지만, 구조는 동일합니다. 새로운 도구를 들이기 전에, 이미 돌아가고 있는 것을 이 세 계층으로 다시 보는 것만으로도 얻을 것이 있습니다.

맺음말

핵심 요약

LLM Wiki는 RAG의 상위 호환이 아니라 비용과 오류의 위치를 옮긴 구조입니다. RAG는 질의마다 비용을 내고 오류도 질의마다 끝납니다. LLM Wiki는 수집 때 비용을 몰아서 내고, 대신 그때 생긴 오류가 페이지에 고정되어 이후 모든 답에 영향을 줍니다.

손익분기점은 질의 횟수로 결정됩니다. 앞의 가정에서는 약 900회였습니다. 이 숫자는 문서량과 페이지 밀도에 따라 달라지므로, 도입 전에 자기 데이터로 다시 계산해 볼 값입니다.

출처 표기와 lint는 선택 사항이 아닙니다. 모든 주장에 원문 출처를 남기는 규칙이 요약 오류의 고착을 막고, 주기적인 lint가 링크 붕괴와 모순 누적을 막습니다. 이 둘이 없는 LLM Wiki는 자신 있게 틀린 말을 하는 문서 더미가 됩니다.

위키는 에이전트가 쓰는 대상이므로 버전 관리가 전제입니다. 수집 한 번을 커밋 하나로 묶고, raw는 불변으로 둡니다.

적용 판단 기준

원문이 안정적이고, 같은 주제를 반복해서 묻고, 개념 사이의 연결 자체가 가치인 작업이라면 시도할 만합니다. 사내 아키텍처 문서, 오래 끌고 가는 연구 주제, 프로젝트별 축적 지식이 여기 해당합니다.

반대로 원문이 자주 갈리거나, 문서가 수십만 건이거나, 답변마다 원문 인용을 대야 한다면 RAG가 여전히 맞습니다. 그리고 둘 중 하나를 고르기 어렵다면, 위키를 앞에 두고 원문 RAG를 뒤에 두는 구성부터 재 보는 것이 가장 실패 비용이 낮습니다.