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

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

프롤로그 — 검색은 다시 인프라가 되었다

2010년대 중반, 검색은 SaaS의 시대였다. Algolia가 인덱싱·랭킹·UI 위젯까지 한 번에 묶어 팔았고, "검색을 직접 짜는 회사는 없다"는 말이 SaaS 영업 자료에 단골 문구로 박혀 있었다.

2026년의 풍경은 완전히 다르다.

- Algolia는 여전히 시장 선두지만, 검색 1M회당 약 1.0~1.4 USD 요금제는 e-커머스와 미디어가 감당하기 어려워졌다.

- Elastic이 라이선스를 Elastic License 2.0으로 바꾼 뒤, AWS가 OpenSearch를 포크해 키운 결과 ALv2 OSS 진영이 두 갈래가 되었다.

- Meilisearch 1.13, Typesense 27, Manticore Search 6.x가 "Algolia 대안"으로 자리 잡았다.

- ParadeDB는 Postgres 안에서 BM25 검색을 끝내는 새로운 접근을 만들었다.

- Orama(구 Lyra)는 TypeScript로 짠 검색을 브라우저·엣지·서버 어디서든 돌린다.

- AI 시대의 RAG 수요가 폭증하면서 벡터·BM25·하이브리드를 한 엔진에서 다 해결하는 흐름이 굳었다.

이 글은 2026년의 셀프 호스트 검색 엔진 지형을 — 왜 셀프 호스팅을 하는가, 어떤 엔진이 어떤 워크로드에 맞는가, 한국어·일본어 토크나이저는 어디서 어떻게 끼는가, RAG와 벡터 검색은 어떻게 들어오는가 — 한 호흡으로 정리한다.

1장 · 왜 셀프 호스팅인가 — 비용·통제·커스터마이징

먼저 셀프 호스팅을 하는 세 가지 이유부터.

첫째, **비용**. Algolia는 검색 1M회당 약 1.0~1.4 USD, 인덱스 레코드는 별도. e-커머스에서 일 1M 검색이면 월 30~50K USD다. Elastic Cloud의 Search Premium 티어도 노드당 월 수백 USD에서 시작한다. Meilisearch나 Typesense를 자체 호스팅하면 EC2 r6g.large 한 대(월 약 80 USD)로 같은 트래픽을 처리할 수 있다.

둘째, **데이터 통제**. 검색 쿼리는 사용자 의도가 가장 진하게 드러나는 데이터다. 의료·금융·법무는 SaaS로 빠지는 순간 컴플라이언스 부담이 커진다. EU의 DSA·DSP 같은 신규 규제도 검색 로그의 처리 지점을 묻는다.

셋째, **커스터마이징**. 토크나이저·랭킹·동의어·시노님·필드 부스팅을 마음대로 바꾸려면 결국 엔진 내부에 손을 대야 한다. 한국어·일본어처럼 형태소 분석이 필요한 언어는 더 그렇다.

이 세 축의 무게가 2024년부터 빠르게 셀프 호스트 쪽으로 옮겨갔다.

2장 · Algolia — 관리형 검색의 표준

먼저 비교 기준이 되는 Algolia부터 정리하자.

| 항목 | 내용 |

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

| 출시 | 2012 |

| 라이선스 | 폐쇄(상용) |

| 강점 | UI 위젯, 글로벌 분산, 즉시 인덱싱 |

| 약점 | 검색 1M당 1~1.4 USD, 데이터 외부 저장 |

| 키 워크로드 | 매장 검색, 미디어, SaaS 인앱 검색 |

NeuralSearch는 2023년에 출시된 벡터+렉시컬 하이브리드다. 데이터를 그대로 두고 임베딩만 추가 인덱싱하는 형태로, 별도 벡터 DB가 필요 없다. DocSearch는 오픈소스 문서 사이트에 무료로 깔리는 Algolia의 부분집합이다.

문제는 가격이다. 트래픽이 늘면 늘수록 한 검색당 마진을 Algolia가 가져간다. 셀프 호스트 엔진들의 등장은 이 구조를 흔든 결과다.

3장 · Meilisearch 1.13 — 프랑스가 만든 "쉬운 검색"

Meilisearch는 2018년 프랑스 파리에서 시작된 MIT 라이선스 검색 엔진이다. Rust로 짜였고, 한 줄 요약은 "Algolia처럼 쉽지만 셀프 호스트 가능".

