보고서 목적
이 보고서는 Graphify에 대한 강한 개발자 관심을 Sanctum 운영 의사결정으로 번역한다. 목적은 hype와 adoption signal을 구분하고 Graphify를 어디까지 pilot에 넣을 수 있으며 어디부터 runtime guardrail이 필요한지 판단하는 것이다.
핵심 결론
개발자 반응은 Graphify가 repo 이해 비용, 서비스 간 관계 탐색, 반복적인 raw file reading, context pack 갱신 비용이라는 실제 문제를 건드린다는 신호다. 그러나 강한 관심은 운영 성숙도의 증거가 아니다.
- 채택 가능: repo navigation, service relation discovery, dependency hint, context pack 초안, root/e2e impact 후보 탐색
- 제한 필요: contract truth 판단, write boundary 결정, approval scope 판단, security-sensitive 변경 계획, stale graph 기반 자동 수정
- 필수 조건: graph freshness metadata, SSOT와 Derived Knowledge 분리, runtime write allowlist, diff guard, handoff 규칙
성숙도 평가 기준
원본은 탐색 성숙도, 최신성 성숙도, 근거 성숙도, 운영 성숙도, 실패 격리 성숙도로 나눴다. Graphify는 탐색 성숙도에서는 유망하지만 최신성, 근거, 운영, 실패 격리는 별도 장치가 필요하다.
Sanctum 적용 해석
Sanctum에서 반복되는 질문은 wallet-api 변경이 kms-api, hd-manager, contracts와 어떤 관계를 갖는지, kms-api 작업자가 wallet flow를 어디까지 읽어야 하는지, derivation 정책과 contract/e2e flow가 연결되는지, Rust MPC protocol boundary가 어디인지, root/e2e agent가 무엇을 handoff해야 하는지다. Graphify는 후보 답을 빠르게 만들 수 있지만, contracts/, 서비스별 AGENTS.md, llm-context/, write allowlist, handoff 규칙으로 검증해야 한다.
운영 판단
Stage 0에서 Graphify 역할을 context router로 문서화한다. Stage 1에서는 root graph를 read-only pilot으로 사용한다. Stage 2에서는 service context pack 초안 생성 보조에 사용한다. Stage 3에서는 runtime worker에게 read-only context로 제공하되 write allowlist와 diff guard를 적용한다. Stage 4에서는 root graph가 noisy할 때 cwd-specific graph를 실험한다.
서비스별로 wallet-api는 wallet handler, KMS 호출, contract 후보, e2e 후보를 찾되 외부 변경은 propose-only로 둔다. kms-api는 security semantics를 canonical docs와 code review로 검증한다. hd-manager, mpc-manager-rs, party-node-rs는 policy/protocol 변경을 handoff한다. root/e2e agent는 Graphify를 넓게 쓰되 service implementation 변경은 해당 worker에게 넘긴다.
리스크와 가드레일
가장 큰 리스크는 개발자 호응이 검증 부족을 가리는 것이다. 실패 모드는 stale graph를 최신 사실로 사용하는 것, graph relation을 contract truth로 해석하는 것, generated summary를 AGENTS.md 또는 contracts/보다 우선하는 것, Codex App workspace separation을 hard boundary로 착각하는 것, service worker가 외부 파일을 직접 수정하는 것이다.
가드레일은 source link, confidence, validation state, stale conditions를 붙이고, Graphify가 SSOT도 write authorization system도 아니라고 worker instruction에 명시하며, contracts/를 canonical contract SSOT로 유지하고 runtime write allowlist와 diff guard를 독립적으로 작동시키는 것이다.
실행 체크리스트
- Graphify adoption signal을 탐색 가치로 해석하고 운영 성숙도와 분리한다.
- Root graph read-only pilot을 시작한다.
- Freshness, source traceability, drift handling, scope safety, failure fallback 체크리스트를 만든다.
- Graphify output을 Derived Knowledge 형식으로 저장한다.
- 서비스별 write/read/propose-only boundary를 문서화한다.
- Graphify 실패나 false positive를 수집해 blocker 전환 여부를 나중에 판단한다.