GPT 위키 제0호기: 대화 내보내기에서 지속 집필의 기억 장치로

좋은 위키를 만드는 것과 AI가 오래 같은 글을 쓰도록 만드는 것은 비슷하지만 다른 과제다. 사람이 읽기에 아름다운 문서 사이트가 생겨도, 다음 집필을 시작한 모델이 앞서 결정한 사실과 문체, 버린 대안, 아직 정하지 않은 문제를 구별하지 못한다면 프로젝트의 기억은 안정되지 않는다. GPT 위키의 초기 구상은 바로 이 간극에서 출발한다. 대화를 정리하여 전시하는 사이트가 아니라, 새로운 집필이 이전 집필의 축적 위에서 출발하도록 하는 외부 기억 장치를 만들자는 것이다.

'제0호기'는 실제로 배포된 별도 시스템의 제품명이나 작동 완료 기록이 아니다. ChatGPT 대화 내보내기와 Codex를 출발점으로 삼아 제안된 선행 설계를, 뒤에 구현된 누적형 지식백과와 구별해 부르는 편집상 이름이다. 현행 운영의 구현 기록은 누적형 지식백과 구축사와 위키 운영 파이프라인에 있다.

목표가 바뀌는 순간: 대화 아카이브에서 집필의 연속성으로

첫 번째 과제는 ChatGPT의 대화 기록을 내보내고, Codex가 그 내용을 읽어 위키를 만들도록 하는 것이었다. 대화는 이미 많은 지식을 품고 있지만, 주제별로 배열되어 있지 않다. 한 프로젝트의 핵심 설정이 여러 채팅에 흩어져 있을 수 있고, 한 채팅 안에도 작업 지시, 임시 제안, 오류 정정, 잡담, 결론이 뒤섞인다. 그러므로 데이터를 Markdown으로 변환하는 작업과 지식을 편집하는 작업을 구별해야 한다.

두 번째 과제는 그보다 엄격했다. GPT가 위키에 접근하여 이미 쌓인 내용을 바탕으로 계속 일관되게 집필할 수 있어야 한다. 이 기준을 넣으면 성공의 정의가 바뀐다. 검색 가능한 대화 목록, 보기 좋은 목차, 요약된 프로젝트 페이지가 생기는 것만으로는 부족하다. 모델이 새로운 글을 쓰기 전에 어떤 지식이 확정되어 있는지, 무엇은 후보에 불과한지, 어느 문체와 서술 원칙을 따라야 하는지를 회수할 수 있어야 한다. 글을 쓴 뒤에는 새로 생긴 설정을 다시 검토하고 저장해야 한다.

이 구상에서 대화 원본은 광산, 정제된 위키는 금속에 해당한다. 모든 광석을 출판할 필요는 없지만, 금속을 만드는 과정에서 무엇을 버렸고 무엇을 확인했는지 판단의 흔적은 중요하다. 원본을 무작정 줄이는 요약이 아니라, 후속 집필에 필요한 지식과 결정의 위계를 세우는 일이다.

원본을 바로 정본으로 삼지 않는 세 겹의 구조

초기안은 한 번의 내보내기를 다음과 같은 서로 다른 층으로 처리한다.

첫 구상에서는 원본을 raw_export/에 두고 scripts/convert_export.py로 변환하여 conversations/와 docs/에 배치하는 예가 제안되었다. 파일에 제목, 생성·수정 날짜, 태그, 프로젝트명, 요약 같은 메타데이터를 붙이고, 사람은 MkDocs로 탐색할 수 있도록 한다. 초기 성공 조건도 분명했다. 표본 내보내기 파일을 변환할 수 있어야 하며, mkdocs serve로 미리 보고 mkdocs build로 정적 사이트를 생성할 수 있어야 한다.

이 구조를 단일 폴더에 모든 문서가 섞이는 방식으로 만들지 않는 이유는 자료의 권위가 다르기 때문이다. 발화가 존재했다는 사실은 그 내용이 최종적으로 채택되었다는 뜻이 아니다. 개별 대화의 마지막 답변 역시 나중에 번복되었을 수 있다. 집필 모델은 대화를 많이 검색하는 것보다, 지금 유효한 결정이 무엇인지 정확히 아는 것이 더 중요하다.

원본 내보내기는 문서 제목, 대화 시각, 작업 경로 및 사적인 정보가 섞일 수 있는 자료다. 첫 제안에 포함된 .gitignore로 raw_export/와 ZIP을 제외한다는 조치는 최소한의 방어선이다. 변환된 대화별 Markdown 또한 자동으로 공개할 자료가 아니다. 공개할 수 있는 정제 원고와 비공개 원본·작업 사본은 저장 위치와 공개 절차를 분리해야 한다.

