한국어 임베딩, 아직도 bge-m3 쓰세요? — ko-embedding-leaderboard가 보여주는 세대교체

트렌딩 오픈소스를 까보는 시리즈다. 이번에도 출발점은 “이 코드가 잘났나”가 아니라 “사람들이 왜 이걸 원했나”다. ko-embedding-leaderboard는 개인이 유지보수하는 한국어 임베딩 모델 리더보드다. MTEB를 한국어 데이터셋으로 커스터마이즈해서 오픈소스 임베딩 모델들의 검색 성능을 재고 순위표를 README에 올려둔다. 별표는 이제 두 자리지만 한국어로 RAG를 만드는 사람이라면 누구나 부딪히는 질문에 답하는 물건이라 들여다볼 가치가 있다.

왜 한국어 전용 리더보드가 따로 필요한가

임베딩 모델을 고르려는 사람이 제일 먼저 여는 건 Hugging Face의 MTEB 리더보드다. 그리고 대부분 거기서 막힌다. 상위권은 수십억 파라미터짜리 다국어 모델이 점령하고 있는데 그 점수는 수십 개 언어의 평균이다. 다국어 평균이 높다는 것과 한국어 검색을 잘한다는 건 다른 명제다. 실제로 다국어 모델들이 번역된 벤치마크에서는 점수가 잘 나오다가 네이티브 한국어 데이터에서는 성능이 크게 떨어지는 현상이 반복적으로 보고돼 왔다. 번역 벤치마크는 영어 문장 구조를 그대로 옮긴 텍스트라서 실제 한국어 사용자가 던지는 질의와는 분포 자체가 다르기 때문이다.

그래서 커뮤니티에는 같은 질문이 계속 올라온다. “한국어에 특화된 성능 좋은 임베딩 모델 찾고 있습니다.” 이 질문에 MTEB는 답을 못 주고, 모델 제작사의 자체 벤치마크는 못 믿겠고, 그래서 제3자가 같은 조건으로 재준 순위표가 필요해진다. 수요가 진짜라는 증거는 공급이 여럿이라는 데 있다. 이 리더보드 말고도 su-park/mteb_ko_leaderboard, 고려대 연구실이 KURE를 공개하며 함께 만든 MTEB-ko-retrieval 등 한국어 임베딩 순위표가 독립적으로 여럿 생겼다. 같은 가려움을 서로 모르는 사람들이 각자 긁기 시작한 것이다.

ko-embedding-leaderboard의 방법론에서 눈여겨볼 건 버전 2로 넘어오면서 내린 결정이다. 클러스터링과 NLI 평가를 버리고 검색(IR) 하나만 남겼다. 7개 한국어 검색 데이터셋(멀티홉 QA인 Ko-StrategyQA, 금융·공공·의료·법률 도메인 문서를 모은 AutoRAGRetrieval, 보건 QA, 법률 검색, 웹 FAQ, 한국어 SQuAD, 그리고 어려운 오답 후보를 섞은 MIRACL)에서 NDCG@5와 NDCG@10의 평균으로 줄을 세운다. 리포가 잘라낸 이유를 길게 설명하지는 않지만 짐작은 어렵지 않다. 2026년에 임베딩 모델을 고르는 사람의 목적은 사실상 하나, RAG의 검색 품질이다. 문장 유사도 점수가 아니라 내 질문에 맞는 문서를 위에 올려주는지가 임베딩의 존재 이유가 됐고 리더보드도 거기에 맞춰 몸을 줄였다.

순위표에서 읽어야 할 세 가지

2026년 7월 기준 밀집(dense) 임베딩 상위권은 이렇다.

