메일리서치 무료

-

Meilisearch는 Rust를 기반으로 하는 오픈 소스 입니다. 매우 빠른 검색 응답과 뛰어난 개발자 경험으로 유명합니다. 즉각적인 검색, 철자 허용 오차 및 의미 검색을 지원합니다.

메일리서치 제품 인터페이스

메일리서치 AI: 오픈소스 검색엔진의 AI 검색 기능 해체

핵심 매개변수 및 통계

매개변수 가치
제품 포지셔닝 초고속 응답성과 AI 의미 검색을 핵심 경쟁력으로 삼는 개발자를 위한 오픈소스 검색 엔진
핵심 형태 검색 API + Docker 이미지 + 관리형 클라우드 서비스
대상 사용자 웹/모바일 개발자, SaaS 제품 팀, 데이터 집약적 애플리케이션
핵심 기술 스택 Rust 네이티브 엔진, 역색인, 벡터 임베딩 검색, 철자 허용 오차, 연합 검색
라이센스 계약 MIT(핵심 엔진은 완전 오픈 소스임)
배포 방법 Docker 자체 호스팅/Meilisearch Cloud(AWS 유럽/미국 지역)
프로그래밍 언어 Rust(핵심 엔진)
모회사 Meilisearch SAS(프랑스 파리)
GitHub 스타 약 50,000+
Docker 풀 볼륨 1억 회 이상(Docker Hub 공개 데이터 기준)

Meilisearch는 오픈 소스 검색 시장에서 Typesense와 듀오를 구성했습니다. 둘 다 "Elasticsearch 대안"으로 포지셔닝되지만 기술 경로와 실행 전략에는 상당한 차이가 있습니다. Meilisearch의 차별화된 장점은 다음 세 가지 수준에 반영됩니다. Rust 코어 엔진 - Elasticsearch의 Java 스택 및 Typesense의 C++ 코어와 비교하여 Rust는 메모리 안전성 및 동시성 성능에서 고유한 이점을 갖고 있으며 동일한 하드웨어에서 처리량은 2~5배 더 높습니다. MIT 라이센스 - Typesense의 GPL 라이센스보다 완화되어 기업 통합 시 카피레프트 전염을 걱정할 필요가 없습니다. 이것이 바로 많은 상업 회사들이 Typesense 대신 Meilisearch를 선택하는 이유입니다. 법적 동기; 내장 의미 검색 - 벡터 검색은 버전 v1.0에서 지원되며 Typesense는 이후 버전까지 이 기능을 추가하지 않았습니다. Meilisearch는 아키텍처 철학에서 기본 구성이 뛰어난 경험을 제공할 수 있는 반면, Elasticsearch는 프로덕션 수준 성능을 달성하기 위해 많은 조정이 필요한 "즉시 사용 가능한 성능"을 추구합니다.

사용자 및 시장 인지도

Meilisearch의 시장 침투는 Elasticsearch의 대규모 공장 주도 생태계를 보완하는 "커뮤니티 중심 + 기업 롱테일 채택"의 2륜 구동 패턴을 제시합니다.

커뮤니티 생태학: GitHub에는 약 50,000명 이상의 스타와 800명 이상의 기여자가 활발한 개발자 커뮤니티를 구성하고 있습니다. 공식 Discord 채널에서 매일 활발한 토론은 성능 조정, 중국어 단어 분할 및 클라우드 서비스 경험에 중점을 두고 있습니다. 커뮤니티에서 제공하는 플러그인 및 통합은 Laravel, Rails, Django 및 Symfony와 같은 주류 웹 프레임워크는 물론 Nuxt 및 Next.js와 같은 프런트엔드 메타 프레임워크를 포괄합니다. 이 "프레임워크 기본 통합" 전략은 개발자의 시행착오 비용을 줄여줍니다. 문서를 읽는 것부터 검색을 실행하는 데까지 단 10분밖에 걸리지 않습니다.

기업 채택: 공개적으로 이용 가능한 채택 사례에는 전자상거래(패션 소매업체, 중고 거래 플랫폼), SaaS(프로젝트 관리 도구, 고객 지원 시스템), 콘텐츠 플랫폼(뉴스 웹사이트, 문서 센터) 및 기타 분야가 포함됩니다. 프랑스 최고의 전자상거래 플랫폼과 유럽의 여러 SaaS 회사는 Meilisearch를 현장 검색의 핵심 엔진으로 채택했습니다. 그러나 Algolia와 Elastic Cloud가 장악하고 있는 미국 시장과 비교하면 북미 지역에서 Meilisearch의 브랜드 인지도는 여전히 개선의 여지가 있습니다. 현재 사용자 기반은 주로 유럽 및 아시아 태평양 개발자입니다.

업계 벤치마킹: 오픈소스 검색 엔진의 '개발자 경험' 측면(JetBrains 개발자 생태계 설문조사 참조)에서 Meilisearch는 '사용 용이성'과 '문서 품질'이라는 두 가지 지표에서 Elasticsearch를 계속 앞서고 있지만, '엔터프라이즈 수준의 기능적 완성도'와 '클러스터 규모 확장'에는 여전히 격차가 있습니다. 제3자 성능 비교 테스트(예: 오픈 소스 커뮤니티 벤치마크)는 단일 노드 1,000만 개의 문서 시나리오에서 Meilisearch의 중앙 검색 대기 시간이 Elasticsearch의 약 1/3-1/5인 것으로 나타났습니다. 그러나 기본 구성에서는 데이터 가져오기 처리량이 낮으며 동등한 수준에 도달하려면 쓰기 버퍼를 조정해야 합니다.

기술 매체 평가: InfoWorld는 평가에서 Meilisearch를 "Elasticsearch에 대한 가장 강력한 오픈 소스 대안"이라고 평가했으며 PCMag는 "개발자 시작 속도"라는 장점을 강조했습니다. 중국 기술 커뮤니티(예: Nuggets V2EX)에서 Meilisearch에 대한 토론은 Typesense와의 선택 비교에 중점을 둡니다. API 디자인의 단순성은 일반적으로 인식되지만 중국어 단어 분할의 세분성 문제도 자주 언급됩니다. "인공지능"과 같은 표준 용어의 단어 분할은 잘 수행되지만 "나노 코팅 방수"와 같은 복합 기술 용어를 접할 경우 단어 분할 결과는 "나노 코팅"을 "나노"와 "코팅"이라는 두 개의 독립적인 단어로 잘라내어 정밀 검색의 회상률에 영향을 미칠 수 있습니다.

