임베딩 모델 선택 가이드 - 개념부터 한국어 벤치마크까지

지도에서 서울과 부산은 멀리 떨어져 있고, 서울과 인천은 가까이 있습니다. 임베딩 모델은 텍스트에 이와 똑같은 '의미 지도'를 만들어줍니다. "Spark 최적화"와 "Apache Spark 튜닝"은 가까이, "Spark"와 "파이썬 Django"는 멀리 배치되는 벡터 공간이죠.

이 의미 지도가 있어야 RAG가 관련 문서를 찾고, 시맨틱 검색이 동의어를 이해하고, 추천 시스템이 비슷한 아이템을 골라낼 수 있습니다. 이 글에서는 임베딩의 개념부터 한국어 벤치마크, 모델 선택 전략까지 단계별로 풀어드립니다.

이 글에서 배우는 것

• 임베딩이 텍스트를 어떻게 벡터로 바꾸는지, 그 원리
• Bi-Encoder vs Cross-Encoder 차이와 RAG에서의 역할
• OpenAI·BGE-M3·multilingual-e5 등 주요 모델 비교
• 한국어 임베딩이 어려운 이유와 실전 팁
• 상황별 모델 선택 기준과 비용 최적화 전략

1. 임베딩이란 무엇인가

정의와 동작 원리

임베딩(Embedding)은 텍스트를 고차원 벡터 공간의 수치 벡터로 변환하는 과정입니다. 의미적으로 유사한 텍스트는 벡터 공간에서 가까운 위치에 배치됩니다. 아래 예시를 보면 같은 의미를 다른 표현으로 쓴 두 문장이 코사인 유사도 0.94로 매우 가깝다는 것을 확인할 수 있습니다.

의미 공간 시각화

임베딩 유형

임베딩 차원의 의미

2. 임베딩 모델 아키텍처

Bi-Encoder vs Cross-Encoder

임베딩 모델에는 크게 두 가지 구조가 있습니다. 서류 전형(Bi-Encoder)으로 후보를 100명으로 추린 뒤, 면접(Cross-Encoder)으로 최종 합격자를 고르는 채용 과정과 비슷합니다.

참고: RAG에서는 1차 검색(Bi-Encoder)으로 후보를 좁힌 뒤, 2차 리랭킹(Cross-Encoder)으로 정밀도를 높이는 2단계 전략이 일반적입니다.

학습 목표: Contrastive Learning

"왜 의미가 비슷한 문장끼리 가까워지는 걸까요?" 그 비밀은 대조 학습에 있습니다. 대부분의 현대 임베딩 모델은 **대조 학습(Contrastive Learning)**으로 훈련됩니다.

풀링 전략

Transformer는 각 토큰마다 벡터를 하나씩 만들어냅니다. 이걸 문장 하나를 대표하는 단일 벡터로 어떻게 합칠지가 풀링 전략입니다.

3. 주요 임베딩 모델 비교

종합 비교표

시장에는 수십 개의 임베딩 모델이 있습니다. 여기서는 실무에서 자주 쓰이는 대표 모델들을 한 표에 정리했습니다. 가격, 차원, 다국어 지원 여부를 함께 보세요.

스펙 기준일: 2026년 9월 8일. 임베딩 모델은 세대 교체가 빠릅니다. 도입 전 각 제공사의 공식 문서에서 최신 스펙과 가격을 다시 확인하세요.

멀티모달: gemini-embedding-2는 텍스트·이미지·오디오·비디오·PDF를, embed-v4.0은 텍스트와 이미지(PDF 포함)를 하나의 벡터 공간에 매핑합니다. 스캔 문서나 차트가 섞인 RAG라면 이 두 모델이 유리합니다.

모델별 특징 상세

OpenAI text-embedding-3 시리즈

• 장점: 높은 범용 성능, 간편한 API, Matryoshka 임베딩 지원 (차원 축소 가능)
• 단점: API 비용 발생, 데이터 외부 전송, 오프라인 사용 불가
• 적합: 빠른 구현, 비용 감당 가능한 프로젝트

