00-index / reports / README

00-index README 향상 보고서

Sanctum LLM 운영 리포트 컬렉션의 인덱스 역할을 운영 의사결정 관점에서 재정리한 보고서입니다.

보고서 목적

이 보고서는 원본 md/00-index/README.md를 바탕으로 Sanctum LLM 운영 리포트 컬렉션의 인덱스 역할을 운영 의사결정 관점에서 재정리한다. 원본 README는 전체 컬렉션의 목적, 읽기 순서, 주제 간 관계, Sanctum 적용 방법을 안내하는 문서이며, 개별 주제 리포트의 본문을 대체하지 않는다.

  • 00-index가 전체 Sanctum LLM 운영 모델에서 어떤 판단 기준을 고정하는지 분명히 한다.
  • 이후 6개 주제 리포트를 읽고 실행 계획으로 전환할 때 필요한 우선순위를 제시한다.
  • Graphify, RAG, SSOT, service worker, Codex App, discord-codex-bot runtime의 역할이 섞이지 않도록 경계를 재확인한다.

핵심 결론

원본 README의 핵심 결론은 “Sanctum LLM 운영은 지식 계층과 실행 경계를 분리해야 한다”는 것이다.
  • SSOT는 사람이 검토 가능한 canonical 문서와 계약 파일에 둔다.
  • contracts/는 Sanctum의 계약 SSOT로 취급하되, 서비스 worker 실행 문맥 전체를 대체하지 않는다.
  • Graphify는 repo navigation과 context routing에 사용한다. SSOT, write authorization, approval model이 아니다.
  • RAG는 원문 근거 검색과 source disclosure에 사용한다. RAG DB와 embedding chunk는 canonical truth가 아니다.
  • Generated summary와 graph는 Derived Knowledge로 취급하고, confidence, validation state, stale condition, source link를 가져야 한다.
  • wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs는 서비스별 context pack과 write boundary 안에서 운영한다.
  • cross-service 변경, contract-impacting change, e2e 검증은 root/e2e agent가 조율한다.
  • Codex App workspace 분리는 위험을 줄이는 수단일 수 있지만, out-of-workspace edit이 가능하다면 hard write boundary가 아니다.
  • 강제 경계는 sparse worktree, container/read-only mount, 또는 discord-codex-bot runtime의 write allowlist와 diff guard로 구현해야 한다.

원본 문서의 주요 내용

컬렉션의 역할

원본 README는 Discord 스레드에서 논의된 Sanctum LLM 운영 모델을 주제별 독립 리포트로 정리하기 위한 인덱스다. 이전의 섹션 묶음형 작성이 아니라, 각 주제마다 별도 xhigh writer가 독립적으로 깊게 분석하는 구조를 전제로 한다.

  • 전체 리포트 세트의 목적을 설명한다.
  • 어떤 리포트를 먼저 읽어야 하는지 제시한다.
  • Graphify, SSOT, RAG, LLM wiki, service worker, runtime boundary 사이의 관계를 정리한다.
  • Sanctum 실제 서비스 예시를 기준으로 리포트 활용 방식을 안내한다.
  • Graphify graph, RAG DB, 자동 요약을 SSOT로 오해하지 않도록 한다.

근거와 한계

원본 README는 handoff에 포함된 Discord thread summary, repo inspection summary, Notion summary를 근거로 한다. 확인된 근거에는 Graphify 분석, zksanctum의 contracts/ 역할, root/service AGENTS.md, Sanctum 서비스 구성, Notion의 zkWallet - SSOT 요약이 포함된다.

동시에 private Notion 원문 재조회 없음, zksanctum 저장소 직접 수정 없음, Cloudflare 배포나 HTML 생성 없음, runtime sandbox 코드 구현 없음, Codex App 공식 UI 기능 추가 검증 없음이라는 한계를 명시한다. 이 한계는 제품 보증 문서가 아니라 확인된 대화 및 inspection 범위에서 작성된 운영 판단 인덱스라는 점을 분명히 한다.

권장 읽기 순서

  1. SSOT, Derived Knowledge, RAG, Graphify의 계층 구분.
  2. Sanctum 문서 구조와 service/flow dual view.
  3. Graphify의 context router 역할과 drift 위험.
  4. 서비스 worker context pack과 contracts/ 연결.
  5. Codex App workspace limit, runtime write allowlist, diff guard.
  6. 최종 운영 모델과 staged rollout.

이 순서는 단순 문서 탐색 순서가 아니라 의사결정 순서다. 먼저 “무엇이 사실인가”를 정하고, 그다음 “어떻게 찾을 것인가”, “누가 어디까지 수정할 것인가”, “어떻게 강제할 것인가”로 내려간다.

주제 맵

Knowledge Architecture는 SSOT와 derived layer를 구분한다. Graphify Operations는 repo graph를 context router로 쓴다. Service Worker Model은 서비스별 AGENTS.md와 llm-context 구조를 정의한다. Runtime Boundaries는 write allowlist, diff guard, filesystem isolation을 다룬다. Final Operating Model은 Codex App, discord-codex-bot runtime, root/e2e agent의 역할을 결합한다.

Sanctum 적용 해석

README는 운영 모델의 라우터다

00-index README는 개별 구현 지시서가 아니라, Sanctum LLM 운영 모델을 읽고 적용하기 위한 라우터다. Graphify가 코드 탐색의 context router라면, 이 README는 보고서 컬렉션의 decision router다.

운영 리드는 이 문서를 통해 wallet-api worker를 만들기 전에 무엇을 정해야 하는지, contracts/를 SSOT로 둘 때 service context pack이 무엇을 복제하지 말아야 하는지, Graphify root graph pilot 전에 어떤 drift 조건을 문서화해야 하는지, Codex App과 runtime enforcement를 왜 분리해야 하는지 판단할 수 있어야 한다.