Docker 한 줄로 시작

docker run -p 7700:7700 getmeili/meilisearch:v1.13

인덱싱 — JSON 한 덩어리 POST

curl -X POST 'http://localhost:7700/indexes/products/documents' \

-H 'Content-Type: application/json' \

--data-binary @products.json

검색

curl 'http://localhost:7700/indexes/products/search' \

-H 'Content-Type: application/json' \

--data-binary '{"q":"shoes","limit":5}'

특징은 다음과 같다.

- **타이포 허용**: 거리 1~2의 편집 거리 자동 매칭. "shoees"가 "shoes"와 매칭된다.

- **인스턴트 검색**: 모든 키스트로크 ~50ms 응답 목표. 평균 p99 50ms 이하.

- **다국어**: ICU 토크나이저 기본, 한국어·일본어·중국어 자동 감지.

- **AI 검색 베타**: 1.6에서 임베더 추가, 1.13에서 하이브리드 검색 정식.

- **싱글 노드 우선**: 클러스터링은 v2에서 본격 도입 예정.

가장 빠르게 도입되는 시나리오는 SaaS 인앱 검색, 문서 사이트, 작은~중간 e-커머스다. 다만 분산이 약하기 때문에 인덱스가 100GB를 넘기면 다른 엔진을 봐야 한다.

4장 · Typesense 27 — Algolia의 오픈소스 클론

Typesense는 2019년 시작된 GPLv3 검색 엔진이다. C++로 짜였고, Algolia의 API·랭킹·UI 위젯을 거의 그대로 따라갔다. 2024년에 v27가 나오면서 클러스터링·벡터 검색·conversational search까지 채웠다.

docker-compose.yml

services:

typesense:

image: typesense/typesense:27.0

environment:

TYPESENSE_API_KEY: xyz

TYPESENSE_DATA_DIR: /data

volumes:

- ./typesense-data:/data

ports:

- 8108:8108

컬렉션 생성

curl 'http://localhost:8108/collections' \

-X POST \

-H 'X-TYPESENSE-API-KEY: xyz' \

-H 'Content-Type: application/json' \

-d '{

"name": "products",

"fields": [

{"name": "title", "type": "string"},

{"name": "price", "type": "float"},

{"name": "embedding", "type": "float[]", "num_dim": 768}

]

Typesense는 Meilisearch보다 **클러스터링이 자연스럽다**. Raft 기반 복제로 3노드부터 안정적으로 돈다. instantsearch.js와 직접 호환되는 점도 강점이다. Algolia에서 Typesense로 마이그레이션하는 e-커머스가 많은 이유다.

| 항목 | Meilisearch | Typesense |

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

| 언어 | Rust | C++ |

| 라이선스 | MIT | GPLv3 |

| 클러스터 | 약함 (v2 예정) | 강함 (Raft) |

| API | 자체 | Algolia 호환 |

| 메모리 | 낮음 | 더 높음 (인덱스 메모리 상주) |

| 타이포 | 강함 | 강함 |

5장 · Manticore Search — Sphinx의 정통 후계자

Manticore Search는 1990년대 Sphinx Search의 정통 후계자다. GPLv3, C++로 짜였고, 풀텍스트 검색에서 가장 오래된 엔진 중 하나다.

-- Manticore는 SQL 인터페이스가 본진이다

CREATE TABLE products (

title TEXT,

description TEXT,

price FLOAT,

category STRING

);

INSERT INTO products VALUES (1, 'Red shoes', '...', 99.99, 'shoes');

SELECT * FROM products WHERE MATCH('red');

특징은 다음과 같다.

- **SQL 우선**: MySQL 와이어 프로토콜을 그대로 받아 SQL 클라이언트로 접근 가능.

- **풀텍스트 표현식**: 구문, 근접도, 와일드카드, 정규식까지.

- **RT 인덱스**: 실시간 삽입·갱신.

- **퍼콜레이션**: 인덱스 쪽이 아니라 쿼리 쪽을 미리 저장해 매칭하는 역방향 검색.

- **벡터 검색**: 6.x에서 추가, HNSW 기반.

Meilisearch나 Typesense보다 **튜닝 폭이 크다**. 인덱스 빌더·랭커·토크나이저를 깊게 만질 수 있고, 대용량 텍스트에서도 빠르다. 다만 학습 곡선은 가파르다.

