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

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

프롤로그 — 검색 박스 하나에 들어 있는 4개의 세계

2026년에도 어느 정적 사이트 / 문서 / SaaS 화면을 열든 오른쪽 위에 작은 돋보기 아이콘이 있다. 누르면 모달이 뜨고, 입력하면 결과가 뜬다. 사용자는 그게 다 같은 거라고 생각한다. 하지만 개발자 입장에선 그 박스 뒤에 **완전히 다른 4개 진영**이 들어 있다.

1. **매니지드 SaaS** — Algolia, Algolia DocSearch, (구) Sajari → Algolia NeuralSearch. 가입하고 키 넣으면 끝. 가격이 들고, 데이터가 외부에 간다.

2. **셀프호스팅 검색 엔진** — Meilisearch, Typesense, Elastic, OpenSearch. 직접 띄우고 색인하고 운영한다. 비용 낮고 통제권 크고, 운영 부담도 크다.

3. **정적 / 인-브라우저** — Pagefind, Orama, Lunr.js, Fuse.js, MiniSearch, FlexSearch. 백엔드가 아예 없거나, 빌드 타임에 인덱스를 만들어 정적으로 띄운다.

4. **AI 문서 검색 (질문→답변)** — Markprompt, kapa.ai, Inkeep, Sourcegraph Cody, AnswerOverflow. 검색이 아니라 RAG 챗봇으로 변신한 카테고리.

이 글은 2026년 5월 기준 이 네 진영의 지도를 그린다. 각 도구의 위치, 가격 모델, 색인 / 쿼리 API의 모양, 그리고 "우리 사이트엔 뭘 쓰면 되나"의 질문에 답한다. 임베딩 / 키워드 / 하이브리드 리트리벌의 차이도 짚고, 한국 · 일본 시장의 검색 SDK도 챕터 하나 떼서 다룬다.

1장 · 2026년 사이트 검색 지도 — 4 진영

다 같은 "사이트 검색"이지만 책임 분담이 다르다.

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

핵심 분기점은 두 개다.

- **데이터가 어디로 가는가** — 클라우드(SaaS) vs 우리(셀프호스팅) vs 브라우저(정적).

- **결과가 무엇인가** — 일치하는 페이지 목록(검색) vs 합성된 답변(AI 검색).

전자는 비용 / 컴플라이언스의 문제고, 후자는 UX 의 문제다. 둘 다 답이 정해진 게 아니다 — 정적 사이트 100페이지에 Elastic 클러스터를 운영할 필요는 없고, 50만 페이지짜리 매뉴얼에 Lunr.js 인덱스를 박을 수도 없다. 사이트의 규모 · 갱신 빈도 · 콘텐츠 타입 · 컴플라이언스 요건이 진영을 결정한다.

2장 · Algolia + DocSearch — OSS 문서의 사실상 표준

Algolia(2012년 파리 창업)는 매니지드 사이트 검색의 대명사다. 가입하고 인덱스 만들고 키 넣고 InstantSearch 라이브러리 붙이면 5분 안에 검색 박스가 뜬다. 결과 품질, 오타 허용, 패싯, 동의어, 분석 도구가 잘 갖춰져 있다. 단점은 가격 — 무료 한도(월 만 검색)를 넘으면 빠르게 비싸진다.

오픈소스 / 문서 사이트에 결정적인 게 **DocSearch** 프로그램이다. Algolia가 OSS 문서 사이트에 한해 크롤러 + 인덱스 + 쿼리를 무료로 제공한다. React, Vue, Vite, Tailwind, Next.js, MDN — 어디든 켜져 있는 그 "Search Docs" 박스가 대부분 DocSearch다. 신청 → 승인 → 메타 태그 한 줄 + DocSearch 컴포넌트 → 끝.

// Next.js + DocSearch 컴포넌트 예시

export function Search() {

return (

appId="YOUR_APP_ID"

apiKey="YOUR_SEARCH_ONLY_API_KEY"

indexName="your-docs"

)

}

