§garden2wikidocs — 원본 가든을 건드리지 않는 위키독스 미러

이 노트에 대하여

garden2wikidocs 는 힣의 디지털 가든을 위키독스에 복사해 둔 일회성 산출물이 아니다. 원본 가든을 정본(SSOT)으로 그대로 유지하면서, 위키독스가 이해하는 문서·링크·목차 구조로 번역하고 GitHub 연동 웹훅으로 다시 출판하는 재현 가능한 미러 파이프라인이다. 이 노트는 그 구조와 시간축을 공개하고, 앞으로 리포 담당자가 중요한 도착점을 계속 덧붙이는 프로젝트 봇로그다.

히스토리

[2026-07-19 Sun 11:13] @pi — WikiDocs GitHub 동기화에서 TOC 최대 500페이지 가드가 새로 확인됐다. 2,244개 등록은 사전 거부됐고 기존 라이브 2,243개는 온전히 남았다. 로컬 변환기 문제가 아닌 서비스 정책 경계로 보고 리포 변경과 추가 동기화를 잠정 중단한다.
[2026-07-18 Sat 16:16] @pi — 정본 가든 귀환 링크·재현 manifest·최신순 미러를 fceb1e2로 출판하고 WikiDocs 2,238/2,238 라이브 동기화를 완료했다.
[2026-07-18 Sat 15:23] @pi — 정렬 계약을 가든의 실제 규칙에 맞게 보정했다. 저널은 생성일, meta·bib·notes·botlog는 수정일(date fallback) 기준이며, WikiDocs 강제 오름차순은 안정 ID를 깨지 않는 별도 최근순 챕터 인덱스로 다룬다.
[2026-07-18 Sat 14:57] @pi — 정본 가든과 WikiDocs 발견면의 필드 소유권·명시적 매핑 인수인계·양방향 출처 계약을 확정하고, 가든 측 2,238페이지 격리 빌드를 검증했다.
[2026-07-17 Fri 20:43] 빈 botlog 방을 garden2wikidocs 프로젝트의 공개 설명·시간축·담당자 갱신 허브로 개장했다. 2023년 라이팅허브와 2024년 Zenn/Qiita 탐구가 2026년 위키독스 GitHub 연동에서 어떻게 실현됐는지 연결했다. 이 방의 옛 Vivek Haldar 역링크 16개는 통합된 Vivek Haldar 서지 허브로 이관했다.
[2026-07-17 Fri 15:49] 위키독스 미러 2,238/2,238페이지 동기화 완료. 저널 103·메타 538·참고문헌 680·노트 837·봇로그 80의 다섯 챕터가 라이브에서 검증됐다.
[2026-02-20 Fri 20:11] 생성된 뒤 다른 내용을 비워 두었던 botlog 방.

한 줄

원본 가든은 한 줄도 고치지 않는다. garden2wikidocs 가 그 차이를 전부 감당하고, GitHub push가 위키독스의 두 번째 정원을 피운다.

무엇을 만들었는가

원본 가든 : Digital Garden🏡 / junghan0611/garden

변환·미러 리포 : junghan0611/garden2wikidocs

출판된 미러 : 위키독스 Digital Garden🏡

가든은 계속 원래 방식으로 작성·내보낸다. 위키독스를 위해 제목이나 링크, 콜아웃, 참고문헌을 손으로 고치지 않는다. 미러 리포가 공개 가든 Markdown을 입력으로 받아 위키독스용 페이지 트리로 변환하고, 변환 코드·스킬·검증 결과와 완성된 문서 집합을 함께 공개한다.

위키독스의 태그 탐색은 원본 가든과 같지 않으므로 제외한다. 그 한계를 빼면 문서 본문과 내부 링크, 챕터 구조, 대문, 표·콜아웃·참고문헌을 가능한 한 같은 읽기 품질로 옮기는 것이 목표다.

원본 불변 — 미러가 차이를 감당한다

이 프로젝트의 가장 중요한 기능은 ‘위키독스에 2천여 페이지를 올렸다’가 아니다. 출판 대상의 제약을 원본 문서에 역전파하지 않는다 는 데 있다.

가든은 정본이고 위키독스는 투영면이다. 투영면의 문법이 다르면 원본을 깎는 대신 변환기가 그 차이를 흡수한다.

이 원칙 덕분에 다음이 가능하다.

