XERJ: 자기 숫자가 부풀려졌다고 먼저 말하는 코딩 에이전트용 검색엔진

자기 프로젝트의 가장 흥미로운 특징이 스스로의 고백이라는 경우는 드물다.

XERJ는 코드와 문서를 위한 Rust 검색엔진으로, 코딩 에이전트를 위해 만들어졌고, Elasticsearch 호환 와이어 프로토콜을 쓰며 Apache-2.0 라이선스다. 실제 달러 숫자가 적힌 벤치마크 표도 있다. 그리고 GitHub 스타 수가 합성 코호트에 의해 약 열세 배 부풀려졌다고 인정하며, 그 수치를 인용하지 말아 달라고 요청하는 메인테이너 노트도 있다.

둘 다 시간을 들일 만한 이야기이고, 둘은 서로 연결되어 있다.

무엇을 겨냥한 도구인가

코딩 에이전트가 코드베이스를 이해해야 할 때 가장 먼저 하는 일은 grep이다. grep은 정직하다. 패턴에 맞는 줄을 찾아준다. 하지만 grep을 쓰는 에이전트는 그 일치가 중요한지 확인하려고 파일을 읽어야 하고, 파일을 읽는 일이 컨텍스트 윈도를 채운다. 큰 파일 하나가 답의 가치보다 많은 토큰을 잡아먹을 수 있다.

XERJ가 내놓는 대안은 로컬 인덱스다. 폴더를 가리키면 autoindex가 파일 형식을 살피고, 데이터셋을 추론하고, 쓰레기를 버리고, 데이터셋마다 별도 인덱스를 만든다. 저장소에 있는 실제 실행 로그는 이렇다. 데이터셋 593개 추론, A 단계에서 정크 또는 건너뛴 파일 1,955개, 이어지는 B 단계에서 워커 8개로 25,329개 파일 인덱싱, 158.1초 만에 완료, 83,103개 레코드 활성.

코드는 tree-sitter로 파싱하며, 모든 것을 평평한 텍스트로 만들지 않고 심볼과 줄 번호를 유지한다. 그래서 xerj def <symbol>이 파일과 줄, 시그니처를 돌려줄 수 있다. 저장소를 넘나드는 정의로 이동, 에이전트가 처음부터 필요로 했던 바로 그것이다.

벤치마크, 꼼꼼히 읽기

프로젝트는 8개 과제를 4개 언어로, 각 조건당 16회씩 돌렸고, 추정이 아니라 실제 claude -p 토큰 소비를 측정했다. 세 가지 설정: 기억만 사용, grep 기반, XERJ.

기억만 사용은 출력 토큰 260,916개, $11.18, 16문제 중 11문제 해결. grep은 26,477 토큰, $3.27, 16문제 전부 해결. XERJ는 9,982 토큰, $1.58, 역시 16문제 전부 해결.

즉, grep보다 출력 토큰이 약 2.7분의 1, 모델 기억에 의존할 때보다 26분의 1이며, 해결률은 그대로다. 최고 단일 사례인 Java 과제에서는 278분의 1을 아꼈다. 사용자들은 엔드투엔드로 대략 5배라고 보고한다.

이제 이 글을 쓰게 만든 단서. 저장소의 헤드라인은 “grep보다 토큰 40분의 1”이라고 주장한다. 본문의 통제 실험은 2.7분의 1이라고 말한다. 같은 주장이 아니고, 그 간극이 바로 벤치마크 기반 마케팅을 믿기 어렵게 만드는 패턴 그 자체다. 프로젝트의 미덕이라면 README 스스로 본문 수치를 우선하라고 적어 두었다는 점이다. 과장한 헤드라인과 이를 바로잡는 각주를 함께 내놓는 건 이상한 출시 방식이지만, 적어도 정정은 거기 있다.

런칭 글에서 아무도 말하지 않는 제약

‘에이전트를 위한 검색’ 프로젝트 대부분이 빼먹는 문장이 있다. 효과는 모델이 그 코드를 이미 아는지에 달려 있다.

비공개 사내 코드, 틈새 코드, 학습 컷오프 이후 코드에서는 검색이 크게 절약된다. 모델이 정말로 추측할 수 없기 때문이다. 반대로 모델이 만 번쯤 본 인기 오픈소스 라이브러리에서는 인덱스가 중립적이거나 오히려 해롭다. 모델이 이미 아는 것을 가져오려고 토큰을 쓰게 된다.

이 제약 하나가 배포 방식을 바꾼다. 보편적 업그레이드가 아니다. 특정 실패 모드에 대한 처방이다. 아무도 블로그 글을 쓰지 않은 코드를 다루는 에이전트, 그 실패 모드에 대한.

--insecure 플래그는 진짜 신뢰 경계다

xerj --insecure로 실행하면 TLS와 API 인증이 꺼진다. 포트에 닿을 수 있는 사람은 사실상 슈퍼유저다. 모든 인덱스를 읽고, 쓰고, 지울 수 있다. /_memory 아래의 모든 것까지 포함해서. 개발자 노트북 한 대에서는 괜찮고, 공유되는 어떤 환경에서는 재앙이다.