gemini-embedding-2 (Google)

• 장점: 네이티브 멀티모달(텍스트·이미지·오디오·비디오·PDF)을 단일 벡터 공간에 매핑, 100개 이상 언어, 128~3072차원 MRL
• 단점: 상용 API 중 텍스트 단가가 가장 높음, 최대 8192토큰
• 적합: 문서에 이미지·차트·스캔본이 섞인 멀티모달 RAG

Cohere embed-v4.0

• 장점: 128K 토큰이라는 압도적인 컨텍스트, 텍스트+이미지 동시 처리, int8/binary 양자화 내장, input_type으로 쿼리/문서 구분
• 단점: 상용 API, 오프라인 불가
• 적합: 청킹 없이 긴 문서를 통째로 임베딩해야 하는 경우

Qwen3-Embedding 시리즈 (Alibaba)

• 장점: 0.6B/4B/8B로 크기 선택 가능, 32K 컨텍스트, 32~4096차원 MRL, 태스크별 instruction 지원, Apache 2.0
• 단점: 8B는 GPU 필수, instruction 프롬프트 설계에 따라 성능 편차
• 적합: 오픈소스로 최고 수준 다국어 성능이 필요한 경우. 0.6B는 경량 대안

BGE-M3 (BAAI)

• 장점: Dense + Sparse + ColBERT 멀티 검색을 한 모델로, 다국어 강점, 한국어 파생 모델 생태계가 두터움
• 단점: 모델 크기 대비 추론 속도 약간 느림
• 적합: 하이브리드 검색을 단일 모델로 구현하고 싶은 경우

KURE (고려대 NLP&AI Lab)

• 장점: 한국어 검색에 특화, MTEB-ko-retrieval에서 BGE-M3 계열을 상회, MIT 라이선스
• 단점: 한국어 전용이라 다국어 서비스에는 부적합. KURE-v2는 late-interaction 방식이라 벡터 DB 연동 방식이 다름
• 적합: 한국어 사내 문서 검색처럼 언어가 한국어로 고정된 RAG

multilingual-e5-large

• 장점: 경량 (560M), 다국어 균형 성능, CPU에서도 실행 가능
• 단점: 짧은 최대 토큰 (512)
• 적합: 리소스 제한 환경, 다국어 범용

세대가 지난 모델: 이전 판에서 소개했던 GTE-Qwen2는 Qwen3-Embedding으로, Cohere embed-v3는 embed-v4.0으로, jina-embeddings-v3는 v4로 대체되었습니다. E5-Mistral-7B, KoSimCSE-roberta도 여전히 동작하지만, 신규 도입이라면 위 모델들을 먼저 검토하세요.

4. 한국어 성능

한국어 임베딩이 어려운 이유

영어 중심으로 설계된 임베딩 모델이 한국어를 처리하면 왜 성능이 떨어질까요? 한국어에는 영어와 다른 구조적 특성이 있어서입니다.

한국어 검색 벤치마크

한국어 임베딩은 공개 리더보드가 많지 않습니다. 현재 가장 참고할 만한 것은 고려대 NLP&AI Lab이 공개한 MTEB-ko-retrieval 리더보드로, 한국어 검색 9개 태스크의 평균 성능을 제공합니다.

출처: nlpai-lab/KURE MTEB-ko-retrieval 리더보드 (한국어 검색 9개 태스크 평균)

읽는 법: 이 리더보드는 한국어 특화·오픈소스 모델 위주로 구성되어 있어 상용 API 모델은 포함되어 있지 않습니다. 또한 KURE-v2는 토큰별 벡터를 저장하는 late-interaction(ColBERT 계열) 방식이라, 단일 벡터 모델과 스토리지·인프라 요구사항이 다릅니다. 순위를 그대로 받아들이기보다 본인 도메인 문서로 직접 측정하는 것이 가장 정확합니다.

한국어 RAG를 위한 실전 팁

