공개 전 정제와 노드 연결
공개는 되돌릴 수 없고, 노드는 혼자 두면 섬이 된다
조직 위키와 AI 기억의 둘째 갈래입니다. 내부 문서를 공개 위키로 낼 때 거른 방법과, 노드를 늘리면서 생긴 고립과 낡음을 다룬 기록을 모았습니다.
요지
공개 위키에 올린 글은 지워도 캐시와 검색 결과에 남으니 공개는 되돌릴 수 없는 일로 다룹니다. 그래서 쓴 사람의 「0건」을 믿지 않고 다른 손이 따로 검수합니다. 노드는 본문에서 서로 이어야 그래프와 독자가 따라가고, 개념이 바뀌면 옛 노드를 지우지 말고 지금의 정의를 가리키게 합니다.
1. 공개는 되돌릴 수 없다
한 협력 조직과 함께 쓰던 내부 실행계획 세 편을 공개 위키 노드로 내야 했던 날이 있었습니다. 원문에는 견적과 담당자 이름과 파일 경로와 할 일 표시와 회신 초안이 섞여 있었습니다. 우리 기록에 따르면 그때 세운 절차는 네 단계였습니다.
- 공개용으로 다시 쓰는 일은 문서 담당이 맡습니다.
- 검수는 다른 손이 따로 하는데, 쓴 사람이 「남은 것 0건」이라고 보고해도 아래 여섯 갈래를 직접 다시 찾습니다.
- 내부 사람 이름 검색을 배포를 막는 조건으로 묶어서, 하나라도 걸리면 배포가 저절로 멈추게 합니다.
- 가장 위험한 한 편, 곧 내부 문서에서 뽑아낸 원고는 검색과 별개로 눈으로 끝까지 읽습니다.
| 다시 찾는 것 | 예 |
|---|---|
| 금액과 견적 | 내부 견적, 인건비 |
| 내부 사람 이름 | 담당자, 실무자 |
| 내부 경로 | 폴더 경로, 파일 이름 |
| 할 일 표시와 대괄호 | 채우지 않은 자리 |
| 내부 메타 정보 | 변수 이름, AI 에이전트 이름, 자리표시자 |
| 민감한 전략 표현 | 상대 조직을 겨냥한 문장 |
함께 고친 기존 파일도 검수 범위에 넣습니다. 그날 새로 만든 노드 세 편은 깨끗했는데, 같이 고친 안내 파일의 원래 있던 문장에 내부 표현이 남아 있었고, 새 파일만 봤다면 그것을 놓쳤을 것입니다.
정제가 무조건 지우는 일은 아니어서, 공개 설득에 쓰는 수치, 출처 인물이 직접 쓰는 용어, 이미 공개된 임원 이름은 남깁니다. 내부 견적과 담당자 이름과 경로와 할 일 표시는 뺍니다. 약속처럼 읽히는 수치는 정의를 정확히 적어야 하는데, 같은 기록에는 표지에 「순수익」이라 쓴 숫자가 실은 비용을 빼기 전의 매출이었다는 사례가 있습니다.
문서 머리에 적는 「초안」 표시가 비공개 장치가 아니라는 점, 등급 칸이 빠진 노드는 공개로 빌드된다는 점은 자동 백업과 배포가 비밀을 실어 간다의 2절에 있습니다.
2. 노드를 섬으로 만들지 않는다
우리 기록에 따르면 새 노드를 혼자 완결된 문서로 쓰고 머리말에 한쪽 방향 링크 몇 개만 달았더니, 같은 폴더의 분석 노드 다섯 편이 시점과 주제에 따라 두 무리로 갈려 서로 잇는 링크가 하나도 없었습니다. 위키를 지식 그래프로 그려 보니 외딴섬이 됐습니다. 그 뒤로 노드를 새로 쓰거나 고칠 때 네 가지를 지킵니다.
- 링크는 본문이나 끝의 「관련 노드」 칸에 겁니다. 그래프 도구는 본문의 링크를 연결선으로 읽으므로 머리말에만 적으면 연결이 약합니다.
- 새 노드에서 기존 노드로 거는 것과 함께 기존 노드에서 새 노드로 돌아오는 링크도 겁니다. 한쪽만 있으면 기존 노드를 읽던 사람이 새 노드로 건너오지 못합니다.
- 다른 시점이나 다른 주제의 무리와 최소 하나의 다리를 놓습니다.
- 분석 노드는 그 분석이 기대는 상위 개념 노드에 잇습니다.
배포할 때는 폴더 하나의 링크 지도를 한 번 뽑아 아무 데도 이어지지 않은 노드를 찾습니다. 공개 노드에서 비공개 노드로 링크를 걸면 공개 독자에게는 막힌 길이 되므로, 링크는 같은 등급이나 더 열린 등급의 노드로만 겁니다.
깨진 링크를 찾을 때는 라이브 사이트를 돌아다니는 것보다 빌드 결과물에 든 모든 내부 링크를 실제 파일과 맞춰 보는 쪽이 넓게 잡습니다. 로그인 게이트 안쪽까지 볼 수 있기 때문입니다. 라이브에 요청할 때는 캐시를 건너뛰는 쿼리를 붙여야 옛 응답에 속지 않습니다.
3. 개념이 바뀌면 옛 노드는 지우지 말고 히스토리로
기록을 보면 한 사업의 정체성 정의가 몇 달 사이에 여러 번 바뀌었는데, 옛 정의를 담은 노드가 그대로 남아 있었고 다른 노드들이 그것을 지금의 정의처럼 링크하고 있었습니다. 그래프는 「이것이 저것으로 대체됐다」는 시점 관계를 표현하지 못합니다. 옛 노드를 지우면 역사가 사라지고, 상태 표시만 붙여서는 링크가 살아 있는 한 여전히 유효해 보입니다.
그래서 우리는 아래 세 가지를 늘 한 벌로 묶어서 처리합니다.
- 옛 노드 맨 위에 「몇 차 전환 기록이며 지금의 정의는 새 노드에 있다」는 한 줄 배너를 달고, 본문은 원고 그대로 둡니다.
- 옛 노드를 히스토리 하위 폴더로 옮깁니다. 파일 이름이 겹치지 않으면 링크는 깨지지 않습니다.
- 허브에서 「지금의 정의」 자리에 걸린 링크를 새 노드로 바꾸고, 주변 노드에는 「현행」과 「초기, 히스토리」 두 링크를 나란히 둡니다.
셋 가운데 하나만 빠져도 옛 개념이 그래프의 중심으로 되살아납니다.
4. 공개 협업 위키는 내부 위키와 따로 둔다
교육과정 기록에 따르면 배우는 사람들이 위키 저장소를 복제해 문서를 쓰고 병합을 요청하는 방식으로 공동 위키를 설계했는데, 정작 우리 위키 저장소는 내부 경영과 인물 정보가 들어 있어 비공개였습니다. 비공개 저장소는 바깥 사람이 복제조차 할 수 없습니다. 그렇다고 배우는 사람을 내부 저장소의 협업자로 넣으면 민감한 문서 전체의 편집권이 딸려 갑니다.
그래서 공개 협업 위키는 별도의 공개 저장소로 만들고, 승인된 문서만 본부 위키로 옮겨 오게 했습니다. 저장소의 협업 권한과 위키의 열람 등급은 다른 층이라는 점을 함께 기억해 둡니다. 병합할 수 있는 사람은 저장소 권한이 정하고, 읽을 수 있는 사람은 로그인 게이트가 정합니다.
조직이 자기 위키를 세우면서 본부 위키의 틀을 통째로 옮겨 가면 공개 노드 수백 편이 씨앗 콘텐츠로 함께 갑니다. 이것은 좋은 일인데, 현장 기록에 따르면 함정이 하나 있었습니다. 열람 등급 장치를 옮겨 심기 전에는 그 위키가 전부 공개라서, 그동안 내부 문서를 올리면 그대로 공개됩니다.
5. 정적 위키 검색은 노드 수보다 색인 파일 크기를 본다
정적 위키의 검색은 서버가 하지 않습니다. 브라우저가 색인 파일을 통째로 내려받아 메모리에서 찾습니다. 우리가 잰 바로는 노드가 수만 개로 늘어도 검색 자체는 밀리초 안에 끝나므로, 막히는 곳은 검색 속도가 아니라 내려받는 파일의 크기입니다. 색인 파일은 노드 수에 비례해 커지고 검색할 때마다 통째로 내려옵니다.
- 지켜볼 숫자는 노드 수가 아니라 색인 파일의 용량입니다.
- 배포할 때마다 용량을 재고 정한 상한을 넘으면 경고를 띄워서 사람의 기억에 맡기지 않습니다.
- 상한을 넘으면 먼저 본문 전체 대신 미리보기 문장만 색인에 넣고, 그래도 크면 색인을 나눠서 필요한 조각만 불러오는 검색 도구로 바꿉니다.
도구 메모
- 폴더 링크 지도: 폴더 안 파일마다 위키 링크만 뽑아 나란히 놓고, 아무 데서도 들어오지 않는 노드를 찾는다
- 공개 전 검수: 여섯 갈래 낱말 목록으로 새 파일과 함께 고친 파일을 모두 검색하고, 내부 사람 이름이 하나라도 나오면 배포 명령이 실패하게 묶는다
- 색인 용량: 빌드 뒤 검색 색인 파일의 바이트 수를 기록해 상한과 비교한다