DocSearch v3 는 키보드 단축키(보통 Cmd+K), 모달 UI, 최근 검색, 즐겨찾기를 다 포함한다. 자체 호스팅을 안 하니 운영 부담이 0 이고, OSS 라면 비용도 0 이다.

상용 사이트라면 Standard 플랜이 월 50 달러부터 시작해서 검색 / 레코드 단위로 올라간다. 대형 e커머스는 결국 비싸지지만, 그만큼 결과 품질과 분석 도구로 뽑아낸다. **2026년 Algolia는 NeuralSearch(구 Sajari 인수)로 임베딩 기반 시맨틱 + 키워드 하이브리드를 같은 인덱스에서 제공한다 — 셀프호스팅으로 따라잡기 힘든 부분이다.**

3장 · Meilisearch — Rust 오픈소스 챔피언

Meilisearch(프랑스, 2018)는 "Algolia 의 셀프호스팅 대안"으로 가장 자주 추천되는 이름이다. Rust 로 짠 단일 바이너리, REST API, 기본값에서 오타 허용 / 형태소 분석 / 패싯이 다 켜져 있다. 도커로 한 줄에 띄울 수 있다.

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

색인 추가도 단순하다.

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

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

--data-binary '[{"id": 1, "title": "Hello", "body": "world"}]'

쿼리.

curl 'http://localhost:7700/indexes/posts/search?q=hllo'

→ hllo 와 hello 를 같은 결과로 본다 (오타 허용)

2024년 시리즈 B 를 마쳐 자금이 두둑하고, 2026년 현재 v1.x 가 안정. 임베딩 기반 시맨틱 검색 / 하이브리드 검색이 기본 기능에 들어와 있어 OpenAI / Ollama / Cohere 임베더를 인덱스에 붙일 수 있다. 매니지드 옵션(Meilisearch Cloud)도 있고, 가격은 Algolia 보다 일반적으로 낮다.

언제 쓰나: **자체 데이터를 외부에 안 보내고 싶을 때, 한국어 / 일본어 / 중국어 같은 비라틴 문자 검색에 강할 때**(Meili 는 형태소 분석 / 분절을 잘 한다). Algolia 만큼 분석 / 동의어 / 룰 엔진이 풍부하진 않지만, OSS 라이선스 + Rust 의 안정성 + 1MB 단일 바이너리는 매력적이다.

4장 · Typesense — Meilisearch 의 가장 큰 라이벌

Typesense(2017, C++)도 같은 "Algolia 대안" 영역이다. Meili 와 자주 비교되는데, 두 도구의 큰 그림은 비슷하다. 차이는 디테일.

| 항목 | Meilisearch | Typesense |

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

| 언어 | Rust | C++ |

| 라이선스 | MIT | GPL v3 |

| 단일 바이너리 | 예 | 예 |

| 임베딩 / 시맨틱 | 내장 | 내장 |

| 클러스터링 | Cloud 에서 | 오픈소스에서 |

| 매니지드 호스팅 | Meilisearch Cloud | Typesense Cloud |

| 한국어 기본 | 분절 가능 | 분절 가능 |

Typesense 는 클러스터링 / Raft 합의를 오픈소스 빌드에서도 정식 지원한다는 점이 차별점이다. 즉 자체 클러스터를 운영하려면 Typesense 가 조금 더 친절하다. 반대로 단일 노드 + 단순 운영을 원한다면 Meili 가 조금 더 가볍다는 평이 많다.

가격(클라우드 기준)은 두 곳 다 인스턴스 RAM / CPU 기반이고, 일반적으로 같은 데이터 양에 대해 Algolia 보다 싸다. 2026년 기준 둘 다 v1.x / v0.27.x 수준의 안정 버전이고, 둘 다 활발하다.

5장 · Pagefind — 정적 사이트 검색의 정답

