Knowledge Integrated Root

LLM Wiki 지식통합 루트

기존 42개 HTML 산출물을 하나의 운영 방법론으로 합성한 정적 루트 페이지다. 결론은 단순하다. LLM Wiki는 질문할 때마다 답을 새로 만드는 장치가 아니라 raw 원천, wiki 해석, rules 운영 계약을 분리하고 질문, 검증, 반영, 감사를 반복하는 업무 지식 시스템이다.

LLM Wiki 핵심 thesis

42개 HTML이 반복해서 말하는 핵심은 LLM 대화에서 사라지는 맥락을 파일 기반 지식 자산으로 바꾸자는 것이다. 반복되는 설명, 판단 기준, 예외 조건, 보고서 톤, 고객 정보 제외 규칙은 프롬프트를 더 길게 쓰라는 신호가 아니라 wiki로 승격할 지식 후보다.

RAG와의 차이

RAG는 질문 시점의 검색과 답변 생성에 강하다. LLM Wiki는 그 과정에서 생긴 구조, 비교, 결정, 확인 필요 항목을 다음 작업의 입력으로 남긴다.

성공 기준

좋은 답변이 아니라 지속 갱신 가능한 저장소가 남아야 한다. 원천 보존, 근거 라벨, update log, lint/review가 핵심 기준이다.

사람의 역할

사람은 모든 문서를 직접 쓰는 대신 자료 선택, 질문 설계, 근거 검증, 승인 범위, 주제 분리와 archive 판단을 맡는다.

소스 역할 구분

index.html과 tree.html은 생성된 탐색면이다. 두 문서는 전체 코퍼스의 길잡이와 coverage map 역할을 하며, 두꺼운 본문 근거라기보다 링크 구조와 읽기 순서를 검수하는 표지다.

wikidocs/index.html은 WikiDocs 책 루트 방법론이다. 8개 장 개요와 25개 세부 절 분석을 LLM위키 운영 루프로 묶는 내부 중심 근거다. wikidocs/serving-index.html은 같은 코퍼스를 외부 서빙 관점에서 검수하는 라우팅 문서다.

llm-wiki-integrated-analysis.html은 GeekNews, WikiDocs 시작 방식, YouTube 튜토리얼을 포함해 외부 레퍼런스까지 합친 상위 통합 분석이다. 나머지 top-level HTML은 기사/영상 기반 보조 분석으로 개념 논쟁, Obsidian/UX 적용, Karpathy식 setup, 시작 방식 선택을 보강한다.

raw/wiki/rules 구조

raw

회의록, 웹 문서, 영상 자막, 정책, 로그, 코드 diff 같은 source of truth를 보존한다. raw에는 판단과 요약을 섞지 않는다.

wiki

LLM이 raw를 읽고 만든 주제 문서, 비교표, 결정 기록, FAQ, 관련 문서 링크다. wiki는 원본이 아니므로 근거, 확인일, 적용 범위가 필요하다.

rules

문서 골격, citation, 금지 사항, 민감정보 처리, 갱신 방식, lint 조건을 고정하는 운영 계약이다. Codex에서는 AGENTS.md와 handoff schema가 여기에 해당한다.

시작 방식 선택

시작 방식은 도구 취향이 아니라 운영 조건으로 고른다. 수동 Markdown은 초보용 임시방편이 아니라 가장 작은 기준선이다. 작은 raw 샘플과 주제 하나로 citation, 문서 형식, 검증 질문이 작동하는지 확인한 뒤 agent, CLI, desktop app, Obsidian vault로 넓힌다.

Node.js CLI류는 반복 ingest/compile/query 자동화에 강하고, Python/OpenKB류는 PDF, Word, Markdown 같은 혼합 문서 처리에 유리하다. Obsidian과 desktop app은 사람이 링크와 구조를 보기에 좋다. 공통 조건은 민감정보 경계, provider/API key 관리, diff review, rollback, 생성물 검증 가능성이다.

첫 주제 위키 생성

  1. 다음 질문이 예상되는 좁은 업무 주제를 고른다.
  2. raw, wiki, output, rules, log 또는 index의 최소 구조를 만든다.
  3. 첫 질문을 검색어가 아니라 역할, 목적, 근거 범위, 출력 형식이 있는 업무 요청으로 쓴다.
  4. 생성된 wiki에서 근거 없는 단정과 누락 조건을 표시한다.
  5. 두 번째 자료를 넣어 새 페이지 생성, 기존 문서 갱신, 충돌 표시가 작동하는지 본다.

