임베딩 모델은 차원 수가 높을수록 무조건 성능이 좋다고 생각하시는 분들이 많은데, 실제로는 그렇지 않습니다. 한국어 임베딩 모델을 고르는 기준은 차원 수 하나가 아니라 차원 수, 컨텍스트 길이, 라이선스라는 세 가지 조건을 순서대로 확인하는 것이고, 이 세 가지만 체크해도 후보군을 몇 개 안 되는 수준으로 좁힐 수 있습니다. 아래에서 각 기준이 실무에서 어떤 차이를 만드는지 실제 모델 스펙으로 짚어보겠습니다.
임베딩 모델은 차원 수가 높을수록 성능이 좋을까요?
차원 수는 벡터 하나가 몇 개의 숫자로 표현되는지를 뜻합니다. 예를 들어 BAAI의 BGE-M3는 1024차원 벡터를 출력하고, intfloat의 multilingual-e5-large도 동일하게 1024차원을 씁니다. OpenAI의 text-embedding-3-small은 기본 1536차원, text-embedding-3-large는 기본 3072차원을 출력하는데, 이 두 모델은 API 호출 시 dimensions 파라미터로 차원을 줄여서 받을 수 있게 설계되어 있습니다.
차원이 높으면 벡터 하나가 담을 수 있는 의미 정보가 늘어나지만, 그만큼 저장 공간과 유사도 계산 비용도 같이 늘어납니다. 문서 수십만 건을 벡터 DB에 올려야 하는 상황이라면 3072차원과 1024차원은 인덱스 크기 차이가 세 배 가까이 나기 때문에, 검색 정확도보다 저장 비용이 먼저 발목을 잡는 경우가 흔합니다. 그래서 차원 수는 “높을수록 좋다”가 아니라 “필요한 정확도 대비 감당 가능한 저장·연산 비용인가”로 판단하는 편이 실무에 더 맞습니다.
RAG용 문서라면 컨텍스트 길이를 어떻게 따져야 하나요?
컨텍스트 길이는 모델이 한 번에 벡터화할 수 있는 최대 토큰 수를 말합니다. multilingual-e5-large는 모델 카드에 최대 시퀀스 길이가 512토큰으로 안내되어 있어서, 그보다 긴 문서를 그대로 넣으면 뒷부분이 잘려나갑니다. 반면 BGE-M3는 최대 8192토큰까지 처리하도록 설계돼 있어서 긴 보고서나 계약서를 청크 단위로 잘게 쪼개지 않아도 되는 여유가 있습니다.
OpenAI의 text-embedding-3 계열도 공식 임베딩 가이드에 최대 입력 토큰이 8191로 명시돼 있어서 BGE-M3와 비슷한 수준의 긴 입력을 받아들입니다. 실무에서는 여기서 트레이드오프가 하나 생기는데, 컨텍스트 길이가 길다고 해서 문서 전체를 통째로 넣는 게 항상 유리한 건 아닙니다. 긴 텍스트를 하나의 벡터로 압축하면 특정 단락의 세부 내용이 평균화되어 검색 정확도가 오히려 떨어지는 경우가 있어서, RAG 파이프라인에서는 여전히 300~500토큰 단위로 청크를 나누고 컨텍스트 길이는 “잘림 없이 처리 가능한 여유분” 정도로 보는 편이 안전합니다.
상업 서비스에 써도 되는 라이선스인지는 어디서 확인하나요?
허깅페이스에 올라온 모델이라고 해서 다 자유롭게 상업적으로 쓸 수 있는 건 아닙니다. 모델 페이지의 license 필드를 먼저 확인해야 하는데, BGE-M3와 multilingual-e5-large는 둘 다 MIT 라이선스로 공개되어 있어서 수정·재배포·상업적 이용에 별다른 제약이 없는 편입니다. MIT 라이선스가 정확히 무엇을 허용하고 어떤 의무(저작권 고지 유지 정도)만 남기는지는 위키백과의 MIT 허가서 문서에 조항별로 정리돼 있습니다.
반면 OpenAI의 text-embedding-3 계열은 오픈소스 모델이 아니라 API로만 제공되는 상품이기 때문에 ‘라이선스’가 아니라 이용약관과 과금 체계를 확인해야 합니다. 이 경우는 벡터를 내려받아 로컬에서 재사용하는 게 아니라 호출할 때마다 과금되는 구조이므로, 라이선스 검토 항목이 오픈소스 모델과 아예 다릅니다. 국내에서 오픈소스 라이선스 조합이나 고지 의무가 헷갈릴 때는 정보통신산업진흥원이 운영하는 오픈소스SW포털에서 라이선스 가이드와 상담 창구를 참고할 수 있습니다.
파이썬 코드로 차원 수·최대 토큰 길이를 직접 확인하려면?
모델 카드 설명만 믿기보다는 실제 로드해서 값을 직접 찍어보는 게 확실합니다. sentence-transformers 라이브러리를 쓰면 몇 줄로 확인할 수 있습니다.
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("BAAI/bge-m3")
print("임베딩 차원:", model.get_sentence_embedding_dimension())
print("최대 토큰 길이:", model.max_seq_length)
text = "한국어 임베딩 모델을 고를 때는 차원 수만 보면 안 됩니다."
vec = model.encode(text)
print("벡터 shape:", vec.shape)
이 코드를 돌리면 아래와 같은 결과를 확인할 수 있습니다.
임베딩 차원: 1024
최대 토큰 길이: 8192
벡터 shape: (1024,)같은 방식으로 모델 이름만 “intfloat/multilingual-e5-large”로 바꿔서 돌려보면 최대 토큰 길이가 512로 나오는 걸 눈으로 확인할 수 있습니다. 이렇게 직접 값을 뽑아보면 모델 카드 설명이 실제 로드된 설정과 일치하는지도 같이 검증되기 때문에, 특히 파인튜닝된 커뮤니티 모델을 쓸 때는 이 단계를 건너뛰지 않는 편이 좋습니다.
세 가지 기준을 표로 정리하면 어떤 모델을 골라야 할까요?
지금까지 살펴본 세 모델을 표로 정리하면 다음과 같습니다.
| 모델 | 임베딩 차원 | 최대 토큰 길이 | 라이선스/제공 방식 |
|---|---|---|---|
| BAAI/bge-m3 | 1024 (가변 지원) | 8192 | MIT, 오픈소스 가중치 |
| intfloat/multilingual-e5-large | 1024 | 512 | MIT, 오픈소스 가중치 |
| OpenAI text-embedding-3-large | 3072(축소 가능) | 8191 | API 이용약관, 종량 과금 |
로컬 서버에 GPU 여유가 있고 긴 문서(계약서, 회의록 전문)를 통째로 처리해야 한다면 BGE-M3처럼 컨텍스트 길이가 긴 오픈소스 모델이 먼저 후보에 올라옵니다. 반대로 문장 단위나 짧은 FAQ 매칭이 대부분이고 인프라 관리 부담을 줄이고 싶다면 512토큰짜리 e5 모델로도 충분한 경우가 많고, 서버를 직접 운영하기 부담스러운 소규모 프로젝트라면 종량 과금이 부담되지 않는 선에서 OpenAI API 쪽이 운영 부담을 줄여줍니다. 다만 API 방식은 문서를 외부로 전송한다는 전제가 깔리기 때문에, 사내 문서처럼 외부 반출이 민감한 데이터라면 이 조건 하나만으로 오픈소스 로컬 모델 쪽으로 결론이 기울기도 합니다. 차원 수, 컨텍스트 길이, 라이선스라는 세 조건을 이 순서로 점검하면, 검색만으로는 잘 드러나지 않던 트레이드오프가 표 한 장으로 정리되고 후보군도 자연스럽게 좁혀집니다.