Pagefind(2022, Eleventy 팀이 만듦)는 "정적 사이트를 위해 만들어진 검색"이다. 핵심 아이디어:

- 빌드 후 출력 디렉토리를 스캔해서 **JSON / WASM 인덱스 파일들을 생성**.

- 런타임에는 백엔드 없이, 사용자가 검색할 때 **필요한 인덱스 청크만 lazy 로드**해서 브라우저에서 쿼리.

- 인덱스가 크면 청크가 나뉘어, 페이지 수가 많아도 초기 로드가 작다.

빌드 후

npx pagefind --site dist

브라우저 측 코드.

const search = await pagefind.search('algolia')

for (const result of search.results) {

const data = await result.data()

console.log(data.url, data.excerpt)

}

Astro, Eleventy, Next.js (정적 빌드), Hugo 어디든 쓸 수 있다. 백엔드가 0 이고, CDN 만 있으면 무한 수평 확장. **사이트 페이지가 만 단위 이하라면 2026년의 정답에 가깝다.**

한계는 분명하다. 페이지가 십만 단위로 가면 인덱스 크기 자체가 커지고, 빌드 시간도 늘어난다. 실시간 갱신도 안 된다(빌드 때 만든다). 분석 / 패싯도 매니지드 SaaS 만큼 풍부하지 않다. 그러나 블로그 / 문서 / OSS 프로젝트 사이트엔 대부분 충분하다.

6장 · Orama — TypeScript + 오타 허용 + 시맨틱

Orama(2022, 이탈리아)는 "TypeScript 로 짠 인-브라우저 / 서버 양쪽 검색 엔진"이다. 같은 코드가 Node / Deno / 브라우저 / Edge 어디서든 돈다.

