# 원고만 쓰고 나머지는 기계에게: 편집 지도·자동 배포·정비로 바꾼 위키 운영

누적형 위키는 성공할수록 운영이 무거워진다. 문서가 늘면 새 지식을 넣기 전에 확인할 것도 늘고, 원고 옆에 따라붙는 색인과 생성 파일도 함께 불어난다. 문서가 100개를 넘긴 시점에 이 위키에서 실제로 무거워진 것은 지식 자체보다 그 **부속물**이었다. 매번 읽어야 하는 안내 자료와, 원고를 고칠 때마다 함께 맞춰야 하는 생성 파일이다. 2026년 10월 26일의 운영 개편은 이 둘을 덜어 내는 데서 출발했다. 원고의 상세함과 기존 주소는 그대로 두고, 사람과 AI가 매번 읽고 쓰는 양만 줄이는 것이 목표였다.

이 글은 그 개편의 문제의식, 구현된 장치, 바뀐 실행 규칙, 그리고 아직 미뤄 둔 구상을 정리한다. 개편 이전의 설계 논의는 [누적형 지식백과 구축사](./wiki-building-history.md)의 05절에 있다.

## 문제: 지식보다 부속물이 무거워졌다

개편 직전 위키에는 원고 115개, 본문 약 60만 자가 쌓여 있었다. 새 대화를 증보하려는 편집자는 규칙상 원고를 한 편도 열기 전에 다음을 먼저 읽어야 했다.

| 자료 | 분량 | 내용 |
| --- | ---: | --- |
| AGENTS.md | 약 0.4만 자 | 저장소 운영 규칙 |
| WIKI_PROTOCOL.md | 약 1.5만 자 | 총합·증보 프로토콜 |
| AI_INDEX.md | 약 4.7만 자 | 공개 문서의 제목·별칭·요약·날짜·링크 |
| wiki/manifest.json | 약 9.9만 자 | 위와 거의 같은 메타데이터와 태그·출처·관련 문서 |

합치면 약 16.7만 자다. 그런데 AI_INDEX.md, ai/index.json, manifest, llms.txt는 같은 메타데이터를 형식만 바꾸어 네 번 담고 있었고, 정작 문서 **안의 어느 절에 무엇이 있는지**는 어디에도 없었다. 많이 읽는데도 정말 필요한 위치 정보는 얻지 못하는 구조였다. 긴 입력을 받은 모델은 뒷부분을 흘려 읽기 쉽고, 어디를 흘렸는지는 드러나지 않는다. 대화를 처음부터 끝까지 꼼꼼히 추출하라는 프로토콜의 요구와도 정면으로 부딪친다.

쓰기 쪽 부담은 더 컸다. 규칙은 원고와 함께 웹사이트용 `notes.json`(약 1.36MB)과 AI 색인 네 가지를 **같은 커밋**에 넣도록 요구했다. 생성 스크립트를 실행할 수 없는 편집 환경에서는 이 생성물을 사실상 손으로 맞춰야 했다. 한 번에 파일 하나만 쓸 수 있는 도구는 main을 중간 상태로 깨뜨리지 않으려고 브랜치를 만들고, 원고·manifest·장부를 따로 커밋한 뒤, 생성물을 맞추는 수습 커밋과 PR 병합을 거쳤다. 두 작업이 동시에 진행되면 생성 파일끼리 거의 확실히 충돌했다. 축적한 지식이 다음 축적의 비용을 키우는 역설이 읽기와 쓰기 양쪽에서 일어나고 있었다.

## 조판은 기계에게: 원고만 커밋한다

첫 조치는 쓰기에서 생성물을 떼어 내는 것이었다. 비유하자면 작가가 조판과 인쇄까지 하고 검수자는 확인만 하던 구조를, 작가는 원고만 넘기고 조판과 인쇄는 인쇄소가 맡는 구조로 바꾸었다. 인쇄소 역할은 GitHub Actions가 맡는다. GitHub Actions는 저장소에 변경이 올라올 때마다 정해 둔 작업을 GitHub의 서버에서 대신 실행하는 기능이다.

