BM25 검색 플랫폼 비교: PostgreSQL vs MongoDB vs Elasticsearch

게시 2026/02/01

By BLUEBUG

36 분읽는 시간

시장 지위와 기업 규모

Elasticsearch: 검색 엔진의 선두주자

Elasticsearch를 개발한 Elastic NV는 2026년 1월 기준 시가총액 77억 달러에 달하는 뉴욕증권거래소 상장 기업이다. 2025년 회계연도 기준 전 세계 14,286개 이상의 기업이 Elasticsearch를 기술 스택에 포함시키고 있으며, Amazon, Walmart, Apple과 같은 글로벌 대기업들이 핵심 고객사로 자리잡고 있다. 호스팅 검색 시장에서 Elastic Stack은 34.15%의 시장점유율을 기록하며 압도적인 1위를 차지하고 있다. 사용 기업의 지리적 분포를 보면 미국이 47.36%로 가장 높고, 인도(9.44%), 프랑스(8.79%)가 그 뒤를 잇는다.

Elasticsearch는 2012년 네덜란드 암스테르담에서 창립되어 2018년 뉴욕증권거래소에 상장했다. 현재는 네덜란드와 미국 샌프란시스코에 본사를 두고 있으며, 단순한 검색 엔진을 넘어 관측성(Observability)과 사이버 보안 분야로 사업을 확장하고 있다. 2016년 Elasticsearch 5.0부터 BM25를 기본 알고리즘으로 채택하면서, 이는 검색 엔진 업계의 사실상 표준이 되었다.

MongoDB: AI 시대의 데이터베이스 강자

MongoDB Inc.는 2025년 회계연도에 연매출 20억 1천만 달러를 달성하며 빠른 성장세를 보이고 있다. 2026년 회계연도 3분기(2025년 10월 마감) 실적에서는 전년 대비 19% 성장한 6억 2,830만 달러의 매출을 기록했다. 특히 클라우드 서비스인 Atlas의 성장이 두드러지는데, Atlas 매출은 전년 대비 30% 증가하며 전체 매출의 75%를 차지했다. 2025년 10월 기준 전 세계 고객사는 62,500개를 넘어섰고, 분기마다 평균 2,600개의 신규 고객이 추가되고 있다.

MongoDB는 2025년에 주목할 만한 성과를 거두었다. 2025년 8월 주가가 214달러였던 것이 12월에는 400달러를 돌파하며 연간 41% 이상 상승했다. 이는 Atlas의 가속화된 성장과 AI 워크로드 확대에 힘입은 것이다. 월가 애널리스트들은 MongoDB가 1,000억 달러 규모의 비정형 데이터베이스 시장에서 상당한 점유율을 확보할 것으로 전망하며, 목표주가를 440 ~ 480달러로 상향 조정했다. 2025년 11월에는 Cloudflare와 ServiceNow 출신의 CJ Desai가 신임 CEO로 선임되면서, AI 시대에 적합한 리더십 체제를 갖추었다는 평가를 받고 있다.

PostgreSQL: 오픈소스의 조용한 승자

PostgreSQL은 상업적 기업이 아닌 전 세계 개발자 커뮤니티가 개발하는 완전한 오픈소스 데이터베이스다. 시가총액이나 매출 같은 기업 지표는 존재하지 않지만, 실제 채택률과 영향력은 막강하다. Stack Overflow의 2024년 개발자 설문조사에서 PostgreSQL은 가장 사랑받는 데이터베이스로 선정되었으며, 전 세계 수백만 개의 애플리케이션과 서비스에서 사용되고 있다.

PostgreSQL의 BM25 검색 기능은 주로 서드파티 확장을 통해 제공된다. ParadeDB의 pg_search 확장은 2023년 11월 공개되어 2025년 현재 활발하게 개발 중이며, Timescale의 pg_textsearch는 2024년 12월에 출시되어 빠르게 주목받고 있다. 두 확장 모두 AGPL-3.0 라이선스로 제공되는 완전한 오픈소스이며, 상업적 지원이 필요한 경우 별도 라이선싱 옵션이 있다.

가격 정책: 유료 vs 무료

PostgreSQL: 완전 무료

PostgreSQL은 PostgreSQL License(BSD 유사)로 배포되는 완전 무료 오픈소스 소프트웨어다. 데이터베이스 자체는 물론 pg_search, pg_textsearch 같은 BM25 확장도 모두 무료로 사용할 수 있다. 클라우드 환경에서 사용할 경우 서버 인프라 비용만 발생할 뿐, 소프트웨어 라이선스 비용은 전혀 없다.