• 모델 추천: 한국어 전용이면 KURE, 다국어를 함께 다루면 BGE-M3 또는 Qwen3-Embedding (오픈소스), 빠른 구현이 우선이면 text-embedding-3-small (API)
• 청킹 전략: 한국어는 문장 단위 분할이 효과적 (kss 라이브러리 활용)
• 쿼리 전처리: 조사 제거, 어근 추출로 검색 품질 향상
• 하이브리드 검색: 한국어는 벡터 + BM25 결합이 특히 효과적

# 한국어 문장 분리 (kss)
import kss
 
text = "Spark는 분산 처리 프레임워크입니다. 대용량 데이터를 병렬로 처리합니다."
sentences = kss.split_sentences(text)
# ['Spark는 분산 처리 프레임워크입니다.', '대용량 데이터를 병렬로 처리합니다.']

5. 임베딩 모델 사용법

OpenAI Embeddings

from openai import OpenAI
 
client = OpenAI()
 
# 단일 텍스트 임베딩
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="Apache Spark는 분산 데이터 처리 프레임워크입니다"
)
embedding = response.data[0].embedding  # 1536차원 벡터
 
# 차원 축소 (Matryoshka)
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="Apache Spark는 분산 데이터 처리 프레임워크입니다",
    dimensions=256  # 1536 → 256으로 축소
)
 
# 배치 처리
texts = ["텍스트 1", "텍스트 2", "텍스트 3", ...]
response = client.embeddings.create(
    model="text-embedding-3-small",
    input=texts  # 최대 2048개, 8191 토큰/건
)
embeddings = [d.embedding for d in response.data]

HuggingFace (sentence-transformers)

from sentence_transformers import SentenceTransformer
 
# BGE-M3 로드
model = SentenceTransformer("BAAI/bge-m3")
 
# 단일 텍스트 임베딩
embedding = model.encode("Apache Spark는 분산 데이터 처리 프레임워크입니다")
# 결과: (1024,) 차원 numpy 배열
 
# 배치 처리
texts = [
    "Spark 성능 최적화 방법",
    "Kafka 컨슈머 그룹 설정",
    "Airflow DAG 스케줄링"
]
embeddings = model.encode(texts, batch_size=32, show_progress_bar=True)
# 결과: (3, 1024) 차원 numpy 배열
 
# 정규화 (코사인 유사도 사용 시)
embeddings = model.encode(texts, normalize_embeddings=True)

Ollama Embeddings

import ollama
 
# Ollama로 임베딩 (로컬 실행)
response = ollama.embeddings(
    model="nomic-embed-text",
    prompt="Apache Spark는 분산 데이터 처리 프레임워크입니다"
)
embedding = response["embedding"]  # 768차원 벡터
 
# 배치 처리
texts = ["텍스트 1", "텍스트 2", "텍스트 3"]
embeddings = []
for text in texts:
    resp = ollama.embeddings(model="nomic-embed-text", prompt=text)
    embeddings.append(resp["embedding"])

유사도 계산

import numpy as np
 
def cosine_similarity(a, b):
    """코사인 유사도 계산"""
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
 
# 예시
emb1 = model.encode("Spark 성능 튜닝")
emb2 = model.encode("Apache Spark 최적화 방법")
emb3 = model.encode("Python 웹 개발 Django")
 
print(cosine_similarity(emb1, emb2))  # ~0.92 (높은 유사도)
print(cosine_similarity(emb1, emb3))  # ~0.35 (낮은 유사도)

6. 차원 축소

Matryoshka Embeddings

Matryoshka 임베딩은 벡터의 앞부분만 잘라도 유효한 임베딩이 되도록 학습된 모델입니다. 러시아 마트료시카 인형처럼, 큰 벡터 안에 작은 벡터가 내포되어 있습니다. 덕분에 저장 공간이 부족하거나 검색 속도를 높여야 할 때 정확도를 거의 잃지 않고 차원을 줄일 수 있습니다.

한 문장으로: Matryoshka 임베딩은 큰 인형 안에 작은 인형이 들어있듯, 1536차원 벡터 앞부분 256개만 잘라도 여전히 제 기능을 하는 "축소 가능한" 임베딩입니다.

