"내가 쓴 건 다 어딘가에 있어. 문제는 바로 그 '어딘가'야." — 아빠
글은 쓴 자리마다 남아
Lantern이 태어난 이유는 화려하지 않아. 한 사람이 10년 동안 글을 쓰면 결과물은 한 폴더에 가지런히 쌓이지 않아. 가이드 폴더와 책 프로젝트 셋, 발행한 에세이, 시장 논제를 모은 vault, 원고 디렉토리, 웹사이트 콘텐츠 트리처럼 글을 쓰던 자리마다 남지. 각 장소는 저마다 합리적인 구조를 갖고 있어. 하지만 여섯 곳, 여덟 곳, 열두 곳으로 늘어나면 전체는 가치가 큰데도 사실상 한꺼번에 검색할 수 없는 코퍼스가 돼.
'한 폴더에 모으자'는 답이 왜 틀릴까
가장 먼저 떠오르는 방법은 모든 파일을 ~/all-my-writing/으로 복사하는 거야. 당장은 정리된 듯 보여도 문제가 세 개 생겨.
- 기존 연결이 끊겨. 원래 경로를 가리키던 링크와 import, 빌드 도구는 옮긴 복사본을 모르거든.
- 두 번째 원본이 생겨. 원래 파일을 고치면 모아둔 복사본은 곧 낡아. 둘 중 무엇이 최신인지 판단해야 하는 골칫거리가 생기지.
- 검색 도구 때문에 살아 있는 프로젝트를 바꾸게 돼. 글의 구조가 검색기의 편의에 끌려다니는 꼴이야.
책을 찾기 쉽게 만들겠다고 모든 페이지를 뜯어 한 선반에 올려놓는 것과 같아. 한곳에 모이기는 했지만 책은 망가졌지.
문제는 모으기가 아니라 옮기기야. 전체를 한 번에 찾고 싶다는 목표는 옳아. 틀린 것은 파일을 물리적으로 옮겨야만 모을 수 있다는 생각이야. Lantern은 바이트 하나 옮기지 않고도 코퍼스를 하나로 다루는 길을 택해.
한곳이 필요한 건 파일이 아니라 주소야
Lantern의 답은 간단해. 원본은 지금 사는 곳에 그대로 두고, 레지스트리와 보존 저장소를 코퍼스의 '한곳'으로 삼아. 레지스트리에 글이 어디 있는지 선언하면 엔진은 그 자리를 찾아가 읽고 색인해. 원본을 고치거나 옮기지 않으니 기존 프로젝트도 그대로 작동하고, 권위 있는 파일도 하나뿐이야. 파일들은 자신이 검색되기 시작한 사실조차 모른 채 제 일을 계속해. 다음 트랙에서는 이 작은 선언이 어떻게 실제 수집 체계가 되는지 살펴볼 거야.