const db = create({

schema: {

title: 'string',

body: 'string',

tags: 'string[]',

})

insert(db, { title: 'Hello', body: 'world', tags: ['a', 'b'] })

const result = await search(db, { term: 'hllo', tolerance: 1 })

특징:

- 0 의존성 TypeScript, 번들 사이즈가 작다.

- 오타 허용 / BM25 / 패싯 / 동의어 기본.

- 시맨틱 검색(임베딩 기반)을 같은 라이브러리에서 지원.

- 매니지드 옵션(Orama Cloud)도 있다.

Pagefind 와 비교하자면 — Pagefind 는 "정적 사이트의 출력물에서 자동으로 인덱스 생성"에 강하고, Orama 는 "라이브러리로서 우리가 직접 색인 / 쿼리 코드를 짠다"에 강하다. 둘 다 인-브라우저로 돌릴 수 있다. SaaS / 앱이라면 Orama, 정적 사이트라면 Pagefind 가 보통 더 편하다.

7장 · Elastic + OpenSearch — 엔터프라이즈 헤비웨이트

Elasticsearch(2010, ELK 스택의 E)는 검색 엔진 진영의 절대 강자였다. 2021년 라이선스를 SSPL/Elastic License 로 바꾸면서 AWS 가 포크를 만들어 OpenSearch 로 분리됐다. 2026년 현재 두 갈래가 평행으로 발전한다.

- **Elastic** — 회사가 직접 클라우드 / 자체호스팅 둘 다. 머신러닝 / 시맨틱 검색 / Observability(APM, 로그)까지 확장. Apache 2.0 라이선스로 2024년에 일부 복귀(Elasticsearch / Kibana).

- **OpenSearch** — AWS 주도. Apache 2.0. AWS 서비스(Amazon OpenSearch Service)로 매니지드 제공. 한국 / 일본의 클라우드 팀들이 많이 쓴다.

둘 다 강력하지만, **사이트 검색만 필요하다면 과하다**. 진짜 가치는 로그 분석 / 메트릭 / APM / 풀-시맨틱 검색 / 자유로운 DSL 쿼리 같은 광범위한 시나리오에서 나온다. 문서 사이트에 Elastic 클러스터를 운영하면 운영 비용이 그 가치를 뒤집는다. **수십~수백 GB 데이터 + 복잡한 쿼리 + 분석까지 같은 인프라에서** 같은 시나리오라면 그때 Elastic / OpenSearch.

도커로 한 노드 띄우기 (개발용)

docker run -p 9200:9200 \

-e "discovery.type=single-node" \

docker.elastic.co/elasticsearch/elasticsearch:8.15.0

8장 · Lunr.js / Fuse.js / MiniSearch / FlexSearch — 인-브라우저 옵션

전통적인 "백엔드 없는 검색" 라이브러리들. 2026년 기준 각자의 자리가 있다.

Lunr.js — 클래식, 정적 사이트 검색의 원조

2012년경 Jekyll / Hugo 사이트에서 가장 많이 보였다. 빌드 타임에 JSON 인덱스를 만들어 브라우저에서 검색. BM25 기반, 형태소 분석기(영어 기본), stemming 지원. **여전히 동작하지만 활발한 개발은 줄었다.** 새 프로젝트라면 Pagefind / Orama 가 보통 낫다.

Fuse.js — 퍼지 / 오타 허용에 특화

const fuse = new Fuse(items, { keys: ['title', 'body'], threshold: 0.3 })

const result = fuse.search('algoria') // typo → algolia

검색 엔진이 아니라 **자바스크립트 배열을 흐릿하게 매칭하는 라이브러리**다. 메뉴 / 명령 팔레트 / 자동완성에 자주 쓴다. 전체 사이트 검색엔 한계가 있지만 작은 데이터셋엔 완벽하다.

MiniSearch

작고 빠른 인-브라우저 풀텍스트 검색. 전형적으로 만 단위 문서까지 인덱싱 가능. API 가 단순하고, BM25 + 오타 허용 + 패싯 지원.

const ms = new MiniSearch({ fields: ['title', 'body'] })

ms.addAll(docs)

const results = ms.search('hello world', { fuzzy: 0.2 })

FlexSearch

자바스크립트 검색 라이브러리 중 가장 빠르다고 알려진 쪽. 인덱스 형식이 효율적이고 메모리도 작다. API 가 다른 라이브러리보다 살짝 까다롭지만 성능 차이가 의미 있을 때 매력.

**선택 가이드**: 정적 사이트엔 Pagefind, 라이브러리 / SaaS 인-브라우저엔 Orama 또는 MiniSearch, 퍼지 매칭만 필요하면 Fuse.js, 극한 성능이 필요하면 FlexSearch.

9장 · Markprompt — AI 문서 검색의 한 선택지

검색이 "키워드 → 페이지"였다면, AI 문서 검색은 "질문 → 답변"이다. 사용자가 자연어로 묻고, RAG 가 관련 문서를 가져와서 LLM 이 답을 합성한다.

Markprompt(2023)는 "마크다운 / MDX 문서 위에 올리는 AI 검색"으로 시작했다. 워크플로:

1. 문서 사이트를 크롤하거나 GitHub 레포를 연결.

2. 청킹 + 임베딩으로 벡터 인덱스 생성.

3. 챗봇 위젯 / 검색 박스 / API 로 노출.

4. 사용자가 묻는 질문 → 관련 청크 검색 → LLM 합성 → 답변 + 출처 링크.

// React 위젯 예시 (간단화)

오픈소스 라이브러리(@markprompt/react 등)와 매니지드 호스팅을 함께 운영한다. 가격은 답변 / 메시지 단위. 큰 장점은 **출처 인용 + 빠른 통합**, 그리고 **챗 UI + 검색 UI 둘 다 제공**한다는 점이다.

10장 · kapa.ai — 개발자 문서에 특화된 AI 검색

kapa.ai 는 "당신의 기술 문서로 학습된 챗봇"으로 포지셔닝했다. Docker, OpenAI, Mapbox, Reflex 같은 회사들이 자기 docs 페이지 옆 "Ask AI" 버튼으로 쓴다.

핵심 차이는 **개발자 도메인에 강하게 튜닝**된 점이다. 코드 블록 인용, 버전 / 라이브러리 인식, GitHub Issues / Discord / Stack Overflow 같은 추가 소스 통합, halucination 을 줄이는 답변 검증 파이프라인. LangChain 기반으로 시작했고, 지금은 자체 파이프라인.

배포는 보통 위젯 한 줄.

data-website-id="YOUR_ID"

data-project-name="YourProject"

async></script>

가격은 별도 견적(엔터프라이즈), 일반적으로 Markprompt 보다 높은 가격대지만 답변 품질 / 운영(예: 환각 모니터링, 답변 휴먼 검토 워크플로)에 더 투자해 있다.

11장 · Inkeep / Sourcegraph Cody / AnswerOverflow — 그 외 AI 검색

생태계가 더 있다.

Inkeep

"제품 문서 + 커뮤니티 + 코드"를 합쳐서 답하는 AI 챗봇. Anthropic, Pinecone, Speakeasy 같은 SaaS 들이 쓴다. SDK / 위젯 / Slack 봇 / Discord 봇 같은 서피스가 풍부.

Sourcegraph Cody

코드 검색이 본업인 Sourcegraph 가 만든 AI 코드 어시스턴트. **사이트 검색이 아니라 코드베이스 검색** — IDE 안에서 "이 함수가 어디서 호출되나" 같은 질문에 답한다. 문서 사이트에 직접 박을 카테고리는 아니지만, 개발자 도구로서 강력.

AnswerOverflow

Discord 의 도움말 채널을 검색 가능한 인덱스로 만들어, Google / 사이트 검색에서 노출되게 한다. 오픈소스 프로젝트의 "Discord 에 답이 있는데 검색이 안 되는" 문제의 해결책. 무료 + 셀프호스팅 가능, 매니지드도 있다.

(참고) Mark (RIP)

2010년대에 인기 있던 검색 라이브러리들 중 일부는 사라졌다. Sajari 는 Algolia 에 인수되어 NeuralSearch 로 합류. Mark 같은 작은 프로젝트들은 유지보수가 멈췄다. 새 프로젝트라면 위에 언급한 활성 도구들을 보는 게 안전하다.

12장 · Embeddings vs Keyword vs Hybrid

2026년 검색의 핵심 논쟁: **임베딩 시맨틱 검색이 키워드 검색을 대체했는가**?

답: **아니다. 두 개를 같이 쓰는 하이브리드가 표준이 됐다.**

세 가지의 차이.

| 방식 | 어떻게 | 강점 | 약점 |

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

실무 패턴은 보통.

1. 키워드(BM25)로 후보 100개.

2. 임베딩 시맨틱 점수로 재순위.

3. 필요하면 LLM 기반 재순위(cross-encoder, Cohere Rerank 같은)로 최종 10개.

Algolia NeuralSearch, Meilisearch, Typesense, Elastic, OpenSearch 모두 2026년에 하이브리드를 지원한다. 정적 / 인-브라우저 도구(Pagefind / Orama)도 일부 임베딩을 붙이지만, 임베딩 인덱스 자체가 무거워서 사이트가 커지면 한계가 있다. **AI 문서 검색(Markprompt / kapa.ai)은 임베딩이 본업이고, 거기에 키워드를 보조로 쓰는 구조다.**

13장 · 한국 / 일본 — 네이버 · 카카오 · Yahoo! 검색 SDK

전 세계 표준은 위에서 다 다뤘지만, 한국 / 일본 시장은 별도 사정이 있다.

한국 — 네이버 / 카카오

- **네이버 검색 API** — 블로그 / 뉴스 / 백과사전 / 쇼핑 / 책 / 영화 등을 검색해 결과를 받는다. 자체 사이트의 인덱스가 아니라 "네이버의 인덱스를 빌려 쓰는" 모델. 신청 / 키 발급은 NAVER Developers 에서.

- **카카오 검색 API** — 다음 / 카카오의 인덱스에서 검색. 비슷한 카테고리(웹 / 블로그 / 카페 / 책 / 영상 / 이미지).

- **한국어 형태소 분석** — Algolia / Meili / Typesense / Elastic 다 한국어 분절기를 붙일 수 있다(MeCab, nori, lucene-analyzers-nori 등). 결과 품질은 분석기 설정에 크게 좌우된다.

자체 사이트 검색에는 위의 글로벌 도구들 + 한국어 분석기 조합이 일반적이다. 네이버 / 카카오 API 는 "네이버 / 다음의 결과를 우리 페이지에서 보여주고 싶을 때" 적합.

일본 — Yahoo! / 사이트 검색

- **Yahoo!検索 API** — Yahoo! JAPAN 의 웹 검색을 API 로 노출. 라이선스 / 사용 한도가 있어 실제로 자체 사이트의 검색 박스로 쓰는 케이스는 줄었다.

- **일본어 형태소 분석** — MeCab / Sudachi / Kuromoji 가 대표. Elastic / OpenSearch 의 kuromoji 플러그인, Algolia 의 일본어 분석기, Meilisearch 의 charabia(자체 분절기) 등. **공백이 없는 일본어는 분절기 품질이 검색 품질을 거의 결정**한다.

요약: **한 · 일 모두 인덱스 자체는 글로벌 도구를 쓰고, 분석기 / 토큰화에 신경을 쓴다**. 네이버 / Yahoo! API 는 별도 트래픽 시나리오(다른 사이트의 결과 표시)에 쓰는 게 보통.

14장 · 누가 무엇을 골라야 하나 — 시나리오별 추천

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

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

| OSS 문서 사이트 (만 페이지 미만) | DocSearch (무료) | Pagefind |

| OSS 문서 사이트 (대형) | DocSearch | Algolia 유료 |

| 개인 블로그 / 정적 사이트 | Pagefind | Lunr.js |

| Astro / Eleventy / Hugo | Pagefind | Orama |

| SaaS 인-브라우저 검색 | Orama | MiniSearch |

| 명령 팔레트 / 자동완성 | Fuse.js | FlexSearch |

| 상용 사이트 (중규모) | Algolia | Meilisearch Cloud |

| 데이터 외부 금지 | Meilisearch (셀프) | Typesense (셀프) |

| 엔터프라이즈 + 로그까지 | Elastic / OpenSearch | - |

| 답변형 docs 챗봇 (개발자) | kapa.ai | Inkeep |

| 답변형 docs 챗봇 (제품) | Markprompt | Inkeep |

| Discord 답변을 웹에 | AnswerOverflow | - |

| 코드베이스 검색 | Sourcegraph Cody | - |

| 한국어 사이트 (자체 색인) | Meili / Algolia + 한국어 분석기 | - |

| 일본어 사이트 (자체 색인) | Elastic + kuromoji / Algolia | Meili + charabia |

대원칙:

- **사이트 규모가 작으면 정적 / 클라이언트로 끝**낸다. 운영이 0 이다.

- **사이트 규모 / 변경 빈도 / 분석 요구**가 늘면 매니지드 SaaS 또는 셀프호스팅 검색 엔진.

- **컴플라이언스 / 데이터 주권**이 핵심이면 셀프호스팅.

- **사용자가 자연어로 묻기 시작**하면 AI 문서 검색 카테고리.

처음부터 완벽한 선택은 없다. 작게 시작(Pagefind / DocSearch / Lunr) → 부족하면 옮긴다 → 데이터 늘면 셀프호스팅 / SaaS → 사용자가 챗으로 묻기 시작하면 AI 검색 도입 — 이 순서가 2026년의 일반적인 진화 경로다.

마치며 — "검색 박스" 뒤의 결정들

검색 박스 하나에 보이지 않는 결정 4개가 들어 있다.

1. **데이터 호스팅** — 클라우드 / 우리 서버 / 브라우저.

2. **리트리벌 알고리즘** — 키워드 / 임베딩 / 하이브리드.

3. **결과 표현** — 페이지 목록 / 합성된 답변.

4. **운영 책임** — 매니지드 / 셀프.

2026년의 좋은 소식은 **각 결정마다 좋은 오픈소스 / 무료 옵션이 있다**는 것. OSS 문서엔 DocSearch, 정적 사이트엔 Pagefind, 셀프 색인엔 Meilisearch / Typesense, 인-브라우저엔 Orama / Fuse / MiniSearch, AI 답변엔 Markprompt / kapa.ai. 사용자가 검색하다 "어, 이거 잘 찾네"라고 느끼게 만드는 데 막대한 인프라가 필요한 시대는 끝났다.

남은 일은 — 우리 사이트의 사용자가 무엇을 어떻게 찾는지 한 번 보고, 위 지도에서 적절한 진영을 고르는 것뿐이다.

참고 / References

- [Algolia DocSearch](https://docsearch.algolia.com/) — OSS 문서용 무료 검색.

- [Algolia InstantSearch](https://www.algolia.com/products/search-and-discovery/instantsearch/) — UI 컴포넌트.

- [Algolia NeuralSearch](https://www.algolia.com/products/ai-search/) — 시맨틱 + 키워드 하이브리드.

- [Meilisearch](https://www.meilisearch.com/) — Rust 셀프호스팅 검색.

- [Meilisearch Cloud](https://cloud.meilisearch.com/) — 매니지드 옵션.

- [Typesense](https://typesense.org/) — C++ 셀프호스팅 검색.

- [Pagefind](https://pagefind.app/) — 정적 사이트용 검색 (Eleventy 팀).

- [Orama](https://orama.com/) — TypeScript 검색 엔진.

- [Elasticsearch](https://www.elastic.co/elasticsearch) — 엔터프라이즈 검색 + 옵저버빌리티.

- [OpenSearch](https://opensearch.org/) — Apache 2.0, AWS 주도 포크.

- [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) — AWS 매니지드.

- [Lunr.js](https://lunrjs.com/) — 정적 사이트 인-브라우저 검색 클래식.

- [Fuse.js](https://www.fusejs.io/) — 자바스크립트 퍼지 매칭.

- [MiniSearch](https://lucaong.github.io/minisearch/) — 가벼운 풀텍스트 검색.

- [FlexSearch](https://github.com/nextapps-de/flexsearch) — 빠른 JS 검색.

- [Markprompt](https://markprompt.com/) — AI 문서 검색.

- [kapa.ai](https://www.kapa.ai/) — 개발자 문서용 AI 챗봇.

- [Inkeep](https://inkeep.com/) — 제품 + 커뮤니티 통합 AI 검색.

- [Sourcegraph Cody](https://sourcegraph.com/cody) — 코드베이스 AI.

- [AnswerOverflow](https://www.answeroverflow.com/) — Discord 답변을 웹에.

- [NAVER Developers — Search API](https://developers.naver.com/docs/serviceapi/search/) — 네이버 검색 API.

- [Kakao Developers — Search](https://developers.kakao.com/docs/latest/ko/daum-search/common) — 다음 / 카카오 검색.

- [Yahoo! JAPAN Developer Network](https://developer.yahoo.co.jp/) — Yahoo!検索 등 일본 API.

- [Elasticsearch kuromoji plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-kuromoji.html) — 일본어 분석기.

- [Lucene nori 한국어 분석기](https://lucene.apache.org/core/9_10_0/analysis/nori/index.html) — 한국어 형태소 분석.

- [Cohere Rerank](https://cohere.com/rerank) — 하이브리드 검색용 재순위 모델.