OpenAI의 text-embedding-3-small이 최신 모델에도 불구하고 계속 사용되는 이유

지난 기사('EmbeddingGemma 2와 Gemini Embedding 2 비교')를 공개한 후, OpenRouter에서 확인한 월간 순위 이용 통계를 살펴보았습니다. 1위를 차지한 OpenAI의 text-embedding-3-small은 월간 약 6억 6,000만 리퀘스트에 달하며, 2위인 Qwen3 Embedding 8B(약 2억 3,100만)나 3위인 Gemini Embedding 2(약 1억 2,700만)를 크게 앞서고 있습니다.

물론 OpenRouter의 수치가 개발자 커뮤니티 전체를 대표하는 것은 아닙니다. 하지만 OpenAI 공식 문서에서도 여전히 주력 모델로 다루어지고 있으며, LlamaIndex 같은 프레임워크에서도 신규 프로젝트 초기 설정으로 권장되고 있다는 점에서 현장에서 뿌리 깊게 사용되고 있는 실태를 엿볼 수 있습니다.

하지만 이렇게 광범위하게 보급되었다고 해서 모든 검색 작업에서 최선의 선택지인 것은 아닙니다. 특히 일본어, 베트남어 등 다국어 데이터를 다루는 RAG (Retrieval-Augmented Generation) 시스템의 경우, 정말 이대로 괜찮은지 멈춰서 검증할 가치가 있습니다.

몇 달 전, 사내 챗봇 개발 중 까다로운 오류에 직면했습니다. 회사 위키에 답이 그대로 적혀 있는 질문임에도 불구하고, 챗봇이 '충분한 정보가 없습니다'라고 답변하거나 사실과 다른 내용(환각, Hallucination)을 답변하는 보고가 연달리 발생했습니다.

해당 시스템의 RAG 파이프라인은 일반적인 2단계 검색 구성을 취하고 있었습니다:

• 1단계 (벡터 검색): Embedding을 사용하여 데이터베이스에서 상위 50개 후보 청크를 가져옴
• 2단계 (재순위화, Re-ranking): Cross-encoder를 사용하여 50개를 재평가하고, 상위 5~10개를 LLM에 전달

검색 로그를 자세히 조사한 결과, 원인은 금방 밝혀졌습니다. 베트남어나 일본어 질의에서 text-embedding-3-small은 정답 문서 중 하나를 60위 근처에 배치하고, 관련 다른 문서는 100위권 밖에 가라앉히는 문제가 발생했던 것입니다.

리랭커는 손에 들어온 후보들 내에서만 순위를 바꿀 수 있습니다. 1단계 벡터 검색에서 상위 50개 안에 들지 못하면, 리랭커는 정답 문서를 평가조차 할 수 없습니다. LLM에는 맥락으로 부적절한 노이즈만 전달되기 때문에, 프롬프트를 아무리 고안하거나 모델의 파라미터를 조정해도 애초에 손에 없는 정보를 답변하는 것은 불가능합니다.

이번 검증에서는 Embedding 모델을 Gemini Embedding 2로 변경한 결과, 정답 문서가 1단계 상위 5~10위 이내에 안정적으로 부상하며 문제가 해결되었습니다.

물론, 이 전환에는 사내 문서를 Gemini의 벡터 공간에 맞게 모두 재임베딩(Re-indexing)해야 하는 과정이 필요했습니다. 서로 다른 모델 간에 질의 벡터와 저장된 벡터를 대조하는 것은 수학적 공간 자체가 완전히 다르기 때문에 불가능합니다.

또한, Embedding 모델을 교체하는 것만이 유일한 해결책은 아닙니다. BM25를 이용한 키워드 검색과 결합한 하이브리드 검색(Hybrid Search)을 도입하는 것도 완전 일치 단어를 포착할 수 있는 효과적인 접근법입니다. 다만, 사용자의 표현 방식과 문서의 서술이 다른 경우에는 역시 Embedding 모델 자체의 의미 이해력이 중요해집니다.

성능 면에서 뛰어난 후발 주자 모델들이 등장하는 와중에, 왜 text-embedding-3-small은 이렇게 널리 사용되고 있을까요? 기술적인 우위성보다는 생태계가 가진 관성이 주요 원인입니다.

많은 RAG 해설 기사, LangChain의 튜토리얼, GitHub의 스타터 키트에서는 기본 모델로 text-embedding-3-small이 지정되어 있습니다. 개발자가 프로토타입을 구축할 때 준비된 샘플 코드를 그대로 사용하는 것이 가장 자연스러운 흐름입니다.

from langchain_openai import OpenAIEmbeddings
# 한 번 작성하면 재검토하기 어려운 초기 설정
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

프로토타입이 실용 단계나 운영 환경으로 전환되어도, 초기 검증에서 표면적으로 작동했던 기반 컴포넌트를 굳이 교체하는 경우는 많지 않습니다. 공식 문서에 기재된 초기 설정이 그대로 운영의 표준(standard)이 되어갑니다.

영어 문서 검색에서 text-embedding-3-small은 많은 상황에서 문제없이 기능합니다. 영어 태스크를 모은 벤치마크(MTEB)에서도 62.3%를 기록했으며, 리랭커(reranker)를 병용할 경우 치명적인 검색 오류로 드러나기 어려운 것이 현실입니다.

