이런 도구를 써보면, 코더가 AI 도구에 과하게 의존할 때 멍청해지는 것처럼 AI 자체도 멍청해지는 모습을 봄
에이전트형 AI는 이미 코드 탐색이나 검색에서 꽤 최적화된 경로를 찾을 만큼 똑똑한데, 이런 도구를 붙이면 검색 결과가 거의 항상 전체 세부사항이 아니라 포인터만 주기 때문에 지나치게 공격적으로 움직이는 경향이 있음
간단히 Pi로, 어느 정도 복잡한 프로젝트에서 전체 수집·검색 경로를 추적하게 해봤는데, codebase-memory-mcp는 85k/4.4k 입력·출력 토큰, 평소 설정은 67k/3.2k, 아무 도구도 없을 때는 80k/3.2k였음
결과 품질과 정보량은 같았고, 이 도구는 크진 않지만 오히려 나빠졌음
내 평소 설정은 AGENTS.md와 CLAUDE.md에 “PROJECT.md부터 읽어라” 한 줄만 넣는 것임 PROJECT.md에는 프로젝트 2~3줄 설명, 관련 파일과 한 줄 설명, 주의점, 그리고 “변경할 가치가 있으면 이 파일을 업데이트하라. 이 파일의 목적은 프로젝트의 대략적인 감을 주고, 필요하면 거기서 더 탐색하게 하는 것이다”라는 LLM용 문구만 둠

“에이전트형 AI는 이미 코드 탐색이나 검색에서 고도로 최적화된 경로를 찾을 만큼 똑똑하다”는 말은 내 경험과 다름
직장에서는 예전에 Augment Code를 썼고, 거기엔 미리 색인된 코드에 대해 자연어 질의에 답하는 MCP 비슷한 Context Engine이 있었음
이후 Claude Code로 바꿨는데, 이상하게도 범위 읽기 도구가 있는데도 자기 기억에 있는 줄 범위를 바탕으로 sed로 파일을 읽으려 함
그게 정말 고도로 최적화된 경로라는 뜻인지는 모르겠음

codebase-memory-mcp와 semble은 정확히 같은 것은 아니지만 흥미로운 비교라서, 확인할 작업 목록에 넣고 가능하면 벤치마크에 추가해보겠음
같은 비교를 semble로 해볼 기회가 있다면 정말 유용한 피드백이 될 것 같음. 이런 “실제” 시나리오는 벤치마크하거나 재현하기가 어렵기 때문임

흥미롭다. 나도 이 분야에서 작업 중이지만 접근은 달랐음
색인을 만드는 대신, 코드베이스와 일반 텍스트 전반에 대해 순위화와 코드 구조 인식을 붙인 더 똑똑한 grep을 만들었고, 대부분의 시간은 성능 문제를 다루는 데 썼기 때문에 매우 빠르게 동작함 https://github.com/boyter/cs와 비교 대상으로 추가해서 내가 묻는 종류의 질문에서 LLM들이 무엇을 선호하는지 봐야겠음
이것도 MCP를 제공하지만 검색용 색인은 만들지 않음. 기본 BM25가 아니라 코드 의미론적 변형을 쓰기 때문에 순위가 어떻게 나올지 궁금함
이 도구는 “인증은 어떻게 동작하나” 같은 질의에 더 잘 맞아 보이고, cs는 authenticate --only-declarations를 한 뒤 파일 내용, 즉 매치 위치가 코드인지 주석인지와 파일의 전체 복잡도에 따라 결과에 가중치를 줌
별표 눌러뒀고 지켜볼 예정임

이 도구가 AI용이라는 건 알지만, 새 코드베이스나 내 코드베이스를 탐색할 때 직접 써보는 데 더 관심이 감
뭔가를 리팩터링하려고 어디를 바꿔야 하는지 전체 윤곽을 보고 싶을 때 유용해 보임
LSP도 그런 일을 해주지만, 이 도구는 한 단계 더 나아갈 수 있을 것 같음

