# 누적형 지식백과 구축사: 총합·증보를 위한 설계와 구현

이 지식백과는 개별 대화를 요약해 쌓아 두는 아카이브가 아니라, 서로 다른 주제에서 얻은 지식을 독립적인 글로 집필하고 이후 자료가 추가될 때마다 계속 수정해 나가는 저술 시스템이다. 서술은 하나의 책처럼 읽히되, 문서들은 서로 연결되고 이전의 설명·반론·미해결 문제가 사라지지 않도록 관리한다.

2026년 10월 22~23일에는 이러한 목적을 위해 편집 프로토콜, Markdown 정본, 증보 이력, AI용 색인, 관계 검색과 교차 편집 규칙을 차례로 정비했다. 다음은 완성된 기능과 아직 해결되지 않은 설계상의 과제를 구별한 구축 기록이다.

## 00. GPT 위키 제0호기: 대화 내보내기에서 외부 기억으로

2026년 10월의 누적형 지식백과에 앞서는 구상에는 ChatGPT의 대화를 내보낸 뒤 Codex가 Markdown으로 변환하고, 그 결과를 GPT가 다음 집필에서 읽도록 하자는 목표가 있었다. 처음에는 대화 아카이브의 구성과 검색이 문제였지만, 곧 중심 과제가 **장기 창작의 일관성을 지키는 외부 기억 장치**로 이동했다. 위키의 성공 기준은 문서 사이트의 완성이 아니라, 다음 집필에서 확정 설정과 미정 항목, 결정의 이유와 폐기된 대안을 구별할 수 있는가였다.

이 초기안은 원본 내보내기, 대화별 변환문, 주제별 정본을 서로 다른 층으로 분리하고, 창작 프로젝트에는 canon·decision log·context pack·open questions를 두자는 제안으로 구체화되었다. MkDocs·Obsidian·검색 데이터베이스는 서로 다른 탐색·독서 선택지였고, ChatGPT 프로젝트·Custom GPT·외부 연결·MCP는 모델이 실제 정본에 접근하는 선택지였다. Codex는 변환기와 운영 규칙을 만들고, 집필 모델은 설정을 참조해 쓰며, 승인된 새로운 정보만 다시 정본에 반영하는 역할 구분도 제안되었다.

이 단계는 **구현 완료 기록이 아닌 선행 설계**다. 초기 논의의 정확한 날짜는 원본 내보내기 시각을 직접 확인하지 못해 미확정으로 둔다. 이후 10월의 구축은 개별 작품의 canon을 넘어 음악·철학·역사·기술의 지식과 논증을 통합하는 편집 시스템으로 발전했다. 양쪽의 차이와 구체적인 초기 작업안은 [GPT 위키 제0호기](./gpt-wiki-zero-prototype.md)에 별도로 기록한다.

## 기획의 출발점: 요약이 아니라 총합

일반적인 요약은 길이를 줄이고 주요 결론을 남기는 것을 목표로 한다. 그러나 지식 생산의 중요한 부분은 결론보다 그 결론의 성립 조건, 개념의 구별, 구체적인 사례, 반론과 수정 과정에 있을 수 있다. 특히 긴 논의를 짧은 일반론으로 환원하면 가장 흥미로운 설명이 먼저 사라진다.

이 시스템은 의미 있는 중복만 병합하고, 유효한 정보의 밀도와 논증의 전개를 보존하거나 확장하는 방향을 택했다. 편집의 대상은 대화 형식의 기록이 아니라 서적·백과사전처럼 독립적으로 읽히는 원고다. 원래 발화 순서를 그대로 재현하지 않아도 되지만, 주장에 도달한 근거의 순서는 필요할 때 본문에 남겨야 한다.

특히 두 종류의 지식을 동등하게 다룬다. 하나는 일반적인 개설만으로 파악하기 어려운 개념의 정립과 정교화다. 다른 하나는 작품·음반·문헌·역사적 사례·추천 목록처럼 자체로 읽을 가치가 있는 독립적 주제다. 이를테면 재즈 즉흥성에 관한 추상적 논증과 실제로 들어볼 재즈 음반의 선정 이유는 서로 연관되면서도 각각 완결된 글이 될 수 있다.

그러므로 편집 성과를 문서 수나 요약의 간결함으로 측정하지 않는다. 추출할 만한 논점이 얼마나 빠짐없이 포착되었는지, 구체성이 얼마나 유지되었는지, 기존 원고가 새 자료로 얼마나 풍부해졌는지가 더 중요한 기준이다.