지원 모델: OpenAI text-embedding-3, Google gemini-embedding-2(1283072), Cohere embed-v4.0(2561536), Qwen3-Embedding(324096), jina-embeddings-v4(1282048), nomic-embed-text

차원별 스토리지 트레이드오프

차원을 줄이면 스토리지가 정비례해서 줄어듭니다. 아래는 float32(차원당 4바이트) 기준의 단순 계산값입니다.

실제 벡터 DB는 인덱스(HNSW 그래프 등)와 원문·메타데이터를 추가로 저장하므로, 위 값은 원시 벡터 크기의 하한입니다. int8이나 binary 양자화를 함께 쓰면 여기서 4~32배를 더 줄일 수 있습니다.

그럼 정확도는 얼마나 떨어질까요? 이건 모델과 태스크에 따라 편차가 커서 하나의 표로 일반화할 수 없습니다. 다만 공개된 기준점이 하나 있습니다 — OpenAI는 text-embedding-3-large를 256차원으로 줄여도 1536차원 text-embedding-ada-002보다 MTEB 점수가 높다고 밝혔습니다. Matryoshka로 학습된 모델에서는 차원 축소의 손실이 그만큼 작다는 뜻입니다.

중요: 이 결과를 다른 모델에 그대로 적용하면 안 됩니다. Matryoshka로 학습되지 않은 모델을 잘라내면 성능이 급격히 무너집니다. 축소 차원은 반드시 본인 데이터로 Recall@k를 측정해서 결정하세요.

7. 임베딩 모델 미세 조정

미세 조정이 필요한 경우

범용 모델로도 충분한 경우가 많지만, 이런 상황이라면 미세 조정을 고려해 보세요.

• 범용 모델이 도메인 전문 용어를 잘 이해하지 못할 때
• 검색 정확도가 요구 수준에 미치지 못할 때
• 특정 언어/도메인의 유사도 판단이 부정확할 때

학습 데이터 형식

# Query-Positive-Negative 트리플 형식
training_data = [
    {
        "query": "Spark executor OOM 에러 해결",
        "positive": "Spark executor 메모리 부족 시 spark.executor.memory를 늘리고...",
        "negative": "Python Django에서 메모리 최적화를 위해..."
    },
    {
        "query": "Kafka 컨슈머 랙 증가 원인",
        "positive": "컨슈머 그룹의 처리 속도가 프로듀서 생산 속도를 따라가지 못하면...",
        "negative": "Redis 캐시 만료 정책을 TTL로 설정하면..."
    }
]

미세 조정 코드

from sentence_transformers import SentenceTransformer, InputExample, losses
from torch.utils.data import DataLoader
 
# 기반 모델 로드
model = SentenceTransformer("BAAI/bge-m3")
 
# 학습 데이터 구성
train_examples = [
    InputExample(texts=[
        "Spark executor OOM 에러 해결",
        "Spark executor 메모리 부족 시 spark.executor.memory를 늘리고..."
    ], label=1.0),
    InputExample(texts=[
        "Spark executor OOM 에러 해결",
        "Python Django에서 메모리 최적화를 위해..."
    ], label=0.0),
]
 
train_dataloader = DataLoader(train_examples, shuffle=True, batch_size=16)
 
# 손실 함수
train_loss = losses.CosineSimilarityLoss(model)
 
# 학습
model.fit(
    train_objectives=[(train_dataloader, train_loss)],
    epochs=3,
    warmup_steps=100,
    output_path="./fine_tuned_embedding"
)
 
# 평가
from sentence_transformers.evaluation import InformationRetrievalEvaluator
 
evaluator = InformationRetrievalEvaluator(
    queries=eval_queries,
    corpus=eval_corpus,
    relevant_docs=eval_relevant,
    name="domain-eval"
)
model.evaluate(evaluator)

8. RAG 연동 모범 사례

청킹과 임베딩 정렬

RAG에서 임베딩 모델을 쓸 때 가장 흔한 실수는 청크 크기와 모델의 최대 토큰 수를 맞추지 않는 것입니다. 청크가 모델 한계를 넘으면 뒷부분이 조용히 잘려나가고, 검색 품질이 떨어집니다.