ParadeDB의 pg_search는 AGPL-3.0 라이선스로 제공되지만, 엔터프라이즈 고객을 위한 상업 라이선스도 별도로 제공한다. 그러나 대부분의 일반적인 사용 사례에서는 무료 버전으로 충분하다. Timescale의 pg_textsearch 역시 오픈소스로 제공되며, Timescale Cloud 사용 시에도 추가 비용 없이 이용할 수 있다.

관리형 PostgreSQL 서비스(AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL)를 이용할 경우 데이터베이스 인스턴스 비용만 발생한다. 예를 들어 AWS RDS의 db.t3.medium 인스턴스(2 vCPU, 4GB RAM)는 시간당 약 0.068달러, 월 약 50달러 수준이다. 이는 Elasticsearch나 MongoDB Atlas의 유사 사양 대비 현저히 낮은 비용이다.

MongoDB Atlas: 계층별 과금

MongoDB Atlas는 무료부터 엔터프라이즈까지 4단계 가격 체계를 운영한다.

무료 계층(M0 Shared) 은 영구 무료로 제공되며 512MB 스토리지, 공유 RAM, 초당 최대 100회 연산을 지원한다. 프로토타입, 학습, 소규모 앱에 적합하지만 공유 리소스이므로 성능이 일정하지 않다. Atlas Search는 무료 계층에서도 사용 가능하지만, 검색 노드가 별도로 할당되지 않아 성능 제한이 있다.

Flex 계층 은 2024년 새로 도입된 가격 모델로, 월 8달러부터 시작한다. 5GB 스토리지와 초당 100회 연산이 기본 제공되며, 사용량에 따라 월 최대 30달러까지 자동 확장된다. MVP 개발, 생성형 AI 애플리케이션, 가변적인 트래픽을 가진 개발 환경에 적합하다. 예측 가능한 비용 한도를 제공한다는 점에서 이전 Serverless 모델보다 개선되었다는 평가를 받는다.

전용 계층(Dedicated) 은 프로덕션 환경을 위한 옵션으로 M10부터 시작한다. M10 인스턴스는 월 57달러(AWS 기준)이며 10GB 스토리지, 2GB RAM, 전용 vCPU를 제공한다. M50 인스턴스는 월 약 2,000달러로 높은 성능과 완전한 네트워크 격리, 다중 지역 배포, 커스터마이징 가능한 백업 정책을 지원한다. 클라우드 제공자와 지역에 따라 가격이 다르며, Azure M40이 시간당 1.13달러인 반면 AWS M50은 시간당 2.00달러다.

Atlas Search 비용 은 별도로 청구된다. High CPU 구성이 권장되며, 검색 노드 티어에 따라 비용이 발생한다. 소규모 검색의 경우 월 수십 달러 수준이지만, 대규모 검색 워크로드는 월 수백 ~ 수천 달러에 달할 수 있다. 데이터 전송 비용(egress)도 추가되는데, 무료 및 Flex 계층은 아웃바운드 데이터가 무료이지만 전용 계층부터는 과금된다.

업계 실무자들의 경험에 따르면 MongoDB는 연간 10만 달러 이상 지출 시 할인이 시작되며, 엄격한 할인 매트릭스를 적용한다. 다년 계약, 대규모 커밋, Azure/AWS Marketplace를 통한 구매 시 추가 할인을 받을 수 있다. 일부 고객은 14%의 엔지니어링 협력 할인을 받았지만, 사용량 감소 시 할인이 철회되는 사례도 보고되었다.

Elasticsearch: 복잡한 리소스 기반 가격

Elasticsearch의 가격 체계는 세 가지 배포 모델을 제공하며, 각각 복잡한 계산이 필요하다.

Elastic Cloud Hosted는 가장 일반적인 관리형 서비스다. CPU, RAM, 스토리지 사용량을 기준으로 과금되며, 정확한 비용 예측이 어렵다는 평가를 받는다. 노드 수, 샤드 구성, 힙 메모리 할당 등을 미리 결정해야 하는데, 이는 Elasticsearch 운영 경험이 없는 팀에게는 큰 진입 장벽이다. 표준 지원부터 엔터프라이즈 지원까지 여러 티어가 있으며, 지원 레벨에 따라 비용이 크게 달라진다.

