setup.sh: 운영자 백업·트랜잭션 스냅샷 이중 압축 (#897 4단계 분리, backlog)

[seoseo-ai]

#897의 4단계를 분리한 이슈입니다. 주장은 사실로 확인되었으나 실익이 47ms로 작습니다 — 우선순위 낮음(backlog).

주장 (#897 원문)

setup.sh: 운영자 백업 + 트랜잭션 스냅샷이 겹치는 관리 트리를 이중 압축

검증 결과 — 사실입니다

setup.sh는 한 번의 실행에서 겹치는 트리를 두 번 gzip합니다.

	위치	대상
운영자 백업	backup_claude_dir() setup.sh:284	settings.json hooks output-styles agents commands skills
트랜잭션 스냅샷	snapshot_paths() 경유 setup.sh:169	CCC_MANAGED_PATHS = 위 6개 + headless.sh CLAUDE.md memories

즉 운영자 백업 대상은 트랜잭션 스냅샷 대상의 진부분집합이며, 두 경로 모두 tar -czf입니다.
(CCC_MANAGED_PATHS 정의: scripts/lib/harness-paths.sh:12)

측정 (yukson/vps5, 실제 ~/.claude 기준)

tar -czf (gzip 있음) :  47 ms   378 KiB
tar -cf  (gzip 없음) :   5 ms  1300 KiB

→ 중복된 gzip 1회의 비용은 약 47ms이고, setup.sh는 세션마다가 아니라 간헐적으로 실행됩니다.

착수하지 않은 이유

• 절감 47ms × 간헐 실행 = 사실상 무시 가능
• 반면 두 아카이브는 역할이 다릅니다:
  • 운영자 백업 = $CLAUDE_DIR/backups/에 남는 durable restore point (--no-backup로 생략 가능)
  • 트랜잭션 스냅샷 = 실패 롤백 전용, 성공 시 폐기되는 사설 스냅샷 (--no-backup에도 유지)
• 두 아카이브의 생명주기·보존정책·생략조건이 다르므로, 통합하려면 이 차이를 유지해야 합니다.
  47ms를 위해 롤백 경로를 건드리는 것은 좋은 거래가 아닙니다.

착수한다면

#897 원안대로 공통 스냅샷 + manifest/hash 기반 변경분만 교체.
단, 아래를 깨지 않아야 합니다:

• --no-backup 시 운영자 백업만 생략되고 트랜잭션 롤백은 계속 동작
• 성공 시 트랜잭션 스냅샷 폐기 / 실패 시 보존(keep_snapshot, setup.sh:197-205)
• 아카이브 검증(tar -tzf) 유지 — 두 경로 모두 생성 직후 검증 중
• settings.local.json이 관리 대상에서 계속 제외될 것 (fix(harness, P2): settings.local.json이 관리 아티팩트로 전 노드 배포 — 노드 로컬 승인 클로버 + 광역 grant 전파 #454, 노드 누적 승인 보호)

결론

기록 목적의 이슈입니다. 주장은 사실이나 실익이 47ms이므로, 누군가 재조사하지 않도록 측정치를 남깁니다.
setup.sh 실행 시간이 실제 문제로 보고되기 전에는 착수를 권하지 않습니다.