LLM Wiki vs RAG 비교
개요
LLM Wiki와 RAG(Retrieval-Augmented Generation)는 둘 다 LLM이 문서를 기반으로 질문에 답하게 만드는 패턴이지만, *언제* 작업이 일어나는지가 근본적으로 다르다. 출처 llm-wiki.en.md
- RAG: 질문 시점(query time)에 문서 청크를 벡터 DB에서 검색해 매번 답변을 재조합한다.
- LLM Wiki: 소스 입수 시점(ingest time)에 내용을 컴파일해 영속적인 위키 페이지로 저장하고, 이후에는 이미 합성된 지식을 읽는다.
핵심 비교표
| 항목 | LLM Wiki (컴파일) | RAG (검색) |
|---|---|---|
| 작업 발생 시점 | Ingest 시점 (한 번 컴파일) | Query 시점 (매번 검색) |
| 시간에 따른 지식 | 누적 — 페이지가 점점 풍부해짐 | 정적 — 매 쿼리마다 재조합 |
| 결과물 | 사람이 읽을 수 있는 상호 링크된 페이지 | 쿼리별로 재조합되는 불투명한 청크 |
| 모순 처리 | Ingest 중 발견·조정 | 조용히 나란히 검색됨 |
| 초기 설정 | Markdown 폴더 + 스키마 파일 | 임베딩 + 벡터 DB + 파이프라인 |
| 규모 한계 | 수백~약 1,000페이지 수준 | 수백만 문서 |
llm-wiki.en.md
지식 누적 vs 재조합
지식 누적(Knowledge Compounding)은 LLM Wiki가 RAG와 구별되는 핵심 특성이다. Ingest·Query·Lint 작업이 반복될수록 위키 페이지는 점점 더 깊어지고, 어떤 주제에 대해 50개의 논문을 Ingest한 위키는 5개만 Ingest한 위키보다 훨씬 풍부한 답변을 제공한다. RAG는 이런 축적 효과가 없다 — 매 쿼리마다 원본 청크로부터 답변을 재조합하기 때문이다. llm-wiki.en.md
RAG의 알려진 실패 사례
RAG는 2026년 기준 기업 AI 애플리케이션의 약 85%가 사용하는 지배적인 패턴이지만, 대표적인 실패 모드가 존재한다:
- 부실한 소스에서 비롯된 자신감 있는 오답 — 검색된 청크의 품질을 제어하기 어렵다.
- RAG 구현의 40~60%가 프로덕션에 도달하지 못한다는 분석이 있으며, ROI를 입증하는 사례도 대부분 검색 튜닝이 아닌 지식 베이스 품질 덕분이다.
LLM Wiki는 단일하고 큐레이션된 상호 참조 아티팩트를 유지함으로써 이 문제를 근본에서 공략한다. llm-wiki.en.md
LLM Wiki의 한계
LLM Wiki의 세 레이어 구조는 강력하지만 RAG 대비 명확한 한계도 있다:
- 규모:
index.md방식은 약 1,000개 파일/수백 페이지까지 편안하게 동작하며, 그 이상에서는 실제 검색 인프라가 필요하다. - 벡터 DB 없음: qmd 같은 로컬 검색 엔진이 규모가 커질 때 보완재로 사용될 수 있다.
- 거버넌스: 신뢰도 점수나 사람의 검토 없이는 잘못된 합성이 조용히 전파될 수 있다.
llm-wiki.en.md
두 패턴은 상호 배타적이지 않다
대규모 코드베이스나 말뭉치의 경우 현실적인 아키텍처는 자주 접근하는 핫 컨텍스트를 위한 컴파일된 위키 + 롱테일 광범위 검색을 위한 RAG 레이어의 조합이다. llm-wiki.en.md
Andrej Karpathy가 제안한 패턴은 개인 규모의 지식에서 LLM Wiki가 RAG를 대체할 수 있다고 보지만, 매우 큰 코어퍼스에서는 하이브리드 설계가 현실적이다.