한국어 검색 품질을 좌우하는 임베딩 모델 선택

한국어로 된 문서를 검색하거나 RAG를 만들 때, 품질의 절반은 임베딩 모델 선택에서 결정됩니다. 임베딩은 문장을 좌표로 바꾸는 역할인데, 한국어를 제대로 학습하지 않은 모델은 뜻이 통하는 문장들을 가깝게 모으지 못합니다. 그러면 청킹과 벡터 DB를 아무리 잘 갖춰도 엉뚱한 문서가 검색됩니다. 문제는 영어 벤치마크에서 높은 점수를 받은 모델이 한국어에서도 좋으리란 보장이 없다는 점입니다. 이 글에서는 임베딩의 기본 개념부터 한국어 성능을 어떻게 가늠하는지, 차원과 비용·다국어와 한국어 특화의 트레이드오프, 정규화와 유사도 측정, 모델을 바꿀 때 드는 재색인 비용, 그리고 내 도메인에 맞는 평가셋을 만드는 방법까지 정리합니다.

임베딩이란 무엇인가

임베딩은 단어·문장·문서를 고정 길이의 실수 벡터로 바꾸는 작업입니다. 핵심 성질은 “의미가 비슷한 텍스트는 벡터 공간에서 가깝게 놓인다”는 것입니다. 잘 학습된 임베딩에서는 “환불 절차”와 “결제 취소 방법”처럼 표현은 달라도 뜻이 통하는 문장들이 서로 가까운 좌표를 갖습니다. 이 성질 덕분에 키워드가 정확히 겹치지 않아도 의미로 검색할 수 있습니다.

한국어가 특별히 까다로운 이유는 형태소 구조에 있습니다. 조사·어미가 붙어 한 단어가 수많은 형태로 변하고, 띄어쓰기가 일정하지 않으며, 동음이의어와 외래어 표기가 뒤섞입니다. 모델이 한국어를 충분히 보지 않았다면 토크나이저가 단어를 잘게 쪼개 의미를 잃거나, 활용형을 다른 단어로 취급해 유사도가 흐트러집니다. 그래서 임베딩 모델 선택은 “한국어를 얼마나 제대로 다루는가”라는 질문으로 귀결됩니다.

한국어 성능을 어떻게 평가하나

모델 카드에 적힌 영어 벤치마크 점수만 보고 고르면 한국어에서 실망하기 쉽습니다. 한국어 성능은 다음 세 층위로 나눠 보면 판단이 쉬워집니다.

공개 벤치마크와 리더보드

다국어 임베딩 벤치마크에는 한국어 검색·분류·유사도 과제가 포함되기도 합니다. 이런 공개 리더보드는 출발점으로 유용하지만, 평가에 쓰인 데이터가 내 도메인과 다를 수 있어 절대적 순위로 믿어선 안 됩니다. 같은 모델이 뉴스 검색에서는 강해도 기술 문서나 상품 리뷰에서는 약할 수 있습니다.

도메인 적합도

법률·의료·커머스·개발 문서는 각기 고유한 어휘와 문체를 갖습니다. 일반 웹 텍스트로 학습한 모델은 전문 용어가 많은 도메인에서 유사도를 잘 구분하지 못할 수 있습니다. 그래서 공개 점수보다 내 실제 문서·질문으로 측정한 결과가 훨씬 신뢰할 만합니다.

실측 검색 품질

결국 가장 확실한 평가는 내 데이터로 만든 평가셋에 모델을 돌려, 정답 문서가 상위 검색에 들어오는 비율을 재는 것입니다. 뒤에서 평가셋 만드는 법을 따로 다룹니다. 공개 리더보드는 후보를 추리는 데, 실측은 최종 결정에 쓰는 식으로 역할을 나누는 편이 좋습니다.

차원과 비용의 트레이드오프

임베딩 벡터의 차원 수는 표현력과 비용을 동시에 좌우합니다. 차원이 높으면 더 미세한 의미 차이를 담을 수 있지만, 저장 공간과 검색 시 계산량이 늘고 벡터 DB의 메모리 사용량이 커집니다. 차원이 낮으면 가볍지만 표현력이 줄어 비슷한 문장들을 충분히 구분하지 못할 수 있습니다.

