"chunk 한테 이름을 주지 마. chunk 의 내용이 스스로 이름 짓게 둬."
공식
Lantern chunk id 는 배정되지 않아 — 계산돼. 문서 자체의 content 해시, 조각의 시작·끝 문자 offset, 그걸 만든 chunking profile 의 id 를 잡아. 이어 붙이고, 결과를 해시하고, 앞 32 개 16진 문자를 남겨. 그 문자열이 chunk id 야. 모든 입력이 내용 자체에 대한 사실이라, 출력이 DB 가 삽입 시점에 붙인 라벨이 아니라 내용의 지문이야.
모든 재료가 거기 있는 이유
공식의 각 부분이 자리를 벌어:
doc_sha256— 어느 문서인가, 파일명이 아니라 내용으로 식별돼. 바이트 동일한 두 파일은 여기서 같은 문서고, 이름 바뀐 파일도 여전히 같은 문서고, 편집된 파일은 다른 문서야.char_start와char_end— 그 문서의 어느 조각인가, 디코드된 텍스트로의 문자 offset 으로. 정확한 범위를 고정해.profile_id— 어느 chunking 규칙 아래인가. 다른 profile 로 잘린 같은 범위는 다른 chunk 고, 다른 id 를 받아야 해.
공식의 어떤 것도 chunk 가 언제 삽입됐는지 어디 테이블에 앉는지 안 말해. 그 누락이 핵심 전부야: 위치와 시간의 흔적을 다 지우면, 남는 건 내용이 바뀔 때만 바뀔 수 있어.
공짜로 얻는 것
content-addressing 이 추가 장부 없이 속성 셋을 한 번에 건네:
- 안정성: 같은 profile 아래 같은 텍스트를 다시 수집하면 id 가 바이트 동일해 — 재구축을 넘어, 기계를 넘어.
- 중복 제거: 동일 내용은 같은 id 로 계산돼, 여럿 대신 자연히 하나로 접혀.
- 검증 가능성: 내용이 주어지면, 누구나 id 를 재계산해 맞는지 확인할 수 있어 — id 는 배정될 뿐 아니라 확인 가능해.
이게 Git 이 commit 과 blob 을 이름 짓고, 컨테이너 시스템이 이미지 layer 를 이름 짓는 데 쓰는 바로 그 트릭이야: 주소가 곧 내용의 해시야.
해시를 자르는 건 의도적이고 안전한 거래야. 완전한 SHA-256 은 16진 64 자고, Lantern 은 32 자를 남겨. 그래도 128 비트 주소 공간이야 — 진짜 코퍼스에서 다른 두 chunk 가 충돌하는 게 천문학적으로 불가능할 만큼 충분히 넘쳐. 이론적 충돌 여유 조금을 더 짧고 다루기 쉬운 id 와 맞바꿔. 왜 자르는지 알고, 이 규모에서 안전하단 걸 알아.
id 는 온전한 provenance 와 함께 여행해
chunk id 는 절대 혼자 안 다녀. 모든 결과가 provenance 번들 전체를 지녀: 코퍼스, 문서 경로, 문서 해시, 문자 offset, chunk 해시, profile. id 는 내구성 있는 손잡이고, 번들은 조각을 처음부터 다시 찾고, 다시 검증하고, 다시 파생하는 데 필요한 전부야. 함께면 결과가 몇 년 뒤, 네가 처음 검색을 돌렸을 땐 존재하지도 않던 기계에서, 완전한 확신으로 가리킬 수 있는 게 돼.