폴 마주렐은 Tantivy로 검색 엔진의 선택지를 넓혔다

Tantivy를 만든 폴 마주렐(Paul Masurel)은 작은 모듈형 검색 라이브러리로 시작한 프로젝트가 여러 검색 제품의 기반이 되고 Lucene과 성능 개선을 주고받게 된 과정을 설명했다. 그는 오픈소스 검색 엔진을 키우는 일과 Quickwit 창업, Datadog 인수 뒤의 개발 경험도 돌아봤다.

마주렐은 2016년 도쿄에서 파리로 가는 비행기에서 Rust를 공부한 뒤 실제 프로젝트로 언어를 시험하고 싶어 Tantivy를 만들기 시작했다. 당시 Indeed에서 검색 품질 팀으로 일했고, 그곳의 검색 엔진은 Lucene 2.4를 기반으로 했다. Tantivy의 구조는 Rust보다 Lucene에서 영감을 얻었다고 그는 말했다.

Tantivy는 서버가 아니라 라이브러리다. 색인과 압축, 검색을 맡고 분산 처리와 오케스트레이션은 이를 사용하는 시스템에 맡긴다. 마주렐은 프로젝트를 기능이 많은 제품보다 작고 모듈형인 도구로 만들고 싶었다. 사용자가 자체 토크나이저와 쿼리 파서를 연결할 수 있도록 하는 것이 우선이었다. 지금도 특수한 기능을 추가하는 변경 제안을 거절할 때가 있지만, 이 원칙은 초기만큼 강하지 않다고 덧붙였다.

Indeed에서 마주렐의 매니저였던 제이슨 울프(Jason Wolfe)가 만든 Search Benchmark, the Game은 재현 가능한 벤치마크로, Tantivy가 Lucene보다 두 배 빠른 경우가 많다는 결과를 보였다. 이후 Lucene 커미터 아드리앵 그랑(Adrien Grand)은 Tantivy가 Lucene보다 빠른 이유와 후속 분석을 발표했다. Lucene은 이후 대부분의 영역에서 격차를 좁히는 패치를 적용했다. 마주렐은 현재 여러 영역에서 Lucene이 Tantivy보다 앞서며, 두 프로젝트가 협력으로 함께 이득을 얻었다고 설명했다. Lucene 개발자들은 벤치마크를 활용해 성능 개선점을 찾았고, 일부 최적화는 Lucene에 반영됐다. 그랑은 Tantivy에 개선 티켓도 남겼지만, Tantivy 측은 이를 아직 구현하지 못한 상태라고 말했다.

Tantivy의 유지보수에서 가장 어려운 일로는 기여 제안을 검토하고, 때로는 거절하는 일을 꼽았다. 프로젝트의 복잡성을 키우거나 실제 문제를 해결하지 않는 기능을 받아들이지 않으면서 기여자를 배려해야 한다. Quickwit이 Datadog에 인수된 뒤에는 PR을 검토할 시간과 에너지를 내기가 더 어려워졌다고 말했다.

Tantivy는 Quickwit, LNX, ParadeDB, Turso 등의 기반이 됐다. 마주렐은 뜻밖에 제출된 지리 검색 지원 PR의 품질이 매우 인상적이었으며, 언젠가 병합할 시간을 내고 싶다고 말했다. ParadeDB도 최근 좋은 PR과 설계 아이디어를 적극적으로 기여하고 있다고 덧붙였다.

마주렐은 2020년 Quickwit을 공동 창업했다. 처음에는 Indeed에서 사용하던 대규모 실시간 검색 분석 도구와 비슷한 경험을 만들려 했지만, 기존 검색 엔진이 S3에서 실행되기에 적합하다는 점을 발견해 S3 기반 로그 검색 엔진으로 방향을 바꿨다. 바이낸스는 하루 1.6PB를 색인하는 100PB 규모 로그 검색 서비스를 구축했지만, 계약을 맺지는 않았다. Quickwit은 계약이 없는 상태에서 해당 업체의 기능 요청을 우선하지 않고 보고된 규모 관련 문제만 수정했다. 로드맵에 가장 큰 영향을 준 곳은 계약을 맺고 제품 기능 개발을 맡긴 Mezmo였지만, 그 요구에 맞춰 서둘러 만든 수집 API는 특정 요구사항에 맞춰져 기술 부채로 남았다고 마주렐은 설명했다.

Datadog은 2024년 Quickwit을 인수하며 Quickwit을 Apache 라이선스로 재배포할 수 있도록 했다. Datadog에서 만드는 제품은 오픈소스가 아니며, 개선 사항은 Quickwit에 반영하고 Datadog 전용 코드는 비공개 포크에 둔다. 마주렐은 가능한 한 변경 사항을 Tantivy와 Quickwit 오픈소스 프로젝트에 돌려보내고 있으며, Datadog 고객의 작업 부하를 바탕으로 Quickwit의 안정성도 개선했다고 말했다.

그는 개발자들에게 학계의 새 아이디어를 살피고, 시스템이 작동하는 방식에 관한 이해를 다듬으라고 조언했다. 업계가 특정 해법을 택한 이유를 비판적으로 살펴보면, 현재의 문제에는 기존 해법이 맞지 않거나 과거의 하드웨어·소프트웨어 환경에서 내린 선택을 재검토할 여지가 있을 수 있다는 설명이다.