비용 이점

메일리서치의 비용 구조는 "소프트웨어 라이센스 비용 + 인프라 비용 + 운영 및 유지 관리 인력"의 세 가지 계층으로 분할되어야 합니다. 선호도에 따라 총 소유 비용(TCO)은 10배 이상 달라질 수 있습니다.

C 측/오픈 소스 자체 호스팅 - 소프트웨어 비용이 들지 않으며 인프라는 직접 부담합니다:

  • MIT 라이선스는 라이선스 비용이 없으며, 비공개 소스 상용 소프트웨어를 포함한 상용 프로젝트에 무료로 사용할 수 있음을 의미합니다.
  • 자체 호스팅을 위한 최소 하드웨어 임계값이 낮습니다. 중소 규모 인덱스(문서 100만 개 이내)를 실행하려면 2GB 메모리 + 1 코어 CPU가 권장됩니다. 낮은 구성의 클라우드 서버 인스턴스(예: 4GB RAM, 2코어 50GB SSD, 약 200엔/월)는 추가 소프트웨어 비용 없이 소규모 전자 상거래 사이트 검색을 호스팅할 수 있습니다.
  • 하지만 참고하세요: 내장된 마스터-슬레이브 복제에는 추가 노드가 필요하고, 고가용성 배포에는 최소 3노드 클러스터가 필요하며, 인프라 비용은 선형적으로 증가합니다.

API/개발자 - 클라우드 호스팅 종량제, 운영 및 유지 관리 부담 없음:

  • Meilisearch Cloud는 월 약 100,000건의 검색을 무료로 제공하며 이후에는 사양 및 사용량에 따라 요금이 청구됩니다.
  • 시작 노드 비용은 월 약 $50-100(검색 100만 건 + 인덱스 스토리지 1GB 포함)이며, 하루 평균 검색 횟수가 수천 건인 중소 규모 프로젝트에 적합합니다.
  • AWS OpenSearch Serverless보다 가격 투명성과 입찰 유연성이 떨어지지만 구성이 필요 없어 더 좋습니다. 관리할 클러스터가 없고, 조정할 샤딩이 없으며, 즉시 사용 가능한 프로덕션 등급 검색 품질입니다.
  • 고주파 API 호출 시나리오에서 셀프 호스팅의 TCO를 비교하는 것이 좋습니다. 50GB 인덱스에 대해 월 평균 500만 건의 검색을 예로 들면, 클라우드 호스팅의 연간 요금은 약 $3,000~6,000이며, 셀프 호스팅에는 약 500~800엔(연간 6,000~9,600엔) 정도의 4코어 16GB 인스턴스가 필요합니다.+ 운영 및 유지 관리 측면에서 인력, 같은 규모에서는 둘 사이에 큰 차이가 없습니다. 그러나 자체 호스팅에는 운영 및 유지 관리가 더 많아지고 나면 운영 및 유지 관리가 필요하지 않다는 것이 클라우드 호스팅의 숨겨진 장점입니다.

기업/민영화 – 독점 클러스터, 비즈니스 협상 필요:

  • Starlite(월 3,000~6,000엔 시작 버전, 검색 약 100,000회)부터 Enterprise 수준까지 무제한 검색을 지원합니다. 가격은 공식 웹사이트를 통해 판매처에 문의하여 확인해야 합니다.
  • SSO 통합, 감사 로그, 사용자 지정 SLA 및 전용 노드 격리는 규정 준수 요구 사항이 높은 시나리오(재무, 정부 업무)의 진입점입니다.
  • 셀프 호스팅에 비해 엔터프라이즈 버전의 핵심 프리미엄은 "무료 운영 및 유지 관리"와 "SLA 보장"입니다. - 셀프 호스팅에서는 노드가 다운되어 검색이 불가능할 경우 팀이 자체적으로 처리해야 합니다. 클라우드 호스팅 버전에서는 Meilisearch가 인프라 안정성을 담당합니다.

경쟁 제품 가격 비교:

비용 차원 Meilisearch 자체 호스팅 메일리서치 클라우드 타입센스 클라우드 알골리아 탄력적 클라우드
소프트웨어 라이센스 무료(MIT) 무료(무료 할당량 이후 사용량 기준) 무료(GPL) 용도별 용도별
시작 비용 서버 월 200엔부터 시작 $50-100/월 $75-150/월 $100-300/월 월 $95부터 시작
연간 1,000만 검색 결제 서버 3,000~6,000엔 $3,000-6,000 ~$4,500 ~$12,000 ~$10,000
운영 및 유지보수팀 비용 주당 0.2-0.5 인력 필요 0 0 0 0.1-0.3 일/주
상업용 라이센스 위험 없음(MIT) 없음 GPL 전염 위험 공급업체 종속 공급업체 종속

주요 결론: 완전한 기술 팀(Docker와 기본 운영 및 유지 관리 가능)이 있는 중간 규모 프로젝트의 경우 셀프 호스팅이 최적의 비용 솔루션입니다(동일한 규모의 SaaS 서비스의 약 1/3-1/2). 팀 규모가 10명인 팀의 경우 핵심 비즈니스에 집중하려는 신생 기업의 경우 클라우드 호스팅의 "운영 및 유지 관리가 필요 없는" 프리미엄은 그만한 가치가 있습니다. 데이터 규정 준수에 민감한 금융 및 정부 프로젝트의 경우 엔터프라이즈 프라이빗 클라우드가 유일한 옵션이지만 가격 협상의 여지가 많다는 점에 유의해야 합니다. 결정을 내리기 전에 셀프 호스팅의 장기 TCO를 완전히 비교하는 것이 좋습니다.

주요 기능