Elasticsearch Serverless는 사용량 기반 과금 모델이다. 인덱싱, 검색, 스토리지에 대해 각각 과금되며, 리소스 관리 부담은 줄지만 예측 가능성은 여전히 낮다. 트래픽 급증 시 예상치 못한 비용 증가가 발생할 수 있다.

자체 관리형(Self-Managed) 은 오픈소스 버전으로 소프트웨어 자체는 무료지만, 인프라 비용과 운영 인력 비용이 발생한다. Elasticsearch는 Java 기반이므로 JVM 튜닝, 클러스터 관리, 샤드 리밸런싱 등 전문 지식이 필요하다. 중소 기업의 경우 전담 Elasticsearch 엔지니어를 고용하는 비용만도 연간 10만 ~ 20만 달러에 달한다.

업계 벤치마크에 따르면 소규모 Elasticsearch 클러스터(3노드, 각 16GB RAM)의 Elastic Cloud 비용은 월 500 ~ 1,000달러 수준이며, 엔터프라이즈급 클러스터는 월 수천 ~ 수만 달러에 이른다. Meilisearch 같은 경쟁사는 월 30 ~ 300달러의 단순한 구독 모델을 제공하는 것과 대조적이다.

성능 비교: 실측 벤치마크

PostgreSQL pg_search: Elasticsearch급 성능

ParadeDB의 2023년 11월 공식 벤치마크에 따르면, 100만 건의 문서를 대상으로 한 테스트에서 pg_search는 PostgreSQL 네이티브 전문 검색(tsvector) 대비 압도적인 성능을 보였다. 인덱스 생성은 50초 더 빠르고, 검색 속도는 20배 이상 빠르다. 더욱 놀라운 점은 Elasticsearch와 거의 동일한 수준의 성능을 보인다는 것이다.

Tembo의 2024년 벤치마크는 더욱 극적인 차이를 보여준다. 1,000만 건 문서에서 PostgreSQL 네이티브 전문 검색은 평균 1.66초가 소요된 반면, pg_search는 6.28밀리초만에 완료되어 약 265배 빠른 성능을 기록했다. 1억 건 문서로 확장했을 때 네이티브 검색은 14초까지 증가했지만, pg_search는 28밀리초를 유지하여 500배의 성능 우위를 보였다.

인덱스 생성 시간도 큰 차이를 보인다. 1,000만 건 기준으로 GIN 인덱스는 282.93초(약 5분)가 소요되었지만 BM25 인덱스는 44.72초로 약 6배 빠르다. 1억 건으로 확장하면 GIN은 58분 24초, BM25는 19분 42초가 걸렸다.

Vineeth Pothulapati의 2025년 실전 벤치마크는 Amazon 제품 160만 건을 대상으로 5가지 검색 유형(전문 검색, 퍼지 검색, 구문 검색, 부분 매칭, 복합 검색)을 테스트했다. PostgreSQL 네이티브는 11개의 인덱스(GIN, pg_trgm 등)가 필요했고 각 검색 유형마다 다른 쿼리 문법을 사용해야 했다. 반면 pg_search는 단일 BM25 인덱스와 일관된 @@@ 연산자만으로 모든 검색을 처리했으며, 성능도 더 우수했다.

그러나 VectorChord의 2025년 4월 분석에서는 다른 관점을 제시했다. PostgreSQL 네이티브 전문 검색이 최적화되면(tsvector 컬럼 생성, GIN 인덱스에 fastupdate=off 설정) 약 50배의 성능 향상이 가능하다는 것이다. 이는 일부 벤치마크가 최적화되지 않은 기준선을 사용했을 가능성을 시사한다. 그럼에도 랭킹 속도는 여전히 pg_search가 우세하다.

MongoDB Atlas Search: 안정적인 중상위권

MongoDB Atlas Search의 공식 성능 데이터는 제한적이지만, 업계 실무 경험에 따르면 검색 지연시간은 20 ~ 100밀리초 범위다. Lucene 기반이므로 Elasticsearch와 유사한 수준의 성능을 기대할 수 있지만, 검색 전용 노드(mongot 프로세스)가 MongoDB 클러스터와 별도로 실행되므로 추가적인 네트워크 홉이 발생한다.

Atlas Search는 실시간 인덱싱을 지원하며, 문서 변경사항이 약 1초 내에 검색 가능해진다. 이는 MongoDB의 Change Streams와 긴밀하게 통합되어 작동한다. 대규모 초기 인덱싱은 백그라운드에서 진행되며, 100만 건 기준 약 2분 정도 소요된다.