자료 수집과 근거화

자료 인입 전에 기준을 정한다. 다시 물어볼 가능성, 현재 결정과의 관련성, 출처 신뢰도, 민감정보 여부, 최신성 요구가 기준이다. 모든 자료를 넣는 것은 지식 축적이 아니라 질문 범위를 흐릴 수 있다.

정리된 wiki는 문장 단위 근거 라벨을 가져야 한다. 확정, 제한적 확인, 추정, 확인 필요, 최신성 확인 필요를 나누고, 근거 없는 자연스러운 문장을 업무 산출물로 승격하지 않는다.

질문과 검증

좋은 질문은 “요약해줘”가 아니라 업무 요청이다. 역할, 목적, 사용할 근거, 제외 범위, 출력 형식, 검증 기준을 포함해야 한다. 답변은 전체 인상으로 승인하지 않고 핵심 주장마다 raw 근거와 wiki 근거를 확인한다.

답변 이후에는 바로 반영할 지식, output으로만 남길 산출물, 확인 필요 후보로 나눈다. 반영할 때는 관련 문서 링크, index, log, 반복 질문 템플릿까지 갱신해야 다음 질문에서 재사용된다.

업무 산출물 생성

LLM Wiki의 output은 보고서, 회의 준비 문서, 실행 항목, 비교표, 제안서, 디자인 리서치 요약, 운영 체크리스트로 나타난다. output은 목적, 독자, 결정할 항목, 근거, 확인 필요, 다음 행동을 갖춰야 한다.

업무 보고서는 예쁜 요약이 아니라 결정을 줄이는 문서다. 실행 항목은 담당자, 할 일, 기한, 근거, 완료 기준을 포함해야 한다. 실제로 쓰인 output의 결정 결과와 새 근거는 wiki/log로 돌아와야 한다.

장기 감사와 운영

위키가 커질수록 위험은 문서 수보다 맥락 혼탁이다. 같은 핵심 질문, 독자, 보안 등급, 산출물 형식인지 기준으로 주제 분리 여부를 판단한다. 세 개 이상의 주제는 인벤토리로 상태, 마지막 갱신일, 다음 행동, 대표 산출물을 관리한다.

감사는 삭제가 아니라 신뢰 경계 회복이다. 주간 15-30분 루틴으로 최근 사용 문서 1-3개를 골라 출처 누락, 오래된 주장, 모순, 중복, 링크 단절을 확인한다. 오래된 주제는 삭제보다 archive로 분리한다.

Discord-Codex/write-agent 적용

Discord-Codex 환경에서 raw는 Discord message, 승인 기록, runtime logs, git diff, test output, sourceManifest, 첨부 원문이다. wiki는 운영 문서, 이슈 분석, 통합 artifact, 결정 기록, 반복 프롬프트 패턴이다. rules는 AGENTS.md, write-agent handoff, 승인 범위, output path boundary, artifact safety policy다.

write-agent 방식은 parent prompt에 모든 원문을 붙이지 않고 sourceManifest로 경계를 준 뒤 로컬 artifact를 직접 읽어 통합 문서를 만드는 점에서 LLM Wiki 원칙과 맞다. served HTML은 local Markdown 링크 대신 대응 HTML 링크를 사용하고, script, iframe, remote asset, absolute local path를 포함하지 않아야 한다.

읽기 경로

처음 만드는 사람

WikiDocs 루트, 1장, 2장, 4장을 순서대로 읽는다.

바로 실험할 사람

3장, 4.1-4.3, Karpathy 튜토리얼 분석을 본다.

자료가 많아진 사람

5장, 6장, 8.2, 8.3으로 근거화와 audit 흐름을 만든다.

업무 산출물이 필요한 사람

7장 전체와 Obsidian/UX 분석을 연결한다.

검증 체크리스트

전체 source map

아래 42개 링크는 이번 통합의 입력 HTML 전체다. Cloudflare Pages에서는 이 페이지를 루트로 두고 같은 상대 경로의 정적 HTML을 함께 제공하면 된다.