터보퍼퍼(turbopuffer)가 자사 검색 엔진의 저장 아키텍처를 전면 재설계하는 작업에 착수했다고 밝혔다. 핵심은 지금까지 모든 설계의 중심이었던 ANN(근사 최근접 이웃) 벡터 인덱스를 더 이상 '주 인덱스(primary index)'로 두지 않겠다는 것이다. 회사는 이 변화를 담은 v3가 텍스트·정규식·벡터 검색 전반을 더 빠르게 만들고, 나아가 더 많은 SQL 질의를 터보퍼퍼 위에서 빠르게 돌릴 토대가 될 것이라고 설명했다.
벡터 전용 DB에서 범용 검색 엔진으로
터보퍼퍼는 서버리스 벡터 데이터베이스(v1)로 출발했다. 오브젝트 스토리지를 원본 저장소(source of truth)로 삼아 비용을 낮추고, NVMe SSD와 메모리로 구성한 계층형 캐시로 성능을 확보하는 방식이었다. 이 절충안은 커서(Cursor), 노션(Notion) 같은 초기 고객을 통해 가치를 검증받았다. 이후 v2에서는 속성 필터링과 BM25 기반 전문 검색(FTS)이 더해졌고, 리니어(Linear)의 동기화 엔진처럼 검색이 아닌 용도로도 쓰이기 시작했다.
문제는 질의 엔진이 이렇게 확장되는 동안 저장 구조는 사실상 그대로였다는 점이다. 초기 설계에서 문서는 ID와 벡터뿐이었고, 벡터는 SPANN에 이어 증분 색인을 지원하는 SPFresh로 군집화됐다. 각 군집에는 ClusterId가, 군집 내 벡터에는 LocalId가 부여되는데 이 둘을 합친 'ANN 주소'가 곧 모든 데이터의 기본 키였다. 속성 필터용 역색인도, FTS의 포스팅 목록도 결국 이 ANN 주소를 가리키도록 설계됐다.
세 가지 발목: 저장·쓰기 증폭과 제한된 벡터화
회사는 벡터 우선 구조가 ANN 검색 자체에는 매우 잘 맞는다고 인정한다. 실제로 단일 인덱스에 1,000억 개 이상의 벡터를 담고 초당 1,000여 건의 질의를 p99 200밀리초로 처리해 왔다. 다만 비(非)벡터 질의에서는 세 가지 한계가 드러났다. 첫째는 저장 증폭이다. 문서 중첩이나 레이트 인터랙션처럼 한 문서를 여러 벡터로 표현하면, 벡터마다 문서 내용을 중복 저장해야 한다. 둘째는 쓰기 증폭이다. 문서가 삽입·수정·삭제될 때 SPFresh가 재현율 유지를 위해 벡터를 재배치하는데, 모든 데이터가 ANN 주소로 묶여 있다 보니 벡터 하나만 옮겨도 수백 개의 속성과 그 색인까지 함께 이동한다. 색인 처리량 튜닝이 한계 효용에 부딪힌 이유다.
셋째는 벡터화의 제약이다. 현대 질의 엔진은 값 블록을 촘촘한 루프로 처리해 SIMD와 CPU 파이프라인을 채운다. 덕DB는 2,048행, 클릭하우스는 약 6만 5,000행, 루씬의 포스팅 블록은 256개 문서 단위로 동작한다. 반면 터보퍼퍼의 ANN 인덱스는 100~200개 문서 군집에서 최적이라, 더 큰 블록을 원하는 질의도 이 크기에 묶여 버린다. 회사는 FTS v1에서 포스팅을 군집 경계로 쪼갰을 때 블록 중앙값이 1.5개에 불과했지만, v2에서 약 256개 고정 블록으로 바꾸자 색인이 10배 작아지고 질의가 최대 20배 빨라졌다는 경험을 근거로 든다. 포스팅은 문서와 분리돼 포인터로만 참조하기에 가능했던 일이다.
해법은 '키를 바꾸는 것'
결론적으로 해법은 단순하다. ANN 주소를 기본 키로 삼지 않는 것, 그것이 v3의 변화다. 벡터 인덱스는 역색인이나 FTS처럼 '또 하나의 보조 인덱스'로 내려오고, 각 질의 계획은 자신에게 맞는 블록 크기를 자유롭게 고를 수 있게 된다. 회사는 이달 초 v3에서 CI를 100% 통과하는 이정표에 도달했으며, 우선 정확성을 확보한 뒤 성능을 끌어올리는 단계라고 밝혔다. 벤치마크는 몇 주에 걸쳐 공개하고, 성능 동등성(parity)을 확보한 뒤 프로덕션에 적용할 계획이다.
실무자 입장에서 이 소식은 몇 가지 시사점을 준다. 벡터 중심으로 설계된 저장 구조가 텍스트·집계·정규식 같은 다른 질의 형태에서는 오히려 비용과 지연을 키울 수 있다는 점, 그리고 블록 크기 같은 저수준 레이아웃 결정이 색인 크기와 질의 속도를 10배, 20배 단위로 좌우한다는 점이다. 다만 현재 공개된 내용은 아키텍처 방향과 CI 통과라는 초기 단계에 머물러 있다. 실제 성능 수치와 기존 ANN 성능의 회귀(regression) 여부는 아직 검증되지 않았고, GROUP BY나 집계 같은 질의가 얼마나 개선될지도 공개될 벤치마크를 기다려 봐야 한다. 1조 개가 넘는 문서와 초당 1,000만 건 이상의 쓰기를 소화한다는 기존 규모를 감안하면, 이 전환이 무리 없이 이뤄지는지 자체가 관전 포인트가 될 전망이다.