첫째, 한국어 파인튜닝이 모델 크기를 이기고 있다. 1위 pplx-embed-v1-4b는 Perplexity가 올해 2월에 공개한 4B 파라미터짜리 프런티어 임베딩이다. 그런데 2위 snowflake-arctic-embed-l-v2.0-ko는 568M, 7배 작은 모델이고 격차는 0.65점이다. 이 모델은 Snowflake의 다국어 임베딩을 허깅페이스의 한 개인 계정(dragonkue)이 한국어 데이터로 파인튜닝한 물건인데 원본 arctic-embed-l-v2.0이 같은 벤치마크에서 80.00으로 7위라는 걸 보면 그림이 선명해진다. 같은 모델에 한국어 파인튜닝을 얹은 것만으로 2점이 올라 4B들을 제쳤다. KURE-v1도 같은 패턴이다. bge-m3(79.30)를 고려대 NLP&AI 연구실이 한국어 질의-문서 쌍 200만 개로 파인튜닝해서 80.76을 만들었다. LLM 쪽에서는 “언어 특화 파인튜닝은 프런티어 모델 한 세대면 따라잡힌다”는 회의론이 우세해졌지만 적어도 임베딩에서는 아직 특화가 크기를 이기는 구간이 남아 있다.

둘째는 국룰의 유통기한이다. bge-m3는 2024년 초부터 한국어 임베딩의 안전한 기본값이었다. 다국어 지원에 8192 토큰 컨텍스트, 준수한 한국어 성능까지 갖춰서 지금도 국내 RAG 튜토리얼 대부분이 이 모델을 예제로 쓴다. 그 bge-m3가 지금 8위다. 심지어 bge-m3를 베이스로 쓴 KURE-v1보다 1.5점 아래다. 잘못된 선택이 됐다는 게 아니다. 이 휴리스틱이 만들어진 2024년과 지금 사이에 선택지가 통째로 물갈이됐고, 튜토리얼 복붙으로 시작한 RAG 스택이라면 임베딩 칸에 2년 전 답이 박제돼 있을 확률이 높다.

셋째, 평균 점수 뒤에는 30점짜리 분산이 숨어 있다. 같은 1위 모델도 데이터셋별로 보면 한국어 SQuAD에서 93.91, MIRACL 하드네거티브에서 65.60이다. 어려운 오답 후보를 섞어놓은 데이터셋에서는 모든 모델이 60점대로 주저앉고 법률 검색에서도 70점대 중반이 상한이다. 순위가 1~5위 안에서 1점 단위로 갈리는 동안 도메인 간 편차는 30점 단위로 벌어진다는 것, 이게 실무에서는 순위보다 중요한 정보다. 내 문서가 법률·의료처럼 도메인 용어가 지배하는 코퍼스라면 리더보드 평균 1점 차이는 내 데이터에서 얼마든지 뒤집힌다.

