Semble: AI 에이전트를 위한 코드 검색 최적화와 98% 토큰 절감

AI 코딩 에이전트를 구축하는 개발자에게, "grep-and-read" 사이클은 악명 높은 병목 현상입니다. 에이전트가 코드베이스를 이해해야 할 때 보통 키워드로 grep을 수행하고 파일을 식별한 뒤 전체 파일을 컨텍스트 윈도우에 읽어들입니다. 이 과정은 느릴 뿐만 아니라 매우 비효율적이며, 단 하나의 함수 정의를 찾기 위해 수천 개의 토큰을 무관한 코드에 소비하게 됩니다.

Semble은 이 사이클을 깨기 위해 설계된 코드 검색 라이브러리입니다. 에이전트에게 가장 관련성 높은 코드 청크만 반환하는 자연어 및 의미 기반 쿼리를 수행할 수 있는 방법을 제공함으로써, Semble은 기존의 grep 기반 탐색에 비해 토큰 사용량을 최대 98%까지 줄일 수 있다고 주장합니다.

Semble의 아키텍처

무거운 트랜스포머 기반 검색 엔진과 달리, Semble은 속도와 로컬 실행을 위해 설계되었습니다. GPU, API 키, 외부 서비스가 전혀 필요 없이 완전히 CPU에서 실행됩니다.

작동 원리

Semble은 정밀도와 재현율을 모두 보장하기 위해 하이브리드 검색 전략을 사용합니다:

  1. Code-Aware Chunking: Using the Chonkie library, Semble splits files into chunks that respect the logical structure of the code.
  2. Hybrid Retrieval: It combines two complementary methods:
    • Semantic Search: Utilizes static Model2Vec embeddings (via the potion-code-16M model) for conceptual similarity.
    • Lexical Search: Uses BM25 for exact matches on identifiers and API names.
  3. Reciprocal Rank Fusion (RRF): The results from both retrievers are fused to create a unified ranking.
  4. Code-Aware Reranking: The final results are refined using several specific signals:
    • Adaptive Weighting: Symbol-like queries (e.g., getUserById) prioritize lexical matches, while natural language queries remain balanced.
    • Definition Boosts: Chunks that define a class or function are ranked higher than those that simply reference it.
    • Identifier Stemming: Query tokens are stemmed to match variations like parseConfig and ConfigParser.
    • Noise Penalties: Test files, legacy shims, and declaration stubs are down-ranked to surface canonical implementations first.

성능 및 벤치마크

Semble의 주요 가치 제안은 속도와 정확도의 교차점에 있습니다. 프로젝트 벤치마크에 따르면 NDCG@10이 0.854에 달하는데, 이는 훨씬 큰 트랜스포머 모델(예: CodeRankEmbed Hybrid)과 거의 동일하지만 지연 시간이 현저히 낮습니다.

  • Indexing Speed: An average repository can be indexed in ~250ms.
  • Query Latency: Queries typically resolve in ~1.5ms.
  • Token Efficiency: The project reports that Semble can reach 94% recall using only 2k tokens, whereas a grep+read approach would require a 100k context window to reach only 85% recall.

통합 및 워크플로

Semble은 현대 에이전트 하니스에 "drop-in" 도구가 되도록 설계되었습니다. 두 가지 주요 방식으로 통합할 수 있습니다:

1. Model Context Protocol (MCP) 서버

MCP를 지원하는 에이전트(예: Claude Code, Cursor, Codex)에서는 Semble을 서버로 실행할 수 있습니다. 이를 통해 에이전트는 search와 find_related 도구를 직접 호출할 수 있습니다. 저장소는 필요에 따라 복제·인덱싱되며, 로컬 경로를 감시해 자동 재인덱싱이 이루어집니다.

2. Bash 통합

서브 에이전트나 CLI 기반 하니스의 경우, AGENTS.md 또는 CLAUDE.md에 Semble을 추가할 수 있습니다. 이렇게 하면 에이전트가 grep 대신 semble search "query" ./path를 사용하도록 지시합니다.

커뮤니티 관점 및 비판적 분석

벤치마크가 인상적이긴 하지만, Hacker News 커뮤니티는 에이전트 워크플로에서 의미 검색을 실제 적용하는 데 몇 가지 중요한 문제점을 제기했습니다.

"신뢰" 문제

LLM이 의미 검색 도구의 결과를 실제로 신뢰할 수 있을지에 대한 큰 우려가 있습니다. 한 사용자(@jerezzprime)가 지적했듯이, 많은 모델이 grep에 대해 강하게 RL 튜닝되어 있습니다. 모델이 의미 결과를 신뢰하지 않으면 여전히 grep을 수행하거나 파일을 다시 읽어 토큰 절감 효과가 사라질 수 있습니다.

확률적 vs. 결정적 검색

grep은 결정적인 반면, Semble은 확률적입니다. 일부 사용자는 작은 임베딩 모델이 문자 그대로의 문자열 검색이 즉시 찾을 수 있는 중요한, 희귀 식별자를 놓칠 수 있다고 우려했습니다.

"인지 결핍" 가설

"단축키" 도구를 제공함으로써 에이전트의 인지 능력이 감소할 수 있다는 보다 철학적인 비판도 있습니다. 일부는 tree와 grep을 사용해 코드베이스를 탐색하는 능력이 추론 과정의 핵심이라고 주장하며, 이를 블랙박스 검색 도구로 대체하면 장기 과제에서 "배포 가능한 지능"이 순전히 감소할 수 있다고 경고합니다.

실제 테스트

이러한 비판에도 불구하고, 일부 사용자는 긍정적인 결과를 보고했습니다. 한 사용자(@aadishv)는 병행 테스트를 수행했으며, 비Semble 버전이 때때로 더 상세했지만 Semble 버전은 특정 추적 작업에서 일관되게 컨텍스트 효율성이 높고 비용 효율적이라는 것을 발견했습니다.

결론

Semble은 "에이전트 네이티브" 코드 검색으로의 전환을 의미합니다. 전체 파일을 읽는 비용이 많이 들고 부정확한 과정을 없애면서 에이전트가 훨씬 작은 컨텍스트 풋프린트로 작업할 수 있게 합니다. 확률적 검색이 grep의 결정적 특성을 완전히 대체할 수 있는지에 대한 논쟁은 계속되지만, 토큰 오버헤드의 대규모 감소는 AI 기반 개발을 확장하려는 모든 사람에게 Semble을 매력적인 도구로 만듭니다.

Sources