Meilisearch의 기능 설계는 "검색 경험의 즉시성 + 결과의 관련성 + 통합의 편의성"이라는 세 가지 기능 라인을 중심으로 이루어집니다. 검색 알고리즘 라이브러리는 제공하지 않지만 기본 검색 인프라 계층은 제공합니다.

  • 입력 시 검색: 사용자가 문자를 입력할 때마다 쿼리가 실행되고 시스템은 50ms 이내에 결과를 반환합니다. 이 경험의 실현은 두 가지 최적화 계층에 달려 있습니다. 프런트 엔드는 디바운스를 사용하여 요청 빈도를 제어하고, 백엔드는 접두사 인덱스 구조(Prefix Index)를 사용하여 3자만 입력해도 후보 문서를 빠르게 찾을 수 있도록 합니다. 전자상거래 검색과 같이 빈도가 높은 상호작용 시나리오의 경우 실시간 검색을 통해 제품 노출이 20~30%까지 직접적으로 증가할 수 있습니다. 실시간으로 완성된 제품 목록을 보는 사용자는 전체 키워드를 직접 입력하는 것보다 클릭을 유발할 가능성이 더 높습니다.

  • 철자 허용 오차 및 대략적인 일치(오타 허용 오차): 철자 오류를 자동으로 수정합니다. 기본 허용 오차는 단어당 1문자 오류입니다(구성 가능). 구현 메커니즘은 편집 거리(Levenshtein Distance) 알고리즘으로, 이는 영어를 지원할 뿐만 아니라 중국어 병음 입력 오류에 대한 특정 내결함성을 갖추고 있습니다. 예를 들어, "aluminum"을 검색하면 "aluminum"과 일치할 수 있으며 "iPhone"과 "iPhone"도 동일한 결과를 반환할 수 있습니다. 실제 시나리오에서는 전자상거래 검색어의 약 10~15%에 맞춤법 오류가 포함되어 있습니다. Typo Tolerance는 "결과가 하나도 없음"에 대한 불만을 직접적으로 줄이고 검색 전환율에 정량적으로 긍정적인 영향을 미칩니다.

  • 의미 검색(벡터 임베딩): 텍스트를 고차원 벡터로 변환하고 코사인 유사성을 통해 의미 매칭을 수행하는 벡터 임베딩 지원이 내장되어 있습니다. 전통적인 BM25 키워드 일치와 비교하여 의미론적 검색은 "노트북" 및 "노트북 컴퓨터"와 같은 다양한 표현 간의 의미론적 동등성을 이해합니다. Meilisearch는 추가 벡터 데이터베이스를 배포할 필요 없이 Hugging Face 모델 또는 자체 훈련된 임베딩 모델을 통해 벡터 생성을 지원합니다. 이 기능의 실질적인 가치는 사용자가 관련 콘텐츠를 찾기 위해 문서에 사용된 정확한 단어를 알 필요가 없다는 점이며, 이는 특히 지식 기반 검색 및 커뮤니티 콘텐츠 플랫폼에 적합합니다.

  • 통합 검색: API 요청은 여러 개의 독립 인덱스에 걸쳐 있으며 공동으로 정렬된 결과를 반환합니다. 프로젝트 관리 SaaS에 전역 검색이 필요하다고 가정합니다. 단일 요청으로 프로젝트, 작업, 댓글, 첨부 파일, 사람의 5개 인덱스를 동시에 쿼리하고 전역 관련성 순으로 반환할 수 있습니다. 이는 프런트 엔드에서 여러 요청에 대한 대기 시간을 줄일 뿐만 아니라 통합된 정렬 전략을 통해 "서로 다른 데이터 유형의 혼합 결과"라는 인식 문제를 방지합니다.

  • 다국어 단어 분할 및 정렬 규칙: 다중 언어 단어 분할(중국어, 일본어, 한국어, 아랍어 등 포함)이 내장되어 있으며 추가 플러그인이나 구성이 필요하지 않습니다. 중국어 단어 분할은 MMSEG 알고리즘을 기반으로 하며 일상 표현과 일반적인 전문 용어에 대해 좋은 단어 분할 효과를 나타냅니다. 정렬 규칙은 체인 조합을 지원합니다. "관련성 > 가격 오름차순 > 마지막 업데이트 시간 > 사용자 정의 등급"으로 정렬하여 전자 상거래 검색 "가장 관련성 + 가장 비용 효율적인 + 선반에 있는 최신"과 유사한 복합 정렬 경험을 얻을 수 있습니다.

  • 필터링 및 패싯 검색: 검색 결과의 구조화된 다차원 필터링을 지원합니다. 전자 상거래 시나리오에서 브랜드, 가격 범위, 색상, 크기 등과 같은 속성을 기반으로 하는 점진적 필터링입니다. 패싯 검색은 필터링 프로세스 중에 실시간으로 각 차원에 대해 남은 결과 수를 반환하므로 사용자가 "빨간색으로 필터링하면 몇 개의 옵션이 남나요?"를 이해하는 데 도움이 됩니다.

  • 인덱스 실시간 업데이트: 인덱스를 재구축하지 않고도 몇 초 안에 문서 추가, 삭제, 수정(CRUD)이 적용되도록 지원합니다. 이는 재고가 자주 변경되는 전자 상거래 시나리오에 매우 중요합니다. 제품이 진열대에서 제거되거나 가격이 변경된 후 예약된 인덱스 재구축 중에 만료된 정보를 표시하는 대신 검색에 몇 초 내에 최신 상태가 반영되어야 합니다.

모델 및 버전의 진화

Meilisearch의 버전 반복은 "안정적인 커널 + 점진적인 향상" 전략을 따릅니다. 큰 버전 번호 점프를 추구하지 않고, 각 작은 버전 증가를 통해 검색 기능을 향상시킵니다.

v0.x 시리즈: 개념 증명 및 커뮤니티 발견(2018-2022)

  • v0.1 - v0.10: 초기 프로토타이핑 단계. 프랑스 파리에 핵심 팀이 설립된 후 먼저 MVP를 사용하여 "Rust 검색 + 즉각적인 피드백"이라는 제품 가설을 검증했습니다. API 디자인은 초기 Elasticsearch REST 스타일을 모방하는 것에서 자체적인 간결한 스타일로 점차 수렴되었습니다.
  • v0.28 (2022): "생산 가능" 합의에 도달한 첫 번째 버전입니다. API 키 인증 메커니즘과 다중 인스턴스 복제의 도입으로 커뮤니티는 이를 프로덕션 환경에 사용하는 것을 진지하게 고려할 수 있었습니다.
  • v0.30 (2022): 중국어 단어 분할 지원 및 정렬 규칙 사용자 정의를 추가합니다. 이 버전은 중국 커뮤니티가 Meilisearch를 대규모로 발견할 수 있는 출발점이었고, 국내 기술 기사와 커뮤니티 토론이 크게 늘어났습니다.

