3개월 전 블로그 #02에서 TurboQuant를 다뤘다. 구글이 ICLR 2026에서 낸 양자화 기법으로, LLM의 KV 캐시를 16비트에서 3비트로 줄이면서 정확도 손실은 0이었다. 그때 글 끝에 이렇게 썼다 — “TurboQuant의 진짜 의미는 더 적은 자원이 아니라, 같은 자원으로 이전에는 불가능했던 것을 가능하게 만든다는 데 있다.”
그 예언이 내가 예상한 곳이 아니라 엉뚱한 데서 현실이 됐다. 똑같은 수학이 모델 안(KV 캐시)이 아니라 모델 밖(RAG 벡터 검색)으로 건너온 것이다. 그게 이번 달 깃허브에서 빠르게 별을 모으고 있는 TurboVec다. 1천만 개 벡터를 4GB에, 학습 단계 없이, 로컬에서 굴린다.
이번 글은 세 가지를 본다. 왜 지금 핫한지, 원천 기술이 무엇인지(이미 #02에서 절반은 봤다), 앞으로 어디로 갈지. 그리고 까보면서 뭘 배울 수 있었는지.
왜 지금 TurboVec가 핫한가 — “학습이 없다”
벤치마크 숫자(FAISS보다 ARM에서 12~20% 빠름)가 헤드라인을 장식했지만, 별이 모이는 진짜 이유는 속도가 아니다.
FAISS로 PQ(Product Quantization) 인덱스를 운영해본 사람은 안다. 압축률을 얻으려면 먼저 코드북을 학습(train)해야 한다. 데이터 분포에 맞춰 k-means를 돌리고, 파라미터를 튜닝하고, 코퍼스가 커지면 다시 빌드한다. 검색 자체보다 이 운영 사이클이 고통이다. 새 문서 1만 개가 들어올 때마다 “이거 리빌드해야 하나”를 고민하게 된다.
TurboVec(정확히는 그 바탕인 TurboQuant)는 이 사이클을 통째로 없앤다.
- 학습 단계가 없다. 코드북을 데이터에서 배우지 않는다.
- 온라인 인제스트. 벡터를 그냥 추가하면 즉시 인덱싱된다. 파라미터 튜닝도, 리빌드도 없다.
- 로컬에서 끝난다. 매니지드 벡터 DB도, 데이터가 VPC를 벗어나는 일도 없다.
별이 빠르게 붙는 건 “FAISS보다 15% 빠르다”여서가 아니다. “train 단계를 영원히 안 봐도 된다”여서다. 사람들이 진짜 원한 건 더 빠른 검색이 아니라 운영에서 통째로 사라지는 한 단계였다. 1천만 벡터가 노트북 메모리(4GB)에 들어간다는 것도 같은 이야기 — 매니지드 서비스 없이 RAG를 손 안에서 끝낼 수 있다는 뜻이다.
원천 기술은 이미 본 적 있다 — TurboQuant의 “데이터를 보지 않는” 양자화
여기가 핵심인데, 절반은 #02에서 이미 정리했다. 그때 KV 캐시 관점에서 본 그 수학을, 이번엔 벡터 검색 관점에서 다시 본다.
보통의 양자화는 데이터를 보고 코드북을 만든다(k-means처럼). TurboQuant는 정반대다 — 데이터를 아예 보지 않는다(data-oblivious). 절차는 이렇다.
- 벡터를 정규화해 단위 구(球) 위의 방향으로 만든다.
- 무작위 회전을 가한다. 그러면 좌표들이 데이터와 무관하게 예측 가능한 베타(Beta) 분포를 따른다.
- 그 알려진 분포에 대해 미리 계산해둔 Lloyd-Max 최적 경계로 양자화한다. (2비트면 버킷 4개, 4비트면 16개)
- 길이 보정 항을 따로 저장해 내적을 편향 없이 복원한다.
핵심은 3번이다. 코드북이 데이터가 아니라 수학(베타 분포)에서 나온다. 그래서 학습이 필요 없고, 이론적으로도 섀넌의 왜곡-율 한계의 약 2.7배 안에 든다. 1536차원 벡터가 6,144바이트(FP32)에서 384바이트(2비트)로 — 16배 압축이 여기서 나온다.
그리고 바로 이 “데이터를 보지 않는다”는 성질이 용도를 갈아타게 만든 열쇠다. #02에서 다룬 TurboQuant는 LLM 추론의 KV 캐시 압축용이었다 — 모델 안. TurboVec는 똑같은 양자화를 RAG 벡터 인덱스에 붙였다 — 모델 밖. 완전히 다른 용도인데도 옮겨갈 수 있었던 건, 코드북이 KV 캐시 데이터에 묶여 있지 않았기 때문이다. 분포에서 나오는 수학이라, 1536차원 임베딩에도 그대로 작동한다.
계보로 보면 이렇다.
QJL (AAAI 2025) → PolarQuant (AISTATS 2026) → TurboQuant (ICLR 2026 — #02에서 다룬, KV 캐시용) → TurboVec (커뮤니티 OSS — RAG 검색으로 재용도화)
참고로 TurboVec 자체는 구글이 아니라 한 개발자가 그 논문 위에 올려 만든 오픈소스다. 그런데 이건 흠이 아니라 #02에서 본 흐름의 연장이다 — 그때도 구글이 공식 코드를 내기 전에 llama.cpp·MLX·CUDA 구현이 24시간 만에 쏟아졌다. 논문이 나오면 며칠 만에 커뮤니티가 제품으로 만든다. TurboVec는 그 패턴이 RAG 쪽에서 한 번 더 일어난 사례다.
까보니 좋았던 점 — 배울 만한 “정직함”
도구를 평가할 때 나는 README보다 코드를, 그림보다 동작을 본다. 이번엔 반대로 README가 기대 이상으로 정직해서 인상적이었다.
벤치마크 표에 FAISS보다 밀리는 경우까지 적어놨다. OpenAI 임베딩(d=1536/3072)에선 FAISS를 앞서지만, 저차원 GloVe(d=200) 2비트에선 FAISS에 1.2점 뒤진다고 — “저차원에선 베타 분포 가정이 느슨해진다”는 이유까지 붙여서. x86의 일부 2비트 구성은 FAISS보다 2~4% 느리다고 적고, 비교 대상도 “FAISS의 강한 베이스라인”이라 자기에게 불리한 조건임을 밝힌다.
이건 도구를 깎으려고 짚는 게 아니다. 거꾸로다 — 자기 한계를 정확히 적어둔 README가 오히려 신뢰를 준다. “어디서 쓰면 좋고 어디서 쓰면 안 되는지”를 사용자가 바로 판단할 수 있기 때문이다. 내가 뭔가를 공개할 때도 가져가고 싶은 태도다.
언제 쓰면 좋은가 Apple Silicon(ARM)에서 로컬 RAG를 돌리고, 코퍼스가 계속 자라 리빌드가 부담일 때.
pip install turbovec한 줄이고, 고차원 OpenAI 임베딩이면 2~4비트에서 FAISS와 비슷하거나 더 낫다. 단 저차원(d≈200)·2비트 조합은 피하라 — 레포가 직접 더 약하다고 밝혀둔 경우다.
앞으로 어떻게 될까
#02에서 제본스 패러독스(효율이 좋아지면 소비가 주는 게 아니라 접근자가 늘어 총수요가 폭증한다)를 꺼냈는데, 그 논리가 RAG에도 그대로 적용된다.
1천만 벡터가 노트북 4GB에 들어가고 학습 단계가 사라지면, “벡터 DB를 아껴 쓰자”가 아니라 “RAG를 어디에나 기본으로 깔자”로 간다. 몇 가지 방향이 보인다.
- 매니지드 벡터 DB 수요의 일부가 로컬로 빠진다. 학습·튜닝·스케일링을 대신 해주던 가치가 약해진다. “벡터 검색은 그냥 라이브러리 한 줄”로 끝나는 영역이 넓어진다.
- 온프렘·프라이버시 민감 도메인이 열린다. 데이터가 기기 밖으로 안 나가도 되니, 규제 강한 영역(금융·의료·공공, 그리고 내가 ISMS-P 사례에서 다룬 고위험 도메인)에서 RAG 채택 문턱이 낮아진다.
- 임베딩 압축이 ‘표준 레이어’가 된다. #18 헤드룸이 컨텍스트 압축을 모델 앞단의 기본 레이어로 만들었듯, 벡터 압축도 RAG 파이프라인의 당연한 한 칸이 될 것이다.
그리고 더 큰 그림 — data-oblivious라는 성질은 다음엔 또 어디로 샐까. KV 캐시(#02) → 벡터 검색(#20)으로 왔다. 이미지·멀티모달 임베딩, 추천 시스템의 아이템 벡터, 온디바이스 검색… 데이터에 묶이지 않는 수학은 도메인을 계속 넘는다.
그래서 무엇을 배우나
① 데이터에 맞추지 말고, 수학으로 풀면 전이된다. TurboQuant가 KV 캐시에서 벡터 검색으로 건너간 건 우연이 아니라 data-oblivious의 필연이다. 데이터 분포에 코드북을 맞추는 대신 “분포가 어차피 베타를 따른다”는 수학으로 풀었더니, 학습이 사라지고 용도까지 넘었다. 문제를 풀 때 데이터에 의존하는 해법과 구조에 기대는 해법을 구분하는 눈 — 후자가 훨씬 멀리 간다.
② “이 기술이 다음엔 어디로 샐까”를 묻는 습관. 같은 논문을 #02에선 KV 캐시로, #20에선 RAG로 본다. 좋은 원천 기술 하나를 보면 “이건 무슨 문제를 풀려고 나왔나” 옆에 “이 성질이 또 어디에 쓰일 수 있나”를 같이 적어두면, 남보다 한 박자 먼저 움직일 수 있다. 종종 후자가 더 큰 시장이다.
③ 정직한 한계 표기가 경쟁력이다. TurboVec의 README는 자기가 약한 부분을 숨기지 않아서 오히려 믿을 만했다. 내가 만들고 공개하는 것에도 똑같이 적용된다 — 잘하는 것만큼 못하는 부분을 분명히 밝히는 게 신뢰의 지름길이다.
마치며
처음엔 “1천만 벡터를 4GB에 넣는다”는 게 진짜인지 확인하려 했다. 진짜였다. 그런데 까보고 나니 더 오래 남는 건 다른 그림이었다.
3개월 전 KV 캐시를 줄이던 그 수학이, 데이터에 의존하지 않는다는 성질 하나 때문에 RAG를 통째로 노트북에 집어넣는 도구로 다시 태어났다. 모델 안을 위한 압축과 모델 밖을 위한 압축이 같은 수학을 공유하기 시작했고, 그 사이를 잇는 건 거대 연구소가 아니라 며칠 만에 움직이는 커뮤니티였다.
#02 끝에 “같은 자원으로 불가능을 가능하게”라고 썼던 예언은 맞았다. 이번엔 한 줄 더 적어둔다 — 좋은 수학은 한 번 쓰이고 끝나지 않는다. 성질이 좋으면, 그게 다음 자리를 스스로 찾아간다. 그걸 먼저 알아보는 게, 내가 이 도구들을 계속 까보는 이유다.
참고 자료
- TurboVec (RyanCodrai/turbovec) — TurboQuant 기반 Rust 벡터 인덱스 (Python 바인딩, MIT)
- TurboQuant — Google Research 블로그 · 논문 (arXiv)
- 관련 글: TurboQuant — KV 캐시 3비트 압축 (블로그 #02) · 넷플릭스 엔지니어의 Headroom을 까보고 · 검색은 더 이상 사람을 위한 게 아니다