Postgres에서 Elasticsearch 없이 고급 검색 구현하는 방법: BM25 기반 PG Text Search 완전 정리

Postgres 검색, 지금 완전히 판이 바뀌고 있다

솔직히 말해볼게요. 데이터베이스 안에서 search 한 번 제대로 해보려고 하면, 묘하게 피곤해지는 순간이 있죠. 쿼리는 잘 쓴 것 같은데 결과는 영 시원찮고, “이게 최선인가?” 싶은 느낌.

저만 그런 거 아니죠.

대부분은 Postgres의 built-in full text search로 시작합니다. tsvector, tsquery, ts_rank 같은 것들요. 처음엔 꽤 괜찮아 보여요. 그런데 데이터가 조금만 커지거나, 검색 결과의 질이 중요해지는 순간… 다들 비슷한 결론에 도달합니다.

 

“그냥 Elasticsearch 붙이자.”

 

예전에는 그게 정답이었어요.

하지만 지금은, 상황이 완전히 달라졌습니다.

AI가 중심이 된 이 시대에서는 search 자체가 시스템의 핵심이 됐거든요. 그리고 예전 방식의 도구들은 여기저기서 한계를 드러내고 있습니다.

이 글에서는 왜 search의 패러다임이 바뀌었는지, 왜 기존 Postgres search가 부족했는지, 그리고 BM25 기반의 PG Text Search가 어떻게 Postgres 안으로 ‘현대적인 검색’을 다시 가져왔는지를 차근차근 풀어봅니다.

게다가 이건 open source고, 지금 바로 무료로 실험해볼 수도 있어요.

 

왜 갑자기 search가 이렇게 중요해졌을까?

 

---

왜 갑자기 search가 이렇게 중요해졌을까?

조금만 뒤로 물러서서 보면, search는 크게 세 번의 시대를 거쳐왔습니다. 이 흐름을 이해하면 지금의 변화가 훨씬 또렷해져요.

1️⃣ 사람을 위한 검색 (초기 시대)

이 시기의 search는 아주 단순했습니다.

• 블로그 글
• 문서
• 상품 목록

 

사람이 키워드를 몇 개 입력하면, 적당히 관련 있는 결과를 보여주면 됐죠. 데이터도 크지 않았고, 자주 바뀌지도 않았습니다.

이때의 Postgres full text search는 정말 훌륭했어요. 빠르고, 단순하고, 딱 필요한 만큼 잘 작동했죠. 솔직히 불만 가질 이유가 없었습니다.

 

 

2️⃣ 시스템을 위한 검색 (Elasticsearch의 시대)

그러다 search의 대상이 사람이 아니라 시스템으로 확장됩니다.

로그, 메트릭, 이벤트 스트림… 데이터는 수백만, 수천만 건으로 늘어났고, 중요한 건 ‘정확한 문서’보다 속도, 확장성, aggregation이었죠.

이때 Elasticsearch가 사실상 표준이 됩니다. 좋아서라기보단, 그 역할을 해낼 수 있었기 때문에요.

 

 

3️⃣ AI Native Application 시대 (지금)

그리고 현재.

search는 더 이상 사람이나 로그만을 위한 게 아닙니다.

• LLM
• RAG 시스템
• chatbot
• agent

 

이 친구들은 단순히 “매칭되는 문서”가 아니라, **정답을 만들 수 있는 맥락(context)**을 필요로 합니다.

여기서 search가 조금만 삐끗해도, 결과는 바로 체감돼요. 모델이 아무리 좋아도, 잘못된 context를 주면 답변도 흐려집니다.

이 지점에서 기존 Postgres search의 한계가 드러나기 시작합니다.

 

 

 

---

진짜 문제는 ‘Ranking Quality’다

AI 시스템에서 search 품질은 옵션이 아닙니다. 출력 품질을 직접 결정해요.

RAG 구조를 생각해보면 간단합니다. LLM은 retrieve된 문서 안에서만 사고합니다. 여기서 애매한 문서가 섞이면, 결과도 애매해질 수밖에 없죠.

그런데 Postgres의 native full text search는 이 부분에서 많이 아쉽습니다.

 

 

기존 Postgres full text search의 한계

Postgres는 ts_rank를 사용합니다. 키워드 매칭 자체는 하지만, 요즘 search에서 당연하게 여기는 요소들이 빠져 있어요.

• IDF(Inverse Document Frequency)가 없다
  database 같은 흔한 단어와 pooling 같은 핵심 용어가 거의 비슷하게 취급됩니다.
• keyword 반복에 취약하다
  단어를 많이 반복한 긴 문서가 상위에 올라오기 쉽습니다.
• 문서 길이 보정이 없다
  짧고 정확한 문서보다 긴 문서가 유리해요.
• boolean 매칭의 경직성
  검색어 중 하나라도 빠지면, 아무리 관련 있어도 아예 제외됩니다.

 

