Sparse Worktree와 Container Sandbox 강화 보고서
이 보고서는 Sanctum 서비스별 LLM worker의 파일시스템 경계를 어떻게 강화할지 결정하기 위한 보고서다.
핵심 결론
- 일반 파일럿은 sparse worktree + runtime write allowlist + diff guard로 시작한다.
- 보안 민감 또는 부수 변경 위험이 큰 작업은 container/read-only mount + writable service mount로 격리한다.
contracts/는 service worker에게 read-only 또는 propose-only로 제공하고 변경은 승인된 contracts owner 또는 root/e2e job에서 수행한다.- Graphify, RAG, generated summary는 SSOT나 write authorization source가 아니다.
원본 문서의 주요 내용
Sparse worktree는 필요한 경로만 checkout하거나 노출해 파일 시야를 줄인다. 도입 속도가 빠르고 Git workflow와 결합하기 쉽지만 단독으로는 보안 경계가 아니다.
Container/read-only mount 방식은 프로세스가 보는 파일시스템 자체를 제한한다. 예를 들어 wallet-api worker container는 wallet-api만 read-write, contracts/는 read-only, sibling service는 read-only stub 또는 no mount로 제공할 수 있다.
Sanctum 적용 해석
wallet-api와 hd-manager는 sparse worktree 파일럿 후보로 적합하다. 다른 서비스와 계약을 읽어야 하지만 기본 작업은 서비스 내부 구현과 테스트에 한정할 수 있다.
kms-api는 container/read-only mount 우선 후보다. 키 관리와 보안 경계가 관련되므로 workspace illusion을 허용하면 안 된다.
mpc-manager-rs와 party-node-rs는 shared metadata나 lockfile 영향이 크다. 대상 서비스만 writable overlay로 두고 shared workspace metadata는 propose-only 또는 root/e2e handoff 대상으로 분류한다.
운영 단계
| 단계 | 대상 | 강제 방식 |
|---|---|---|
| Stage 1 | wallet-api, hd-manager | sparse worktree + diff guard |
| Stage 2 | contracts/root-e2e governance | proposal + owner approval |
| Stage 3 | kms-api, rust-mpc | container/read-only mount |
| Stage 4 | 전체 운영 | allowlist, mount, approval, audit 통합 |
리스크와 가드레일
- Sparse 밖 파일이 formatter, package manager, codegen으로 바뀌면 전체 diff에서 lockfile, root config, generated schema를 별도 분류한다.
- Container mount가 너무 넓게 열리면 의미가 사라지므로 target service만 writable로 둔다.
llm-context/contracts.md에 계약 사실을 복제하지 않고 canonical 위치와 책임 해석을 제공한다.- Graphify root graph가 관련 파일을 찾아줘도 worker가 그 파일을 쓸 수 있다는 뜻은 아니다.