00-index / reports / executive-summary

00-index Executive Summary 향상 보고서

Sanctum LLM 운영 모델의 핵심 의사결정을 실행 가능한 운영 판단으로 변환한 보고서입니다.

보고서 목적

이 보고서는 원본 md/00-index/executive-summary.md를 바탕으로 Sanctum LLM 운영 모델의 핵심 의사결정을 강화한 파일 수준 보고서다. 원본 executive summary는 Graphify, RAG, LLM wiki/SSOT, Sanctum 서비스 문서 구조, worker context pack, Codex App 한계, discord-codex-bot runtime 기반 강제 경계를 한 번에 파악하기 위한 요약 문서다.

이 향상 보고서는 원본의 결론을 실행 가능한 운영 판단으로 변환한다. 독자는 Sanctum의 LLM worker 운영과 지식 아키텍처를 설계하는 엔지니어링 리드로 가정한다.

핵심 결론

Sanctum의 LLM 운영 모델은 사람이 검증하는 SSOT, Derived Knowledge, Graphify context router, RAG evidence retrieval, 서비스별 worker context pack, runtime write boundary를 분리해야 한다.
  • Graphify graph, RAG DB, 자동 생성 요약은 유용하지만 SSOT가 아니다.
  • SSOT는 사람이 읽고 리뷰할 수 있는 canonical 문서와 계약 파일이어야 한다.
  • contracts/는 contract-level truth의 중심이지만 서비스 worker 실행 컨텍스트 전체는 아니다.
  • worker가 실제로 수정할 수 있는 범위는 Graphify 결과나 Codex App workspace 표시가 아니라 runtime write allowlist, diff guard, sparse worktree/container 같은 강제 장치가 결정한다.
  • Codex App은 개인 탐색과 리뷰 보조 도구로 두고, enforced service worker 실행은 discord-codex-bot runtime이 관리하는 구조가 적합하다.
  • root/e2e agent는 cross-service flow, contract-impacting change, 통합 테스트, handoff 조율을 담당한다.

원본 문서의 주요 내용

확인된 사실

  • Graphify는 repo memory index 또는 context router로 분석되었다.
  • Graphify는 graph.json 기반 질의를 통해 반복적인 raw file reading을 줄인다.
  • Graphify에 대한 개발자 반응은 긍정적이지만, 초기 단계 운영 리스크가 있다.
  • graph drift 원인은 rename/delete/move, branch switch, merge/rebase, ignore 변경, shared file, semantic extraction failure다.
  • Sanctum은 zk-pol보다 Graphify 첫 pilot 대상으로 적합하다고 판단되었다.
  • LLM wiki, Graphify, RAG는 서로 다른 계층이다.
  • SSOT는 human-readable canonical documents에 있어야 한다.
  • RAG와 Graphify는 derived index/cache다.
  • Derived Knowledge는 conclusion, reasoning, confidence, validation state, stale condition, source link를 기록해야 한다.
  • Sanctum LLM docs는 service-oriented structure와 flow-oriented structure를 모두 필요로 한다.
  • contracts/는 계약 SSOT로 유용하지만 service worker 실행 전체 문맥은 아니다.
  • 각 서비스에는 AGENTS.md와 llm-context/가 필요하다.
  • Graphify는 context pack 생성/갱신을 도울 수 있지만 AGENTS.md, contracts, handoff rules, write boundaries를 대체하지 않는다.
  • 초기 pilot은 root Graphify graph가 적합하다.
  • scope invasion의 주된 원인은 Graphify가 아니라 repo-wide write access다.
  • Codex App workspace separation은 out-of-workspace edit이 가능하다면 hard write boundary가 아니다.
  • hard enforcement에는 sparse worktree, container/read-only mount, 또는 runtime write allowlist와 diff guard가 필요하다.

네 가지 설계 판단

첫째, Graphify는 source of truth가 아니라 navigation layer다. wallet-api에서 시작한 요청이 kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs, contracts/와 어떻게 연결되는지 찾는 데 가치가 있다. 그러나 graph 자체가 오래되거나 잘못 추출될 수 있으므로 승인이나 계약 사실의 기준으로 쓰면 안 된다.

둘째, contracts/는 계약 SSOT로 존중하되 worker 실행 컨텍스트와 분리한다. 서비스별 llm-context/contracts.md는 계약 내용을 베껴 쓰는 문서가 아니라 어떤 canonical contract를 읽어야 하는지 연결하는 map이어야 한다.