기본값이 이 플래그보다 낫다. 새 노드는 127.0.0.1에 바인딩되고, 비루프백 주소로의 평문 바인딩은 server.allow_insecure_network_bind = true를 명시하지 않으면 시작을 거부한다. 프로젝트는 또한 0.0.0.0에서 비보안으로 돌린 것이 실제 취약점이었다는 점(LAN 클라이언트가 인가 없이 쓸 수 있었다)과 그것이 수정되었다는 점을 기록해 두었다. 자기 과거 취약점에 이름을 붙이는 건 좋은 습관이다.

템플릿이 되어야 할 공개

instrumentation 커밋에서 메인테이너는 이렇게 썼다. 저장소의 스타와 포크는 합성 코호트에 의해 약 열세 배 증폭되었다. 실제 설치 데이터는 빈약하다. 릴리스 에셋 다운로드가 대략 145회, 완료된 설치가 약 28회. 그리고 Cloudflare RUM이 7월에 기록을 멈췄으므로 사이트의 제로 트래픽 차트는 인공물이다.

Elasticsearch 호환을 내세우고 적합성 테스트 1,371개를 통과한(실패 0, 스킵 3) 프로젝트로서는 놀라운 공개다. 오픈소스 신호가 지금 어떤 상태인지도 알려준다. 스타 수는 마케팅 표면이고, 성장 루프를 돌리는 사람은 누구나 움직일 수 있다. 믿을 만한 숫자는 저자가 자기 불이익을 무릅쓰고 자발적으로 내놓은 것뿐이다.

그 밖에 만나게 될 것들

설치는 curl을 셸로 파이프하는 방식인데, SHA256을 검증하고 체크섬 도구를 찾지 못하면 진행을 거부한다. 이 패턴 치고는 드물게 제정신인 가드다. 빌드는 정적 musl에 jemalloc, Linux 우선이고 Windows는 수동 설치. xerj_plan과 xerj_map을 포함해 열세 개 도구를 노출하는 MCP 서버가 있고, xerj init은 명령 하나로 Claude Code나 Cursor를 연결한다. scalar8 양자화를 쓰는 kNN을 지원한다. 다중 노드 배포에는 Helm 차트와 compose 파일이 따라온다.

버전은 1.0.0-rc.x이고 CLI는 아직 움직인다. CLA는 Apache 것을 각색한 것으로, 변호사 검토를 받지 않았고 자리표시자 필드 두 개가 남아 있다는 메인테이너 노트가 붙어 있다. 많은 커밋이 코딩 에이전트가 작성했고 그렇게 표시되어 있다. 투명한 동시에, 의존하는 코드는 읽어야 한다는 이유이기도 하다.

레퍼런스 코딩, 아무도 벤치마크하지 않는 용도

README 깊숙한 곳에 가장 흥미로운 활용법이 묻혀 있다. 풀려는 문제에 가장 가까운 오픈소스 프로젝트에 인덱스를 걸고, 참조 코드를 컨텍스트에 둔 채 자기 버전을 쓰는 것.

실제 엔지니어링의 상당 부분이 이렇게 진행된다. 이미 해결한 라이브러리를 찾아 읽고, 더 좁은 것을 구현한다. 못하면 저장소 절반을 프롬프트에 붙여넣게 된다. 잘하면 “이 프로젝트는 백프레셔를 어디서 처리하지”라고 물어 파일과 줄과 함수 시그니처를 받는다.

위 벤치마크의 한계도 드러난다. 레퍼런스 코딩은 남의 저장소를 내려받아 인덱싱해야 하니 시간과 디스크와 네트워크가 든다. 절약은 첫 질의가 아니라 두 번째, 세 번째 질의에서 나타난다. 평가하려는 사람은 과제 하나가 아니라 세션 전체를 측정해야 한다.

Elasticsearch 호환성 주장

XERJ는 Elasticsearch 와이어 프로토콜을 말하고, 프로젝트는 적합성 테스트 1,371개가 실패 0, 스킵 3으로 통과했다고 보고한다. 사실이라면 Elasticsearch용으로 이미 작성된 도구들을 최소한의 수정으로 돌려볼 수 있고, 문서 수백만 건을 담으려고 클러스터 비용을 내온 팀에게는 출구가 생긴다.

Elasticsearch의 SSPL 라이선스에 대한 비판은 타당하다. SSPL은 OSI 의미의 오픈소스가 아니고, 검색엔진 위에 제품을 올리려는 회사에는 그게 중요하다. 하지만 ‘호환’은 스펙트럼이다. Query DSL 커버리지, 집계, 분석기 동작에서 차이가 드러나고, 적합성 스위트가 당신이 선의 어느 쪽에 있는지 아는 유일한 방법이다.

써야 할까

에이전트가 사내 코드, 큰 비공개 저장소, 어떤 모델도 본 적 없는 로그와 문서를 다룬다면 근거는 괜찮다. 로컬이고, Apache-2.0이고, ES 호환이고, tree-sitter 심볼 인식이 있으며, 벤치마크는 정직하다. 작업의 대부분이 공개 라이브러리라면 grep과 잘 손본 ripgrep 설정이 못지않게 효과적일 것이고, 유지할 것도 훨씬 적다.

이 프로젝트에서 하나만 가져간다면 검색엔진이 아니라 공개하는 습관을 가져가라. 자기 숫자가 부풀려졌다고 말해주는 도구는, 자기가 마흔 배 낫다고 말하는 도구보다 더 볼 만하다.