또한, 세상에 유통되는 기술 데모의 상당수가 영어를 전제로 구성되어 있어, 다른 언어를 본격적으로 투입하기 전까지는 약점에気づきにくい 배경도 있습니다.

이전을 망설이게 하는 가장 현실적인 요인은 인덱스 재구축에 필요한 노력과 위험성입니다.

Pinecone, Qdrant, pgvector와 같은 벡터 데이터베이스 자체가 특정 모델에 묶여 있는 것은 아닙니다. 새로운 모델을 채택하려면 저장된 문서의 모든 벡터를 다시 생성하고 인덱스를 처음부터 만들어야 합니다.

이미 수백만 청크(chunk) 규모의 데이터를 운영하는 기업에게 있어, 전체 문서 재임베딩, 차원 설정 변경, 유사도 임계값 재조정은 상당한 계산 비용과 엔지니어링 공수를 필요로 합니다. 결과적으로 '작동하고 있다면 건드리지 않는다'는 태도로 미뤄지기 쉽습니다.

100만 토큰당 0.02달러라는 가격은 월별 클라우드 청구서에서 거의 오차 범위에 들어옵니다. 인프라 비용이 월 수십 원에서 수백 원 수준으로 해결되는 상황에서, 굳이 공수를 들여 최적화하려는 동기는 경영적인 관점과 엔지니어의 시점 모두에서 생겨나기 어렵다고 할 수 있습니다.

text-embedding-3-small이 단순한 체념을 넘어 실제 과제가 되기 쉬운 부분이 바로 다국어 환경에서의 검색입니다.

OpenAI 발표 당시, 영어 벤치마크(MTEB)에서는 62.3%였던 반면, 다국어 검색 벤치마크(MIRACL)에서는 44.0%로 보고되었습니다. 이들은 평가 설계가 다른 별개의 벤치마크이므로, 수치의 차이를 그대로 성능 저하 폭으로 비교할 수는 없지만, 다국어 검색이 다른 난이도를 가지고 있음을 보여줍니다.

다국어 검색의 품질은 단순히 단어를 어떻게 분리하는지(토큰화, tokenization)뿐만 아니라, 학습 데이터셋의 언어 비율이나 서로 다른 언어 간에 개념이 얼마나 깔끔하게 매핑되는지에 따라 크게 좌우됩니다. 추측으로 판단하기보다는, 자사 애플리케이션이 실제로 다루는 언어와 쿼리를 사용하여 직접 테스트해보는 것이 확실합니다.

가격이 저렴하다는 이유로 text-embedding-3-small을 계속 선택하는 팀도 적지 않습니다. 표준적인 텍스트 입력에 대한 API 비용 비교는 다음과 같습니다:

단가가 높은 모델이 항상 우월한 것은 아닙니다. 하지만 시스템 전체 운영 비용에서 임베딩 비용이 극히 일부라면, 얻을 수 있는 검색 품질 향상에 비해 충분히 가치 있는 투자가 될 수도 있습니다.

RAG 파이프라인 전체의 비용 구조에서 가장 큰 비중을 차지하는 것은 후단 LLM(GPT, Claude, Gemini 모델 등)의 추론 비용입니다. 검색 단계에서 관련 없는 문서를 가져오게 되면, LLM은 불필요한 맥락을 읽기 위해 풀 프라이스 토큰을 소비하고, 결과적으로 오답이나 환각(hallucination)을 내놓게 됩니다.

text-embedding-3-small을 계속 사용해야 할지, 아니면 다른 모델로 전환해야 할지는 다루는 데이터와 요구사항에 따라 판단이 달라집니다:

• 대상 문서가 완전히 영어이며, 사내 매뉴얼 같은 평이한 글이 중심인 경우
• 이미 정교한 리랭커나 BM25 하이브리드 검색이 작동하고 있어 일상적인 검색 패턴을 충족하는 경우
• 이미 수백만 건 규모의 인덱스가 존재하며, 현재 시점에서 이전 검증을 할 개발 자원이 투입되기 어려운 경우

일본어, 베트남어 등 비영어 데이터를 일상적으로 다루는 제품의 경우,"영어로 괜찮을 테니 문제없겠지"라고 과신하지 말고, 대상 언어에서의 검색 정확도를 개별적으로 확인하는 것을 추천합니다.

새로운 프로젝트를 시작할 경우. 처음부터 오래된 설정에 맞출 이유는 적으며, Gemini Embedding 2나 오픈 웨이트(open-weight)의 EmbeddingGemma 2 등 다국어 대응력이 높은 선택지를 초기 후보군에 포함시키는 것이 더 합리적입니다.

사용자로부터 "답변이 빠져있다", "검색 결과가 나오지 않는다"와 같은 불만이 올라오는 경우. 프롬프트를 수정하기 전에, 먼저 1단계 벡터 검색에서 정답이 몇 번째 순위로 포착되고 있는지 확인해 볼 가치가 있습니다.

text-embedding-3-small이 널리 사용되는 데에는 저렴함, 간편성, 인지도가 충분한 이유가 있습니다. 하지만 "모두가 사용하고 있다"는 이유만으로, 자사의 RAG 시스템에 가장 좋은 모델이라고 단정할 수는 없습니다.