LLM Wiki Operating Model
원문은 RAG와의 핵심 차이를 지속·누적되는 wiki artifact로 규정하며, 이 page는 그 누적을 가능하게 하는 운영 조건을 도구가 아니라 역할 분담으로 본다(해석). 사람은 source를 고르고 판단을 내리며, LLM은 Wiki의 cross-link, update, logging 같은 maintenance를 맡는다 — 사람은 거의 wiki를 직접 쓰지 않고, LLM이 wiki를 작성·유지하는 동안 사람은 소싱과 탐색, 좋은 질문에 집중한다.[1]
flowchart LR H[Human: source·question·judgment] --> R[Raw] R --> I[LLM ingest] I --> W[Wiki] W --> Q[Wiki-first query] Q -->|reusable + consent| I
책임 분리
세 layer(Raw, Wiki, Schema)에 사람과 LLM의 역할을 겹쳐 보면 아래 표가 된다. Raw는 사람이 큐레이션하지만 LLM이 읽기만 하는 immutable source of truth이고, Wiki는 LLM이 전적으로 소유해 쓰는 markdown layer이며, Schema는 LLM이 disciplined maintainer로 행동하도록 사람과 함께 발전시키는 설정 문서다.[1:1]
| 주체 | 책임 | 맡기면 안 되는 일 |
|---|---|---|
| 사람 | source를 제공하고, 민감도·우선순위·영구 보존 여부를 판단 | LLM output을 검증 없이 source로 승인 |
| Raw | 원문과 provenance 보존 | reader-facing knowledge graph 역할 |
| LLM ingest | source를 concept/pattern/comparison 구조로 재조립 | 원문에 없는 fact를 확정적으로 추가 |
| Wiki | 재사용 가능한 설명, link, boundary, query entry point 제공 | 모든 개인 메모와 대화의 archive |
| Schema/tooling | 반복 가능한 quality gate와 workflow 제공 | 지식의 진실성 자체를 판정 |
운영 순환
- 사람이나 agent가 새 source 또는 질문을 가져온다.
- agent는 existing Wiki를 먼저 읽어 중복 page 대신 기존 knowledge를 재사용한다 — 질문에 답할 때 index를 먼저 읽고 관련 page로 들어가는 방식이 embedding 기반 RAG 인프라 없이도 중간 규모(약 100개 source, 수백 개 page)에서 잘 작동한다고 원문은 설명한다.[2]
- source가 새 claim이나 correction을 지지하면 Raw를 보존하고 Wiki를 갱신한다.
- 페이지 변경 뒤에는 source summary, index, 관련 page, log를 함께 갱신해 다음 query가 변경을 찾을 수 있게 한다 — 원문의 ingest 예시는 summary page 작성, index 갱신, 관련 entity·concept page 갱신, log 항목 추가를 한 흐름으로 묶는다.[3] overview 갱신과 fidelity check는 원문이 아니라 이 vault의 Ingest workflow가 더하는 절차다. log가 일관된 prefix로 작성되면
grep "^## \[" log.md | tail -5같은 명령으로 최근 항목을 바로 확인할 수 있고, 이 timeline이 LLM이 최근 작업을 파악하는 데도 쓰인다.[3:1] - lint와 completion gate는 link·frontmatter·작업 흔적을 검사하고, audit는 claim·visual·boundary의 질을 검사한다.
- log 없이 page만 바꾸면 나중에 어떤 source가 어떤 결정을 바꿨는지 추적하기 어렵다 — 이는 4번 단계에서 log 갱신을 함께 요구하는 이유이기도 하다.
- automated gate만 믿으면 source blur와 overgeneralization을 놓친다. 반대로 review만 하고 deterministic check를 생략하면 link와 navigation이 깨질 수 있다 — 5번 단계의 lint/gate와 audit를 둘 다 두는 이유로 볼 수 있다.
왜 독립 모델인가
- 단순 노트 모음은 찾을 수 있어도 어떤 note가 최신 모델인지 알기 어렵다고 판단된다.
- 단순 RAG는 source를 찾을 수 있어도, 매 질문마다 지식을 다시 발견할 뿐 repeated explanation과 cross-source decision을 남기지 않는다 — LLM Wiki는 이 재발견을 없애기 위해 질문 시점마다 raw 문서를 다시 검색하는 대신 지속되는 위키를 점진적으로 구축·관리한다.[4]
- source layer와 generated layer를 섞으면 변경·삭제·검증의 기준이 사라진다는 점이 이 모델이 Raw/Wiki/Schema를 독립된 layer로 두는 이유라고 해석할 수 있다. LLM Wiki는 사람이 읽는 Markdown page와 agent가 추적하는 provenance를 같은 운영 loop에서 다룬다.
운영 구분
index.md: content-oriented catalog. 위키 전체를 category별로 나열하고, LLM은 ingest 때마다 갱신하며 query에 답할 때 가장 먼저 읽는다.[2:1]log.md: chronological change record. append-only로 ingest·query·lint 시점을 기록해 위키 진화의 timeline을 제공한다.[3:2]Schema/: LLM의 discipline을 위한 operating rules.
경계
이 운영 모델은 현재 Raw source를 기반으로 한 방법론이다. 특정 CLI, Graphify, Dataview는 선택 도구이지 모델의 필수 조건이 아니다.
관련
- Persistent Wiki — 유지하는 knowledge layer의 기본 모델이다.
- RAG vs Persistent Wiki — retrieval과 persistence의 역할 경계다.
- Query Compounding — 운영 loop에서 답변을 지식으로 바꾸는 pattern이다.
출처
LLM wiki 참고자료.md — "This is the key difference: the wiki is a persistent, compounding artifact." (L17), "You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work...", "Raw sources... These are immutable — the LLM reads from them but never modifies them. This is your source of truth.", "The wiki... The LLM owns this layer entirely... You read it; the LLM writes it.", "The schema... it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain." (L19, L35-L39) ↩︎ ↩︎
LLM wiki 참고자료.md — "index.md is content-oriented. It's a catalog of everything in the wiki... The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure." (L57), "integrates it into the existing wiki — updating entity pages, revising topic summaries" (L15) ↩︎ ↩︎
LLM wiki 참고자료.md — "log.md is chronological. It's an append-only record of what happened and when... if each entry starts with a consistent prefix... the log becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently." (L59), "An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log." (L45) ↩︎ ↩︎ ↩︎
LLM wiki 참고자료.md — "the LLM is rediscovering knowledge from scratch on every question. There's no accumulation... Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki." ↩︎