임베딩 모델 고르기, API·오픈소스 비용과 차원별 저장 용량 비교

RAG 나 의미 검색을 붙이려고 임베딩 모델을 고르다 보면 리더보드 점수와 100만 토큰당 단가부터 비교하게 돼요. 그런데 계산해 보면 임베딩 호출비는 전체 비용에서 가장 작은 항목인 경우가 많아요. 한국어 문서 100만 청크(4억 토큰)를 한 번 색인하는 비용은 2026년 10월 공식 가격표 기준으로 8~80달러예요. 그보다 큰 돈은 벡터를 몇 차원·어떤 자료형으로 저장하느냐(메모리), 상위 문서를 다시 매기는 재정렬(리랭커)에서 나가요.

그래서 이 글은 원리 대신 고를 때 정해야 하는 다섯 가지를 숫자로 다뤄요. API 와 직접 띄우는 오픈소스 중 무엇을 쓸지, 차원을 몇으로 줄일지, 양자화를 할지, 리랭커를 붙일지, 모델을 바꿀 때 무엇이 깨지는지예요. 단가는 OpenAI·Google·Voyage AI 의 공식 가격표를 2026년 10월 27일에 열어 확인한 값만 썼어요.

임베딩 비용은 어디서 나가나 — 네 군데로 나눠 보기

임베딩을 붙인 검색 한 번에는 돈과 시간이 드는 자리가 네 군데 있어요. 어디가 큰지 먼저 갈라 놓아야 모델 비교가 의미 있어요.

표에서 보듯 모델 단가가 직접 곱해지는 건 위 두 줄이고, 그 둘은 생각보다 작아요. 차원은 셋째 줄을, 리랭커는 넷째 줄을 정해요. 차원 선택이 단가 선택보다 중요한 이유가 여기 있어요.

2026년 10월 임베딩 API 가격 비교 — OpenAI·Gemini·Voyage

아래는 텍스트 입력 100만 토큰당 표준 요금이에요. OpenAI 가격표, Gemini API 가격표, Voyage AI 가격표에서 옮겼어요.

차원·입력 길이는 OpenAI 임베딩 가이드, Gemini 임베딩 문서, Voyage 텍스트 임베딩 문서 기준이에요. Voyage 의 4세대 모델은 계정당 처음 2억 토큰이 무료이고, 배치 API 는 33% 할인이지만 무료 토큰은 배치에 적용되지 않는다고 적혀 있어요. Gemini Embedding 2 는 텍스트 말고도 이미지·음성·영상·PDF 를 같은 공간에 넣는 멀티모달 모델이라, 텍스트만 쓴다면 단가가 높은 편이에요.

토큰 수는 모델마다 다르게 세요. OpenAI 가이드는 3세대 임베딩 모델에 cl100k_base 인코딩을 쓰라고 적어 두었는데, 한국어 LLM 토큰 비용 비교에서 잰 예문 기준으로 이 인코딩은 한국어 1,000자당 약 872토큰이었어요. 아래 계산은 비교를 위해 모든 모델에 같은 토큰 수(청크당 400토큰, 한국어 약 460자) 를 가정했어요. 실제 청구 토큰은 각 회사 토크나이저로 다시 세야 해요.

문서 100만 청크 색인 비용

4억 토큰을 한 번 임베딩할 때의 비용이에요. 무료 토큰은 빼고 정가로 계산했어요.

가장 비싼 선택도 80달러예요. 질의 쪽은 더 작아요. 질문 하나를 30토큰으로 잡으면 월 100만 건이 3,000만 토큰이라 text-embedding-3-small 0.6달러, text-embedding-3-large 3.9달러, Gemini Embedding 2 6달러예요. 그러니 단가 차이 6~10배는 대부분의 서비스에서 월 수십 달러 차이이고, 품질이 조금이라도 낫다면 비싼 모델을 써도 되는 구간이에요.

품질은 단가만큼 크게 벌어지지 않아요. OpenAI 가이드가 밝힌 MTEB 평균은 text-embedding-3-small 62.3%, text-embedding-3-large 64.6%, 이전 세대 ada-002 61.0%예요. 단가는 6.5배인데 평균 점수 차이는 2.3%포인트예요. 다만 평균은 평균일 뿐이에요. MTEB 논문은 8개 작업·58개 데이터셋·112개 언어로 33개 모델을 재고 모든 작업에서 앞서는 방법은 없다고 결론 냈어요. 내 언어·내 작업 종류로 걸러 본 점수와, 결국에는 내 데이터로 잰 점수가 기준이에요.