하나 더, 밀집 모델 표 옆에 스파스(sparse) 표가 따로 있다는 것 자체가 정보다. SPLADE 계열 한국어 모델들이 77~78점, 밀집 중위권과 겹치는 점수를 내는데 이 모델들의 출력은 토큰 단위 가중치라서 Elasticsearch 같은 역색인에 그대로 얹을 수 있고 어떤 토큰이 매칭됐는지 눈으로 확인할 수 있다. 이미 키워드 검색 인프라가 있는 조직이라면 벡터 DB를 새로 들이지 않고 검색 품질을 올리는 경로가 되고 밀집 벡터와 섞는 하이브리드 검색의 재료로도 쓰인다. pgContext(#41)에서는 하이브리드 검색이 DB 확장 안으로 들어왔는데, 그 하이브리드의 스파스 쪽 자리에 BM25 대신 들어갈 후보들이 여기 줄 서 있다.

누가 만들고 있나

순위표에서 모델 이름 앞의 조직명만 훑어도 재미있는 그림이 나온다. 상위권을 채운 건 빅테크의 다국어 모델(Perplexity, Qwen, Snowflake, Google), 고려대 연구실(KURE), 그리고 개인 계정과 국내 스타트업이다. 2위 모델은 개인의 파인튜닝이고, 3위 PIXIE-Rune과 스파스 1위 PIXIE-Splade를 만든 텔레픽스(TelePIX)는 위성영상 분석이 본업인 회사다. KURE를 만든 연구실 출신 저자는 개인 자격으로 한국어 SPLADE 모델(splade-ko-v1)도 올려놨다.

빅테크는 한국어만을 위한 임베딩을 만들지 않는다. 한국어는 늘 다국어 모델의 74개 언어 중 하나로 커버되고 그 커버리지와 실사용 품질 사이의 갭을 연구실 하나, 개인 몇 명, 스타트업 몇 곳이 파인튜닝으로 메우고 있다. 리더보드 유지보수자까지 포함하면 한국어 검색 품질이라는 공공재가 사실상 소수의 자발적 기여로 돌아가는 셈이다. 반대로 말하면 이 판은 진입장벽이 낮다. 좋은 베이스 모델과 잘 만든 한국어 학습 데이터만 있으면 개인이 4B 프런티어 옆에 이름을 올릴 수 있다. 2위가 그 증거다.

실전: 지금 한국어 임베딩을 골라야 한다면

리더보드를 읽는 법까지 왔으니 선택 기준으로 정리하자.

1. 기본값은 한국어 파인튜닝 568M 둘 중 하나다. snowflake-arctic-embed-l-v2.0-ko와 KURE-v1. 둘 다 1024차원, 8192 토큰, sentence-transformers로 바로 서빙되고 GPU 한 장이면 충분한 크기다. 리더보드 점수는 전자가 1.4점 높지만 이 정도 차이는 도메인에 따라 뒤집히는 수준이니 라이선스와 자기 데이터 평가로 가르는 게 맞다. 4B급(pplx-embed, Qwen3-Embedding-4B)은 점수 1~2점을 위해 서빙 비용과 지연시간을 몇 배로 치를 가치가 있는지부터 계산하고 들어가자. pplx-embed는 INT8 네이티브 양자화가 들어 있어서 4B치고는 메모리 부담이 덜하다는 게 변수다.

2. 이 리더보드에 없는 선택지를 잊지 마라. 여기 실린 건 오픈소스뿐이다. OpenAI, Voyage, Upstage 같은 API 임베딩은 평가 대상 밖이라 여기서의 1위는 오픈소스 중 1위지 전체 1위가 아니다. 다만 API 임베딩은 문서가 늘 때마다 과금이 따라오고 임베딩을 바꾸면 전량 재색인해야 하니, 벤더 종속이 벡터 개수만큼 쌓인다는 점도 저울에 함께 올려야 한다.

3. 자기 데이터로 100쿼리짜리 평가셋을 만들어라. 도메인 편차 30점의 세계에서 남의 평균 1점 차이로 결정을 내리는 건 순서가 틀렸다. 실제 사용자 질의(없으면 예상 질의) 100개에 정답 문서를 매겨놓고 후보 모델 두세 개로 NDCG@10을 재는 데 하루면 된다. 임베딩 교체는 전체 재색인을 동반하는 비싼 결정이라 나중에 무를수록 비싸진다. 처음에 하루를 쓰는 게 남는 장사다.

4. 벤치마크 점수는 상한이 아니라 참고치다. 평가 데이터셋이 공개돼 있다는 건 학습 데이터에 섞여 들어갈 수 있다는 뜻이고 실제로 리더보드 상위권 경쟁이 치열해질수록 벤치마크 과적합의 유인도 커진다. 순위표는 후보를 3개로 좁히는 데 쓰고 최종 결정은 3번의 자기 데이터 평가로 내리는 게 안전하다.

관전 포인트

#41에서 “벡터를 어디에 넣을까”가 Postgres로 수렴하는 걸 봤다면, 이번엔 “그 벡터를 뭘로 만들까”의 답이 한국어에서는 아직 수렴하지 않았다는 걸 봤다. 다국어 프런티어가 반년마다 갱신되고 그때마다 한국어 파인튜너들이 몇 주 안에 그 위에 한국어 특화판을 얹는 추격전이 반복되고 있다. 이 리듬이 유지되는 동안은 최신 다국어 모델이 아니라 그 모델의 한국어 파인튜닝판이 정답 후보의 자리를 지킬 거다.

지켜볼 변수는 두 가지다. 하나는 프런티어 다국어 임베딩이 한국어 파인튜닝의 우위를 흡수해버리는 시점이 오는가(pplx-embed가 파인튜닝 없이 1위를 차지한 건 그 전조일 수 있다). 다른 하나는 이 공공재 인프라의 지속가능성이다. 리더보드도, 상위권 파인튜닝도 상당 부분 개인의 자발적 기여로 돌아가고 있어서 이 사람들이 지치면 한국어 임베딩 생태계의 지도가 다시 안개 속으로 돌아간다. 별표 하나, 평가 요청 이슈 하나가 실제로 의미 있는 기여가 되는 드문 동네다.