✍️ 필사 모드: 차세대 검색 엔진 2026 — Meilisearch·Typesense·Elasticsearch·OpenSearch·Quickwit·Vespa 심층 비교 (Elastic 이후의 풍경)

프롤로그 — Elasticsearch는 여전히 거인이지만, 풍경은 흩어졌다

2018년에 "검색 엔진 뭐 쓸까요"의 답은 사실상 하나였다. Elasticsearch. ELK 스택은 로그도 Elasticsearch였고, 사이트 검색도 Elasticsearch였고, 추천도 (어떻게든) Elasticsearch에서 굴렸다.

2026년에 같은 질문을 던지면 답이 다섯 갈래는 나온다.

• "in-app 검색이면 Meilisearch나 Typesense, 굳이 ES 안 써요."
• "로그 검색은 Quickwit으로 옮겼어요. S3에 그냥 두는 게 미친 가성비."
• "Elastic 라이선스 때문에 OpenSearch로 갔습니다. AWS에 살면 자연스러워요."
• "추천·RAG·real-time AI serving은 Vespa예요. 다른 게 못 따라옵니다."
• "여전히 Elasticsearch입니다. v3 라이선스도 살 만하고, ESQL이 좋아요."

이 글은 2026년 5월 기준 검색 엔진들을 솔직하게 비교한다. 각 엔진의 강점·약점, 그리고 모든 곳에 들어온 hybrid search(풀텍스트 + 벡터 + reranker)의 현실, 그리고 "언제 무엇을 골라야 하는가"에 대한 결정 프레임워크까지.

미리 결론을 한 줄로: "풀텍스트 vs 벡터" 이분법은 옛말이다. 2026년의 정답은 거의 항상 hybrid다. 다만 누가 hybrid를 가장 매끄럽게 해주는가는 다르다.

1장 · 도구 풍경 — 일곱 가지 + 알파

먼저 도구 지도를 그린다. 카테고리가 섞이지 않게.

대부분의 사람이 한 번에 다 검토하지 않는다. 시나리오 세 가지 — in-app 검색, 로그 검색, RAG 검색 — 으로 보면 후보가 자연스럽게 좁혀진다.

• In-app 검색 — 사이트 검색·상품 검색·문서 검색. Meilisearch·Typesense·Algolia·Elasticsearch·OpenSearch.
• 로그·observability — 트레이스·메트릭·로그. Quickwit·Elasticsearch·OpenSearch·Loki.
• RAG·real-time AI — 임베딩 + 풀텍스트 + reranker. Vespa·Elasticsearch·OpenSearch·Weaviate·Qdrant·pgvector + Meilisearch hybrid.

2장 · Elasticsearch — 거인이 살아 있다

Elasticsearch는 죽지 않았다. 오히려 2024~2025에 두 가지로 반격했다.

2.1 라이선스 — SSPL/Elastic License v2에서 AGPL/Elastic v3로

2024년 후반 Elastic이 Elasticsearch와 Kibana를 AGPL v3(Elastic License v2와 병행) 로 다시 오픈했다. 이 결정은 OpenSearch 진영에 대한 명백한 신호였고, OSS 친화 클라우드(Bonsai·Elastic Cloud·자체 호스트)에 다시 활기를 가져왔다. 다만 AWS 매니지드 Elasticsearch 서비스가 다시 돌아온다는 의미는 아니다 — AWS는 OpenSearch에 자원을 모두 투입한 상태다.

라이선스 결정의 핵심을 정리하면.

• AGPL v3 — 진짜 OSS. 단, 서비스로 호스트할 때 수정 코드 공개 의무.
• Elastic License v2 — 매니지드 SaaS로 재판매하지 않는 한 자유롭게 사용.
• 양자 택일 — 사용자가 둘 중 하나로 받음.

2.2 ESQL — SQL 같은 새 쿼리 언어

Elasticsearch 8.11+에서 ESQL(Elasticsearch Query Language)이 GA됐다. Lucene의 쿼리 DSL을 직접 짜는 대신, 파이프 기반 SQL-ish 문법으로 동일한 일을 한다.

FROM logs-*
| WHERE @timestamp > NOW() - 1 hour AND http.status >= 500
| STATS count(*) BY service.name
| SORT count DESC
| LIMIT 10