v1.0 시리즈: 프로덕션급 안정성 및 의미 검색(2023~2024)

  • v1.0 (2023-02): 베타에 대한 공식적인 작별 및 생산 준비가 선언되었습니다. API는 안정적인 단계에 진입했으며 이전 버전과의 호환성을 위해 최선을 다하고 있습니다. 동시에 Meilisearch Cloud 클라우드 서비스 공개 베타가 출시되었습니다.
  • v1.1 - v1.3: 인덱스 성능 및 데이터 가져오기 처리량을 최적화합니다. 가동 중지 시간 없이 전체 데이터 업데이트를 가능하게 하는 문서 교체 메커니즘을 도입합니다.
  • v1.4 - v1.6: 검색 성능 최적화 및 쿼리 언어 향상. v1.4에는 지리적 검색(지리적 범위 검색)이 도입되었으며 v1.6에는 다중 색인 검색을 위한 기본 기능이 추가되었습니다.
  • v1.7 - v1.9: 벡터 스토리지 온라인 및 임베디드 검색 테스트. v1.7에서는 실험적으로 벡터 검색을 지원하고 v1.8에서는 공식적으로 지원하며 v1.9에서는 벡터 인덱스 압축률을 최적화하여 동일한 메모리에서 벡터 용량을 약 40% 늘립니다.

v1.10+ 시리즈: AI 심층 통합 및 통합 검색(2025-2026)

  • v1.10(2025): 의미 검색 공식 버전(실험 버전 대체)을 구현하고 연합 검색 기능을 도입합니다. 벡터 검색 성능은 BM25 키워드 일치와 벡터 의미 검색 결과의 가중치 융합인 하이브리드 검색을 지원하도록 더욱 최적화되었습니다.
  • v1.11(~2025): 다국어 단어 분할 정확도를 향상하고 아랍어, 한국어 및 기타 작은 언어의 단어 분할 품질을 최적화합니다. 통합 검색에는 페이징 및 정렬 일관성에 대한 지원이 추가되었습니다.
  • v1.12(~2026): 인스턴트 검색 경험을 계속 반복하고, 클라우드 서비스의 자동 확장 및 축소 메커니즘을 최적화하고, 다국어 혼합 텍스트에 대한 의미 검색 성능을 개선합니다. v1.13은 Meilisearch를 "검색 도구"에서 "AI 지식 검색 파이프라인"의 필수 부분으로 확장하는 RAG(검색 증강 생성)의 기본 통합을 도입할 것으로 예상됩니다.

버전 리듬 설명: Meilisearch에는 고정된 출시 일정이 없으며, 버전 출시 리듬은 커뮤니티 기여와 비즈니스 요구에 따라 결정됩니다. 클라우드 플랫폼 버전 업데이트는 추가 안정성 검증을 완료하기 위해 일반적으로 오픈소스 버전보다 2~4주 정도 지연됩니다. 오픈 소스 커뮤니티 버전과 클라우드 플랫폼 간의 기능 정렬은 v1.12에서 최고 수준에 도달했으며 클라우드 플랫폼에는 더 이상 장기적인 기능 지연이 없습니다.

기술적인 장점

메일리서치의 기술적인 장점은 단순히 '이런 알고리즘에 대한 지원'을 쌓는 것이 아니라 Rust의 기본 동시성 모델과 인덱스 구조 혁신을 통해 다른 검색 엔진과 다른 '검색 응답 속도'와 '리소스 효율성' 간의 균형을 찾는 것입니다.

Rust 코어 엔진의 성능 이점: 검색 엔진의 기본 작업(단어 분할, 역검색, 등급 계산)은 본질적으로 CPU 및 I/O 집약적인 작업입니다. Rust의 무료 추상화 및 소유권 모델을 통해 Meilisearch는 이러한 작업을 손으로 작성한 C에 가까운 성능으로 컴파일하는 동시에 C/C++의 포인터 오버플로 및 버퍼 오버플로와 같은 안전 문제를 피할 수 있습니다. 검색 시나리오와 관련하여 Rust의 소유권 시스템은 인덱스 로딩 단계에서 데이터 구조의 메모리 레이아웃 최적화가 완료되도록 허용하므로 검색 중에 GC 일시 중지가 거의 없습니다. 이는 Elasticsearch의 Java 기반 JVM GC 튜닝과 질적으로 다릅니다. 후자의 GC 일시 중지는 힙 메모리가 32GB를 초과하면 두 번째 수준에 도달할 수 있으며 이는 검색 대기 시간의 P99 테일 지연에 직접적인 영향을 미칩니다.

접두사 색인 및 즉시 검색의 엔지니어링 매핑: Meilisearch는 "입력 중 검색"이라는 쿼리 모드를 특별히 최적화하기 위해 반전된 색인 위에 접두사 색인(접두사 색인) 레이어를 구축합니다. 이 인덱스 구조는 사용자가 입력한 각 접두사 조각을 해당 문서 ID 세트에 매핑하여 2~3자의 낮은 정보 상태에서도 결과를 신속하게 반환할 수 있도록 합니다. 실시간 검색 시나리오에서 Completion Suggester 또는 Edge Ngram 토크나이저의 조합을 사용하는 Elasticsearch와 비교할 때 Meilisearch의 접두사 인덱스는 기본적으로 내장되어 있으며 구성 비용은 거의 0입니다. 사용자는 뛰어난 실시간 검색 경험을 얻기 위해 "ngram이 무엇인지"를 이해할 필요가 없습니다.

하이브리드 검색 메커니즘: v1.10에 도입된 하이브리드 검색은 기존 BM25 키워드 일치 및 벡터 의미 검색 결과를 가중치 융합과 결합합니다. 핵심 논리는 다음과 같습니다. 사용자가 입력한 키워드가 문서에서 명확한 용어 일치에 도달하면 BM25가 더 많은 가중치를 부여합니다. 사용자가 설명적이고 모호한 언어를 입력하면 벡터 검색의 의미론적 일치가 더 많은 가중치를 부여합니다. 융합 가중치에는 자동(쿼리 특성에 따라 시스템에 의해 동적으로 조정됨)과 수동(개발자가 API 매개변수를 통해 BM25와 벡터의 가중치 비율을 지정함)의 두 가지 모드가 있습니다. 실제 테스트에서 하이브리드 검색은 고주파 쿼리의 정확성을 유지하면서 순수 BM25에 비해 롱테일 쿼리의 재현율을 약 15~30% 향상시킬 수 있습니다.

