checkout은 너무 큰 망치야
한 문장을 되살리고 싶을 때 live vault 전체를 과거 commit으로 checkout하면 그 뒤 생긴 정당한 수정까지 같이 사라져. 특히 여러 장치가 쓰는 vault에서는 과거 snapshot이 알지 못하는 현재가 항상 존재할 수 있어.
파일 하나만 checkout해도 문제는 남아. 현재 버전과 과거 버전 사이 의미 충돌을 보지 않고 덮기 때문이야. restore UI가 쉬워 보일수록 사용자는 시간을 되감았다고 착각하고, 실제로는 다른 사람의 현재를 지운다.
과거는 evidence로만 읽어
안전한 restore는 history에서 blob을 읽고 현재 파일과 diff를 보여준 뒤, 승인된 내용을 live vault에 새 write로 적용해. 그 write는 edit과 같은 permission, stale guard, atomic replace를 통과하고 새로운 semantic commit을 낳아.
결과만 보면 과거 내용이 돌아왔지만 history는 앞으로 갔어. 누가 어느 시점의 무엇을 참고해 복원했는지 새 commit이 설명하고, 원하면 복원 자체도 다시 고칠 수 있어. 되돌림이 감사에서 사라지지 않는 구조야.
부분 복원이 기본이야
memory note는 한 덩어리처럼 보여도 최근에 추가된 올바른 문단과 잘못 바뀐 한 문장이 공존해. restore가 blob 전체만 제공하면 사용자는 둘 중 하나를 희생해야 해. 최소한 current, historical, proposed 세 면을 보여줘야 해.
자동 merge가 가능한 text라도 conflict가 없다는 사실은 의미가 맞다는 뜻이 아니야. 도구는 syntactic patch를 제안할 수 있지만 기억 의미를 확정하는 건 live session의 판단이야.
restore rehearsal은 실제 원본을 건드리지 않아야 해
복구 기능 테스트를 production vault에서 해선 안 돼. 임시 source와 history를 만들고, 과거 blob 선택, stale detection, forward commit, audit trailer를 end to end로 검증해. restore는 평소 거의 안 쓰여서 가장 위험한 코드가 되기 쉽거든.
운영 UI에서는 restore 버튼이 정확한 대상과 결과를 preview하고, 적용 뒤 새 head를 보여줘야 해. 성공 toast 하나만으로는 어떤 bytes가 살아났고 어떤 commit이 기록했는지 증명되지 않아.