더 좋은 도구를 붙였는데 에이전트가 쓰지 않았다

결론부터. 도구를 붙였다는 사실은 그 도구가 쓰인다는 뜻이 아니다. 에이전트 도구를 설계할 때 성능만큼 중요한 게 출력 형식이고, 그것보다 먼저 확인해야 할 건 실제 채택률이다.

코딩 에이전트에서 grep과 LSP를 비교한 실험 결과가 그걸 정면으로 보여준다.

무슨 결과가 나왔나

LSP(Language Server Protocol)는 코드 구조를 이해하는 정교한 도구다. 단순 텍스트 검색인 grep보다 당연히 나을 것 같다. 실제로는 이랬다.

• 기본적인 위치 찾기에서 Opus 4.8은 의미 기반 검색을 0% 사용했다. 전부 grep을 골랐다
• LSP를 먼저 쓰도록 강제하자 성공률이 100%에서 89%로 떨어졌다
• 다만 "모든 참조 찾기" 같은 작업에서는 LSP 채택률이 45~57%로 올라갔다. 작업 종류에 따라 선택이 갈린다

레포지토리에 따라서도 갈렸다. remeda(TypeScript)는 grep 정밀도가 1.00이라 LSP를 쓰면 토큰만 16% 더 썼다. 반면 hono는 grep 정밀도가 0.51이라 LSP가 F1을 0.246 올리면서 토큰은 12% 줄였다.

진짜 흥미로운 건 출력 형식이었다

LSP 결과에 줄 번호만이 아니라 소스 코드 맥락을 함께 넣자 숫자가 이렇게 바뀌었다.

• 다중 파일 이름 변경 성공률: 67% → 83%
• 이후 파일 읽기 횟수: 15.2회 → 3.2회

도구 자체는 그대로다. 응답에 무엇을 담느냐만 바꿨는데 결과가 달라졌다. 위치만 돌려주면 에이전트는 그 위치를 이해하려고 파일을 다시 읽어야 한다. 그 왕복이 전부 비용이다.

원문의 표현을 빌리면 이렇다.

결과는 다음 판단에 충분한 맥락을 담고 있어야 한다. 에이전트 능력 = 모델 × 하네스.

출처: grep이 LSP를 이긴다고? 코딩 에이전트가 더 정교한 도구를 무시하는 이유

1인 개발자용으로 정리하면

혼자 에이전트를 붙여 쓰는 입장에서 가져갈 건 네 가지다.

채택률을 측정한다. 도구를 등록했다고 쓰이는 게 아니다. 사용 가능한 것과 실제로 선택되는 것은 다른 지표다. 로그에서 호출 횟수를 세보면 안 쓰이는 도구가 생각보다 많다.

출력 스키마를 도구 자체만큼 신경 쓴다. 응답이 다음 행동을 결정할 만큼의 맥락을 담고 있는지가 핵심이다. ID나 좌표만 돌려주는 도구는 반드시 추가 조회를 유발한다.

기존 도구를 치우지 않는다. 새 도구가 더 정교하다고 옛것을 없애면 폴백이 사라진다. grep과 LSP는 경쟁 관계가 아니라 다른 문제를 푸는 도구다.

벤치마크를 도구 단위로 하지 않는다. 도구만 떼어 재면 LSP가 항상 이긴다. 에이전트 루프 전체에서 재야 토큰과 왕복 비용이 드러난다.

덧붙이면

이 결과가 불편한 이유는, 우리가 보통 반대로 하기 때문이다. 좋아 보이는 도구를 붙이고, 붙였으니 됐다고 생각하고, 실제로 쓰이는지는 안 본다.

붙이는 건 30분이고 쓰이게 만드는 건 그 다음 일이다.