GitHub Pages의 배포 방식을 "브랜치에서 배포"에서 "GitHub Actions"로 바꾸고, 배포 워크플로(`.github/workflows/deploy-pages.yml`)가 main에 커밋이 들어올 때마다 다음을 수행하게 했다.

1. 원고·manifest·관계·장부로부터 `notes.json`, AI 색인, `llms.txt`, 편집 지도, 정비 대기열을 생성한다.
2. 기존의 모든 검증(생성물 동기화, 장부, 교차 제안, 뷰어 테스트)을 실행한다. 하나라도 실패하면 배포하지 않으며 사이트는 직전 상태로 남는다.
3. 바뀐 생성물을 main에 자동 커밋한다.
4. 같은 결과물로 사이트를 배포한다.

3단계의 자동 커밋은 사이트 때문이 아니라 **저장소를 읽는 편집자**를 위한 것이다. 외부 AI 편집자는 GitHub에서 색인과 지도를 읽으므로 저장소의 생성물도 최신이어야 한다. 사이트는 워크플로가 만든 결과물로 직접 배포되므로, 자동 커밋이 별도의 Pages 빌드를 촉발하지 않아도 게시가 누락되지 않는다. 워크플로의 기본 토큰으로 만든 커밋은 다시 워크플로를 촉발하지 않으므로 생성과 커밋이 무한히 반복되지도 않는다.

그 결과 실행 규칙이 단순해졌다. 편집자는 원고·manifest·관계 정본·편집 장부만 main에 **직접** 커밋하고, 생성물은 쓰지 않으며, 증보 작업에 브랜치와 PR을 만들지 않는다. 여러 파일을 한 번에 쓸 수 없는 도구는 원고 → manifest와 관계 → 장부 순으로 나누어 커밋한다. 중간 커밋에서 검증이 실패하더라도 그 시점의 배포만 건너뛰고, 순서가 끝나는 커밋에서 정상 배포된다.

## 읽기의 계층: 지도, 카드, 절

다음 조치는 읽기에 계층을 만드는 것이었다. 도서관 목록에서 책을 고르고, 그 책의 목차를 보고, 해당 쪽을 펴는 순서다. 원고는 한 글자도 줄지 않는다. 바뀌는 것은 **처음에 무엇을 읽는가**다. 세 가지 자료가 모두 원고에서 자동 생성되며 손으로 관리하지 않는다.

### 전체 지도

`editorial/map/index.md`는 미게시 원고까지 포함한 모든 원고를 분류별로 한 줄씩 싣는다. 각 줄에는 ID, 제목, 별칭, 절 수, 분량, 장부 기록 수가 있다. 약 1.5만 자로, 모든 문서가 한 파일에 있다는 점이 중요하다. 분류별로 묶었지만 파일을 분야마다 쪼개지 않았기 때문에, 분야를 넘나드는 후보를 찾는 전체 탐색 경로 역할도 한다. 대신 나누는 기준을 생성기에 미리 넣어 두었다. 지도가 2만 5천 자(문서 약 200개)를 넘으면 자동으로 분류 목록과 분류별 파일로 나뉜다. 그때도 맨 앞 목록에는 모든 문서의 ID를 남겨, 분야를 넘나드는 후보 찾기가 한 분류 안에 갇히지 않게 한다.

장부 기록 수를 함께 적는 이유는 장부 도입 이전 원고를 구별하기 위해서다. "장부 없음"은 그 원고에 내용이 없다는 뜻이 아니라, 처리 기록이 남기 전에 쓰였거나 아직 기록이 없다는 뜻이다. 그런 원고는 장부가 아니라 절 목차로 찾아야 한다.

### 문서 카드

`editorial/map/docs/<id>.md`는 원고마다 하나씩 있는 카드다. 문서당 평균 약 1.2천 자이며 다음을 담는다.

- 요약, 별칭, 태그, 수정일과 실제 증보일, 관련 문서
- 절 목차: 들여쓰기로 나타낸 소제목 경로, 원고 파일에서 그 절이 차지하는 줄 범위, 분량, 8자리 해시, 첫 문장
- 장부에 기록된 반영 지식(절별로 묶음)
- 확인된 의미 관계와 교차 편집 제안