셋째, Sanctum 문서 체계는 service view와 flow view를 모두 가져야 한다. 서비스별 문서만 있으면 e2e 흐름을 놓치고, flow 문서만 있으면 worker 수정 범위와 테스트 범위가 흐려진다.

넷째, write boundary는 문서나 graph가 아니라 runtime에서 강제해야 한다. 서비스 worker가 wallet-api만 수정해야 한다면 runtime이 실제 diff에서 wallet-api/** 외 변경을 차단해야 한다.

Sanctum 적용 해석: 계층형 운영 모델

원본 executive summary는 Sanctum 운영 모델을 여섯 계층으로 분리한다. 이 계층 분리는 tool 선택보다 중요하다. 운영 실패는 보통 도구 부족이 아니라 역할 혼동에서 발생한다.

  1. SSOT layer: canonical docs, contracts/, root/service AGENTS.md, human-facing Notion SSOT, flow docs.
  2. Derived Knowledge layer: LLM이나 도구가 만든 결론, 요약, 연결 설명, 위험 분석.
  3. Graphify layer: context router와 repo navigation.
  4. RAG layer: evidence retrieval과 source disclosure.
  5. LLM wiki layer: 사람이 읽고 LLM도 재사용할 수 있는 verified knowledge.
  6. Runtime enforcement layer: write allowlist, read boundary, propose-only boundary, diff guard, sparse worktree/container.

Graphify를 SSOT로 쓰거나, Codex App workspace가 분리되어 있다고 hard boundary로 믿거나, RAG chunk를 최신 계약 사실로 쓰면 위험이 커진다.

서비스 worker context pack 적용

각 서비스 worker는 독립 실행 가능한 context pack을 가져야 한다. 권장 구조는 <service>/AGENTS.md, llm-context/service.md, commands.md, test-scope.md, e2e-role.md, contracts.md, dependency-stubs.md이다. 이 구조는 generic README가 아니라 operational contract다.

  • wallet-api worker는 wallet-facing request handling과 orchestration을 다룬다. kms-api, hd-manager, contracts/ 영향은 read/propose-only 또는 handoff 대상이다.
  • kms-api worker는 key management 책임을 다룬다. wallet request와 MPC signing flow에 영향을 주면 root/e2e agent로 handoff한다.
  • hd-manager worker는 HD derivation 책임을 다룬다. contract field나 wallet lifecycle 변경이 있으면 contracts/와 wallet-api worker context를 확인한다.
  • rust-mpc/mpc-manager-rs worker는 MPC orchestration과 manager logic을 다룬다. party protocol 변경은 party-node-rs 또는 root/e2e agent와 분리한다.
  • rust-mpc/party-node-rs worker는 party node 실행과 protocol participation을 다룬다. cross-party behavior나 e2e signing semantics는 root/e2e 검증 대상으로 넘긴다.
  • root/e2e agent는 여러 서비스와 contracts/를 함께 변경하거나 전체 flow를 검증하는 작업을 담당한다.

운영 판단

1. SSOT layer를 먼저 확정한다

Sanctum 운영 모델의 첫 결정은 어떤 도구를 쓸지가 아니라 어떤 문서가 canonical truth인지를 정하는 것이다.

  • contracts/를 contract SSOT로 명시한다.
  • root AGENTS.md는 repo 전체 경계와 cross-service 규칙을 둔다.
  • service AGENTS.md는 서비스별 작업 규칙, 허용 변경 범위, handoff rule을 둔다.
  • human-facing Notion SSOT는 제품/운영 지식의 사람이 읽는 기준으로 유지한다.
  • flow docs는 wallet 생성, key management, HD derivation, MPC signing 같은 cross-service request path를 설명한다.

2. Derived Knowledge는 신뢰 메타데이터를 가져야 한다

Derived Knowledge는 유용하지만 canonical fact가 아니다. 예를 들어 “kms-api가 특정 contract field를 소비한다”는 요약은 판단 자료일 뿐이며, 최종 사실은 contracts/와 구현 코드에서 확인해야 한다.

  • 모든 generated summary에는 conclusion, reasoning, confidence, validation state, stale condition, source links를 포함한다.
  • stale condition에는 contract 변경, service boundary 변경, flow 변경, major refactor, graph rebuild 실패를 포함한다.
  • 검증되지 않은 derived knowledge는 worker 실행의 직접 근거로 쓰지 않는다.

3. Graphify는 root graph pilot으로 시작한다

초기 pilot으로 root graph를 권장한다. 이유는 freshness 규칙과 agent 운영 규칙이 단순하기 때문이다. root graph는 service/flow 탐색과 context pack 갱신 후보 탐색에 사용하고, root graph가 noisy해지면 service graph와 merged graph를 추가한다.

4. Runtime enforcement가 service worker 모델의 핵심이다

문서가 아무리 정확해도 worker가 repo-wide write access를 가지면 scope invasion이 발생할 수 있다. Graphify가 원인이 아니라 write access 모델이 원인이다.

  • service worker별 write allowlist를 둔다.
  • 읽기는 dependency와 canonical docs까지 허용하되, 읽기 권한이 쓰기 권한을 의미하지 않게 한다.
  • sibling service와 shared contract는 propose-only 또는 handoff path로 둔다.
  • final diff guard가 allowlist 밖 변경을 차단한다.
  • 필요 시 sparse worktree, container, read-only mount를 적용한다.

리스크와 가드레일

Graphify drift

rename/delete/move, branch switch, merge/rebase, ignore rule 변경, shared file 변경, semantic extraction 실패로 graph가 stale해질 수 있다. graph freshness metadata, rebuild trigger, merged graph regeneration 규칙을 두고 중요한 작업에서는 graph 결과를 canonical files와 focused search로 검증한다.

SSOT inversion

Graphify graph나 RAG DB가 편하다는 이유로 canonical contract와 사람이 검토한 문서보다 우선될 수 있다. contracts/와 canonical docs를 우선하고, RAG/Graphify/generated summary는 source link와 confidence를 가진 derived layer로 둔다.

Scope invasion

wallet-api 작업 중 kms-api나 contracts/를 수정하는 식의 경계 침범이 발생할 수 있다. runtime write allowlist와 diff guard로 실제 변경 파일을 검사하고, cross-service semantics는 root/e2e agent가 통합한다.

Context pack staleness

llm-context/가 실제 코드와 contract 변경을 따라가지 못하면 worker가 오래된 명령, 테스트, dependency map을 사용할 수 있다. context pack에 stale condition을 넣고 contract 변경 또는 service boundary 변경 시 관련 pack 갱신 workflow를 둔다.

Codex App hard boundary 오해

workspace separation을 hard write boundary로 오해할 수 있다. Codex App은 exploration/review 용도로 제한하고, service worker safety는 runtime allowlist와 diff guard에서 확보한다.

실행 체크리스트

  • contracts/의 contract SSOT 역할을 명시한다.
  • root/service AGENTS.md의 책임을 구분한다.
  • wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs별 context pack을 만든다.
  • 각 context pack에 commands, test scope, e2e role, contract mapping, dependency stubs를 포함한다.
  • llm-context/contracts.md는 canonical contracts/를 참조하고 계약 사실을 복제하지 않는다.
  • Graphify root graph pilot을 context routing 목적으로만 도입한다.
  • graph freshness와 rebuild trigger를 문서화한다.
  • RAG는 evidence retrieval과 source disclosure에 사용한다.
  • Derived Knowledge schema에 confidence, validation state, stale condition, source link를 포함한다.
  • Codex App은 personal exploration/review 용도로 둔다.
  • discord-codex-bot runtime에 write allowlist와 diff guard를 둔다.
  • allowlist 밖 변경은 자동 차단하거나 root/e2e handoff로 전환한다.
  • root/e2e agent가 cross-service flow와 integration test 책임을 맡는다.

최종 판단

원본 executive summary는 Sanctum LLM 운영이 단일 도구 도입 문제가 아니라 계층과 경계의 문제임을 확정한다. Graphify는 길을 찾게 하고, RAG는 근거를 찾게 하며, LLM wiki와 contracts/는 사람이 검증하는 지식 기준을 제공한다. 하지만 실제 서비스 worker의 안전성은 context pack과 runtime enforcement가 함께 있을 때만 확보된다.

Sanctum은 Graphify/RAG를 SSOT가 아닌 파생 탐색 계층으로 사용하고, contracts/와 canonical docs를 SSOT로 유지하며, 서비스별 context pack과 discord-codex-bot runtime의 write allowlist/diff guard를 통해 wallet-api, kms-api, hd-manager, rust-mpc worker와 root/e2e agent를 분리 운영해야 한다.
Stage 2 topic report HTML conversion. Source: md/topic-reports/00-index/executive-summary.md.