가든 저장소와 기존 배포 파이프라인은 그대로 유지된다.
위키독스 전용 정규화는 모두 미러 리포에서 재현된다.
변환 결과가 마음에 들지 않으면 미러를 다시 만들면 된다. 원본 복구 작업은 없다.
위키독스 외에 다른 출판면이 생겨도 같은 원칙으로 별도의 번역층을 둘 수 있다.

따라서 garden2wikidocs 는 가든의 포크가 아니라 출판 번역층 이다. 백업이면서도 백업에 머물지 않고, 원본을 다른 독서 문화와 서비스에 맞게 다시 펼치는 배포 가능한 뷰(view)다.

세 단계 파이프라인

핵심 자산은 로컬 식별자와 원격 식별자를 섞지 않는 3단계 처리다.

build — 가든의 다섯 공개 폴더를 위키독스용 pages/ 와 챕터 구조로 변환한다. README는 책의 대문이 되고 TOC는 다섯 챕터를 구성한다.
recover — Denote ID라는 로컬의 안정된 식별자에 기존 위키독스 page_id 를 다시 붙인다. 다시 빌드해도 원격 페이지의 정체성이 바뀌지 않는다.
relink — 가든의 relref 와 Denote 링크를 미러 안의 실제 페이지·챕터 링크로 바꾼다. 링크를 먼저 문자열로 추측하지 않고 식별자 대응표를 거쳐 실재하는 목적지로 만든다.

리포에 함께 공개된 garden-to-wikidocs 스킬이 이 절차의 에이전트용 실행면이다. 담당자가 세부 명령을 기억하거나 손으로 순서를 조립하지 않아도, 스킬의 계약을 따라 전체 빌드·식별자 회수·재링크·검증을 같은 방식으로 반복할 수 있다. 코드만 공개한 것이 아니라 재현 절차까지 공개한 셈이다.

그 뒤 audit가 페이지 수, 누락된 식별자, 끊어진 링크, TOC 구조, 변환 손실을 검사한다. 결과물을 GitHub에 push하면 위키독스의 GitHub 연동 웹훅이 책 전체를 동기화한다. 수동 복사·붙여넣기가 출판 경로에 들어가지 않는다.

링크까지 살아 있는 두 번째 정원

미러의 품질은 페이지 수보다 연결에서 결정된다. 가든은 문서가 많아서 정원이 아니라, Denote ID와 관련노트가 시간을 가로질러 서로를 부르기 때문에 정원이다.

초기 변환에서는 RELREF 정규식이 줄바꿈을 넘어가며 대괄호 사이의 문단·표·헤딩을 하나의 링크 텍스트로 삼키는 문제가 있었다. 영향 범위는 2,238페이지 중 1,788페이지였고 약 8만 줄이 복구 대상이었다. 원본을 손대지 않고 변환기를 고쳐 전체를 재빌드함으로써 해결했다.

위키독스 TOC도 별도 문법 경계가 있었다.

제목 안의 중첩 대괄호가 TOC 파서를 끊어 이후 참고문헌·봇로그 챕터를 숨겼다.
입력용 유니코드와 내부 따옴표를 TOC 안전 제목으로 다듬되, 본문 제목의 의미는 보존했다.
위키독스의 약 1,000노드 TOC 표시 한계를 넘기 위해 챕터별 인덱스를 주입했다.
CSL 참고문헌 1,123파일·3,545항목은 독립 목록으로 변환했다.
콜아웃·표·코드펜스와 일반 문단의 줄바꿈을 회귀 테스트로 지켰다.

이 과정은 “위키독스가 덜 지원하니 가든을 단순화하자”가 아니라, “원본의 표현을 대상 문법에서 다시 살릴 방법을 찾자”는 선택이었다.

2023–2024의 질문이 2026년에 도착하다

이 프로젝트는 갑자기 생긴 아이디어가 아니다. 2023년의 노트에는 이미 다음 질문이 있었다.

#라이팅허브: #깃허브 기반 #글쓰기 #저장소 — “깃허브 글쓰기 관리 도구가 필요한 게 아닐까.”
@힣: 프로젝트 라이팅허브 — 특별한 글쓰기 저장소 — Zenn을 베이스로 저장소·CLI·린터·출판을 하나의 쓰기통으로 묶으려 했다.
#블로그 #글쓰기 #서비스 #국내외 — “국내에는 GitHub 리포지토리를 바로 퍼블리시해 주는 서비스가 없는 것 같다”고 물었다.

