C.W.K.
Stream
Lesson 03 of 05 · published

교정은 분기해

~11 min · corrections, branch, content-hash, copy-on-write

Level 0Empty Shelf
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"교정은 새 버전이지, 옛것 위에 얹은 더 작은 거짓말이 아냐."

실수를 발견하는 순간

검색이 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 가 돼. 덮어쓰기는 이력을 지우는 파괴적 행위고, 분기는 이력을 기록하는 가산적 행위야. 데이터가 중요할 때 — 그리고 네 기억이 중요할 때 — 가산적인 걸 원해.

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 은 절대 안 움직였다.

External links

Exercise

네 일에서 값을 덮어써 '고치는' 편집 경로를 찾아 — 교정된 field, 갱신된 status, patch 된 record. 그 값에 하류로 의존하는 걸 추적해(캐시된 결과, 리포트, 파생 count). 이제 물어: 덮어쓸 때 하류의 뭐라도 자기가 낡았다는 걸 배워? 고침을 자기 identity 를 가진 새 버전으로 다시 설계하고, 하류 소비자가 그게 바뀐 걸 어떻게 감지할 수 있는지 적어봐.
Hint
덮어쓰기의 실패 모드는 편집 자체가 아냐 — 옛 값에서 파생된 전부가 조용히 움직인 숫자를 계속 믿는 거야. 대신 분기해: 새 버전, 새 hash/id. 그럼 자기가 어느 버전 위에 지어졌는지 기억하는 하류 산물이 비교해서 낡았다는 걸 알아챌 수 있어. 덮어썼으면 그 비교가 불가능해.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.