Wiki 현황 정리 (2026-09-18, 2026-09-21 갱신)
0. 2026-09-21 갱신 — 무엇이 좋아졌나
| 영역 | 전 | 후 |
|---|---|---|
| 조회 결과 | record가 지식 문서를 밀어냄 (gj 질의 4건 전부 회의 record) | 지식 문서 우선, record는 1칸 |
| 제외된 정본 | 조용히 빠짐 (gj 4건, lesson 포함) | 세션 시작에 [wiki 상태] 정본 N건 제외 표시, gj는 정비해 0건 |
| 조회 피드백 | 12건 중 8건 미마감 | 세션 시작에 [wiki 피드백 미마감 N건], 완료 보고 항목에 포함 |
| 후보 평가 | 보류 55건이 매 run 10칸을 독점, 미평가 후보 ~780건 대기 | 신규↔재시도·관찰↔기록물 각 절반 보장, 보류는 1→3→7→30일 backoff |
| 정책성 보류 | 매일 재평가 (Codex 비용) | 정책이 바뀔 때만 |
| 누적 | prune 없음 | 주간 아카이브 (완료 30일·정책 보류 90일), 관찰 페이지 90일 보존 |
| publisher 정지 | 보고서 journal이 걸리면 며칠 조용히 멈춤 (2회) | journal 자동 폐기·재생성, sync-commit 3회 연속 지연 시 경고 |
| registry | aidp 미분류 repo 3개 | 0개 |
실측: 새 코드 첫 2 run이 관찰 5 + 기록물 5로 채워졌고 전부 처음 평가되는 후보였다. 두 번째 run에서 record 3건이 바로 정본이 됐다.
1. Auto LLM wiki 구조 (raw → candidate → sys-wiki)
vault는 ~/oyunseong-wiki이고, Git이 정본입니다. Mac mini에서만 commit하며 MacBook은 Obsidian Sync로 받아봅니다.
| 층 | 위치 | 역할 | 누가 씀 |
|---|---|---|---|
| raw | vault 밖 spool ~/.local/state/oyunseong-wiki/spool + GCS | 수집 원본, 불변 | collector |
| candidate | 정제 queue와 후보 파일, 사람용은 candidate/index.md | raw에서 뽑은 관찰·기록물 후보, 미검증 | distill |
| sys-wiki | sys-wiki/<namespace>/<영역>/ | 검증 게이트를 통과한 정본 | auto-ingest, 에이전트 save |
| my-wiki | my-wiki/ | 직접 쓰시는 노트, LLM 대상 아님 | 사용자 |
정본이 되는 흐름은 다음 순서입니다.
- collector가 raw를 spool에 쌓고 GCS에 올립니다.
- distill이 하루 4회(00·06·12·18시 52분) 비밀값을 가리고 Codex로 관찰과 기록물 후보를 뽑습니다.
- auto-ingest가 10분마다 후보를 최대 10건씩 평가해, 게이트를 통과한 것만 sys-wiki에 씁니다.
- publisher가 commit·push합니다.
자동 기록은 publisher 전용 worktree에서만 일어나 primary 작업과 섞이지 않습니다. 에이전트가 작업 중 save로 직접 쓰는 길이 별도로 있습니다.
2. sys-wiki로 작업할 때
2-1. 새 프로젝트
- 세션 시작 hook이 registry를 확인해, 미등록이면
[wiki 미연결]한 줄만 알립니다. 자동 생성은 하지 않습니다. - 개인 repo는
connect_project_wiki.py --project <repo> --slug <slug> --personal을 dry-run으로 보여드리고, 승인 후 apply합니다. registry에 등록되고sys-wiki/<slug>/namespace와 index가 생깁니다. - 업무 repo는 registry에
common-only항목이 먼저 있어야 합니다. 그 항목 추가는 아직 수동입니다. - 새 프로젝트는 기본 영역 폴더 4개(overview, business, engineering, delivery)로 시작합니다. 영역은 1단계만 허용합니다.
- 연결 전까지는 repo만 보고 작업하며, 교훈은 그 repo의 HANDOFF
## Lessons에 남깁니다. - 작업 중 지식은 운영배포 후
knowns마감이나save명령으로 들어갑니다. raw에서 자동으로 들어오려면 정책에 그 프로젝트를 허용하는 규칙이 있어야 합니다.
2-2. 기존 프로젝트, 새 세션
- 현재 연결된 프로젝트는 5개입니다: cntvplus-erp, cntv-collector, cntv-oms-dashboard (모두
sys-wiki/aidp/cntv), gj-erp (aidp/gj), jy-tech (jyt). - 비단순 작업 전에
project-wiki-context의 route 명령이 Git remote로 프로젝트를 식별합니다. clone이나 worktree여도 같은 매핑입니다. - route는 질의에 맞는 정본 최대 4건만, 필요하면 해당 줄 범위만 돌려줍니다. 지식 문서(domain, runbook, lesson, decision 등)를 먼저 채우고 record는 1칸까지만 넣습니다. index는 길 안내용이라 주입하지 않습니다.
- 오래됐거나 상충하거나 형식이 깨진 문서는 거부하고, 거부가 있으면 세션 시작에
[wiki 상태] 정본 N건 제외한 줄로 알립니다. raw·candidate·관찰 이력은 읽지 않습니다. my-wiki는 명시적으로 연결한 문서만 읽기 전용입니다. - 해당 scope의
type: lesson을 먼저 확인합니다. “옵시디언 참조”라고 하시면 최근log.md10건과 최신 세션 메모도 함께 봅니다. - wiki와 코드가 다르면 현재 코드·migration·테스트가 우선합니다. 조회 trace는 작업이 끝날 때 실제로 썼는지 기록하며, 완료 보고의 “Wiki 조회” 항목과 세션 시작의
[wiki 피드백 미마감 N건]이 마감을 강제합니다.
3. 지금 상태로 얻는 것
- 세션 간 기억. 새 세션이 프로젝트 도메인 규칙, 결정, 교훈을 다시 묻지 않고 시작합니다.
- 자동으로 쌓이는 기록물. 회의·설계·리뷰·리서치 record 303건이 업무영역 폴더에 날짜별로 들어 있습니다. 같은 녹음은 종류별로 1건만 남습니다.
- 출처 추적. 모든 record가 raw-event id와 sha, 원문 인용을 갖습니다.
- 고객 경계. 모델은 정책이 허용한 프로젝트 집합 안에서만 고릅니다. AI 세션은 cwd, Notes는 폴더, 메일은 헤더로 결정적으로 분류하고, 음성·Slack은 고객 용어가 원문에 있어야 합니다.
- Obsidian 뷰. index의 Bases 표로 영역·종류·검토기한별로 봅니다. 관찰 페이지 5,837개는 vault 밖으로 빼서 목록이 깔끔합니다.
- 교훈 루프. 교정받은 규칙을
type: lesson으로 남깁니다. 현재 7건입니다. - 한계.
- status류 후보 280건은 정책상 record로 만들지 않습니다.
- 프로젝트가 모호한 46건은 보류 중입니다.
- AI 리뷰 세션이 많은 gj/delivery는 126건으로 비대합니다.
- Slack·Gmail은 8~9월 실데이터에서 record가 나오지 않았습니다(라우터는 준비돼 있어 회의·설계 내용이 오면 hourly 경로에서 record가 됩니다).
4. raw 수집·저장 대상
| 소스 | 대상 | 주기 | spool |
|---|---|---|---|
| AI 세션 | Claude Code·Codex 로컬 세션 | 6시간 | 6.2 GB |
| Slack | wishket aidp-* 10채널 (general·notice·goodstuff는 2026-09-18부터 중단) | 하루 4회, 주간 full | 25 GB (대부분 과거 3채널) |
| Gmail | 회사 메일 전체 | 하루 4회, 일 full | 234 MB |
| Notes | iCloud 메모 | 15분 | 11 MB |
| Voice | PLAUD 개인 노트, 팀 워크스페이스 export | 1시간, 5분 | 1.1 GB |
- 저장은 도메인별(work, personal, quarantine)로 나눕니다. 봉투(metadata)와 payload 한 쌍이고, 내용 해시를 검증합니다.
- quarantine은 local 전용이라 GCS에 올리지 않습니다. 분류가 안 된 PLAUD 녹음이 여기 있고 현재 11 GB입니다.
- 메일 라벨 변경 같은 개정은 새 봉투가 됩니다. 정제할 때 구 revision은 건너뜁니다.
5. candidate 대상과 정리 방법
- 대상은 두 종류입니다. 관찰(지식 후보: 규칙, 결정, 선호)과 material(기록물 후보: meeting, design, review, research, status)입니다.
- 정제 규칙. batch는 8건 또는 2만 자 단위입니다. 비밀값이 있으면 차단하고, 인용은 원문과 글자 그대로 일치해야 합니다. 같은 녹음의 전사와 요약은 한 batch로 묶습니다.
- 상태 관리. 후보마다 상태를 둡니다. 보류는 같은 사유가 반복되면 1 → 3 → 7 → 30일로 재시도 간격이 늘고, 정책이 원인인 보류(허용 안 된 종류, 출처 권한 미매핑)는 정책이 바뀔 때만 다시 봅니다. 오류는 30분 뒤 재시도합니다.
- 예산 분배. run당 10건을 배치 안에서는 신규↔재시도, run 안에서는 관찰↔기록물이 각각 절반씩 보장받습니다. 새 후보는 늦어도 다음 run에 평가됩니다.
- 누적 해소. 매주 일요일 prune이 완료 30일·정책 보류 90일 지난 후보 row를 아카이브(jsonl)로 옮기고, 관찰 페이지는 90일 지나면 지웁니다. 상태 파일은 남겨 같은 후보가 다시 나와도 완료로 판정됩니다. 정제 봉투(queue)는 정제 커버리지의 근거라 지우지 않습니다.
- 사람이 보는 곳.
candidate/index.md의 검토 현황 보고서 하나입니다. 개별 관찰 페이지는 vault 밖~/.local/share/oyunseong-wiki/candidate-pages에 있습니다. - 사람이 쓰는 곳.
candidate/sessions/<scope>/는 저장 필터를 통과하지 못한 작업의 인계 메모 자리입니다.
6. sys-wiki 대상과 정리 방법
- 구조. namespace는 aidp(공통, cntv 7개 영역, gj 3개 영역), jyt, victory, personal, reference입니다. 영역 폴더는 1단계만 허용하며 계약 파일
knowledge-contract.json이 목록을 고정합니다. - 문서 종류. 지식 문서는 domain, system, decision, runbook, lesson 등입니다. record는 파일명이
YYYY-MM-DD-<topic>.md이고record_kind와source_groups를 가집니다. - 들어오는 조건.
- 지식은 저장 필터 5개와 출처·발언자 권위·적용 범위·중복·충돌 검증을 통과해야 합니다. 사용자 발화만 근거로 씁니다.
- record는 허용된 종류이고, 프로젝트가 확정되고, 그 프로젝트의 영역이 선택되고, 인용이 검증돼야 합니다.
- index.
## 기록절에 제목 링크가 자동으로 붙고, Bases 블록이 영역·종류·검토기한 뷰를 만듭니다. - 점검.
kb_check.py가 frontmatter, id 중복, 링크, 검토기한을 검사합니다. 현재 0 errors입니다. “위키 점검”이라고 하시면 모순·고아 문서·중복·추측 표현까지 읽기 전용 보고서로 냅니다. - 수정 경로. 자동분은 publisher가, 에이전트는 branch에서 검증 후 main에 반영합니다. 매번
log.md에 한 줄을 남깁니다. sys-wiki는 MacBook에서 편집하지 않습니다.