"교정은 새 버전이지, 옛것 위에 얹은 더 작은 거짓말이 아냐."
실수를 발견하는 순간
검색이 model 이 이름을 잘못 들은 segment 를 찾아냈어 — 아빠가 분명 'Pippa' 라고 했는데 'Mathilda' 라고 썼어. 고치고 싶어. 여기가 대부분의 시스템이 잘못된 선택을 하는 정확한 갈림길이야. 솔깃한 수는 transcript 에 손을 뻗어 그 segment 를 제자리에서 편집하는 거야. UPDATE 하나. 끝난 느낌.
Recall 은 그 편집을 거부해. 교정은 raw run 을 절대 변형 안 하고, 기존 release 도 변형 안 해. 대신 분기해: 교정은 명시적 segment 교체로 기록되고, 그게 새 content hash 를 가진 완전히 새로운 release 버전을 만들어. 옛 release 는 여전히 존재해. 밑의 얼린 run 은, 늘 그렇듯, 손 안 대.
왜 분기가 덮어쓰기보다 나아
보상 셋, 그리고 복리로 쌓여:
- 증거가 살아남아. 불변 run 은 여전히 model 이 정확히 뭐라 했는지 쥐고 있어서, 제품이 이제 'Pippa' 를 보여줘도 'Mathilda' 는 기록된 사실로 보존돼. model 의 실수가 네 게 아니라 model 의 것이었음을 언제든 증명할 수 있어.
- 변화가 보여. 교정된 텍스트가 새 content hash 를 가진 새 버전이라, 교정은 조용한 변형이 아니라 일급 이벤트야. v2 가 존재하고, 뭘 바꿨고, 언제인지 볼 수 있어.
- staleness 가 감지 가능해져. 이게 큰 거고 다음 레슨 전체가 이거야: 옛 release 위에 지은 어떤 요약이나 index 든 옛 content hash 를 지목했어. 새 release 는 새 hash 를 가져. 그 불일치가 시스템이 요약이 이제 낡았다는 걸 아는 방법이야.
진실에 적용한 copy-on-write
이건 파일시스템이랑 함수형 자료구조에서 본 copy-on-write 패턴을 transcript 에 적용한 거야. 공유된 걸 변형하지 않고, 안 바뀐 전부를 공유하며 네가 교정한 데서만 다른 새 버전을 써. 옛 버전은 아직 그걸 가리키는 누구(또는 어떤 산물) 에게든 유효하게 남고, 새 버전이 current 가 돼. 덮어쓰기는 이력을 지우는 파괴적 행위고, 분기는 이력을 기록하는 가산적 행위야. 데이터가 중요할 때 — 그리고 네 기억이 중요할 때 — 가산적인 걸 원해.