"다시 찾아갈 수 없는 인용은 인용이 아냐. 각주 모양을 한 소문일 뿐이지."
인용은 미래에 하는 약속이야
어떤 문장을 인용한다는 것은 나중에도 같은 자리로 돌아가 정확한 단어를 확인할 수 있다고 약속하는 일이야. 다음 주나 내년뿐 아니라 데이터베이스를 다시 만들고 기계를 바꾼 뒤에도 그래야 해. 주소가 모르는 사이 다른 내용을 가리킬 수 있다면 약속은 이미 깨진 셈이야. 아직 따라가 확인하지 않아서 드러나지 않았을 뿐이지.
쉽게 붙인 주소는 쉽게 움직여
- 검색 결과의 순번: '세 번째 결과'는 쿼리나 코퍼스가 달라지면 바로 다른 문서가 돼.
- DB 행 번호: 삽입할 때 붙인 자동 증가 id는 인덱스를 지우고 다시 만들면 새로 배정돼. 예전의
id=417이 엉뚱한 chunk를 가리킬 수도 있어. - 문자 위치만 저장한 주소:
4120–4229위쪽을 편집하면 뒤의 모든 위치가 밀려나.
셋 다 오늘은 잘 작동해 보여서 더 위험해. 깨진 링크처럼 즉시 실패하지 않고, 재구축 뒤에 다른 내용으로 조용히 연결될 수 있거든.
재색인은 일상적인 작업이야
살아 있는 코퍼스에서는 파일을 고치고 새 문서를 넣을 때마다 인덱스 일부가 다시 만들어져. chunking profile을 바꾸면 범위는 더 커지고. 그러니 재색인을 드문 재난처럼 취급해 주소 설계를 미룰 수 없어. 위치나 삽입 순서에 묶인 인용은 매일 썩을 기회를 얻고, 틀린 문단에 도착할 때까지 아무 경고도 주지 않아.
참조는 놓인 자리보다 내용에 묶어. 행 번호와 순번은 저장 방식이 바뀌면 사라지지만, 내용에서 계산한 주소는 같은 내용을 다시 만들 때 되살아나. 내구성 있는 참조는 대상이 스스로 주소를 결정해야 해.
다음 단계: 텍스트가 자기 이름을 짓게 해
Lantern은 문서의 내용 해시와 chunk의 문자 범위, 그 범위를 만든 profile을 함께 해시해 chunk id를 계산해. 데이터베이스가 우연히 붙인 이름이 아니라 텍스트의 지문을 만드는 거야. 같은 소스와 같은 규칙으로 다시 색인하면 새 기계에서도 같은 id가 나와. 이 성질이 재구축할 때마다 죽던 인용을 다시 확인할 수 있는 약속으로 바꿔.