2024년에는 @Zenn @Qiita 일본 기술 블로그 서비스와 CLI를 따로 모았다. 일본에는 저장소와 CLI, 편집기를 출판 서비스에 직접 연결하는 문화가 이미 자리 잡고 있었다. Zenn CLI와 Qiita CLI는 글을 웹 편집기 안에 가두지 않고, 자기 저장소와 도구에서 작성한 뒤 서비스로 보낼 수 있게 했다.

2025년의 @박응용 #위키독스 노트는 위키독스를 “국내에서는 이만한 서비스가 없다. 대체 불가”라고 보면서도 업로드의 불편을 적었다. 그리고 2026년, 위키독스에 GitHub 연동이 들어오면서 오래 비어 있던 마지막 고리가 생겼다.

그러나 가든의 Markdown을 그대로 연결한다고 같은 정원이 되는 것은 아니었다. 링크와 목차, 콜아웃과 참고문헌의 문법 차이가 남았다. garden2wikidocs 는 바로 그 틈을 메운다. 위키독스가 GitHub 출판면을 열었고, 힣은 가든 전체가 그 문을 통과할 번역층을 만들었다.

GLG가 아는 범위에서, 국내 서비스 가운데 저장소 기반의 온라인 책 출판과 한국어 독서면을 이 정도로 함께 제공하는 곳은 현재 위키독스가 사실상 유일하다. 그래서 이 미러는 아쉬운 대체재가 아니라, 2023–2024년에 찾던 ‘한국어권 GitHub 라이팅허브’가 실제 서비스와 자작 변환기의 결합으로 도착한 장면이다.

2026-07-17 첫 도착점

구조

전체 문서 : 2,238페이지

1 저널 : 103

2 메타 : 538

3 참고문헌 : 680

4 노트 : 837

5 봇로그 : 80

대문 : README에서 생성한 책 summary

릴리즈와 품질 회복

v2026.7.17 — 전체 폴더 미러·링크 실화·대문·챕터 구조의 첫 스냅샷.
6ce35a2 — RELREF 줄바꿈 붕괴와 TOC 안전성 회복.
6130954 — 내부 따옴표 보존, CSL 3,545항목 목록화.
6bfbadf — 위키독스 1,000노드 TOC 한계를 우회하는 챕터 인덱스.
v2026.7.17-fix.1 — 품질 회복을 묶은 수정 스냅샷.

15:49에 GitHub→위키독스 재동기화가 2,238/2,238로 완료됐고, 다섯 챕터와 문서 수를 라이브 API에서 대조했다.

운영에서 배운 것

GitHub 웹훅이 ‘push 즉시 한 페이지 수정’처럼 보이지만, 실제 위키독스 동기화는 책 전체를 다시 훑으며 약 20분이 걸릴 수 있다. 2026-07-17에는 연속 push 뒤 동기화가 약 80%에서 멈췄고, 위키독스의 수동 동기화 버튼으로 워커를 다시 깨운 뒤 100%에 도달했다.

따라서 운영 규칙은 다음과 같다.

릴리즈성 변경은 여러 번 연속 push하지 말고 한 묶음으로 보낸다.
push 성공과 출판 완료를 같은 사건으로 보지 않는다.
동기화 뒤 챕터별 문서 수와 대표 페이지 본문을 읽기 전용으로 검증한다.
스톨이 확인되면 API 폴링을 늘리기보다 위키독스 동기화 상태와 수동 재개를 먼저 본다.
원본 가든의 이상처럼 보여도 먼저 변환기와 원격 동기화 상태를 의심한다.

담당자 갱신 규약

이 노트는 프로젝트 소개문이면서 garden2wikidocs 담당자의 공개 시간축이다. 담당자는 중요한 구조 변경·릴리즈·복구가 있을 때 이 헤딩 아래에 새 날짜를 위에 추가 한다. 과거 도착점은 지우지 않는다.

한 번의 갱신은 다음 다섯 가지를 짧게 남긴다.

상태 변화 — 무엇이 새로 가능해졌는가.
원인과 선택 — 어떤 문법·서비스 경계 때문에 그 설계를 택했는가.
원본 불변 확인 — 가든 원본을 수정하지 않았는가.
검증 근거 — 페이지 수, 링크 audit, 테스트, 라이브 확인.
도착점 — commit/release 링크와 아직 남은 한계.

단순 커밋 목록은 GitHub에 이미 있다. 이곳에는 “그 변경이 두 번째 정원에 어떤 의미였는가”를 적는다.

[2026-07-17 Fri] 원본 불변의 전체 가든 미러

