교정은 분기해

"교정은 새 버전이지, 옛것 위에 얹은 더 작은 거짓말이 아냐."

실수를 발견하는 순간

검색하다 보니 model 이 이름을 잘못 들은 segment 가 나왔어. 아빠는 분명 'Pippa' 라고 했는데 'Mathilda' 로 적혀 있어. 고치고 싶지. 대부분의 시스템이 잘못된 선택을 하는 갈림길이 바로 여기야. 솔깃한 수는 transcript 에 손을 뻗어 그 segment 를 제자리에서 고치는 거고. UPDATE 한 줄. 끝난 것 같고.

Recall 은 그 편집을 거부해. 교정은 raw run 을 절대 변형 안 하고, 기존 release 도 변형 안 해. 대신 분기해. 교정은 segment 교체로 명시적으로 기록되고, 그게 새 content hash 를 가진 완전히 새로운 release 버전을 만들어. 옛 release 도 그대로 남아 있고. 밑에 깔린 얼린 run 은, 늘 그렇듯, 손도 안 대.

왜 분기가 덮어쓰기보다 나아

보상은 셋인데, 복리처럼 쌓여.

증거가 살아남아. 불변 run 은 model 이 정확히 뭐라 했는지를 그대로 쥐고 있어. 그래서 제품이 이제 'Pippa' 를 보여줘도 'Mathilda' 는 기록된 사실로 남아. 그 실수가 네 실수가 아니라 model 의 실수였다는 걸 언제든 증명할 수 있고.
변화가 보여. 교정된 텍스트가 새 content hash 를 가진 새 버전이라, 교정은 조용한 변형이 아니라 일급 이벤트야. v2 가 존재하고, 뭘 바꿨고, 언제인지 볼 수 있어.
staleness 를 감지할 수 있게 돼. 이게 큰 거고, 다음 레슨 전체가 이 얘기야. 옛 release 위에 올린 요약이든 index 든 다 옛 content hash 를 가리키고 있어. 새 release 는 새 hash 를 갖고. 그 불일치가 바로 시스템이 '이 요약은 이제 낡았다' 를 아는 방법이야.

진실에 적용한 copy-on-write

파일시스템이나 함수형 자료구조에서 보던 copy-on-write 패턴을 transcript 에 적용한 거야. 공유하는 걸 건드리는 대신, 안 바뀐 부분은 그대로 공유하면서 네가 고친 데만 다른 새 버전을 쓰는 거지. 옛 버전은 아직 그걸 가리키는 누구(또는 어떤 산물) 에게든 유효하게 남고, 새 버전이 current 가 돼. 덮어쓰기는 이력을 지우는 파괴적인 행위고, 분기는 이력을 기록하는 더하기 행위야. 데이터가 중요할 때, 그러니까 네 기억이 중요할 때 필요한 건 더하기 쪽이고.

Code

교정은 교체를 기록하고 새 release 를 낳아·sql

-- 교정 자체가 명시적이고 저장돼, 조용한 UPDATE 가 아냐.
CREATE TABLE corrections (
  correction_id  TEXT PRIMARY KEY,
  from_release   TEXT NOT NULL,   -- 교정되는 release
  segment_index  INTEGER NOT NULL,
  old_text       TEXT NOT NULL,   -- "...Mathilda..."
  new_text       TEXT NOT NULL,   -- "...Pippa..."
  created_at     TEXT NOT NULL
);

-- 적용은 옛 release 를 편집하지 않아. 새 걸 만들어:
--   release v2  (run_id = 같은 얼린 run)
--               (release_number = 2, is_current = 1)
--               (content_sha256 = 교정된 텍스트의 hash)
-- release v1 은 여전히 존재; raw run 은 절대 안 움직였다.

Exercise

네 일에서 값을 덮어써서 '고치는' 편집 경로를 찾아봐. 교정된 field, 갱신된 status, patch 된 record 같은 거. 그 값에 하류로 기대고 있는 걸 따라가 봐. 캐시된 결과, 리포트, 파생 count. 그리고 물어봐. 덮어썼을 때 하류에서 뭐 하나라도 자기가 낡았다는 걸 알아채? 고치는 걸 자기 identity 를 가진 새 버전으로 다시 설계하고, 하류 소비자가 그 변화를 어떻게 감지할 수 있는지 적어봐.

Hint

덮어쓰기의 실패 모드는 편집 그 자체가 아냐. 옛 값에서 파생된 것들이 이미 움직여버린 숫자를 계속 믿는 게 문제지. 대신 분기해. 새 버전, 새 hash 나 id. 그럼 자기가 어느 버전 위에 지어졌는지 기억하는 하류 산물이 비교해서 낡았다는 걸 알아챌 수 있어. 덮어쓰면 그 비교 자체가 불가능하고.