Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 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/site 검색 (단순함) | Meilisearch·Typesense | Rust/C++로 가벼움, 셀프호스트 친화 |

| 종합 검색·분석 | Elasticsearch·OpenSearch | 거인 + AWS 포크 |

| 로그·observability 검색 | Quickwit·Loki·Elasticsearch | S3 기반이 새 흐름 |

| AI serving 검색 | Vespa | real-time ranking·tensor·ML 일등시민 |

| SaaS 사이트 검색 | Algolia | 자체 호스트 없음, 매우 빠름 |

| 초경량 | Sonic | 자동완성 정도, Rust |

| 검색·분석 융합 | Apache Doris·StarRocks·ClickHouse | OLAP가 검색을 흉수하기 시작 |

| 벡터 DB | Pinecone·Weaviate·Qdrant·Milvus·LanceDB | 다음 절에서 별도 |

대부분의 사람이 한 번에 다 검토하지 않는다. 시나리오 세 가지 — **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 지원 비교 표

| 도구 | BM25 | dense vector | RRF | 외부 reranker 통합 | ColBERT/late-interaction |

| --- | --- | --- | --- | --- | --- |

| Elasticsearch | O | O (HNSW) | O | 직접 호출 | 제한적 |

| OpenSearch | O | O (k-NN) | O | 직접 호출 | 제한적 |

| Vespa | O | O (HNSW·기타) | O | 인덱스 내장 가능 | **1군 시민** |

| Meilisearch | O | O | semanticRatio | embedder 통합 | 없음 |

| Typesense | O | O | alpha | 직접 호출 | 없음 |

| Quickwit | O | 제한적 | - | - | 없음 |

| Weaviate | 제한적 | O | hybrid 쿼리 | 모듈 | 없음 |

| Qdrant | sparse | O | RRF | 외부 | 제한적 |

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장 · 능력 매트릭스 — 한눈에 보는 비교

| --- | --- | --- | --- | --- | --- | --- | --- |

| 풀텍스트 (BM25/유사) | 매우 좋음 | 매우 좋음 | 좋음 | 좋음 | 좋음 | 좋음 | 매우 좋음 |

| 벡터 검색 | 좋음 (HNSW) | 좋음 (k-NN) | 좋음 | 좋음 | 제한적 | **매우 좋음** | 부가 |

| 분산 | 매우 좋음 | 매우 좋음 | 보통 | 좋음 | 좋음 (S3) | 매우 좋음 | SaaS only |

| 로그·시계열 | 좋음 | 좋음 | 부적합 | 부적합 | **매우 좋음** | 부적합 | 부적합 |

| RAG retrieval | 좋음 | 좋음 | 보통~좋음 | 보통~좋음 | 부적합 | **매우 좋음** | 보통 |

| 운영 복잡도 | 높음 | 높음 | 매우 낮음 | 낮음 | 중간 | 매우 높음 | SaaS only |

| 비용 | 비쌈 (hot tier) | 비쌈 | 저렴 | 저렴 | **매우 저렴** (S3) | 비쌈 | 사용량 폭증시 비쌈 |

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 공식](https://www.meilisearch.com/)

- [Meilisearch GitHub](https://github.com/meilisearch/meilisearch)

- [Meilisearch Hybrid Search Docs](https://www.meilisearch.com/docs/learn/ai_powered_search/hybrid_search)

- [Typesense 공식](https://typesense.org/)

- [Typesense GitHub](https://github.com/typesense/typesense)

- [Typesense Vector & Hybrid Search](https://typesense.org/docs/latest/api/vector-search.html)

- [Elasticsearch 공식](https://www.elastic.co/elasticsearch)

- [Elasticsearch AGPL Announcement (Aug 2024)](https://www.elastic.co/blog/elasticsearch-is-open-source-again)

- [Elasticsearch ESQL Documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/esql.html)

- [Elasticsearch Vector Search](https://www.elastic.co/what-is/vector-search)

- [OpenSearch 공식](https://opensearch.org/)

- [OpenSearch Software Foundation](https://opensearch.org/foundation)

- [OpenSearch k-NN Plugin](https://opensearch.org/docs/latest/search-plugins/knn/index/)

- [Quickwit GitHub](https://github.com/quickwit-oss/quickwit)

- [Quickwit Datadog Acquisition (Oct 2024)](https://www.datadoghq.com/blog/datadog-acquires-quickwit/)

- [Vespa 공식](https://vespa.ai/)

- [Vespa GitHub](https://github.com/vespa-engine/vespa)

- [Vespa ColBERT Tutorial](https://docs.vespa.ai/en/tutorials/colbert.html)

- [Algolia 공식](https://www.algolia.com/)

- [Sonic GitHub](https://github.com/valeriansaliou/sonic)

- [Apache Doris](https://doris.apache.org/)

- [StarRocks](https://www.starrocks.io/)

- [ClickHouse Full-Text Search](https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/invertedindexes)

- [Cohere Rerank](https://cohere.com/rerank)

- [Voyage AI Rerankers](https://docs.voyageai.com/docs/reranker)

- [BGE Reranker](https://huggingface.co/BAAI/bge-reranker-large)

- [Reciprocal Rank Fusion Paper](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)

- [Weaviate](https://weaviate.io/)

- [Qdrant](https://qdrant.tech/)

- [Milvus](https://milvus.io/)

- [LanceDB](https://lancedb.com/)

- [pgvector](https://github.com/pgvector/pgvector)

- [GitHub Blackbird (Code Search) Engineering Blog](https://github.blog/engineering/the-technology-behind-githubs-new-code-search/)