AI 생성 이미지
RAG에서 비용이 드는 곳은 LLM 호출만이 아닙니다. 문서를 임베딩으로 바꾼 뒤에는, 질의가 들어올 때마다 고차원 벡터끼리의 유사도를 계산해야 합니다. 예를 들어 OpenAI 임베딩에서 흔히 볼 수 있는 1,536차원 벡터 1만 개를 검색하면, 쿼리 한 번에 약 1,500만 번의 부동소수점 곱셈이 필요합니다.1
코사인 유사도 자체는 어렵지 않습니다. 두 벡터의 내적을 두 벡터 노름의 곱으로 나누면 됩니다.1 문제는 이 계산이 벡터 수와 차원 수에 따라 빠르게 커진다는 점입니다. 순수 JavaScript 기반 벡터 검색이 10만 개 벡터에서 1.5초 이상 걸릴 수 있다는 사례도 같은 맥락에서 이해할 수 있습니다.1
이 병목을 줄이기 위해 등장한 선택지 중 하나가 Turbovec입니다.
Turbovec은 무엇인가
Turbovec은 Rust 기반 벡터 인덱스이며, Python 바인딩을 제공합니다. Google Research의 TurboQuant 알고리즘을 기반으로 하며, 벡터 검색에 사용됩니다.2
핵심 아이디어는 임베딩을 float32 그대로 저장하지 않고, 2~4비트 수준으로 양자화해 검색 가능한 형태로 압축하는 것입니다. 프로젝트 설명에 따르면 1,000만 문서 임베딩은 float32 기준 약 31GB가 필요하지만, turbovec은 이를 4GB에 담을 수 있다고 설명합니다.2
따라서 Turbovec은 단순히 “벡터를 찾는 라이브러리”라기보다, 메모리 사용량을 줄이면서 벡터 검색을 실행하기 위한 인덱스에 가깝습니다.
왜 이 접근이 의미 있는가
벡터 검색에서는 정확도, 속도, 메모리 사용량 사이의 균형이 중요합니다. 데이터가 작을 때는 단순 계산으로도 충분할 수 있지만, 벡터 수가 늘어나면 저장 비용과 검색 시간이 함께 커집니다.
기존 PQ 방식은 보통 코드북 학습이 필요합니다. 데이터가 추가되거나 바뀌면 재학습과 재빌드가 운영 부담이 될 수 있습니다. Turbovec이 내세우는 장점은 코드북 학습 없이 벡터를 추가하면 바로 인덱싱된다는 점입니다.2
이 차이는 로컬 RAG나 사내 검색처럼 데이터가 계속 변하는 환경에서 특히 중요합니다. 문서를 외부 서버로 보내지 않는 프라이버시 우선 RAG 앱에서는 브라우저 내 벡터 검색이 활용될 수 있고, 클라이언트 측 임베딩에는 Transformers.js 같은 도구를 사용할 수 있습니다.1 Turbovec 자체가 브라우저용 도구라는 뜻은 아니지만, “데이터를 밖으로 내보내지 않고 검색한다”는 문제의식과 맞닿아 있습니다.
실제 도입 전에 확인할 점
Turbovec은 필터 검색도 지원합니다. SQL, BM25, 권한 조건 등으로 후보 ID를 먼저 좁힌 뒤, 허용된 집합 안에서만 벡터 검색을 수행할 수 있습니다.2 실제 서비스에서는 단순히 “가장 가까운 문서”를 찾는 것보다 “사용자가 볼 수 있는 문서 중 가장 가까운 문서”를 찾는 일이 더 중요할 때가 많습니다.
다만 압축 기반 인덱스는 항상 트레이드오프를 동반합니다. 메모리 사용량을 줄이는 대신 정확도나 검색 특성이 달라질 수 있으므로, 벤치마크는 반드시 자신의 데이터와 질의 패턴으로 확인해야 합니다.
정리하면, Turbovec은 다음 조건에서 검토할 만합니다.
벡터 수가 많아 메모리 사용량이 부담된다.
로컬 또는 사내 환경에서 벡터 검색을 운영하고 싶다.
데이터 추가가 잦아 인덱싱 부담을 줄이고 싶다.
권한 조건이나 필터링과 함께 벡터 검색을 수행해야 한다.
반대로 데이터 규모가 작거나, 정확도 검증 없이 압축 인덱스를 바로 적용하려는 경우에는 신중해야 합니다. Turbovec의 가치는 “무조건 더 빠른 검색”이 아니라, 제한된 메모리 안에서 벡터 검색을 실용적으로 운영할 수 있게 해주는 것에 있습니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.