자료 저장소와 위키 엔진은 별개다

초기 설계에서는 세 유형이 선택지로 제시되었다. 이는 동시대 사용 실태를 조사하여 검증한 순위가 아니라, 용도별 아키텍처를 비교한 설계상의 분류다.

첫 권고는 Markdown + Git 저장소 + MkDocs Material + Codex였다. 초기에는 정적 페이지와 기본 검색으로 시작하고, 필요할 때 데이터베이스나 검색 계층을 추가한다는 단계적 접근이다. Obsidian은 개인 보관 방식, MkDocs는 독서·공개 방식, RAG는 탐색 방식이므로 서로 완전히 배타적인 선택지는 아니다.

장기 집필의 관점에서 더 중요한 결정은 도구 이름보다 하나의 정본을 유지하는 것이다. 원고를 여러 장소에 복사하고 각 복사본을 따로 수정하면, 어느 것이 최신인지 알기 어려워진다. 읽기 편한 사이트, 대화별 목차, 모델용 간추림 자료는 정본과 연결되어야 하며 그 자체가 새로운 권위가 되어서는 안 된다.

세계관의 기억에는 네 종류의 문서가 필요하다

장기 연재나 연속적인 창작은 단순한 사실 아카이브보다 더 엄격한 기억을 요구한다. 무엇이 존재하는가뿐 아니라, 왜 그 설정을 채택했는가, 어떤 선택을 버렸는가, 무엇이 아직 비어 있는가를 구별해야 한다.

확정 설정: canon

인물, 장소, 사건의 순서, 제도, 기술적 제약, 서술 규칙과 금지된 설정을 정본으로 둔다. 여기서 canon은 확인된 외부 역사 사실을 뜻하는 말이 아니라, 한 창작 프로젝트 내부에서 현재 유효하다고 승인된 설정이라는 뜻이다. 창작자가 승인하지 않은 모델의 제안을 확정 설정으로 승격해서는 안 된다.

결정 장부: decision log

결과만 남기면 같은 문제가 되풀이된다. 처음에는 그럴듯해 보였지만 특정한 모순 때문에 폐기한 대안, 더 평범한 일상성을 얻기 위해 화려한 연출을 줄이기로 한 이유 같은 선택의 근거를 남긴다. 이는 모호한 설정을 다시 해석할 때 유용하다. 결정의 변경도 과거의 판단이 존재하지 않았던 것처럼 지우지 않고, 무엇이 바뀌었는지 기록해야 한다.

미해결 문제: open questions

확정되지 않은 날짜, 지리적 배치, 인물 관계, 제도적 소속 등은 명시적으로 미정 상태로 유지한다. 이 빈칸은 결함이 아니라 창작의 여지다. 모델이 빈칸을 볼 때마다 자연스러운 사실인 양 메우면, 우연한 즉흥 발상이 다음 글의 구속 조건이 되는 설정의 무단 고착이 일어난다.

집필용 문맥 묶음: context pack

새로운 글을 쓰기 직전에 핵심 전제와 톤, 이번 작업과 관계된 확정 설정을 짧게 묶어 준다. 예컨대 미래의 일상생활을 다루는 연재에서는 거대한 사건의 설명보다 평범한 인물의 일상 감각을 앞세운다는 문체 규칙이 중요할 수 있다. 다만 요약 문맥 묶음은 사용 편의를 위한 파생물이어야 하며, 세부 정본과 충돌할 때 정본을 우선한다. 짧은 파일이 모든 예외와 반론을 대신하도록 해서는 안 된다.

초기 예시에는 'Yuna 2400' 같은 장기 창작 프로젝트를 위한 인물·거주지·포스팅 형식의 분리, 그리고 서로 다른 창작·설계 프로젝트를 프로젝트별로 나누어 관리하는 구상이 등장했다. 이는 정보 구조를 보여 주는 예시일 뿐, 예시에 적힌 인물·주소·계정·기술 사양 전체가 독립 검증된 설정이라는 뜻은 아니다.

GPT가 접근하는 경로: 읽을 수 있음과 최신임을 구분한다

외부 기억이 제대로 작동하려면 위키가 존재하는 것과 GPT가 실제로 그 내용을 읽을 수 있는 것을 구별해야 한다. 초기안에는 세 가지 접근 경로가 제시되었다.

첫째, ChatGPT 프로젝트의 파일을 사용하는 방법이다. 작업 전 사용할 주요 정본이나 문맥 묶음을 프로젝트에 첨부하는 방식이다. 특별한 서버를 만들지 않고 시작할 수 있지만, Git 저장소의 원고를 고친 뒤 프로젝트 파일도 자동으로 바뀐다고 가정해서는 안 된다.