일부 최신 모델은 하나의 임베딩을 학습해 두고 필요에 따라 차원을 잘라 쓰는 방식을 지원하기도 합니다. 큰 차원으로 정확도를 확보하다가, 비용이 문제되면 차원을 줄여 균형을 맞추는 식입니다. 다만 이런 기능과 권장 차원, 처리 단가는 모델마다 다르므로 OpenAI 임베딩 공식 문서 같은 공식 문서에서 확인해야 합니다. API 기반 모델은 토큰당 과금이라, 색인할 문서량이 많으면 임베딩 비용을 미리 추산하는 것이 중요합니다.

다국어 모델 vs 한국어 특화 모델

임베딩 모델은 크게 여러 언어를 함께 학습한 다국어 모델과, 한국어 중심으로 학습한 특화 모델로 나뉩니다. 어느 쪽이 낫다고 일반화하기는 어렵고, 데이터 성격으로 갈립니다.

문서와 질문이 모두 한국어이고 교차언어 검색이 필요 없다면, 한국어를 충실히 학습한 모델이 안정적인 경우가 많습니다. 반대로 한국어와 영어 문서가 섞여 있거나 영어로 질문하고 한국어 문서를 찾아야 한다면, 교차언어를 지원하는 다국어 모델이 유리합니다. 핵심은 라벨이 아니라 내 데이터에서의 실측 성능입니다.

정규화와 유사도 측정

임베딩을 비교할 때 어떤 유사도 척도를 쓰느냐도 결과에 영향을 줍니다. 가장 흔한 코사인 유사도는 벡터의 방향만 보고 크기는 무시합니다. 많은 모델이 코사인을 전제로 학습되며, 이 경우 벡터를 L2 정규화(길이를 1로 맞춤)하면 코사인 유사도와 내적이 같아져 검색이 일관됩니다.

import numpy as np

def l2_normalize(v):
    return v / np.linalg.norm(v)

# 정규화 후에는 내적 = 코사인 유사도
sim = np.dot(l2_normalize(q), l2_normalize(d))

주의할 점은 모델이 권장하는 유사도와 벡터 DB의 거리 설정을 일치시켜야 한다는 것입니다. 코사인을 전제로 한 모델인데 DB에서 유클리드 거리로 검색하면 결과가 어긋날 수 있습니다. 또 질의와 문서에 서로 다른 전처리(정규화 여부, 접두어 prompt)를 적용하면 비교가 깨지므로, 색인과 질의의 전처리를 반드시 동일하게 맞춰야 합니다. 일부 모델은 “검색 질의”와 “문서”에 서로 다른 안내 접두어를 붙이도록 설계돼 있으니 모델 문서를 따르세요.

내 도메인 평가셋 만들기

모델 선택의 마지막 결정은 공개 점수가 아니라 내 데이터로 내려야 합니다. 평가셋은 거창할 필요 없이, 실제 사용자가 던질 질문과 그에 답이 되는 문서(또는 청크)를 짝지은 목록이면 됩니다. 만드는 순서는 다음과 같습니다.

• 질문 수집 — 운영 로그·고객 문의·검색어에서 실제 질문 30~100개를 모읍니다. 직접 지어내기보다 진짜 표현을 쓰는 것이 중요합니다.
• 정답 라벨링 — 각 질문에 대해 정답이 담긴 문서나 청크를 지정합니다. 한 질문에 정답이 여럿일 수 있습니다.
• 지표 선정 — Recall@k(상위 k에 정답이 들어오는 비율), MRR(정답의 평균 순위) 등으로 검색 품질을 수치화합니다.
• 모델 비교 — 같은 평가셋·같은 청킹·같은 DB 설정에서 임베딩 모델만 바꿔 가며 점수를 비교합니다.

이렇게 만든 평가셋은 임베딩 모델 선택뿐 아니라, 나중에 청킹이나 검색 설정을 바꿀 때도 그대로 재사용할 수 있는 자산이 됩니다. 변수를 한 번에 하나씩만 바꿔 측정하면, 어떤 선택이 품질을 끌어올렸는지 분명하게 드러납니다.