ESQL의 의미는 단순하다. "로그·메트릭에서 Elasticsearch가 OLAP에 더 가까워졌다" — Apache Doris·ClickHouse 같은 분석 엔진과 경쟁할 수 있는 표면을 갖췄다는 신호. ESQL은 검색 인덱스가 아니라 통계·집계에 최적화된 경로를 쓴다.

2.3 벡터 검색·hybrid가 1군 시민

8.x 후반부터 dense vector 필드와 HNSW 인덱스, BM25 + kNN의 hybrid 검색이 표준 기능이다. learning_to_rank·ELSER(Elastic이 학습한 sparse 임베딩) 도 제공돼서, 별도 벡터 DB 없이 RAG 파이프라인 한가운데에 둘 만한 옵션이 됐다.

2.4 Elasticsearch의 강점·약점

• 강점: 모든 시나리오에 쓸 수 있는 만능성, 풍부한 에코시스템(Kibana·Logstash·Beats·Fleet·APM), ES 8.x의 hybrid·ESQL.
• 약점: 운영 복잡도(JVM·shard·replica·노드 튜닝), 가격, 콜드 데이터 비용. 대량 로그 데이터를 모두 hot tier에 두려면 비용이 빨리 무서워진다.

3장 · OpenSearch — AWS 포크의 정치학과 기술학

2021년 ES SSPL 전환에 반발해 AWS가 fork한 OpenSearch는 5년이 지나 더 이상 "fork"가 아니라 독자 프로젝트다. 2026년의 현황.

• 거버넌스 — 2024년 9월 AWS는 OpenSearch 프로젝트를 Linux Foundation 산하 OpenSearch Software Foundation으로 이관했다. SAP·Uber·Aiven·Atlassian 등이 founding member로 참여. 이 변화의 의미는 큰데, "AWS-only 프로젝트"라는 인식을 깨고 다중 벤더 거버넌스를 만든 것.
• 호환성 — OpenSearch는 Elasticsearch 7.10에서 갈라졌고, 그 이후 API 호환성은 더 이상 1:1이 아니다. 다만 클라이언트 라이브러리 수준에서는 여전히 호환되는 부분이 많다.
• 벡터 — opensearch-knn 플러그인, HNSW·IVF·k-NN 지원. Faiss·Lucene 기반 백엔드 선택 가능.
• OpenSearch Dashboards — Kibana fork. 기능은 Kibana보다 한 발 늦지만 따라가는 중.

OpenSearch를 고르는 경우는 대체로 두 가지.

1. AWS에 살고 매니지드 검색을 쓴다 — Amazon OpenSearch Service가 가장 자연스러운 선택.
2. Elastic License v2의 SaaS 재판매 제약을 피해야 한다 — 자기가 제공하는 서비스의 일부로 검색 엔진을 노출하는 매니지드 검색 서비스 회사들.

대부분의 in-app·로그 시나리오에서 ES 또는 OpenSearch의 기능은 거의 동등하다. 다만 ESQL 같은 ES 신기능이 OpenSearch에는 다른 모양(PPL — Piped Processing Language)으로 들어오기 때문에, 이미 어느 한쪽 쿼리 언어에 코드가 짜여 있으면 옮기는 비용이 있다.

4장 · Meilisearch — Rust로 만든 단순함의 미학

Meilisearch는 in-app 검색에 특화된 Rust 검색 엔진이다. 2026년 5월 기준 v1.13+ 시리즈. 한마디로 정의하면 "Algolia 같은 경험을 셀프호스트로".

4.1 왜 인기인가

• 단일 바이너리 — Rust로 빌드된 정적 바이너리 하나. JVM 없음, 의존성 없음.
• 0 설정에 가까운 시작 — meilisearch 한 줄로 띄우고, JSON 문서 POST하면 즉시 검색 가능.
• typo tolerance·prefix·하이라이트·페이셋·동의어 — in-app 검색에 필요한 거의 모든 게 기본 탑재.
• JS·React·Vue SDK가 매끄럽다 — InstantMeiliSearch 같은 도구로 5분이면 UI에 붙는다.

4.2 2026년 새 기능 — Vector·Hybrid

Meilisearch는 v1.6에서 dense vector 검색을 도입했고, 2025년 들어 embeddings·rerankers·hybrid가 안정화됐다.

// Meilisearch 1.x — hybrid 검색
const results = await client.index('products').search('blue runners', {
  hybrid: {
    embedder: 'openai',
    semanticRatio: 0.7,
  },
  limit: 20,
})