Pi와 GPT 5.5로 몇 가지 평가를 해봤음
RTK 켬 / headroom 켬 / 둘 다 켬 / 둘 다 끔을 테스트했고, 모두 표준 Pi 시스템 지시문을 사용했으며 AGENTS.md는 없었음
정확히 어떤 테스트였는지는 잊었지만, 사람들이 쓰는 표준 에이전트 평가 몇 개였고 내가 쓰는 언어인 Python 하나와 TypeScript 하나였음
철저한 테스트라거나 좋은 테스트였다고 주장하진 않음. 하루 정도 AGENTS.md와 Pi 시스템 프롬프트·도구 지시문을 조정했다면 더 나은 결과가 나왔을 수도 있음. 평가를 돌리며 배운 한 가지는 그런 미묘한 차이가 결과를 크게 바꿀 수 있다는 점임
하지만 둘 다 끈 경우가 명확히 더 좋았고, 3라운드 뒤 바로 테스트를 멈출 만큼 충분했음
문제는 컨텍스트 사용량은 줄어들 때도 있었지만, 완료까지의 턴 수가 늘어서 전체 대화 비용은 더 높아졌다는 것임
이런 도구를 공유하는 사람이 매우 많지만, 평가가 전혀 없거나 재현하기 수상할 정도로 어렵거나, 이 도구처럼 많은 벤치마크를 하면서도 틀린 것을 측정하는 경우가 많다는 걸 크게 의식하게 됨
이 도구가 grep보다 토큰을 덜 쓰는 것은 맞고 벤치마크도 그걸 증명하지만, 중요한 건 그게 아님. 중요한 건 에이전트가 이 도구를 써서 같은 품질의 작업을 더 빠르고 더 낮은 비용으로 해내는지임

지금 AI 업계 전반에 테스트 부족이 있음
이 도구만의 문제가 아니라, 코드베이스나 개발 흐름에 AI를 붙이는 모든 것의 문제임
AI 이전에도 “이게 얼마나 빠르고 잘 개발됐나”를 측정하는 테스트가 없었고, 지금도 추가하지 않았음

AI에서는 “할 수 있었기 때문에, 해야 하는지는 생각하지 않았다”가 매우 자주 벌어질 것 같음

실제 에이전트 벤치마크를 보고 싶음. 예를 들어 Claude Code나 Copilot CLI에서 grep을 제거하고 이 도구를 대신 넣는 식임
RTK와 여러 LSP 구현을 살펴봤는데, 모델들이 grep에 너무 강하게 강화학습되어 있어서 다른 형태의 결과를 신뢰하지 않고 계속 재시도하거나 다시 읽음
그래서 모델이 다른 도구 결과를 믿지 않기 때문에 토큰 절약분이 모두 사라짐

전역 CLAUDE.md(~/.Claude 아래)에 grep 대신 LSP를 쓰라고 적어뒀더니 그 뒤로는 이 문제가 없었음

Codex CLI는 RTK를 꽤 잘 돌림. 적어도 GPT 5.5 xhigh에서는 그랬음
다만 find의 특정 CLI 플래그 같은 걸 지원하지 않을 때, 명령의 전체 출력을 보내는 대신 오류 메시지를 내는 점이 거슬림
그러면 에이전트가 토큰을 낭비하며 재시도하거나, 더 나쁘게는 프롬프트 때문에 RTK 없이는 명령을 실행하면 안 된다고 겁먹고 아예 시도하지 않기도 함

우리도 이런 벤치마크에 관심이 있고, 모델이 더 쉽게 쓰도록 프롬프트와 설명 최적화와 함께 로드맵에 들어 있음
일화 수준이지만, 우리도 물론 이 도구를 직접 쓰고 있고 지금까지는 꽤 잘 동작함
Anthropic 모델들은 이 도구를 호출하고 결과를 신뢰하는 것처럼 보임

