# Claude Code에 네이티브 LSP 지원 기능 추가 > Clean Markdown view of GeekNews topic #25269. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25269](https://news.hada.io/topic?id=25269) - GeekNews Markdown: [https://news.hada.io/topic/25269.md](https://news.hada.io/topic/25269.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-23T10:33:11+09:00 - Updated: 2025-12-23T10:33:11+09:00 - Original source: [github.com/anthropics](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) - Points: 18 - Comments: 2 ## Summary **Claude Code**가 이제 **LSP(Language Server Protocol)** 를 네이티브로 지원하며, 터미널 환경에서도 IDE 수준의 코드 인텔리전스를 제공합니다. 이제 정의 이동, 참조 찾기, 호버 문서 표시가 가능해졌고, `/terminal-setup` 명령으로 Kitty·Alacritty·Zed·Warp 터미널을 손쉽게 설정할 수 있습니다. 또한 `/context` 출력이 출처별 그룹화와 토큰 사용량 기준 정렬로 정돈되어, 대화형 코딩 세션의 맥락 관리가 한층 명확해졌습니다. ## Topic Body - 터미널에서 실행되는 **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를 출처별로 그룹화**, 슬래시 명령 기준 정리, **토큰 사용량 기준 정렬** 제공 ## Comments ### Comment 48180 - Author: aqqnucs - Created: 2025-12-23T14:50:27+09:00 - Points: 1 serena 쓰고 있었는데 역시 빌트인이 맞죠 ### Comment 48173 - Author: neo - Created: 2025-12-23T10:33:11+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46355165) - JetBrains가 왜 **리팩토링 도구**를 AI 시스템에 통합하지 않았는지 이해가 안 됨 함수 이름 변경처럼 간단한 작업도 수백 개 파일을 편집하는 대신 훨씬 작은 컨텍스트로 처리할 수 있었을 텐데 아쉬움 LSP 지원은 좋은 출발이지만, 코드 **변형 기능**이 없으면 여전히 미흡함 JetBrains의 LSP 품질도 일반적인 것보다 낫지 않음 - 요즘 JetBrains가 좀 **방향을 잃은 느낌**임 커밋 모달을 없애고 요금제를 올린 뒤로 10년 넘게 써온 걸 옮길까 고민했음 최근의 실수 사례는 [이 블로그 글](https://blog.jetbrains.com/datagrip/2025/12/18/query-consoles-are-coming-back/)에서도 볼 수 있음 - 이건 전형적인 **혁신가의 딜레마** 같음 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](https://github.com/brian-yu/python-rope-refactor)를 연결하는 스킬을 직접 만들어봄 꽤 만족스러움 - 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 **플러그인 래퍼**로 감싸야 함 관련 문서는 [여기](https://code.claude.com/docs/en/plugins-reference)에 있음 - Anthropic의 **Claude Code UX**는 주요 AI 제품 중 최악임 단순히 텍스트를 복사해 붙여넣는 것도 불편하고, 사용자 피드백도 무시함 이런 상태라면 왜 ChatGPT 대신 이걸 써야 하는지 모르겠음 - 나는 오픈소스인 [OpenCode](https://opencode.ai/)를 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](https://backnotprop.com/blog/its-on-your-computer/) - IDE 안의 에이전트가 LSP에 접근할 수 있는지 궁금함 예를 들어 Zed는 MCP 서버가 없다면 LSP 정보를 활용하지 못함 - 내 에디터와 챗봇이 모두 터미널 안에 있어서 굳이 IDE로 옮기고 싶지 않음 데스크톱 앱의 **불완전한 UI**보다 CLI가 낫다고 느낌 - CLI의 장점은 특정 IDE에 **종속되지 않는 자유로움**임 - 최근 [내 글](https://hachyderm.io/@ed_blackburn/115747527216812176)에서도 말했듯, LLM을 비효율적으로 돌리느라 **토큰 낭비와 에너지 낭비**가 심함 LLM이 도구를 더 쉽게 사용할 수 있게 만드는 게 핵심임 이건 코딩뿐 아니라 모든 분야에 적용 가능한 원칙임 - 몇 년 후엔 지금의 **비효율적 도구 생태계**를 부끄럽게 돌아보게 될 것임 에너지, 물, 자원 낭비로 인한 환경 피해를 고려해야 함 - 이미 이런 문제를 해결하려는 시도가 있었음 예를 들어 [Serena](https://github.com/oraios/serena) 같은 프로젝트가 있음 - 내가 좋아하는 에이전트 **Crush**는 이미 LSP 지원을 하고 있음 다만 실제로 에이전트가 그 기능을 자주 사용하진 않음 [Crush GitHub 링크](https://github.com/charmbracelet/crush) - `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](https://github.com/valentjn/lsp-cli) 같은 CLI 프런트엔드가 있음 하지만 LLM이 전용 도구로 LSP를 사용하는 게 단순 쉘 명령보다 더 효율적임