임베딩 차원 줄이기 — 차원·자료형별 저장 용량 계산

벡터 하나의 크기는 차원 × 자료형 바이트 예요. float32 는 4바이트, int8 은 1바이트, 이진은 1비트(8분의 1바이트)예요. 벡터 100만 개로 곱하면 아래와 같아요.

3072차원 float32 는 100만 개에 12.3GB예요. 1,000만 청크면 123GB라 메모리에 올려 두는 벡터 DB 에서는 서버 등급이 바뀌는 크기예요. 같은 데이터를 1024차원 int8 로 두면 10.2GB로 12분의 1이에요. GB 와 GiB 차이가 헷갈리면 데이터 용량 변환기로 1000·1024 기준을 바꿔 보면 돼요. 인덱스 종류별 그래프 오버헤드와 양자화 손실은 벡터 인덱스 고르기에서 따로 계산했어요.

차원을 줄이는 방법은 모델마다 달라요. 여기서 실수가 잦아요.

• OpenAI 3세대: 요청에 dimensions 를 넣으면 짧은 벡터가 바로 와요. 이미 받은 긴 벡터를 앞에서 잘라 쓸 수도 있지만, 가이드 예제처럼 자른 뒤 길이 1로 다시 정규화해야 해요.
• Gemini: 문서에 따르면 gemini-embedding-2 는 768·1536처럼 기본이 아닌 차원도 자동으로 다시 정규화해 줘요. 반면 이전 모델 gemini-embedding-001 은 3072가 아닌 차원을 쓰면 직접 정규화해야 한다고 적혀 있어요. 같은 회사 모델인데 동작이 달라요.
• Voyage 4세대: output_dimension 으로 256~2048, output_dtype 으로 float·int8·uint8·binary·ubinary 를 고를 수 있어요. 양자화된 벡터를 API 가 바로 돌려줘요.
• 오픈소스 모델: 앞부분만 잘라도 되는 성질은 Matryoshka 학습(MRL)을 한 모델에만 있어요. MRL 논문은 ImageNet-1K 분류에서 같은 정확도로 임베딩을 최대 14배 작게 만들었다고 보고하지만, 그렇게 학습하지 않은 모델을 자르면 이 결과가 보장되지 않아요. 모델 카드에 MRL 언급이 있는지 먼저 봐요.

API 와 오픈소스 직접 서빙 — 손익분기 계산

오픈소스 모델을 직접 띄우면 토큰당 요금은 없지만 GPU(또는 CPU) 시간이 들어요. 비교는 간단해요. 서버 시간당 비용 ÷ API 토큰 단가 = 그 서버가 한 시간에 처리해야 본전인 토큰 수예요.

아래는 시간당 1달러짜리 서버를 가정한 예시 계산이에요. 실제 단가는 쓰는 클라우드 가격표로 바꿔 넣으면 돼요.

내 서버가 이 처리량을 넘는지는 모델 크기·배치 크기·청크 길이에 따라 달라서 직접 재야 해요. 넘는다 해도 서버를 계속 바쁘게 돌릴 수 있을 때만 직접 서빙이 싸져요. 문제는 가동률이에요. 4억 토큰 색인을 끝낸 뒤 질의만 들어오는 서비스라면 월 토큰이 수천만 개라 서버는 대부분 놀아요. 그 경우 월 730달러를 내고 API 로 1달러 안쪽이면 될 일을 하는 셈이에요.

그래도 직접 서빙이 맞는 경우가 있어요.

• 데이터를 외부로 보낼 수 없을 때: 사내 규정·계약상 문서를 외부 API 에 넣지 못하면 비용 비교 전에 답이 정해져요.
• 매일 수십억 토큰을 새로 임베딩할 때: 크롤링·로그 분석처럼 입력이 계속 들어와 서버가 쉬지 않을 때예요.
• 질의 지연을 몇 밀리초 단위로 줄여야 할 때: 질의 임베딩이 같은 데이터센터 안에서 끝나 외부 왕복이 사라져요. 대신 서버 장애·배포를 직접 책임져요.
• 특정 모델을 고정해야 할 때: API 모델은 지원 종료되면 재색인이 강제돼요. 가중치를 가진 모델은 버전을 계속 고정할 수 있어요.

오픈소스 쪽에서는 입력 길이를 꼭 봐요. 예를 들어 multilingual-e5-small 모델 카드는 384차원·12층이고 512토큰을 넘으면 잘린다고 적혀 있어요. BGE-M3 모델 카드는 1024차원, 8,192토큰, 100개 넘는 언어를 지원하고 밀집·희소·다중 벡터 검색을 한 모델로 한다고 소개해요. 청크를 512토큰보다 길게 자를 계획이면 앞의 모델은 뒷부분을 버려요.