토큰 절약은 점점 더 중요해지고 있지만, 에이전트가 결과를 신뢰하고 검색을 멈추는지도 중요함
검색 출력만 볼 게 아니라 전체 에이전트 루프를 측정해야 함

적어도 Codex는 grep이 종종 너무 느리니 rg를 쓰라고 하면 말을 듣지만, RTK를 추가하면 RTK를 통해 grep을 써서 좀 짜증남

아이디어가 좋아 보여서 조금 만져봤음
테스트는 browsercode(https://github.com/browser-use/browsercode) 저장소에서 했고, 프롬프트는 “semble CLI만 사용해, Browsercode가 기본 OpenCode 도구 외에 에이전트에 제공하는 도구가 무엇인지 답하라. 도구 입력·출력의 정확한 스키마와, 무엇을 하고 어떻게 동작하는지 간단히 요약하라”였음
여기에 https://github.com/MinishLab/semble#bash-integration의 AGENTS.md 조각을 붙였음
Semble을 쓰지 않는 테스트에서는 같은 질문을 rg와 fd CLI만 사용하라고 바꿨음
두 경우 모두 Pi와 gpt-5.4 medium을 썼고, 나머지 설정은 매우 최소화했음. 실제로 한쪽은 rg와 fd만, 다른 한쪽은 semble만 썼는지도 확인했음
Semble 없이 모델 컨텍스트의 10.9%와 API 크레딧 $0.144를 썼고, Semble 사용 시 9.8%와 $0.172를 썼음
결과 답변도 거의 같아서 매우 근접했음
OpenCode 저장소에서도 한 번 더 테스트했는데, 질문은 “OPENCODE_EXPERIMENTAL_EXA 환경 변수가 1로 설정되는 지점부터 OpenCode 에이전트에 제공되는 시스템 프롬프트나 도구에 나타나는 결과까지 경로를 추적하라”였음
위와 같은 지시문과 문서를 포함했음
Semble이 아닌 버전이 조금 더 자세했고, 웹 검색 제공자로 Exa나 Parallel이 활성화되었는지에 따라 도구 호출 경로가 Exa를 호출하는지도 다뤘지만, 실제 질문에 대한 답은 두 버전 모두 정확했음
Semble 버전은 컨텍스트 14.7% / API 비용 $0.282, 비-Semble 버전은 19.0% / $0.352를 썼음
컨텍스트 효율 면에서는 분명 Semble의 승리였지만, 비-Semble 버전이 대략 두 배 빠르게 끝났다는 점은 주목할 만함
물론 그냥 내가 조금 만져본 정도라, 결과는 달라질 수 있음

“grep보다 토큰을 98% 적게 쓴다”는 말은, grep이 그렇게 낭비가 심해서 모델이 매번 98%의 쓸모없는 쓰레기를 읽고 있다는 뜻으로 믿으라는 건가?
이 주장이 대표성이 없거나, 모델에 줄 컨텍스트의 대부분을 버릴 때 뭔가 다른 걸 놓치고 있는 것 같음

98%는 grep 출력만이 아니라 grep+read 루프와 비교한 것임
에이전트가 낯선 코드베이스를 만나면 보통 먼저 cat file을 하거나 파일 전체를 읽음. 적어도 내 경험은 그랬음
에이전트가 안정적으로 grep -C N만 하고 거기서 멈추게 만들고 있다면 설정이 정말 궁금함. 내 생각엔 그 결과 품질이 유용한 컨텍스트로 쓰기에는 너무 낮기 때문임

Claude가 node_modules에서 잡힌 항목 때문에 수백 킬로바이트 출력을 읽는 문제가 있었음 ripgrep이 도움이 되니, 어떤 메모리 파일에 그걸 쓰라고 한 줄 추가하는 게 말이 됨

grep은 매칭되는 모든 줄을 출력함
LLM이 어떤 검색을 하면 잡음이 많이 나올 수 있고, 구체적으로 찾을 수 없어서 그런 검색을 해야 할 수도 있음 목표 지향 검색은 토큰 수를 줄일 수 있음
다만 이 비교는 필요한 부분만 받는 것과 코드베이스 전체를 읽는 것을 비교한 것 같음

피드백을 주자면, codex-cli가 MCP를 통해 이걸 호출할 때 멈춤 semble 프로세스도 좀비처럼 남아서 영원히 멈춰 있음. 이유는 모르겠고 로그에도 아무것도 없음
스킬을 통해 CLI 호출 방식으로 부르면 GPT 5.5가 ripgrep에 익숙한 것처럼 검색어를 엄청 많이 던지려고 함
이게 얼마나 효과적인지는 모르겠고, GitHub의 짧은 문서와 에이전트 지시문만으로는 무엇이 최적인지 명확하지 않음
마지막으로 bash용으로 설치할 때 GitHub 외부 연결 관련 오류도 몇 번 났음. 멈춤과 관련이 있는지는 모르겠음
추가로, 내 에이전트는 이어서 ripgrep도 쓰려고 해서 중복처럼 보임. 신뢰 문제가 있는 것처럼 행동함
더 자세한 에이전트 스킬 설명이 있으면 에이전트를 올바른 사용법으로 유도할 수 있을 것 같음

자세한 피드백 고마움
버그는 설정 세부사항과 함께 이슈를 열어줄 수 있으면 좋겠음. 이건 확실히 조사하고 고치고 싶은 부분임
여러 질의를 던지는 문제도 정말 좋은 피드백이고, 이런 일이 생기지 않도록 프롬프트와 지시문을 업데이트하고 관련 테스트도 추가해보겠음
설치 중 외부 연결 오류는 uv가 PyPI에서 의존성을 가져오면서 생긴 것 같고, 멈춤의 원인은 아닐 것임

좋아 보이는 아이디어임
관련된 문제도 하나 말하자면, 작은 코드베이스에서는 Claude가 그냥 전체 코드베이스를 한 번에 컨텍스트에 넣고 아주 적은 토큰으로 처리할 수 있는데도, 뭔가를 찾느라 시간을 많이 씀
괜찮은 우회법은 시작 훅으로 전체 디렉터리를 컨텍스트에 넣어버리는 것임
그러면 Claude가 매 작업마다 “어둠 속에서 더듬는” 구간을 건너뜀
더 큰 저장소에서 모델에 스텁이 있는 개요를 주는 훌륭한 프로젝트도 본 적이 있는데, 이름은 잊었음

맞는 말임. 에이전트는 자신이 보고 있는 것들, 예를 들어 파일 수나 파일 크기 같은 정보를 잘 모름
다만 작은 코드베이스라면 찾고 싶은 것도 찾기 쉬우므로, 검색이 여전히 비용 절감에 도움이 될 수 있음

이런 해법들의 더 큰 문제는, 대부분의 AI가 학습 덕분에 이미 grep과 검색을 아주 잘 쓴다는 것임
AI에게 새 도구를 건네면 그런 도구는 AI의 인지 능력을 일부 빼앗아 감
인간은 보통 이런 도구 사용법을 “학습”하겠지만, LLM의 학습은 고정되어 있고 이미 grep 같은 기존 도구에 매우 깊은 숙련도를 갖고 있음
예를 들어 AI는 이미 tree 같은 Linux 명령으로 코드베이스를 탐색할 줄 알고, 이것도 충분히 학습되어 있음
또 다른 문제는 이런 도구의 효용을 보여주는 예시는 만들기 쉽지만, 그런 도구가 유발하는 인지적 결손을 장기 실행에서 효용이 상쇄한다는 걸 실제로 증명하기는 어렵다는 것임
내 첫 직감으로는 장기 실행에서 배포 가능한 지능이 순손실이 되어, 에이전트가 기존 도구를 쓸 때보다 더 나빠질 것 같음
그 반대를 증명하는 건 사소하지 않은 문제지만, 어쩌면 도전해볼 만한 과제일 수 있음