2024년 MongoDB가 공개한 사례에 따르면, 2,400만 건의 PubMed 초록을 대상으로 한 생물의학 QA 시스템에서 쿼리 지연시간 82밀리초, 종단간 RAG 응답시간 1.9초를 달성했다. 이는 Atlas Search가 대규모 프로덕션 환경에서도 안정적으로 작동함을 보여준다.

MongoDB는 BM25 파라미터(k1, b)를 직접 조정할 수 없지만, 필드별 부스팅, 퍼지 매칭 정도, 그리고 2025년 새로 도입된 대체 스코어링 알고리즘(stableTfl, boolean)을 통해 간접적으로 랭킹을 조정할 수 있다. 하이브리드 검색($rankFusion, $scoreFusion)도 네이티브로 지원하여, 별도의 수동 구현 없이 텍스트와 벡터 검색을 결합할 수 있다.

Elasticsearch: 검색 성능의 황금 표준

Elasticsearch는 검색 전문 엔진답게 가장 빠른 성능을 제공한다. 잘 튜닝된 클러스터에서 검색 지연시간은 5 ~ 50밀리초 범위이며, 수억 ~ 수십억 건의 문서에서도 안정적인 성능을 유지한다. 이는 Lucene의 최적화된 역색인 구조, 스킵 리스트를 통한 빠른 교집합 연산, IDF 값 캐싱 등의 기술 덕분이다.

Elastic의 공식 블로그에 따르면, BM25의 기본 파라미터(k1=1.2, b=0.75)는 대부분의 코퍼스에서 잘 작동하지만, 도메인 특성에 따라 조정이 필요할 수 있다. 학술 논문 검색의 경우 b=0.3~0.9, k1=0.5 ~ 2.0 범위에서 최적값을 찾는 것이 권장된다. Elasticsearch는 인덱스별로 커스텀 유사도 설정을 지원하여 이러한 튜닝이 가능하다.

대규모 환경에서의 Elasticsearch 성능은 샤딩 전략에 크게 좌우된다. 샤드당 20~50GB가 권장되며, 1,000만 건 문서의 경우 3개 샤드가 적절하다. 다만 샤드가 여러 개일 경우 각 샤드의 IDF 통계가 달라져 점수 불일치가 발생할 수 있다. 이는 dfs_query_then_fetch 검색 타입으로 해결할 수 있지만, 모든 샤드에서 통계를 먼저 수집하므로 추가 네트워크 왕복이 필요하다. 충분한 데이터가 쌓이면 샤드 간 통계가 수렴하여 문제가 자연스럽게 해결된다.

인덱스 라이프사이클 관리(ILM)를 통해 시간이 지난 데이터는 웜 계층으로 이동하고, 샤드를 축소하며, 세그먼트를 강제 병합하여 스토리지와 성능을 최적화할 수 있다. 이러한 고급 기능들이 Elasticsearch를 대규모 로그 분석과 실시간 모니터링의 사실상 표준으로 만들었다.

시장 평가와 산업 동향

하이브리드 검색의 부상

2025년 검색 기술의 가장 중요한 트렌드는 하이브리드 검색이다. BM25 같은 키워드 기반 검색과 벡터 임베딩 기반 의미론적 검색을 결합하여, 정확성과 재현율을 모두 높이는 접근법이다. 2025년 2월 연구에 따르면, 하이브리드 시스템은 키워드 검색 대비 8 ~ 12%, 자연어 검색 대비 15%의 정확도 향상을 보였다.

PostgreSQL은 pgvector와 pg_search/pg_textsearch를 결합하여 Reciprocal Rank Fusion(RRF) 방식의 하이브리드 검색을 구현할 수 있다. 모든 것이 단일 데이터베이스 안에서 처리되므로 인프라가 단순하다. MongoDB Atlas는 2025년 9월 $rankFusion과 $scoreFusion 파이프라인을 도입하여 하이브리드 검색을 네이티브로 지원한다. 텍스트와 벡터 검색 결과를 가중 평균으로 결합할 수 있다. Elasticsearch는 하이브리드 검색을 위한 네이티브 기능이 없어 수동으로 구현해야 하지만, 커뮤니티에서 다양한 플러그인과 솔루션이 개발되고 있다.

AI/RAG 워크로드의 영향