줄 범위는 원고를 받은 뒤 해당 위치를 정확히 짚게 해 준다. 해시는 그 절 내용의 지문이어서, 원고가 바뀌면 값도 바뀐다. 읽은 뒤에 다른 작업으로 절이 바뀌었는지 확인하는 데 쓰이며, 장차 절 단위로 수정하는 도구를 만들 때 기반이 된다. 첫 문장은 위치를 확인하는 용도일 뿐 절의 내용을 대표하지 않는다. 반례나 단서는 첫 문장에 나오지 않는 경우가 많기 때문이다.

### 지식 표제 역색인

기존 편집 장부는 처리 배치별로 "어떤 지식을 어느 문서의 어느 절에 반영했는지"를 기록해 왔다. 좋은 자산이지만 배치 이름 순서로 쌓여 있어서, 특정 논점이 이미 처리되었는지 찾기 어려웠다. `editorial/map/knowledge.md`는 이 기록을 **뒤집어** "지식 표제 → 반영 문서·절 → 처리 배치"로 찾을 수 있게 한다. 새 요약을 만든 것이 아니라 기존 기록에 검색 경로를 하나 더 낸 것이다. 반영 위치가 없어 어느 카드에도 보이지 않던 보류 항목은 사유와 함께 맨 앞에 모았다.

장부 항목이 600개를 넘어 이 파일은 약 8.7만 자다. 통째로 읽으면 색인 과부하를 한 층 위로 옮길 뿐이다. 그래서 **낱말로 검색하는 용도**로만 쓰고, 검색할 수 없는 환경에서는 후보 문서 카드의 장부 기록으로 대신 확인한다.

### 바뀐 읽기 순서와 그 경계

첫 개편 직후의 실행 규칙(WIKI_PROTOCOL v1.5~1.7, AGENTS.md)이 정한 읽기 순서는 다음과 같았다. 규칙 문서 자체는 같은 날 v2.0에서 다시 가벼워졌다(아래 「규칙 문서의 경량화」).

1. AGENTS.md와 WIKI_PROTOCOL.md는 **전부** 읽는다.
2. 대화에서 지식 항목을 추출하고, 항목마다 전체 지도에서 제목·별칭·다른 표현으로 후보를 찾는다.
3. 후보의 문서 카드에서 절 목차와 장부 기록을 확인하고, 처리 여부가 궁금한 논점은 역색인을 검색한다.
4. 대조할 절 본문과 그 절이 기대는 정의·전제·반례가 있는 절을 읽는다.

프로토콜을 나누지 않고 전부 읽게 둔 데는 이유가 있다. 개편 전 선독량 가운데 규칙 문서는 약 10%였고, 부담의 대부분은 색인이었다. 반면 프로토콜에는 축약 금지, 문체, 출처 분리, 완료 조건처럼 결과의 품질을 지키는 기준이 다 들어 있다. 이를 "필요할 때 읽는 모듈"로 쪼개면 필요한 순간을 놓칠 위험이 생긴다. 얻는 분량에 비해 잃을 수 있는 것이 크다.

원고 전문으로 범위를 넓히는 조건도 명시했다.

- 기존 정의나 전제를 바꾸거나, 그 정의를 참조하는 다른 절에 영향이 있을 때
- 절을 신설·분할·재배열하는 등 문서 구조를 바꿀 때
- 새 내용이 기존 서술과 충돌하거나 국소적으로 해결되지 않을 때
- 카드의 목차와 첫 문장만으로 대조할 위치를 정할 수 없을 때

가장 중요한 경계는 **색인만 보고 "이미 있는 내용"이라고 버리지 않는다**는 것이다. 제목과 요약이 같아도 새 설명에는 다른 성립 조건이나 반례가 들어 있을 수 있다. 중복으로 판정해 반영을 생략하려면 해당 절 본문을 반드시 읽고, 읽지 못한 항목은 반영된 것으로 간주하지 않고 보류로 기록한다. 잘못된 중복 판정은 새 정보를 지우고, 잘못된 신규 작성은 나중에 병합 비용을 남긴다. 두 오류의 비용이 같지 않으므로, 애매하면 본문으로 내려간다.

카드는 원고가 커밋된 뒤 Actions가 갱신하므로 커밋 직후에는 잠시 낡았을 수 있다. 카드의 줄 범위·해시와 본문이 맞지 않으면 본문을 따른다.

