Field Log · Entry
LLM Wiki와 RAG의 차이: 대체 관계가 아니라 지식 수명주기다 (4/6)
이번 글의 결론
- RAG는 주로 query 시점에 외부 memory에서 context를 고르고 답을 생성하는 architecture입니다.
- LLM Wiki는 source를 page·node·edge로 변환하고 검수·승격·갱신·폐기하는 knowledge lifecycle입니다.
- 따라서 “LLM Wiki가 RAG를 대체한다”는 질문은 비교 단위가 맞지 않습니다. LLM Wiki의 build와 Ask 기능 양쪽에 RAG가 들어갈 수 있습니다.
- GraphRAG도 graph를 이용해 query context를 만드는 RAG 방법이며, 그 graph가 곧 사람과 조직의 canonical wiki라는 뜻은 아닙니다.
- Retrieval metric만 좋아도 wiki 품질은 보장되지 않습니다. Coverage, provenance, schema, link, freshness, review를 별도로 측정해야 합니다.
LLM Wiki와 RAG의 차이는 검색 방식보다 시스템이 책임지는 시간 범위에 있습니다. RAG는 “이 질문에 어떤 context를 넣을까”를 풀고, LLM Wiki는 “원천에서 어떤 지식을 만들고 누가 검수하며 언제 낡았다고 표시할까”를 풉니다. 둘은 대체재가 아니라 한 제품 안에서 자주 결합됩니다.
먼저 비교 단위부터 맞춘다
두 용어를 같은 층에 놓으면 다음과 같은 잘못된 질문이 생깁니다.
Vector DB인가, Wiki인가?
RAG인가, Graph인가?
Chat인가, Page인가?실제로는 각각 다른 설계 축입니다.
| 설계 축 | 선택지 예 |
|---|---|
| Canonical knowledge | Markdown·database·typed graph |
| Retrieval | BM25·dense·hybrid·graph traversal |
| Generation | template·LLM·deterministic render |
| Interface | browse·search·chat·MCP |
| Lifecycle | draft·review·approved·stale·archived |
Markdown wiki를 vector index에 넣어 RAG Q&A를 만들 수 있습니다. Graph node를 BM25로 찾을 수도 있습니다. Chat에서 답한 내용을 review한 뒤 page로 승격할 수도 있습니다.
핵심 문장을 먼저 고정하겠습니다.
RAG는 context selection architecture이고, LLM Wiki는 knowledge artifact lifecycle이다.
RAG가 책임지는 것
Lewis 등의 2020년 RAG 논문은 pretrained seq2seq model의 parametric memory와 Wikipedia passage의 dense vector index라는 non-parametric memory를 결합했습니다. Query를 받아 passage를 retrieve하고, 그 passage를 조건으로 response를 생성합니다.
오늘날 산업에서 RAG는 더 넓게 쓰입니다.
query
→ query rewrite / routing
→ sparse + dense retrieval
→ fusion / reranking
→ context selection
→ grounded generation
→ citation이 pipeline의 주 질문은 다음과 같습니다.
- Relevant evidence를 top-k 안에 가져왔는가?
- 가장 좋은 근거가 앞에 오는가?
- Prompt token budget에 어떤 span을 넣을 것인가?
- 근거가 없거나 모순될 때 답하지 않을 수 있는가?
- 최종 answer가 context에 의해 지지되는가?
그래서 RAG 평가는 Recall@k, MRR, nDCG, context precision, answer correctness, citation entailment처럼 query와 answer를 중심으로 설계됩니다. 기본 검색 계층은 RAG 검색 계층 시리즈에서 단계별로 다룹니다.
RAG가 자동으로 책임지지 않는 것도 있습니다.
- Page hierarchy와 navigation
- 원천의 여러 chunk를 합친 stable concept page
- Candidate와 canonical의 구분
- 사람 review와 revision history
- Source change에 따른 stale page 계산
- Entity lifecycle과 relation constraint
물론 RAG 제품이 이런 기능을 추가할 수 있습니다. 그 순간 retrieval system 위에 knowledge management lifecycle을 얹는 것입니다.
LLM Wiki가 책임지는 것
LLM Wiki는 사용자가 질문하기 전부터 작업합니다.
source inventory
→ parse / normalize
→ classify / page plan
→ claim·node·edge proposal
→ evidence binding
→ staging
→ deterministic validation
→ human review
→ canonical promotion
→ index / browse / Q&A
→ stale detection / incremental rebuild주 질문도 달라집니다.
- Source가 빠짐없이 inventory에 잡혔는가?
- 어떤 page가 어느 source revision에서 나왔는가?
- 같은 entity를 중복 생성하지 않았는가?
- Page와 edge가 contract를 지키는가?
- 중요한 문서를 누락하지 않았는가?
- 누가 candidate를 승인했는가?
- Source가 바뀐 뒤 어느 page가 stale인가?
이 작업의 출력은 query별 answer가 아니라 versioned artifact입니다.
id: decision:sqlite-first
kind: decision
status: approved
sources:
- path: docs/architecture/storage.md
revision: 7a13d2e
relations:
- type: constrains
to: component:project-registry
reviewed_at: 2026-07-29질문이 없어도 이 page는 browse할 수 있고, 다음 agent run의 context로 넣을 수 있습니다.
그림 1. RAG와 LLM Wiki는 다른 시간축을 책임지며, approved wiki가 다시 RAG의 retrieval corpus가 될 수 있다.
같은 source를 처리해도 산출물이 다르다
다음 세 문서가 있다고 가정하겠습니다.
docs/auth.md
incident/2026-06-token-loop.md
src/auth/refresh.ts사용자가 “refresh token이 반복되는 조건은?”이라고 물으면 basic RAG는 관련 chunk를 retrieve해 answer와 citation을 만들 수 있습니다. 질문 해결에는 충분합니다.
LLM Wiki build는 질문 없이 다음 artifact를 미리 만들 수 있습니다.
concept: Refresh Token Rotation
incident: 2026-06 Refresh Loop
component: Auth Refresh Worker
incident --caused_by--> concept misconfiguration
component --implements--> concept
incident --changed_by--> commit 8f20...그 뒤 사용자가 같은 질문을 하면 Ask layer는 raw chunk, approved page, graph neighbor를 함께 retrieve할 수 있습니다.
두 접근의 관계:
raw-source RAG
빠른 시작, 최신 원문 직접 검색
wiki RAG
검수된 요약과 구조 재사용
hybrid
wiki로 route·overview를 잡고 raw source로 사실 확인실무에서는 hybrid가 안전합니다. Wiki page는 빠른 이해와 terminology normalization에 좋고, 구체적인 code·수치·정책 답변은 raw source revision으로 내려가 확인합니다.
LLM Wiki 안에서 RAG는 두 번 쓰일 수 있다
Build time: 어떤 source를 page 생성에 넣을까?
Source가 context window보다 크면 page worker마다 관련 문서를 선택해야 합니다.
page purpose
→ retrieve source candidates
→ rerank
→ generate evidence-bearing proposal여기서 retrieval이 틀리면 page가 얕아집니다. 그래서 large repository에서는 folder hierarchy, symbol graph, manual page plan을 vector similarity와 함께 사용합니다.
Cognition의 공식 DeepWiki steering 문서는 large repository에서 built-in limit로 중요한 component가 빠질 수 있음을 설명하고, explicit page plan으로 default cluster planning을 우회하게 합니다. Generation 전에 source scope와 page scope를 정하는 것이 build-time retrieval 문제입니다.
Query time: 어느 page와 원문으로 답할까?
Approved wiki가 만들어진 뒤에는 다음처럼 검색합니다.
query
├─ exact identifier / BM25
├─ page embedding
├─ raw chunk embedding
└─ graph neighbor expansion
↓
rerank + context budget
↓
answer with page + raw citations이 구조는 사람에게는 page navigation을, agent에게는 compact context를 제공하면서도 raw evidence를 보존합니다.
GraphRAG와 LLM Wiki도 같은 말이 아니다
Microsoft는 GraphRAG indexing을 unstructured text에서 structured data를 추출하는 pipeline으로 설명합니다. Standard method는 entity, relationship, optional claim을 추출하고 community detection과 multi-level community report generation을 수행하며, text도 vector space에 embed합니다.
Query engine은 질문 범위에 따라 방법을 나눕니다.
- Basic: top-k text unit vector RAG
- Local: 특정 entity 주변 graph와 raw text
- Global: community report를 map-reduce
- DRIFT: community에서 시작해 local follow-up 확장
자세한 구조는 Microsoft GraphRAG 해부에서 설명했습니다.
GraphRAG의 목적은 query에 넣을 context를 더 잘 만드는 것입니다. 그 output에는 entity table과 community report가 있어 wiki page처럼 보일 수 있지만 다음 항목이 자동으로 보장되지는 않습니다.
- 조직이 합의한 canonical entity schema
- Page owner와 approval status
- Lifecycle transition
- Revision review와 rollback
- ACL이 반영된 파생 page
반대로 계약형 LLM Wiki가 GraphRAG의 community detection을 쓰지 않을 수도 있습니다. 관계는 다음처럼 정리할 수 있습니다.
GraphRAG = graph-structured retrieval/indexing method
Graph Wiki = graph-structured knowledge artifact and lifecycle둘을 결합하면 graph artifact를 사람이 검수하고, query engine이 local/global retrieval에 재사용할 수 있습니다.
비교표: Chat-only RAG와 LLM Wiki
| 축 | Chat-only RAG | LLM Wiki |
|---|---|---|
| 시작 event | User query | Source change·build request |
| 주 계산 시점 | Query time | Build/index time + query time |
| 주 산출물 | Answer | Page·node·edge·diagram + optional answer |
| 식별자 | Query/session ID | Stable page/node ID |
| 탐색 | 질문·검색 중심 | TOC·link·graph + 질문 |
| Provenance | Answer citation | Claim·edge·page source lineage |
| 품질 gate | Retrieval·answer eval | Coverage·schema·link·graph·freshness·review |
| 갱신 | Re-index | Proposal→review→promote→stale |
| 사람 역할 | 질문·답변 확인 | 편집·승인·정본 관리 |
| 실패 형태 | 틀린/근거 없는 answer | 틀린 page가 반복 재사용될 위험 |
마지막 행이 특히 중요합니다. Chat answer의 오류는 한 session에 머물 수 있지만, 잘못된 wiki page는 검색과 agent context에 반복 주입됩니다. Materialization은 재사용 효율과 오류 증폭을 함께 높입니다.
평가도 두 층으로 분리한다
Retrieval·answer 평가
- Hit/Recall@k
- MRR·nDCG
- Context precision·coverage
- Answer correctness
- Citation entailment
- No-answer calibration
- Latency·cost
Wiki build·lifecycle 평가
- Source inventory coverage
- Source→page citation coverage
- Unverifiable evidence count
- Duplicate entity rate
- Schema·frontmatter validity
- Broken link·orphan node
- Stale page age
- Human acceptance·edit distance
- Incremental rebuild idempotency
- Secret·PII finding
RAG benchmark가 좋아도 source 30%가 page plan에서 빠지면 wiki build는 실패입니다. 반대로 모든 문서를 page로 만들었어도 query가 중요한 page를 찾지 못하면 Ask layer는 실패입니다.
제가 “검색 성공”과 “지식화 성공”을 분리한 이유
개인 LLM Wiki 구현에서 처음에는 pipeline이 끝까지 실행되고 node가 생성되면 성공으로 봤습니다. 하지만 “전 문서를 읽었다”와 “모든 문서의 중요한 내용이 wiki에 반영됐다”는 다른 상태였습니다.
그래서 source path와 proposal의 evidence citation을 대조하는 coverage report를 만들었습니다.
source A → node 1, node 3 covered
source B → node 2 covered
source C → none unmapped이 metric은 retrieval Recall@k가 아닙니다. 특정 query 없이 build가 source inventory를 얼마나 지식 artifact에 반영했는지 보여 줍니다.
또 evidence verifier에서 source path가 실제 raw/ file인지 확인했습니다. 현재 구현은 존재하지 않거나 경계를 탈출하는 citation을 unverifiable로 분류하고, 해당 evidence를 제거한 뒤 근거가 하나도 남지 않은 proposal을 drop합니다. 반면 quote_or_summary가 원문과 verbatim하게 일치하지 않는 경우 field가 summary일 수도 있어 warning으로 남겨 human review에 보냅니다.
이 경험은 retrieval과 curation gate를 같은 “RAG quality”로 뭉치면 무엇이 실패했는지 알 수 없다는 점을 보여 줬습니다.
무엇부터 만들지 선택하는 기준
Basic RAG부터 시작해도 되는 경우
- 사용자가 묻는 질문이 이미 명확합니다.
- 원문이 authoritative하고 직접 citation하면 충분합니다.
- Page navigation과 cross-session memory가 필요 없습니다.
- Source 규모와 변경 속도가 작습니다.
- Generated artifact를 정본으로 관리할 이유가 없습니다.
LLM Wiki lifecycle이 필요한 경우
- 질문하기 전 전체 map을 봐야 합니다.
- 같은 synthesis를 여러 사람과 agent가 반복합니다.
- Decision·experiment·incident처럼 stable entity가 있습니다.
- Source와 derived knowledge의 review·rollback이 필요합니다.
- 관계와 전체 corpus 질문이 중요합니다.
- 다음 agent run에 검수된 compact context를 제공해야 합니다.
둘을 처음부터 결합할 경우
MVP를 아래처럼 좁힙니다.
Markdown + Git canonical wiki
source hash ledger freshness
BM25 exact search
vector index semantic fallback
human review promotionGraph DB와 multi-agent는 실제 failure가 단일 page worker와 link로 해결되지 않을 때 추가합니다.
자주 묻는 질문
LLM Wiki를 만들면 vector DB가 필요 없나?
아닙니다. Page 수가 작으면 BM25와 file search만으로 충분할 수 있지만, semantic question과 raw chunk 검색에는 vector index가 유용합니다. Vector DB는 canonical knowledge store가 아니라 재생성 가능한 retrieval index로 두는 편이 안전합니다.
GraphRAG를 쓰면 바로 LLM Wiki가 되나?
GraphRAG output을 page로 render하고 provenance·review·revision·freshness를 붙이면 LLM Wiki의 일부가 될 수 있습니다. Indexing과 query만 운영하면 graph-based RAG system입니다.
Wiki page만 retrieve할까, raw source도 retrieve할까?
둘 다 유지하는 hybrid를 권합니다. Wiki는 overview와 routing, raw source는 정확한 사실과 최신 revision 확인에 씁니다. Answer citation에는 가능한 한 raw source도 포함합니다.
Long-context model이면 build-time retrieval이 필요 없나?
작은 source set에서는 생략할 수 있습니다. 큰 repository에서는 전체가 들어가더라도 attention, cost, source coverage, worker specialization 문제가 남습니다. Page plan과 folder decomposition은 context window 크기와 별개의 구조화 도구입니다.
마무리
RAG와 LLM Wiki의 차이를 한 줄로 다시 쓰면 다음과 같습니다.
RAG: 지금 이 질문에 필요한 context를 고른다.
LLM Wiki: 다음 질문에도 재사용할 지식을 만들고 관리한다.좋은 LLM Wiki는 RAG를 버리지 않습니다. Raw source와 approved page를 hybrid retrieval하고, 필요하면 graph로 확장하며, answer에서 다시 source로 돌아가게 합니다. 대신 retrieval score와 별도로 page coverage, evidence validity, freshness, human acceptance를 측정합니다.
다음 글 LLM Wiki 구현 1에서는 source inventory부터 evidence-bearing proposal까지 실제 Python 구조로 내려갑니다.