검색 결과가 정확해도 도구는 실패한다 - grep과 LSP 실험으로 본 에이전트 인터페이스

TL;DR

• 도구의 검색 정확도와 에이전트의 작업 성공률은 다르다. 코드 위치만 돌려주면 에이전트가 맥락을 얻기 위해 파일을 반복해서 읽어야 한다.
• 같은 LSP 검색 결과에 주변 코드를 붙이자 이름 변경 실험의 pass@1이 0.67에서 0.83으로 높아지고 추가 파일 읽기는 15.2회에서 3.2회로 줄었다. 이 조건에서도 grep의 pass@1은 1.00이었다.
• 의미 기반 검색의 이점은 작업과 저장소에 따라 달랐다. 참조를 정확히 찾는 작업에는 도움이 되지만 주석·문자열까지 고치는 작업은 텍스트 검색이 필요할 수 있다.
• 소수 저장소와 모델을 사용한 예비 실험이다. LSP 전체의 우열이나 학습 데이터의 인과 효과를 입증한 결과는 아니며, 실제 작업 성공률을 유지한 상태에서 비용을 비교해야 한다.

Source

Grep beats LSP? Why coding agents ignore your fancier tools

발견 경로: GeekNews. 원문은 2026년 8월 12일에 발행됐고 GeekNews에는 2026년 9월 6일에 등록됐다.

Knowledge

정확한 위치만으로는 다음 행동을 결정하기 어렵다

코딩 에이전트에 의미 기반 검색 도구를 붙이면 불필요한 탐색이 줄어들 것이라고 기대하기 쉽다. Pengcheng Xu는 grep과 LSP 기반 코드 탐색을 비교했지만 검색 결과가 정밀하다는 사실만으로는 성공을 설명하기 어려웠다. 처음 사용한 LSP 도구는 파일 경로와 줄·열 위치를 반환했고 grep은 일치한 코드 줄을 바로 보여줬다. 에이전트가 다음 행동을 판단할 때 필요한 정보량부터 달랐던 셈이다.

위치만 받은 에이전트는 코드를 확인하려고 파일을 다시 열어야 했고 이 과정에서 호출과 토큰이 더 필요했다. 저자는 검색 백엔드를 바꾸지 않고 각 참조에 앞뒤 두 줄의 코드를 붙였다. Opus 4.8과 인덱스를 미리 준비한 pyright를 사용한 여러 파일의 이름 변경 실험에서 첫 시도 성공률인 pass@1은 0.67에서 0.83으로 높아졌으며 추가 파일 읽기는 평균 15.2회에서 3.2회로 줄었다. 다만 같은 표의 grep 성공률은 1.00이므로 이 결과를 LSP의 최종 승리로 해석해서는 안 된다.

어떤 대상을 빠짐없이 찾아야 하는가

grep은 문자열을 찾고 LSP 기반 탐색은 정의나 참조 같은 코드의 의미 관계를 찾는다. 함수 호출만 정확히 찾는 일과 이름이 들어간 모든 텍스트를 고치는 일은 검색 범위가 다르다. 이름 변경에는 주석, 문서 문자열, 설정값도 포함될 수 있지만 참조 탐색은 이런 텍스트를 원래 반환하지 않는다. 도구 선택에 앞서 작업이 요구하는 완전성의 범위를 정해야 한다.

실험에서도 에이전트의 선택은 작업에 따라 바뀌었다. 단순 위치 찾기에서는 의미 기반 도구를 거의 고르지 않았지만 모든 호출자를 찾는 작업에서는 더 자주 사용했다. 동일한 TypeScript라도 문자열 검색에 혼동이 적은 저장소에서는 의미 기반 탐색의 이득이 없었고 무관한 텍스트가 섞인 저장소에서는 정확도 개선이 나타났다. 언어 이름만 보고 도구를 고정하기보다 실제 검색의 오탐을 측정할 이유가 있다.

도구를 연결한 뒤의 전체 경로를 평가한다

이 결과를 에이전트 설계에 적용한다면 도구 목록에 새 기능을 추가한 시점에서 평가를 끝낼 수 없다. 실제로 그 도구를 호출하는지, 반환값을 읽고 바로 다음 판단을 내릴 수 있는지, 실패 후에는 어떻게 회복하는지까지 살펴봐야 한다. 경로와 식별자만 반환하는 인터페이스라면 근거가 되는 짧은 본문이나 주변 맥락을 함께 주는 실험부터 해볼 만하다. 이것은 원문에서 얻을 수 있는 설계 제안이며 모든 도구에 같은 출력 길이가 최적이라는 뜻은 아니다.

비용 비교에도 성공 조건이 필요하다. 작업을 끝내지 못한 실행이 일찍 중단되면 토큰이 적게 들었다는 이유로 효율적이라고 오판할 수 있다. 저자는 양쪽 모두 성공한 경우에 토큰을 비교했다고 설명한다. 실무에서도 완료율과 결과 품질을 먼저 맞춘 뒤 토큰, 추가 읽기, 지연을 함께 비교하는 편이 유용하다. 평가 단위에는 모델뿐 아니라 도구의 입력·출력과 실행 흐름도 포함된다.

예비 실험이 설명하는 범위

이 글은 소수의 Python·TypeScript 저장소와 Claude 모델 세 가지, 조건별 두세 번의 실행을 사용한 예비 실험이다. LSP의 참조·정의·문서 심벌 탐색을 시험했으며 전용 이름 변경 기능이나 진단, 코드 액션까지 비교한 것은 아니다. 따라서 특정 작업에서 grep이 앞섰다는 관찰을 LSP 전체가 불필요하다는 주장으로 넓힐 수 없다. 모델이 익숙한 도구 사용 경로를 학습했을 것이라는 설명 역시 학습 데이터를 조작해 확인한 인과 관계는 아니다.

원문은 AgentConnect의 제품 설계 배경도 설명하는 글이므로 제품 주장의 맥락을 함께 읽을 필요가 있다. 여기서 가져갈 만한 것은 자신의 도구 응답을 바꿔 시험할 수 있다는 점이다. 실제 작업 하나를 정하고 검색 백엔드는 유지한 채 반환 맥락만 바꾸면 도구 설계의 병목을 더 좁혀볼 수 있다. 기존 검색 경로를 남겨둔 상태에서 성공률과 비용을 비교하면 새 기능의 가치를 구체적으로 판단할 수 있다.

더 생각해보기

• 내가 연결한 MCP 도구는 다음 판단에 필요한 맥락을 주는가, 아니면 다시 조회해야 할 식별자만 주는가?
• 현재 평가에서 토큰이 줄어든 이유가 작업 효율 향상인지, 실패한 실행의 조기 종료인지 구분하고 있는가?
• 새 검색 도구의 효과를 모델 변경과 분리해 확인하려면 어떤 실제 작업과 비교 조건을 고정해야 할까?