생성형 AI와 RAG(Retrieval-Augmented Generation) 시스템의 확산은 검색 인프라에 대한 요구사항을 변화시켰다. MongoDB의 CEO CJ Desai는 2025년 12월 실적발표에서 “AI가 평생에 한 번 올까 말까 한 기회(once in a lifetime opportunity)”에 도달했다고 언급했다. 실제로 MongoDB의 Atlas 매출 중 상당 부분이 AI/ML 워크로드에서 발생하고 있다.

RAG 시스템은 정확한 문서 검색이 최종 출력 품질을 직접 결정하므로, BM25와 벡터 검색의 조합이 필수적이다. 2025년 6월 연구에서는 BM25 점수를 LLM 리랭킹 프롬프트에 주입하면 BRIGHT 벤치마크에서 Gemini 2.5 flash는 2.2%, GPT-4o는 0.5%의 성능 향상을 보였다. 이는 BM25가 여전히 현대 AI 시스템에서 중요한 역할을 한다는 것을 의미한다.

비용 최적화 압박

경기 침체 우려와 VC 자금 조달 어려움 속에서 기업들은 인프라 비용 절감에 집중하고 있다. MongoDB Atlas는 2024년 10월 비용 최적화 도구를 강화했고, Elasticsearch 대비 26.7% 낮은 비용으로 유사 구성을 제공한다고 주장한다. 그러나 많은 기업이 PostgreSQL로 회귀하는 추세다. “You Don’t Need Elasticsearch: BM25 is Now in Postgres”라는 제목의 Tiger Data 블로그 포스트는 대부분의 애플리케이션이 PostgreSQL로 충분하다는 메시지를 전달하며 큰 반향을 일으켰다.

실제로 ParadeDB pg_search가 Elasticsearch와 거의 동일한 성능을 제공하면서도 별도의 클러스터 관리가 필요 없다는 점은 강력한 경쟁력이다. 스타트업과 중소기업은 PostgreSQL 단일 스택으로 데이터베이스, 검색, 벡터 검색을 모두 해결하여 월 수천 달러의 비용을 절감하고 있다.

오픈소스 vs 상용 소프트웨어

Elasticsearch는 2021년 라이선스를 Elastic License 2.0과 SSPL(Server Side Public License)로 변경하면서 논란을 겪었다. 이는 AWS가 Elasticsearch를 관리형 서비스로 제공하는 것을 막기 위한 조치였지만, 오픈소스 커뮤니티의 반발을 샀다. AWS는 이에 대응하여 OpenSearch(Elasticsearch 7.10.2 기반 포크)를 만들었고, 현재 독자적인 생태계를 구축하고 있다.

반면 PostgreSQL은 진정한 오픈소스로 남아 있으며, ParadeDB와 Timescale 같은 벤처 지원 스타트업들이 혁신을 주도하고 있다. 이들은 오픈소스를 무기로 빠르게 성장하며, 엔터프라이즈 고객에게는 상업 지원을 제공하는 하이브리드 비즈니스 모델을 채택했다. MongoDB는 SSPL 라이선스를 사용하지만, Atlas가 매출의 75%를 차지하는 클라우드 중심 비즈니스 모델로 성공적으로 전환했다.

실무 선택 가이드

PostgreSQL을 선택해야 하는 경우

데이터가 이미 PostgreSQL에 있고 인프라를 단순하게 유지하고 싶다면 pg_search 또는 pg_textsearch가 최선의 선택이다. 트랜잭션 일관성이 중요한 금융, 전자상거래, SaaS 애플리케이션에서 검색과 데이터베이스 로직이 긴밀하게 결합되어 있을 때 특히 유용하다. 예를 들어 주문 생성과 동시에 검색 인덱스가 업데이트되어야 하는 경우, PostgreSQL의 ACID 트랜잭션 내에서 모두 처리할 수 있다.

스타트업과 중소기업이 월 수천 달러의 Elasticsearch 비용을 절감하기 위해 PostgreSQL로 전환하는 사례가 늘고 있다. 데이터 볼륨이 수천만 건 이하라면 PostgreSQL로 충분하며, 하이브리드 검색도 pgvector와의 조합으로 쉽게 구현할 수 있다. 팀에 이미 PostgreSQL DBA가 있다면 추가 학습 비용도 최소화된다.

다만 pg_search와 pg_textsearch 모두 AWS RDS, Google Cloud SQL 같은 관리형 서비스에서 사용할 수 없다는 제약이 있다. 자체 호스팅이나 Docker 배포가 필요하므로, 이를 수용할 수 있는 팀에게만 권장된다.

