PostgreSQL에서 BM25 전문 검색을 쓸 수 있게 해주는 pg_textsearch 확장

Elasticsearch 없이도 제대로 된 전문 검색이 가능할까?

서비스를 만들다 보면 검색 기능은 거의 필수적으로 들어가잖아요. 그런데 PostgreSQL의 기본 전문 검색(Full-Text Search)은 좀 아쉬운 부분이 있어요. ts_rank라는 내장 랭킹 함수가 있긴 한데, 이게 문서의 길이나 검색어 빈도를 정교하게 반영하지 못해서, 검색 결과의 품질이 기대에 못 미치는 경우가 많거든요. 그래서 결국 Elasticsearch나 Typesense 같은 별도의 검색 엔진을 도입하게 되는데, 이러면 인프라 복잡도가 확 올라가요.

Timescale 팀에서 만든 pg_textsearch는 이 문제를 정면으로 해결하려는 PostgreSQL 확장(Extension)이에요. 핵심은 BM25 알고리즘을 PostgreSQL 안에서 네이티브로 사용할 수 있게 해준다는 거예요.

BM25가 뭔데 중요한 거예요?

BM25는 정보 검색(Information Retrieval) 분야에서 사실상 표준처럼 쓰이는 랭킹 알고리즘이에요. 이게 뭐냐면, 검색어가 문서에 얼마나 관련성이 높은지를 점수로 매기는 공식인데요, 크게 세 가지 요소를 고려해요.

첫째, TF(Term Frequency), 검색어가 해당 문서에 얼마나 자주 등장하는지를 봐요. 많이 나올수록 관련성이 높겠죠. 하지만 단순히 횟수가 많다고 점수가 끝없이 올라가는 게 아니라, 어느 정도 이상이면 포화(saturation)되도록 설계되어 있어요. "사과"라는 단어가 10번 나온 문서와 100번 나온 문서의 점수 차이가 1번 vs 10번만큼 크지 않다는 거죠.

둘째, IDF(Inverse Document Frequency), 검색어가 전체 문서 중 얼마나 드물게 등장하는지를 봐요. "the" 같은 흔한 단어보다 "PostgreSQL" 같은 특정 단어로 검색했을 때 그 단어가 포함된 문서에 더 높은 점수를 주는 거예요.

셋째, 문서 길이 정규화예요. 짧은 문서에서 검색어가 나오면 긴 문서에서 나오는 것보다 더 관련성이 높다고 판단해요. 3줄짜리 글에서 핵심 키워드가 나온 거랑, 100페이지 문서에서 한 번 나온 건 다르니까요.

Elasticsearch, Lucene, 그리고 대부분의 현대 검색 엔진이 기본 랭킹으로 BM25를 사용해요. 이걸 이제 PostgreSQL에서도 쓸 수 있다는 게 pg_textsearch의 핵심이에요.

어떻게 동작하나요?

pg_textsearch는 PostgreSQL의 기존 전문 검색 인프라 위에 구축되어 있어요. 즉, tsvector와 tsquery라는 PostgreSQL의 기본 텍스트 검색 타입을 그대로 활용하면서, 랭킹 계산 부분만 BM25로 교체하는 방식이에요.

사용법도 비교적 직관적이에요. 기존에 ts_rank() 함수를 쓰던 자리에 pg_textsearch가 제공하는 BM25 랭킹 함수를 넣으면 되는 구조거든요. 기존 PostgreSQL 전문 검색을 이미 쓰고 있었다면 마이그레이션 비용이 크지 않다는 얘기예요.

BM25 점수를 계산하려면 전체 문서에 대한 통계 정보(문서 수, 평균 문서 길이, 각 단어의 문서 빈도)가 필요한데, pg_textsearch는 이런 통계를 내부적으로 관리해요. 데이터가 바뀔 때 통계를 어떻게 효율적으로 업데이트하는지가 성능의 핵심 포인트일 텐데, 이 부분은 프로젝트 저장소에서 구현 디테일을 살펴볼 수 있어요.

기존 대안들과 비교하면?

지금까지 PostgreSQL에서 더 나은 전문 검색을 하려면 몇 가지 선택지가 있었어요. ParadeDB의 pg_search는 내부적으로 Tantivy(Rust로 만든 Lucene 대안)를 임베딩해서 PostgreSQL 안에 완전한 검색 엔진을 넣는 접근이에요. 기능은 풍부하지만 의존성이 크고, 기존 tsvector/tsquery 인프라와는 별개로 동작해요.

반면 pg_textsearch는 PostgreSQL의 기존 전문 검색 시스템을 확장하는 방식이라, 더 가볍고 기존 코드와의 호환성이 좋아요. 이미 tsvector 인덱스를 만들어뒀다면 그걸 그대로 활용할 수 있거든요.

물론 Elasticsearch처럼 하이라이팅, 자동완성, 퍼지 매칭 같은 풍부한 검색 기능이 필요하다면 여전히 별도 검색 엔진이 나을 수 있어요. 하지만 "검색 결과 순서만 좀 더 똑똑했으면 좋겠다" 수준의 요구사항이라면, pg_textsearch로 충분할 가능성이 높아요.

한국 개발자에게 주는 시사점

스타트업이나 소규모 팀에서 검색 품질 때문에 Elasticsearch를 도입할지 고민했던 적 있다면, 이 확장이 좋은 대안이 될 수 있어요. 인프라를 하나 더 관리하는 건 생각보다 큰 부담이거든요. 데이터 동기화도 신경 써야 하고, 장애 포인트도 늘어나고요. PostgreSQL 하나로 애플리케이션 데이터와 검색을 동시에 처리할 수 있다면 운영 복잡도가 확 줄어들어요.

다만, 한국어 검색의 경우 형태소 분석이 중요한데, 이건 pg_textsearch의 범위가 아니라 PostgreSQL 전문 검색 파이프라인의 텍스트 분석 단계에서 처리해야 할 부분이에요. 한국어 형태소 분석기(예: mecab 기반 확장)를 함께 설정해야 제대로 된 한국어 검색이 가능하다는 점은 기억해두세요.

Timescale이라는 검증된 팀이 만들고 있다는 점도 긍정적이에요. 시계열 데이터베이스 확장으로 이미 PostgreSQL 생태계에서 탄탄한 입지를 가진 팀이니까, 장기적인 유지보수 측면에서도 어느 정도 신뢰할 수 있어요.