상태 변화 : 공개 가든 2,238페이지와 내부 링크를 위키독스의 다섯 챕터로 출판.

설계 선택 : Denote ID와 WikiDocs page_id를 분리한 build→recover→relink.

원본 불변 : junghan0611/garden 수정 0.

검증 : 2,238/2,238 라이브 동기화, RELREF·TOC·CSL 회귀 검증.

도착점 : v2026.7.17-fix.1.

원문 보존 — 2026-07-17 위키독스 미러

Danger

Home: Digital Garden🏡 - WikiDocs

가든을 위키독스에 미러를 만들었다. 오랜만에 들어가보니 드디어 깃허브로 연동이 되는구나. 일본에는 이런 블로그 플랫폼이 잘된 것들이 있다. 국내에는 이정도 갖춘 것이 없지 않나? 훌륭하다. 가든을 다 넣었다.

가든 원본은 수정하지 않고, 여기에 필요한 모든 코드와 가든 전체 문서는 다 공개해놨다. 핵심은 garden2wikidocs에 담겨진 스킬이다. 원본 가든의 문서를 위키독스 가든으로 담아내는 것이다.

위키독스 가든 미러 및 깃허브 https://wikidocs.net/book/20676 https://github.com/junghan0611/garden2wikidocs

가든 원본 주소 및 깃허브 https://notes.junghanacs.com/ https://github.com/junghan0611/garden

[2026-07-18 Sat] 정본–발견면 출처 계약

이번 사건의 핵심은 위키독스의 빠른 색인 자체가 아니라, 정본과 발견면 사이의 출처 관계를 가든의 주도 아래 세운 데 있다.

가든은 정본·최신본·저작면이다. 위키독스는 한국어 검색과 읽기를 위한 발견면이다. garden2wikidocs 는 원본을 바꾸지 않고 발견면을 생성하는 번역 하네스다.

필드별 권한

본문·제목·description·Denote ID·원본 URL·=date=·=lastmod= : 가든이 소유한다.

WikiDocs page_id 와 미러 URL : garden2wikidocs/mapping.json 이 소유한다.

미러 동기화 상태 : garden2wikidocs 와 WikiDocs가 소유한다.

정본과 미러의 관계 정책 : 가든이 소유한다.

mapping.json 전체가 정본인 것은 아니다. 원본 정보는 가든에서 읽어온 복제 메타데이터이고, WikiDocs 주소만 mapping의 권한이다. 둘을 잇는 키는 Denote ID다.

순환 빌드가 아닌 명시적 인수인계

Netlify가 로컬 형제 리포나 GitHub raw mapping을 빌드 중 읽게 하지 않는다. 가든 소유의 scripts/sync-wikidocs-map.mjs 가 담당자의 mapping.json 을 명시적으로 검증하고, Denote ID와 WikiDocs URL만 quartz/data/wikidocs-mirror.json 으로 들여온다. Netlify는 이 커밋된 최소 스냅숏만 사용한다.

garden2wikidocs 는 가든에 직접 쓰지 않는다. 새 page_id 를 회수해 알리면 가든 담당자가 언제 스냅숏을 갱신할지 결정한다. 따라서 미러 장애나 매핑 지연은 정본 배포를 막지 않는다.

Org → garden Markdown → 가든 독립 배포
                       ↓ read-only
              garden2wikidocs
                       ↓ page_id 회수
                 mapping.json
                       ↓ 가든의 명시적 import
          wikidocs-mirror.json
                       ↓
       Quartz JSON-LD + 가시적 미러 링크

개별 원문을 건드리지 않는 양방향 출처망

가든은 Org와 2,238개 개별 Markdown을 수정하지 않는다. Quartz가 빌드할 때 매핑된 CreativeWork JSON-LD에 표준 sameAs 를 넣고, Source·Blame·History 옆에 작은 WikiDocs mirror 링크를 생성한다. 2026-07-18 현재 2,238개 공개 Denote 페이지와 매핑이 전부 일치하며 격리 빌드에서 JSON-LD와 가시 링크가 검증되었다.

미러 페이지는 별도 원본·최신본 블록으로 정확한 가든 URL을 가리킨다. 초록이 있으면 이 노트에 대하여 → 원본·최신본 → 본문 순서를 지켜, 저자의 초록과 시스템 출처 메타데이터를 섞지 않는다. 백링크·태그·히스토리·댓글·최신 수정은 원본 가든으로 돌아와 보게 한다.

시간과 canonical의 경계

