Sanctum LLM Operations Reports · Stage 2 Topic HTML

LLM Wiki vs Graphify vs RAG 향상 보고서

topics / 10-context-management / reports / llm-wiki-vs-graphify-vs-rag

← 주제 인덱스로 돌아가기

보고서 목적

이 보고서는 Sanctum LLM 운영에서 LLM Wiki, Graphify, RAG를 각각 어떤 책임과 신뢰 수준으로 사용할지 결정하기 위한 파일 수준 향상 보고서다. 대상은 wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs, contracts/, root/e2e agent를 운영할 엔지니어링 리드다.

핵심 결론

Sanctum은 단일 지식 도구를 고르는 방식이 아니라 계층 분리 모델을 채택해야 한다. LLM Wiki는 검증된 장기 운영 지식과 반복 판단을 보존한다. Graphify는 repo 구조와 service-to-service 관계 후보를 좁히는 context router다. RAG는 특정 질문에 대한 원문 근거를 회수하는 evidence retrieval 계층이다. SSOT는 contracts/, 승인된 AGENTS.md, service llm-context/, runbook, current source code에 있어야 한다.

Graphify graph, RAG DB, generated summary, Discord thread summary는 모두 derived layer다. 이들은 worker를 빠르게 만들 수 있지만 write authorization이나 source of truth가 아니다.

원본 문서의 주요 내용

계층주 역할Sanctum 적용SSOT 여부
LLM Wiki검증된 결론과 운영 판단 보존worker boundary, flow 판단, handoff rule보통 derived knowledge
Graphify구조/관계 탐색관련 service, contract, test 후보 축소불가
RAG원문 근거 검색contracts/, AGENTS.md, llm-context/, runbook evidence불가
Runtime guard실제 write 경계 강제allowlist, diff guard, approval, handoff권한 집행 계층

contracts/는 contract SSOT로 유용하지만 service worker 실행 문맥 전체를 대체하지 않는다. 따라서 각 서비스에는 AGENTS.mdllm-context/service.md, commands.md, test-scope.md, e2e-role.md, contracts.md, dependency-stubs.md가 필요하다. 특히 contracts.md는 contract 내용을 복제하지 않고 canonical contracts/ 위치와 service impact를 매핑해야 한다.

Sanctum 적용 해석

wallet-api 변경 요청이 들어오면 Graphify는 wallet handler, DTO, kms-api 호출 지점, hd-manager derivation 관련 코드, contracts/ schema, root/e2e test 후보를 좁힌다. 그러나 실제 수정은 wallet-api write allowlist 안에서만 수행해야 한다. kms-api, hd-manager, rust-mpc, contracts/ 변경은 read 또는 propose-only로 남기고 root/e2e agent에 handoff한다.

kms-api는 key management와 보안 경계가 강하므로 Graphify/RAG 결과보다 canonical runbook, contract, current source 확인을 우선한다. hd-manager는 derivation 또는 wallet material 변경이 wallet lifecycle에 영향을 줄 수 있으므로 e2e handoff 조건을 명확히 둔다. mpc-manager-rsparty-node-rs는 orchestration과 protocol compatibility가 얽혀 있으므로 관련 edge 탐색과 수정 권한을 분리한다.

운영 판단

초기 Graphify 도입은 root graph pilot으로 시작한다. root graph는 freshness 관리가 단순하고 wallet-api -> kms-api/hd-manager/contracts, mpc-manager-rs -> party-node-rs 같은 cross-service flow tracing에 적합하다. root graph가 noisy하다는 실측 근거가 생기면 service scan-root graph와 merged graph를 도입한다.

RAG는 canonical docs, service context pack, contracts, runbook, validated wiki를 대상으로 삼되 source hash, indexed_at, source type, validation state를 기록해야 한다. LLM Wiki는 repeated decision을 저장하지만 stale condition과 source link 없이는 운영 근거로 쓰지 않는다.

리스크와 가드레일

리스크가드레일
Graphify driftbranch, commit, generated_at, scan-root, ignore policy 기록 및 stale check
RAG miss 또는 stale chunksource hash, indexed_at, canonical priority, raw read fallback
LLM Wiki staleconfidence, validation_state, stale_when, source links 필수
contracts.md가 contract 복제본이 됨mapping only 원칙 적용
scope invasionwrite/read/propose-only boundary, diff guard, handoff
Codex App boundary 오해Codex App은 exploration/review, enforced write는 runtime/sandbox 사용

실행 체크리스트

  • contracts/를 contract SSOT로 명시한다.
  • 각 서비스에 AGENTS.mdllm-context/ pack을 만든다.
  • llm-context/contracts.md는 canonical path mapping으로 작성한다.
  • Graphify는 root graph pilot부터 시작하고 metadata를 기록한다.
  • RAG 결과에 source type, revision, indexed_at, validation state를 붙인다.
  • worker별 write allowlist와 diff guard를 runtime에서 강제한다.
  • cross-service 변경은 root/e2e agent handoff로 처리한다.

관련 주제 연결

이 보고서는 ssot-and-derived-knowledge의 저장 규칙과 context-router-model의 실행 흐름을 연결한다. 또한 Graphify drift, service context pack, worker handoff, Codex App/runtime boundary, 최종 adoption roadmap의 선행 원칙이 된다.