6장 · OpenSearch 2.x — Elastic의 AWS 포크

2021년 Elastic이 라이선스를 Elastic License 2.0으로 바꾸면서, AWS가 Elasticsearch 7.10 시점의 코드를 포크해 만든 게 OpenSearch다. ALv2로 유지된다.

Helm 차트로 클러스터 세 개 노드 띄우기

helm install opensearch opensearch/opensearch \

--set replicas=3 \

--set persistence.size=100Gi

인덱스 생성

curl -X PUT 'localhost:9200/products' -H 'Content-Type: application/json' -d '{

"mappings": {

"properties": {

"title": {"type": "text", "analyzer": "nori"},

"price": {"type": "float"},

"embedding": {"type": "knn_vector", "dimension": 768}

}

OpenSearch가 2.x에서 채운 핵심은 **Neural Search**다. 임베딩 파이프라인을 인덱스에 붙여 인제스트 시점에 벡터를 생성하고, 쿼리에서 BM25 + 벡터를 RRF로 묶는다.

`RRF(k=60)`로 두 점수를 합치는 게 기본이다.

OpenSearch의 강점은 분산이다. 100개 노드 클러스터, 1PB 인덱스, 멀티 테넌트까지 검증된 운영 경험이 있다. 다만 메모리·디스크 비용이 비싸고, JVM 튜닝 부담이 있다. 로그 검색을 겸한다면 압도적으로 좋은 선택이다.

7장 · Elasticsearch 8.x / 9.0 — 라이선스가 다시 갈라진 본가

Elasticsearch 본가는 8.x에서 9.0으로 넘어오면서 Vector Search(KNN), ESQL(SQL 유사 쿼리 언어), Search AI Platform 같은 기능을 채웠다.

[Elasticsearch 9.0 핵심 차이]

- ESQL: 새 쿼리 언어, 파이프라인 표현식

- KNN: HNSW 기반 벡터 검색, GPU 가속 베타

- Semantic search: ELSER 임베딩 빌트인

- Search AI: RAG 파이프라인 빌트인

- 라이선스: Elastic License 2.0 또는 SSPL (양자택일)

가장 큰 변화는 **AGPL 라이선스 추가**다. 2024년 8월부터 ELv2·SSPL·AGPLv3 셋 중에서 고를 수 있게 됐다. 사실상 OSS 진영으로 다시 합류하는 신호로 읽힌다.

Elasticsearch는 여전히 가장 **풍부한 기능셋**을 가진다. 머신러닝, APM, 보안, RUM까지 한 스택으로 묶이는 Elastic Stack(ELK)의 일원이다. 다만 OpenSearch와의 호환성은 7.10 이후로 점점 멀어지고 있다.

8장 · Solr 9 — 클래식 엔터프라이즈의 자존심

Apache Solr는 2004년 시작된 Lucene 기반의 가장 오래된 OSS 검색 엔진이다. 9.0에서 Java 11로 올라가고 SolrCloud의 ZooKeeper 의존을 줄였다.

Solr의 강점은 **튜닝의 자유도**다. 토크나이저·필터·랭커를 XML로 줄줄이 조립할 수 있고, 한국어용 Mecab-ko, 일본어용 Kuromoji, 중국어용 ICU 같은 토크나이저가 다 들어온다.

LINE Yahoo는 일본어 검색을 Solr 위에 오래 굴려왔고, 2024년부터 점진적으로 Vespa로 옮기는 중이다. Elasticsearch가 운영성·UX에서 앞서면서 Solr의 시장은 줄었지만, 정밀 튜닝이 필요한 엔터프라이즈에서는 여전히 살아 있다.

9장 · Vespa.ai — 야후가 만든 랭킹 엔진

Vespa는 야후가 2017년에 오픈소스화한 검색·랭킹 플랫폼이다. ALv2 라이선스, C++ 코어, 한 줄 요약은 "BM25 + 벡터 + 랭킹 모델을 한 곳에서".

schema.sd — Vespa의 스키마 DSL

schema product {

document product {

field title type string {

indexing: index | summary

index: enable-bm25

}

field embedding type tensor<float>(x[768]) {

indexing: attribute | index

attribute {

distance-metric: angular

}

rank-profile hybrid inherits default {

first-phase {

expression: bm25(title) + closeness(embedding)

}

Vespa의 차별점은 **랭킹 모델을 엔진 안에서 돌린다**는 것이다. ONNX 모델을 첨부해 두 단계 랭킹(first-phase, second-phase)을 굴릴 수 있고, GBDT·MLP·트랜스포머까지 들어간다.

야후의 광고·뉴스·메일 검색이 모두 Vespa 위에서 돈다. 텐서 연산을 1차 시민으로 다루는 거의 유일한 OSS 검색 엔진이다. 다만 학습 곡선이 거대하고, 작은 팀이 다루기엔 무겁다.

10장 · Quickwit · Tantivy · Bleve · Whoosh — 라이브러리/특화 엔진

| 도구 | 언어 | 라이선스 | 특징 |

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

**Quickwit**는 로그 검색에 특화된 엔진이다. 오브젝트 스토리지(S3, GCS) 위에서 직접 인덱스를 검색하기 때문에 "스토리지와 컴퓨트 분리"가 가능하고, 동일 로그 1TB 기준 Elasticsearch보다 10배 이상 저렴한 비용을 광고한다. 2024년에 Datadog이 인수했고, 일부 기능은 Datadog 내부 검색으로 흡수되고 있다.

**Tantivy**는 Rust로 짠 Lucene 유사 라이브러리다. 다른 엔진(Meilisearch, ParadeDB, Quickwit)이 Tantivy를 내부에 임베딩해 쓴다.

**Bleve**는 Go의 풀텍스트 검색 라이브러리다. CouchDB의 검색 엔진이 Bleve 기반이다.

**Whoosh**는 순수 파이썬 검색 라이브러리. 성능보다는 학습·작은 도구에 적합하다.

11장 · ParadeDB · pg_search — Postgres 안에서 끝내기

ParadeDB는 2023년 시작된, Postgres에 BM25 풀텍스트 검색을 붙이는 확장이다. 핵심은 `pg_search` extension이다.

-- pg_search 설치 후

CREATE EXTENSION pg_search;

-- BM25 인덱스

CREATE INDEX product_search_idx ON products

USING bm25 (id, title, description)

WITH (key_field='id');

-- 쿼리

SELECT id, title, paradedb.score(id) AS score

FROM products

WHERE title @@@ 'red shoes'

ORDER BY score DESC

LIMIT 10;

ParadeDB의 강점은 **한 데이터베이스 안에서 끝낸다**는 것이다.

- 별도 검색 엔진을 운영하지 않는다 — Postgres 한 대로 끝.

- ETL/CDC 파이프라인이 없다 — 트랜잭션 안에서 인덱스가 갱신된다.

- 권한·트랜잭션·JOIN을 그대로 활용한다.

`pgvector`와 조합하면 BM25 + 벡터 하이브리드까지 Postgres 한 대에서 처리한다. Postgres 데이터가 검색 후보의 90% 이상이라면 ParadeDB는 굉장히 강력한 선택이다.

12장 · Orama (구 Lyra) — TypeScript로 짠 임베디드 검색

Orama는 2022년 Lyra라는 이름으로 시작했다가 2023년에 리브랜드한 TypeScript 검색 엔진이다. 브라우저·엣지·서버 어디서든 돈다.

const db = create({

schema: {

title: 'string',

price: 'number',

embedding: 'vector[768]',

})

await insert(db, { title: 'Red shoes', price: 99.99, embedding: [...] })

const results = await search(db, {

term: 'shoes',

properties: ['title'],

limit: 5,

})

Orama의 특징은 다음과 같다.

- **풀-자바스크립트**: 의존성 없이 npm 한 줄.

- **임베디드**: 인덱스를 직렬화해 정적 호스팅에 같이 올리면 그대로 검색이 된다.

- **벡터 + BM25**: 둘 다 지원, 하이브리드도.

- **Cloudflare Workers·Bun·Node·Deno 모두 지원**.

작은 docs 사이트, JAMstack, 정적 e-커머스 카탈로그에서 굉장히 잘 맞는다. 인덱스가 수십만 단위로 커지면 메모리·로드 시간 문제로 한계에 부딪힌다.

| 라이브러리 | 사이즈 | 특징 |

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

| Orama | ~30KB | 풀-자바스크립트, 벡터까지 |

| MiniSearch | ~8KB | 가볍고 빠른 풀텍스트만 |

| Fuse.js | ~12KB | 퍼지 매칭 중심 |

| FlexSearch | ~10KB | 풀텍스트, 인덱스 콤팩트 |

| Lunr.js | ~28KB | 클래식, jQuery 시절부터 |

13장 · 검색 엔진의 형태 — 역인덱스·벡터·하이브리드

세 가지 핵심 형태를 짚자.

먼저 **역인덱스(Inverted Index) + BM25**.

documents:

doc1: "red shoes"

doc2: "blue shirt"

doc3: "red shirt"

inverted index:

"red" -> [doc1, doc3]

"shoes" -> [doc1]

"blue" -> [doc2]

"shirt" -> [doc2, doc3]

쿼리 "red shirt"는 `red`의 포스팅 리스트와 `shirt`의 포스팅 리스트를 교집합하고 `BM25(doc, query)` 점수로 정렬한다. 50년 가까이 검색의 표준이었다.

다음으로 **벡터 + ANN**.

임베딩 모델 → 768차원 벡터

HNSW 그래프에 인서트

쿼리도 임베딩 → ANN 검색 → 가까운 K개

의미 검색은 여기서 출발한다. "운동화"가 "스니커즈"와 매칭되는 건 벡터 공간에서의 거리 덕분이다.

마지막으로 **하이브리드(BM25 + 벡터 + RRF)**. 두 점수를 Reciprocal Rank Fusion으로 합친다. `RRF(k=60)`가 기본 공식. 2025년부터 거의 모든 엔진(OpenSearch, Vespa, Elastic, Meilisearch, Typesense, ParadeDB)이 기본 옵션으로 가진다.

14장 · 멀티 테넌시와 샤딩

대규모 검색 엔진은 결국 두 축으로 갈린다 — 샤딩과 복제.

**Elastic/OpenSearch**는 인덱스를 N개 샤드로 자르고, 각 샤드를 R개 복제한다. 데이터는 hot-warm-cold 티어로 옮긴다. 핫 노드는 SSD, 콜드 노드는 객체 스토리지에 가깝게 둔다.

**Vespa**는 콘텐츠 클러스터를 그룹과 분산자(distributor)로 묶고, 그 위에 컨테이너 클러스터가 쿼리를 디스패치한다.

**Meilisearch/Typesense**는 인덱스를 노드 단위로 갈라 멀티 테넌시를 구현한다. 테넌트 = 인덱스 = 필터 키. 작은 테넌트라면 한 인덱스에 multi-tenant key로 풀고, 큰 테넌트라면 분리.

**ParadeDB**는 Postgres의 파티셔닝과 RLS를 그대로 쓴다. 테넌트별 schema 또는 RLS policy로 격리.

15장 · 지오 검색·패싯·자동완성

검색 UI의 표준 기능 세 개를 짚자.

**지오 검색**. Elastic은 `geo_point` 매핑, Meilisearch는 `_geo` 필드, Typesense는 `geopoint`. 모두 "이 좌표에서 X km 안" 같은 필터를 지원한다. e-커머스의 매장 찾기, 배달 앱, 부동산이 다 이 위에 산다.

**패싯 검색**. 색상 / 사이즈 / 브랜드 같은 측면 필터다. Meilisearch는 `facets`, Typesense도 `facet_by`, Elastic은 `aggregations`. Algolia가 만들어 표준이 된 UI 패턴이다.

**자동완성·즉시 검색**. Meilisearch의 `instant-meilisearch`, Typesense의 `typesense-instantsearch-adapter`가 Algolia의 `instantsearch.js`를 그대로 받아 쓴다. 키스트로크마다 50ms 안에 응답하는 게 표준이다.

여기에 **동의어(Synonyms)**와 **불용어(Stop Words)**가 필드별로 설정된다. "TV" = "텔레비전" = "television"을 같은 토큰으로 매칭하고, "을·를·이·가" 같은 한국어 조사를 인덱스에서 빼는 식이다.

16장 · 한국어·일본어·중국어 토크나이저

영어는 공백으로 자르면 되지만, 한·중·일은 다르다.

**한국어**.

- **Mecab-ko**: MeCab 기반 형태소 분석기. Solr·Elastic 둘 다 지원.

- **Nori**: Elastic이 만든 한국어 분석기. 7.x부터 내장 플러그인.

- **Open Korean Text (OKT)**: 트위터 기반 한국어 분석기, 트위터 줄임말·신조어에 강함.

입력: "빨간 운동화를 샀다"

Nori 출력 토큰: [빨갛다(VA), 운동(NNG), 운동화(NNG), 사다(VV)]

조사·어미를 분리하고 명사·동사를 원형으로 복원하는 게 핵심이다.

**일본어**.

- **Kuromoji**: Solr/Lucene 진영의 표준. 비교적 가볍고 빠름.

- **Sudachi**: Works Applications가 만든 형태소 분석기. 어휘량이 더 많음.

- **MeCab**: 가장 오래된 일본어 형태소 분석기. C++.

入力: "赤い靴を買った"

Kuromoji出力: [赤い, 靴, を, 買っ, た]

**중국어**.

- **jieba**: 가장 널리 쓰이는 Python 중국어 분석기. Elastic·Solr 플러그인.

- **ICU**: 유니코드 표준 기반의 다국어 토크나이저. 정확도는 낮지만 다국어를 한 번에.

토크나이저를 잘못 고르면 검색 품질이 한순간에 무너진다. 한국어로 "신발"을 입력했는데 "신발들"이 매칭이 안 되거나, "텐트치다"가 "텐트 + 치다"로 잘리지 않는다. 한국어 검색을 한다면 토크나이저는 협상 불가의 1순위다.

17장 · 클러스터 사이징 — 샤드·복제·티어

대용량 검색 클러스터의 룰 오브 텀.

- **샤드 크기**: 30~50GB. 작으면 오버헤드, 크면 리밸런싱이 느려진다.

- **샤드 수**: 노드당 1~3개의 핫 샤드. 너무 많으면 JVM 힙이 터진다.

- **복제 수**: 2가 표준. 3은 PB급에서.

- **JVM 힙**: 노드 메모리의 50%, 최대 31GB. 그 이상은 GC가 망가진다.

- **디스크**: 노드당 핫은 SSD, 콜드는 HDD/S3.

Elastic·OpenSearch는 ILM(Index Lifecycle Management)으로 hot → warm → cold → delete를 자동화한다. 30일 핫, 60일 웜, 1년 콜드 같은 정책이 흔하다.

18장 · 2026년의 AI 검색

검색의 다음 페이지는 AI다.

**Algolia NeuralSearch**는 BM25와 벡터를 RRF로 합쳐 사용자의 의도에 가까운 결과를 낸다. 2023년 출시 이후 e-커머스에서 빠르게 자리를 잡았다.

**Vespa Hybrid**는 BM25, 벡터, ML 랭커를 한 쿼리 안에서 실행하는 가장 표현력 높은 방식이다.

**OpenSearch Neural Search**는 임베딩 파이프라인을 인제스트에 붙이고, 쿼리에서 RRF로 묶는다. 모델은 BYOM(Bring Your Own Model) 방식으로 ONNX/HuggingFace 모델을 넣는다.

**Meilisearch + Embedders**는 v1.13에서 정식이 됐다. OpenAI·Cohere·HuggingFace 임베더를 설정만 하면 자동으로 벡터 인덱싱이 된다.

**Typesense Conversational Search**는 RAG를 검색 엔진에 내장한 형태다. 사용자 질문 → 검색 → LLM 합성 응답을 한 API에서 한다.

19장 · RAG와 검색의 결합

검색은 RAG의 retrieval 단계 그 자체다.

[User Query]

[Embedder] -- 쿼리 임베딩

[Hybrid Search] -- BM25 + 벡터 + RRF

[Reranker] -- Cohere Rerank, bge-reranker 등

[Context Builder] -- 상위 K개 문서를 LLM에 주입

[LLM] -- Claude / GPT / Llama

[Answer]

RAG에 가장 친화적인 셀프 호스트 엔진은 셋이다.

- **ParadeDB**: Postgres + pg_search + pgvector. 한 DB 안에서 메타데이터·풀텍스트·벡터를 다 처리.

- **Meilisearch + Embedders**: 가장 빠른 설정, 하이브리드 빌트인.

- **Vespa**: 가장 표현력 높은 랭킹, 다단계 모델까지.

Elastic과 OpenSearch도 강력하지만, 운영 부담이 크다. 100K 문서 미만의 RAG는 Meilisearch나 ParadeDB로 충분하다.

20장 · 케이스 스터디 — 한국과 일본

**한국**.

- **NCsoft**: 게임 내 검색에 Elasticsearch를 오래 굴렸다. 2024년부터 GenAI 검색에 OpenSearch를 추가.

- **Coupang**: 카탈로그 검색이 Elasticsearch 기반. 한국어 토크나이저는 자체 개발한 모델.

- **Naver**: 자체 검색 엔진이 본진이지만, 외부 검색에는 Elastic을 같이 쓴다.

**일본**.

- **Mercari**: 출품 카탈로그 검색이 Elasticsearch 기반. Kuromoji 튜닝이 깊다.

- **LINE Yahoo**: Solr를 오래 굴렸고, 2024년부터 Vespa로 점진 이전.

- **Sansan**: 명함 데이터 검색이 Elasticsearch + 자체 토크나이저.

공통점은 두 가지다. 첫째, **대규모는 결국 Elastic/OpenSearch/Vespa**로 간다. 둘째, **언어별 토크나이저에 가장 많이 투자한다**. Nori·Kuromoji 기본형 위에 사전 보강, 신조어 처리, 도메인 명사 추가가 핵심이다.

21장 · 비용 매트릭스

일 1M 검색, 인덱스 50GB 기준으로 거칠게 추정.

| 옵션 | 월 비용 (USD) | 비고 |

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

| Algolia | 500~1500 | 트래픽 기반, 가장 비싸지만 운영 0 |

| Elastic Cloud | 300~800 | 클러스터 크기 따라 |

| AWS OpenSearch | 200~600 | r6g.large × 3 기준 |

| Meilisearch (셀프) | 50~150 | EC2 r6g.large × 1~2 |

| Typesense (셀프) | 80~200 | t3.xlarge × 3 클러스터 |

| ParadeDB (셀프) | 50~120 | RDS db.r6g.large 한 대 |

| Vespa (셀프) | 200~500 | 운영 복잡도 큰 만큼 |

| Manticore (셀프) | 50~100 | c6g.large × 1 |

이 표는 어디까지나 거친 추정이다. 트래픽 패턴(피크 vs 평균), 인덱싱 빈도, 백업·DR 요구사항에 따라 ×2~3까지 흔들린다.

22장 · 퍼포먼스 비교

공식 벤치마크나 독립 벤치마크에서 보고된 수치(2025년 기준).

- **Meilisearch**: 1M 문서, p99 50ms 이하 (싱글 노드).

- **Typesense**: 1M 문서, p99 30~50ms (3노드 클러스터).

- **Elasticsearch**: 10M 문서, p99 100~200ms (3노드, 샤드 튜닝 기준).

- **OpenSearch**: Elasticsearch와 유사, Neural Search 추가 시 +20ms.

- **Vespa**: 100M+ 문서에서도 p99 100ms 이하 (대규모 클러스터).

- **ParadeDB**: 1M 문서, p99 50~100ms (Postgres 단일 인스턴스).

- **Manticore**: 1M 문서, p99 30~80ms.

성능 자체로 보면 차이가 크지 않다. 차이는 **튜닝 노력**과 **인덱스 사이즈가 커질 때의 스케일링**에서 벌어진다. 1M 문서까지는 어느 엔진을 골라도 빠르다. 100M부터는 Elastic/OpenSearch/Vespa의 분산 경험이 압도적이다.

23장 · 유스케이스별 선택 가이드

| 시나리오 | 1순위 | 2순위 | 비고 |

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

24장 · 마이그레이션 패턴

세 가지 흔한 경로.

**Algolia → Typesense**. API 호환성 덕에 가장 매끄럽다. instantsearch.js를 그대로 유지하고 어댑터만 갈아끼우면 된다. 비용이 1/10로 줄어드는 게 보통.

**Elastic → OpenSearch**. ALv2 라이선스만 보고 옮기는 경우. 7.10까지는 API 동일, 그 이후로는 점점 갈라진다. 7.x에서 옮기는 게 가장 쉽고, 8.x → OpenSearch 2.x는 마이그레이션 도구가 필요하다.

**Elastic → Vespa**. 랭킹 모델이나 텐서 연산이 핵심이라면. 스키마·쿼리 DSL이 완전히 다르므로 사실상 재구축에 가깝다.

마이그레이션할 때 가장 중요한 건 **인덱싱 파이프라인의 재현성**이다. 검색 품질을 평가할 표준 쿼리셋(NDCG, MRR)을 미리 만들어두고, 새 엔진에서 같은 쿼리셋의 점수를 측정해야 회귀 없이 옮길 수 있다.

25장 · 운영 베스트 프랙티스

마지막으로 운영 측면 짚고 마무리.

- **인덱싱은 비동기로**. 카프카·Redpanda·SQS를 앞에 두고 검색 엔진은 컨슈머로. 인덱스 장애가 본업에 안 번지게.

- **인덱싱·검색 노드 분리**. 작은 클러스터라도 인덱싱 부하와 검색 부하는 다른 자원을 쓴다.

- **검색 품질 평가**. 클릭률, 0-결과율, 평균 깊이를 분기마다 측정. NDCG@10 / MRR을 도메인 쿼리셋으로.

- **인덱스 버전 관리**. blue/green 인덱스로 무중단 재인덱싱. alias로 스위치.

- **백업**. 인덱스 스냅샷 + 원본 데이터 양쪽 다. 인덱스만 백업하면 스키마 변경 때 못 살린다.

- **모니터링**. 쿼리 지연(p50/p99), 인덱싱 큐 길이, 디스크 사용량, JVM 힙(있다면). 검색 0결과 비율도 비즈니스 KPI다.

검색 엔진은 한번 박히면 잘 안 바뀐다. 처음에 토크나이저, 라이선스, 분산 모델을 잘 고르는 게 5년치 노력을 아낀다.

26장 · 에필로그 — 검색은 다시 흥미로워졌다

2010년대의 검색은 "Algolia 쓰면 끝"이었다. 2020년대 초의 검색은 "Elastic 클러스터 운영기"였다. 2026년의 검색은 셋 중 어느 쪽도 아니다.

작은 팀은 Meilisearch나 ParadeDB로 일주일 안에 검색을 띄운다. 중간 팀은 Typesense나 OpenSearch로 클러스터를 굴린다. 큰 팀은 Vespa나 Elastic 위에 ML 랭커를 얹는다. AI/RAG 팀은 검색 엔진 위에 임베더와 리랭커를 합쳐 한 파이프라인으로 묶는다.

핵심은 **선택지가 풍부해졌다**는 것이다. SaaS만이 답이던 시대는 끝났고, OSS만이 답이던 시대도 끝났다. 도메인·트래픽·언어·예산이라는 네 변수에 맞춰 도구를 고르는 것 — 그게 2026년의 검색 엔지니어링이다.

참고 자료

- [Meilisearch Documentation](https://www.meilisearch.com/docs)

- [Typesense Documentation](https://typesense.org/docs/)

- [Manticore Search Documentation](https://manual.manticoresearch.com/)

- [OpenSearch Documentation](https://opensearch.org/docs/latest/)

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

- [Apache Solr Reference Guide](https://solr.apache.org/guide/solr/latest/)

- [Vespa.ai Documentation](https://docs.vespa.ai/)

- [Quickwit Documentation](https://quickwit.io/docs/)

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

- [ParadeDB pg_search](https://docs.paradedb.com/documentation/full-text/overview)

- [Orama Documentation](https://docs.orama.com/)

- [Algolia NeuralSearch](https://www.algolia.com/products/ai-search/)

- [Elastic License 2.0 Changes](https://www.elastic.co/pricing/faq/licensing)

- [OpenSearch Neural Search](https://opensearch.org/docs/latest/search-plugins/neural-search/)

- [Nori Korean Analyzer](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-nori.html)

- [Kuromoji Japanese Analyzer](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-kuromoji.html)

- [BM25 Wikipedia](https://en.wikipedia.org/wiki/Okapi_BM25)

- [HNSW Paper (Malkov 2016)](https://arxiv.org/abs/1603.09320)

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

- [Vespa Ranking Documentation](https://docs.vespa.ai/en/ranking.html)

- [Open Korean Text](https://github.com/open-korean-text/open-korean-text)

- [Sudachi Japanese Tokenizer](https://github.com/WorksApplications/Sudachi)