Field Log · Entry
LLM Wiki란 무엇인가: AI 챗봇·RAG·전통 위키와 구분하기 (1/6)
이번 글의 결론
- LLM Wiki는 아직 RAG처럼 합의된 단일 학술 용어가 아니라 여러 제품과 구현을 묶어 부르는 실무 용어에 가깝습니다.
- 이 시리즈에서는 원천을 출처가 연결된 지속 가능한 페이지·노드·관계로 재구성하는 지식층을 LLM Wiki라고 부릅니다.
- 답변만 생성하는 챗봇, 검색 인덱스만 만드는 RAG, 한 번 생성하고 끝나는 문서 자동화와는 산출물의 수명주기가 다릅니다.
- 판별 기준은 materialized artifact, provenance, navigation structure, review/update lifecycle, reuse 다섯 가지입니다.
- LLM은 초안을 제안하고, 코드가 계약을 검사하며, 사람이 정본 승격을 결정하는 구조가 안전한 출발점입니다.
LLM Wiki란 코드·문서·대화·실험 같은 원천을 LLM이 읽고, 다시 탐색하고 갱신할 수 있는 지식 페이지와 관계로 정리하는 시스템입니다. 핵심은 “질문에 답했다”가 아니라 답변 뒤에도 남아 사람과 다음 AI 에이전트가 재사용할 지식 자산을 만들었다는 데 있습니다.
LLM Wiki는 아직 하나의 표준 용어가 아니다
Retrieval-Augmented Generation은 2020년 Lewis 등의 논문에서 parametric memory와 dense vector index의 non-parametric memory를 결합하는 모델로 구체화됐습니다. 반면 LLM Wiki는 하나의 논문이나 표준 사양보다 제품과 오픈소스 프로젝트에서 먼저 널리 쓰인 이름입니다. 따라서 제품 이름만 보고 정의하면 범위가 계속 달라집니다.
Cognition의 DeepWiki는 repository를 자동 index해 architecture diagram, source link, codebase summary와 Q&A를 제공합니다. NotebookLM은 사용자가 넣은 source를 근거로 답하고 briefing·mind map 같은 파생 형식을 만듭니다. 조직 지식 검색 도구는 Slack·Drive·기존 wiki를 찾아 답하지만 새 page를 항상 만들지는 않습니다.
그래서 이 시리즈에서는 제품명이 아니라 산출물로 정의합니다.
LLM Wiki는 원천 자료를 LLM으로 해석해 출처가 연결된 지속 가능한 페이지·노드·관계로 재구성하고, 사람과 AI 에이전트가 탐색·검색·질의·갱신에 다시 사용하는 지식층입니다.
이것은 보편 표준을 선언하는 문장이 아니라 앞으로의 비교를 일관되게 만들기 위한 작업 정의입니다.
전통 위키에 LLM이 더해지면 무엇이 달라질까?
전통 위키의 강점은 “페이지” 자체보다 수명주기에 있습니다. 페이지에는 주소가 있고, 다른 페이지와 연결되며, 누가 언제 무엇을 고쳤는지 revision이 남습니다. MediaWiki도 page history에서 revision 비교와 특정 version의 영구 링크를 제공합니다.
LLM Wiki는 이 기본 구조를 버리지 않습니다. 대신 사람이 하던 초기 지식화 비용 일부를 LLM이 맡습니다.
| 단계 | 전통 위키 | LLM Wiki |
|---|---|---|
| 입력 | 사람이 알고 있는 내용 | 코드·문서·대화·로그 같은 원천 |
| 페이지 계획 | 편집자가 목차 설계 | LLM이 후보를 제안하고 사람이 steering |
| 초안 | 사람이 직접 작성 | LLM이 요약·관계·diagram 초안 생성 |
| 근거 | 편집 규칙과 인용 문화 | source path·span·commit을 기계적으로 연결 |
| 검수 | 동료 편집·revision review | schema·link·graph 검사 + human review |
| 소비 | browse·search | browse·search·Q&A·agent tool |
즉 LLM Wiki의 혁신은 “글을 자동으로 잘 써 준다”보다 흩어진 원천에서 page proposal을 만들고 다시 원천으로 돌아가는 비용을 낮춘다는 데 있습니다.
그림 1. LLM Wiki의 경계는 모델 이름이 아니라 영속 산출물, provenance, 탐색 구조, 검수·갱신, 재사용으로 정한다.
LLM Wiki를 판별하는 다섯 가지 기준
어떤 서비스가 이름에 Wiki를 붙였다고 모두 같은 종류는 아닙니다. 다음 질문 중 몇 개에 “예”라고 답할 수 있는지 확인합니다.
1. 답변 뒤에 재사용할 지식 산출물이 남는가?
대화가 끝나면 사라지는 response가 아니라 Markdown page, typed node, diagram, index처럼 안정된 식별자를 가진 artifact가 남아야 합니다.
질문 → 답변 → 종료
AI 챗봇
원천 → page/node/edge → 탐색·질문·다음 작업
LLM Wiki2. 각 주장과 관계에서 원천으로 돌아갈 수 있는가?
페이지 아래에 “참고 문서 20개”만 붙이는 것으로는 부족합니다. 중요한 claim이나 edge가 어느 source path, revision, span에서 나왔는지 추적할 수 있어야 합니다. Source가 바뀌었을 때 영향받는 page를 찾는 데도 같은 lineage가 쓰입니다.
3. 질문을 몰라도 둘러볼 구조가 있는가?
좋은 wiki는 질문을 정확히 만들기 전에도 table of contents, backlink, tag, hierarchy, graph로 영역을 파악하게 합니다. Chat-only interface는 사용자가 모르는 것을 모를 때 시작하기 어렵습니다.
4. 초안·검수·정본·폐기의 상태가 구분되는가?
LLM output을 곧바로 canonical page에 덮어쓰면 “생성”은 빨라도 “관리”는 불가능해집니다. 최소한 candidate와 approved를 나누고, source change 뒤 stale 상태를 표현해야 합니다.
5. 사람뿐 아니라 다음 AI 실행도 이 지식을 다시 쓰는가?
웹 page로만 읽어도 wiki지만, LLM Wiki의 효과는 agent context로 연결될 때 커집니다. DeepWiki MCP도 read_wiki_structure, read_wiki_contents, ask_question을 제공해 repository wiki를 agent가 programmatic하게 소비하도록 합니다. 자세한 도구 표면은 공식 DeepWiki MCP 문서에서 확인할 수 있습니다.
AI 챗봇·RAG·문서 생성기와 어디서 갈리는가?
세 가지를 기능 목록으로 비교하면 모두 “문서를 읽고 답하고 요약한다”고 보입니다. 차이는 무엇을 정본으로 남기고 언제 계산하는가에 있습니다.
AI 챗봇
대화가 주 산출물입니다. Session history를 저장할 수는 있지만, 여러 session의 결론을 stable page로 통합하는 단계는 별도입니다.
RAG
RAG는 외부 memory에서 query와 관련된 context를 가져와 response를 만드는 architecture입니다. 원래 RAG 논문도 dense vector index에서 passage를 retrieve해 generator를 조건화합니다. Index와 citation은 있어도 page plan, revision, human promotion이 자동으로 생기지는 않습니다. 반대로 LLM Wiki의 Q&A 층이 RAG를 사용할 수 있습니다.
일회성 문서 생성기
Repository를 읽고 ARCHITECTURE.md 하나를 만드는 도구는 유용합니다. 그러나 source 변화 감지, page별 provenance, 중복 병합, 검수 상태, 증분 재생성이 없다면 “wiki build”보다 “documentation generation”에 가깝습니다.
경계는 이 한 문장으로 정리됩니다.
RAG는 질문 시점의 context 선택 문제이고,
LLM Wiki는 지식 산출물의 생성·검수·갱신·재사용 문제다.두 시스템은 경쟁자가 아니라 자주 한 제품 안에 함께 존재합니다. 이 차이는 4편: LLM Wiki와 RAG의 차이에서 build time과 query time으로 더 정확히 나눕니다.
제가 직접 만들며 바뀐 정의
처음 개인 LLM Wiki 대시보드를 만들 때는 “agent 대화와 project 문서를 읽어 Markdown을 잘 만들면 된다”고 생각했습니다. 그래서 worker에게 문서를 쓰게 하고 마지막에 사람이 확인하는 그림이 자연스러워 보였습니다.
구현을 검토하면서 정의가 바뀌었습니다. Worker는 정본을 쓰는 주체가 아니라 evidence가 붙은 proposal을 만드는 주체여야 했습니다. Lead는 여러 proposal을 병합하고, writer는 승인된 plan만 staging에 적용하며, validator는 source·schema·link·graph를 기계적으로 확인해야 했습니다.
더 뼈아픈 문제도 있었습니다. 초기에 수백 개 test가 통과했지만 fake runner가 완벽한 JSON만 반환했고, agent는 실제 source text를 받지 않았습니다. “Evidence 기반”이라는 말이 prompt에만 있고 코드에는 없었던 셈입니다. 이 실패 뒤에야 source reader와 evidence verifier를 별도 경계로 만들었습니다.
이 경험에서 얻은 가장 짧은 정의는 다음입니다.
LLM Wiki의 품질은 모델이 얼마나 그럴듯하게 썼는지가 아니라, 생성된 지식이 원천으로 돌아가고 안전하게 다음 실행에 재사용되는지로 판단해야 합니다.
최소 아키텍처
처음부터 vector DB, graph database, multi-agent를 모두 넣을 필요는 없습니다. 최소 구조는 아래 여섯 단계면 됩니다.
1. authoritative source inventory + content hash
2. bounded source reader
3. evidence-bearing page proposal
4. deterministic render to staging
5. schema/link/source validation + human review
6. approved page promotion + search여기서 가장 먼저 지켜야 할 불변조건은 세 가지입니다.
- 원천을 생성 pipeline이 수정하지 않는다.
- LLM output이 canonical을 직접 덮어쓰지 않는다.
- 근거 없는 claim을 “검증됨” 상태로 승격하지 않는다.
Vector search와 graph retrieval은 이 기초 위에 추가합니다. 기초가 없으면 검색 성능이 좋아져도 더 빠르게 낡은 문서와 근거 없는 요약을 배포할 뿐입니다.
자주 묻는 질문
LLM Wiki는 DeepWiki의 일반명인가?
이 시리즈에서는 더 넓게 사용합니다. DeepWiki는 code repository를 자동 문서화하는 대표적인 제품 사례이고, LLM Wiki는 개인 연구 노트·조직 지식·도메인 graph·agent memory까지 포함할 수 있는 실무 범주입니다.
Notion AI나 NotebookLM도 LLM Wiki인가?
기능에 따라 다릅니다. Source-grounded Q&A만 제공하면 conversational knowledge base에 가깝고, 출처가 연결된 영속 page·구조·revision·갱신 workflow까지 만들면 이 글의 LLM Wiki 기준에 가까워집니다. 제품 전체에 하나의 꼬리표를 붙이기보다 사용 중인 mode의 산출물을 봐야 합니다.
반드시 Knowledge Graph가 필요한가?
아닙니다. Markdown page와 명시적인 link만으로도 좋은 LLM Wiki를 만들 수 있습니다. 관계 질의, lifecycle constraint, cross-project traversal이 중요해질 때 typed graph를 추가합니다.
LLM이 기존 wiki를 자동 수정하게 해도 될까?
초안 생성은 가능하지만 canonical 자동 overwrite는 늦게 여는 편이 안전합니다. Proposal, diff, validation report, human approval을 먼저 만들고 반복적으로 안전성이 확인된 좁은 범위만 자동 승격합니다.
마무리
LLM Wiki는 “문서에 ChatGPT를 붙인 것”보다 넓고, “RAG의 새 이름”도 아닙니다.
- 원천에서 page·node·edge를 materialize합니다.
- Claim과 relation을 source에 연결합니다.
- 질문 없이도 탐색할 구조를 만듭니다.
- Candidate·review·canonical·stale 수명주기를 둡니다.
- 사람과 다음 agent가 같은 지식을 다시 씁니다.
다음 글 LLM Wiki가 인기인 이유에서는 이 형태가 2025년 이후 코드 이해 도구와 AI 에이전트 생태계에서 빠르게 주목받은 이유를 살펴봅니다. “인기”를 과장된 시장 규모가 아니라 공개 repository 수, 오픈소스 채택, MCP 연결, context engineering의 변화로 검증합니다.