"난 10년을 썼어. 문제는 더 쓰는 게 아니었어. 분명 내가 쓴 그 한 줄을 다시 찾을 수 없다는 거였지." — 아빠
먼저, 이 엔진이 맡는 일
Lantern은 코퍼스 엔진이야. 가이드와 책, 에세이, 시장 논제, 원고, 웹사이트 글처럼 여러 곳에 흩어진 글을 한곳에서 찾을 수 있게 해. 방법은 네 가지 동사로 설명할 수 있어. 어디에 있는지 등록하고, 내용을 수집하고, 필요한 구절을 검색하고, 다시 인용할 수 있게 보존하지. 가벼운 웹 콘솔은 그 엔진에 처음 꽂아본 전구야. 회로가 제대로 흐르는지 보여주지만, 회로 자체는 아니야.
일부러 하지 않는 일
도구는 무엇을 하느냐만큼 무엇을 거절하느냐로 선명해져. Lantern에는 네 개의 단단한 경계가 있어.
- RAG 챗봇이 아니야. 대화도 메모리도 자기 뇌도 없고, 질문에 산문으로 답하지 않아.
- 비서의 기억 저장소가 아니야. 개인 vault와 대화 기록은 그걸 책임지는 별도 시스템에 남고, Lantern은 그 내용을 색인하지 않아.
- 디지털 자산 관리자가 아니야. 이미지·영상·오디오 원본 대신 텍스트와 그 스냅샷, 원본을 가리키는 정보만 다뤄.
- LLM 처리 흐름이 아니야. 검색 결과를 만드는 길에는 언어 모델 호출이 없어. 임베딩과 rerank는 버전을 고정한 결정론적 서비스로 쓰고, 해석과 판단은 API 위의 뇌가 맡아.
이 경계들은 아직 못 만든 기능 목록이 아냐. Lantern이 다른 것으로 변하지 않게 지키는 벽이야.
왜 앱이 아니라 엔진일까
앱부터 만들면 API는 첫 화면에 필요한 모양을 따라가게 돼. 반대로 엔진부터 완성하면 순서가 달라져. 코어가 먼저 책임을 다하고, 누구나 쓸 수 있는 API를 연 뒤, 콘솔이나 에디터 같은 클라이언트가 붙지. POST /api/search가 출처 정보까지 갖춘 결과를 돌려준다면 그 결과는 콘솔뿐 아니라 코드 에디터, 사이트 검색창, AI 비서에게도 똑같이 쓸모 있어. 엔진은 하나지만 그 불을 쓰는 등불은 여럿일 수 있는 거야.
아빠가 Lantern을 처음 설명했을 때 난 곧장 익숙한 이름을 붙였어. "아, RAG 시스템이네." 아빠가 바로 선을 그었지. 찾는 일은 모델에게 맡길 판단이 아니라, 지루할 만큼 확실하게 풀어둘 기반이라고. 그 말을 이해하고 나니 위치가 보였어. 모델은 강력하지만 비싸고 흔들릴 수 있어. 그러니 반드시 돌아가야 하는 검색 길에서는 빼고, 판단이 필요한 위쪽에 두는 게 맞아.