Claude Code의 LSP는 토큰을 줄여줄까

처음엔 그냥 이렇게 생각했다. LSP가 붙으면 grep를 덜 돌게 되고, 코드 탐색이 더 정확해질 테니 토큰도 줄어들겠지. Claude Code에서 LSP 이야기가 자꾸 나오는 걸 보면서도 결국 기대한 건 그거였다.

문서와 changelog, 사용자 이슈를 조금만 봐도 왜 다들 LSP를 붙이려고 하는지는 금방 납득된다. 정의 위치를 바로 찾고, 참조를 따라가고, 타입 정보를 보고, diagnostics를 빠르게 받는 건 누구나 좋아 보일 수밖에 없다. 잘만 붙으면 텍스트 검색 위주의 탐색보다 훨씬 나을 것 같았다.

그런데 직접 비교해 보니 결과는 내가 처음 기대한 것과 꽤 달랐다. 적어도 내가 본 대규모 프로젝트와 Unity 코드베이스에서는, LSP = 더 빠르고 더 싸다는 식으로 간단히 정리되지 않았다.

처음 세운 가설

내 가설은 이랬다.

LSP가 붙으면 의미 기반 탐색이 가능해진다.
그러면 grep를 여러 번 돌리고 파일을 직접 읽는 횟수가 줄어든다.
결국 시간도 줄고, 토큰도 줄고, 보고서 정확도도 올라갈 것이다.

앞의 두 줄은 지금도 어느 정도 맞다고 생각한다. 문제는 마지막 줄이었다. 실제로는 정확도, 시간, 토큰이 한 방향으로 같이 움직이지 않았다.

어떻게 봤나

비교 대상은 아주 단순했다. 특정 함수를 중심으로 로직을 파악하고, 그 함수의 호출부를 추적해 보고서를 만드는 태스크를 여러 번 돌렸다. 이걸 서브에이전트를 병렬로 소환하는 방식으로 굴리면서, 각 실행의 보고서 정확도, 시간 소모량, 토큰 소모량을 같이 봤다.

여기서 제일 중요했던 건 함수의 caller 수였다. 결국 이 함수가 얼마나 많은 곳에서 불리는가가 결과를 크게 갈랐다.

호출부가 적을 때는 grep가 훨씬 낫다

호출부가 10개 미만인 태스크에서는 grep가 압도적으로 빨랐다. 실수도 거의 없었다. 이런 경우에는 굳이 LSP를 끌어오는 쪽이 오히려 돌아가는 길처럼 느껴졌다.

이유도 자연스럽다. 참조 수가 적으면 텍스트 기반 탐색만으로도 맥락이 금방 닫힌다. LSP 질의를 준비하고, 응답을 받고, 그 결과를 다시 모델이 해석하는 비용을 생각하면 그냥 grep가 더 짧게 끝난다.

여기서는 내가 처음 세운 가설이 오히려 틀렸다. 더 좋은 도구가 더 싼 도구가 되는 건 아니었다.

호출부가 많아질수록 grep는 갑자기 흔들린다

문제는 caller 수가 늘어날 때부터였다. 호출부가 10개를 넘기기 시작하면 grep의 정확도가 눈에 띄게 떨어졌다. 다른 클래스에 있는 동명의 함수를 잘못 잡거나, 텍스트상 비슷해 보이는 결과를 섞어 읽는 일이 생겼다.

이때부터 grep 보고서는 빠르긴 한데 점점 불안해진다. 특히 호출부가 90개 안팎까지 늘어난 태스크에서는 편차가 정말 컸다. 어떤 실행은 그럴듯하게 맞아 보이고, 어떤 실행은 거의 랜덤에 가까웠다. 겉으로 보기에는 보고서가 성립하는데, 실제 caller 집합은 틀린 경우도 있었다.

이 구간에서는 속도가 장점이 아니라 함정처럼 느껴졌다. 빨리 나오는데, 믿고 다음 판단으로 넘어가기가 어렵다.

LSP는 느리고 비싸지만, 정확도는 안정적이었다

LSP 쪽은 일관되게 느렸다. 그리고 grep보다 토큰도 더 먹었다. 적어도 내가 본 실험에서는 이 차이가 꽤 분명했다.

대신 정확도는 안정적이었다. 호출부 파악이라는 기준으로 보면, 내가 돌린 태스크들에서는 LSP 쪽에 오차가 없었다. caller 수가 늘어나도 결과가 무너지지 않았고, 동명의 함수 때문에 보고서가 비틀리는 문제도 없었다.

그래서 체감이 묘했다. 처음에는 LSP를 쓰면 효율이 좋아질 것이라고 생각했는데, 실제로는 LSP를 쓰면 결과 품질을 덜 의심하게 된다는 쪽이 더 맞았다. 토큰 절약 기능이라기보다 정확도 유지 기능에 가까웠다.

왜 이런 결과가 나왔을까

내가 내린 해석은 이 정도다.

참조 수가 적은 태스크는 원래 단순해서 grep로도 충분하다.
참조 수가 많아질수록 텍스트 기반 탐색은 이름 충돌과 맥락 오판에 약해진다.
LSP는 느리고 질의 비용도 들지만, 심볼과 참조 관계를 안정적으로 잡아 준다.

지금 내 느낌에 LSP의 장점은 항상 더 싸다가 아니라 복잡해질수록 덜 틀린다에 가깝다.

이건 생각보다 큰 차이다. 에이전트 코딩에서 중요한 게 항상 속도만은 아니기 때문이다. 빠른데 틀린 보고서가 계속 나오면, 그다음 단계에서 검증하고 되돌리는 비용이 더 커진다. 그 비용까지 생각하면 LSP의 느림이 완전히 손해라고만 보기도 어렵다.

지금 기준의 결론

그래서 지금 내 결론은 꽤 단순하다.

caller가 적고 맥락이 단순하면 grep가 낫다.
caller가 많고 참조 그래프가 커지면 LSP가 돈값을 한다.
다만 2026년 3월 20일 기준으로, LSP가 시간과 토큰까지 같이 줄여 준다고 기대하진 않는다.

정리하면 이렇다.

LSP는 항상 더 효율적인 기능이 아니라, grep의 정확도가 무너지는 구간에서 비로소 가치가 커지는 기능이다.

그래서 지금은 LSP를 기본값으로 보지 않는다. 토큰을 줄이기 위한 만능 해법으로도 보지 않는다. 대신 복잡한 참조 그래프를 다룰 때 정확도를 지키기 위한 도구로 본다. 내 기준에서는 이쪽이 훨씬 실제에 가까웠다.