Semble, 에이전트 코드 검색의 토큰세를 줄이다

Semble은 스스로를 “에이전트를 위한 빠르고 정확한 코드 검색”이라고 설명한다. 공개 README 기준 핵심 주장은 분명하다. grep으로 후보를 찾고 파일을 통째로 읽는 방식보다 약 98% 적은 토큰을 쓰며, 평균 저장소 색인은 약 250ms, 질의는 약 1.5ms에 끝난다는 것이다. CPU에서 동작하고 API 키, GPU, 외부 서비스가 필요 없다는 점도 강조한다.

이 뉴스가 중요한 이유는 단순히 새 CLI가 나왔기 때문이 아니다. 최근 코딩 에이전트의 실패는 모델이 코드를 전혀 못 써서라기보다, 엉뚱한 파일을 읽고, 같은 탐색을 반복하고, 컨텍스트 창을 비싼 로그 저장소처럼 쓰는 데서 자주 발생한다. Vibe coding과 agentic engineering의 경계가 흐려질수록 “어떤 모델을 쓰나”만큼 “모델에게 어떤 근거를 주나”가 제품 경쟁력이 된다.

grep 이후의 에이전트 검색 계층

기존 에이전트는 대개 grep, rg, find, read 조합으로 코드베이스를 훑는다. 사람에게는 충분한 방식이지만 에이전트에게는 비용이 크다. 검색어를 잘못 잡으면 결과가 너무 많고, 파일을 통째로 읽으면 토큰이 낭비된다. Semble은 자연어 질의를 받아 관련 코드 조각만 돌려주는 방식으로 이 문제를 줄이려 한다.

Model Context Protocol 서버로 붙일 수 있고, PyPI 패키지로 설치할 수 있다는 점은 실용적이다. Claude Code, Cursor, Codex, OpenCode 같은 도구가 모두 각자 다른 UX를 갖고 있어도, 코드 검색은 공통 하부 계층이 될 수 있다. Statewright의 상태 머신 기반 에이전트 안정성이 실행 흐름의 신뢰성을 다뤘다면, Semble은 탐색 단계의 신뢰성을 노린다.

토큰 절감은 곧 제품 단가 절감이다

98%라는 숫자는 벤치마크 조건을 따져봐야 한다. 모든 저장소와 모든 질의에서 같은 절감이 나오리라고 단정할 수는 없다. 그래도 방향은 맞다. 코딩 에이전트가 실무에 들어오면 모델 호출 자체보다 “반복 탐색”이 비용의 큰 부분이 된다. 특히 대규모 모노레포에서는 한 번의 잘못된 파일 읽기가 이후 추론 품질까지 망칠 수 있다.

한국 기업 입장에서는 이 지점이 중요하다. 내부 코드가 외부 SaaS 색인으로 나가는 것을 꺼리는 조직은 여전히 많다. Semble이 말하는 로컬 CPU 실행, 외부 서비스 불필요, MCP 또는 쉘 통합은 보안팀과 개발팀 사이의 협상 비용을 낮춘다. Braintrust 침해 사고가 보여준 AI 평가 스택의 키 관리 경고처럼, AI 도구의 가치는 성능만이 아니라 비밀정보를 어떻게 덜 노출하느냐에도 있다.

벤치마크보다 중요한 운영 지표

Semble README는 코드 특화 트랜스포머 대비 색인 속도와 질의 속도, NDCG 품질을 제시한다. 하지만 도입 여부는 다른 지표로 판단해야 한다. 에이전트가 같은 파일을 몇 번 반복해서 읽는지, PR당 평균 입력 토큰이 얼마나 줄어드는지, 잘못된 수정 파일 비율이 감소하는지, 리뷰어가 “왜 이 파일을 건드렸는지” 추적할 수 있는지가 더 중요하다.

GitHub CLI나 ripgrep처럼 이미 표준이 된 도구와 경쟁한다기보다, Semble은 에이전트용 어댑터가 되려 한다. 사람은 여전히 rg가 편할 수 있다. 그러나 에이전트는 검색어를 발명하고, 결과를 평가하고, 다음 질의를 반복하는 루프를 돈다. 그 루프를 줄이는 도구는 모델 업그레이드 못지않게 큰 효과를 낸다.

결론

Semble의 메시지는 “코딩 에이전트를 더 똑똑하게 만들려면 검색부터 바꿔야 한다”다. 모델이 커질수록 컨텍스트를 많이 넣는 유혹도 커지지만, 실무 시스템에서는 덜 읽고 더 정확히 읽는 능력이 비용과 품질을 동시에 좌우한다. 한국 개발팀은 새 모델을 기다리기 전에, 에이전트가 코드베이스를 찾고 읽는 방식을 계측해볼 필요가 있다.

FAQ

Semble은 무엇인가?

AI 코딩 에이전트가 코드베이스에서 필요한 조각을 빠르게 찾도록 돕는 로컬 코드 검색 도구다.

98% 토큰 절감은 확정된 수치인가?

Semble이 공개한 벤치마크 기준 주장이다. 실제 절감률은 저장소 구조, 질의 품질, 기존 워크플로에 따라 달라진다.

기존 grep을 대체하나?

사람 개발자에게는 grep과 ripgrep이 여전히 유용하다. Semble은 에이전트가 반복 탐색에 쓰는 토큰을 줄이는 보조 계층에 가깝다.

기업 도입 시 가장 먼저 볼 지표는?

PR당 입력 토큰, 반복 파일 읽기 횟수, 잘못 수정한 파일 비율, 리뷰어 재작업 시간을 보는 것이 좋다.

한국 개발팀에 왜 중요한가?

외부 색인 서비스 없이 로컬에서 코드 검색을 강화할 수 있다면 보안 부담을 낮추면서 에이전트 생산성을 시험할 수 있다.