Grep이 LSP를 이긴다? 코딩 에이전트가 고급 도구를 무시하는 이유

TL;DR Highlight

LSP 결과에 소스 두 줄을 붙이자 rename 성공률이 0.67→0.83으로 올랐다

Who Should Read

코딩 에이전트에 LSP·MCP 같은 새 코드 탐색 도구를 붙였는데 에이전트가 잘 안 써서 고민인 개발자

Core Mechanics

에이전트는 웬만하면 grep을 고른다
- 단순 코드 위치 찾기에서 세 모델이 둘 다 쓸 수 있을 때 의미 기반(LSP) 도구를 고른 비율은 0~6%였다.
- 의미 기반 경로를 먼저 쓰게 강제하자 성공률이 100%에서 89%로 떨어졌다.
호출 전부 찾기에선 LSP를 절반쯤 쓴다
- 모든 호출처를 찾아야 하는 reference-completeness 작업에서는 의미 기반 도구 선택 비율이 45~57%였다.
- 정밀도는 grep 0.76 대비 LSP 1.00이었지만 재현율(recall)은 양쪽 모두 약 0.66이었다.
grep이 지저분한 레포에서만 LSP가 이득이다
- remeda는 grep 정밀도 1.00이라 LSP가 F1 변화 없이 토큰만 16% 더 썼다.
- hono는 grep 정밀도 0.51이라 LSP가 F1 +0.246, 토큰 12% 절감이었다.
- 같은 TypeScript인데 결과가 반대라서, 정적 타입 여부보다 grep의 오탐 수가 기준이다.
LSP 결과에 소스 두 줄을 붙였더니 달라졌다
- 처음엔 파일·줄·열 위치만 돌려줬고, 에이전트가 결과를 보려면 파일을 따로 열어야 했다.
- 참조 앞뒤 2줄 소스를 붙이자 multi-file rename pass@1이 0.67에서 0.83으로 올랐다.
- 후속 파일 읽기는 에피소드당 15.2회에서 3.2회로 줄어 grep의 4.3회보다 적었다.

Community Reactions

새 도구는 에이전트에게 물어보며 찾는다는 경험
- Claude Code 작업을 지켜본 뒤 "어떤 도구가 있었으면 더 쉬웠겠냐"고 물어 fzf 같은 도구를 알게 됐다는 경험담이 있었다.
- 그렇게 만든 Python CLI로 데이터를 Parquet 변환 후 DuckDB로 조회해 분석 시간이 크게 줄었다고 한다.
희소 AST 출력 도구가 효과 있었다는 경험
- 함수 본문 없이 타입과 함수 시그니처만 보여주는 도구를 skill로 설치하면 탐색 시간과 토큰이 크게 줄었다는 경험이 있었다.
- 같은 도구의 편집 기능은 모델이 학습 때 익힌 흔한 편집 도구 쪽으로 쏠려 잘 안 먹혔다고 한다.
실험 조건에 의문을 제기하는 의견
- 저자가 자체 하니스를 썼으니 LSP를 직접 지원하는 Claude Code로도 확인해야 한다는 의견이 있었다.
- 토큰 효율만 봤고, 토큰 과금을 안 쓰는 사람에겐 난이도·품질 지표가 더 중요하다는 의견도 있었다.
- Claude Code의 LSP/pyright 관련 이슈가 많아 grep이 더 안정적으로 보일 수 있다는 의견도 나왔다.
LSP를 쓰게 만드는 방법에 대한 경험
- LSP를 더 자주 쓰라고 지시하는 SKILL이 잘 통했다는 경험이 있었다.
- Serena를 MCP로 쓰면 Claude에 LSP 사용을 상기시키는 훅이 설치돼 잘 된다는 경험도 있었다.
- 반대로 Claude가 LSP를 거의 안 쓴다는 경험도 있었다.

How to Apply

에이전트가 새 도구를 실제로 부르는지 세기
- 오늘 쓰는 에이전트 로그에서 LSP·MCP 도구와 grep의 호출 횟수를 작업 유형별로 센다.
- 도구가 켜져 있어도 호출률이 0에 가까우면 도구 설명과 결과 형태부터 손본다.
도구 응답에 path:line:content 형태로 주변 코드 붙이기
- 위치만 돌려주는 커스텀 도구나 MCP 서버는 각 결과에 앞뒤 2줄 소스를 같이 넣는다.
- 바꾼 뒤 후속 파일 읽기 횟수와 성공률을 전후 비교한다.
레포 노이즈를 보고 검색 도구를 라우팅하기
- 자주 쓰는 식별자로 grep을 돌려 오탐 비율을 먼저 본다.
- 오탐이 많은 레포에만 의미 기반 탐색을 켜고, 깨끗한 레포는 grep만 쓴다.
grep 폴백을 항상 남기고 같은 정확도로 비교하기
- rename처럼 주석·문자열까지 고쳐야 하는 작업에는 grep 경로를 열어 둔다.
- 새 도구는 성공률이 같은 조건에서만 토큰을 비교한다.

Try It

복사해서 바로 해보기

# Claude Code 또는 Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 도구 결과 형태 점검)

나는 코딩 에이전트용 도구를 만들고 있다. 아래는 내 도구가 에이전트에게 돌려주는 응답 예시다.

{{도구 응답 예시 (JSON 또는 텍스트)}}

다음 기준으로 이 응답을 점검해 줘.
1. 에이전트가 파일을 따로 열지 않고도 각 결과의 관련성을 판단할 수 있는가?
2. grep처럼 path:line:content 한 줄 형태로 바꾸면 어떻게 되는가? 앞뒤 2줄 소스를 붙인 개선안을 보여 줘.
3. 이 도구가 놓치는 결과(주석, 문자열, 설정 파일)는 무엇이고, 그럴 때 grep으로 폴백하게 하려면 도구 설명에 뭘 써야 하는가?

이어서 해 볼 것: 개선안으로 같은 작업 5개를 돌려 후속 파일 읽기 횟수를 전후 비교해 봐.

Terminology

LSP (Language Server Protocol)에디터가 "정의로 이동", "참조 찾기" 같은 코드 이해 기능을 언어 서버에 물어보는 표준 규약이다. 텍스트 검색이 아니라 코드 구조를 아는 내비게이션이다.

하니스(harness)모델 주변의 지시문, 도구, 입력 스키마, 결과 형태, 루프를 합친 실행 환경이다. 같은 엔진도 차체가 다르면 다르게 달리는 것과 비슷하다.

pass@1첫 시도에서 작업을 성공하는 비율이다.

F1정밀도(맞게 찾은 비율)와 재현율(전체 중 찾은 비율)을 합친 점수다. 변화가 없으면 검색 품질이 안 움직인 것이다.

재현율(recall)실제 호출처 중 에이전트가 끝내 찾아낸 비율이다. 도구가 깨끗해도 에이전트가 일찍 멈추면 안 오른다.