지연은 직접 재야 해요

API 지연은 지역·요청 크기·시간대에 따라 달라서 남의 숫자를 옮기는 건 의미가 없어요. 질의 경로에서 재야 할 것은 "질문 하나를 임베딩해 돌려받는 시간"의 중앙값과 p95 예요. 아래처럼 실제 서버 위치에서 몇십 번 재 보면 돼요.

import time, statistics
from openai import OpenAI

client = OpenAI()
q = "환불 규정에서 7일 이후 반품은 어떻게 되나요?"
ms = []
for _ in range(50):
    t = time.perf_counter()
    client.embeddings.create(model="text-embedding-3-small", input=q, dimensions=512)
    ms.append((time.perf_counter() - t) * 1000)
ms.sort()
print("p50", round(statistics.median(ms)), "ms / p95", round(ms[int(len(ms) * 0.95) - 1]), "ms")

같은 코드로 직접 띄운 서버의 엔드포인트도 재서 나란히 놓으면, 지연 때문에 직접 서빙할 가치가 있는지 숫자로 판단할 수 있어요. 문서 색인은 지연이 아니라 처리량 문제라 배치 크기를 키우고, Gemini·Voyage 처럼 배치 요금이 있으면 그쪽으로 보내요.

리랭커를 붙이면 비용이 어떻게 바뀌나

임베딩 검색으로 후보를 넉넉히 뽑고, 두 문장을 한꺼번에 보는 리랭커로 다시 매기면 상위 결과가 좋아지는 경우가 많아요. BGE-M3 모델 카드도 RAG 에는 하이브리드 검색과 재정렬을 함께 쓰라고 권해요. 비용 구조는 임베딩과 완전히 달라요.

Voyage 가격표는 재정렬 토큰을 질문 토큰 × 문서 수 + 문서 토큰 합 으로 세요. 질문이 문서마다 한 번씩 다시 들어가는 셈이에요. 질문 30토큰, 문서 400토큰으로 계산하면 이래요.

후보 50개를 rerank-3 로 매기면 질문 하나에 21,500토큰이에요. 질의 임베딩 30토큰의 700배가 넘어요. 그래서 리랭커를 붙일 땐 모델보다 후보 수를 먼저 정해요. 내 평가 세트로 후보 20·50·100개일 때 최종 상위 5개의 정답률을 재 보고, 개선이 멈추는 지점에서 끊으면 돼요. 문서를 짧게 청크하는 것도 재정렬 비용을 바로 줄여요.

상황별 임베딩 모델 추천

모델마다 질문과 문서를 구분하는 방식도 달라요. e5 계열은 앞에 query: ·passage: 를 붙이고, Voyage 는 input_type 에 query·document 를 넘기고, Gemini Embedding 2 는 task_type 대신 작업 지시를 입력 문장 안에 넣으라고 안내해요. 같은 코드에서 모델 이름만 바꾸면 이 부분이 조용히 빠져요.

임베딩 도입 체크리스트

• 평가 세트부터: 실제 질문 50~200개와 정답 문서를 짝지어 두고, 후보 모델마다 상위 5개 안에 정답이 든 비율(Recall@5)을 재요. 이게 없으면 모델·차원·리랭커 어느 것도 고를 근거가 없어요.
• 토큰 수 재기: 청크 길이와 총 토큰을 그 회사 토크나이저로 세서 색인 비용을 미리 계산해요.
• 입력 길이 한도: 청크가 모델 한도(512·8,192·32,000토큰)를 넘으면 뒷부분이 오류 없이 잘려요.
• 차원과 자료형 결정: 벡터 수 × 차원 × 바이트로 메모리를 계산하고, 줄일 거면 MRL 지원 여부와 재정규화를 확인해요.
• 정규화 확인: 저장 직전 norm 이 1인지 찍고, 벡터 DB 거리 함수를 코사인 또는 (정규화된 벡터의) 내적으로 맞춰요.
• 질문·문서 구분: 접두사·input_type·작업 지시를 모델 문서대로 넣었는지 봐요.
• 모델 이름을 벡터와 함께 저장: 모델이 다르면 차원이 같아도 공간이 달라서 섞으면 결과가 망가져요. 메타데이터에 모델·차원·버전을 남겨요.
• 재색인 계획: 모델을 바꾸면 전체 재임베딩이 필요해요. 새 인덱스를 따로 만들어 평가하고 질의를 옮긴 뒤 옛 인덱스를 지우는 순서를 정해 둬요.
• 리랭커 후보 수: 붙인다면 20·50·100개로 평가해 비용 대비 개선이 멈추는 지점에서 끊어요.