리소스 효율성 및 하드웨어 임계값: 1,000만 개의 문서와 50개의 필드로 구성된 일반적인 전자상거래 인덱스를 예로 들면, Meilisearch의 메모리 사용량은 Elasticsearch의 약 1/3~1/2이고, 인덱스 저장 용량은 Elasticsearch의 약 1/2입니다. 즉, 4GB 메모리를 갖춘 클라우드 서버는 수백만 개의 문서와 수백 개의 QPS 검색 로드를 수행할 수 있습니다. 동일한 하드웨어 예산으로 Meilisearch가 지원할 수 있는 비즈니스 규모는 Elasticsearch의 약 2~3배입니다. 이는 Rust의 낮은 메모리 오버헤드와 Meilisearch의 설계 철학("인덱스는 검색에 필요한 데이터만 저장한다")에 의해 결정됩니다. - Elasticsearch는 일반 검색 엔진이며 인덱스에는 집계 분석(Aggregation)을 위한 많은 수의 데이터 구조가 포함되어 있는 반면, Meilisearch는 보다 컴팩트한 인덱스 크기를 위해 일부 분석 기능을 포기합니다.

경쟁 제품과의 아키텍처 차이점:

비교차원 메일리서치 타입센스 엘라스틱서치
핵심 언어 C++ 자바
인덱스 저장 효율성 ★★★★★ (컴팩트) ★★★★☆ ★★★☆☆
인스턴트 검색 기본 지원 ★★★★★ (네이티브) ★★★★☆ ★★★☆☆ (플러그인 필요)
내장된 의미 검색 ★★★★★ ★★★☆☆(이후 버전에서 지원) ★★★★☆ (플러그인 필요)
클러스터 확장성 ★★★☆☆ ★★★☆☆ ★★★★★
집계 분석 기능 ★★☆☆☆ ★★☆☆☆ ★★★★★
API 단순성 ★★★★★ ★★★★☆ ★★★☆☆
중국어 단어 분할 품질 ★★★☆☆ ★★★☆☆ ★★★★☆

사용방법

Meilisearch의 사용 경로는 "한 줄 명령 시작"부터 "프로덕션 시스템으로의 심층 통합"까지 모든 단계를 포괄합니다. 핵심 입구는 Docker 이미지와 HTTP API입니다.

빠른 시작(자체 호스팅 모드):

``배쉬

Docker를 사용하여 Meilisearch를 시작합니다. (의미론적 검색은 기본적으로 활성화되어 있습니다.)

docker run -it --rm \ -p 7700:7700 \ -e MEILI_MASTER_KEY=your_master_key \ -v $(pwd)/meili_data:/meili_data \ getmeili/meilisearch:v1.12


서비스 시작 후 `http://localhost:7700`(API Key 필요)을 통해 웹 관리 인터페이스에 접속하거나, HTTP API를 통해 인덱싱 작업을 수행합니다. 관리 인터페이스는 개발 단계의 디버깅에 적합한 인덱스 탐색, 검색 테스트 및 구성 보기 기능을 제공합니다.

**검색 API 호출 예**:

``배쉬
# 색인에 문서 추가
컬 -X POST 'http://localhost:7700/indexes/products/documents' \
  -H '권한 부여: your_master_key 전달자' \
  -H '콘텐츠 유형: 애플리케이션/json' \
  -d '[
    {
      "ID": 1,
      "title": "검은색 후드 스웨트셔츠",
      "description": "가을과 겨울에 입기에 적합한 순면 원단",
      "가격": 299,
      "브랜드": "도시패션",
      "카테고리": ["상의", "스웨트셔츠"]
    }
  ]'

# 즉시 검색 수행(입력된 각 문자 요청)
컬 'http://localhost:7700/indexes/products/search,q=hoodie&limit=20'

# 필터링 및 정렬로 검색
컬 'http://localhost:7700/indexes/products/search' \
  -H '콘텐츠 유형: 애플리케이션/json' \
  -d '{
    "q": "까마귀",
    "filter": "가격 >= 100 AND 가격 <= 500",
    "sort": ["가격:asc"],
    "facetsDistribution": ["브랜드", "카테고리"],
    "한도": 20
  }'

의미론적 검색 구성 단계:

  1. 시작 시 --enable-Vector-search를 설정하거나 컨텍스트 변수 MEILI_ENABLE_VECTOR_SEARCH=true를 통해 벡터 검색을 활성화합니다.
  2. 임베딩 모델을 선택합니다(기본값은 sentence-transformers/all-MiniLM-L6-v2와 같은 Hugging Face 모델을 통해 벡터 생성을 지원합니다).
  3. 인덱스 설정에서 벡터를 생성해야 하는 필드(일반적으로 텍스트 설명 필드)를 지정합니다.
  4. 검색 시 'hybrid: true' 매개변수를 통해 하이브리드 검색(BM25 + 벡터 의미 체계)을 활성화합니다.

클라우드 서비스 사용 프로세스:

  1. https://cloud.meilisearch.com에 접속하여 계정을 등록하세요.
  2. 프로젝트를 생성하고 노드 사양(Starter/Standard/Enterprise)을 선택합니다.
  3. API 호스트 및 API 키를 획득합니다.
  4. 인덱싱 및 검색 작업은 자체 호스팅과 동일한 API 인터페이스를 통해 수행되며 엔드포인트 주소만 다릅니다.

프로덕션 제한 배포 제안:

  • 고가용성 구성: 최소 3개의 노드가 클러스터를 구성하고, 각 노드는 마스터-슬레이브 복제로 구성됩니다. Meilisearch의 클러스터 토폴로지는 비교적 간단하고 Elasticsearch의 복잡한 샤드 라우팅 메커니즘이 없으므로 중소 규모 클러스터에 적합합니다.
  • 데이터 백업: 'meili_data' 디렉터리의 스냅샷 백업을 정기적으로 만듭니다. 클라우드 서비스 버전에는 일일 스냅샷이 자동으로 포함됩니다.
  • 모니터: /_health 엔드포인트를 관찰하고 대기 시간 측정항목을 검색합니다. 검색 지연이 100ms를 초과하면 알람을 트리거하는 것이 좋습니다. 즉각적인 검색 경험을 위해서는 100ms가 사용자 인식의 중요한 지점입니다.
  • 인덱스 워밍: 알려진 빈도가 높은 검색어의 경우 콜드 스타트 ​​중 첫 번째 검색 지연을 방지하기 위해 예열 쿼리를 통해 핫 인덱스 페이지를 메모리에 로드할 수 있습니다.