semanticRatio: 0.7은 "벡터 70%, BM25 30% 가중치로 섞기". 0이면 풀텍스트 only, 1이면 벡터 only.

4.3 Meilisearch의 강점·약점

• 강점: 가장 단순한 운영, 가장 빠른 시작, in-app 검색에 거의 모든 게 기본 제공, 엣지·셀프호스트 친화적.
• 약점: 분산·샤딩이 ES만큼 성숙하지 않음 (멀티 노드 클러스터링이 후순위), 로그 검색·OLAP 시나리오에는 부적합, 매우 큰 단일 인덱스(수억 문서 이상)는 ES가 더 안정적.

언제 고르는가 — 상품 카탈로그·문서 검색·블로그 검색·작은~중간 in-app 검색. Algolia를 셀프호스트로 대체하려는 거의 모든 경우.

5장 · Typesense — C++로 만든 또 다른 in-app 강자

Typesense는 C++로 작성된 in-app 검색 엔진이다. Meilisearch와 같은 시나리오를 노리지만, 철학이 약간 다르다.

5.1 Meilisearch와의 차이

• 언어 — Meilisearch는 Rust, Typesense는 C++. 둘 다 단일 바이너리. 성능은 거의 비등.
• 분산 — Typesense는 처음부터 Raft 기반 분산 클러스터링을 지원. 멀티 노드 HA가 v0.x부터 1군 시민.
• multi-tenancy — 한 클러스터에 여러 컬렉션, 컬렉션마다 API key의 search scope를 좁히는 패턴이 매끄럽다. SaaS의 in-app 검색에 잘 맞음.
• 시각화 도구 — Typesense Dashboard는 ES Kibana만큼은 아니지만, 도구 자체가 단순해서 큰 대시보드가 필요 없다.

5.2 2026년 새 기능 — Conversational·Vector·Hybrid

Typesense는 v0.25+부터 벡터 검색·hybrid·자연어 검색을 들고 왔다. "Conversational search" — LLM과 결합해 자연어 질문에 직접 답하는 endpoint도 v28.x에서 GA.

const result = await client.collections('products').documents().search({
  q: 'red running shoes under 100',
  query_by: 'name,description,embedding',
  vector_query: 'embedding:([], k: 50, alpha: 0.4)',
})

alpha: 0.4 — Meilisearch의 semanticRatio와 같은 개념. 풀텍스트와 벡터의 가중치.

5.3 Typesense의 강점·약점

• 강점: 분산 클러스터링이 1군 시민, multi-tenant 친화, 매우 빠른 응답 시간, SDK가 잘 짜여 있음.
• 약점: 커뮤니티가 Meilisearch보다 조금 작음(절대 작은 건 아니지만 상대적으로), 일부 자연어/이질문자 시나리오에서 Meilisearch가 약간 매끄러움.

언제 고르는가 — SaaS의 multi-tenant in-app 검색, 분산이 처음부터 필요한 in-app 검색.

6장 · Quickwit — S3-native 로그 검색 그리고 Datadog 인수

Quickwit은 검색 엔진 풍경에서 가장 최근의 큰 사건이다. Rust로 작성된 로그 검색 특화 엔진으로, 객체 스토리지(S3·GCS·Azure Blob)를 1차 저장소로 사용한다는 점에서 ES와 결정적으로 다르다.

6.1 왜 중요한가 — "S3에 그냥 두는 게 미친 가성비"

ES로 로그를 운영해 본 사람은 안다. 시계열 데이터를 hot tier에 두려면 SSD가 끝없이 필요하고, frozen tier·snapshot·ILM 설정은 운영 부담의 절반을 차지한다.

Quickwit의 모델은 정 반대다.

• 인덱스 파일(splits)을 S3에 그대로 두고, 검색 시에 필요한 부분만 가져온다.
• 컴퓨트와 스토리지가 완전 분리. 검색 노드는 stateless. 인덱싱 노드만 약간의 상태.
• 비용 단가는 S3 가격이다. 즉 EBS/SSD 대비 한 자릿수 분의 1.

6.2 2024년 Datadog 인수 — 그 후

2024년 10월 Datadog이 Quickwit을 인수했다. 인수 후 Quickwit OSS는 어떻게 되는가가 시장의 가장 큰 질문이었는데, 2025~2026 사이 답은 "유지된다, 단 핵심 개발은 Datadog 내부 로그·트레이스 시스템에 더 깊이 들어간다".

