오픈소스 검색엔진 비교: OpenSearch vs Meilisearch vs Typesense

1️⃣ 들어가며

검색 기능은 단순히 문자열을 찾는 기능을 넘어, 언어 구조를 이해하고 유사한 의미까지 탐색하는 기술로 진화하고 있다.

특히 한국어는 띄어쓰기 규칙이 불규칙하고 복합명사가 많아, 검색엔진 선택이 검색 품질에 직접적인 영향을 준다.

이번 글에서는 대표적인 오픈소스 검색엔진인

OpenSearch, Meilisearch, Typesense를 비교하며,

한국어 처리력·띄어쓰기 오류 대응·개발 난이도 측면에서 분석한다.

---

2️⃣ 엔진별 개요

 

항목	OpenSearch	Meilisearch
기반 구조	Lucene 기반 (Elasticsearch fork)	Rust 기반	C++ 기반
주요 특징	대규모 데이터, 고급 쿼리, 형태소 분석	설치 간단, 빠른 인덱싱	실시간 검색, 자동완성 최적화
형태소 분석	✅ Nori Analyzer 내장	❌ 없음	❌ 없음
오타 허용 (Fuzzy Search)	✅ 설정 가능	✅ 기본 내장	✅ 기본 내장
Prefix 검색	⚙️ edge_ngram 설정 필요	✅ 기본 내장	✅ 기본 내장

---

3️⃣ 한국어 검색 품질의 핵심 — 형태소 분석

한국어 검색의 품질을 결정짓는 요소는 형태소 분석(Morphological Analysis) 이다.

형태소 분석은 문장을 의미 단위로 분리하는 과정으로, 예를 들어 다음과 같다.

 

검색어 형태소	분석 결과
“스마트워치리뷰”	스마트, 워치, 리뷰
“워치스트랩”	워치, 스트랩
“헬스기능테스트”	헬스, 기능, 테스트

형태소 분석이 없으면 "워치"로 검색해도 "스마트워치리뷰" 문서를 찾지 못한다.

이 문제를 자동으로 해결하는 것이 OpenSearch의 Nori 분석기다.

---

4️⃣ 띄어쓰기·붙여쓰기 오류 대응 비교

항목	OpenSearch (Nori)	Meilisearch	Typesense
붙여쓰기 대응	✅ 자동 (형태소 분석으로 분리)	⚙️ n-gram 전처리 필요	⚙️ n-gram 전처리 필요
띄어쓰기 오류 대응	✅ 자동 (형태소 단위 인식)	⚙️ 공백 제거 전처리 필요	⚙️ 공백 제거 전처리 필요
복합명사 대응	✅ 완전 지원	⚠️ 직접 분리 필요	⚠️ 직접 분리 필요
n-gram 필요성	❌ 불필요	✅ 필수	✅ 필수

🔹 OpenSearch는 언어 수준에서 오류를 인식하고 보정

🔹 Meilisearch / Typesense는 전처리를 통해 비슷한 효과를 “만드는” 수준

---

5️⃣ 영어는 왜 문제 없을까?

영어는 공백 단위로 명확히 단어가 구분되며,

Meilisearch·Typesense 모두 prefix 검색과 오타(fuzzy) 매칭을 기본적으로 지원한다.

예를 들어 "smartwatch"라는 단어가 인덱싱되어 있을 때

사용자가 "smart" 또는 "smrtwatch"(오타)로 검색해도 자동으로 매칭된다.

즉, 영어는 n-gram 전처리가 불필요하지만

한국어는 공백으로 단어 경계가 구분되지 않기 때문에 전처리가 필요하다.

---

6️⃣ 구현 예시 비교

✅ OpenSearch (자동 처리)

{
  "settings": {
    "analysis": {
      "analyzer": {
        "korean_custom": {
          "tokenizer": "nori_tokenizer",
          "filter": ["nori_part_of_speech", "lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "korean_custom" }
    }
  }
}

→ "스마트워치리뷰"가 저장돼 있어도 "워치"로 검색 시 자동 매칭 ✅

---

⚙️ Meilisearch (전처리 필요)

def make_ngrams(text, n=2):
    return [text[i:i+n] for i in range(len(text)-n+1)]

doc = {
  "title": "스마트워치리뷰",
  "title_ngrams": make_ngrams("스마트워치리뷰", 2)
}
# searchableAttributes = ["title", "title_ngrams"]

→ "워치"로 검색 시 "트워", "워치" n-gram이 일치해 매칭 ✅

단, 모든 문서에 n-gram을 생성해 인덱싱해야 함.

---

7️⃣ 종합 비교표

기준	OpenSearch	Meilisearch	Typesense
한국어 형태소 분석	🟩 있음 (Nori)	🟥 없음	🟥 없음
띄어쓰기/붙여쓰기 대응	🟩 자동	🟨 전처리 필요	🟨 전처리 필요
오타 허용	🟩 설정 가능	🟩 기본 내장	🟩 기본 내장
인덱싱 속도	🟨 보통	🟩 매우 빠름	🟩 빠름
운영 난이도	🟥 높음 (클러스터 기반)	🟩 낮음	🟩 낮음
검색 정확도	🟩 매우 높음	🟨 중간	🟨 중간
추천 용도	대규모 한글 서비스	중소규모 영어 서비스	실시간 검색, 자동완성

---

8️⃣ 결론 — 실무 기준 선택 가이드

 

상황	추천
한국어 복합명사, 띄어쓰기 오류, 검색 품질 중요	🔸 OpenSearch + Nori Analyzer
영어 중심 서비스 / 빠른 구축이 목표	🔹 Meilisearch
자동완성 중심의 실시간 검색	🔹 Typesense
내부 관리용 간단한 검색	🔹 PostgreSQL FTS + pg_trgm

---

✏️ 마무리

형태소 분석이 없는 검색엔진은 “의미”를 이해하지 못한다.

한국어처럼 복합명사와 띄어쓰기 오류가 많은 언어는

사실상 OpenSearch + Nori 조합이 유일한 실무 해답이다.