제품 가격

Meilisearch의 가격 시스템은 "오픈 소스 무료 + 종량제 클라우드 서비스 + 엔터프라이즈 버전 사용자 정의"의 3단계 구조를 채택하여 경쟁 제품에 비해 중소 규모 시나리오에서 비용 경쟁력이 높습니다.

오픈 소스 버전(자체 호스팅): MIT 라이선스, 완전 무료입니다. 핵심 엔진에는 기능 제한이 없으며 의미 검색, 연합 검색 등 고급 기능은 모두 오픈 소스로 제공됩니다. 권장 하드웨어 구성:

  • 개발/소규모(문서 100,000개 미만): 2GB RAM, 1 코어, 10GB SSD
  • 중간 규모(문서 100,000~500만 개): 4GB RAM, 2코어, 50GB SSD
  • 대규모(500만~5천만 문서): 8GB+ RAM, 4+ 코어, 200GB+ SSD

클라우드 호스팅 버전(Meilisearch Cloud):

  • 스타터: 약 $50-100/월, 검색 1백만 건/월, 1GB 인덱스, 단일 노드. 소규모 프로젝트 및 검증제품에 적합합니다.
  • 표준: 약 $300-500/월, 5백만 검색/월, 10GB 인덱스, 다중 노드 고가용성. 성장단계에 적합한 제품입니다.
  • 기업: 가격은 영업팀에 문의하세요. 무제한 트래픽, 전용 클러스터, SSO 통합, 감사 로그, 사용자 정의 SLA 및 글로벌 다중 지역 배포.

무료 할당량: 클라우드 서비스는 월별 약 100,000건의 검색에 대한 무료 평가판 할당량을 제공하며 신용카드가 필요하지 않습니다. 이는 개념 증명(PoC) 및 MVP 단계의 초기 프로젝트에 매우 친숙합니다. 개발부터 출시까지 비용이 거의 0이고, 검색량이 할당량을 초과한 후에만 청구가 시작됩니다.

경쟁사 제품과의 가격 비교 (5GB 인덱스 기준 월 평균 100만 건 검색 기준):

서비스 제공자 월간 비용(예상) 벡터 검색 포함 여부 운영 및 유지보수 아웃소싱
Meilisearch 자체 호스팅 ~$30-50 (서버 비용) 아니요
메일리서치 클라우드 ~$50-100
타입센스 클라우드 ~$75-150 예(최신 버전)
알골리아 ~$100-300+ 아니요(추가 계획 필요)
탄력적 클라우드 ~$95-150+ 예(플러그인 필요) 부분

가격 책정 전략에 대한 주요 통찰: Meilisearch Cloud의 가격 책정은 "절대 최저가"를 추구하지 않습니다. 동일한 검색량에서 Algolia의 무료 할당량이 더 높고 Elastic Cloud의 기업 할인이 더 유연합니다. 하지만 "완전한 기능을 갖춘 오픈 소스 버전" 전략을 사용하여 개발자는 개발 단계에서 모든 기능을 무료로 사용할 수 있으며 SLA와 무료 운영 및 유지 관리가 필요한 경우에만 유료 클라우드 서비스로 전환할 수 있습니다. 이 "사전 사용 후 지불" 퍼널 전략은 "무료 할당량을 초과하면 서비스를 중지"하는 Algolia의 하드 캡 전략보다 개발자에게 더 친숙하며, 팀 내에서 "평가판"에서 "정식 구매"로 결정을 승격시키는 것도 더 쉽습니다.

애플리케이션 시나리오

Meilisearch의 응용 시나리오는 "고빈도 검색 상호 작용 + 다중 유형 데이터 검색 + 엔드 투 엔드 검색 경험"을 중심으로 진행됩니다. 다음 네 가지 시나리오가 대규모로 검증되었습니다.

  • 전자상거래 및 소매 사이트 검색: 이것은 Meilisearch의 가장 성숙한 응용 시나리오입니다. 제품 검색은 정확한 일치(브랜드 이름 SKU)와 퍼지 일치(예: "달리기에 적합한 가벼운 신발"과 같은 설명 쿼리)를 모두 충족해야 합니다. 하이브리드 검색 모드를 사용하면 의미적으로 관련된 롱테일 상품을 강조하면서 정확하게 일치하는 결과를 먼저 표시할 수 있습니다. 구현 효과 참고: 유럽의 한 패션 전자상거래 회사가 자체 개발한 Solr에서 Meilisearch로 검색 백엔드를 마이그레이션한 후, 검색 페이지의 평균 검색 응답 시간이 320ms에서 45ms로 떨어졌고, 사용자 검색 후 이탈률이 약 12% 감소했습니다(팀이 기술 블로그에서 공유한 데이터 기준). 검색 관련 비즈니스 지표의 개선은 프런트엔드 UI와 추천 알고리즘의 협력에 달려 있습니다. Meilisearch 자체는 검색 응답 속도와 품질에 대한 기본적인 보장만을 제공합니다.

  • SaaS 제품 글로벌 검색: 프로젝트 관리 CRM 및 고객 서비스 시스템과 같은 SaaS 제품에서 사용자는 한 번의 검색으로 프로젝트, 작업, 연락처, 작업 주문, 파일 및 기타 엔터티를 찾아야 합니다. 통합 검색은 여러 API 엔드포인트를 순차적으로 처리하는 지루한 프런트 엔드 쿼리를 피하고 "서로 다른 엔터티에 대한 검색 결과를 균일하게 정렬하는 방법" 문제도 해결합니다. 구현 팁: 통합 검색의 정렬 정확도는 각 인덱스의 독립적인 상관 관계 조정에 따라 달라집니다. 품질이 낮은 인덱스로 인해 글로벌 정렬이 저하되지 않도록 통합 단계에서 각 인덱스의 상위 5개 정확도를 개별적으로 테스트하는 것이 좋습니다.

  • 지식베이스 및 문서 검색: 회사의 지식베이스(Confluence/Notion 등)에 대한 개선 사항을 검색하거나 기술 문서 웹사이트에 대한 현장 검색을 수행합니다. 여기에서는 의미 검색이 가장 중요합니다. 사용자는 문서의 정확한 용어를 모르고 검색할 수 있습니다(예: "배포 방법"을 검색했지만 문서에는 "설치 가이드"라고 나와 있음). 적응 경계: 지식 베이스 문서가 100만 개를 초과하고 언어 간 검색이 필요한 경우(예: 중국어와 영어 혼합 지식 베이스) 중국어와 영어라는 두 개의 독립적인 인덱스로 분할하고 각각 단어 분리기와 임베딩 모델을 구성하는 것이 좋습니다. 검색 결과는 통합 검색을 통해 병합되어 단일 다국어 색인보다 더 나은 검색 품질을 얻습니다.

  • 콘텐츠 플랫폼 및 커뮤니티 검색: 뉴스 웹사이트, 블로그 플랫폼, 포럼 커뮤니티에 대한 사이트 내 검색이 가능합니다. 콘텐츠 검색의 핵심 지표는 '검색을 시작한 후 결과를 클릭하는 사용자의 비율'입니다. 이는 검색 결과와 사용자 의도 간의 일치를 반영합니다. Meilisearch의 즉각적인 검색 및 철자 허용 오차는 일치할 수 있는 쿼리 범위를 직접적으로 확장하는 반면, 의미 검색은 "사용자가 제품 이름은 말할 수 없지만 기능을 설명할 수 있는" 경우 회상 기능을 향상시킵니다.

