Sanctum LLM 운영 리포트 / topics / 00-index

00-index 통합 지식 보고서

컬렉션 전체의 판단 기준을 고정하는 control plane 역할의 주제 페이지입니다.

주제 통합 결론

00-index의 두 원본 문서인 README.md와 executive-summary.md는 Sanctum LLM 운영 리포트 컬렉션의 단순 목차가 아니다. 두 문서는 전체 운영 모델의 판단 기준을 고정하는 control plane 역할을 한다.

핵심 결론: Sanctum LLM 운영은 무엇이 사실인가, 무엇이 파생 지식인가, 무엇이 탐색 도구인가, 누가 어디까지 수정할 수 있는가, 그 경계를 무엇으로 강제할 것인가를 분리해야 한다.

이 분리가 없으면 Graphify, RAG, LLM wiki, Codex App, service worker, runtime sandbox가 서로의 역할을 침범한다.

최상위 운영 모델

  • SSOT: 사람이 검토 가능한 canonical docs와 contracts/.
  • Derived Knowledge: generated summary, 연결 분석, 운영 판단, 위험 분석.
  • Graphify: repo memory index와 context router.
  • RAG: evidence retrieval과 source disclosure.
  • LLM wiki/context pack: worker가 실행에 필요한 검증된 문맥.
  • Service worker: 서비스별 read/write/propose-only 경계 안에서 작업하는 실행 단위.
  • Runtime enforcement: write allowlist, diff guard, sparse worktree/container/read-only mount.
  • Root/e2e agent: cross-service change, contract-impacting change, e2e 검증, handoff 조율.

Graphify와 RAG는 강력한 보조 계층이지만 최종 사실과 쓰기 권한의 기준이 아니다. Codex App workspace separation도 위험을 줄일 수는 있으나, out-of-workspace edit이 가능하다면 hard write boundary가 아니다.

이 주제의 HTML 보고서

README 향상 보고서컬렉션 인덱스의 운영 의사결정 역할과 적용 순서 Executive Summary 향상 보고서핵심 의사결정, 계층형 운영 모델, runtime boundary

이 주제에서 확정된 원칙

1. SSOT는 사람이 검토 가능한 곳에 둔다

SSOT는 Graphify graph나 RAG DB가 아니라 human-readable canonical 문서와 계약 파일이어야 한다. Sanctum에서는 contracts/가 contract-level truth의 중심이다. Notion의 사람용 SSOT는 제품 구성, 시스템 컴포넌트, 주요 요청 흐름, 배포 단위, 운영/runbook 성격의 지식 기준으로 유용하다.

  • contracts/를 계약 SSOT로 명시한다.
  • service context pack은 contract fact를 복제하지 않고 canonical contract를 가리킨다.
  • 충돌 시 Graphify/RAG/generated summary보다 canonical docs, 실제 코드, 테스트 결과를 우선한다.

2. Derived Knowledge는 낮은 신뢰 계층으로 관리한다

Generated summary, LLM 분석, graph 기반 연결 설명은 유용하지만 파생물이다. 파생 지식은 반드시 검증 상태를 드러내야 한다.

  • Derived Knowledge에는 conclusion, reasoning, confidence, validation state, stale condition, source link를 포함한다.
  • stale condition에는 contract 변경, service boundary 변경, flow 변경, branch 전환, graph rebuild 실패를 포함한다.
  • 검증되지 않은 파생 지식은 worker의 직접 수정 근거로 쓰지 않는다.

3. Graphify는 navigation/context-router다

Graphify는 graph.json 기반으로 repo 구조와 서비스 연결을 탐색하고 반복적인 raw file reading을 줄이는 도구다. Sanctum에서는 wallet-api 요청이 kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs, contracts/와 어떻게 연결되는지 찾는 데 가치가 있다.

  • Graphify query 결과는 읽기 후보 목록이다.
  • Graphify는 source of truth가 아니다.
  • Graphify는 write authorization이나 approval model이 아니다.
  • graph에 없는 파일은 영향이 없다고 단정하지 않는다.
  • root graph pilot으로 시작하고, noisy해지면 service graph와 merged graph를 추가한다.

4. RAG는 evidence retrieval이다

RAG는 원문 근거를 찾고 source disclosure를 제공하는 계층이다. RAG DB와 embedding chunk는 검색 캐시이지 canonical source가 아니다.

  • RAG는 관련 contract, docs, code snippets, 과거 결정을 찾는 데 사용한다.
  • RAG 답변에는 source disclosure가 있어야 한다.
  • 오래된 chunk를 최신 사실처럼 사용하지 않는다.
  • RAG 검색 결과만으로 write scope를 결정하지 않는다.

