"하나는 model 이 뭐라 했나를 물어. 다른 하나는 오늘 뭘 보여주나를 물어."
명사 둘, 질문 둘
Recall 은 transcript 를 아주 다른 일을 하는 두 개의 일급 대상으로 쪼개. 각각이 어느 질문에 답하는지 배우면 데이터 모델 전체가 딱 맞아 들어가:
- run 은 답해: "이 model 이, 이 설정으로, 이 source 바이트에 정확히 뭘 돌려줬나?" 얼린 증거야. 절대 안 바뀌어.
- release 는 답해: "지금 제품이 어느 버전의 텍스트를 보여주고, 요약이랑 검색을 파생하나?" 버전이야. 교정하면 바뀌어.
이건 같은 행의 두 이름이 아냐. 다른 규칙을 가진 별도 테이블에 살아. run 은 한 번 쓰고 봉인해. release 는 '이게 이 영상의 현재 최선 텍스트야' 라고 말하는 움직이는, 번호 매긴 포인터야.
run 하나, release 여럿
중요한 관계가 여기 있어: 불변 run 하나가 시간에 걸쳐 여러 release 밑에 앉을 수 있어. model 이 영상을 한 번 전사했어(그게 run). 그다음 이름을 잘못 들은 걸 발견해서 교정했고 — 그게 release v2 를 만들었어. 나중에 타임스탬프를 고쳤고 — release v3. run 은 안 움직였고, release 가 쌓였어. 어느 순간이든 영상당 정확히 한 release 가 current 로 표시되고, 그게 검색이랑 요약이 쓰는 거야.
버전 관리처럼 생각해: run 은 불변 commit — 정확히 뭐가 캡처됐는지의 영구 기록. current release 는 최신 좋은 버전으로 옮겨가는 branch 포인터 같은 거. 언제든 raw commit 으로 걸어 돌아갈 수 있고, 언제든 '지금 HEAD 가 어느 버전이야?' 를 물을 수 있어. 질문 둘, 답 둘, 절대 혼동 안 함.
그냥 텍스트를 편집하면 안 돼?
'그냥 텍스트 편집' 은 두 질문을 하나의 mutable blob 으로 무너뜨리고 두 답을 다 잃으니까. 제자리 편집하면 model 이 원래 뭘 돌려줬는지(run 이 사라짐) 도 텍스트가 어떻게 진화했는지(버전이 사라짐) 도 못 말해. run 은 얼리고 release 는 버전 관리함으로써, Recall 은 '기계가 실제로 뭐라 했나?' 랑 '지금 뭘 보여주나?' 랑 '하나에서 다른 걸로 어떻게 갔나?' 를 — 전부 한 번에 답할 수 있어. 다음 레슨이 교정의 순간에 뭐가 일어나는지, 왜 덮어쓰지 않고 분기하는지 보여줘.