둘째, Custom GPT의 Knowledge 파일을 이용하는 방법이다. 특정 프로젝트의 집필 규칙을 가진 전용 GPT를 구성할 수 있다. 그러나 업로드된 지식이 살아 있는 저장소와 계속 동기화되는지, 새 결정이 즉시 반영되는지는 별도의 확인 문제다.

셋째, GitHub·Google Drive·Notion 또는 자체 MCP와 연결된 외부 저장소를 읽는 방법이다. 장기적으로는 최신 원고를 검색하고 필요한 절을 읽으며, 승인된 집필 결과를 다시 정본에 되돌리는 순환을 상정할 수 있다. 하지만 읽기 권한, 쓰기 권한, 동기화 지연, 지원되는 도구의 범위는 서로 다르다. 외부 연결이 있다는 사실만으로 자동 검색·자동 편집·연속성 검증까지 완성된 것은 아니다.

현재의 누적형 지식백과는 이러한 문제 중 읽을 입구를 별도로 해결해 왔다. 자바스크립트로 본문을 그리는 웹사이트 주소보다, Markdown 원문 주소와 llms.txt가 일부 LLM 열람 도구에 더 확실한 길이 된다. 자세한 구현은 위키 운영 파이프라인의 링크 열람 절에 있다. 이는 제0호기에서 논의한 접근성 목표의 한 가지 실현이지, 당시 제안한 모든 연결 기술이 설치되었다는 뜻은 아니다.

Codex가 해야 하는 일과 집필 모델이 해야 하는 일

이 설계에서 Codex는 단순히 책의 저자가 아니라 책이 계속 자랄 수 있게 하는 편집 공정의 제작자다. 첫 업무는 내보내기 자료의 파싱, Markdown 변환, 메타데이터 부착, 정적 사이트 빌드, Git 관리, 공개·비공개 자료의 분리다. 다음 업무는 서로 다른 대화에서 프로젝트 후보를 찾고, 설정의 충돌과 미정 항목을 표시하며, 검토한 변경만 정본에 반영할 수 있게 하는 절차를 마련하는 것이다.

저장소 루트의 AGENTS.md는 Codex에게 목적과 경계 조건을 알려 주는 지침으로 제안되었다. 중요 규칙은 단순하다. 원본 내보내기를 Git에 올리지 말 것, 원본에 없는 사실을 만들지 말 것, 한국어 자료를 임의로 번역하지 말 것, 확정·후보·폐기·미정을 구별할 것, 새 아이디어를 무단으로 canon에 넣지 말 것. 모델에게 맡길 작업은 목표, 관련 파일, 금지 조건과 완료 조건을 함께 명시해야 한다.

집필 모델이 해야 하는 일은 다르다. 관련 정본과 문체 지침, 미해결 질문을 먼저 읽고 새로운 글을 쓴다. 새 글에 원래 없던 사실이 필요하면 본문과 구분해 정본 반영 후보로 표시한다. 설정 충돌 여부와 그 근거를 점검하되, 모델 자신의 판단을 곧바로 최종 승인으로 간주하지 않는다.

따라서 추천된 운영 고리는 다음과 같다.

1. 내보내기 또는 새로운 집필 결과를 자료로 수집한다.
2. Codex나 편집 에이전트가 주제별 지식·설정·결정 후보를 추출한다.
3. 기존 정본, 결정 장부, 미해결 질문과 대조하여 중복·수정·모순을 가른다.
4. 사람이 최종 설정의 승인 여부를 판단한다.
5. 승인된 내용만 정본에 반영하고, 문맥 묶음과 탐색 자료를 갱신한다.
6. GPT는 최신 정본과 필요한 문맥을 읽은 뒤 다음 집필을 수행한다.
7. 새 글에서 발생한 설정 후보를 다시 별도로 추출한다.

여기서 '사람이 승인한다'는 것은 사람이 모든 문장을 직접 작성한다는 뜻이 아니다. 집필 속도는 기계가 높이되, 작품의 사실과 방향을 바꾸는 권위 있는 결정은 누가 내리는지 명시한다는 뜻이다.

실패하기 쉬운 지점

가장 쉬운 실패는 원본 대화를 통째로 검색하게 하고 그것을 기억이라고 부르는 것이다. 그 안에는 진지한 결정과 농담, 오류와 정정, 첫 번째 구상과 폐기된 구상이 함께 있다. 자료를 많이 주는 것이 설정의 일관성을 뜻하지 않는다. 반대로 대화를 한두 문장으로 줄이는 요약도 위험하다. 결정의 이유와 반례, 설정을 지탱하는 세부가 사라지면 읽기 쉬운 정리가 다음 집필에서는 빈약한 제약으로 작동한다.