5. 서비스별 context pack은 worker의 operational contract다

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

  • AGENTS.md는 해당 서비스의 작업 규칙과 boundary를 둔다.
  • service.md는 책임, entrypoint, owned/non-owned module을 설명한다.
  • commands.md는 build/test/lint/local run 명령을 둔다.
  • test-scope.md는 worker가 직접 실행할 테스트와 root/e2e agent로 넘길 테스트를 구분한다.
  • contracts.md는 canonical contracts/ mapping을 제공하고 contract fact를 복제하지 않는다.

6. Write boundary는 runtime에서 강제한다

문서와 graph는 boundary를 설명할 수 있지만 강제하지 못한다. 서비스 worker가 실제로 어떤 파일을 수정했는지는 final diff로 확인해야 한다.

  • worker별 write allowlist를 둔다.
  • 읽기 권한과 쓰기 권한을 분리한다.
  • sibling service와 shared contract는 propose-only 또는 handoff 대상으로 둔다.
  • final diff가 allowlist 밖 파일을 포함하면 차단한다.
  • 필요 시 sparse worktree, container, read-only mount로 파일 시스템 수준 격리를 추가한다.

7. Codex App은 hard boundary가 아니다

Codex App workspace separation은 개인 탐색과 리뷰에서 위험을 줄일 수 있다. 그러나 out-of-workspace edit이 가능하다면 hard write boundary로 간주할 수 없다.

  • Codex App은 personal exploration/review에 사용한다.
  • enforced service worker 실행은 discord-codex-bot runtime에서 수행한다.
  • hard enforcement는 runtime allowlist, diff guard, filesystem sandbox가 맡는다.

Sanctum 운영 모델에 주는 의미

wallet-api

wallet-api는 wallet-facing request handling과 orchestration의 진입점이다. 이 worker는 wallet API 내부 구현과 해당 서비스 테스트를 주로 다루며 kms-api, hd-manager, contracts/를 읽을 수 있어야 한다. sibling service 내부 변경은 직접 수정하지 않고 propose-only 또는 handoff로 처리해야 한다.

kms-api

kms-api는 key management API 책임을 가진다. wallet request와 MPC signing flow에 영향을 줄 수 있으므로 contract와 e2e flow 연결이 중요하다. contract-impacting change는 contracts/와 root/e2e agent 검토가 필요하다.

hd-manager

hd-manager는 HD key derivation 관련 책임을 가진다. 계약 필드와 wallet lifecycle 변경에 민감하므로 canonical contracts/ mapping을 읽어야 하고, cross-service semantics 변경은 root/e2e agent가 통합 검증을 맡아야 한다.

rust-mpc/mpc-manager-rs와 party-node-rs

mpc-manager-rs는 MPC orchestration과 manager logic을 담당한다. party-node-rs는 party node 실행과 protocol participation을 담당한다. party node protocol-facing 변경, wallet API surface, shared contract, cross-party behavior 변경은 propose-only 또는 root/e2e handoff 대상이다.

contracts/와 Root/e2e agent

contracts/는 계약 SSOT다. contract 사실은 여기에서 확인하고, service llm-context/contracts.md는 canonical contract mapping과 서비스별 적용 해석을 둔다. Root/e2e agent는 cross-service 변경, e2e 테스트, contract migration, service worker handoff 통합을 담당한다.

다른 주제와 연결되는 의존성

10-context-management

00-index는 SSOT, Derived Knowledge, RAG, Graphify의 계층 분리를 확정한다. 10-context-management는 Derived Knowledge schema, stale condition, validation state, LLM wiki와 RAG index의 관계를 세부 정책으로 확장해야 한다.

20-graphify-evaluation

00-index는 Graphify를 context router로 고정한다. 20-graphify-evaluation은 root graph pilot의 성공 기준, graph drift 이벤트, root graph가 noisy해지는 기준과 service graph 전환 조건을 검증해야 한다.

30-sanctum-knowledge-architecture

00-index는 contracts/와 service context pack의 역할을 분리한다. 30-sanctum-knowledge-architecture는 service-local AGENTS.md, llm-context/contracts.md, service-oriented docs와 flow-oriented docs의 유지 구조를 정의해야 한다.

Stage 2 topic HTML conversion. Source: md/topic-knowledge/00-index-integrated-knowledge.md.