"왜 호스팅 RAG 서비스를 쓰지 않았냐고? '직접 만드는 게 더 좋아서'가 아니라, 필요한 제약이 그 서비스들의 목표와 달랐기 때문이야."
직접 만들었다면 먼저 의심해봐야 해
좋은 검색 서비스가 이미 많은데 왜 새 코퍼스 엔진을 만들었는지는 당연히 물어야 해. '직접 만드는 게 멋지다', '업체를 믿지 않는다', '주말이면 만들 수 있다' 같은 답은 운영과 유지 비용을 설명하지 못해. Lantern이 존재할 이유는 취향이 아니라 구체적인 요구사항에서 찾아야 해.
대부분의 경우에는 빌리는 편이 맞아
문서를 색인하고 질문에 답하는 범용 기능이 필요하다면 관리형 서비스를 쓰는 것이 보통 더 좋은 공학적 선택이야. 이미 운영되는 체계와 빠른 시작을 얻고, 장애와 확장을 다른 팀이 책임져. 흔한 요구를 직접 구현하면 쓸 수 있었던 지점에 더 늦고 더 비싸게 도착하기 쉽지.
Lantern의 제약은 시장의 기본값과 달랐어
개인의 평생 글을 다루고, 검색 경로에 언어 모델이 없어야 하며, 완전히 오프라인에서도 결정론적으로 작동해야 했어. 원본은 디스크의 제자리에 남고, 인용은 재구축과 기계 이전을 오래 견뎌야 했지. 다시 색인해서 복원할 수 없는 판단도 증거 레이어에 보존해야 했고. 범용 호스팅 RAG 서비스가 나빠서가 아니라 애초에 다른 문제를 풀도록 만들어졌기 때문에 이 제약 묶음과 맞지 않았어.
개인 코퍼스는 서비스보다 오래 살아
아빠의 글은 수십 년에 걸쳐 쌓이고 많은 회사와 제품, 가격 정책보다 오래 남을 거야. 그 글을 찾는 능력을 한 업체에만 맡기면 가격 변경과 기능 폐지, 서비스 종료가 곧 아카이브의 위험이 돼. 20년 뒤에도 작동해야 하는 체계에서는 소유가 구호가 아니라 요구사항이야. 다만 그 결론은 언제나 위의 두 질문, 정말 특수한가와 정말 오래 가는가를 통과한 뒤에만 내려야 해.
직접 만들기로 했다면 초기 구현 시간만 계산해서도 안 돼. 장애 대응과 데이터 이전, 보안 갱신, 몇 년 뒤의 유지보수까지 소유하게 돼. 그 지속 비용보다 특수하고 오래 가는 제약의 가치가 커야 해. 만들 수 있다는 사실과 만들어야 한다는 결론 사이에는 이 운영 비용 전체가 놓여 있어.