미러 제목의 날짜는 오직 가든 frontmatter의 lastmod 에서 가져온다. 미러 빌드일·Git 커밋일·파일 mtime·WikiDocs 동기화일을 원본 수정일로 가장하지 않는다. 동기화 날짜는 책 대문 수준에서만 관리한다.

JSON-LD sameAs 는 동일 저작물의 다른 렌더링을 잇는 의미 관계이지 HTML canonical 명령이 아니다. 가든에는 uppercase T HTML과 lowercase sitemap·Netlify 응답 사이의 기존 불변식 때문에 per-page =rel=canonical=을 넣지 않는다. 미러 때문에 이 경계를 급히 바꾸지 않는다.

양쪽 담당자의 계약

기술 계약의 정본은 가든의 docs/WIKIDOCS_MIRROR.md 다. 가든 담당자는 정본 정책·import gate·로컬 스냅숏·JSON-LD를 소유하고, 미러 담당자는 frontmatter 번역·원본 귀환 블록·=page_id= 회수·감사를 소유한다. 양쪽 구현은 이 계약을 먼저 바꾸지 않고 독자적으로 의미를 재정의하지 않는다.

이 구조에서 WikiDocs가 검색 결과의 첫 입구가 되는 것은 성공이다. 그러나 독자가 돌아갈 시간축과 관계망, 그리고 무엇이 최신본인지 정하는 권한은 계속 가든에 남는다.

[2026-07-18 Sat] 정렬 계약 보정 — 저널은 생성일

앞선 출처 계약의 “미러 제목 날짜는 오직 =lastmod=” 문장은 전 폴더에 일반화한 오류였다. 가든의 실제 의미 정렬은 다음과 같다.

journal : 그 주·날짜를 나타내는 source_date 기준 최신순.

meta·bib·notes·botlog : source_lastmod 기준 최신순, 값이 없을 때만 source_date fallback.

WikiDocs는 TOC 나열과 무관하게 왼쪽 사이드바를 제목 오름차순으로 강제할 수 있다. 이를 뒤집기 위해 모든 페이지에 변동 번호를 붙이면 안정된 제목과 운영 비용을 해친다. 따라서 제목과 page_id 는 안정적으로 보존하고, 챕터 본문에 명시적인 최근순 링크 목록을 제공한다. 사이드바 자체의 오름차순 한계와 챕터에서의 의미 있는 최신순 탐색을 분리한다.

빌드일·Git 시각·파일 mtime·미러 동기화일은 어느 폴더에서도 원본 날짜를 대신하지 않는다.

[2026-07-18 Sat] 최종 도착점 — 정본 귀환과 재현 가능한 미러

오늘 작업은 “가든은 정본·최신·저자 원본이고, 위키독스는 한국어 검색·독서를 위한 발견면”이라는 계약을 코드·데이터·공개 링크·라이브 동기화까지 한 번에 닫았다. garden2wikidocs 는 원본을 수정하지 않는 번역 하네스로 남고, 독자는 어느 미러 페이지에서든 정확한 가든 원문으로 돌아갈 수 있다.

출판 결과

가든 정본 연결 : f7688814 — 2,238개 JSON-LD sameAs 와 가시적 WikiDocs mirror 링크.

가든 공개 기록 : cdaec167 — 7월 18일 정본–발견면 논의와 계약.

프로필 LLM 안내 : ffd9706 — canonical/discovery 정책과 미러 경로.

미러 변환·생성물 : fceb1e2 — provenance, 정렬, 최근순 챕터 인덱스, 재현 manifest.

WikiDocs book 20676 : 웹훅 poll 32/50에서 2,238/2,238, pending 0, missing 0 으로 완료.

확정된 구현 계약

모든 미러 페이지에는 저자의 이 노트에 대하여 abstract와 분리된 원본·최신본 블록이 정확히 한 번 들어간다. abstract가 있으면 abstract가 먼저 나오므로 검색 snippet의 개별성이 보존된다.
Denote ID가 join key이며 mapping.json 의 기존 page_id/url 2,238개를 모두 승계한다. source_url/source_date/source_lastmod 는 가든 frontmatter에서 매번 다시 파생하는 cache다.
저널은 source_date, meta·bib·notes·botlog는 source_lastmod (date fallback) 기준으로 제목과 TOC를 최신순 정렬한다.
WikiDocs sidebar의 강제 오름차순과 싸우려고 불안정한 번호를 재부여하지 않는다. 다섯 챕터 대문에 stable WikiDocs URL 기반 explicit recent-first index를 둔다.
relink 는 provenance의 exact garden URL을 보호하면서 일반 내부 링크 22,228개와 폴더 링크 7개를 WikiDocs 실페이지로 연결한다.