재즈 드럼에 관한 대화 하나가 기존 문서 세 편(드럼키트, 리듬 섹션, 재즈 인터플레이)과 관련된다고 하면, 원고 본문을 읽기 전 선독량은 약 16.7만 자에서 약 4.1만 자로 줄어든다. 개정된 AGENTS와 프로토콜 약 2.2만 자, 전체 지도 약 1.5만 자, 후보 카드 세 장 약 0.5만 자다. 줄어든 몫은 대화의 추출과 집필에 쓸 수 있다.

### 규칙 문서의 경량화: 프로토콜 v2.0

색인을 가볍게 만든 뒤에도 규칙 문서는 매번 약 2.2만 자를 차지했다. 따져 보니 무거운 이유는 규칙이 많아서가 아니었다. 같은 규칙이 두 곳에 있었고, 규칙 사이에 구축 경위가 섞여 있었다.

- **두 문서의 중복:** 프로토콜은 AGENTS.md도 전부 읽으라고 했는데, AGENTS.md의 파일 목록·편집 절차·색인 필드 설명·직접 집필과 간접 제안의 구분은 대부분 프로토콜에 이미 있었다. 규칙을 바꿀 때마다 두 파일을 같이 고쳐야 했고, 한쪽만 고치면 서로 어긋날 위험이 있었다.
- **경위와 낡은 문장:** 절 제목에 "(단계 01 이행)" 같은 꼬리표가 붙어 있었고, "이 단계에서는…" 같은 구축 경위가 규칙 사이에 끼어 있었다. 자동 배포로 바뀐 뒤에는 "기존 `notes.json`과 정적 사이트는 변경하지 않는다"처럼 **현재와 모순되는 문장**도 남아 있었다.
- **내부 반복:** 추출·실행 절차·완료 검사가 같은 순서를 세 번 설명했고, 출처 분리 규칙은 세 절에 흩어져 있었다.

v2.0은 규칙을 하나도 빼지 않고 다시 배치했다. 증보에 필요한 규칙은 프로토콜 하나에 모두 담고(약 1.15만 자), 프로토콜은 더 이상 AGENTS.md를 읽으라고 하지 않는다. 순서는 원칙 → 자료 범위 → 추출 → 찾기와 대조 → 집필과 문체 → 통합 → 간접 연결 → 출처와 장부 → 원고·메타데이터·커밋 → 실행 순서 → 완료 검사 → 호출이다. AGENTS.md는 "증보는 프로토콜, 정비는 프로토콜과 정비 절차, 종합은 프로토콜과 종합 절차"를 알려 주는 표와 모든 작업에 공통인 원칙 몇 줄만 남은 안내판이 되었고(약 0.1만 자), 파일 목록은 README로 옮겼다. 정비와 종합의 절차 문서도 "프로토콜과 이 문서"만 읽게 바뀌었다.

규칙을 줄이는 일은 이 위키가 가장 경계하는 "요약하다 내용을 잃는" 위험을 그대로 안고 있다. 그래서 개정에는 **규칙 대응표**를 붙였다. 옛 프로토콜과 AGENTS.md의 규칙 하나하나가 새 문서의 어느 절로 갔는지, 지웠다면 왜 지웠는지를 적은 표다. 증보 장부가 "어느 지식이 어느 절에 반영되었는가"를 기록하는 것과 같은 방식을 규칙 자신에게 적용한 셈이다. 실제로 지운 것은 구축 경위 설명, 모순되던 문장 하나, 외부 AI에게 하는 안내 한 줄(지금은 `llms.txt` 첫머리가 맡는다), 그리고 AGENTS.md를 읽으라는 참조뿐이다.

그 결과 원고 본문을 읽기 전의 선독량은 약 3만 자 남짓이 되었다. 프로토콜 약 1.15만 자, 전체 지도 약 1.6만 자, 처리 이력과 후보 카드 몇 장이다. 개편 전 약 16.7만 자와 비교하면 5분의 1 수준이다. 앞으로 늘어나는 것은 지도뿐이며, 그 증가는 앞의 분할 기준이 받아 낸다.

## 두 속도: 일상 증보와 정비