서비스 예시별 적용

wallet-api는 사용자 요청과 wallet-facing orchestration의 진입점이므로 kms-api, hd-manager, contracts/와의 연결을 자주 읽어야 한다. Graphify는 이 연결을 찾는 데 도움을 줄 수 있지만 sibling service를 직접 수정해도 된다는 뜻은 아니다.

kms-api는 key management 책임을 가진다. hd-manager는 HD derivation 관련 로직을 다룬다. rust-mpc/mpc-manager-rs와 party-node-rs는 MPC orchestration과 party-node protocol-facing 책임을 나눠 가진다. 경계가 흐려지면 단일 worker가 protocol semantics를 과도하게 변경할 수 있으므로 propose-only/handoff 규칙이 필요하다.

contracts/는 계약 사실의 중심이다. 다만 서비스별 worker가 실행할 때 필요한 명령, 테스트 범위, dependency stub, e2e role까지 제공하지는 않으므로 service-local AGENTS.md와 llm-context/가 별도로 필요하다. root/e2e agent는 여러 서비스 변경을 통합하고 contract-impacting change를 검토한다.

운영 판단

1. README의 첫 번째 결정은 SSOT 우선순위다

운영 도입의 첫 단계는 도구 선택이 아니라 사실의 기준을 정하는 것이다. contracts/와 canonical docs가 우선이고, Graphify/RAG/generated summary는 그 위에 놓인 탐색 및 파생 계층이다.

  • contracts/ 변경은 일반 서비스 worker의 자동 수정 범위에서 분리한다.
  • service llm-context/contracts.md는 계약 내용을 복제하지 않고 canonical contract mapping을 둔다.
  • Derived Knowledge에는 stale condition을 넣어 contract 변경 시 재검증되게 한다.

2. Graphify는 탐색 비용 절감 도구다

Graphify는 반복적인 raw file reading을 줄이고, 어떤 파일을 읽을지 좁히는 데 적합하다. 초기 pilot은 root graph로 시작하고, root graph가 noisy할 때 service graph와 merged graph를 추가한다. graph query 결과는 읽기 후보이지 승인 근거가 아니다.

3. Runtime enforcement 없이는 service worker 모델이 완성되지 않는다

문서와 Graphify만으로는 쓰기 경계를 강제할 수 없다. wallet-api worker가 kms-api나 contracts/를 수정하지 못하게 하려면 실제 diff를 검사해야 한다.

  • worker별 write allowlist를 둔다.
  • sibling service는 read/propose-only로 둔다.
  • allowlist 밖 diff는 차단하거나 root/e2e handoff로 전환한다.
  • Codex App workspace separation은 hard boundary가 아니라 risk-reduction measure로만 표현한다.

리스크와 가드레일

인덱스 문서를 실행 정책으로 오해

README는 전체 방향을 설명하지만 직접 enforcement를 수행하지 않는다. README의 원칙을 AGENTS.md, runtime policy, diff guard로 내려야 하며, 각 worker handoff에는 구조화된 allowed paths, propose-only paths, test scope를 포함해야 한다.

Graphify 권한 오해

Graphify가 어떤 파일을 연결한다고 해서 그 파일을 수정해도 된다는 뜻은 아니다. Graphify 결과는 read candidate로만 표시하고, write authorization은 server-side metadata와 runtime allowlist가 결정해야 한다.

SSOT inversion

RAG DB, graph, generated summary가 편하다는 이유로 canonical docs보다 우선될 수 있다. derived artifact에는 source link, confidence, validation state, stale condition을 필수로 두고, 충돌 시 contracts/, canonical docs, 실제 코드, 테스트 결과를 우선한다.

Codex App boundary 과신

Codex App workspace를 분리하면 안전하다고 오해할 수 있다. Codex App은 개인 탐색과 리뷰에 두고, enforced service worker 실행은 discord-codex-bot runtime에서 수행해야 한다.

실행 체크리스트

  • contracts/의 contract SSOT 범위를 명시한다.
  • Notion SSOT와 repo-local LLM context pack의 역할 차이를 문서화한다.
  • wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs별 AGENTS.md와 llm-context/ 구조를 만든다.
  • 각 service context pack에 service.md, commands.md, test-scope.md, e2e-role.md, contracts.md, dependency-stubs.md를 포함한다.
  • Graphify root graph pilot의 목적을 context routing으로 제한한다.
  • graph drift 조건과 rebuild trigger를 정의한다.
  • RAG는 evidence retrieval과 source disclosure에만 사용한다.
  • service worker별 write allowlist와 propose-only boundary를 정의한다.
  • final diff guard가 allowlist 밖 변경을 차단하도록 한다.
  • root/e2e agent의 cross-service change, contract migration, e2e verification 책임을 정의한다.

최종 판단

00-index README는 Sanctum LLM 운영 컬렉션의 목차가 아니라 운영 판단의 기준선이다. 이 문서를 기준으로 후속 주제는 “지식은 어디에 둘 것인가”, “탐색은 무엇으로 할 것인가”, “worker는 어디까지 수정할 것인가”, “그 경계는 무엇으로 강제할 것인가”를 분리해 답해야 한다.

Sanctum은 Graphify와 RAG를 SSOT가 아닌 파생 탐색 계층으로 사용하고, contracts/와 canonical docs를 사실의 기준으로 유지하며, service-local context pack과 discord-codex-bot runtime의 write allowlist/diff guard로 실제 worker 경계를 강제해야 한다.
Stage 2 topic report HTML conversion. Source: md/topic-reports/00-index/README.md.