우리가 코드 검색을 voyage-4-large로 업그레이드한 이유

이 글의 벤치마크 수치는 게시 시점(2026년 6월)의 RTEB 리더보드를 반영합니다. 리더보드는 계속 바뀌므로, 순위는 영구적인 사실이 아니라 특정 시점의 스냅샷으로 받아들이세요.

시맨틱 검색은 그 밑에 깔린 임베딩만큼만 좋습니다.

에이전트가 Maguyva에게 “우리가 재시도를 어디서 처리하나”라고 물을 때, 이는 “retry”라는 단어를 grep하는 것이 아닙니다. 의미를 묻는 것입니다. 백오프 루프, 서킷 브레이커, 불안정한 호출을 감싸는 그 무언가를요. 이 질문은 코드를 공간 속의 한 점으로 바꾸고 이웃을 찾는 벡터 모델이 답합니다. 더 나은 모델을 고르면, 제품 안의 모든 시맨틱 쿼리가 조용히 더 날카로워집니다.

그래서 우리는 우리 것을 바꿨습니다. 2026년 6월 기준, Maguyva의 코드 임베딩은 voyage-code-3을 대체한 voyage-4-large 위에서 실행됩니다.

벤치마크

우리는 이 결정을 감으로 내리지 않았습니다. 공개된 검색 임베딩 벤치마크(RTEB)는 실제 검색 작업으로 임베딩 모델의 순위를 매기는데, Code 리더보드에서 voyage-4-large는 **전체 1위(90.86)**를 차지하고 있습니다. gemini-embedding-2-preview(90.26)보다 앞서고, 특히 우리가 이미 사용하고 있던 모델인 voyage-code-3(89.73, 3위)보다도 앞섭니다.

절대적인 차이는 작습니다. 하지만 이는 공개된 벤치마크에서, 우리가 신경 쓰는 바로 그 작업 — 의미로 코드를 검색하는 것 — 에서 올바른 방향으로의 차이입니다.

우리가 받아들이는 트레이드오프: 바이너리 양자화

대부분의 “우리는 모델을 업그레이드했다”는 글이 빠뜨리는 부분이 여기 있습니다.

Maguyva는 완전 정밀도(full-precision) 벡터를 저장하지 않습니다. 우리는 바이너리 양자화된 임베딩을 저장합니다. 2048차원 벡터 각각은 2048비트 시그니처로 압축됩니다. 벡터당 256바이트입니다. 이 시그니처들은 해밍 거리(Hamming distance)로 검색되며, 테넌트별로 인덱싱되고 파티셔닝됩니다.

이는 의도적인 트레이드오프입니다. 바이너리 양자화는 별도의 벡터 데이터베이스를 운영할 필요 없이 극적으로 작아진 저장 공간과 빠르고 저렴한 거리 계산을 대가로 일부 검색 정밀도를 포기합니다. 워크스페이스마다 전체 저장소를 인덱싱하는 제품에게는, 벤치마크 점수의 마지막 소수점을 짜내는 것보다 이 경제성이 더 중요합니다.

voyage-4-large는 저장 레이어의 마이그레이션을 강제하지 않고도 이 설계에 들어맞습니다. voyage-code-3과 동일하게 2048차원 출력을 만들어내므로, 우리의 bit(2048) 컬럼과 해밍 검색 경로는 바뀌지 않았습니다. 모델은 좋아졌지만, 스키마는 그대로 남았습니다.

코드는 시작에 불과했다

Maguyva는 코드 인텔리전스 도구입니다. 하지만 우리는 스스로도 첫 번째 고객이며, 이를 다른 것에도 겨냥합니다. 코드와 나란히 우리 저장소에 존재하는 마크다운 말이죠. 아키텍처 결정 기록, 런북, 계약서, 재무 및 정책 문서 — 이 모든 것이 Git으로 버전 관리되고, 모두 동일한 MCP 서버 뒤에 있으며, 소스 코드뿐 아니라 문서 전체에 걸친 시맨틱 인덱스입니다.

