RAG 파이프라인에서 임베딩 모델은 검색 품질의 천장을 결정합니다. 그런데 모델 종류가 너무 많아 무엇을 기준으로 골라야 할지 막막합니다. 이 글에서는 한국어 RAG를 전제로 임베딩 모델 선택 기준을 실무적으로 비교합니다.
기준 1: 다국어·한국어 성능
한국어 문서를 다룬다면 다국어 학습 데이터 비중과 한국어 벤치마크 점수를 먼저 봐야 합니다. 영어 전용 모델은 영어 벤치마크에서 아무리 높아도 한국어 의미 검색에서 무너지는 경우가 흔합니다. 가능하면 자신의 실제 문서로 작은 테스트셋을 만들어 직접 비교하는 것이 가장 확실합니다.
기준 2: 벡터 차원과 저장 비용
차원이 높을수록 표현력은 좋아지지만 저장 공간과 검색 지연이 늘어납니다. 1024차원과 384차원은 메모리 사용량이 거의 3배 차이가 납니다. 문서가 수백만 건이라면 차원 수가 인프라 비용에 직접 반영됩니다.
- 384차원: 가볍고 빠름, 대규모 인덱스에 유리
- 768차원: 균형점, 가장 보편적
- 1024차원 이상: 표현력 우수, 비용과 지연 증가
기준 3: 최대 입력 길이
임베딩 모델마다 한 번에 처리 가능한 토큰 한도가 다릅니다. 512토큰 한도 모델에 800토큰 청크를 넣으면 뒷부분이 잘려 의미가 손실됩니다. 청킹 전략과 임베딩 모델의 입력 한도는 반드시 함께 설계해야 합니다.
기준 4: 호스팅 방식과 비용
API형 임베딩은 도입이 쉽지만 호출량이 많으면 비용이 누적되고 외부로 데이터가 나갑니다. 오픈 모델을 자체 호스팅하면 데이터 통제와 단가는 좋아지지만 GPU 운영 부담이 생깁니다. 민감 데이터가 있다면 자체 호스팅이 사실상 필수입니다.
벤치마크 1위 모델이 우리 데이터에서도 1위라는 보장은 없습니다. 공개 리더보드는 후보를 좁히는 용도로만 쓰고, 최종 선택은 자체 평가셋으로 검증하세요.
흔한 실수
가장 흔한 실수는 한 번 고른 임베딩 모델을 나중에 바꾸는 것을 가볍게 보는 것입니다. 모델을 바꾸면 전체 문서를 다시 임베딩해야 하므로, 수백만 건 규모에서는 상당한 시간과 비용이 듭니다. 그래서 처음 선택 시 확장성을 함께 고려해야 합니다. 또 다른 실수는 질문과 문서를 서로 다른 모델로 임베딩하는 것으로, 이 경우 벡터 공간이 달라 검색이 전혀 동작하지 않습니다.
정리
임베딩 모델은 한국어 성능, 차원, 입력 길이, 호스팅 비용의 네 축으로 비교하고, 최종 결정은 반드시 자체 데이터로 검증하세요. 작은 평가셋 하나가 리더보드 100개보다 정확한 답을 줍니다.