• OSS 자체 — Apache 2.0 라이선스로 유지. GitHub repo도 활발히 업데이트.
• 상용 클라우드 — Quickwit Cloud는 신규 가입을 종료. 대신 Datadog 매니지드 로그가 Quickwit 기반으로 동작.
• 신규 채택 위험 — 인수 후 OSS의 "공식 매니지드" 옵션이 사라진 셈. 셀프호스트할 자신이 있으면 여전히 최고의 선택이지만, "관리자 없이 그냥 쓰고 싶은" 회사에게는 위험 신호.

6.3 Quickwit의 데이터 모델

ES와 다른 두 가지.

1. append-only 시계열 위주 — 업데이트는 제한적. 로그·트레이스에 최적화.
2. schema-less가 1군 — JSON 그대로 받아서 인덱싱. 동적 필드 매핑이 ES보다 매끄러움.

쿼리는 Elasticsearch DSL과 유사한 형태도 지원하고, OpenTelemetry·Jaeger·Grafana와의 통합이 1군이다.

6.4 Quickwit의 강점·약점

• 강점: S3-native로 압도적 비용 효율, 로그·트레이스 시나리오에 최적화, OpenTelemetry/Grafana 통합, stateless 검색 노드.
• 약점: in-app 검색에는 부적합(업데이트가 약함), Datadog 인수 후 OSS 매니지드가 사라짐, 풀텍스트 외 기능(벡터·집계의 일부)은 ES보다 덜 풍성함.

언제 고르는가 — 로그·트레이스·observability 검색, S3에 콜드 데이터까지 다 두고 싶을 때.

7장 · Vespa — 진짜 AI serving 검색

Vespa는 흥미로운 위치에 있다. Yahoo!의 내부 검색·추천 인프라에서 시작해, 2017년 오픈소스화, 2023년 Verizon Media에서 Vespa.ai로 spinoff. 2026년 기준 v8.x.

Spotify·Wikipedia·Pinterest 같은 곳의 검색·추천 시스템이 Vespa로 돌아간다. 무엇이 특별한가.

7.1 다른 검색 엔진과의 결정적 차이

• Tensor가 1군 시민 — 임베딩·다차원 텐서를 인덱스/스토리지/쿼리에 직접 다룬다. 벡터 검색이 부가 기능이 아니라 핵심.
• ranking pipeline이 1군 시민 — first-phase·second-phase·global-phase ranking이 구조에 있다. ONNX·TensorFlow 모델을 ranking 단계에서 직접 실행.
• real-time write + serving — 인덱싱과 서빙이 같은 노드. 실시간 업데이트가 매끄럽다.

이게 RAG·추천·real-time AI serving에 강한 이유다.

7.2 ColBERTv2 — Vespa가 가장 매끄럽게 다루는 reranker

ColBERTv2는 dense retrieval과 cross-encoder reranking 사이의 효율적인 중간점이다. 각 토큰별 임베딩으로 late interaction을 계산하는데, Vespa는 이를 1군 시민으로 다룬다 — 인덱스에 ColBERT 텐서를 직접 저장하고, ranking 단계에서 효율적인 MaxSim 계산을 한다.

7.3 Vespa의 강점·약점

• 강점: 진짜 AI serving 검색, 텐서·임베딩·모델이 1군 시민, real-time 업데이트, 매우 큰 규모 입증됨.
• 약점: 학습 곡선이 가파름, 운영 복잡도가 ES보다 더 큼, 작은 in-app 검색에는 과함, 매니지드 옵션(Vespa Cloud) 외에는 셀프호스트 운영 부담.

언제 고르는가 — 추천 시스템 핵심, RAG의 진짜 핵심, 검색과 ranking 모두 ML 모델로 돌아가는 곳.

8장 · Algolia·Sonic·Apache Doris·StarRocks — 그 외의 풍경

8.1 Algolia — SaaS 사이트 검색의 여전한 1위

Algolia는 셀프호스트 옵션이 없다. SaaS로만 제공된다. 그게 강점이자 약점.

• 강점: 매우 빠른 응답(글로벌 엣지 CDN), 운영 부담 0, InstantSearch UI 키트가 가장 성숙.
• 약점: 비용이 빠르게 커짐(record 수·쿼리 수 기반), 데이터 sovereignty 제약, 셀프호스트 불가.