예전 프로토콜은 국소 갱신 뒤에 관련 항목과 중복 후보, 새 관계를 **전역적으로** 재검토하라고 했다. 문서가 적을 때는 가능했지만, 새 대화를 넣을 때마다 멀리 떨어진 모든 글의 관계까지 다시 읽으면 비용이 문서 수와 함께 커진다. 그래서 작업을 두 속도로 나누었다.

- **일상 증보**는 새 지식과 직접 관련된 절과 그 연결만 검토한다. 고친 문서의 관련 문서, 고친 절을 참조하는 절까지다. 증보 중에 발견한 넓은 문제는 고치지 않아도 되며, 필요하면 보류 항목이나 교차 제안으로 남긴다.
- **정비**는 가끔 위키 전체를 살피는 별도 작업이다. 절차는 [MAINTENANCE.md](https://github.com/belorin/belorin.github.io/blob/main/MAINTENANCE.md)에 따로 두어, 일상 증보에서는 읽지 않는다.

정비의 원칙은 "컴퓨터는 전체를 검사하고, AI는 신호가 가리키는 곳을 읽고 판단한다"이다. 링크·ID·생성물 동기화 같은 형식 검사는 기계가 매 커밋마다 저장소 전체에 돌린다. 기계가 모든 파일을 검사하는 비용과 AI가 모든 논증을 다시 읽는 비용은 다르다. 앞의 것은 사실상 공짜이고, 뒤의 것은 문서 수에 비례해 커진다.

### 정비 대기열

`editorial/maintenance/queue.md`는 원고 전체에서 기계가 찾은 정비 신호를 모은 자동 생성 목록이다. 첫 생성 시점의 신호는 다음과 같았다.

- 지난 정비 이후 변경된 문서(첫 정비이므로 115개 전부, 분류별로 묶음)
- 다른 문서의 관련 문서·본문 링크·관계 어디에도 등장하지 않는 고립 문서 12개
- 한쪽에서만 건 관련 문서 69건
- 관련 문서가 하나도 없는 문서 13개
- 제목·별칭·소제목의 글자 2-gram 유사도로 뽑은, 비슷한 문서 쌍 상위 15개
- 보류 항목 3개, 열린 교차 제안 7개
- 분량 참고(1만 자 초과 7개, 1,500자 미만 7개)와 분류 참고(분류 20개 중 문서가 하나뿐인 분류 7개)

신호는 판정이 아니다. 비슷한 쌍의 맨 위에는 서커스 음악사의 두 원고가 유사도 0.91로 올라왔는데, 서로 연결되어 있지 않았다. 중복인지, 같은 주제의 다른 판본인지는 정비에서 양쪽 본문을 읽고 판단할 일이다.

### 정비의 권한과 기록

정비가 직접 할 수 있는 일은 세 단계로 나뉜다.

- **직접 고친다:** 본문을 읽고 직접 관련이 확인된 관련 문서의 추가와 대칭화, 메타데이터의 명백한 오탈자
- **고치고 보고한다:** 별칭 추가, 요약 갱신, 문서마다 다르게 적힌 사실에 검토 필요 표시
- **제안만 한다:** 문서 병합·분할, 분류 체계 변경, 교차 제안의 승인과 반려, 서술 충돌을 해소하는 본문 수정, 보류 항목의 완료 처리

분량만으로 문서를 나누거나 합치지 않는다. 문서마다 길이가 다른 것은 결함이 아니며, 내용상 이유가 있을 때만 제안한다.

정비 한 번마다 `M001`, `M002`처럼 버전을 붙인다. 각 정비는 보고서(`editorial/maintenance/reports/<버전>.md`)를 남기고 버전 로그(`editorial/maintenance/log.json`)에 한 줄을 더한다. 보고서는 게시된 기록물이며 채팅에는 그 링크로 결과를 보고한다. 로그에 새 버전이 추가되면 대기열의 "변경 문서" 기준일이 그 정비일로 옮겨 간다. 한 회차에 신호를 다 읽을 수 없으면 분류 단위로 나누어 처리하고, 남은 것은 보고서의 "다음 정비로 넘김"에 적는다. 위키가 커질 때를 대비한 장치다.

## 링크를 건네받은 LLM이 읽는 것

장기 집필을 위한 초기 설계에서는 채팅 내보내기에서 정본을 만들고 GPT가 그 정본을 계속 읽도록 하려 했다. [GPT 위키 제0호기](./gpt-wiki-zero-prototype.md)의 핵심 문제는 **기억이 있는가**보다 **다음 집필이 어느 버전의 기억을 실제로 읽는가**였다. 여기서 다루는 원문 링크와 색인은, 나중에 더 커진 지식백과에서 그 읽기 문제를 해결하기 위한 구체적인 운영 장치다.

이 위키의 주된 용도는 사이트를 직접 둘러보는 것보다, 위키의 링크를 LLM 채팅에 넣고 관련 내용을 찾게 한 뒤 그 위에서 대화를 이어 가는 **저장 창고**에 가깝다. 그렇다면 LLM이 링크를 받았을 때 실제로 무엇을 읽는지가 가장 중요하다.

문서 주소 `https://belorin.github.io/#<문서-id>`에는 함정이 있다. 주소의 `#` 뒤 부분은 서버로 전송되지 않으므로, 어떤 문서 링크를 주든 서버는 같은 `index.html`을 돌려준다. 그리고 그 HTML에는 본문이 없다. 본문은 자바스크립트가 `notes.json`을 내려받은 뒤에야 화면에 그려진다. 자바스크립트를 실행하지 않는 열람 도구가 받는 글은 메뉴 몇 개와 "문서를 불러오는 중입니다." 한 줄뿐이다. 이때 LLM은 읽지 못했다고 말하거나, 더 나쁘게는 주소와 제목만 보고 그럴듯한 내용을 지어낼 수 있다. 자바스크립트를 실행하는 도구라면 읽을 수 있으므로 결과는 도구마다 다르다.

같은 문서의 원문 주소 `https://raw.githubusercontent.com/belorin/belorin.github.io/main/wiki/<문서-id>.md`는 그런 도구로도 제목, 첫 문단, 소제목까지 그대로 읽힌다. 그래서 기존 주소 체계와 사이트 모습은 그대로 두고 입구를 세 군데 손보았다.

1. **사이트 HTML의 정적 안내:** 자바스크립트 없이도 보이는 한국어·영어 안내를 넣었다. "주소의 `#` 뒤가 문서 ID이며 원문은 이 주소에 있다, 전체 목록은 `llms.txt`에 있다"는 내용이다. 브라우저에서는 본문이 그려지면서 이 안내가 사라지므로 사람에게는 거의 보이지 않는다.
2. **`llms.txt`의 사용법:** 공개 문서 전체의 제목, 한 줄 설명, 원문 링크를 담은 `llms.txt` 첫머리에 외부 AI를 위한 읽는 순서를 넣었다. 목록에서 후보를 고르되 한 분류에서만 찾지 말 것, 한 줄 설명만으로 단정하지 말고 원문을 열어 읽을 것, 답할 때 근거 문서와 절을 밝히고 위키 밖의 지식이나 추론을 구분할 것.
3. **"LLM용 원문 링크 복사" 버튼:** 사이트의 문서 화면에서 그 문서의 원문 주소를 바로 복사할 수 있다. 휴대전화에서 채팅으로 링크를 넘길 때를 위한 것이다.

정리하면, 위키 전체를 바탕으로 대화하려면 `https://belorin.github.io/llms.txt`를 건네고, 특정 문서를 건넬 때는 사이트 주소 대신 원문 링크를 쓰는 편이 확실하다.

## 셋째 작업: 종합

증보가 지식을 넣고 정비가 정리한다면, 셋째 작업은 이미 쌓인 지식을 엮어 새로 생각하는 것이다. 이 작업을 위한 절차를 [SYNTHESIS.md](https://github.com/belorin/belorin.github.io/blob/main/SYNTHESIS.md)에 따로 두었다. 유형은 셋이다.

- **교차 종합:** 여러 문서를 가로질러 하나의 질문을 세우고 새 논점을 전개하는 장문이다. 재료가 이미 모여 있는 주제도 있다. 교차 제안 7건 가운데 3건이 무성영화 극장 음악가의 실직과 AI 시대의 능력·무력화 문서를 잇고 있어, "기술 전환은 인간 수행의 가치를 어떻게 재배치하는가" 같은 글을 쓸 수 있다.
- **개념 길잡이:** 한 개념이 문서마다 어떻게 다르게 쓰이는지 보여 주는 대조 지도다. 개념을 한 줄로 정의해 원문을 대체하는 짧은 개념 페이지와는 다르다. 압축하지 않고 원문으로 안내한다.
- **편집 비평:** 논증이 약한 곳, 빠진 반론, 문서 사이의 엇갈림을 짚는 AI의 의견이다. 대상 문서는 고치지 않고 고칠 방향만 제안한다.

종합은 지식 문서가 아니라 편집 해석이며, 그 사실을 감추지 않는 것이 이 작업의 핵심 규칙이다. 재료는 위키 안의 문서뿐이고, 사실은 근거 문서와 절을 밝혀 쓰며, 해석과 의견은 그렇게 드러낸다. 근거로 쓰는 문서는 전문을 읽는다. 문서 전체의 맥락 위에서만 종합이 정확하기 때문이다.

종합 글은 manifest에서 `kind: "synthesis"`와 유형, 근거 문서 목록(`based_on`)을 갖고 분류 "종합"으로 등록된다. 사이트에서는 보라색 말머리와 "이 글은 편집 해석이며 근거는 아래 문서에 있다"는 안내 상자로 표시된다. 전체 목록·문서 수·무작위 글에서는 빠지고 "종합" 주제로 따로 모이며, AI 색인·`llms.txt`·편집 지도에서도 별도 묶음으로 실린다.

가장 중요한 경계는 **종합이 다른 글의 사실 근거가 되지 않는다**는 것이다. 해석이 근거로 재인용되면 AI의 해석이 점점 사실처럼 굳어지는 순환이 생긴다. 그래서 다른 종합을 근거로 삼거나, 근거 문서를 링크하지 않거나, 대화 지식을 종합 글에 증보하면 빌드가 실패해 배포되지 않는다. 또 이 위키는 소유자의 이름으로 공개되므로, 종합 글은 처음에 미게시로 쓰고 소유자가 읽은 뒤 게시를 결정한다.

## 미뤄 둔 것

개편 과정에서 나왔지만 이번에 구현하지 않은 구상도 있다.

- **질문 답변의 저장:** 위키에 질문하고, 근거 절을 인용한 답 가운데 가치 있는 것을 다시 문서로 저장하는 순환이다. 종합의 넷째 유형으로 거론되었으나, 이 위키의 주된 사용 방식이 외부 LLM 채팅에서 위키를 읽고 대화를 이어 가는 것이어서 뒤로 미루었다.
- **`notes.json`의 분할:** 사이트는 첫 방문에 전체 본문을 한 번에 내려받는다. 목록과 본문을 나누어 불러오면 가벼워지지만, 편집 과정의 개선보다 시급하지 않다.
- **분류 체계 정비:** 문서가 하나뿐인 분류가 여럿이고 음악 분류에 문서가 몰려 있다. 분류 변경은 정비에서 제안으로 다룬다.

## 관련 문서

- [GPT 위키 제0호기: 대화 내보내기에서 지속 집필의 기억 장치로](./gpt-wiki-zero-prototype.md)
- [누적형 지식백과 구축사: 총합·증보를 위한 설계와 구현](./wiki-building-history.md)
- [사람과 AI가 함께 편집하는 규칙](./editing-principles.md)
- [대화가 끝난 뒤에도 자라는 노트](./living-notes.md)
- [총합·증보 프로토콜](https://github.com/belorin/belorin.github.io/blob/main/WIKI_PROTOCOL.md)
- [정비 절차](https://github.com/belorin/belorin.github.io/blob/main/MAINTENANCE.md)
- [종합 절차](https://github.com/belorin/belorin.github.io/blob/main/SYNTHESIS.md)
- [전체 지도](https://github.com/belorin/belorin.github.io/blob/main/editorial/map/index.md)
- [정비 대기열](https://github.com/belorin/belorin.github.io/blob/main/editorial/maintenance/queue.md)
- [외부 AI용 문서 목록](https://belorin.github.io/llms.txt)