평가셋을 만들 때 흔히 빠지는 함정도 미리 알아 두면 좋습니다. 첫째, 질문을 개발자가 직접 지어내면 실제 사용자의 어휘·말투와 동떨어져 평가가 낙관적으로 나옵니다. 운영 로그의 진짜 질문을 쓰는 것이 중요합니다. 둘째, 정답 라벨을 한 명이 달면 주관이 섞이므로, 모호한 질문은 복수의 정답을 인정하거나 검토자를 두는 편이 좋습니다. 셋째, 평가셋이 너무 쉬우면 모델 간 차이가 드러나지 않습니다. 실제로 검색이 자주 실패하던 까다로운 질문을 일부러 포함시켜야 변별력이 생깁니다. 이런 평가셋을 한 번 잘 만들어 두면, 모델 공급사가 새 버전을 내놓을 때마다 같은 기준으로 빠르게 재검증할 수 있어 의사결정의 속도와 신뢰도가 함께 올라갑니다.

선택 전 점검 체크리스트

• 영어 점수가 아니라 한국어 과제·도메인 적합도로 후보를 추렸는가
• 문서·질문이 한국어 전용인지, 다국어·교차언어가 필요한지 정의했는가
• 차원에 따른 저장·검색 비용과 표현력의 균형을 따졌는가
• API 모델이라면 색인할 문서량 기준 임베딩 비용을 추산했는가
• 모델 권장 유사도와 벡터 DB 거리 설정을 일치시켰는가
• 질의·문서 전처리(정규화·접두어)를 동일하게 맞췄는가
• 내 도메인 평가셋으로 후보 모델을 실측 비교했는가

자주 묻는 질문

영어 벤치마크 1위 모델이면 한국어도 좋은가요?

보장되지 않습니다. 한국어 학습량과 토크나이저 품질에 따라 한국어 성능은 크게 갈립니다. 공개 리더보드는 후보 추리기에만 쓰고, 최종 결정은 내 한국어 데이터로 실측해 내리는 것이 정확합니다.

차원이 높을수록 검색이 정확한가요?

대체로 표현력은 늘지만 저장·계산 비용도 함께 늘고, 일정 수준을 넘으면 정확도 향상이 둔해집니다. 도메인의 미세 구분 필요와 비용을 저울질해 정하고, 가능하면 차원을 바꿔 가며 실측 비교하세요.

다국어 모델과 한국어 특화 모델 중 무엇을 고를까요?

문서·질문이 한국어 전용이면 한국어 특화가 안정적인 경우가 많고, 다국어·교차언어 검색이 필요하면 다국어 모델이 유리합니다. 라벨이 아니라 내 데이터 실측 성능으로 결정하는 것이 맞습니다.

임베딩은 정규화해야 하나요?

코사인 유사도를 전제로 학습된 모델이라면 L2 정규화 후 내적으로 비교하는 것이 일관적입니다. 중요한 것은 색인과 질의에 같은 전처리를 적용하고, 모델 권장 유사도와 벡터 DB의 거리 설정을 일치시키는 것입니다.

나중에 더 좋은 모델이 나오면 쉽게 바꿀 수 있나요?

임베딩 모델을 바꾸면 기존 벡터가 무효가 되어 전체 재임베딩·재색인이 필요합니다. 문서가 많을수록 비용과 시간이 드므로, 초기 선택을 신중히 하고 교체 시에는 비용·다운타임을 미리 계획하세요.

이 글은 한국어 검색·RAG에서 임베딩 모델을 고를 때 따질 일반적인 기준과 원리를 정리한 기술 참고 자료이며, 특정 모델의 우열을 단정하지 않습니다. 모델별 한국어 성능, 권장 차원, 정규화·접두어 규칙, 처리 단가는 시점과 버전에 따라 달라지므로, 선택 전에 각 모델의 공식 문서와 최신 벤치마크를 확인하고 내 도메인 데이터로 직접 평가하시기 바랍니다.