언제 고르는가 — 트래픽이 적고 빠르게 출시해야 하는 in-app 검색, 사이트 검색·블로그 검색. 트래픽·record 수가 커지면 Meilisearch·Typesense로 마이그레이션하는 패턴이 흔하다.

8.2 Sonic — 극단적으로 가벼운 자동완성

Sonic은 Rust로 작성된 극단적으로 가벼운 검색 엔진이다. "자동완성·suggest"에 특화. SQLite 같은 인덱스 파일에 메모리 사용량은 거의 없는 수준.

• 강점: 매우 가벼움, 시작이 빠름.
• 약점: 풀텍스트 검색이 단순함, 페이셋·하이라이트가 제한적, 벡터 없음.

언제 고르는가 — 검색이 거의 자동완성이고, 메인 검색은 다른 도구가 처리할 때. 사실 2026년 기준 거의 모든 자동완성을 Meilisearch·Typesense가 잘 처리하기 때문에 Sonic의 영역은 작아진 편.

8.3 Apache Doris·StarRocks — OLAP가 검색을 잠식하다

Doris·StarRocks·ClickHouse 같은 컬럼형 OLAP가 inverted index·텍스트 검색을 지원하기 시작하면서 "분석 데이터에서 검색도 같이"라는 새 시나리오가 열렸다. 특히 로그·이벤트 데이터처럼 분석과 검색이 같은 데이터에 일어나는 경우에 매력적.

• 강점: 한 시스템에 분석과 검색.
• 약점: 풀텍스트 검색의 매끄러움(랭킹·동의어·페이셋)은 ES만큼 성숙하지 않음.

언제 고르는가 — 분석이 핵심이고 검색은 부가. 메인 사이트 검색을 이걸로 돌리는 건 아직 무리.

9장 · Hybrid Search — 2026년의 기본값

"풀텍스트 검색 vs 벡터 DB"의 이분법은 옛말이다. 2026년의 검색은 거의 항상 hybrid다. 그 구조를 풀어 쓴다.

9.1 hybrid의 세 층

1. retrieval (1차 검색)
   - BM25 (풀텍스트, lexical match)
   - Dense vector (의미 기반, embedding ANN)
   - 두 결과를 RRF 또는 가중합으로 결합

2. reranking (2차 정렬)
   - cross-encoder 또는 ColBERT 같은 모델
   - 상위 50~200개 결과만 다시 정렬
   - 비싸지만 품질에 크게 기여

3. business logic (3차 정렬)
   - 인기도·최신성·개인화·비즈니스 규칙

이 세 층을 어떻게 구현하는가가 엔진별로 다르다.

9.2 RRF (Reciprocal Rank Fusion) — hybrid의 표준 결합

두 개의 ranked list(BM25 결과·벡터 결과)를 어떻게 합치는가. 가장 흔한 방법이 RRF.

RRF_score(d) = sum( 1 / (k + rank_i(d)) )  for each ranker i

k는 보통 60. 단순하지만 매우 견고. ES·OpenSearch·Vespa·Meilisearch·Typesense 모두 RRF 또는 그 변형을 지원.

9.3 Reranker — Cohere Rerank·Voyage·ColBERT

• Cohere Rerank — Cohere가 학습한 cross-encoder. API로 호출. 가격은 query당 과금. 가장 보편적인 선택.
• Voyage AI rerankers — voyage-rerank 시리즈. Cohere와 직접 경쟁. 일부 도메인에서 더 좋음.
• Vespa의 ColBERTv2 — late interaction 방식. 모델이 인덱스에 임베딩되어 reranker가 외부 API에 의존하지 않음.
• 오픈소스 rerankers — bge-reranker·mxbai-rerank·jina-rerank. 자체 호스트.

reranking은 보통 retrieval 결과의 상위 50~200개에만 적용한다. 그 이상은 비용이 폭발.

9.4 hybrid 지원 비교 표

10장 · 풀텍스트 vs 벡터 DB vs 둘 다 — 결정 프레임워크

10.1 풀텍스트만으로 충분한 경우

• 상품 카탈로그 — SKU·이름·태그가 정확하게 일치. 의미 검색 필요성이 낮음.
• 로그·트레이스 — 정확한 키워드·식별자 매칭이 핵심.
• 개발자 도구의 검색 — 코드·식별자·정확 매칭.

→ Meilisearch·Typesense·Quickwit·Elasticsearch·OpenSearch 중 시나리오에 맞는 것.

10.2 벡터만으로 충분한 경우

