Schema는 위키의 운영 헌법이다
LLM Wiki를 만들 때 많은 사람이 먼저 폴더부터 만든다. raw/, wiki/, assets/, logs/를 만들고, Obsidian에서 열어본다. 여기까지는 쉽다. 하지만 이 상태에서 AI에게 "정리해줘"라고만 말하면 결과는 곧 흔들린다.
어떤 날은 concepts/에 파일을 만들고, 어떤 날은 ideas/에 만든다. 한 번은 출처를 각주로 남기고, 다음에는 본문에 대충 적는다. 비슷한 개념을 다른 이름으로 두 번 만들기도 한다. 처음에는 작은 차이처럼 보이지만, 위키가 커질수록 이런 차이는 구조적 부채가 된다.
Schema는 이 문제를 막는 운영 규칙이다. Claude Code를 쓴다면 CLAUDE.md, Codex나 다른 에이전트를 쓴다면 AGENTS.md가 그 역할을 한다. 이 파일은 AI에게 "너는 지금부터 이 위키의 관리자이며, 다음 규칙에 따라 움직인다"라고 알려주는 문서다. Claude Code는 프로젝트 안의 CLAUDE.md를 세션 시작 시 읽어 프로젝트의 규칙과 구조를 이해할 수 있도록 설계되어 있다1.
중요한 점은 Schema를 프롬프트 한 줄로 생각하지 않는 것이다. Schema는 제품 설계다. 좋은 LLM Wiki의 품질은 좋은 모델보다 좋은 Schema에서 더 자주 결정된다. 같은 자료를 넣어도 Schema가 분명하면 AI는 일관된 편집자가 되고, Schema가 없으면 매번 새로 온 인턴처럼 행동한다.
먼저 책임 경계를 정한다
첫 번째 Schema에서 가장 먼저 써야 할 것은 폴더의 책임이다. AI가 어디를 읽을 수 있고, 어디를 수정할 수 있는지 명확히 나눠야 한다.
LLM Wiki의 기본 원칙은 단순하다.
raw/는 원문 저장소다.wiki/는 AI가 만든 지식층이다.assets/는 이미지, 첨부파일, 도표 같은 보조 자료를 둔다.logs/또는log.md는 변경 기록을 남긴다.index.md는 전체 위키의 지도다.
여기서 가장 중요한 규칙은 raw/를 수정하지 않는 것이다. 원문은 증거다. AI가 만든 위키 페이지가 틀렸을 때 돌아가 확인할 수 있는 기준점이다. 여러 LLM Wiki 구현 가이드도 raw source는 불변이며, AI는 읽기만 하고 위키 층을 생성·갱신해야 한다고 강조한다2.
Schema에는 다음처럼 짧고 강하게 적는다.
## Project Boundaries
- `raw/` contains immutable source materials. Read only. Never edit, rename, summarize in place, or delete files here.
- `wiki/` contains LLM-generated knowledge pages. You may create and update files here.
- `assets/` contains copied images and attachments. Do not delete without user approval.
- `logs/` and `log.md` contain append-only operation records.
- `index.md` is the navigation map. Update it whenever important wiki pages are created or changed.이 정도만 있어도 AI의 행동이 달라진다. "전체 폴더를 정리해줘"라는 요청을 받아도 원문을 건드리지 않고, 위키 층에 해석을 쌓는 방향으로 움직인다.
페이지 유형을 정하면 위키가 재사용된다
다음은 페이지 유형이다. 모든 문서를 같은 방식으로 만들면 위키는 금방 두꺼운 요약집이 된다. LLM Wiki는 요약집이 아니라 지식 지도다. 자료의 성격에 따라 페이지 유형을 나눠야 한다.
처음에는 다섯 가지면 충분하다.
개념 페이지: 아이디어, 이론, 방법론
인물 페이지: 사람, 저자, 창업자, 연구자
책·논문 페이지: 특정 책, 논문, 보고서
프로젝트 페이지: 제품, 사업, 연구, 글쓰기 프로젝트
의사결정 페이지: 왜 그렇게 결정했는지 남기는 기록
각 페이지에는 YAML frontmatter를 둔다. frontmatter는 마크다운 파일 맨 위에 붙는 구조화된 메타데이터다. Obsidian, Dataview, 검색 도구가 이 정보를 읽어 필터링과 표 생성을 할 수 있다.
예를 들어 개념 페이지는 이렇게 정한다.
---
title: "LLM Wiki"
type: concept
tags: [wiki/concept, needs_review]
created: 2026-05-19
updated: 2026-05-19
sources:
- raw/articles/karpathy-llm-wiki.md
source_count: 1
confidence: medium
related:
- "[[RAG]]"
- "[[Obsidian]]"
---책이나 논문 페이지는 조금 다르다.
---
title: "논문 또는 책 제목"
type: source-work
author: "저자"
year: 2026
tags: [wiki/source-work]
created: 2026-05-19
updated: 2026-05-19
raw_path: raw/books/example.md
status: draft
---의사결정 페이지에는 결정일, 선택지, 근거, 검토 상태가 필요하다.
---
title: "Markdown 위키를 기본 저장 형식으로 선택"
type: decision
date: 2026-05-19
tags: [wiki/decision]
status: accepted
review: none
related:
- "[[Markdown]]"
- "[[Obsidian]]"
---처음부터 필드를 너무 많이 만들 필요는 없다. 필드가 많으면 AI가 채우는 데 집중하고, 사람은 검토하기 어려워진다. 시작 단계에서는 title, type, tags, created, updated, sources, confidence, related 정도면 충분하다.
출처 규칙은 선택이 아니라 안전장치다
LLM Wiki에서 가장 위험한 순간은 AI가 원문 내용과 자기 일반 지식을 섞을 때다. 겉으로는 그럴듯한 위키 페이지가 생기지만, 나중에 확인해보면 어떤 주장이 어디서 왔는지 알 수 없다. 이런 위키는 시간이 지날수록 똑똑해지는 것이 아니라, 출처 없는 확신을 축적한다.
그래서 Schema에는 출처 규칙을 반드시 넣어야 한다.
## Evidence Rules
- Every important factual claim must include evidence.
- Evidence must point to the original raw source path.
- When possible, include document title, section name, page number, timestamp, or quote location.
- Wiki pages are interpretation and synthesis. Raw files are evidence.
- Do not present unsupported assumptions as facts.출처는 꼭 복잡한 학술 인용일 필요는 없다. 실무에서는 다음 정도면 충분하다.
- 근거: `raw/meetings/2026-05-19-product-interview.md`, "가격 민감도" 섹션
- 근거: `raw/papers/example-paper.pdf`, p. 12, Table 3
- 근거: `raw/transcripts/video-001.md`, 00:13:20–00:15:05중요한 것은 "위키는 해석이고, raw는 증거"라는 원칙이다. 이 원칙을 지키면 나중에 AI가 만든 설명을 검증할 수 있다. 일부 LLM Wiki 실험에서는 모든 사실에 원본 각주를 강제하고, 충돌이 생기면 조용히 병합하지 않고 별도 표시하는 방식을 사용한다3. 이 규칙은 번거로워 보이지만, 위키가 커질수록 가장 큰 자산이 된다.
새 페이지를 만들지, 기존 페이지를 고칠지 정한다
AI에게 자료를 넣을 때 가장 자주 생기는 문제가 중복 페이지다. 예를 들어 RAG.md, Retrieval-Augmented-Generation.md, 검색증강생성.md가 따로 생기면 위키는 빠르게 흐트러진다. 따라서 Schema에는 ingest 판단 규칙이 있어야 한다.
## Ingest Decision Rules
When ingesting a new source:
1. Read `index.md` first.
2. Search existing `wiki/` pages for overlapping concepts, people, projects, and decisions.
3. Prefer updating an existing page when the topic already exists.
4. Create a new page only when:
- the concept is genuinely new,
- the source introduces a distinct person, project, book, paper, or decision,
- existing pages would become too broad if this content were added.
5. If two pages overlap, do not create a third page. Propose a merge.
6. After changes, update `index.md` and append an entry to `logs/log.md`.이 규칙은 AI에게 "쓰기 전에 먼저 찾아라"라고 말하는 장치다. LLM Wiki의 ingest는 단순 요약이 아니다. 새 자료가 기존 지식 구조를 어떻게 바꾸는지 판단하는 작업이다. Karpathy식 패턴에서 ingest는 소스 요약을 만들고, 관련 엔티티와 개념 페이지를 갱신하고, index와 log를 업데이트하는 반복 가능한 운영 절차로 설명된다4.
모순과 불확실성을 숨기지 않는다
좋은 위키는 모든 것을 깔끔하게 정리한 위키가 아니다. 무엇이 확실하고, 무엇이 불확실하며, 무엇이 충돌하는지 드러내는 위키다.
AI는 종종 모순을 부드럽게 합쳐버린다. A 자료는 "이 기능이 고객 유지율을 높였다"고 말하고, B 자료는 "효과가 불분명했다"고 말하는데, AI가 "일부 효과가 있었다"처럼 중간 문장으로 정리해버리는 식이다. 이렇게 하면 갈등은 사라지지만, 판단에 필요한 정보도 사라진다.
Schema에는 검토 태그를 정해둔다.
## Review Tags
Use these tags when needed:
- `needs_review`: human review required
- `conflict`: source contradicts another source or wiki page
- `low_confidence`: weak evidence or uncertain interpretation
- `outdated`: likely superseded by newer information
- `source_needed`: claim needs stronger evidence그리고 페이지 안에는 검토 섹션을 둔다.
## 검토 필요
- `conflict`: A 자료는 기능 X가 전환율을 높였다고 말하지만, B 회의록에서는 유의미한 변화가 없었다고 기록한다.
- `low_confidence`: 표본 수가 작아 일반화하기 어렵다.AI가 판단해야 할 일과 사람이 판단해야 할 일을 나누는 것이 중요하다. AI는 모순을 발견하고 정리할 수 있다. 그러나 어떤 출처를 더 신뢰할지, 어떤 결정을 내릴지는 사람이 해야 한다.
첫 번째 CLAUDE.md 초안
아래는 바로 사용할 수 있는 최소 Schema다. 너무 길게 시작하지 말자. 처음에는 짧고 분명한 규칙이 낫다.
# LLM Wiki Schema
## Purpose
This project is an LLM-maintained knowledge wiki. The goal is to turn raw sources into durable, linked, evidence-backed Markdown knowledge pages.
## Folder Roles
- `raw/`: immutable source materials. Read only. Never edit.
- `wiki/`: LLM-generated knowledge pages. Create and update here.
- `assets/`: images and attachments.
- `logs/`: operation logs.
- `index.md`: master map of important wiki pages.
## Core Rules
- Do not modify files in `raw/`.
- Use Markdown and Obsidian `[[wikilinks]]`.
- Every important factual claim needs evidence from `raw/`.
- Prefer updating existing pages over creating duplicates.
- Record every meaningful change in `logs/log.md`.
- Update `index.md` when new important pages are created.
## Page Types
Allowed `type` values:
- `concept`
- `person`
- `source-work`
- `project`
- `decision`
- `synthesis`
Every wiki page should include frontmatter with these fields:
title:
type:
tags:
created:
updated:
sources:
confidence:
related:
## Ingest Workflow
1. Read the new source completely.
2. Read `index.md`.
3. Find related existing wiki pages.
4. Create a source summary if useful.
5. Update related concept, person, project, or decision pages.
6. Add evidence references to raw paths.
7. Mark conflicts or weak claims with review tags.
8. Update `index.md`.
9. Append a log entry.
## Query Workflow
1. Read `index.md` first.
2. Read relevant wiki pages.
3. Answer using wiki links and source-backed claims.
4. If the answer creates reusable knowledge, save it as a `synthesis` page after user approval.
## Lint Workflow
Check for:
- duplicate pages
- orphan pages
- broken wikilinks
- claims without sources
- outdated pages
- conflicts between pages
- important concepts without pages
Do not silently fix high-impact conflicts. Mark them for human review.이 초안은 완벽하지 않다. 하지만 충분히 좋다. 좋은 Schema는 처음부터 완성되는 문서가 아니라, 운영하면서 개선되는 문서다.
Schema도 주기적으로 다듬는다
첫 번째 Schema를 만든 뒤에는 바로 대량 자료를 넣지 말자. 자료 2~3개만 먼저 ingest한다. 결과를 읽어보고 다음을 확인한다.
파일명이 마음에 드는가?
frontmatter가 검색과 Dataview에 쓸 만한가?
출처가 충분히 추적 가능한가?
AI가 기존 페이지를 잘 갱신했는가?
중복 페이지를 만들지 않았는가?
index.md와log.md가 실제로 도움이 되는가?
문제가 보이면 Schema를 고친다. 예를 들어 AI가 자꾸 새 페이지를 만든다면 "기존 페이지 검색 후 생성" 규칙을 더 강하게 쓴다. 출처가 약하다면 "모든 핵심 주장에 raw 경로와 위치 정보를 붙이라"고 보강한다. 모순을 덮어버린다면 conflict 태그와 검토 섹션을 의무화한다.
Schema는 AI에게 주는 명령서이면서, 나 자신에게 주는 운영 기준이기도 하다. 이 파일이 분명할수록 위키는 덜 흔들린다. 이제 우리는 폴더만 가진 사람이 아니라, AI 위키 관리자를 고용한 사람에 가까워졌다.
다음 단계는 실제 자료를 넣는 일이다. 좋은 Schema가 준비되면 ingest는 단순한 요약 작업이 아니라, 지식이 기존 구조 안으로 흡수되는 과정이 된다.
참고
1Give Claude context: CLAUDE.md and better prompts
2LLM-Wiki Obsidian Setup Guide
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.