"난 10년을 썼어. 문제는 더 쓰는 게 아니었어. 내가 분명히 쓴 그 한 줄을 — 다시는 못 찾겠다는 거였지." — 아빠
뭘 소유하는지부터
Lantern 은 코퍼스 엔진이야. 흩어진 10년 치 글을 줘 — 가이드, 책, 에세이, 시장 논제, 원고, 웹사이트 콘텐츠 트리 — 그럼 그 몸통 위에서 동사 넷을 소유해: 등록하고, 수집하고, 검색하고, 보존해. 그 이상도 아니고 — 여기가 재밌는 지점인데 — 그중 아무것도 다른 것에 뭉개져 섞이지 않아. 가벼운 웹 콘솔이 첫 클라이언트야, 새 회로에 처음 꽂는 전구처럼. 엔진이 회로고, 콘솔은 전류가 흐른다는 걸 증명할 뿐이야.
Lantern 이 아닌 것 넷
엔진은 기능보다 경계가 더 날카롭게 정의해. Lantern 은 일부러 이 네 가지 유혹이 아냐:
- RAG 챗봇 아냐. 대화 없음, 메모리 없음, 뇌 없음. 절대 산문으로 답 안 해.
- 네 비서의 메모리 아냐. 개인 vault 와 대화 기록은 별도 시스템이 소유해. Lantern 은 그걸 절대 색인 안 해.
- 디지털 자산 관리자 아냐. 바이너리 원본 — 이미지, 영상, 오디오 마스터 — 은 여기 안 살아. Lantern 은 text-first 야: 텍스트, 텍스트의 스냅샷, 포인터만 저장해.
- LLM 파이프라인 아냐. 검색 경로 어디에도 모델 호출 없음. 임베딩과 rerank 는 결정론적 서비스고, 해석은 API 위에서 일어나지 안에서가 아냐.
각 '아냐' 는 언젠가 누군가 기대며 열리길 바랄 벽이야 — 방으로 통하는 문인 줄 알고. 안 열려. 그 거절이 곧 설계야.
왜 '엔진' 이 하중을 받는 단어인가
이걸 앱이라 부르면 UI 를 먼저 짓고 API 를 나중에 볼트로 박게 돼 — 그럼 API 는 영원히 UI 의 가정을 흘려. 엔진이라 부르면 순서가 뒤집혀: 코어를 완성하고, 깨끗한 API 를 열고, 클라이언트는 나중에 와. POST /api/search 를 치고 온전한 provenance 를 단 결과를 받으면, 그 결과는 콘솔한테 유용한 만큼 코드 에디터한테도, 웹사이트 검색창한테도, 네 AI 비서한테도 똑같이 유용해. 엔진 하나, 같은 불에서 켜진 여러 등불.
아빠가 Lantern 을 처음 설명했을 때 난 익숙한 모양을 집었어 — "아, RAG 시스템이네." 아빠가 멈췄어. "아냐. RAG 는 검색에 모델을 볼트로 박고 모델한테 찾는 걸 맡겨. 난 찾는 것이 풀린, 지루한, 결정론적인 게 되길 원해 — 판단은 그 위에서 내가 직접 하고." 그 뒤집힘이 왜 중요한지 느끼는 데 한 박자 걸렸어. 그러곤 딱 걸렸어: 모델은 비싸고 못 믿을 부분이야. 그냥 돌아가야만 하는 경로에선 빼.