거의 없다. 순수 벡터 검색은 짧은 쿼리·정확 매칭·식별자 검색에 약하다. 키워드 검색이 동시에 가능한 환경이 거의 항상 좋다.

예외 — 이미지·오디오·비디오 유사도 검색처럼 텍스트 인덱스가 없는 경우. 이때는 Pinecone·Qdrant·Milvus·Weaviate·LanceDB 같은 순수 벡터 DB가 자연스러움.

10.3 hybrid가 정답인 경우 (대부분)

• 사이트 검색의 의미 확장 — "blue runners" → 운동화 검색.
• RAG 검색 — 사용자 질문에서 문맥 문서 가져오기.
• 사내 문서·지식 베이스 검색 — 동의어가 많고 키워드가 변동적.
• 추천 시스템의 1단계 candidate 생성.

→ Vespa·Elasticsearch·OpenSearch·Meilisearch hybrid·Typesense hybrid 중 시나리오와 운영 부담 균형으로.

11장 · 능력 매트릭스 — 한눈에 보는 비교

12장 · 시나리오별 권장 — in-app·로그·RAG

세 시나리오를 결정 트리로 푼다.

12.1 In-app 검색 (사이트·상품·문서)

- 트래픽 적고 빨리 출시: Algolia
- 셀프호스트 원함, 단순: Meilisearch
- 셀프호스트 원함, multi-tenant: Typesense
- 이미 ES/OS 있고 운영 가능: Elasticsearch / OpenSearch
- 검색이 ML로 ranking되어야 함: Vespa (운영 부담 감수)

12.2 로그·observability

- 비용 우선, 데이터 양 큼: Quickwit (셀프호스트)
- 매니지드, AWS: Amazon OpenSearch Service
- 매니지드, multi-cloud: Elastic Cloud, Grafana Cloud Loki
- Datadog 이미 쓰는 중: Datadog (내부 Quickwit)

12.3 RAG·real-time AI serving

- 1단계 retrieval만 필요: Meilisearch/Typesense hybrid + 외부 reranker
- 본격 ranking pipeline 필요: Vespa
- ES/OS 이미 있고 운영 가능: ES/OS dense_vector + reranker
- 이미지·오디오 위주: Pinecone/Qdrant/Milvus/Weaviate
- Postgres가 진실의 원천: pgvector + 외부 reranker

13장 · 실제 사례 — 어디서 무엇을 쓰는가

• Spotify — Vespa를 검색·추천 핵심에 사용. 노래·아티스트·플레이리스트의 ranking.
• Wikipedia — 검색에 Elasticsearch 기반(CirrusSearch), 일부 추천에 Vespa 실험.
• Pinterest — 추천에 Vespa, 일부 검색에 Elasticsearch.
• HackerNews 검색 — Algolia (오랜 파트너십).
• Datadog 로그 검색 — Quickwit (인수 후 내부 흡수).
• GitHub Code Search — Blackbird (자체 엔진). 2023~2024년에 ES에서 마이그레이션.
• GitLab 검색 — Elasticsearch.
• Notion 검색 — 자체 구현 + ElasticSearch + 벡터 DB hybrid.
• Shopify — Elasticsearch 기반 상품 검색 + 자체 ML ranking.
• 소규모 SaaS — Algolia 또는 Meilisearch·Typesense.

이 분포에서 보이는 패턴.

• 대규모 추천·랭킹 → Vespa 또는 자체 구축.
• 대규모 풀텍스트·로그 → Elasticsearch.
• 로그 전용·비용 최적 → Quickwit/Datadog.
• in-app 검색 → Algolia·Meilisearch·Typesense.
• 이미 AWS → OpenSearch.

14장 · 운영 비용·복잡도 — 진짜 비용은 어디에서 나오는가

엔진 선택에서 가장 자주 무시되는 변수는 운영 비용이다. 라이선스 가격이 아니라 사람의 시간 + 인프라 + 데이터 이동 비용.

14.1 인프라 비용

대략적인 한 자릿수 차이.

• Quickwit (S3 기반) — 1x (기준).
• Meilisearch·Typesense (단일 노드) — 비슷한 수준, 데이터 양에 따라.
• Elasticsearch·OpenSearch (hot tier SSD) — 5~10x (대량 로그).
• Algolia (record당 과금) — 작을 때 저렴, 커지면 매우 비쌈.
• Vespa Cloud — 중간~상위.