MongoDB Atlas를 선택해야 하는 경우

데이터가 이미 MongoDB에 있고, 완전 관리형 솔루션을 원하며, 인프라 관리 부담을 최소화하고 싶다면 Atlas Search가 이상적이다. JSON 문서 구조와 검색이 자연스럽게 통합되므로, 동적 스키마와 중첩 데이터를 다루는 애플리케이션에 적합하다. 전자상거래 제품 카탈로그처럼 카테고리별로 다른 속성을 가진 데이터를 검색할 때 강점을 발휘한다.

하이브리드 검색을 네이티브로 지원하는 $rankFusion과 $scoreFusion은 RAG 애플리케이션 구축 시 큰 장점이다. 별도의 수동 구현 없이 텍스트와 벡터 검색을 결합할 수 있으며, 가중치도 쉽게 조정할 수 있다. MongoDB의 개발자 경험과 생태계도 뛰어나다. 공식 드라이버가 모든 주요 언어를 지원하고, Atlas UI는 직관적이며, 문서화도 잘 되어 있다.

그러나 비용은 신중하게 고려해야 한다. 초기에는 무료 또는 Flex 계층으로 시작할 수 있지만, 프로덕션으로 확장하면 월 수백 ~ 수천 달러로 증가한다. Atlas Search 전용 노드 비용도 추가되므로, 총 소유 비용(TCO)을 정확히 계산해야 한다.

Elasticsearch를 선택해야 하는 경우

데이터 볼륨이 수억 ~ 수십억 건에 달하고, 복잡한 집계와 분석이 핵심 요구사항이며, 최고 수준의 검색 성능이 필요하다면 Elasticsearch가 여전히 최선이다. 로그 분석, 애플리케이션 모니터링, 보안 이벤트 분석처럼 시계열 데이터를 실시간으로 수집하고 검색해야 하는 경우 Elastic Stack(Elasticsearch + Logstash + Kibana)의 통합 솔루션이 강력하다.

BM25 파라미터(k1, b)를 도메인 특성에 맞게 세밀하게 튜닝할 수 있다는 점도 장점이다. 학술 논문, 법률 문서, 의료 기록처럼 특수한 랭킹 요구사항이 있는 경우 최적 파라미터를 찾아 적용할 수 있다. Function Score를 통해 BM25 점수에 비즈니스 로직(가격, 재고, 인기도 등)을 곱셈으로 결합하여 정교한 랭킹을 구현할 수 있다.

다만 운영 복잡도와 비용을 감당할 수 있어야 한다. Elasticsearch 전담 엔지니어 또는 외부 컨설팅이 필요하며, 클러스터 관리, JVM 튜닝, 샤드 리밸런싱 등에 지속적인 투자가 필요하다. 이미 Elasticsearch를 성공적으로 운영 중이고 팀에 전문성이 축적되어 있다면 계속 사용하는 것이 합리적이다. 그러나 새로운 프로젝트에서 처음 도입한다면, 먼저 PostgreSQL이나 MongoDB Atlas로 시작하는 것을 권장한다.

결론: 단순함이 이긴다

BM25 검색 기술은 성숙했고, PostgreSQL, MongoDB, Elasticsearch 모두 프로덕션 수준의 구현을 제공한다. 성능 차이는 점점 줄어들고 있으며, 선택의 핵심은 기술적 우수성보다 운영 복잡도, 비용, 팀 역량이다.

2025년 시장 동향은 명확하다. 대부분의 애플리케이션은 전문 검색 엔진의 복잡성을 필요로 하지 않으며, 데이터베이스에 내장된 검색으로 충분하다. PostgreSQL의 pg_search와 pg_textsearch는 Elasticsearch급 성능을 제공하면서도 인프라를 단순하게 유지할 수 있게 해준다. MongoDB Atlas는 관리형 서비스의 편의성과 하이브리드 검색의 강력함을 결합했다. Elasticsearch는 여전히 최고 성능을 제공하지만, 그 성능이 정말 필요한 시점은 대부분의 기업이 생각하는 것보다 훨씬 늦게 온다.

현명한 선택은 간단한 것부터 시작하는 것이다. PostgreSQL이나 MongoDB로 시작하고, 실제로 한계에 부딪힐 때 비로소 Elasticsearch를 고려하라. 많은 경우 그 시점은 영원히 오지 않을 수도 있다.

작성 일자: 2026-02-01

TechStack, Backend Architecture