바로 이것이 voyage-4-large의 폭넓음이 중요한 이유입니다. 동일한 RTEB 계열의 리더보드에서 이 모델은 재무 1위, 헬스케어 1위, 전체 텍스트 검색 1위입니다. Google의 Gemini Embedding, Cohere의 Embed v4, OpenAI의 text-embedding-3-large보다 앞섭니다. (Voyage는 RTEB의 공동 제작자이므로, 우리는 이를 완벽하게 중립적인 심판이라기보다는 강력한 공개 신호로 받아들입니다. 하지만 이는 비공개 홀드아웃 세트에서 모든 주요 상용 모델과 정면으로 벤치마크된 것입니다.) 에이전트를 위해 올바른 함수를 찾아주는 것과 동일한 인덱스가 계약서의 올바른 조항이나 정책의 올바른 문구를 찾아줍니다. 그리고 그 도메인들에서 voyage-4-large는 타협이 아니라 선두주자입니다.

우리가 프리미엄 임베딩에 비용을 지불하는 이유

검색을 하는 더 저렴한 방법이 있고, 그중 상당수는 무료입니다. BM25와 그 친척들 같은 렉시컬 검색은 키워드를 매칭하고, 로컬에서 실행되며, 비용이 들지 않습니다. BGE, Nomic, embeddinggemma 같은 오픈소스 임베딩 모델은 진짜로 괜찮은 시맨틱 검색을 제공하고, GPU 한 대 값으로 직접 호스팅할 수 있습니다. Maguyva도 무료인 쪽을 사용합니다. 모든 쿼리는 텍스트, AST, 그래프, 시맨틱 검색을 융합합니다. 우리가 아끼지 않는 부분은 시맨틱 레이어입니다.

우리는 무료 모델을 직접 호스팅하는 대신 프리미엄 임베딩인 voyage-4-large에 토큰당 비용을 지불하는데, 여기에는 두 가지 이유가 있습니다. 첫째, 코드가 “retry”라는 단어를 한 번도 쓰지 않고 backoff와 circuit breaker라고 말할 때, 키워드 검색만으로는 “우리가 재시도를 어디서 처리하나”에 답할 수 없습니다. 의미야말로 임베딩의 존재 이유이며, 우리가 다루는 도메인에서 오픈 모델은 프리미엄 모델에 뒤처집니다. 일반 텍스트에서는 몇 점 뒤처지고, 코드, 계약서, 재무 같은 틈새 영역에서는 더 크게 뒤처집니다. 둘째, 우리 경험상 검색 품질은 반대편의 모델보다 더 크게 최종 답변을 좌우합니다. 강력한 에이전트라도 잘못된 컨텍스트를 받으면 여전히 틀린 답을 하고, 애초에 주어지지 않은 문서는 절대 보지 못합니다.

그래서 프리미엄 임베딩은 우리가 인덱싱하는 모든 저장소와 문서에 비례해 늘어나는 토큰당 청구서이고, 우리는 이를 의도적으로 지불합니다. 사용자가 얻는 결과 — 올바른 함수 혹은 올바른 조항 — 를 위해서라면, 우리는 이 트레이드오프가 그럴 만한 가치가 있다고 생각합니다.

솔직한 부분

Voyage 자체 문서는 여전히 voyage-code-3을 코드 최적화 모델로 표시하고 있습니다. 그렇다면 왜 옮겼을까요?

우리가 벤더의 모델 표만이 아니라 공개 벤치마크를 읽었기 때문이고, 그 벤치마크가 코드 검색에서 voyage-4-large를 1위에 올려놓았기 때문입니다. 이는 미래를 내다보는 결정이었습니다. 더 새롭고 대체로 더 강력한 모델을 골라, 중요한 작업들에 대한 공개 리더보드로 그것을 검증하는 것입니다. 우리가 그 베팅을 편하게 할 수 있는 이유는 근거가 폭넓기 때문입니다. voyage-4-large는 코드에서만 이기는 것이 아니라, 재무, 헬스케어, 전체 검색에서도 선두를 달립니다.

조용한 바닥

시맨틱 검색, 태스크 컨텍스트 수집, 근거 기반 Q&A까지, 우리가 노출하는 모든 도구는 결국 검색으로 귀결됩니다. 검색기가 개선되면, 반대편의 에이전트는 더 나은 근거를 얻고, 잘못된 방향으로 덜 빠지며, 자신의 답을 올바른 코드에 — 혹은 올바른 조항이나 올바른 정책에 — 근거하게 됩니다. 더 날카로운 임베딩 모델은 화려한 기능이 아닙니다. 다른 모든 것 아래에 있는 바닥이며, 우리는 그것을 방금 끌어올렸습니다. 여러분은 눈치채지 못할 것입니다. 그것이 핵심입니다.