1. RAG 검색 60% 문제를 해결하는 BM25 키워드 검색과 1원짜리 질의 재작성 가이드
최근 인공지능 기술의 급격한 발전과 함께 거대언어모델(LLM)을 사내 업무나 서비스에 접목하려는 시도가 폭발적으로 증가했다.
그 중심에는 언제나 검색 증강 생성(Retrieval-Augmented Generation, RAG) 기술이 자리 잡고 있다. 인공지능이 사전에 학습하지 못한 기업 내부의 비공개 데이터나 실시간 최신 정보를 검색하여 정확한 답변을 생성하도록 돕는 이 기술은 생성형 인공지능 도입의 표준 경로로 자리매김했다.
그러나 시장의 뜨거운 관심 속에서 수많은 조직이 심각한 기술적 함정에 빠져들고 있는 실정이다.
대다수의 엔지니어링 팀과 기획 부서에서는 RAG 시스템을 구축한다고 하면 가장 먼저 고가의 상용 벡터 데이터베이스(Vector DB)를 구독하고, 최신 딥러닝 기반 텍스트 임베딩 모델을 선정하며, 복잡한 재순위화(Reranking) 파이프라인을 설계하는 데 착수한다.
이는 업계 전반에 퍼진 일종의 유행이자 기술적 허영심에 가깝다. 실제 서비스 현장에서 발생하는 정보 검색 문제의 상당수는 이처럼 거창하고 비싼 고도화 기술을 전혀 필요로 하지 않는다는 것이다.
RAG 검색 구조의 거품을 걷어내고, 복잡한 딥러닝 임베딩 대신 전통적인 키워드 검색 엔진인 BM25와 저비용 거대언어모델을 결합한 질의 재작성(Query Rewriting) 기법만으로도 실무 문제의 60% 이상을 압도적인 속도와 최저 비용으로 해결할 수 있는 논리적 배경과 기술적 아키텍처를 상세하게 살펴보고자 한다.
2. RAG 검색 본질과 엔지니어링의 치명적인 함정
검색 증강 생성(RAG)의 기본 구조는 비개발자의 시각에서 바라보았을 때 매우 직관적이다.
도서관에서 책을 찾아주는 전문 사서와 방문객의 상호작용을 떠올리면 이해하기 쉽다. 방문객이 사서에게 질문을 던지면, 사서는 서가로 달려가 관련 있는 서적 몇 권을 뽑아온 뒤(Retrieval), 그 책들의 내용을 종합하여 방문객에게 친절한 문장으로 정리해 답변을 건넨다(Generation).
여기서 서가에서 책을 골라오는 과정이 바로 검색 파이프라인이며, 이 검색 단계가 부실하면 아무리 말을 유창하게 잘하는 사서라 할지라도 엉뚱한 거짓말을 지어내는 환각 현상(Hallucination)을 피할 수 없다.
문제는 서가에서 책을 찾는 방식에서 비롯된다. 현재 인공지능 업계는 텍스트를 고차원 숫자 배열로 변환하는 ‘임베딩(Embedding)’ 기술을 맹신하는 경향을 보인다.
문장의 의미와 문맥적 뉘앙스를 수학적 거리로 계산하는 벡터 검색은 언뜻 보기에 인간의 사고방식과 유사한 고도의 지능형 검색처럼 느껴진다. 예를 들어 “배가 고플 때 간단히 먹을거리”라는 입력을 넣었을 때, 본문에 ‘배’나 ‘음식’이라는 단어가 직접 적혀 있지 않아도 ‘컵라면 조리법’이나 ‘삼각김밥 보관법’을 기막히게 찾아내는 마법 같은 능력을 보여주기 때문이다.
하지만 이러한 의미론적(Semantic) 접근 방식은 현실의 기업 환경에서 커다란 부작용을 낳는다.
기업 내부의 실무 문서는 시적 표현이나 추상적인 은유로 가득 찬 문학 작품이 아니다. 대부분의 비즈니스 데이터는 계약서 번호, 소프트웨어 오류 코드, 고객 식별자(ID), 특허 번호, 사내 시스템 프로젝트 코드명 등 명확하고 구체적인 고유명사로 이루어져 있다. 이러한 환경에서 의미 기반의 벡터 검색은 오히려 치명적인 취약점을 드러낸다.
“오류 코드 403과 404의 차이점”을 물었을 때, 임베딩 모델은 두 숫자가 지닌 의미적 유사도에 취약하여 403 에러 문서와 404 에러 문서를 뒤죽박죽 섞어서 가져오는 실수를 범한다.
이보다 더 심각한 것은 시스템 구축과 운영에 들어가는 엄청난 엔지니어링 비용과 관리 오버헤드다.
텍스트를 벡터로 변환하여 저장하려면 문서를 적절한 크기로 자르는 ‘청킹(Chunking)’ 작업이 필수적이다. 문서를 500자 단위로 자를 것인지, 1,000자 단위로 자를 것인지, 앞뒤 문맥을 얼마나 겹치게 할 것인지(Overlap)를 결정해야 한다.
또한 모델을 서비스 도중에 더 좋은 최신 모델로 업그레이드할 경우, 과거에 저장해 둔 수백만 건의 문서를 처음부터 끝까지 전부 다시 변환(Re-embedding)해야 하는 막대한 클라우드 컴퓨팅 비용과 서비스 중단 위험이 뒤따른다.
결국 수많은 기업이 실제로는 단순한 키워드 매칭만으로도 충분히 풀 수 있는 ‘60% 수준의 평범한 문제’를 해결하기 위해, 상위 5%의 고도화된 연구소에서나 다룰 법한 극도로 복잡하고 불안정한 인프라 파이프라인을 억지로 끌어안고 끙끙 앓고 있는 형국이다.
이것이 바로 현재 생성형 인공지능 도입 현장에서 가장 흔하게 목격되는 과잉 엔지니어링(Over-engineering)의 실체라는 것이다.
3. RAG 검색 기초가 되는 BM25 키워드 검색의 압도적인 강점
과잉 엔지니어링의 늪에서 벗어나기 위한 가장 확실한 출발점은 오랜 기간 정보 검색(Information Retrieval, IR) 분야에서 검증되어 온 전통적인 전문 검색(Full-Text Search) 기술로 회귀하는 것이다. 그 대표 주자가 바로 BM25(Best Matching 25) 알고리즘이다.
BM25는 웹의 여명기부터 구글과 같은 대형 검색 엔진의 뼈대를 이루었던 역문서 빈도(TF-IDF) 계열의 확률론적 검색 알고리즘이다.
원리는 명료하다.
사용자가 검색창에 입력한 단어가 특정 문서 안에 얼마나 자주 등장하는지(단어 빈도, TF)를 확인하고, 동시에 그 단어가 전체 문서 집합에서 흔하게 나타나는 흔한 단어인지 아니면 매우 드물게 등장하는 특별한 단어인지(역문서 빈도, IDF)를 계산하여 순위를 매긴다.
또한 문서의 길이가 지나치게 길어서 단순히 단어가 많이 들어간 문서가 부당하게 높은 점수를 받지 않도록 문서 길이에 따른 정규화 페널티를 부여한다. 쉽게 말해 책의 맨 뒤에 붙어 있는 ‘찾아보기 색인(Index)’ 목록을 시스템이 초고속으로 대조하는 작업이다.
ㄱ. BM25 기반 전문 검색이 최신 임베딩 파이프라인을 압도하는 첫 번째 강점은 경이적인 응답 속도와 제로에 가까운 비용이다.
고가의 GPU 서버나 인공지능 전용 가속기 없이도 일반적인 CPU 환경에서 수백만 건의 문서를 10밀리초(ms, 0.01초) 미만의 찰나에 찾아낸다. 상용 인공지능 API를 호출할 필요가 없으므로 검색 1건당 발생하는 클라우드 API 호출 요금은 정확히 0원이다.
초기 시스템을 구축하는 단계에서 별도의 벡터 데이터베이스를 라이선스 구매하거나 인프라 클러스터를 구축할 필요도 없다. 이미 전 세계 수많은 엔터프라이즈 환경에서 표준으로 널리 사용 중인 엘라스틱서치(Elasticsearch)나 오픈서치(OpenSearch), 심지어 대중적인 관계형 데이터베이스인 포스트그레스큐엘(PostgreSQL)의 내장 전문 검색 기능만 켜도 즉각적으로 구현이 가능하다.
ㄴ. 디버깅과 품질 검증의 완벽한 투명성이다.
딥러닝 기반 임베딩 검색은 결과가 잘못 나왔을 때 원인을 규명하기가 극도로 어렵다.
“왜 A 문서 대신 전혀 상관없는 B 문서가 검색되었는가?”라는 질문에 엔지니어는 “1,536차원의 벡터 공간상에서 코사인 유사도 점수가 0.02 높게 계산되었기 때문”이라는 무의미한 대답밖에 내놓지 못한다. 인공신경망 내부의 가중치 행렬은 블랙박스이기 때문이다.
반면 BM25는 명확한 수식에 기반한다. 어떤 키워드가 일치했고, 그 키워드의 가중치가 몇 점이며, 문서 길이 보정값이 얼마였는지가 수학적으로 100% 투명하게 노출된다. 결과가 이상하다면 불필요한 단어를 걸러내는 불용어(Stopwords) 사전을 고치거나, 오탈자를 교정하는 토크나이저 설정을 손보는 것만으로 즉각적인 품질 통제가 가능하다.
ㄷ. 문서 구조 파괴와 모델 종속성 위험으로부터의 완전한 자유다
BM25는 본래 문서 전체를 통째로 읽어 들여 단어의 출현 빈도를 분석하도록 설계된 알고리즘이다.
따라서 문맥을 인위적으로 512글자씩 토막 내는 가혹한 청킹 작업이 전혀 필요 없다. 원본 문서의 구조와 문맥이 고스란히 보존된 상태로 색인이 이루어진다.
게다가 인공지능 서비스 제공업체가 특정 임베딩 모델의 지원 종료(Deprecation)를 일방적으로 선언하더라도 시스템이 영향을 받지 않는다. 수학적 알고리즘 자체에는 유효기간이나 지원 종료라는 개념이 존재하지 않기 때문이다.
참조: 과거 주소 검색 시스템 구축 프로젝트에서 딥러닝 대신 TF-IDF 변형 엔진을 사용해 수많은 예외 처리와 중복 입력을 100% 통제했던 실무 사례가 있었음.
물론 BM25에도 뚜렷한 한계는 존재한다. 가장 대표적인 약점은 동의어와 다의어를 스스로 처리하지 못하는 ‘어휘 불일치(Vocabulary Mismatch)’ 문제다.
사용자가 “자동차”로 검색하면 본문에 “차량”이나 “오토모빌”이라고만 적혀 있는 훌륭한 문서를 완전히 지나쳐 버린다. 또한 사용자가 “어떻게 해야 하나요?”라거나 “지난번에 말했던 그 규정”과 같이 모호하고 대화체로 질문을 던질 경우, 문장 속에 의미 있는 명사 키워드가 희박하므로 검색 정확도가 곤두박질치게 된다. 바로 이 지점에서 대다수 팀이 성급하게 고비용 벡터 검색으로 갈아타는 우를 범하지만, 실제로는 훨씬 더 영리하고 경제적인 대안이 존재한다.
4. 1원짜리 LLM 질의 재작성으로 완성하는 초경량 RAG 검색
BM25의 유일한 단점인 어휘 불일치와 대화체 질문의 모호성을 해결하는 가장 우아하고 실용적인 해법은 문서를 인공지능으로 변환하는 것이 아니라, 사용자가 던진 ‘질문’을 인공지능으로 다듬는 것이다. 이것이 바로 ‘에이전트형 질의 재작성(Agentic Query Rewriting)’ 아키텍처다.
많은 엔지니어가 검색 품질이 떨어지는 이유가 검색기(Retriever)의 지능이 낮기 때문이라고 착각하지만, 실제 프로덕션 환경에서 발생하는 검색 실패의 대다수는 ‘질문 자체가 검색하기에 부적합하게 구성되었기 때문’에 발생한다. 사용자는 검색 엔진의 색인 원리를 알지 못하므로 일상적인 구어체로 길게 늘여서 질문을 던진다.
예를 들어 사용자가 “사내 메신저 슬랙 연동할 때 자꾸 타임아웃 오류가 나면서 안 되는데 어떻게 해결해야 하나요?”라고 길게 질문했다고 가정해 보자. 이 문장을 그대로 BM25에 던지면 ‘어떻게’, ‘해야’, ‘하나요’, ‘자꾸’ 같은 무의미한 일상어들이 검색 점수를 심각하게 오염시킨다.
이때 시스템 최전방에 GPT-4o-mini나 클로드 하이쿠(Claude Haiku)와 같은 극도로 저렴한 초경량 LLM을 전처리 비서로 배치하는 것이다. 이 경량 모델의 역할은 단 하나다. 사용자의 장황한 질문을 검색 엔진이 가장 이해하기 쉬운 핵심 키워드의 조합으로 다시 번역해 주는 것이다.
[사용자 원본 질의]
“사내 메신저 슬랙 연동할 때 자꾸 타임아웃 오류가 나면서 안 되는데 어떻게 해결해야 하나요?”[LLM 질의 재작성 프롬프트 처리 결과]
“슬랙 API 연동 타임아웃 에러 해결 가이드 오류코드 504 Timeout”
경량 모델이 불필요한 조사와 불용어를 깨끗하게 발라내고, ‘슬랙 연동 안 됨’이라는 문맥에서 ‘API 연동’, ‘타임아웃 에러’, ‘504 Timeout’과 같은 도메인 표준 전문 용어로 동의어를 대폭 확장(Query Expansion)해 준다. 이렇게 정갈하게 다듬어진 키워드 뭉치를 앞서 설명한 초고속 BM25 검색 엔진에 집어넣는 것이다.
이 방식의 경제성과 효율성은 압도적이다. 2026년 현재 상용 초경량 LLM을 통해 질문 하나를 재작성하는 데 소요되는 클라우드 비용은 질의 1건당 약 0.001달러, 한화로 환산하면 고작 1원에 불과하다. 하루에 1,000건의 검색이 발생하는 중소형 비즈니스라 할지라도 한 달 동안 지출되는 비용은 약 30달러(한화 약 4만 원) 수준에 그친다.
수백만 건의 원본 문서를 매달 벡터 데이터베이스에 유지하고 동기화하는 데 들어가는 수백, 수천 달러의 인프라 비용과 비교하면 사실상 무시할 수 있는 수준의 금액이다.
더욱 강력한 이점은 사내 독점 용어와 은어(Jargon)를 처리하는 탁월한 유연성이다.
범용 인공지능 임베딩 모델들은 전 세계 인터넷 데이터를 기반으로 사전 학습되었기 때문에 기업 내부의 특수한 프로젝트명을 전혀 알지 못한다. 만약 어떤 회사의 사내 데이터 파이프라인 시스템 이름이 ‘아틀라스(Atlas)’라면, 범용 임베딩 모델은 이 단어를 그리스 신화의 거인이나 세계 지도책과 강하게 연관 지어 버린다. 그 결과 “아틀라스 배치 작업 어떻게 돌리나요?”라는 질문을 임베딩 검색에 넣으면 관련 사내 문서를 찾아낼 확률이 바닥으로 떨어진다.
반면 질의 재작성 구조에서는 이러한 문제를 단 1분 만에 해결할 수 있다. 경량 LLM의 시스템 프롬프트(System Prompt)에 사내 용어집을 간단한 텍스트로 적어두기만 하면 된다.
[시스템 프롬프트 지침]
당신은 사내 검색 질의 변환기입니다. 다음 고유명사를 반드시 표준 검색어로 변환하십시오.
– 아틀라스(Atlas): 사내 대용량 배치 데이터 처리 엔진 프레임워크
– 머큐리(Mercury): 실시간 메시징 브로커 큐 시스템
– 제우스(Zeus): 사내 통합 SSO 로그인 인증 인프라
사용자가 “아틀라스에서 지난달 정산 데이터 일괄 처리 오류 확인하는 법”이라고 질문하면, LLM은 프롬프트를 즉각 참조하여 “Atlas batch processing settlement error log”라는 정확한 기술 키워드를 생성해 낸다. 그리고 뒤단에 위치한 BM25는 이 단어들을 놓치지 않고 100% 정확하게 일치하는 문서를 색인에서 찾아낸다.
만약 검색 품질을 더 높이고 싶다면 다단계 피드백 루프(Loop)를 적용할 수도 있다.
LLM이 1차로 재작성한 검색어로 BM25를 실행했을 때 문서 매칭 점수가 사전에 설정한 임계치(Threshold)에 도달하지 못하면, LLM이 방금 나온 실패 결과를 스스로 관찰하고 다른 동의어를 조합하여 최대 3회까지 질의를 자동 수정하며 재검색을 시도하는 방식이다.
이 모든 복잡한 적응형 튜닝이 문서를 단 한 글자도 재임베딩하지 않고, 오직 프롬프트 텍스트 몇 줄을 수정하는 것만으로 완벽히 작동한다는 것이다.
예시: 사내 인트라넷 검색 로그 분석 결과, 사용자의 70%가 고유명사 오탈자나 구어체 서술로 인해 검색에 실패했음. 이를 단순 프롬프트 기반 키워드 정규화로 교정하여 검색 성공률을 즉각 복구했음.
5. RAG 검색 방식 결정을 위한 5가지 평가 기준
렇다면 우리 팀은 과연 언제까지 이 단순한 ‘BM25 + 질의 재작성’ 조합에 머물러야 하고, 어느 시점에 더 복잡한 딥러닝 하이브리드 검색으로 넘어가야 하는가? 무작정 감에 의존해 기술을 고르는 것이 아니라, 철저히 정량적인 데이터에 기반하여 검색 파이프라인의 복잡도를 결정해야 한다. 기술 아키텍처를 결정짓는 핵심 5가지 기준은 다음과 같다.
ㄱ. 데이터의 신선도와 갱신 주기(Freshness)다.
다루고자 하는 문서가 뉴스 기사, 실시간 고객 상담 티켓, 주식 시황, 소셜 미디어 피드처럼 매시간 실시간으로 쏟아지는 데이터라면 무거운 사전 임베딩 방식은 재앙에 가깝다. 데이터가 추가되거나 수정될 때마다 벡터 인덱스를 갱신하는 데 병목이 발생하기 때문이다. 반면 BM25는 텍스트가 인입되는 즉시 역색인(Inverted Index)을 가볍게 업데이트하므로 초 단위의 실시간 데이터 처리에 압도적으로 유리하다.
ㄴ. 말뭉치의 일일 변경률(Churn Rate)과 접근 분포다.
하루에 전체 문서의 10% 이상이 수정되거나 삭제되는 환경이라면 전체 사전 임베딩을 피해야 한다. 또한 파레토 법칙에 따라 사용자가 조회하는 검색 트래픽의 80%가 상위 20%의 특정 매뉴얼이나 인기 문서에만 집중되고 나머지 80%의 문서는 거의 조회되지 않는 ‘롱테일(Long-tail)’ 구조를 띤다면, 읽지도 않을 문서 전체를 비싼 돈을 들여 미리 벡터로 변환해 둘 하등의 이유가 없다.
ㄷ. 사용자의 질의 패턴이다.
검색창에 들어오는 질문의 형태를 로그로 면밀히 분석해야 한다.
부품 규격, 주문 번호, 에러 코드, 고유 명사 중심의 검색이 대다수라면 고민할 것도 없이 BM25 위주의 키워드 검색이 정답이다. 반면 “이 약관의 환불 조건과 유사한 사례를 찾아줘”와 같이 추상적이고 서술적인 개념을 묻는 질문이 주를 이룬다면 그때 비로소 임베딩 모델의 도입 필요성을 타진해야 한다.
ㄹ. 서비스 규모와 트래픽 레이턴시 요구치다.
하루 질의량이 1,000건 미만인 내부 업무 시스템이나 초기 스타트업 서비스라면 가장 단순한 구조를 유지하는 것이 현명하다. 불필요하게 기술 부채를 쌓을 필요가 없다. 반대로 하루 수만 건 이상의 트래픽을 감당해야 하고 사용자의 화면 응답 속도가 무조건 50ms 미만이어야 하는 대규모 서비스라면, 그제서야 고가의 전용 인프라 최적화가 비즈니스적으로 정당화될 수 있다.
ㅁ. 시스템을 운영할 엔지니어링 팀의 역량이다.
팀 내에 머신러닝 모델의 수명 주기(MLOps)를 관리하고, 벡터 임베딩의 성능 저하를 모니터링하며, 전용 벡터 데이터베이스의 분산 샤딩 클러스터를 장애 없이 유지보수할 수 있는 전문 데이터 엔지니어가 부족하다면, 결코 복잡한 구조로 건너뛰어서는 안 된다. 장애가 발생했을 때 원인을 해석조차 할 수 없는 시스템은 엔터프라이즈 환경에서 시한폭탄과 다름없기 때문이다.
이러한 판단 기준을 요약하여 조직의 상황을 자가 진단할 수 있도록 구조화하면 아래의 비교 분석표와 같다.
| 평가 기준 항목 | 저복잡도 유지 권장 (BM25 + 질의 재작성) | 고복잡도 확장 검토 (하이브리드 / 사전 임베딩) |
| 데이터 갱신 주기 | 초·분·일 단위의 잦은 실시간 갱신 | 월·분기 단위로 고정된 안정적인 정적 문서 |
| 문서 일일 변경률 | 하루 10% 이상의 문서가 빈번히 수정·삭제 | 일일 변경률 5% 미만의 매우 안정적인 말뭉치 |
| 주요 질의 패턴 | 단어, 품번, 에러코드, 명사형 키워드 중심 | 추상적 서술, 문맥적 유사 비교, 개념 질문 중심 |
| 일일 검색 트래픽 | 하루 1,000건 내외의 초기 및 중소형 규모 | 하루 10,000건을 상회하는 대규모 동시 접속 |
| 운영 인력 전문성 | 일반 백엔드 개발자 및 인공지능 초심자 팀 | 전담 MLOps 및 검색 전처리(IR) 전문 엔지니어 보유 |
6. 실천을 위한 단계별 확장 로드맵
RAG 시스템을 성공적으로 서비스에 안착시키기 위한 엔지니어링의 대원칙은 ‘가장 단순하고 투명한 바닥부터 출발하는 것’이다. 복잡함을 더하는 것은 언제나 쉽지만, 불필요하게 부풀려진 복잡함을 걷어내는 것은 수많은 비용과 시간의 낭비를 수반하기 때문이다.
실제 성공적인 인공지능 프로덕션을 운영하는 기업들의 통계를 분석해 보면, 전체 검색 시스템의 약 60%는 본문에서 다룬 ‘BM25 키워드 검색과 LLM 질의 재작성’ 조합만으로 충분한 비즈니스 목표를 달성한다.
나머지 25% 정도만이 키워드 검색과 의미 검색을 결합한 하이브리드 검색을 필요로 하며, 전체 문서를 거대한 비용을 들여 사전에 임베딩해 두어야 하는 초대형 시스템은 상위 10%에 불과하다. 맞춤형 전용 구조가 필요한 시스템은 5% 미만이다. 60%짜리 단순한 문제에 상위 5%짜리 비싼 해법을 들이붓지 않는 것이 과잉 엔지니어링을 피하는 핵심 기준이라는 점을 반드시 기억해야 한다.
검색 기능을 새롭게 기획하거나 기존의 부실한 RAG 파이프라인을 개편하려는 조직이라면 반드시 다음의 3단계 실행 로드맵을 따라 점진적으로 진화해 나갈 것을 강력히 권장한다.
- 첫째, 기존 데이터베이스의 전문 검색이나 BM25 엔진을 활용하여 최소 기능 제품(MVP)을 즉시 구축한다.
이 단계에서는 복잡한 문서 분절(청킹)이나 벡터 변환에 단 1원의 예산도 쓰지 않는다. 원본 텍스트를 그대로 색인하고, 사용자가 입력하는 질문을 날것 그대로 검색기에 연결하여 2주에서 4주간 실제 사용자 피드백과 검색 실패 로그를 수집한다. - 둘째, “분명히 시스템 안에 존재하는 문서인데 검색 결과에 나오지 않는다”는 불만이 접수되기 시작하면, 비로소 질의당 1원짜리 경량 LLM 질의 재작성 모듈을 파이프라인 최전방에 결합한다.
사용자의 대화체 질문에서 명사 키워드를 추출하고, 사내 전문 용어 사전을 프롬프트에 주입하여 동의어를 확장하도록 구성한다. 이 단계만 도달해도 실무에서 발생하는 검색 실패 사례의 태반이 말끔히 해결된다. - 셋째, 질의 재작성을 거쳤음에도 불구하고 “원하는 뉘앙스의 문서를 찾을 수 없다”는 실측 데이터와 정량적 벤치마크 지표가 명백히 누적되었을 때에 한하여, 비로소 다음 단계인 ‘의미론적 임베딩과 재순위화(Reranker)’ 모듈을 선택적으로 도입한다.
이때도 무작정 전체 문서를 갈아엎는 것이 아니라, BM25로 1차 후보군 50개를 먼저 거른 뒤 소수의 상위 문서에 대해서만 의미를 대조하는 하이브리드 방식을 채택해야 비용과 속도를 모두 지켜낼 수 있다.
기술의 우수성은 얼마나 최신의 복잡한 라이브러리를 사용했는가로 증명되지 않는다.
비즈니스가 요구하는 문제를 가장 적은 인프라 비용과 가장 빠른 응답 속도, 그리고 가장 안정적인 유지보수성으로 해결해 내는 것이야말로 진정한 엔지니어링의 정수다. 단순함이야말로 고품질 RAG 검색 아키텍처를 완성하는 가장 강력한 무기라는 사실을 잊지 말아야 한다.