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

Claude 모델 3종의 코드 탐색·편집 실험에서 단순 위치 찾기의 의미 기반 도구 호출 비중은 0~6% 에 그쳤고, 이를 먼저 쓰도록 강제하자 해당 실험군의 성공률이 100%에서 89%로 떨어짐 검색 정확도만큼 반환하는 맥락과 출력 형식도 중요함: LSP 결과에 소스 코드를 넣자 다중 파일 이름 변경의 첫 시도 성공률이 0.67에서 0.83으로 높아지고, 후속 파일 읽기는 15.2회에서 3.2회로 줄어듦 LSP의 이점은 작업과 코드베이스에 따라 달랐음: 전체 호출자 찾기에서는 정밀도가 0.76에서 1.00으로 높아졌지만 재현율은 두 방식 모두 약 0.66이었고, 주석·문자열까지 수정하는 작업에는 grep의 넓은 검색 범위가 유리했음 다만 소규모 예비 실험이므로 LSP 전체에 일반화할 수 없음: textDocument/rename, 진단, 코드 액션은 시험하지 않았으며, 학습된 익숙한 도구 사용 패턴 때문에 grep을 선호한다는 해석도 가설에 머무름 새 도구는 모델과 하네스를 함께 평가해야 함: 같은 성공 수준에서 토큰 사용량과 실제 도구 선택률을 비교하고, 다음 판단에 필요한 맥락과 기존 도구로 돌아갈 대체 경로를 제공해야 함 비교 대상과 실험 범위 grep은 일치하는 텍스트를 검색하고, 실험에 사용한 LSP 기반 도구는 참조·정의·문서 심벌을 통한 의미 기반 탐색을 수행함 의미 기반 탐색은 실제 함수 호출과 주석에 등장하는 같은 단어를 구분할 수 있음 예비 실험은 Opus 4.8, Sonnet 4.6, Haiku 4.5와 여러 Python·TypeScript 저장소를 대상으로 코드 위치 찾기·전체 호출자 찾기·편집 작업을 비교함 토큰 사용량은 두 방식이 모두 성공한 경우에만 비교함 실패한 실행이 일찍 종료됐다는 이유만으로 효율적으로 보이는 평가 오류를 피하기 위한 조건임 작업과 코드베이스에 따라 달라진 도구 선택 단순 코드 위치 찾기에서 의미 기반 도구 호출 비중은 Opus 4.8이 0%, Sonnet 4.6이 4%, Haiku 4.5가 6%에 그침 의미 기반 탐색을 먼저 쓰도록 강제한 실험군에서는 성공률이 100%에서 89%로 하락함 다중 파일 이름 변경에서도 Opus 4.8의 의미 기반 도구 호출 비중은 3%였음 모든 호출자를 찾는 참조 완전성 작업에서는 의미 기반 도구 호출 비중이 각각 45%, 50%, 57%로 높아짐 LSP 기반 탐색은 거짓 일치를 제거해 정밀도 1.00을 기록했고, grep은 0....