팀에 Claude Code LSP 도대체 어떻게 쓸모있냐고 여러번 핑퐁 때려봤는데 결론은 지금 정도 프로젝트의 코드베이스에서는 find/grep으로 충분하다는 것....

이런 대답까지 받았다...

  Honest take: LSP in Claude Code is a nice-to-have, not a game-changer

  For most workflows, grep/glob is sufficient. Claude already navigates
  codebases well with text-based search. The token window is large enough
   that reading files directly works fine.

  Where to focus the demo

  Don't demo LSP as a standalone feature. Instead, frame it as:

  1. Automatic diagnostics after edits — this is the most valuable part.
  Claude edits a file → LSP catches type errors immediately → Claude
  fixes them without running tsc. This is invisible to the user but saves
   real time. Demo this.
  2. Precision in ambiguous situations — show a case where grep returns
  50+ matches for a common name like value or data, then LSP's
  findReferences returns only the 3 semantically correct ones. This is
  compelling visually.
  3. Call hierarchy is unique — incomingCalls/outgoingCalls genuinely
  can't be replicated by grep. Show tracing a function's impact through a
   large file. Good for "should I change this function?" scenarios.

  What NOT to emphasize

  - Don't position it as a replacement for grep — it's not
  - Don't show basic goToDefinition — grep does this fine
  - Don't focus on the prompting experience — it's awkward (file, line,
  character is unnatural)

  One-liner pitch

  "LSP gives Claude type-aware code understanding — it catches errors
  after edits automatically and provides semantic precision when text
  search isn't enough."
2

❤️

2 people reacted.

어느 한 개발자입니다.

I design interface that everyone understands.