또 하나의 실패는 정본과 문맥 묶음이 각각 따로 자라는 것이다. 자동으로 생성되는 작은 요약은 자주 쓰이기 때문에 어느새 기준처럼 취급되기 쉽다. 상세 정본을 수정한 뒤 요약을 갱신하지 않으면 다음 글은 과거 설정을 따른다. 정보가 낡았거나 충분히 회수되지 않았을 때 '찾지 못했다'고 말할 수 있는 집필 과정이 필요하다.

마지막으로 공개와 권한의 혼동이 있다. 원본 파일을 Git에서 제외해도 이미 가공된 글에 민감 정보가 남을 수 있다. 공개 사이트에서 숨긴 문서도 공개 저장소 안에서는 읽힐 수 있다. 자동화를 맡긴 에이전트에게 원문 공개와 확정 설정의 변경 권한을 동시에 주는 것이 안전하다는 보장도 없다.

제0호기와 후속 누적형 지식백과의 차이

초기의 초점은 한 프로젝트를 오래 집필하기 위한 기억이었다. 그래서 대화 내보내기, 프로젝트별 canon, decision log, context pack, open questions, 스타일 지침이라는 제안이 중심을 이룬다. 원본을 정제하여 모델이 다음 글을 일관되게 이어 쓸 수 있는가가 관건이다.

이후 구축된 누적형 지식백과의 초점은 여러 대화에서 얻은 지식을 하나의 공개 저술로 총합·증보하는 일로 넓어졌다. 창작 세계관의 승인된 설정만 모으는 대신, 음악·철학·역사·기술의 논증과 반례, 독립적인 자료 목록까지 편집한다. Markdown 정본, manifest, 편집 장부, AI용 색인, 문서별 관계, 전체 지도와 절별 카드, 생성물 자동 배포라는 장치는 이러한 확장에 맞춘 것이다.

양쪽에 공통인 원리는 분명하다. 자료를 그대로 보존하는 일, 해석하고 집필하는 일, 확정된 지식으로 다음 작업을 시작하는 일은 서로 다른 단계다. 원본 대화는 곧바로 정본이 아니며, 검색용 요약도 정본을 대신하지 않는다. 한 번 확인하여 통합한 결과는 다음 집필의 출발점이 되어야 한다.

다만 제0호기의 제안 가운데 전량 내보내기 자동 변환기, MkDocs 사이트, 창작별 canon 승인 시스템, 자동 context-pack 생성, 전용 MCP 서버가 당시 구축되었다는 증거는 이 글의 자료 범위에 없다. 이들은 검토된 구상으로 기록하며 후속 지식백과의 실제 구현과 섞지 않는다. 초기 구상의 날짜가 이전 안내에서 2026년 5월 중순이라고 제시된 바 있으나, 내보내기 원본의 생성 시각을 직접 확인하지 못했으므로 여기서는 정확한 날짜를 확정하지 않는다. 이 제안이 2026년 10월의 구축 기록보다 설계상 선행하는 구상이었다는 점과 특정 구현이 끝났다는 주장은 분리한다.

남겨진 설계 문제

제0호기는 답보다 다음의 질문을 남긴다. GPT가 전자책처럼 모든 원고를 통째로 읽지 않고도 필요한 정본 절을 정확히 찾는가. 기억의 최신성을 어떻게 확인하는가. 장문의 집필에서 문체 지침과 사실 제약의 우선순위가 충돌하면 누가 결정하는가. 임시 묘사가 어느 시점에 확정 설정이 되는가. 승인되지 않은 문맥 묶음이나 요약이 뒤의 글에서 사실로 재활용되는 것을 어떻게 막는가. 그리고 원본 대화와 비공개 프로젝트를 보호하면서도 공개 가능한 지식은 어떻게 장기적으로 축적할 것인가.

그 결과 제0호기가 던지는 질문은 단순한 '대화를 위키로 만들 수 있는가'가 아니다. 기억을 외부에 두었을 때, 다음의 지능이 그것을 정확히 읽고, 수정의 권위를 지키면서, 이전보다 더 멀리 쓸 수 있는가이다.

관련 문서

• 누적형 지식백과 구축사: 총합·증보를 위한 설계와 구현
• 원고만 쓰고 나머지는 기계에게: 위키 운영 파이프라인
• 사람과 AI가 함께 편집하는 규칙