Claude 3종(Opus 4.8·Sonnet 4.6·Haiku 4.5)을 비교한 소규모 실험에서, 코드 구조를 이해하는 LSP 도구를 줘도 단순 위치 찾기엔 대부분 grep을 썼다(의미 도구 호출 비중 0~6%). LSP를 먼저 쓰도록 강제하면 성공률이 100%에서 89%로 떨어졌다. 반면 위치만 반환하던 LSP 응답에 소스 코드를 함께 넣자 다중 파일 이름변경 첫 시도 성공률이 67%에서 83%로 오르고 후속 파일 읽기가 15.2회에서 3.2회로 줄었다.
실험은 Opus 4.8·Sonnet 4.6·Haiku 4.5와 여러 Python·TypeScript 저장소를 대상으로 위치 찾기, 전체 호출자 찾기, 편집 작업을 비교했다. 단순 위치 찾기에서 의미 기반 LSP 호출 비중은 Opus 0%, Sonnet 4%, Haiku 6%에 그쳤고, LSP를 강제한 실험군은 성공률이 100%에서 89%로 하락했다. 반대로 모든 호출자를 찾는 참조 완전성 작업에서는 LSP가 주석·문자열의 가짜 일치를 걸러 정밀도 1.00을 기록(grep 0.76)해 작업에 따라 이점이 갈렸다.
핵심은 검색 정확도보다 '결과를 바로 쓸 수 있는가'였다. 초기 LSP 도구는 파일 경로·행·열만 반환해 코드를 보려면 파일을 또 열어야 했고, 이 탓에 이름변경 첫 성공률 0.67·후속 읽기 15.2회에 머물렀다. 백엔드는 그대로 두고 응답에 소스 텍스트만 덧붙이자 성공률 0.83·후속 읽기 3.2회로 개선됐다. 저장소별로도 grep 정밀도가 낮은 hono에서는 LSP가 F1을 0.246 올리고 토큰을 12% 줄인 반면, grep 정밀도 1.00인 remeda에서는 개선 없이 토큰만 16% 늘어, 새 도구는 '제공 여부'가 아니라 실제 사용률·맥락·성공률·토큰을 전체 실행 흐름에서 평가해야 함을 보여준다.