Stage 2ReportRoadmap

Sanctum 도입 로드맵 강화 보고서

보고서 목적

이 보고서는 Sanctum에 LLM 운영 모델을 도입할 때 문서, 탐색 도구, 실행 경계, handoff 체계를 어떤 순서로 세워야 하는지 명확히 하는 실행 의사결정용 보고서다. 근거는 원본 Markdown과 제공된 대화 맥락이며, 실제 zksanctum 저장소 최신 상태를 새로 검증한 보고서는 아니다.

핵심 결론

Sanctum 도입 순서는 문서화 -> context routing -> runtime enforcement -> optional graph refinement가 되어야 한다. Graphify나 RAG를 먼저 붙이면 탐색은 빨라지지만, SSOT와 write boundary가 불명확한 상태에서는 잘못된 근거를 빠르게 실행할 위험이 커진다.

Lane	주 역할	운영 판단
Codex App	개인 탐색, 리뷰, 설계 비교, 초안 작성	workspace 분리는 위험 감소 수단이지만 hard write boundary가 아니다.
discord-codex-bot runtime	service-scoped worker 실행, 승인 기반 변경, artifact 관리	write allowlist, diff guard, server-side approval scope로 강제 경계를 만든다.
root/e2e agent	cross-service flow 검증, contract impact 판단, handoff 조정	repo-wide read는 가능하되 service-local 구현 변경은 원칙적으로 해당 worker에게 넘긴다.

원본 문서의 주요 내용

원본 로드맵은 6단계를 제시한다. Phase 0은 canonical 문서, contracts/, Derived Knowledge의 역할 정리다. Phase 1은 wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs의 service context pack 작성이다. Phase 2는 root Graphify graph pilot이다. Phase 3은 RAG를 evidence retrieval로 연결하고 검증된 결론을 Derived Knowledge로 저장하는 단계다. Phase 4는 discord-codex-bot runtime의 write allowlist, propose-only boundary, diff guard, approval record, handoff rule 강제다. Phase 5는 root graph가 noisy해진 뒤에만 cwd/service graph와 merged graph를 추가하는 단계다.

핵심은 contracts/와 service context pack의 역할 차이다. contracts/는 계약 사실의 canonical owner가 될 수 있지만 worker 실행에 필요한 명령, 테스트 범위, dependency stub, handoff 기준까지 제공하지는 않는다.

Sanctum 적용 해석

Sanctum의 첫 적용 지점은 wallet-api 중심 flow다. wallet-api는 사용자 요청의 시작점이며 kms-api, hd-manager, contracts/, 장기적으로 rust-mpc/mpc-manager-rs와 rust-mpc/party-node-rs까지 이어지는 dependency를 드러내기 쉽다.

대상	로드맵상 역할	첫 조치
`wallet-api`	첫 worker pilot 대상	context pack, KMS/HD dependency stub, contract mapping
`kms-api`	보안 민감 dependency 및 다음 확장 후보	key lifecycle, auth boundary, caller contract mapping
`hd-manager`	derivation flow와 wallet/KMS 연결점	derivation responsibility, dependency failure mode
`rust-mpc/mpc-manager-rs`	MPC orchestration worker 후보	party coordination, protocol impact handoff rule
`rust-mpc/party-node-rs`	MPC participant worker 후보	manager interface, protocol-level change 기준
`contracts/`	engineering contract SSOT	contract owner, change approval, service mapping
root/e2e agent	integration lane	wallet -> KMS -> HD -> MPC flow 검증과 handoff 조정

llm-context/contracts.md는 contract schema나 field truth를 복제하지 않고 canonical contracts/ path, producer/consumer 관계, 테스트 범위, handoff owner만 매핑해야 한다.

운영 판단

Phase 0과 Phase 1은 즉시 시작해도 된다. Graphify root graph pilot은 context pack 초안이 생긴 뒤 시작하는 것이 좋다. RAG는 SSOT가 아니라 source-backed retrieval로만 운영한다. runtime enforcement 전에는 service worker에게 application code 변경을 맡기지 않는다. Codex App은 탐색과 리뷰에 유용하지만 out-of-workspace edit 가능성이 있으면 service isolation을 보장하지 않는다. service graph는 root graph의 query noise와 rebuild cost 문제가 실제로 확인된 뒤 검토한다.

리스크와 가드레일

리스크	영향	가드레일
Graphify를 SSOT처럼 사용	stale edge나 삭제된 파일을 근거로 작업	graph metadata, stale condition, direct source read 필수
RAG 결과를 decision으로 승격	오래된 문서가 canonical fact처럼 사용	source link와 validation state 요구
contract fact 중복	`contracts/`와 service context 간 drift	service context는 mapping만 유지
scope invasion	worker가 다른 서비스나 shared contract 수정	runtime write allowlist, propose-only boundary, diff guard
Codex App boundary 과신	workspace 밖 수정 누락	Codex App은 personal lane, enforced worker는 runtime lane
root/e2e agent 비대화	root agent가 모든 구현을 직접 처리	integration, review, handoff coordination 중심

실행 체크리스트

root LLM operating principle을 작성한다.
contracts/를 canonical contract SSOT로 명시한다.
Derived Knowledge schema를 확정한다.
service context pack template을 만든다.
wallet-api와 kms-api context pack을 우선 작성한다.
hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs context pack을 순차 작성한다.
root/e2e agent 역할을 문서화한다.
root Graphify graph와 freshness metadata를 준비한다.
RAG source registry를 canonical/derived group으로 분리한다.
worker별 write allowlist, read boundary, propose-only path를 runtime metadata로 정의한다.
diff guard가 allowlist 밖 변경을 실패 처리하는지 검증한다.