xerj-org/xerj — XERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.
XERJ: 파일을 자동 색인해 AI 에이전트가 검색하는 로컬 검색 엔진
XERJ는 코드와 문서, 로그 등 여러 형식의 파일을 자동 색인하고 Elasticsearch API로 검색하는 로컬 엔진입니다. 제작자 측 측정에서는 grep 기반 코딩보다 출력 토큰을 2.7배 줄이면서 같은 해결률을 기록했지만, 효과는 모델이 이미 아는 공개 코드보다 비공개·희소 코드에서 큽니다.
- 주제
에디터 노트
XERJ의 토큰 절감 주장은 공개 코드 전반에 적용되는 성능 보장이 아니라 모델이 기억하지 못하는 코드를 검색하는 상황에 한정됩니다. 제작자 측 실험에서는 grep 방식과 해결률을 맞춘 채 출력 토큰과 비용을 낮췄지만, 인기 공개 라이브러리에서는 효과가 없거나 불리할 수 있다는 조건도 함께 제시합니다. 현장 약 5배 절감은 통제 실험이 아니라 사용자 보고입니다. 실제 도입 판단에는 API 호환 범위와 실행 경계를 함께 봐야 합니다. 테스트 1,369개 중 1,366개 통과라는 수치와 스크롤 검색의 제한은 Elasticsearch 대체를 검토할 때 구체적인 기준을 제공합니다. 반면 `--insecure`는 접근 가능한 호출자에게 색인 삭제 권한까지 주므로 로컬 개발 환경과 공유 서버의 설정을 구분해야 합니다. 벤치마크와 호환성 결과는 프로젝트가 공개한 측정치이며, 원문은 재현 자료도 안내합니다.
AI 요약
XERJ는 폴더를 자동으로 분석해 파일 형식에 맞는 색인을 만들고, 검색 결과를 파일 경로와 줄 번호로 돌려주는 로컬 검색 엔진입니다. 코드에는 tree-sitter를 적용해 심볼과 전체 텍스트를 함께 색인합니다. 코드 검색과 RAG, 보안 감사, 로그 분석, 에이전트 메모리를 한 엔진에서 처리하며 Elasticsearch REST API와 MCP(Model Context Protocol)도 지원합니다.
에이전트 코딩에서의 토큰 절감
프로젝트가 제시한 통제 실험은 모델이 기억하지 못하는 코드를 대상으로 8개 작업과 4개 언어를 시험하고 각 방식에 16회 실행을 배정했습니다. 기억만 사용한 에이전트는 출력 토큰 260,916개와 비용 11.18달러로 11/16개 작업을 해결했습니다. grep 기반 에이전트는 26,477개와 3.27달러로 16/16개를 해결했고, XERJ는 9,982개와 1.58달러로 같은 16/16개를 해결했습니다. 따라서 이 실험에서 XERJ의 출력 토큰은 grep 방식보다 2.7배 적고, 기억만 사용한 방식보다 26배 적습니다. Java 작업 하나에서는 최대 278배 차이가 났다고 설명합니다.
다만 이 이점은 모델이 코드를 이미 기억하는지에 따라 달라집니다. 프로젝트는 비공개 코드나 내부 코드, 희소하거나 학습 시점 이후에 나온 코드에서 효과가 크고, 모델이 이미 아는 인기 공개 라이브러리에서는 효과가 없거나 불리할 수 있다고 밝힙니다. 일상 개발에서 약 5배 절감했다는 수치는 통제 실험과 구분해 사용자 현장 보고로 제시합니다.
자동 색인과 검색 기능
xerj autoindex <폴더> 명령은 파일 형식을 감지해 데이터셋별 색인을 만듭니다. 코드 외에도 CSV, JSON, SQLite, PDF, 문서 파일, 스프레드시트, 이메일, Jupyter 노트북, 로그 등을 다룹니다. Unity 프로젝트에서는 텍스트 직렬화된 씬과 프리팹을 GameObject와 Component 단위로 나누고, 스크립트와 씬의 연결도 검색할 수 있도록 색인합니다. 문서에 나온 한 실행 사례에서는 25,329개 파일을 8개 워커로 158.1초 동안 처리해 데이터셋 593개와 레코드 83,103개를 만들었습니다. 이 수치는 해당 사례의 결과입니다.
검색은 전체 텍스트, 벡터, 하이브리드 방식을 지원합니다. Elasticsearch 클라이언트와 대시보드를 기존 방식으로 연결할 수 있으며, MCP 서버는 검색과 메모리 저장·회상 등 13개 도구를 제공합니다. 에이전트 메모리는 /_memory/{namespace} 경로에 저장합니다. XERJ 자체가 로컬에서 처리하는 기능과 달리 선택형 Jev 재정렬 기능은 결과 문서 텍스트를 TypeSafe AI 서버로 보냅니다. 프로젝트는 해당 기능이 기본적으로 꺼져 있고 API 키가 필요하다고 명시합니다.
보안과 호환성의 경계
--insecure 옵션은 TLS와 API 키 인증을 끕니다. 이 상태에서는 포트에 접근하는 모든 호출자가 색인을 읽고 삭제할 수 있는 관리자 권한을 가집니다. 새 노드는 기본적으로 127.0.0.1에만 바인딩하며, 다른 인터페이스에 인증 없이 바인딩하려 하면 명시적 허용 없이는 시작하지 않습니다. 공유 환경에서는 인증을 켜고 API 키를 전달해야 합니다.
XERJ는 Elasticsearch 내부 구현이나 포크가 아니라 Elasticsearch API 호환 엔진입니다. 프로젝트의 호환성 테스트는 1,369개 중 1,366개를 통과했고, 남은 차이도 공개합니다. 스크롤 검색은 전체 결과를 순회하는 커서가 아니라 앞부분을 제한해 저장하는 스냅샷 방식이므로, 큰 결과 집합에는 search_after를 쓰라고 안내합니다. Elasticsearch 8.13.4와의 비교에서는 55개 항목에서 우세, 26개에서 동률, 4개에서 열세였으며, 열세 항목은 높은 쓰기 부하에서 읽기 p99 지연이 커지는 문제라고 설명합니다.
원문: GitHub / 번역·요약: Trawling