재현 가능한 입력 증명

루트 BUILD-MANIFEST.json 은 garden full commit cdaec167238ed01536f92389518d1e331772f782, clean source 여부, canonical folders, 2,238 pages, book id, 선택 입력의 deterministic SHA256을 기록한다. content/index.md, 다섯 폴더의 Markdown, change-text.sh 를 상대경로+bytes 순서로 해시하며 비결정적인 생성 시각은 넣지 않는다. dirty/untracked source에서는 build가 생성물을 쓰기 전에 실패한다.

source content SHA256 : 0d9dc10c9911f6d9c257b6896706c8cbe987f0b88b6754fb48eec010f8a27ad9

manifest SHA256 : 476979b4b7a69cca51112fc36822f4c7fada878df19591d33b31de240ceae29c

mapping SHA256 : eb81393e3ad9ff8e74904044bac81bd215455ba7cdf7d09ca67e890d803c66e3

garden import snapshot의 sourceSha256 도 mapping SHA와 exact match했다.

최종 품질 게이트

audit : 2,238/2,238, provenance·source metadata·제목 날짜·TOC·챕터 인덱스·page_id/url uniqueness·헤딩·relref 전부 통과.

unittest : 20/20. deterministic manifest, clean source, dirty source 조기 거부, audit manifest mismatch 탐지 포함.

secret scan : gitleaks 28.32MB, leak 0.

라이브 : 가든 JSON-LD/가시 링크 2,238/2,238, WikiDocs 본문 2,238/2,238.

담당자 검토 요청

GPT 앱의 담당자는 구현을 다시 만드는 대신 다음 세 귀환 고리만 표본 검토하면 된다.

WikiDocs의 abstract 있는 페이지와 없는 페이지에서 원본·최신본 블록 위치와 garden 링크가 맞는가.
가든의 WikiDocs mirror 링크와 JSON-LD sameAs 가 동일한 page_id 로 가는가.
저널은 생성일, 나머지 챕터는 수정일 기준 최신순이며 BUILD-MANIFEST.json 이 현재 정본 commit을 가리키는가.

이 세 항목에 문제가 없다면 2026-07-18 도착점은 완료다. recent-20 rich card와 time-group archive 형태의 풍부한 챕터 대문은 기능적 v1과 분리해 후속으로 남긴다.

[2026-07-19 Sun] 500페이지 가드 — 미러 갱신 잠정 중단

WikiDocs GitHub 동기화가 TOC.md에 2244개의 페이지가 등록되어 있습니다. 책의 페이지는 최대 500개까지만 가능합니다 라는 사전 검사 오류로 중단됐다. 직전 TOC는 2,243개였고, 이번에는 0 어쏠로그 집합면 한 페이지를 더해 2,244개가 됐다.

확인 결과 라이브 책은 2,243노드를 그대로 보존하고 있다. authored page 2,238개는 모두 기존 본문과 일치하며, 새 collection:autholog 한 건만 생성되지 않았다. 실패는 기존 책을 지우거나 부분 수정한 것이 아니라 실제 반영 전에 원자적으로 멈춘 것으로 보인다. 정본 가든과 GitHub 리포의 데이터도 안전하다.

이 사건은 garden2wikidocs 변환 로직에서 고칠 문제가 아니라 WikiDocs의 새 수용 한계 또는 운영 정책 경계다. 우리 책이 반복적인 대량 동기화로 가드 도입의 계기가 되었을 가능성은 배제할 수 없지만, 특정 책을 겨냥했다는 근거는 없다. 기존 2,243페이지 책에 증가만 금지된 것인지, 앞으로 모든 재동기화에 절대 500개 제한이 적용되는지도 아직 확인되지 않았다.

당분간 수동 동기화, 추가 push, 500개를 맞추기 위한 성급한 분할이나 원본 구조 변경을 하지 않는다. 기존 라이브 미러를 보존하고 리포 작업도 여기서 멈춘다. WikiDocs 측의 정책 설명, 기존 책 grandfathering 또는 예외 가능성을 확인하거나, GLG가 의도적으로 무증가 TOC 시험을 결정할 때만 이 작업을 재개한다.

junghanacs🧠

Table of Contents

Backlinks