"identity 열 개, 그리고 각각이 정확히 특정 실수 하나를 막으려고 존재해."
사다리 전체를, 한 단씩
Recall 의 파이프라인에는 identity 계층이 대략 열 개 있어. 이걸 과잉 설계로 보고 싶어지지. 아냐. 계층마다 자기가 막는 구체적이고 진짜인 혼동이 있어서 있는 거야. 그 계층이 위 계층으로 뭉개지면 파이프라인이 어떻게 잘못되는지가 정해져 있거든. 이 사다리는 '일어날 수 없게 만든 실수' 목록으로 읽어.
- Video (video_id) — 같은 슬롯의 중복 논리 아카이브 행을 막아.
- 관찰 미디어 (cheap_fingerprint) — 바뀐 바이트를 옛 파일로 취급하는 걸 막아.
- 아카이브 execution (execution hash) — 같은 트랜스코드/전사 execution 을 두 번 큐잉하는 걸 막아.
- source 콘텐츠 (source_sha256) — '같은 경로' 를 '같은 바이트' 로 혼동하는 걸 막아.
- 오디오 proxy (source hash + proxy config) — 동일 오디오 chunk 를 다시 빌드하는 걸 막아.
- 유료 provider 호출 (chunk hash + provider config) — 동일 증거에 두 번 결제하는 걸 막아.
- transcript run (video + source + provider config + proxy config) — 받아들인 raw 증거를 중복하는 걸 막아.
- release (run id + content hash) — 같은 투영된 transcript 를 중복하는 걸 막아.
- summary (release + type + provider + model) — 동일 요약 산물을 반복하는 걸 막아.
- title (영상의 summary id) — stale 요약 증거에서 파생된 제목을 보여주는 걸 막아.
각 계층이 자기 자리를 버는 이유
이 계층들은 hash 하나를 중복해서 복사한 게 아냐. granularity 가 다른 자리에서 다른 질문에 답하는 것들이야. 유료 호출 identity 랑 transcript-run identity 는 비슷해 보여도, 하나는 오디오 chunk 하나에 범위가 잡혀 있고(그 chunk 를 두 번 결제 안 하려고), 다른 하나는 영상 전체의 증거에 잡혀 있어(받아들인 run 을 중복 안 하려고). 이 둘을 뭉개면 chunk 단위로 하려던 걸 영상 단위로 결제하거나, 영상 단위로 하려던 걸 chunk 단위로 dedupe 하게 돼. 계층마다 어떤 종류의 동일성을 어느 granularity 에서 알아봐야 하는지가 정확히 정해져 있는 거야.
Merkle tree 를 닮은 아이디어야. 레벨마다 있는 identity 가 각각 아래를 요약하니까, 어디서 변화가 나든 전부를 다시 확인하지 않고도 맞는 계층에서 잡혀. 데이터 중복제거 시스템도 똑같이 해. chunk 경계에서 hash 해서 안 바뀐 영역은 값싸게 알아보고 바뀐 데만 정확히 골라내지. Recall 의 10계층은 그 원리를 전사 파이프라인에 적용한 거고. '같다' 는 개념이 여러 개면, 각각 자기 granularity 에서 자기 identity 를 갖는 거야.
옮겨 쓸 규칙
정확히 10계층이 필요한 경우는 거의 없을 거야. 근데 그 밑에 깔린 결정은 계속 마주치게 돼. 가져갈 규칙은 이거야. 'done' 이나 '이미 있음' 체크에 손을 뻗을 때마다 '어느 레벨에서 같은 거지?' 를 물어봐. 같은 논리 entity 야? 같은 관찰 버전이야? 정확히 같은 바이트야? 같은 설정 아래 같은 파생 출력이야? 이 물음에 '응, 근데' 가 하나 나올 때마다 identity 계층이 하나 더 필요하다는 힌트야. 계층 수는 결국 네 시스템이 실제로 구별해야 하는 동일성의 종류 개수야. 더도 말고, 절대 덜도 말고.