1. 개요
Language Server Protocol, LSPIDE상에서 다양한 프로그래밍 언어들에 대한 개발 편의 기능을 보편적으로 구현하기 위해 탄생한 프로토콜. 여기서의 개발 편의 기능에는 포맷팅, 자동 완성, 수정 제안, 구문 강조 등이 포함된다.
LSP등장 이전에 흔히 IDE에서 제공되는 문법 검사, 구문 강조 등의 기능은 각 IDE가 자체적으로 구현할 몫이었다. 다만 이는 효율적이지 못한 것이, 한 언어의 명세는 하나인데도 이에 따른 IDE의 구현이 양립할 수 밖에 없었다. 또한 새로운 언어가 탄생했을때, 이에 대한 자동 완성 등의 편의기능이 실사용 수준으로 정착하기까지의 기간 또한 길었다.
이를 해결하기 위해 언어에 대한 처리를 각 IDE에서 구현하는 것이 아닌, 특정 언어의 종속적인 기능들만 처리하는 '언어 서버'의 개념으로 분리하여 구현하고, 서로 일정한 프로토콜을 통해 상호작용하도록 하였다. 이를 통해 IDE에서의 개발 부담과 기술 양립을 감소시키고, 개발 편의기능을 다양한 환경에서 보편적으로 사용할 수 있게 되었다.
2. 유래와 역사
LSP는 Visual Studio Code의 개발 과정에서 탄생했다.2020년대에는 LSP가 빠르게 표준으로 자리잡아 다양한 IDE 및 기업에서 채용되었다.
3. 주요 구현체
3.1. 서버 구현체
확장 시스템이 있는 개발환경이라면 확장 단위로 사용할 수도 있으나, Neovim이나 Zed, Helix 등 LSP 설정을 유저에게 좀더 직접적으로 드러내는 환경들도 많다.3.1.1. 문서가 존재하는 구현체
- C/C++
- Python - 정적 타이핑 관련 표준과 툴링이 이것저것 범람하는 현 Python 생태계 특성상 LSP 구현체도 유독 많은 편이다. 아래 문서가 존재하지 않는 구현체 목록도 참고하자.
3.1.2. 기타
- TypeScript(JavaScript)
- typescript-language-server - 기본적으로 Microsoft의 독자 프로토콜을 사용하는 TSServer를 LSP 프로토콜을 지원하도록 래핑한 구현체. TSServer 프로토콜 자체는 LSP와 호환이 안 되기 때문에 Visual Studio Code에서는 TSServer를 직접 사용하고, 그 외의 환경에서는 주로 tsls가 쓰인다.
- vtsls - 단순히 TSServer가 아닌 vscode의 내장 TypeScript 지원 확장의 기능까지 래핑한 구현으로, 결과적으로 마이크로소프트 프로토콜 대신 LSP 프로토콜만 사용해서 vscode 수준의 TypeScript 지원을 추가할 수 있다.
- Python
- basedpyright - 상술한 Microsoft의 Pyright를 포크해 일부 개선한 구현체로, 똑같이 Pyright를 기반으로 구현되었으나 클로즈드 소스인 Microsoft의 Pylance 확장과 유사한 기능을 제공하는 등의 시도를 하고 있다.
- jedi-language-server - jedi 라이브러리를 기반으로 하는 LSP 구현체.
- Zuban - jedi를 개발한 개발자가 현재 개발중인 Rust 기반 LSP 구현체이다.
- palantir/python-language-server - jedi 기반 LSP 구현체.
- python-lsp/python-lsp-server - 위 palantir/python-language-server를 포크해 유지보수하는 프로젝트이다. 현재 pylsp라 하면 보통 이쪽을 가리킨다.
- python-lsp/pylsp-mypy - mypy 타입 채커를 사용하는 pylsp 확장.
- Pylyzer# - Rust로 제작된 LSP 구현체.
- Pyre(저장소) - 메타 플랫폼즈에서 OCaml로 개발한 타입 체커 및 LSP 구현체. 현재는 저장소에서 Pyrefly 사용을 권하고 있다.
- Pyrefly - 메타에서 Rust로 개발 중인 또다른 LSP 구현체. 대표적인 특징으로, 타입 체커 및 추론 로직이 정적 타입 언어들과 비교될 정도로 굉장히 aggresive하고 좁은 편이다.#
- Rust
- RLS - 현재는 후술할 RA에 의해 deprecated되었다.
- rust-analyzer - RLS가 실패한 이후 개발된 서드파티 구현체로, 워낙 뛰어나 공식인 RLS보다 널리 쓰이다가 2022년 2월부터 공식 rust 프로젝트로 편입되었으며, 현재는 rustup component로 관리할 수 있다.# Rust 커뮤니티에서 주로 RA라 불린다.
- Lua
- Lua Language Serverrepo - 흔히 sumneko luals라고 불리는 구현체. 2023년 2월 경
sumneko/lua-language-server에서LuaLS/lua-language-server로 조직을 변경했다. #1874 - Nix
- rnix-lsp - 가장 오래된 구현체 중 하나. 2021년 메인테이너인 jD91mZM2가 사망하였고,# 그 후로 아카이브되었다.
- nil - 자주 쓰이는 구현체 중 하나. nixd에 비해 설정할 게 적고 구현된 LSP 기능 범위가 넓은 편이다.
- nixd - 비교적 최근인 2023년부터 개발되기 시작한# 구현체. nix 유저들 평가는 대체로 좋은 편이나,## 코드 액션#466# 등 미구현된 중요 기능이 일부 있다.
- Haskell
- Kotlin
- fwcd/kotlin-language-server - 서드파티 구현체. JetBrains 특성상 공식 LSP 구현체가 없었기 때문에 vscode 등에서 Kotlin을 사용하려면 이런 프로젝트를 사용해야 했다. 공식 LSP가 나온 후로는 개발이 중단되었다.
- kotlin-lsp - 마침내 2025년 5월 KotlinConf 2025에서 공식 LSP 구현체가 공개되었다.#
- Astro
- Typst
- Prisma
- Ruby
- Solargraph - 현재 가장 지원 범위가 넓은 구현체 중 하나.
- Shopify/ruby-lsp - Shopify가 개발한 구현체.
- Bash
- bash-language-server - Tree-sitter bash 파서를 사용한다.
- Tailwind CSS
- Zig
- TOML
- jq
- 기타
- typos-lsp - 맞춤법 검사 구현용
- Wakatime
- mrnossiom/wakatime-ls - 현재 안정 확장 시스템이 없는 Helix에 wakatime 기능을 지원하기 위해 만든 구현체.
- wakatime/zed-wakatime/wakatime-ls - Zed 플러그인용으로 개발된 wakatime 구현체.
- estin/simple-completion-language-server - Helix에 버퍼 내 단어 자동완성 기능 구현용으로 개발된 구현체.
- @github/copilot-language-server - GitHub Copilot의 LSP 기반 wrapper. Helix 같이 자체 플러그인 시스템이 없는 환경에선 거의 유일한 코파일럿 사용 방법이다.