Persistent Wiki

Persistent Wiki는 질문 때마다 새로 만드는 답이 아니라, source를 ingest해 계속 유지하는 지식 layer다. 핵심 흐름은 Raw → ingest → interlinked Wiki → query → optional compounding로 요약된다 — 새 source가 기존 concept, comparison, synthesis를 갱신하거나, 갱신하지 못할 만큼 어긋나면 그 contradiction을 남긴다.

세 layer와 각자의 역할

Raw는 immutable source of truth다. articles, papers, images, data files처럼 사람이 가져온 원문을 LLM이 읽되 수정하지 않는다.^[1] 원문을 예쁘게 정리하는 장소가 아니라 claim을 되짚는 근거다.
Wiki는 LLM이 생성·유지하는 markdown knowledge layer다. summary, entity page, concept page, comparison, overview, synthesis를 포함할 수 있고, 이 layer를 LLM이 전적으로 소유해 page 생성·업데이트·cross-reference 유지·일관성 관리를 맡는다 — 사람은 읽고 LLM은 쓴다.^[1:1]
Schema는 ingest, query, maintenance 규칙을 LLM에게 제공하는 설정 문서다. LLM을 generic chatbot이 아니라 disciplined wiki maintainer로 만드는 핵심 구성 요소이며, 사람과 LLM이 시간이 지나며 함께 발전시킨다.^[1:2]

ingest는 Raw의 목차를 복제하는 일이 아니라, 여러 source에서 반복되는 개념·적용 조건·예외·비교 기준을 Wiki page의 구조로 다시 만드는 작업이라고 볼 수 있다. Wiki page도 현재 질문에 답하는 데 그치지 않고, 다음 질문이 바로 이어질 수 있도록 related page와 reading path를 제공해야 한다는 것이 이 모델의 요구라고 해석된다. Schema와 lint는 정답을 생성하지 않으며, source link·page type·navigation·log처럼 반복해서 빠지기 쉬운 운영 규율을 강제하는 역할에 그친다.

경계: 무엇이 Persistent Wiki가 아닌가

Raw archive나 단순 검색 인덱스 자체는 Persistent Wiki가 아니다. Raw는 원문의 근거일 뿐 재사용 가능한 구조로 재조립되지 않았기 때문이다.
모든 질문을 새 page로 만들지 않는다 — 재사용되는 지식만 compound한다.
query는 먼저 Wiki를 읽어 이미 검증한 모델을 재사용하고, 필요한 경우에만 Raw로 내려가 source fidelity나 최신성을 확인한다.
새로운 source가 기존 모델을 지지하면 page를 보강하고, 범위를 좁히면 boundary를 수정하며, 충돌하면 양쪽 scope와 uncertainty를 함께 남긴다 — 다수결로 어느 한쪽을 지우지 않는다는 뜻으로 읽을 수 있다.

공개 전 상태를 별도로 두는 이유

AI가 만든 분류나 Wiki 초안은 ingested knowledge와 같은 상태가 아니다. source link·공개 범위·검수 결과가 확인되기 전에는 draft로 남긴다.

사람이 승인한 산출물만 reader-facing Wiki와 chatbot retrieval에 들어간다.^[2] 승인되지 않은 초안을 검색 대상으로 삼으면 아직 검증되지 않은 주장도 답변의 근거처럼 보이게 되기 때문이라는 이유는 이 page의 해석이다.
source가 갱신되거나 처리에 실패하면 기존 위키 정보, 검수 대기 상태, 실패 단계와 사유를 구분해서 관리하고, 승인 전 갱신안끼리는 자동 병합하지 않는다.^[2:1] 이 구절들로부터 오류가 난 처리를 조용히 최신 knowledge로 대체하지 않는다고 읽는 것은 이 page의 해석이다.

이 경계는 원문 요구사항에 나타난 사내 위키 서비스의 product design 사례이며, 모든 Wiki 시스템이 같은 상태명이나 저장 구조를 써야 한다는 표준은 아니다.

유지 판단

상황	우선 행동	이유
같은 개념을 다시 설명해야 함	기존 concept 갱신	중복 page보다 하나의 모델이 검색과 유지에 유리하다
두 접근의 선택이 반복됨	comparison 추가	선택 조건과 혼동 지점을 고정한다
source가 서로 다른 결론을 냄	synthesis 또는 기존 page의 uncertainty	다수결로 지우지 않고 scope를 보존한다
개인 대화의 일회성 맥락	defer	Raw와 Wiki의 signal-to-noise를 지킨다

Ingest·유지에서 흔히 깨지는 지점

Raw note마다 Wiki page를 하나씩 만들면 → source shape를 그대로 따라가게 되어 concept graph가 조각난다.
citation만 있고 page가 질문·관계·경계를 설명하지 않으면 → retrieval 결과를 사람이 다시 조립해야 하는 부담이 남는다.
최신성이 필요한 claim을 오래된 Wiki 문장만으로 답하면 → persistent knowledge가 오히려 stale knowledge가 된다.

출처

LLM wiki 참고자료.md — "Raw sources — your curated collection of source documents... These are immutable — the LLM reads from them but never modifies them. This is your source of truth.", "The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely... You read it; the LLM writes it.", "The schema — a document... that tells the LLM how the wiki is structured... it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time." ↩︎ ↩︎ ↩︎
요구사항 명세서.md — FR-WIKI-003 위키 승인: "관리자는 위키 초안을 검수한 후 공개하거나 반려할 수 있어야 한다.", "공개 전 위키는 사원에게 노출하지 않으며 챗봇 검색 대상으로 사용하지 않는다."; FR-DOC-005 문서 처리 상태 관리(업로드 완료·파싱 중·파싱 실패·분류 중·분류 완료·위키 생성 중·위키 생성 실패·처리 완료·처리 실패)와 "문서의 승인/반려/비공개/삭제 여부는 별도의 문서 운영 상태로 관리한다."; NFR-AI-003 장애 대응: "AI 처리, 문서 파싱, 일정 추출 실패 시 실패 상태와 사유를 제공해야 한다."; FR-WIKI-005 위키 버전 관리(L90): "시스템은 위키의 정보가 바뀔 경우, 기존 위키의 정보를 관리해야 한다."; 문서 처리 상태값(L163): "문서 운영 상태는 초안, 검수 대기, 승인, 반려, 비공개, 삭제로 관리한다."; AI 처리 흐름(L164): "실패 시 실패 단계와 사유를 저장하며"; 위키 갱신 충돌 처리(L166): "승인 전 갱신안끼리는 자동 병합하지 않는다." ↩︎ ↩︎