사람이 검색할 땐 “좀 불편하네” 정도지만, AI 입장에서는 치명적입니다.

 

 

 

---

BM25가 이 문제를 어떻게 해결할까?

사실 이 문제들은 새로운 게 아닙니다. modern search engine들은 이미 오래전에 해결했어요.

그 핵심이 바로 BM25입니다.

실험적인 알고리즘이 아닙니다. 업계 표준이에요.

BM25가 좋은 이유는 명확합니다.

1. IDF 적용
   희귀하지만 중요한 단어에 더 큰 가중치를 둡니다.
2. term frequency saturation
   단어를 반복하면 도움이 되긴 하지만, 어느 순간부터는 효과가 줄어듭니다.
3. length normalization
   짧고 집중된 문서도 충분히 경쟁할 수 있습니다.

 

Google, YouTube 같은 서비스들이 이 방식을 씁니다. 이유가 있겠죠.

문제는 하나였어요.

 

“왜 Postgres에는 BM25가 없지?”

 

…이제는 있습니다.

 

 

 

---

PG Text Search: BM25를 Postgres 안으로

PG Text Search는 BM25 기반 keyword search를 Postgres 내부로 직접 가져옵니다.

• 외부 search engine 필요 없음
• index 동기화 파이프라인 없음
• 데이터 중복 없음

 

그냥 Postgres입니다.

여기에 pgvector까지 더하면?

• BM25 keyword search의 정확함
• vector search의 semantic 이해

 

이 둘을 결합한 hybrid search가 완성됩니다.

아키텍처 관점에서 보면, 꽤 큰 변화예요.

 

 

 

---

실제로 써보면 이렇게 다르다

Tiger Data(Tiger Cloud)를 사용하면, 이걸 무료로 바로 실험해볼 수 있습니다. PG Text Search를 open source로 공개한 곳이기도 하고요.

설정은 생각보다 단순합니다.

CREATE EXTENSION pg_text_search;

 

extension만 활성화하면 끝.

그 다음 BM25 index를 만들고, 평범한 SQL로 검색하면 됩니다. index는 transactional이라 따로 sync할 필요도 없어요.

 

 

검색 예시

products 테이블에서 “wireless charging”을 검색한다고 해봅시다.

SELECT id, name,
       description @@ to_bm25query('wireless charging') AS score
FROM products
ORDER BY score DESC
LIMIT 5;

 

결과는 꽤 인상적입니다.

• wireless charging mat
• wireless charger stand
• wireless mouse pad

 

점수도 납득이 가요. 아, 이래서 이 순서구나 싶은 느낌.

처음 봤을 때 저도 잠깐 멈췄습니다. “이게… Postgres 맞아?” 하고요.

맞습니다.

 

 

 

---

Hybrid Search: AI에 딱 맞는 조합

PG Text Search는 vector search를 대체하지 않습니다. 보완합니다.

보통 이런 흐름이 가능해요.

1. vector search로 의미상 가까운 후보를 찾고
2. 그 결과 안에서 BM25로 keyword ranking

 

semantic + precision.

RAG나 agent 시스템에서 특히 강력합니다.

 

 

---

결국, 아키텍처가 단순해진다

Elasticsearch 운영, 솔직히 쉽지 않았죠.

PG Text Search를 쓰면:

• database 하나
• transaction 모델 하나
• 운영 포인트 하나

 

search 품질은 더 좋아지고, 구조는 단순해집니다.

“원래 이렇게 했어야 하는 거 아닌가?” 싶은 순간이 옵니다.

 

 

---

정리하며

이제 search는 단순한 기능이 아닙니다.

AI 시스템에서는 정답의 재료입니다.

PG Text Search는 BM25라는 검증된 방식을 Postgres 안으로 가져와, AI 시대에 맞는 search를 가능하게 합니다.

외부 도구 없이.

깔끔하게.

솔직히 말해, 꽤 설레는 변화입니다.

 

 

---

FAQ (2025 기준)

PG Text Search는 뭔가요?
BM25 기반 keyword search를 제공하는 Postgres extension입니다.

기존 full text search와 뭐가 다른가요?
ranking 품질이 압도적으로 좋아집니다.

Elasticsearch를 완전히 대체할 수 있나요?
많은 use case에서는 충분히 가능합니다.

production에서 써도 되나요?
BM25는 이미 업계 표준입니다.

vector search랑 같이 쓸 수 있나요?
네. hybrid search가 핵심 포인트입니다.

index 관리가 필요한가요?
아니요. transactional index입니다.

무료인가요?
네, open source입니다.

RAG에 적합한가요?
아주 잘 맞습니다.

대용량 데이터도 괜찮나요?
ranking 품질을 유지하면서 처리 가능합니다.

빠르게 실험해보려면?
Tiger Cloud free tier가 가장 쉽습니다.

 

 

---

한 줄 요약
AI 시대의 search는 옵션이 아니라, 모델이 숨 쉬는 공기다.