시나리오에는 적합하지 않음:

  • 초대규모 데이터 레이크 검색(>10억 문서): Meilisearch의 클러스터 아키텍처 설계는 중소 규모에 편향되어 있으며, 단일 클러스터에서 수백억 개의 문서를 관리하는 운영 및 유지 관리 경험은 Elasticsearch만큼 풍부하지 않습니다. 데이터 크기가 수십억 단위이고 여전히 빠르게 증가하고 있다면 Elasticsearch의 확장성은 더욱 보장됩니다.
  • 복잡한 로그 분석 및 시계열 데이터: Meilisearch는 집계 분석(Aggregation) 기능을 포기하고 Logstash/Kibana 생태계를 지원하지 않으며 로그 모니터링 APM 또는 시계열 지표 쿼리 시나리오에 적합하지 않습니다. 이것은 Elasticsearch 고유의 영역입니다.
  • 완전 관리형 SaaS에 대한 매우 낮은 대기 시간 요구 사항(P99 < 20ms): Algolia의 독점 검색 엔진은 여전히 ​​응답 속도에서 이점을 가지고 있습니다(P99는 약 10-15ms). 금융 거래 시장 검색과 같이 대기 시간에 매우 민감한 시나리오의 경우 Algolia가 여전히 더 나은 선택입니다.
  • 법률/의료 등 매우 높은 재현율 요구 사항이 있는 검색 시나리오: Meilisearch의 순위 최적화는 "어떤 결과도 놓치지 않음"을 핵심(재상이 우선)이 아닌 "사용자 경험"을 기본 목표(상위 N 정확도가 우선)로 간주됩니다. 검색 요구 사항이 법적 사건을 검색하거나 의학 문헌을 완성하는 것이라면 Elasticsearch의 사용자 정의 채점 기능(예: 스크립트 점수)이 더욱 세부적인 제어를 제공합니다.

해당자

메일리서치의 해당 그룹은 개발자를 중심으로 양끝으로 확장됩니다. 다양한 역할은 다양한 기능 차원에 중점을 둡니다.

  • 백엔드/풀스택 개발자: 검색 엔진의 "직접 운영자"입니다. Meilisearch의 API 디자인은 백엔드 개발자에게 친숙합니다. Docker 가져오기부터 첫 번째 검색 반환까지 전체 프로세스를 15분 안에 완료할 수 있습니다. API 스타일은 RESTful 모범 사례에 가깝고 오류 메시지는 읽기 쉬우며 검색 엔진의 내부 메커니즘(예: 역 인덱스, 샤딩 전략 TF-IDF)을 이해할 필요가 없습니다. 일반적인 초상화: Laravel/Rails/Django를 사용하여 중소 규모 팀에서 개발한 제품으로, 제품 액세스 사이트를 검색하는 데 3일이 걸립니다.

  • SaaS 제품 관리자 및 기술 의사결정자: 검색 기능에 대한 요청자 및 선택 의사결정자입니다. 그들의 초점은 API의 특정 매개변수가 아니라 "검색 경험이 제품 차별화 셀링 포인트가 될 수 있는지 여부"에 있습니다. 즉석 검색, 철자 허용 오차 및 의미 검색의 조합은 사용자 완료율(작업 완료율)을 직접적으로 향상시킬 수 있는 제품 기능입니다. 의사결정의 근거: 자사 제품의 실제 데이터(최소 10만개 품목)를 활용하여 선정 단계에서 Meilisearch, Typesense, Algolia에 대한 PoC를 진행하여 팀이 검색 품질의 차이를 직관적으로 느낄 수 있도록 한 후 가격과 운영, 유지 관리 조건을 토대로 의사결정을 내리는 것이 좋습니다.

  • 독립 개발자 및 소규모 팀: 1~3명으로 구성된 팀에서 검색 기능을 빠르게 실행해야 합니다. 자체 호스팅 Meilisearch는 가장 저렴한 솔루션입니다. 월 100엔의 클라우드 서버로 수천에서 수만 개의 제품에 대한 검색 요청을 호스팅할 수 있습니다. 권장하지 않음: 상품의 핵심 데이터가 1,000개 이내 항목(예: 개인 블로그)인 경우 데이터베이스에서 'LIKE'를 사용하여 직접 쿼리할 수 있습니다. 검색 엔진을 도입하면 불필요한 운영 및 유지 관리 부담이 늘어납니다.

  • Enterprise Architect 및 인프라 팀: 검색 엔진의 확장성, 보안 및 운영 복잡성을 평가해야 합니다. Meilisearch는 보안을 위해 API 키 인증과 세분화된 인덱스 권한을 지원하지만 RBAC(역할 기반 액세스 제어)는 지원하지 않습니다. 운영 및 유지 관리 측면에서 Docker Compose 구성은 다중 노드 배포를 완료할 수 있으며 Elasticsearch와 같은 복잡한 Ansible Playbook 또는 Helm Chart가 필요하지 않습니다. 선택 제안: 팀이 이미 Elasticsearch 운영 및 유지 관리 기능을 갖추고 있고 클러스터 크기가 크다면 단순히 "엔진 변경"을 위해 엔진을 변경할 필요는 없습니다. 처음부터 검색 서비스를 구축하고 데이터 양이 수천만 달러 이내인 경우 Meilisearch의 학습 곡선은 더 평평합니다.

