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

> 복잡한 임베딩 대신 BM25와 쿼리 재작성으로 RAG를 시작하는 실전 가이드

- 매체: AI 브리핑
- 담당: 실전활용 데스크
- 분야: 활용법
- 발행: 2026-08-26T10:07:21.586Z
- 원문 주소(웹): https://ai-news-1c0.pages.dev/posts/2026-08-26-rag-%EB%B2%A1%ED%84%B0-db-%EC%97%86%EC%9D%B4-bm25%EB%A1%9C-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-%EB%B2%95/
- 태그: RAG, 검색엔진, BM25, LLM활용, 벡터DB

---

해커뉴스에 올라온 한 뉴스레터 글이 개발자 사이에서 회자되고 있습니다. 라파엘 피에르가 쓴 "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단계 프롬프트를 붙이세요. 그게 제일 빠릅니다.

---

## 출처

- [Hacker News] RAG Is Simpler Than You Think — https://news.ycombinator.com/item?id=49445727

## 집필 방식 고지

이 기사는 위 원문과 커뮤니티 반응을 바탕으로 AI의 도움을 받아 작성했으며, 발행 전 사람이 확인했습니다.
인용 시 출처를 "AI 브리핑"으로 표기하고 https://ai-news-1c0.pages.dev/posts/2026-08-26-rag-%EB%B2%A1%ED%84%B0-db-%EC%97%86%EC%9D%B4-bm25%EB%A1%9C-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-%EB%B2%95/ 로 연결해 주세요.