## 핵심 아키텍처: 하나의 정본과 두 개의 탐색 화면

인간과 AI를 위해 지식 자체를 두 번 작성하면 사본 사이에서 내용이 달라질 수 있다. 이에 따라 본문은 하나의 Markdown 정본으로 유지하고, 필요한 표현과 탐색 정보만 파생시키는 구조를 채택했다.

Markdown 원고는 논증·예시·반론·큐레이션을 담는 저술의 본체다. 메타데이터는 문서 ID와 제목, 별칭, 주제, 검토 상태, 수정일, 명시적으로 기록한 증보일과 관련 문서를 관리한다. 사람이 읽는 웹사이트는 이 원고로 생성한 데이터를 사용하며, AI는 별도의 작은 색인에서 후보를 찾은 후 관련 원고의 상세 본문을 읽는다.

AI가 색인을 먼저 읽는다고 해서 색인만으로 집필한다는 뜻은 아니다. 짧은 설명은 어디에 무엇이 있는지 알려 주는 지도다. 판단과 실제 수정에 필요한 근거는 언제나 원고의 자세한 서술에 있다. 이 구분을 지키지 않으면 검색의 효율을 위해 만든 짧은 문장이 지식의 전체를 대체하게 된다.

장기적으로는 같은 정본에서 위키식 연결 탐색, 책의 순차적 목차, 출처와 개정 이력, 작품·음반별 가이드 같은 서로 다른 독서 경로를 구성할 수 있다. 그러나 이들은 별도의 지식 사본이 아니라 원고의 다양한 접근 방식이어야 한다.

## 원본 충실성과 공개 정책

특정 논의를 위키에 편입하는 작업에서는 외부 인터넷 조사나 새 문헌 수집을 하지 않는다. 새로운 실질적 사실을 덧붙이지 않고, 실제 접근 가능한 내용과 저장소에 이미 축적된 원고만 이용한다. 이는 연구 자체의 금지가 아니라, 기존 지식의 총합과 새로운 조사를 서로 다른 작업으로 구분하기 위한 규칙이다.

원문에 있었던 사건·인물·수치·주장은 재검증이 이루어지지 않았을 경우 확정 사실로 꾸미지 않는다. 개인적 해석, AI가 구성한 추론, 편집자가 제안한 관계와 확인된 사실의 경계를 유지한다. 원문에서 확인할 수 없는 대목을 접근했다고 주장하거나, 불확실한 설명을 새로운 출처로 정당화해서도 안 된다.

공개 GitHub 저장소에는 개인 대화의 전문이나 발췌문, 공유 링크, 화자의 세부 기록을 보관하지 않는다. 공개 가능한 추출 지식은 완성 원고에 쓰고, 편집 장부에는 지식 항목의 짧은 이름·반영된 문서와 절·미완 상태만 남긴다. 새로운 본문 또한 '대화에서는', '사용자가 말했다', 'AI가 답했다'는 식의 생성 경위 소개 대신 대상 개념과 사실을 곧장 설명하는 독립적인 문체를 사용한다.

이 원칙은 과거에 이미 작성한 모든 글을 소급해서 재작성한다는 뜻은 아니다. 기존 본문은 보존하고 새로 집필하거나 증보할 부분부터 적용한다.

## 준비 단계: 공통 편집 프로토콜의 제정

2026년 10월 22일에는 여러 채팅에서 공통으로 참조할 편집 규칙을 저장소 루트의 WIKI_PROTOCOL.md에 마련했다. 매번 장문의 프롬프트를 복사하는 대신 하나의 프로토콜 링크를 통해 같은 편집 원칙과 저장 경로를 적용하는 방식이다.

프로토콜에는 순차적인 주제 추출, 드문 개념 설명과 독립적인 목록의 동등한 보존, 반론의 보존, 기존 원고와의 병합, 링크 및 누락 검수, 접근할 수 없는 원문 범위의 보고, 외부 조사 금지, 민감한 정보의 비공개 처리 등이 들어갔다. AGENTS.md는 편집 도구가 그 프로토콜과 실제 파일 구조를 함께 따르도록 하는 안내서다.

구축의 중요한 판단은 하나의 대화가 하나의 짧은 문서로 끝나서는 안 된다는 것이다. 한 자료가 여러 기존 문서의 절을 확장할 수 있으며, 별도의 독립 주제가 충분하면 새로운 글도 만들어야 한다. 반대로 비슷한 이름을 가진 기존 원고가 있다고 해서 논증의 차이를 지우며 병합해서도 안 된다.

