▲

Claude Code에 네이티브 LSP 지원 기능 추가

 (github.com/anthropics)
14P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 터미널에서 실행되는 AI 기반 코딩 도구인 Claude Code가 최신버전에서 LSP (Language Server Protocol) 도구를 추가
  • 이를 통해 정의로 이동(go-to-definition), 참조 찾기(find references), 호버 시 문서 표시 같은 IDE 수준의 코드 인텔리전스 기능 제공
  • /terminal-setup 명령이 Kitty, Alacritty, Zed, Warp 터미널을 공식 지원
  • /theme 화면에서 Ctrl+T로 문법 하이라이팅 on/off 토글 가능
  • macOS에서 Alt 단축키가 동작하지 않는 경우를 대비한 터미널 설정 가이드 추가 및 macOS 단축키 표기를 alt 대신 opt로 통일하여 실제 키캡과 일치시킴
  • /context 명령 출력이 개선되어, skill과 agent를 출처별로 그룹화, 슬래시 명령 기준 정리, 토큰 사용량 기준 정렬 제공
▲
aqqnucs 23시간전  [-]

serena 쓰고 있었는데 역시 빌트인이 맞죠

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • JetBrains가 왜 리팩토링 도구를 AI 시스템에 통합하지 않았는지 이해가 안 됨
    함수 이름 변경처럼 간단한 작업도 수백 개 파일을 편집하는 대신 훨씬 작은 컨텍스트로 처리할 수 있었을 텐데 아쉬움
    LSP 지원은 좋은 출발이지만, 코드 변형 기능이 없으면 여전히 미흡함
    JetBrains의 LSP 품질도 일반적인 것보다 낫지 않음

    • 요즘 JetBrains가 좀 방향을 잃은 느낌임
      커밋 모달을 없애고 요금제를 올린 뒤로 10년 넘게 써온 걸 옮길까 고민했음
      최근의 실수 사례는 이 블로그 글에서도 볼 수 있음
    • 이건 전형적인 혁신가의 딜레마 같음
      JetBrains는 코드 의미를 가장 잘 이해하는 PSI 엔진을 갖고 있지만, 여전히 사람이 IDE를 직접 조작하는 패러다임에 묶여 있음
      Claude Code나 Cursor는 에디터를 AI가 자유롭게 다루는 캔버스로 보는데, JetBrains는 AI를 단순한 사이드바 플러그인으로 취급함
      내부 리팩토링 도구를 에이전트에 개방하지 않으면 VS Code로의 전환 마찰이 사라질 것임
    • JetBrains는 자체 AI인 Junie에 집착하지 말고, 이미 자리 잡은 도구들과 통합하는 데 집중해야 함
      그렇지 않으면 VS Code가 시장을 삼킬 것임
    • 자만심이 문제였음
      한때 큰 진입장벽을 갖고 있었지만, VS Code가 그걸 무너뜨림
      변화의 흐름을 전혀 예상하지 못하고 지금은 방향을 잃은 듯함
    • Microsoft도 비슷한 실수를 하고 있음
      Roslyn과 Copilot을 제대로 결합하지 못했음
      Roslyn analyzer는 단순한 린터가 아니라 코드 변환까지 가능한 강력한 도구인데, AI가 여전히 단순한 find/replace로 처리하는 걸 보면 답답함
      Roslyn 기반의 에이전트가 등장하면 대규모 코드베이스 작업 효율이 폭발적으로 오를 것임

  • 나는 Claude Code / Codex CLI + LSP 조합에 매우 긍정적임
    주말에 Codex를 써봤는데, 함수 이름 변경이나 심볼 이동 시 참조를 놓치는 게 불편해서 Python용 리팩터링 도구인 Rope를 연결하는 스킬을 직접 만들어봄
    꽤 만족스러움

    • OpenAI 엔지니어가 F2 키 대신 Copilot 버튼을 눌러서 참조 이름 변경을 실패한 셈임
      LSP 지원이 없는 게 정말 이상함
    • Codex 5.1 버전에서는 별로였는데, 지금은 Claude Code보다 나아졌는지 궁금함
    • OpenAI 내부에서도 이런 기능을 직접 만들어야 한다는 게 놀라움
      아직 이 분야에 할 일이 많음을 보여줌

  • 공식 문서가 부족해서 직접 알아본 결과를 공유함
    /plugin 명령으로 Claude Code의 플러그인 매니저를 열고, Discover 탭에서 lsp를 검색해 spacebar로 활성화 후 i로 설치하면 됨

    • 나도 처음에 Claude가 Go LSP 설치 여부를 물어봐서 놀랐음
      최근 변경 로그를 찾아보니 3일 전에 추가된 기능이었음
      아직은 실험적이라 비활성화해둠
    • 최신 버전에서도 mcp 검색 시 아무것도 안 나옴
      기능이 아직 미완성 단계로 보임
      향후 Claude가 자동으로 LSP를 인식하도록 개선되길 바람
    • 커스텀 LSP를 추가하려면 Claude Code 플러그인 래퍼로 감싸야 함
      관련 문서는 여기에 있음

  • Anthropic의 Claude Code UX는 주요 AI 제품 중 최악임
    단순히 텍스트를 복사해 붙여넣는 것도 불편하고, 사용자 피드백도 무시함
    이런 상태라면 왜 ChatGPT 대신 이걸 써야 하는지 모르겠음

  • 나는 오픈소스인 OpenCode를 6개월째 사용 중인데, 이미 이런 기능을 제공하고 있었음
    폐쇄형 소프트웨어의 느린 진전이 놀라움
    Claude나 Copilot 구독과 함께 사용할 수 있어서 추천함

    • 오픈소스와 프로바이더 독립성을 선호해서 OpenCode를 좋아하려 했지만, 실제로는 Claude Code가 더 안정적이었음
      OpenCode는 승인 대기 중 CPU 100% 사용, 팝오버로 인한 오작동 등 성능 문제가 있었음
      그래도 Claude Code에도 스크롤 시 깜빡임 같은 버그가 있음
    • 나는 OpenCode를 제대로 활용하지 못함
      Claude Code는 즉시 좋은 결과를 주는데, OpenCode는 모델 연결도 어렵고 효율이 낮음
      아마 Claude Code의 프롬프트 튜닝이 오래된 덕분일 것임
    • 오픈소스는 의사결정 구조가 단순해서 빠르게 움직일 수 있음
      여러 이해관계자 설득이나 스프린트 조정에 시간을 낭비하지 않음
    • OpenCode의 설정 경험은 다른 CLI 도구 중 가장 간단하고 직관적임
      다만 자잘한 버그와 크래시가 종종 발생함
    • OpenCode의 개발 속도는 매우 빠름
      누가 아침에 AGI를 발표하면, 저녁엔 이미 통합해둘 정도임
      나도 여러 도구를 오가며 테스트하지만 OpenCode는 꾸준히 발전 중임

  • CLI 형태의 도구에 열광하는 게 이상하게 느껴짐
    IDE 기반 에이전트는 이미 이런 기능을 기본 제공하는데, 굳이 터미널에서 diff나 LSP를 구현하는 게 효율적인가 의문임
    Cursor는 이미 이런 기능을 오래전부터 지원함

    • LSP는 원래 하나의 서버를 여러 클라이언트가 공유하도록 설계됨
      CLI도 LSP 서버에 연결하는 작은 클라이언트를 만들면 충분함
      IDE만 LSP의 혜택을 독점할 이유는 없음
    • 비개발자도 Claude Code CLI를 더 자연스럽게 느낀다고 함
      터미널은 단순히 코드 편집이 아니라 컴퓨터 전체를 오케스트레이션하는 공간임
      kubectl이 GUI로 진화하지 않은 이유와 비슷함
      관련 글: It's on your computer
    • IDE 안의 에이전트가 LSP에 접근할 수 있는지 궁금함
      예를 들어 Zed는 MCP 서버가 없다면 LSP 정보를 활용하지 못함
    • 내 에디터와 챗봇이 모두 터미널 안에 있어서 굳이 IDE로 옮기고 싶지 않음
      데스크톱 앱의 불완전한 UI보다 CLI가 낫다고 느낌
    • CLI의 장점은 특정 IDE에 종속되지 않는 자유로움임

  • 최근 내 글에서도 말했듯, LLM을 비효율적으로 돌리느라 토큰 낭비와 에너지 낭비가 심함
    LLM이 도구를 더 쉽게 사용할 수 있게 만드는 게 핵심임
    이건 코딩뿐 아니라 모든 분야에 적용 가능한 원칙임

    • 몇 년 후엔 지금의 비효율적 도구 생태계를 부끄럽게 돌아보게 될 것임
      에너지, 물, 자원 낭비로 인한 환경 피해를 고려해야 함
    • 이미 이런 문제를 해결하려는 시도가 있었음
      예를 들어 Serena 같은 프로젝트가 있음

  • 내가 좋아하는 에이전트 Crush는 이미 LSP 지원을 하고 있음
    다만 실제로 에이전트가 그 기능을 자주 사용하진 않음
    Crush GitHub 링크

    • AGENT.md에 설치된 LSP 서버를 명시해도 차이가 없었는지 궁금함

  • 아직 LSP가 실제로 사용되는 사례를 보지 못했음
    Opus 4.5는 QA 타이밍이 안정적이고, 린트 체크도 IDE 밖에서 잘 작동함
    정의가 깊숙이 숨겨진 경우엔 LSP가 유용할 수 있음
    Claude가 제공하는 LSP 기능 목록은 다음과 같음

    • goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls 등

  • LSP는 쉘 명령어 형태의 API를 제공해야 함
    그러면 LLM 통합이 쉬워지고, 사람에게도 유용할 것임

    • 이미 lsp-cli 같은 CLI 프런트엔드가 있음
      하지만 LLM이 전용 도구로 LSP를 사용하는 게 단순 쉘 명령보다 더 효율적임
답변달기