자주 묻는 질문

임베딩 모델은 비싼 걸 쓰면 검색 품질이 그만큼 좋아지나요?

단가 차이만큼 벌어지지는 않아요. OpenAI 가 밝힌 MTEB 평균은 3-small 62.3%, 3-large 64.6%로 단가 6.5배에 2.3%포인트 차이예요. 다만 색인·질의 비용이 원래 작아서 비싼 모델의 추가 비용도 월 수십 달러 수준이라, 내 평가 세트에서 의미 있게 좋다면 써도 돼요.

임베딩 차원을 줄이면 품질이 얼마나 떨어지나요?

모델에 달려 있어요. OpenAI 가이드는 dimensions 로 줄여도 의미를 담는 성질이 유지된다고, Gemini 문서는 MRL 로 학습해 작은 차원에서도 품질 손실이 적다고 적어요. 그래도 손실 폭은 데이터마다 다르니, 1024·512·256차원으로 같은 평가 세트를 돌려 Recall 이 떨어지기 시작하는 지점을 직접 확인하세요.

임베딩 모델을 바꾸면 기존 벡터를 그대로 써도 되나요?

안 돼요. 모델마다 벡터 공간이 달라서, 차원이 같아도 옛 문서 벡터와 새 질의 벡터를 비교하면 엉뚱한 결과가 나와요. 문서를 전부 새 모델로 다시 임베딩해야 해요. Voyage 는 4세대 모델끼리 임베딩이 호환된다고 문서에 적어 두었지만, 이런 명시가 없는 조합은 섞지 않는 게 원칙이에요.

한국어 문서에는 어떤 임베딩 모델이 좋나요?

한 가지로 정해진 답은 없어요. 다국어 지원을 명시한 API 모델(Voyage 4세대, Gemini, OpenAI 3세대)과 오픈소스 다국어 모델(multilingual-e5, BGE-M3 등) 중 2~3개를 골라 실제 한국어 질문 평가 세트로 비교하는 게 가장 빠른 길이에요. 한국어는 토크나이저에 따라 토큰 수도 달라지니 비용도 같이 비교해요.

리랭커는 꼭 붙여야 하나요?

필수는 아니에요. 상위 몇 개 결과의 정확도가 답변 품질을 좌우하는 QA 라면 효과가 큰 편이지만, 질문마다 후보 수만큼 토큰을 내야 해서 임베딩보다 수백 배 비쌀 수 있어요. 리랭커 없이 평가한 값과 후보 20·50개로 재정렬한 값을 비교해 보고, 개선 폭이 비용을 정당화할 때 붙이세요.

직접 띄운 오픈소스 임베딩이 API 보다 싼 기준은 뭔가요?

서버 시간당 비용을 API 토큰 단가로 나누면 본전 처리량이 나와요. 시간당 1달러 서버라면 0.02달러 API 와 비교해 초당 약 13,900토큰을 쉬지 않고 처리해야 본전이에요. 질의만 드문드문 들어오는 서비스라면 서버가 대부분 놀기 때문에 API 가 훨씬 싸요.

정리

임베딩 모델을 고를 때 단가표는 생각보다 결정적이지 않아요. 100만 청크 색인이 8~80달러, 월 100만 건 질의가 1~6달러라서, 비용을 실제로 가르는 건 차원·자료형이 정하는 메모리와 리랭커 후보 수예요. 순서는 이렇게 잡으면 돼요. 평가 세트를 만들고, 다국어 지원 모델 2~3개를 같은 세트로 비교하고, 차원을 줄여 가며 품질이 꺾이는 지점을 찾고, 필요할 때만 리랭커를 후보 수부터 정해 붙여요.

메모리 계산을 단위까지 맞추려면 데이터 용량 변환기를, 인덱스 구조별 메모리는 벡터 인덱스 고르기를, 한국어 토큰 수 추정은 한국어 LLM 토큰 비용 비교를 함께 보세요. 단가는 2026년 10월 27일 기준이라 바뀔 수 있으니, 도입 직전에 각 회사 가격표를 다시 확인하세요.

더 깊이 읽기

이 글은 실무에서 판단할 때 필요한 것 위주로 정리했어요. 같은 주제의 내부 동작 원리는 devboi 기술 블로그의 임베딩과 코사인 유사도 원리 — 벡터가 의미를 재는 법에서 도식과 코드로 단계별로 풀었어요.