Graphify 파일럿 대상 비교 향상 보고서: zk-pol vs Sanctum

Sanctum LLM operations reports · Stage 2 topic HTML

보고서 목적

이 보고서는 Graphify 첫 파일럿 대상을 Sanctum으로 선택해야 하는 이유를 decision-oriented하게 정리한다. 목적은 Graphify의 효용뿐 아니라 SSOT 분리, worker boundary, runtime enforcement, drift 대응까지 함께 검증할 수 있는 pilot 환경을 고르는 것이다.

핵심 결론

Graphify 첫 파일럿은 Sanctum에서 진행해야 한다.

  • Sanctum은 wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs, contracts, root/e2e agent처럼 서비스와 역할 경계가 구체적이다.
  • 핵심 문제는 서비스 간 계약과 실행 흐름 추적이므로 Graphify의 context routing value를 직접 검증할 수 있다.
  • write/read/propose-only boundary, handoff, diff guard, root/e2e agent 조율을 실제로 검증할 수 있다.
  • graph drift, root graph vs cwd graph tradeoff, generated summary의 shadow SSOT 위험, Codex App workspace separation의 한계를 드러낸다.

zk-pol도 혜택을 받을 수 있지만 첫 파일럿으로는 Sanctum보다 우선순위가 낮다. Sanctum에서 운영 규칙을 먼저 검증한 뒤 적용하는 것이 안전하다.

파일럿 평가 기준

단순 코드 규모보다 서비스 경계, canonical contract와 구현의 연결, e2e 요청 흐름, 서비스별 agent/write boundary, graph drift의 운영 영향, SSOT와 Derived Knowledge 분리 필요성, 실패 시 영향 범위 통제 가능성이 중요하다. 이 기준에서 Sanctum은 더 적합하다.

Sanctum 적용 해석

Sanctum 파일럿은 Graphify 단독 평가가 아니라 전체 LLM 운영 architecture에서 Graphify의 위치를 검증하는 실험이다. 권장 계층은 SSOT, Derived Knowledge, Graphify, RAG, Worker context pack, Runtime guard로 나뉜다.

  • SSOT: contracts/, canonical docs, 검증된 runbook, 실제 코드와 테스트
  • Derived Knowledge: conclusion, reasoning, confidence, validation state, stale condition, source links를 가진 파생 결론
  • Graphify: repo 구조 지도와 context router
  • RAG: evidence retrieval과 source disclosure
  • Worker context pack: service AGENTS.md, llm-context/service.md, commands.md, test-scope.md, e2e-role.md, contracts.md, dependency-stubs/
  • Runtime guard: write allowlist, diff guard, handoff gate, approval metadata, sandbox enforcement

운영 판단

Stage 1은 root graph navigation pilot이다. Repo root 기준 graph를 만들고 wallet-api, kms-api, hd-manager, Rust MPC, contracts query scenario를 만든다. 결과는 read set 후보로만 사용한다. Stage 2는 worker context pack integration이다. Graphify는 누락 후보와 relation 후보를 제안하고 llm-context/contracts.md는 canonical content를 복제하지 않는다. Stage 3은 enforced worker runtime이다. Service worker는 자기 write allowlist 안에서만 수정하고 외부 변경은 propose-only 또는 handoff한다. Stage 4는 root graph가 noisy하거나 rebuild 비용이 커질 때 cwd-specific graph와 merge를 실험한다.

리스크와 가드레일

주요 리스크는 Graphify graph를 repo의 진실로 취급하는 것, 연결이 없다는 이유로 영향이 없다고 판단하는 것, generated summary를 검증 없이 canonical fact처럼 사용하는 것, root graph가 service worker context를 오염시키는 것, Graphify 관계 때문에 외부 파일을 수정하는 것, Codex App workspace separation을 hard boundary로 착각하는 것이다. 가드레일은 Graphify result를 navigation hint로 표시하고, 계약 사실을 contracts/로 역추적하며, Derived Knowledge에 confidence와 stale condition을 기록하고, runtime write allowlist와 diff guard를 독립적으로 적용하는 것이다.

실행 체크리스트

  • 첫 파일럿 repo를 Sanctum으로 확정한다.
  • zk-pol은 Sanctum 이후 2단계 적용 대상으로 둔다.
  • Root graph와 freshness metadata를 먼저 만든다.
  • wallet-apikms-api를 첫 worker pair로 검증한다.
  • contracts/ mapping을 포함한 llm-context/contracts.md 형식을 만든다.
  • HD manager와 Rust MPC 서비스로 확장한다.
  • Root/e2e agent가 cross-service flow와 handoff를 조율하게 한다.
  • Runtime write allowlist와 diff guard를 적용한다.
  • Graph noise, false positive, false negative, stale incident를 측정한다.
← 주제 인덱스로 돌아가기