정말 좋은 검색 엔진을 만드는 건 얼마나 어려울까? — 인덱스: AI 에이전트를 위해 특별히 설계된 밀리초 수준의 동적 문서 검색 시스템. @opennote 설립자 Abhi가 진행하는 이 기술 프레젠테이션은 자체 개발 검색 시스템인 Index에 중점을 두고 있습니다. 이 시스템은 인간 기반 검색 엔진이 아니라, AI 에이전트가 사용자의 개인 지식 기반에서 매우 빠르고 정확한 검색을 수행할 수 있도록 설계되었습니다. 기존 검색 시스템이 지능형 에이전트의 요구를 충족하지 못하는 이유는 무엇일까요? 기존 검색 엔진은 인간을 위해 설계되었습니다. 인간은 점차 시스템의 특징을 이해하고, 단어를 바꾸거나 보완하고, 단점은 건너뛰는 법을 배웁니다. 그러나 지능형 에이전트는 이러한 능력이 전혀 없습니다. 모든 질의는 처음부터 시작하며, 기억력도 없고 지식 기반에 대한 "감각"도 없습니다. 더 심각한 문제는 다음과 같습니다. • 지능형 에이전트는 환각에 매우 취약합니다. 맥락이 약간만 틀려도 전체 대응이 무너집니다. • Opennote는 일반적으로 수억 개가 아닌 수천 개의 문서만 처리하며, 오류에 대한 허용 범위가 사실상 전혀 없어 첫 번째 시도에서 가장 정확한 세그먼트를 찾아야 합니다. • 이 제품은 일반 소비자를 대상으로 하기 때문에 연구 도구처럼 몇 초 동안 기다릴 수 없습니다. 엔드투엔드 지연 시간은 수백 밀리초 이내로 안정적이어야 합니다. 저자는 지수가 다음과 같은 거의 모순되는 요구 사항을 동시에 충족해야 한다고 반복해서 강조합니다. 1. 매우 낮은 지연 시간: P99 < 300ms (전 세계 어디에서나 동일한 속도) 2. 높은 정확도: 동일한 개념이 여러 문서에 나타나는 경우 가장 정확한 맥락을 가진 개념을 찾는 것도 필요합니다. 3. 다중 테넌시 및 동적 범위: 성능 저하 없이 "나만", "친구와 공유", "전체 커뮤니티", "공개 페이지 포함" 등 모든 조합의 동시 검색을 지원합니다. 4. 글로벌 저지연성: 사용자와 에이전트가 지구 반대편에 있을 수 있습니다. 5. 데이터는 결코 정적이지 않습니다. 사용자는 언제든지 편집, 공유, 삭제하고 권한을 변경할 수 있습니다. 핵심 기술 선택(대부분은 반직관적임) 1. 선택된 저장소 및 핵심 검색 엔진은 Pinecone, Weaviate, Qdrant, Chroma와 같은 주류 전용 벡터 데이터베이스 대신 PlanetScale에 호스팅된 Postgres(pgvector + pg_trgm + tsvector)입니다. 그 이유는 다음과 같습니다. • 매우 빠른 메타데이터 필터링으로 벡터 계산 전 후보 집합을 최소화합니다. • 진정한 하이브리드 검색(전문 + 퍼지 매칭 + 의미론)을 기본적으로 지원합니다. • 멀티 테넌트 경계, 동적 필터링, UPSERT/DELETE는 모두 본질적으로 효율적입니다. • 실제 테스트 결과 P99 지연 시간이 475ms에서 209ms로 단축되었습니다. 2. 전체 글로벌 분산 런타임 아키텍처는 Cloudflare 생태계에서 실행됩니다: Workers + Hyperdrive + R2 + Workers AI + Vectorize + KV. 장점은 코드가 전 세계 수십 개의 에지 노드에서 자연스럽게 실행되고, 데이터베이스에 액세스할 때 Hyperdrive로 가속화된 후 로컬 액세스만큼 빠르게 느껴진다는 것입니다. 3. 문서 처리 파이프라인(Ingestion) Worker + R2 객체 스토리지 설계를 완전히 비상태 저장 방식으로 채택하여 Worker의 128MB 메모리 제한에 엄격하게 맞춰 적용합니다. 프로세스는 다음과 같습니다. 1. 재귀적 블록 분해(모든 종류의 복잡한 문서에 충분히 강력함) 2. 해시를 사용하여 이전 청크와 새 청크를 정확하게 비교하고 실제로 변경된 부분만 다시 계산합니다. 3. 변경된 청크만 다시 포함합니다(비용과 시간 모두 절약) 4. 문서와 중요한 문단에 대한 요약을 작성하여 에이전트에게 "전체 문서의 내용"에 대한 추가적인 맥락을 제공합니다. 5. 새 청크 UPSERT 6. 이전 청크를 삭제하고 캐시 무효화를 트리거합니다. 4. 검색 프로세스 1. 에이전트로부터 쿼리를 받으면 먼저 매개변수 정리와 필터 조건 연결을 수행합니다. 2. Postgres에서는 메타데이터를 사용하여 검색 공간(테넌트, 소스, 태그, 시간, 명시적 제외 등)을 미리 최소화합니다. 3. 필터링된 데이터 세트에서 전체 텍스트 검색과 벡터 검색을 병렬로 실행합니다. 4. 두 점수 세트를 0~1로 정규화하고 알파라는 매개변수를 사용하여 동적으로 융합합니다(0 = 순수 키워드, 1 = 순수 의미론). 5. 데이터베이스 내에서 중복 제거, 정렬, Top-K 검색을 수행합니다. 6. 선택적으로 Workers AI를 사용하여 가벼운 재정렬을 수행하고 마지막으로 결과를 반환합니다. 5. 캐싱 시스템(가장 독창적인 부분) 일반 캐시는 문서가 업데이트된 후에 더러워집니다. 저자는 이 문제를 완전히 해결하기 위해 3단계 메커니즘을 설계했습니다. • 정확한 캐싱: 동일한 쿼리 + 동일한 필터링 조건이 키-값 쌍에 직접 적용됩니다. • 시맨틱 캐싱: 벡터화를 사용하여 쿼리 임베딩을 저장하여 유사한 쿼리를 캐싱할 수 있도록 합니다. • 역색인 무효화: 각 청크는 캐시에 나타나는 쿼리를 기록합니다. 청크가 무효화되면 관련된 모든 캐시가 사전에 삭제됩니다. 이를 통해 데이터베이스에 가해지는 부담이 크게 줄어들고 오래된 콘텐츠가 반환되는 일이 없습니다. 실제 테스트 결과는 표준 데이터 세트 MSMARCO(10,000개의 질문-답변 쌍) + BGE-M3 모델을 사용하여 ChromaDB와 엄격하게 비교되었습니다. Recall@10, MRR@10, MAP@10, NDCG@10의 네 가지 지표 측면에서 Index는 Chroma와 거의 동일하거나 약간 더 높습니다. 또한 하이브리드 검색, 멀티 테넌트 격리, 동적 필터링과 같은 추가 기능도 제공합니다. 실제 운영 환경에서 P99 지연 시간은 300ms 이내로 안정적입니다. Index는 이제 공식적으로 Opennote 커뮤니티 기능에 대한 전체 검색 부하를 처리합니다. 저자는 현재의 색인이 단지 '검색' 도구일 뿐이며, 다음 단계는 이를 '이해' 도구로 발전시키는 것이라고 생각합니다. • 청크 간의 시간적, 인과적, 진화적 관계를 추가합니다. • 중요도/인기도 신호를 도입합니다. • 더 작고, 더 빠르고, 더 전문화된 임베딩 모델을 지속적으로 정제합니다. • 에이전트가 다단계 검색 전략을 사용자 정의할 수 있도록 합니다. 궁극적인 목표는 지능형 에이전트가 사용자의 지식 기반에 대한 "정신 모델"을 실제로 보유할 수 있도록 하는 것이며, 매번 맹목적으로 추측하는 것이 아닙니다.
