임베딩 검색, 정말 만능일까?

요즘 사내 검색 시스템을 구축할 때 가장 먼저 떠오르는 키워드는 단연 벡터 임베딩입니다. OpenAI의 text-embedding 모델이든, 한국어 특화 모델이든, 문장을 벡터로 변환해서 의미 기반으로 검색하면 모든 게 해결될 것 같죠. 하지만 실제로 사내 문서 검색 시스템을 운영해 보면, 임베딩만으로는 해결이 안 되는 영역이 분명히 존재합니다.

특히 약어, 코드네임, 프로젝트명이 난무하는 한국어 사내 환경에서는 오히려 전통적인 키워드 검색 알고리즘인 BM25가 놀라울 정도로 강한 성능을 보여줍니다. 오늘은 그 이유를 실제 사례와 함께 정리해 보겠습니다.

BM25란 무엇인가?

BM25(Best Matching 25)는 정보 검색 분야에서 수십 년간 사용되어 온 확률 기반 키워드 검색 알고리즘입니다. 핵심 원리는 간단합니다.

• TF(Term Frequency): 검색어가 문서에 자주 등장할수록 관련성이 높다
• IDF(Inverse Document Frequency): 전체 문서에서 드물게 등장하는 단어일수록 중요하다
• 문서 길이 정규화: 긴 문서가 단순히 단어가 많다는 이유로 상위에 오르지 않도록 보정한다

Elasticsearch, Apache Solr 같은 검색 엔진의 기본 랭킹 알고리즘이 바로 이 BM25입니다. “구식”이라 무시하기엔 아직도 현역에서 매우 잘 작동하는 알고리즘이죠.

임베딩 검색이 약한 세 가지 상황

1. 사내 약어와 코드네임

회사마다 고유한 약어 체계가 있습니다. 예를 들어볼까요?

• “PJT-블루오션”이라는 프로젝트명
• “CCR”이라는 사내 시스템 약자 (고객 불만 접수 시스템)
• “K8S 마이그레이션 TF”라는 조직명

임베딩 모델은 이런 약어를 학습 데이터에서 본 적이 없기 때문에, 의미를 제대로 이해하지 못합니다. “CCR 장애 대응 매뉴얼”을 검색하면, 임베딩 검색은 “고객 불만 처리”와 관련된 일반적인 문서를 반환할 수도 있고, 전혀 엉뚱한 결과를 보여줄 수도 있습니다. 반면 BM25는 “CCR”이라는 문자열 자체를 정확히 매칭하기 때문에, 해당 약어가 포함된 문서를 빠짐없이 찾아냅니다.

2. 한국어-영어 혼용 환경

한국 기업의 사내 문서는 한국어와 영어가 자유롭게 섞입니다. “deploy 전에 QA 사인오프 받아야 합니다”처럼 한 문장 안에 두 언어가 공존하죠. 대부분의 임베딩 모델은 단일 언어에 최적화되어 있어서, 이런 코드스위칭(code-switching) 텍스트의 의미를 정확히 포착하기 어렵습니다.

BM25는 언어를 구분하지 않습니다. “deploy”라는 단어가 문서에 있으면 그냥 매칭합니다. 이 단순함이 오히려 혼용 환경에서는 큰 장점이 됩니다.

3. 정확한 고유명사 검색

“2026년 1분기 매출 리포트”, “v2.3.1 릴리즈 노트”처럼 버전 번호, 날짜, 특정 식별자를 포함한 검색에서 임베딩 검색은 유독 약합니다. 임베딩 모델은 “2.3.1”과 “2.3.2”의 의미 차이를 거의 구분하지 못하지만, BM25는 정확한 문자열 일치를 기반으로 하므로 이런 검색에서 실수하지 않습니다.

실전에서 확인한 BM25의 강점

실제로 한 IT 기업에서 사내 위키 검색 시스템을 구축하면서 임베딩 검색과 BM25를 비교 테스트한 결과가 있습니다. 약 5만 건의 사내 문서를 대상으로 200개의 실제 검색 쿼리를 테스트했을 때, 결과는 흥미로웠습니다.

• 일반적인 개념 검색(“신입사원 온보딩 절차”): 임베딩 검색 승리
• 약어 포함 검색(“ERP 연동 API 스펙”): BM25 승리
• 코드네임 검색(“프로젝트 피닉스 회의록”): BM25 압도적 승리
• 버전/날짜 검색(“v3.2 핫픽스 내역”): BM25 압도적 승리

전체적으로 보면 임베딩이 우세한 경우도 많았지만, 사내 특수 용어가 포함된 쿼리에서는 BM25가 일관되게 더 좋은 결과를 보여줬습니다.

가장 현실적인 답: 하이브리드 검색

그렇다면 BM25만 쓰면 될까요? 물론 아닙니다. 의미 기반 검색의 장점도 분명히 존재합니다. “재택근무 신청 방법”으로 검색했을 때 “원격 근무 가이드”라는 제목의 문서를 찾아주는 건 임베딩 검색만 할 수 있는 일이니까요.

현실적인 최적의 방법은 하이브리드 검색(Hybrid Search)입니다. 구현 방식은 다음과 같습니다.

• BM25 스코어와 벡터 유사도 스코어를 각각 계산
• 두 스코어를 가중 합산하여 최종 랭킹 결정
• 약어나 고유명사가 포함된 쿼리에는 BM25 가중치를 높이고, 자연어 질문에는 임베딩 가중치를 높이는 동적 가중치 조정 적용

이를 지원하는 도구도 이미 충분합니다. Elasticsearch 8.x는 kNN 벡터 검색과 BM25를 동시에 지원하고, Weaviate나 Qdrant 같은 벡터 DB도 하이브리드 검색 기능을 내장하고 있습니다.

BM25 성능을 더 끌어올리는 팁

사내 환경에서 BM25의 성능을 극대화하려면 몇 가지 튜닝이 필요합니다.

사내 약어 사전 구축

“CCR → 고객 불만 접수 시스템”처럼 약어를 풀어 쓴 동의어 사전을 만들어 검색 시 확장하면 BM25의 재현율(recall)이 크게 올라갑니다. Elasticsearch의 synonym filter를 활용하면 간단히 적용할 수 있습니다.

한국어 형태소 분석기 적용

Nori(노리) 같은 한국어 전용 형태소 분석기를 적용하면 “검색했습니다”, “검색하는”, “검색할” 같은 활용형을 모두 “검색”으로 정규화해서 검색 품질이 향상됩니다.

필드별 가중치 차등 적용

문서 제목에 등장하는 키워드는 본문에 등장하는 것보다 중요도가 높습니다. BM25 쿼리에서 title 필드에 boost 값을 높게 설정하면 더 정확한 결과를 얻을 수 있습니다.

마무리: 새것이 항상 좋은 것은 아니다

AI 시대에 “키워드 검색”이라니 시대착오적으로 느껴질 수도 있습니다. 하지만 기술 선택은 유행이 아니라 실제 데이터의 특성에 맞춰야 합니다. 약어와 코드네임이 가득한 사내 문서 환경에서는 BM25가 여전히 강력한 도구입니다.

임베딩 검색을 도입하기 전에, 먼저 자사의 문서 특성을 분석해 보세요. 그리고 BM25를 기본으로 깔고, 의미 검색을 보완적으로 얹는 하이브리드 전략을 고려해 보시길 추천합니다. 가장 단순한 방법이 가장 효과적일 때가 많으니까요.

Photo by Markus Spiske on Pexels