30 Sanctum Knowledge Architecture 통합 지식 보고서

주제 통합 결론

Sanctum의 LLM 지식 아키텍처는 하나의 위키나 하나의 그래프로 해결할 문제가 아니다. 안전한 운영 모델은 canonical source, execution context, navigation/retrieval, enforcement의 네 계층을 분리해야 한다.

Canonical source 계층에서 contracts/는 서비스 간 계약의 SSOT이고, root/service AGENTS.md와 service llm-context/는 worker 실행 규칙과 운영 문맥의 SSOT다. Notion은 product, system, runbook을 위한 human-facing canonical portal로 유지한다.

Execution context 계층에서는 wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs 각각에 worker가 즉시 읽을 수 있는 context pack이 필요하다. 이 계층은 계약을 복제하지 않고, 어떤 canonical source를 읽고 어디까지 수정할 수 있으며 어떤 테스트와 handoff가 필요한지 알려준다.

Navigation/retrieval 계층에서 Graphify는 repo 구조와 서비스 관계를 찾는 context-router이고 RAG는 근거 후보를 찾는 retrieval cache다. 둘 다 생산성 도구지만 SSOT나 write authorization 근거가 아니다. Enforcement 계층은 sparse worktree, container/read-only mount, discord-codex-bot runtime write allowlist, diff guard, approval scope, root/e2e handoff로 구성한다.

확정 원칙

1. contracts/는 contract SSOT다.
2. contracts/는 worker 실행 문맥 저장소가 아니다.
3. service llm-context/contracts.md는 schema 복제본이 아니라 canonical contract path, 사용 코드 위치, worker permission, handoff owner, validation requirement를 담는 지도다.
4. Graphify는 navigation/context-router이며 write authorization이나 contracts/보다 높은 권위를 가져서는 안 된다.
5. RAG는 evidence retrieval cache이며 최종 판단은 canonical file direct read로 한다.
6. Derived Knowledge는 conclusion, reasoning, confidence, validation state, stale condition, source link를 포함해야 한다.
7. Codex App workspace separation은 risk reduction이지 hard write boundary가 아니다.

Sanctum 운영 모델의 의미

wallet-api worker는 wallet-facing request handler와 local tests를 다루되 kms-api, hd-manager, rust-mpc, contracts/ 변경은 기본 propose-only로 둔다. signing, wallet creation, recovery flow에 영향을 주면 root/e2e handoff가 필요하다.

kms-api worker는 key/signing/security boundary 때문에 가장 보수적으로 운영한다. secret, credential, private key는 문서화하지 않고 error semantics 또는 permission expectation 변경은 consumer impact와 migration 검토를 요구한다.

hd-manager worker는 derivation과 downstream MPC 연결을 다룬다. 내부 refactor는 service-local로 처리할 수 있지만 derivation semantics나 MPC operation contract 변경은 root/e2e 검증 대상이다. mpc-manager-rs와 party-node-rs의 manager-party boundary 변경은 contract proposal, paired handoff, root/e2e validation을 거친다.

의존성과 우선순위

• 10-context-management는 SSOT, Derived Knowledge, Graphify, RAG의 역할 분리를 뒷받침한다.
• 20-graphify-evaluation은 root graph로 시작하고 noisy할 때 service graph/merged graph로 확장하는 판단을 제공한다.
• 40-worker-agent-operations는 service-scoped worker, cwd boundary, handoff, root/e2e orchestrator 역할을 실제 작업 흐름으로 만든다.
• 50-codex-app-and-runtime-boundary는 workspace correction, sandbox, write allowlist, diff guard로 집행 계층을 만든다.
• 60-final-recommendations는 adoption roadmap, pilot checklist, risks and guardrails로 연결된다.

실행 로드맵

1단계: Authority matrix 고정

• contracts/, root/service AGENTS.md, service llm-context/의 권위를 선언한다.
• Graphify/RAG/Derived Knowledge가 SSOT가 아님을 문서 루트에 명시한다.

2단계: 서비스 context pack 작성

• 각 서비스에 AGENTS.md와 llm-context/ 최소 파일을 만든다.
• contracts.md는 canonical pointer와 usage map만 포함한다.
• test-scope.md는 local required와 e2e handoff trigger를 분리한다.

3단계: Contract change proposal 절차 도입

• service worker는 contracts/를 기본 read-only로 둔다.
• proposal에는 problem, proposed change, impacted services, required validation, migration/backward compatibility를 포함한다.

4단계: Runtime enforcement 연결

• runtime write allowlist, diff guard, approval scope 비교를 적용한다.
• 가능하면 sparse worktree, container, read-only mount를 service worker 실행에 적용한다.

5단계: Graphify/RAG/Derived Knowledge 운영화

• Graphify는 root graph pilot로 시작하고 필요 시 service graph/merged graph로 확장한다.
• RAG는 source disclosure와 freshness metadata를 제공한다.
• Derived Knowledge는 confidence, validation state, stale condition, source link를 강제한다.

검증 질문

• wallet-api worker가 kms-api contract mismatch를 발견했을 때 proposal/handoff로 전환하는가?
• kms-api 문서에 secret 값이나 private credential이 들어가지 않는가?
• hd-manager derivation semantics 변경이 e2e handoff trigger로 잡히는가?
• mpc-manager-rs와 party-node-rs protocol 변경이 paired validation 없이 단독 완료되지 않는가?
• Graphify/RAG 결과가 write authorization 또는 SSOT처럼 쓰이지 않는가?
• runtime write allowlist와 diff guard가 service worker 문서 경계와 일치하는가?

최종 요약

30번 Sanctum knowledge architecture 주제의 통합 결론은 문서 구조가 아니라 권위 구조다. 올바른 지식 아키텍처는 LLM이 더 많은 파일을 읽게 만드는 것이 아니라 어떤 원본을 믿고, 어떤 도구를 참고하며, 어디까지 수정하고, 언제 넘겨야 하는지를 반복 가능하게 만드는 운영 체계다.

보강 보고서