XERJ: AI 에이전트 토큰을 줄이는 로컬 검색 엔진
XERJ는 Rust로 작성된 Elasticsearch 호환 로컬 AI 검색 엔진입니다. autoindex 기능은 명령어 하나로 코드, 문서, 로그, PDF를 색인합니다. 그래서 coding agent는 grep, sed로 파일을 하나씩 읽는 대신 필요한 정확한 조각을 바로 가져올 수 있습니다. 프로젝트는 grep보다 토큰 사용량이 40배 적다고 밝히며, 검색, RAG, 보안 감사, 에이전트 메모리를 지원합니다. 공식 통제 연구의 참조 코딩 시나리오에서는 에이전트의 출력 토큰이 2.7배 줄었고 해결률은 16/16을 유지했습니다. xerj init으로 Claude Code와 Cursor에 한 번에 연결할 수 있어, 에이전트 비용을 낮추면서 기존 Elasticsearch 클라이언트를 계속 쓰려는 개발자와 엔지니어링 팀에 적합합니다.
배경
coding agent는 낯선 프로젝트에 들어가면 grep, sed, 파일 열기를 반복하며 구조를 파악합니다. 파일을 읽을 때마다 token이 나가고, 방향을 잘못 잡으면 한 번 더 읽어야 합니다. 저장소가 클수록 비용이 불어나고, 모델도 관련 없는 내용 속에서 길을 잃기 쉽습니다. XERJ는 바로 이 문제를 겨냥한 오픈소스 도구입니다.
XERJ는 Rust로 작성된 로컬 AI 검색 엔진입니다. 에이전트가 먼저 색인으로 데이터를 파악하고, 필요한 내용만 정확히 가져오게 하자는 발상입니다. 새로운 벡터 데이터베이스가 아니라 전통적인 전문 검색 엔진과 에이전트 도구 사이에 놓이는 계층입니다. Elasticsearch와 호환되므로 기존 클라이언트를 고치지 않고 연결할 수 있고, MCP와 skill 같은 에이전트 연동 방식도 염두에 두었습니다.
프로젝트 태그에 bm25-search가 있어 단어 빈도 기반 순위가 기본임을 알 수 있습니다. 문서에 벡터 검색 페이지도 따로 있으니 의미 기반 검색을 배제하지는 않습니다. 핵심 용례는 참조 코딩입니다. 에이전트가 작업과 가장 가까운 오픈소스 저장소를 찾아 색인한 뒤, 그 해법을 참고해 코드를 씁니다.
심층 분석
가장 중요한 기능은 autoindex입니다. 명령어 하나로 코드, 문서, 로그, PDF를 색인하고, 같은 색인을 검색, RAG, 보안 감사, 에이전트 메모리에 함께 씁니다. 용도마다 시스템을 따로 만들 필요가 없습니다. 검색 결과는 file:line 위치가 붙은 순위별 조각으로 돌아옵니다. 에이전트는 파일 전체가 아니라 바로 인용할 수 있는 출처를 받습니다. def 명령은 정의로 이동하는 기능으로, 파일 줄 번호와 함수 시그니처를 알려 줍니다. xerj gain 명령은 도구가 실제로 한 일을 추정치가 아닌 실제 집계로 보고합니다.
XERJ는 grep보다 token을 얼마나 줄일까요? 프로젝트는 grep보다 token 사용량이 40배 적다고 밝힙니다. 참조 코딩 시나리오의 통제 연구에서는 에이전트의 출력 token이 2.7배 줄었고 해결률은 16/16으로 유지되었습니다. 일상 사용자의 반응은 대략 5배입니다. 세 수치는 기준이 서로 다르므로 따로 읽어야 합니다. 프로젝트는 이 절감 폭이면 더 작고 저렴한 모델이 기억에 의존해 코드를 쓰는 비싼 모델을 앞설 수 있다고도 말합니다. 시작 방법은 두 가지입니다. 하나는 에이전트에게 프롬프트를 넘겨 llms.txt를 읽고 설치, 색인, 참조 코딩 설정을 직접 끝내게 하는 것입니다. 다른 하나는 curl 설치 스크립트를 실행하고 xerj 서비스를 띄운 뒤, xerj init으로 Claude Code나 Cursor에 연결하고 xerj autoindex로 프로젝트 디렉터리를 색인하는 것입니다. 이후 xerj search로 질문하면 됩니다. 주의할 옵션은 --insecure입니다. TLS와 API key 인증을 끄므로, 포트에 닿는 모든 호출자가 슈퍼유저가 되어 모든 색인과 /_memory 네임스페이스를 읽고 지울 수 있습니다. 단독 개발 머신용이며, 새 노드는 기본적으로 127.0.0.1에만 바인딩됩니다. 보안 모델은 docs/SECURITY_MODEL.md에 있으니 먼저 읽어 보는 편이 좋습니다.
산업 영향
XERJ는 "덜 읽고 정확히 읽기"를 독립된 인프라로 만들었습니다. 에이전트 비용이 팀의 실제 청구서가 된 지금, 검색을 모델의 컨텍스트 창 밖으로 꺼내 집계할 수 있고 재사용 가능한 색인 계층에 맡기는 접근은 현실적입니다. Elasticsearch 호환 덕분에 기존 운영 경험과 클라이언트 라이브러리를 그대로 쓸 수 있어 도입 문턱도 낮습니다.
라이선스는 Apache-2.0입니다. 커뮤니티 방식은 독특합니다. 참여 증표로 짧은 사용 보고서를 내 달라고 하며, 사람과 에이전트 모두를 환영한다고 밝힙니다. 실제 피드백을 모을 수 있지만, 보고서의 품질과 측정 기준이 일관될지는 지켜봐야 합니다.
전망
위험은 분명합니다. 첫째, 효과 수치는 프로젝트의 자체 연구와 사용자 후기에서 나왔고, 연구 표본은 16개 과제로 작으며 독립 검증은 아직 없습니다. 자기 코드베이스에서 직접 재 보아야 하며, xerj gain이 그 수단이 됩니다. 둘째, 색인에 코드, 로그, 에이전트 메모리가 모이므로 보안 설정이 틀리면 노출 범위가 큽니다. 셋째, 에이전트가 외부 오픈소스 저장소를 내려받아 색인하면 라이선스와 출처 신뢰의 문제가 따라옵니다.
앞으로는 벤치마크가 얼마나 공개되는지, 벡터 검색이 얼마나 성숙하는지, 더 큰 다중 사용자 환경에서 인증과 권한을 어떻게 설계하는지가 관건입니다. 이 답이 XERJ가 개인 개발자의 편리한 도구에 머물지, 팀의 공용 인프라로 자랄지를 가를 것입니다.
Sources
FAQ
XERJ는 무엇인가요?
XERJ는 Rust로 작성된 오픈소스 로컬 AI 검색 엔진이며 Elasticsearch와 호환됩니다. autoindex 기능은 명령어 하나로 코드, 문서, 로그, PDF를 색인합니다. 그래서 coding agent는 grep, sed로 파일을 하나씩 읽는 대신 필요한 정확한 조각을 바로 가져올 수 있습니다.
XERJ가 AI 코딩 에이전트에 왜 중요한가요?
XERJ는 검색을 모델의 컨텍스트에서 꺼내 셀 수 있고 재사용 가능한 로컬 색인 계층으로 옮깁니다. 프로젝트는 grep보다 토큰이 40배 적다고 밝힙니다. 통제 연구에서는 에이전트 출력 토큰이 2.7배 줄고 해결률은 16/16이었습니다. 이 수치는 프로젝트 자체 자료이며 독립 검증이 필요합니다.
XERJ를 도입하기 전에 무엇을 확인해야 하나요?
XERJ를 도입하기 전에 xerj gain 명령이 알려 주는 실제 집계로 자신의 코드베이스에서 절감 효과를 측정하세요. --insecure는 TLS와 API 키 인증을 끄므로 1인 개발 머신에서만 쓰세요. docs/SECURITY_MODEL.md를 읽고 외부 저장소의 라이선스도 확인해야 합니다.