⚠️ 청크 크기 1,000 토큰인데 모델 최대 토큰이 512라면, 절반의 내용이 임베딩에 반영되지 않습니다. 반드시 모델 최대 토큰 안에 들어오도록 청킹하세요.

쿼리 vs 문서 임베딩

일부 모델은 쿼리와 문서에 다른 프리픽스를 사용합니다.

# BGE 모델: 쿼리에 프리픽스 추가
query_embedding = model.encode("Represent this sentence for searching: Spark 성능 최적화")
doc_embedding = model.encode("Spark 성능을 최적화하려면 파티션 수를 조정하고...")
 
# E5 모델: query/passage 프리픽스
query_embedding = model.encode("query: Spark 성능 최적화")
doc_embedding = model.encode("passage: Spark 성능을 최적화하려면...")

비용 최적화 전략

9. 선택 가이드

의사결정 플로차트

"어떤 모델을 써야 하나요?" — 이 플로차트를 따라가면 빠르게 답을 찾을 수 있습니다.

시나리오별 추천

참고: "최고의 임베딩 모델"은 없습니다. 도메인, 언어, 인프라, 비용 제약에 따라 최적의 선택이 달라집니다. 프로토타입은 OpenAI API로 빠르게 검증하고, 프로덕션에서는 요구사항에 맞는 오픈소스 모델로 전환하는 전략을 추천합니다.

마치며 — 핵심 요약

• 임베딩은 텍스트를 의미 지도 위의 좌표로 변환합니다. 비슷한 의미는 가깝게, 무관한 것은 멀게 배치됩니다.
• Bi-Encoder가 1차 검색(빠름), Cross-Encoder가 2차 리랭킹(정확)을 담당하는 2단계 전략이 RAG의 표준입니다.
• 한국어 RAG라면 KURE(한국어 특화)나 BGE-M3(다국어 겸용), 빠른 구현이 우선이면 text-embedding-3-small부터 시작해보세요.
• Matryoshka 임베딩으로 차원을 줄이면 스토리지가 정비례로 절감됩니다. 다만 정확도 손실폭은 모델마다 다르니 본인 데이터로 측정해서 축소 차원을 정하세요.
• 미세 조정은 도메인 전문 용어가 많거나 범용 모델 정확도가 부족할 때 시도하세요. 먼저 OpenAI API로 빠르게 검증하고, 오픈소스로 전환하는 순서를 추천합니다.
• "최고의 임베딩 모델"은 없습니다. 오늘 당장 text-embedding-3-small로 프로토타입을 만들어 보세요 — 실제 데이터로 측정해봐야 비교가 의미가 생깁니다.

References

• Reimers, N. & Gurevych, I. (2019). "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks." EMNLP
• Chen, J. et al. (2024). "BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings." arXiv
• Wang, L. et al. (2024). "Multilingual E5 Text Embeddings: A Technical Report." arXiv
• Kusupati, A. et al. (2024). "Matryoshka Representation Learning." NeurIPS
• Zhang, Y. et al. (2025). "Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models." arXiv:2506.05176
• Lee, D. et al. (2025). "KURE: Embedding Model for Korean-Specific Retrieval." 한글 및 한국어 정보처리 학술대회
• OpenAI. "Embeddings Guide" — https://developers.openai.com/api/docs/guides/embeddings
• Google. "Gemini Embedding 2" — https://ai.google.dev/gemini-api/docs/embeddings
• Cohere. "Cohere's Embed Models" — https://docs.cohere.com/docs/cohere-embed
• Qwen3-Embedding — https://github.com/QwenLM/Qwen3-Embedding
• KURE / MTEB-ko-retrieval 리더보드 — https://github.com/nlpai-lab/KURE
• Sentence-Transformers Documentation — https://www.sbert.net/
• MTEB Leaderboard — https://huggingface.co/spaces/mteb/leaderboard

— Data Dynamics 엔지니어링 팀