"'어느 복사본이 진짜야?'라는 질문에는 언제나 답이 하나여야 해. 둘이 되는 순간 버그가 시작돼."
진실과 그 복사본을 구별해
시스템 안의 데이터를 하나 가리키고 물어봐. 이것이 원본인가, 원본에서 다시 만든 것인가? 원본을 맡은 저장소는 권위 있는 출처야. 언제든 버리고 원본에서 다시 만들 수 있는 것은 파생 상태고. 튼튼한 시스템은 자신이 가진 모든 데이터가 어느 쪽인지 설명할 수 있어. 대답이 흐릿한 곳이 있다면 복구할 때 반드시 문제가 생겨.
복사는 권위를 둘로 갈라
파일을 한곳에 모으려고 복사하기 전에는 답이 간단해. 원래 파일이 진짜야. 그런데 모음 폴더에 똑같은 파일을 하나 더 두면 두 복사본이 모두 원본처럼 보여. 한쪽만 고친 뒤 여섯 달이 지나면 어느 버전을 남기려 했는지 알기 어려워지지. 복사는 글을 모은 게 아니라, 무엇을 믿어야 하는지 모호하게 만든 거야.
레지스트리는 선을 넘지 않아
Lantern은 원본을 복사하지 않고 주소만 등록해. 그래서 파일은 계속 권위 있는 출처로 남아. 그 파일에서 만든 chunk 테이블과 FTS 인덱스, 벡터는 모두 파생 상태야. 원본과 어긋나면 원본이 이기고, 인덱스는 버린 뒤 다시 만들면 돼. 서로 진짜라고 주장하는 복사본이 생길 틈이 없어.
검색 엔진만의 규칙이 아니야
캐시와 검색 인덱스, 구체화 뷰, 비정규화 테이블, 썸네일, 컴파일 결과도 같은 범주야. 이들은 중요하지 않다는 뜻이 아니라 다시 만들 수 있다는 뜻이야. 파생임을 분명히 표시하고 두 번째 원본으로 승격시키지 마. 문제가 생겼을 때 수선이 아니라 재구축을 택할 수 있어야 해. Lantern이 원본은 건드리지 않고 인덱스는 과감히 버릴 수 있는 이유도 바로 이 구분에 있어.
백업과 경쟁하는 복사본도 구별해야 해. 백업은 자기 역할이 복구용이고 원본이 따로 있다는 걸 분명히 알고 있어. 반면 두 폴더를 모두 편집하면서 둘 다 진짜라고 부르면 권위가 갈라져. 위험한 것은 복사 행위 자체보다 어느 쪽을 믿어야 하는지 설명할 수 없는 상태야.