## 01. Markdown 정본화: 본문과 생성물의 분리

2026년 10월 23일 첫 이행 단계에서는 기존 웹사이트의 문서를 표시하는 notes.json과 별도로 축적되어 있던 wiki/*.md의 역할을 명확히 했다. 지식의 원고는 Markdown 하나로 유지하고, notes.json은 사이트가 읽는 자동 생성 결과물로 전환한 것이다.

wiki/manifest.json에는 문서 ID, 제목, 분류, 게시 여부, 정렬 순서, 간단한 설명, 관련 문서 등의 메타데이터가 들어간다. scripts/build-notes.mjs는 Markdown과 manifest를 결합하고, 파일 간 상대 링크를 기존 웹사이트의 해시 링크로 변환해 notes.json을 만든다. 결과적으로 같은 본문을 Markdown과 JSON에 각각 써 두지 않아도 된다.

이행 시점의 공개 항목은 23개였으며, 별도의 Markdown으로만 존재하던 항목까지 합친 원고 수는 28개가 되었다. 기존 웹사이트에서만 관리하던 항목 중 Markdown 원고가 없었던 4개도 원고로 옮겼다. 공개되지 않았던 5개 원고는 그때의 게시 상태를 유지했다.

기존 GitHub Pages 화면, 주소, notes.json을 읽는 방식은 그대로 두었다. Markdown에서 생성한 JSON은 원고와 같은 커밋에 포함하며, GitHub Actions가 새 결과의 일치 여부를 검사한다. 이 단계의 주요 구현 커밋은 [Markdown 정본화](https://github.com/belorin/belorin.github.io/commit/fca517a2fcb81d7ead9a483e476547b6185aa2fa)이다.

## 02. 증보 이력: 원문이 아니라 반영 상태를 추적

두 번째 단계는 어떤 지식이 어느 문서의 어느 절에 들어갔는지, 무엇이 보류되었는지를 기록하는 체계를 만들었다. 원본 대화 자체를 저장하지 않는다는 공개 정책을 유지하면서 집필 작업의 진척을 추적해야 했기 때문이다.

editorial/ingestions/index.json은 처리 배치의 색인이고, 각 배치의 JSON에는 공개 가능한 지식 항목의 표제, 유형, integrated 또는 pending 상태, 실제 문서 ID와 절 제목을 기록한다. integrated라는 말은 실제 원고에서 해당 절을 확인한 경우에만 사용한다. 접근할 수 없었던 원문 범위도 처리 완료로 꾸미지 않고 제한 사항으로 남긴다.

scripts/validate-editorial.mjs는 중복된 식별자, 존재하지 않는 문서, 잘못된 절 제목, 예상하지 못한 원문 필드를 검사한다. 하지만 기계 검증은 원본의 의미가 정말 손실 없이 집필되었는지 판단할 수 없다. 추출 단계에서 놓친 정보를 발견하려면 원본에 접근 가능한 동안의 별도 대조가 필요하다.

주요 구현은 [원문 없는 증보 이력 체계](https://github.com/belorin/belorin.github.io/commit/e9373dc60a0d8ba1c95e229c8de6c92a539296b0)와 [검증 테스트 보강](https://github.com/belorin/belorin.github.io/commit/64b72fd9e8810c0f7d8237701c11ad63cd6cb4db)에 기록되어 있다. 이 체계 도입 이전의 문서를 나중에 임의의 처리 배치에 귀속시키지 않는다.

## 03. AI 탐색 계층: 색인을 먼저 읽고 원고를 찾아가기

세 번째 단계에서는 사람이 읽는 본문과 별개로 AI가 효율적으로 문서를 찾을 수 있는 탐색 계층을 추가했다. AI_INDEX.md와 ai/index.json에는 공개 문서의 ID, 제목, 별칭, 태그, 개요, 검토 상태, 수정일, 증보일, 관련 문서와 Markdown 직접 주소가 들어간다.

llms.txt는 외부 AI가 접근할 수 있는 선택적 진입점이며, ai/relations.json에는 단순 관련성과 근거를 확인한 의미 관계가 포함된다. 유형 없는 관련 링크는 곧바로 지지·반박·확장이라는 뜻을 갖지 않는다. 의미 관계를 부여하려면 wiki/relations.json에 방향, 유형, 실제 근거 절, 이유를 분명히 기록해야 한다.

과거 원고의 수정 날짜를 실제 지식 증보일로 오인하지 않기 위해, 확인되지 않은 last_enriched_on은 null로 둔다. 검토 상태도 확인 가능한 범위를 넘어 자동으로 '검증 완료' 처리하지 않는다. AI 색인과 llms.txt는 상세 설명을 반복 저장하는 곳이 아니라 원고에 도달하기 위한 수단이다.

외부 탐색 목록은 공개 사이트에 게시된 원고만 포함한다. 다만 GitHub 저장소 자체가 공개되어 있으므로 목록에서 빠졌다는 것이 파일 접근의 비공개를 보장하지 않는다. 주요 구현은 [AI 탐색 색인과 llms.txt 생성](https://github.com/belorin/belorin.github.io/commit/19e65715b1b748ed97c51c5927e1dee295014784) 및 [색인 우선 편집 프로토콜](https://github.com/belorin/belorin.github.io/commit/edf36924c3608183d2a98c3a032790cfee762ae2)에 남아 있다.

## 04. 의미 검색과 교차 편집: 직접 증보와 해석 제안의 분리

네 번째 단계에서는 관련 문서를 찾는 일을 조금 더 확장했다. scripts/search-wiki.mjs는 제목·별칭·소제목·간단한 설명의 어휘와 한국어 문자 n-gram, 문서 간 연결 관계를 이용해 후보를 좁힌다. 직접 링크되지 않은 문서를 후보로 제시할 수도 있고, 미게시 원고까지 함께 검사하는 선택지도 있다.

그러나 이 검색은 벡터 임베딩에 기반한 본격적인 의미 검색 엔진이 아니다. 점수는 후보 탐색을 돕는 신호일 뿐, 두 문서가 철학적으로 같은 주장을 한다는 증거가 아니다. 일반 채팅에서는 색인을 바탕으로 후보 원고를 직접 읽고 AI가 의미 관계를 재평가하는 과정이 추가로 필요하다.

직접적으로 뒷받침되는 사실·사례·반론은 기존 편집 원칙에 따라 원고를 증보할 수 있다. 반면 서로 다른 영역을 잇는 개념적 유비나 해석적 확장은 editorial/crosslinks/index.json에 proposed 상태로 기록한다. 예컨대 유성영화가 음악 노동의 구조를 바꾼 사례와 AI가 인간 능력의 기준을 바꿀 가능성을 비교하는 관점은 흥미로운 연구 문제이지만, 두 사건의 결과가 동일하다는 사실 주장으로 만들 수는 없다.

같은 원칙이 재즈의 반복되는 코러스와 들뢰즈의 생성 개념 사이의 비교에도 적용된다. 관계의 근거와 한계를 분리하고, 제안이 승인되었다고 해서 자동으로 본문에 들어갔다고 처리하지 않는다. proposed, approved, integrated, rejected라는 상태는 새 해석의 검토와 실제 집필을 분리하기 위한 장치다.

주요 구현은 [후보 검색과 교차 편집 제안 대장](https://github.com/belorin/belorin.github.io/commit/001a8db14cf42f49eeaad0c4e7a352fe4fdd1091), [편집 규칙·CI 연동](https://github.com/belorin/belorin.github.io/commit/b8424cc064655bfbb8241e86675e5a6b6b60da9d), [검색 코드 오류 수정](https://github.com/belorin/belorin.github.io/commit/ad234be17da84d68510e8ad5410f591c96263162)으로 추적할 수 있다.

## 게시 기술을 바꾸지 않는 이유

이 시스템의 핵심 요구는 새로운 문서를 만들 때마다 기존 지식과 접속하고, 필요할 경우 여러 원고를 수정하며, 이전의 세부 설명을 보존하는 것이다. 이러한 저술·검색·검수 과정은 GitHub의 Markdown 파일과 커밋 이력만으로도 현재 규모에서는 운영할 수 있다.

기존 GitHub Pages를 유지하면 정본과 공개 페이지의 연결이 단순하며, 정적 호스팅을 위해 새로운 런타임 서버나 별도의 데이터베이스를 유지할 필요도 없다. 지금까지 만든 생성기와 검증 작업도 그대로 활용할 수 있다. 정적 사이트 생성기인 Quartz 등으로 옮기는 것은 독서 경험의 선택지이지, 지식 총합 시스템의 필수 조건은 아니다.

한편 현 웹사이트의 Markdown 렌더러는 단순하다. 소제목, 단락, 목록, 기본 링크를 중심으로 표시하며, 복잡한 문서 내 목차·각주·백링크·표·풍부한 학술적 주석은 아직 충분히 구현되어 있지 않다. 페이지가 길어지고 서적 단위의 독서 요구가 커지면 이 부분만 점진적으로 발전시키거나, 그때 기존 Markdown 정본을 유지한 채 렌더링 계층을 교체할 수 있다.

따라서 현 시점의 결정은 GitHub 유지, Markdown 정본 유지, 기존 Pages 유지다. 향후 생성기를 교체하더라도 지식의 원본을 다시 쓰는 일은 최소화해야 한다.

## 한 줄 호출과 편집 절차

어느 대화에서든 WIKI_PROTOCOL.md의 GitHub 주소를 참조시키고 그 기준에 따라 지식을 총합·증보하도록 요청하는 방식으로 작업을 시작한다. 편집자는 먼저 AI 색인에서 주제 후보를 살피고, 미게시 원고를 포함한 manifest를 확인한 뒤, 관련 Markdown 원고의 전문을 읽는다.

그다음 접근 가능한 자료에서 개념·사실·사례·반론·목록을 순서대로 추출한다. 직접 관련된 주제는 기존 절을 보존하며 증보하고, 독립 주제는 새 원고로 집필한다. 간접적 개념 관계는 별도의 제안으로 남긴다. 편집 장부에는 공개 가능한 항목명과 실제 반영 문서·절만 기록한다.

원고와 메타데이터를 편집한 후 build-notes와 build-ai-index 생성기를 실행해 JSON·색인·llms.txt를 재생성하고, 편집 이력 및 교차 연결 검증을 거쳐 같은 커밋에 반영한다. 접근할 수 없는 대화 범위나 미처리 항목은 완료한 척하지 않고 보고한다.

실제 작업 명령과 규칙의 정본은 [WIKI_PROTOCOL.md](https://github.com/belorin/belorin.github.io/blob/main/WIKI_PROTOCOL.md) 및 [AGENTS.md](https://github.com/belorin/belorin.github.io/blob/main/AGENTS.md)에 있다.

## 운영 한계와 향후 개선의 우선순위

구조를 갖추었다는 사실이 지식 보존의 품질을 자동으로 보장하지는 않는다. 긴 대화의 일부 발화에 접근할 수 없을 수 있고, 추출 목록이 완전해 보여도 미묘한 설명·예외·독립적인 주제가 누락될 수 있다. 게시 후에도 원고의 설명이 충분한지, 새롭게 합친 내용이 옛 반론을 지우지 않았는지 확인해야 한다.

현재의 문자 유사도와 관계 기반 검색은 후보를 찾는 데 도움이 되지만, 직접적인 단어 중복이 없는 심층 철학적 관계를 체계적으로 발굴하는 데에는 한계가 있다. 추가적인 의미 검색 기술을 도입하더라도, 기계의 후보 추천과 실제 해석의 승인 사이에는 검토 단계가 남아야 한다.

장기적인 독서 경험은 새로운 사이트 기술의 도입보다 작은 기능 개선으로 발전시킬 수 있다. 문서 내부 목차, 다른 문서에서 들어오는 백링크, 실제 GitHub 커밋으로 연결되는 개정 이력, 음악·책·영화 같은 독립 목록의 정돈된 표시, 여러 원고를 한 권처럼 이어 읽는 서적식 목차가 우선 후보이다.

원고를 더 잘 읽을 수 있게 만드는 기능과 지식을 더 잘 축적하는 기능은 서로 보완하지만 같은 문제가 아니다. 탐색과 편집이 충분히 안정된 상태에서 독서 인터페이스를 점진적으로 확장하는 것이 현재의 운영 방침이다.

## 05. 누적 증보의 과부하와 계층 편집 설계

위키가 성장할 때 먼저 해결해야 할 문제는 매회 증보에 필요한 읽기와 판단의 양이다. 문서를 보기 좋게 만드는 일만으로는 이 비용이 줄지 않는다. 원고의 상세함을 보존할수록 문서는 길어지고, 관련 원고 전문을 읽는 절차와 국소 갱신 뒤의 전역 재검토를 반복하면 작은 추가에도 큰 검토 범위가 따라붙는다. 축적한 지식이 다음 축적을 어렵게 만드는 역설이다.

2026년 10월 26일에 기록한 다음 내용은 이러한 과부하를 줄이기 위한 **후속 설계이며 구현 완료 보고가 아니다.** 현재 WIKI_PROTOCOL v1.3과 AGENTS.md는 후보 원고의 전문 확인을 요구한다. 절 단위 읽기로 이행하려면 탐색 자료와 검증 장치를 마련하고 두 실행 지침의 관련 조항도 함께 개정해야 한다. 이 절을 게시했다는 사실만으로 기존 실행 규칙이 변경되지는 않는다.

### 보존량과 매회 읽기량을 분리한다

원고를 줄이지 않으면서도 한 번의 편집에서 읽는 범위는 줄일 수 있어야 한다. 상세 원고를 정본으로 유지하고, 어디를 읽을지 결정하는 작은 탐색 자료를 그 정본에서 파생시키는 방식이다. 목표는 모든 주장을 짧은 페이지로 쪼개는 것이 아니다. 전제·논거·반례가 이어지는 장문을 유지하면서 그 안의 필요한 논증에 도달할 수 있게 한다.

대화의 저장 단위와 지식의 단위도 다르다. 한 자료에는 여러 주제가 있고 같은 논점은 여러 자료에서 되풀이된다. 검색할 때마다 조각을 다시 종합하는 데서 멈추면 같은 편집 비용을 계속 치르게 된다. 확인된 종합 결과를 정본으로 되돌리고 다음 작업이 그 결과에서 출발하게 해야 한다. 다만 반복에는 단순 중복뿐 아니라 새 근거·반례·조건의 정교화도 있으므로, 되풀이되었다는 이유만으로 삭제해서는 안 된다.

### 위층에서 찾고 아래층에서 판정한다

계층 순회의 원칙은 읽을 위치를 상위 색인에서 찾고, 실제 반영 여부는 해당 본문에서 판정하는 것이다.

| 층 | 읽는 자료 | 역할과 읽는 조건 |
| --- | --- | --- |
| L0 | 짧은 프로토콜 핵심부 | 매회 지켜야 할 보존·출처·완료 원칙과 필요한 모듈의 위치를 확인한다 |
| L1 | 전역 지도와 지식 표제·별칭의 위치 색인 | 신규 지식이 들어갈 후보 문서와 절을 찾는다 |
| L2 | 후보 문서의 절 개요 | 제목 경로·본문 발췌·분량·해시를 보고 대조할 범위를 좁힌다 |
| L3 | 대상 절과 필요한 맥락·참조 절 | 기존 정의·전제·반례와 새 내용을 대조하고 집필한다 |
| L4 | 문서 전체와 필요한 관련 원고 | 분할·재구성, 광범위한 전제 변경, 국소적으로 풀리지 않는 충돌을 검토한다 |

절 개요에는 첫 문장이나 짧은 발췌를 기계적으로 담을 수 있다. 앞으로 쓰는 절의 첫 문장이 핵심을 드러내면 탐색에 도움이 되지만, 모든 기존 문장을 그 형식에 맞추어 다시 쓸 필요는 없다. 첫 문장에 나오지 않는 반례도 존재하므로 개요는 본문을 대신하지 못한다. 본문에서 생성했다는 사실만으로 개요의 의미적 충분성이나 최신성이 보장되는 것도 아니다. 생성 시점과 해시의 일치 여부를 확인해야 한다.

전역 색인 자체도 계속 커진다. 장기적으로는 작은 진입 지도에서 필요한 색인 부분을 조회하는 방식이 필요하다. 전체 본문 대신 거대한 색인 하나를 매번 읽게 만드는 것은 과부하를 한 층 위로 옮길 뿐이다.

### 중복 판정과 읽기 범위 확장의 조건

색인은 후보를 찾는 장치이며, 읽지 않은 내용을 이미 반영했다고 판정하는 근거가 아니다. 제목과 요약이 같아도 새 설명에 다른 성립 조건이나 반례가 들어 있을 수 있다. 중복이라고 제외하려면 해당 본문을 읽어 그 차이를 대조해야 한다.

반대로 첫 검색에서 일치하지 않았다고 곧바로 독립 문서를 만들지 않는다. 별칭과 다른 표현, 관련 개념으로 후보를 다시 확인한다. 기존 절의 정의나 전제가 다른 곳에 있으면 그 절도 읽고, 정의를 변경할 때는 그것을 참조하는 부분까지 확인 범위를 넓힌다. 문서 구조를 바꾸거나 여러 절의 논증이 함께 움직이는 경우에는 전문 검토가 필요하다. 개요가 낡았거나 맥락을 충분히 설명하지 못할 때에도 최신 본문을 확인한다.

오류의 비용은 대칭적이지 않다. 잘못 중복 처리하면 새 정보가 사라지고, 중복 문서를 만들면 뒤에 병합해야 할 비용이 생긴다. 따라서 애매하면 본문으로 내려가되, 읽기 예산이 부족하면 판단하지 못한 항목을 보류한다. 확인하지 못했다는 사실을 기존 지식에 포함되어 있다는 결론으로 바꾸지 않는다.

### 절의 고정 주소와 지식 표제 역색인

편집 주소는 절 제목이나 등장 순서가 바뀌어도 유지되는 식별자를 갖는 것이 바람직하다. 제목 경로는 사람이 위치를 이해하도록 하고, 고정 ID는 같은 절을 계속 가리키며, 본문 해시는 읽은 이후 내용이 바뀌었는지를 확인한다. 해시가 같다는 사실은 내용의 진실성이나 다른 절과의 의미적 독립성을 증명하지 않는다.

기존 증보 장부의 지식 표제와 반영 위치를 모으면 '지식 표제 → 문서·절' 역색인을 만들 수 있다. 다만 배치별 항목 이름과 식별자는 곧바로 전역적인 개념 식별자가 되지 않는다. 서로 다른 표현이 같은 논점을 뜻하는지는 검토가 필요하다. 반복해서 등장하는 개념부터 검토된 별칭과 공통 식별자를 마련하고, 자동 유사도만으로 서로 다른 주장을 합치지 않는다.

장부 도입 이전의 원고도 찾을 수 있어야 하므로 역색인은 본문에서 생성한 절 색인과 함께 사용한다. 옛 글에 처리 장부가 없으면 그 이력은 미색인 상태로 두며 출처나 처리 배치를 추정해 채우지 않는다. 자동 생성되는 개요와 역색인은 편집 정본을 추가하는 것이 아니라 기존 정본으로 가는 경로를 제공한다.

### 일상 증보와 정기 정비의 두 속도

일상 증보는 새 자료와 직접 영향을 받는 범위에 집중하고, 넓은 관계 재검토는 별도 정비 회차에서 수행하는 방식으로 설계한다. 매회에는 신규 지식 추출, 후보 탐색, 대상 절과 필요한 맥락 대조, 직접 이웃 확인, 국소 집필과 검증을 수행한다. 문서 간 중복, 관계 누락, 문서 분할과 먼 개념 사이의 연결은 정비 회차의 주요 대상이다.

정기 정비도 항상 처음부터 전체를 읽는 절차일 필요는 없다. 마지막 정비 이후 변경된 문서와 해결되지 않은 항목에서 출발해 필요한 범위를 넓힌다. 전역 검토가 필요한 문제는 별도로 남긴다. 일상 작업에서 확인하지 않은 관계를 정비 완료로 간주해서는 안 된다.

링크·식별자·생성물 동기화 같은 기계 검사는 저장소 전체를 대상으로 유지할 수 있다. 모델이 전체 원고를 읽어 의미를 재판단하는 비용과 스크립트가 전체 파일의 형식을 검사하는 비용을 구분하는 것이다. 전역 기계 검사 통과는 국소 편집의 의미적 완전성을 보증하지 않는다.

### 처리 경계와 승인된 지식의 환류

편집 결과에는 실제로 확인한 범위와 확인하지 못한 범위가 구분되어야 한다. 반영 항목은 정확한 문서·절로 연결하고, 보류 항목은 이유를 남긴다. 현재 장부에 없는 세밀한 읽기 범위 필드를 도입하려면 장부 스키마와 검증기도 함께 변경해야 한다. 원본 대화의 문장이나 위치 정보를 공개 기록에 추가하는 방식으로 해결하지 않는다.

대화 안에는 위키 내부 배치 ID를 포함한 반영 표지를 남겨 다음 호출의 출발점으로 삼을 수 있다. 그러나 표지는 누락된 원문을 복구하는 장치가 아니다. 마지막 표지나 그 이후 내용에 접근할 수 없다면 그 제한을 보고하고, 이미 처리한 범위를 추측해 완료로 선언하지 않는다.

기록·배열·저술은 서로 다른 판단을 요구한다. 원본, 짧은 안내, 주제별 배열, 정식화된 입장, 전체 지도라는 층을 개념적으로 구별하더라도 각각을 별도 본문 사본으로 만들 필요는 없다. 공개 위키에는 원문 비보관 정책을 유지하고, 상세 원고를 정본으로 두며 개요와 색인은 파생시킨다. AI가 제안했으나 수용 여부가 확인되지 않은 주장을 저자의 확정 입장으로 바꾸지 않는다. 간접 해석과 승인되지 않은 정식은 다음 작업에서 확정된 지식으로 재사용하지 않는다.

### 구현의 순서와 현재의 경계

우선 구현할 것은 절 개요 생성기와 지식 표제 역색인이다. 다음으로 전문 필독을 국소 대조와 조건부 범위 확장으로 전환하는 규칙을 실행 지침에 반영하고, 처리 경계와 보류 기록을 정비하며, 일상 증보와 정기 정비의 절차를 나눈다. 짧은 핵심 프로토콜과 게시·교차 연결 등 필요할 때 읽는 모듈의 분리도 이 과정에 포함된다.

생성 파일의 자동 작성과 게시를 서버나 GitHub Actions에 맡기는 일은 별도의 배포 설계다. 현재는 원고와 생성물을 같은 커밋에 넣고 CI가 동기화 여부를 검사한다. 자동 생성만 켜면 기존 게시 흐름까지 완결된다고 가정하지 않는다.

전용 MCP 서버는 그 뒤의 선택지다. 지도 조회, 지식 키 조회, 개요·절 읽기, 읽은 해시를 조건으로 한 절 패치, 장부 기록을 제공하도록 구상할 수 있다. 생성물 직접 쓰기 거부와 큰 내용 감소의 사유 확인도 서버 측에서 강제할 수 있다. 그러나 이 기능들은 아직 구현된 것이 아니며, 계층 색인과 편집 규칙이 먼저 마련되면 기존 GitHub 연결에서도 일부 절차를 활용할 수 있다. 특정 서비스의 연결·쓰기 권한은 도입 시점에 별도로 확인해야 한다.

성공 기준은 모든 것을 매번 읽었다는 선언이 아니다. 이번 편집에 필요한 근거를 찾고, 범위를 넓혀야 할 때 넓히며, 확인하지 않은 부분을 정확히 남기면서 기존 논증과 새 지식을 함께 보존하는 것이다.

## 관련 문서와 검증 가능한 이력

- [열린 노트의 운영 방향](./living-notes.md)
- [사람과 AI가 함께 편집하는 규칙](./editing-principles.md)
- [GPT 위키 제0호기: 대화 내보내기에서 지속 집필의 기억 장치로](./gpt-wiki-zero-prototype.md)
- [원고만 쓰고 나머지는 기계에게: 편집 지도·자동 배포·정비로 바꾼 위키 운영](./wiki-operations-pipeline.md)
- [지식백과가 계속 검토할 질문](./open-questions.md)
- [편집 프로토콜](https://github.com/belorin/belorin.github.io/blob/main/WIKI_PROTOCOL.md)
- [문서·별칭·검토 상태를 담은 AI 색인](https://github.com/belorin/belorin.github.io/blob/main/AI_INDEX.md)
- [공개되지 않은 원고까지 기록한 manifest](https://github.com/belorin/belorin.github.io/blob/main/wiki/manifest.json)
- [원문 없는 증보 이력 설계](https://github.com/belorin/belorin.github.io/blob/main/editorial/README.md)
- [교차 편집 제안 규칙](https://github.com/belorin/belorin.github.io/blob/main/editorial/crosslinks/README.md)
- [GitHub의 실제 변경 기록](https://github.com/belorin/belorin.github.io/commits/main/)

이 구축사의 01~04단계는 2026년 10월 23일 시점의 구현과 설계 판단을, 05절은 2026년 10월 26일에 기록한 누적 증보의 후속 설계를 구분해 기록한다. 이후 구성 요소가 변경되면 과거의 결정 이유를 지우지 않고 현재 상태를 별도로 증보한다. 05절 설계 가운데 같은 날 구현된 절 단위 탐색 자료(전체 지도·문서 카드·지식 표제 역색인), 실행 규칙의 개정, 일상 증보와 정비의 분리, 생성물의 자동 배포는 [위키 운영 개편](./wiki-operations-pipeline.md)에 따로 기록한다.