14.2 운영 시간 비용

• Algolia — 거의 없음 (SaaS).
• Meilisearch·Typesense — 거의 없음 (단일 바이너리, 운영 단순).
• OpenSearch·Elasticsearch — 큼 (shard·노드·ILM·튜닝).
• Vespa — 매우 큼 (학습 곡선·운영 복잡도).
• Quickwit — 중간 (객체 스토리지 운영 + 자체 운영).

14.3 마이그레이션 비용

• 풀텍스트 → 풀텍스트 (예: ES → Meilisearch) — 보통.
• 풀텍스트 → AI serving (예: ES → Vespa) — 매우 큼.
• in-app → 로그 엔진 (예: Algolia → Quickwit) — 거의 의미 없음 (시나리오가 다름).

라이선스가 비싸 보인다고 엔진을 갈아엎기 전에, 마이그레이션 + 운영 시간 + 학습 비용을 합쳐서 본다.

에필로그 — 검색은 풀텍스트도 벡터도 아니다, 검색이다

2026년 5월의 검색 풍경을 한 줄로 요약하면.

"Elasticsearch가 거인이고, in-app과 로그가 갈라졌고, AI serving은 Vespa가 가져갔고, 모든 곳에 hybrid가 들어왔다."

결정 체크리스트

• 시나리오는 무엇인가? — in-app / 로그 / RAG / 추천 중 하나로 좁힌다.
• 운영 인력 있는가? — 없으면 매니지드 SaaS (Algolia·Elastic Cloud·OpenSearch Service).
• 셀프호스트하면 누가 운영하는가? — 단순함 우선이면 Meilisearch/Typesense.
• AGPL 라이선스 괜찮은가? — 아니면 OpenSearch.
• 로그 비용이 폭발하나? — Quickwit 검토.
• 검색에 ML ranking 모델이 들어가야 하나? — Vespa.
• hybrid가 필요한가? — 거의 항상 yes. 어떤 엔진이 가장 매끄러운지 본다.
• 벡터 DB가 정말 필요한가? — 텍스트가 동반되면 hybrid 엔진이 나음.

안티 패턴

1. "Elasticsearch가 다 해준다" — 모든 시나리오를 ES로 — 운영 비용이 빨리 폭발.
2. "벡터 DB 하나로 hybrid도 풀텍스트도 다" — 키워드 매칭의 정확도가 무너짐.
3. "Quickwit으로 in-app 검색" — 업데이트 약함, 시나리오 미스매치.
4. "Vespa로 모든 검색" — 운영 복잡도가 in-app 검색에 비해 압도적.
5. "Algolia로 무한히 키운다" — record가 수천만 넘으면 셀프호스트 검토.
6. "OS == ES"라고 가정 — 7.10 이후 API·기능 차이가 누적.
7. "hybrid 안 쓰고도 충분" — 2026년에 사용자 기대치가 그렇지 않다.

다음 글 예고

다음 후보 — Vespa 첫 90일 — Spotify 스타일 추천 시스템 셀프호스트 가이드, Quickwit 자체 호스트 — S3·Kubernetes 위에 로그 검색 만들기, Meilisearch + Cohere Rerank로 RAG 한 시간만에 만들기.

"검색은 데이터베이스가 아니다. 검색은 사용자 경험이다. 도구는 그 끝에서 골라진다."

— 차세대 검색 엔진 2026, 끝.

참고 / References

• Meilisearch 공식
• Meilisearch GitHub
• Meilisearch Hybrid Search Docs
• Typesense 공식
• Typesense GitHub
• Typesense Vector & Hybrid Search
• Elasticsearch 공식
• Elasticsearch AGPL Announcement (Aug 2024)
• Elasticsearch ESQL Documentation
• Elasticsearch Vector Search
• OpenSearch 공식
• OpenSearch Software Foundation
• OpenSearch k-NN Plugin
• Quickwit GitHub
• Quickwit Datadog Acquisition (Oct 2024)
• Vespa 공식
• Vespa GitHub
• Vespa ColBERT Tutorial
• Algolia 공식
• Sonic GitHub
• Apache Doris
• StarRocks
• ClickHouse Full-Text Search
• Cohere Rerank
• Voyage AI Rerankers
• BGE Reranker
• Reciprocal Rank Fusion Paper
• Weaviate
• Qdrant
• Milvus
• LanceDB
• pgvector
• GitHub Blackbird (Code Search) Engineering Blog