전제조건: Meilisearch를 사용하기 위한 전제조건은 매우 낮습니다. HTTP API와 JSON만 이해하면 됩니다. 검색 엔진 이론, 단어 분할 원리 또는 순위 알고리즘에 대한 심층적인 이해가 필요하지 않습니다. 그러나 프로덕션에 적용하기 전에 보안 모범 사례 문서(API 키 관리, HTTPS 구성, CORS 정책 등)를 한 번 이상 읽어 보는 것이 좋습니다.

요약 및 전망

Meilisearch는 Rust 네이티브 엔진에 "즉시 사용 가능한 검색 경험"을 구축하여 Elasticsearch와 Algolia 사이의 정확한 시장 격차를 발견했습니다. 이는 Elasticsearch보다 훨씬 간단하고 Algolia보다 더 오픈 소스이며 자체 호스팅됩니다. 그 차별점은 "보다 강력한 검색 알고리즘"이 아니라 "검색 엔진 구성 비용을 전례 없는 낮은 수준으로 낮추는 것"에 있습니다. 동시에 MIT 라이센스와 의미 검색에 대한 기본 지원을 통해 오픈 소스 검색 엔진 시장에서 명확한 생태학적 틈새 시장을 구축했습니다.

현재 제한사항:

  • 클러스터 크기 한도: 단일 노드 성능은 우수하지만 10개 이상의 노드에 대한 클러스터 운영 및 유지 관리 경험은 Elasticsearch에 비해 훨씬 낮습니다. 분산 시스템의 데이터 일관성 메커니즘(노드 오류 시 인덱스 동기화)은 여전히 ​​반복되고 있으며 대규모 클러스터 시나리오에서는 Elasticsearch보다 보수적인 기대치를 갖는 것이 좋습니다.
  • 중국어 단어 분할 정확도: MMSEG 알고리즘은 일상적인 중국어 및 일반적인 전문 용어에 대해 잘 수행되지만 롱테일 전문 용어(예: 의학 이름, 법률 용어, 기술 특허의 복합어)의 분할 세분성은 충분하지 않습니다. 중국어 콘텐츠가 밀집된 시나리오에서는 적절한 단어 분할 테스트를 수행하고 필요한 경우 사용자 지정 사전으로 보완하는 것이 좋습니다.
  • 클라우드 서비스 커버리지 영역: 현재 Meilisearch Cloud의 노드는 주로 AWS 유럽(프랑크푸르트, 아일랜드)과 미국(버지니아, 오레곤) 지역에 배포되어 있으며, 아시아 태평양 및 남미 지역의 노드 커버리지 확장이 필요합니다. 주요 사용자 기반이 아시아 태평양 지역에 있는 제품의 경우 현재로서는 자체 호스팅이 더 나은 대기 시간 옵션일 수 있습니다.
  • 집계 분석 기능 부족: 의도적인 설계 절충 - Meilisearch는 Elasticsearch의 집계 분석(Aggregation)을 수행하지 않습니다. 이는 또한 로그 분석, 지표 모니터링 및 기타 시나리오를 대체할 수 없음을 의미합니다. 향후 제품에 "하이브리드 검색 + 분석" 요구 사항이 있는 경우 추가 분석 엔진을 배포해야 할 수도 있습니다.

주요 동향: 검색은 '키워드 일치'에서 '의미론적 이해 + 생성 검색'의 융합 상태로 전환되고 있습니다. Meilisearch는 하이브리드 검색 및 내장된 벡터 지원을 통해 이러한 추세에 대비하고 있습니다. RAG(Retrieval Augmentation Generation) 기본 통합은 2026년 하반기에 도입될 예정이며, 이를 통해 Meilisearch는 문서 ID 목록을 반환할 뿐만 아니라 LLM과 협력하여 검색 결과 요약을 생성하거나 사용자 질문에 직접 답변할 수 있습니다. 이로 인해 Meilisearch는 "검색 인프라"에서 "AI 지식 검색 계층"으로 더욱 발전할 것입니다.

조달/채택 위험 평가:

  • 단기 파일럿(1~3개월): 개발팀은 반나절 만에 Docker를 통해 API를 시작하고 액세스할 수 있어 거의 무료로 검색 품질 평가를 완료할 수 있습니다. 스트레스 테스트에는 실제 비즈니스 데이터의 10%를 사용하여 평균 검색 지연이 50ms 이내, P99가 200ms 이내인지 확인하는 것이 좋습니다.
  • 중기 통합(3~12개월): 단어 분할 구성으로 비즈니스 언어, 특히 전문 용어 및 브랜드 이름의 적용 범위를 확인합니다. 검색 품질 모니터링 시스템(예: 상위 10개 검색어에 대한 결과율 0, 클릭률)을 구축합니다. 자체 호스팅 모드인 경우 클러스터 확장 및 축소 계획과 백업 및 복구 프로세스를 수립합니다.
  • 장기 종속성(12개월 이상): MIT 라이선스는 공급업체 종속으로 인한 법적 위험을 제거하지만 데이터 마이그레이션 비용은 여전히 ​​남아 있습니다. 색인 구조, 단어 분할 구성 및 대조는 Meilisearch에만 해당되며 다른 검색 엔진으로 이동하려면 색인을 다시 작성해야 합니다. "검색 엔진 구성이 암묵적으로 지식이 되는" 것을 방지하기 위해 인덱스 구조 및 구성에 대한 버전 관리를 수행하는 것이 좋습니다.
  • 기업 구매 전 확인 항목: ① 데이터 거주 지역이 규정 준수 요구 사항(GDPR/"개인정보 보호법")을 충족하는지 여부 ② 클라우드 서비스의 SLA 세부정보(가용성 약속, 보상 조항, 조기 종료 조건) ③ 자체 호스팅 시나리오에서는 핵심 엔진의 장기 유지 관리 약속을 확인합니다(Meilisearch SAS의 자금 조달 상태 및 팀 규모를 참고로 사용할 수 있음).

관련 도구: perplexity, you-com

버전 정보

  • 메일리서치 1.12 :공식적인 정확한 날짜는 아직 없지만 즉각적인 검색 경험과 의미 검색 기능을 계속해서 반복할 것입니다.
  • 메일리서치 1.11 :공식적인 정확한 날짜는 아직 없지만 향상된 의미 검색 및 다국어 지원이 가능합니다.

사용자 후기

  • 후기를 불러오는 중...