RAG, 벡터 DB 없이 BM25로 시작하는 법

해커뉴스에 올라온 한 뉴스레터 글이 개발자 사이에서 회자되고 있습니다. 라파엘 피에르가 쓴 "RAG Is Simpler Than You Think"입니다. 핵심은 단순합니다. 대부분 팀이 임베딩과 벡터 데이터베이스를 너무 일찍 도입한다는 지적입니다.

원문은 6월 10일 발행됐습니다. 해커뉴스에서 점수 22, 댓글 2개를 기록했습니다. 댓글은 적지만 "정보 검색을 새 포장으로 팔 뿐"이라는 냉소와 "임베딩이 쉽고 강력하다"는 반박이 동시에 달렸습니다. 이 글은 그 논쟁의 중간 지대를 노립니다.

왜 다들 복잡하게 만드는가

원문은 다섯 가지 판단 기준을 제시합니다. 데이터 신선도, 문서 특성, 질문 패턴, 규모, 팀 역량입니다. 이 중 팀 역량이 가장 현실적입니다. 머신러닝 전문가가 없다면 임베딩 파이프라인은 유지보수 부채가 됩니다.

청킹 크기 512인지 1024인지, 겹침 50인지 100인지, 의미 기반 청킹인지 고정 크기인지. 임베딩을 쓰면 이 모든 결정을 내려야 합니다. 평가셋도 만들어야 하고, 모델이 폐기되면 다시 임베딩해야 합니다. 전체 문서 검색은 이런 고민이 없습니다. 문서가 곧 인덱스입니다.

3단계 레시피: 아래로 내려가지 마라

원문은 요리책 비유를 듭니다. 1단계부터 시작하고, 데이터가 증명할 때만 다음 단계로 가라는 것입니다.

1단계: BM25 전체문서 검색
엘라스틱서치, 포스트그레스 전문검색, 심지어 SQLite FTS5도 됩니다. 키워드 질의("인보이스 #12345")에 강합니다. 지연시간 10밀리초 내외. API 비용 0원. 디버깅 쉽습니다. 동의어("자동차" vs "자동차")와 의미 질문("어떻게 하지?")엔 약합니다. 하지만 원문 경험상 상당수 유스케이스가 여기에서 끝납니다.

2단계: LLM으로 쿼리 재작성
사용자 질문을 깨끗한 키워드로 바꿉니다. "버그 고치기" → "디버깅". "코드 빠르게" → "성능 최적화". 내부 용어("아틀라스 프레임워크")를 시스템 프롬프트에 고정하면 됩니다. 결과가 안 좋으면 프롬프트만 고치면 됩니다. 재임베딩 불필요. 즉시 테스트 가능.

3단계: 하이브리드·임베딩
하루 1만 쿼리 이상, 의미 검색이 필수적일 때만 갑니다. 그때가 되면 벡터 DB와 리랭커를 붙입니다.

쉽게 풀어보면

라파엘 피에르가 제안한 것은 검색엔진부터 쓰고, 안 되면 LLM으로 질문을 다듬고, 그래도 안 되면 임베딩을 쓰라는 3단계 순서입니다. 뷔페에 비유하면 이렇습니다. 접시 크기(청킹 전략) 고민하며 음식을 잘게 썰어 담는 대신(임베딩), **원래 요리 그대로(전체 문서) 진열대에서 집어서 접시에 담으라는 것(BM25)**입니다. 손님이 "매운 거 줘"라고 말하면(자연어 질문), 웨이터(LLM)가 "김치찌개, 제육볶음, 닭발"로 바꿔 주문해 주는 것(쿼리 재작성)이 2단계입니다.

이 비유에서 중요한 점: 접시 크기 고민(청킹)은 3단계 가서나 합니다. 1단계에선 그릇 통째로 냅니다. 문서가 곧 검색 단위니까요.

나에게 미치는 영향

오늘 챗GPT나 클로드에서 바로 해볼 수 있습니다. 내 문서 10~20개를 업로드하고 "이 문서들에서 키워드 검색만으로 답해줘"라고 지시해 보세요. RAG 플러그인 없이도 작동합니다. 답이 이상하면 "질문을 검색어로 바꿔서 다시 찾아줘"라고 한 번 더 시키면 2단계가 됩니다.

자영업자라면 상품 매뉴얼·FAQ PDF를 통째로 넣고 "모델명 검색만으로 답해줘" 프롬프트로 시작하세요. 청킹 전략 고민할 필요 없습니다. 직장인이라면 사내 위키·노션 페이지를 익스포트해 똑같이 테스트해 보세요. "아틀라스" 같은 내부 용어는 시스템 프롬프트에 "절대 수정 금지 키워드"로 적어두면 됩니다.

막히는 지점: 한글 형태소 분석이 안 되면 BM25가 말을 안 듣습니다. 포스트그레스 pg_trgm이나 엘라스틱서치 노리 분석기, 아니면 파이썬 kiwi·mecab으로 토큰화해 별도 컬럼에 저장해야 합니다. 이 부분만 넘으면 1단계는 30분 안에 뜹니다.

커뮤니티가 지적한 것들

해커뉴스 댓글 두 가지가 인상적입니다. "이미 수십 년 전부터 있던 정보 검색이다"라는 냉소. 그리고 "임베딩이 90% 프로젝트에서 주력이어야 한다"는 반박. 둘 다 맞습니다. 전자는 기술적 본질을, 후자는 현재 구현 편의성을 말합니다. 원문은 "증명되기 전엔 1단계에 머물라"는 절제입니다. 이 대목이 걸립니다. 검증 없이 3단계로 점프하는 팀이 너무 많습니다.

남은 쟁점

한국어 환경에서 BM25만으로 어디까지 커버되는지 공개된 벤치마크가 적습니다. 원문은 영어 기준입니다. 한국어 형태소·띄어쓰기·외래어 혼용이 BM25 성능을 얼마나 떨어뜨리는지, 쿼리 재작성 프롬프트로 얼마나 보완되는지 실측 데이터가 필요합니다. 이 부분은 제가 직접 테스트해 보고 후속 기사로 정리하겠습니다.

일단 오늘 문서 10개로 1단계 테스트 해보세요. 안 되면 그때 2단계 프롬프트를 붙이세요. 그게 제일 빠릅니다.