LSP & Tree-sitter 생태계 2026 — ast-grep / Biome / Helix / Zed / Neovim Treesitter / 언어별 LSP 심층 가이드

프롤로그 — 코드 도구의 양대 표준

2010년대의 에디터 전쟁은 단순했다. "어떤 앱을 쓰느냐" 가 거의 모든 것을 결정했다. VS Code인가, JetBrains인가, Vim인가, Emacs인가. 각자 자기만의 자동완성·정의 이동·리팩토링·문법 강조를 따로 구현했고, 새 언어가 나오면 에디터 x 언어 만큼의 작업이 매번 필요했다.

2026년의 그림은 완전히 다르다. 에디터·IDE의 진짜 무게중심은 두 개의 프로토콜·라이브러리로 옮겨갔다.

지난 10년의 함의는 분명하다. 에디터를 만드는 것보다, 표준에 붙는 것이 압도적으로 싸다. 그래서 Helix와 Zed처럼 새로 등장한 에디터들은 처음부터 LSP + Tree-sitter를 빌트인으로 짠다. Neovim은 0.5부터 LSP 클라이언트를 코어에 내장했고, VS Code는 처음부터 LSP의 레퍼런스 클라이언트였다.

그리고 이 두 표준 위에 새로운 생태계가 폭발적으로 자라고 있다 — ast-grep(Tree-sitter 기반 구조 검색·리라이트), BiomeJS(Rust로 다시 짠 JS 툴체인), Marksman(Markdown LSP), Semgrep / CodeQL(보안·정책 검색), Comby(언어 중립 리라이트). 이 글은 그 전부를 한 권으로 정리한다.

1장 · LSP — Microsoft 표준의 자리

1.1 왜 LSP가 필요했나

2015년 이전: 새 언어를 지원하려면 에디터마다 따로 플러그인을 짜야 했다.

언어가 M개, 에디터가 N개면 M x N개의 플러그인이 필요했다. 게다가 각 플러그인이 "정의 이동"이나 "리네임" 같은 기능을 다시 구현해야 했고, 품질은 천차만별이었다.

Microsoft의 통찰: 코드 분석 로직을 별도 프로세스(언어 서버) 로 분리하고, 에디터와 서버가 표준 JSON-RPC 메시지로 대화하게 하면, M + N으로 줄어든다.

1.2 LSP 핵심 메시지

전송 계층은 기본적으로 stdin/stdout JSON-RPC 2.0이다. TCP·소켓도 가능하지만 stdio가 표준이다.

1.3 LSP의 한 줄 그림

       ┌──────────────┐           ┌─────────────────────┐
       │   에디터      │  JSON     │   언어 서버 (LSP)    │
       │  (클라이언트)  │◀────────▶│  rust-analyzer 등   │
       │  VS Code,    │   RPC     │  (별도 프로세스)     │
       │  Helix, Zed, │           │                     │
       │  Neovim ...   │           │  - 파싱             │
       └──────────────┘           │  - 타입 추론        │
                                  │  - 인덱싱           │
                                  └─────────────────────┘

에디터 쪽은 얇아진다. 언어 서버 쪽은 두꺼워진다. 그리고 한 번 잘 짠 서버는 모든 에디터에서 쓸 수 있다.

1.4 2026년 LSP의 위상

• 모든 진지한 에디터가 LSP 클라이언트를 내장. VS Code, JetBrains, Helix, Zed, Neovim, Emacs (eglot), Sublime.
• 모든 활발한 언어가 자기 LSP 서버를 가짐. rust-analyzer, gopls, pyright, typescript-language-server, clangd 등.
• 벤더 락인이 사라진 영역. 더 이상 "VS Code에서만 잘 되는 언어 지원"이라는 말이 어색하다.

2장 · Tree-sitter — Max Brunsfeld의 증분 파서

2.1 정규식 강조의 한계

2010년대 중반까지, 거의 모든 에디터의 문법 강조는 정규식이었다. TextMate 문법 (.tmLanguage) 같은 형식이 사실상 표준이었다.

문제:

• 거짓말한다. 정규식은 진짜 파서가 아니라서, 중첩된 문자열·복잡한 보간·매크로에서 무너진다.
• 느리다. 큰 파일에서 매 키 입력마다 다시 매칭한다.
• 에러에 약하다. 코드가 잠시 깨졌을 때 강조가 통째로 망가진다.

2.2 Tree-sitter의 답

Max Brunsfeld(Atom 출신, GitHub)가 만든 Tree-sitter는 다음을 동시에 푼다.

1. 증분(incremental). 키 입력 한 번에 트리 전체를 다시 파싱하지 않고, 바뀐 부분만 재파싱한다.
2. 에러 복구. 코드가 일시적으로 깨져도 가능한 만큼 파싱하고 나머지는 에러 노드로 둔다.
3. 일반화된 LR(GLR) 알고리즘. 모호한 문법도 처리.
4. 언어 중립. 문법은 DSL(JS 비슷한 문법 정의)로 쓰고, 파서는 C로 생성된다.
5. 빠르다. 진짜 파서면서도 강조 용도로 충분히 빠르다.

2.3 어디에 쓰는가

• 문법 강조: 진짜 AST 기반이라 정확하다.
• 코드 폴딩: 함수·블록을 구조 기반으로 접는다.
• 구조 선택: "함수 전체 선택", "표현식 단위 확장 선택" 같은 동작.
• 검색·리라이트: 텍스트가 아니라 AST 노드로 쿼리한다 (ast-grep, Comby).
• 하이라이트 외 인덱싱: 함수·클래스·임포트 목록 추출.

2.4 누가 쓰나

2.5 grammar의 분포

tree-sitter-rust, tree-sitter-python, tree-sitter-typescript ... 거의 모든 인기 언어가 별도 npm/crates 패키지로 grammar를 제공한다. 새 언어를 지원하려면 grammar만 새로 짜면 되고, 강조 쿼리(.scm)는 짧다.

3장 · ast-grep (sg) — 구조적 검색/리라이트

3.1 grep의 한계, ast-grep의 답

grep은 텍스트 매칭이다. "console.log를 호출하는 모든 곳" 을 찾으면, 주석·문자열·doc 안의 console.log도 같이 잡힌다. 게다가 "console.log의 첫 인자가 객체인 곳만" 같은 질문은 정규식으로는 사실상 불가능하다.

ast-grep(sg)는 다르다. Tree-sitter로 파싱한 AST 위에서 패턴을 매칭한다. 패턴 언어는 그 언어 자체의 코드처럼 보이고, $VAR로 메타변수를 둔다.

3.2 누가 만들었나, 무엇이 새로운가

• Herrington Darkholme 가 Rust로 작성.
• 2024년에 외부 투자(시드 라운드)를 받으며, "ast-grep 회사"로 본격 확장 — 엔터프라이즈 코드 마이그레이션·정책 검색이 타깃.
• Rust + Tree-sitter 조합이라 빠르고, 모든 Tree-sitter 지원 언어에서 동작.

3.3 패턴 예시

# console.log를 어떤 인자로든 호출한 모든 곳
sg --pattern 'console.log($A)' --lang typescript

# 첫 인자가 객체 리터럴인 호출만
sg --pattern 'console.log({ $$$ })' --lang typescript

# 리라이트: console.log(x) -> logger.debug(x)
sg --pattern 'console.log($A)' --rewrite 'logger.debug($A)' --lang typescript --update-all

$A는 임의의 표현식 하나, $$$는 임의의 노드 목록을 잡는 메타변수다.

3.4 sgconfig.yml — 코드베이스 정책

ast-grep은 YAML 룰셋으로 팀 정책을 저장할 수 있다. CI에서 룰셋을 돌리면 "이 패턴을 쓰지 마라" 같은 정책이 자동 검사된다.

id: no-direct-fetch
language: typescript
rule:
  pattern: fetch($URL)
message: "fetch 대신 apiClient.get을 쓰세요"
severity: warning

3.5 어디에 적합한가

• 대규모 리팩토링. "이 API 호출 패턴을 새 SDK로 일괄 마이그레이션." 손으로 하면 일주일, ast-grep으로는 몇 분.
• 코드베이스 정책. "이 모듈에서 console.log 금지", "useEffect 안에 fetch 금지" 같은 규칙.
• 거대한 코드베이스 탐색. "이 패턴을 쓰는 모든 곳" 같은 질문에 grep보다 훨씬 정확.

4장 · BiomeJS — ESLint + Prettier 대체

4.1 JS 툴체인의 누적된 문제

2010년대 중반 이후 JS 개발자가 반드시 쓰던 두 도구:

• ESLint — 코드 품질 린트 (JS로 작성)
• Prettier — 코드 포맷터 (JS로 작성)

둘 다 훌륭하지만:

• 느리다. 거대한 모노레포에서 Lint 30초, 포맷 10초가 일상.
• 설정이 복잡하다. ESLint config가 plugin·preset·rule의 미로.
• 둘이 따로 돈다. ESLint --fix와 Prettier가 충돌해서 추가 플러그인이 필요.
• 타입 정보 없이 동작. AST 수준 검사라 한계가 있다.

4.2 Biome의 접근

Biome(원래 Rome 프로젝트에서 분리·재출범)은 다음을 묶었다.

• Rust로 작성 — 같은 코드에 대해 ESLint+Prettier 대비 수십~수백 배 빠르다.
• 단일 바이너리 — Lint + 포맷 + 임포트 정리 + 코드 액션이 한 도구.
• 거의 제로 설정 — 좋은 기본값. biome.json 한 파일.
• LSP 서버 내장 — 에디터 통합이 자체 제공.

4.3 한 줄로 보는 차이

# 전통적
eslint . --fix && prettier --write .

# Biome
biome check . --apply

4.4 한계

• TypeScript 전용 룰은 ESLint가 여전히 더 풍부(2026년 기준 빠르게 줄어드는 중).
• 커스텀 룰: ESLint가 더 성숙. Biome도 v2부터 플러그인 시스템 확장.
• Vue·Svelte 같은 비표준 문법: 지원 중이지만 ESLint 만큼 깊지 않을 때가 있다.

그래도 신규 JS/TS 프로젝트의 기본값은 빠르게 Biome로 이동하고 있다.

5장 · Marksman — Markdown LSP

5.1 Markdown도 LSP가 필요한가

처음엔 의외다. 마크다운은 그냥 텍스트인데? 하지만 마크다운을 본격적으로 쓰는 위키·노트·블로그·문서 사이트에서는 다음이 필요하다.

• 문서 간 링크의 정의 이동 ([foo](./other.md) 가서 열기).
• 헤딩·앵커·이미지의 자동완성.
• 깨진 링크의 진단.
• 백링크 추적.
• 이름 변경 시 모든 참조 일괄 수정.

이게 LSP의 정확한 사용처다.

5.2 Marksman의 자리

Marksman(F# 작성)은 마크다운 전용 LSP 서버다. Helix·Zed·Neovim·VS Code 모두에서 동작한다.

• [[wiki-link]] 와 [text](path.md) 양쪽을 지원.
• 헤딩 자동완성: [#까지 치면 가능한 헤딩 목록.
• 깨진 링크 표시.
• 헤딩 리네임이 모든 참조에 전파.
• 워크스페이스 심볼: 모든 헤딩이 검색 가능.

5.3 비슷한 도구

• zk-lsp — Zettelkasten 스타일 노트.
• Obsidian — 자체 인덱서지만, 외부 에디터에서 같은 vault를 다룰 때 Marksman이 표준이다.

6장 · Helix 에디터 — built-in LSP + Tree-sitter

6.1 Helix의 디자인 결정

Helix는 Rust로 짠 모달 에디터다. Vim/Kakoune의 후예이지만 결정적인 차이가 있다.

• 빌트인 LSP 클라이언트. 플러그인 없음. languages.toml에 서버를 등록하면 끝.
• 빌트인 Tree-sitter. 강조·들여쓰기·구조 모션·텍스트 객체 전부 TS 기반.
• selection-first 편집 모델. Vim의 verb-object를 뒤집어 object-verb로. 선택이 항상 먼저 보인다.
• 플러그인 시스템이 거의 없음(설계 의도). 코어가 두꺼워서 거의 필요 없게 만든다.

6.2 왜 매력적인가

"한 시간 안에 IDE급 환경"이 Helix의 약속이다. 트레이드오프는 분명하다 — 깊은 커스터마이즈는 Neovim이 여전히 왕이다.

6.3 languages.toml 예시

[[language]]
name = "rust"
language-servers = ["rust-analyzer"]
auto-format = true

[[language]]
name = "python"
language-servers = ["basedpyright"]

이게 거의 전부다.

7장 · Zed 에디터 — Tree-sitter + LSP + 실시간 협업

7.1 Zed의 출신과 야망

Zed는 Atom·Electron 시절의 공동저자(Nathan Sobo 등)가 다시 만든 에디터다. 핵심은 Rust로 처음부터 다시 짠 네이티브 에디터 + 공동 편집(collab) + AI 통합.

• GPU 가속 렌더링. 에디터로서 매우 빠르다.
• 빌트인 Tree-sitter / LSP. Helix와 같은 철학.
• 실시간 공동 편집. Google Docs 같은 멀티 커서·음성 통화·화면 공유까지 일체화.
• AI 통합. 챗·인라인 어시스트·에이전트 통합이 빌트인.
• 확장 시스템. WebAssembly 기반.

7.2 누구에게 맞나

• VS Code의 무거움(Electron, RAM 사용량, 시작 속도)에 지친 사람.
• 공동 편집을 제품 수준으로 자주 쓰는 페어 프로그래밍 팀.
• AI 기능을 에디터 코어에서 쓰고 싶은 사람.

7.3 트레이드오프

• 확장 생태계가 VS Code만큼 깊지 않다.
• 거대 모노레포의 일부 워크플로우(특정 디버거·테스트 러너)는 아직 VS Code 쪽이 더 풍부.

8장 · Neovim 통합 — nvim-treesitter / lsp-zero / nvim-lspconfig

8.1 Neovim의 자리

Neovim은 Vim에서 포크되어 빌트인 LSP 클라이언트(0.5+)와 Lua 런타임, Tree-sitter 지원(0.8+)을 코어에 넣었다. 결과적으로 무한 커스터마이즈가 가능한 에디터로 남았다.

대표 플러그인:

8.2 lsp-zero의 가치

Neovim의 LSP 셋업은 강력하지만 처음엔 가파르다. 1) lspconfig로 서버 등록, 2) mason으로 설치, 3) cmp로 자동완성 연결, 4) 키맵 설정. lsp-zero는 이 네 단계를 합리적인 기본값으로 한 번에 한다.

local lsp_zero = require('lsp-zero')
lsp_zero.on_attach(function(client, bufnr)
  lsp_zero.default_keymaps({buffer = bufnr})
end)

require('mason').setup({})
require('mason-lspconfig').setup({
  ensure_installed = { 'rust_analyzer', 'gopls', 'basedpyright', 'tsserver' },
  handlers = { lsp_zero.default_setup },
})

8.3 nvim-treesitter

require('nvim-treesitter.configs').setup({
  ensure_installed = { 'rust', 'go', 'python', 'typescript', 'tsx', 'lua' },
  highlight = { enable = true },
  indent = { enable = true },
})

이걸 켜는 순간 정규식 강조와는 비교가 안 되는 정확성이 들어온다.

9장 · 언어별 LSP 카탈로그

9.1 Rust — rust-analyzer

• Rust 공식 권장 LSP.
• 매크로 확장·트레잇 추론·라이프타임 단서까지 인라인 표시.
• 메모리·CPU를 적지 않게 먹지만 그만한 값을 한다.

9.2 Go — gopls

• Go 팀이 직접 유지. 사실상 표준.
• gofmt·goimports와 통합된 빠른 포맷.
• generics 도입 이후 안정화가 빨랐다.

9.3 Python — pyright / basedpyright / jedi / pylyzer

2026년 기준: 새 코드베이스에 권장은 basedpyright. 레거시 untyped 코드에는 jedi.

9.4 TypeScript / JavaScript

• typescript-language-server (오랜 표준). tsserver를 LSP로 래핑.
• vtsls — VS Code의 TS 확장에 더 가깝게 동작하는 신흥 래퍼. 2026년에는 많은 Neovim/Helix 사용자가 vtsls로 이동.
• 포맷·린트는 BiomeJS가 빠르게 잡아먹는 중.

9.5 C/C++ — clangd

• LLVM 진영의 표준. compile_commands.json만 잘 만들면 거대한 코드베이스에서도 동작.
• 인덱싱이 느릴 수 있지만 한 번 인덱스가 만들어지면 응답이 빠르다.

9.6 Java — jdtls

• Eclipse JDT를 LSP로 노출. Java 생태계의 사실상 표준 LSP.
• 메모리 사용이 크다. Maven/Gradle 통합 깊음.

9.7 그 외

9.8 한 가지 패턴

• 언어 팀이 직접 만든 LSP (gopls, rust-analyzer, ruby-lsp, hls, ocaml-lsp)는 거의 항상 가장 깊고 정확하다.
• 사설 회사가 만든 LSP (pyright, sourcekit-lsp)도 종종 표준이 된다.
• 언어가 정적 타입을 가지면 LSP 품질이 비약적으로 좋아진다 — 타입 정보가 곧 LSP의 재료다.

10장 · 구조적 검색 — Comby / Semgrep / CodeQL

ast-grep과 가까운 동네에 있는 세 도구. 각자 약간 다른 자리를 차지한다.

10.1 Comby

• 언어 중립 구조 매칭 도구. 자체 미니 파서로 "괄호·중괄호·따옴표 같은 균형 잡힌 구조"를 인식.
• 새 언어 지원이 아주 저렴 — 진짜 grammar가 아니라 "언어의 토큰 모양"만 등록하면 된다.
• 작고 빠른 일회성 리라이트에 강하다.

comby 'foo(:[x])' 'bar(:[x])' file.py

10.2 Semgrep

• 보안 중심으로 출발. 지금은 일반 정책 검색 엔진.
• 패턴은 그 언어의 코드 자체처럼 보임. $X.execute($Y) 같은 메타변수.
• 룰셋이 거대 (수천 개의 보안 룰). CI에 꽂아 두는 표준 도구.
• 회사 차원의 코드 정책 — "이 API 호출 금지", "이 인자 패턴 확인" — 에 최적.

10.3 CodeQL

• GitHub(Microsoft) 소유. "코드를 데이터베이스로 보고 SQL-like 쿼리".
• 패턴 매칭이 아니라 데이터 흐름 분석까지 한다.
• 매우 강력하지만 학습 곡선이 가팔라서 보통 보안팀이 사용.
• GitHub Code Scanning의 기본 엔진.

10.4 셋 비교

선택 가이드:

• 한 번 잘 짜고 팀이 계속 검사 -> Semgrep.
• 즉석 대규모 리팩토링 -> ast-grep.
• 가볍게 한두 곳 -> Comby 또는 ast-grep.
• 깊은 보안 분석 -> CodeQL.

11장 · Tabnine vs 언어별 자동완성

11.1 두 갈래

자동완성은 두 가지가 섞여 있다.

11.2 Tabnine의 자리

• 초창기 GPT-2 기반 로컬 자동완성으로 알려졌다.
• 2026년에는 엔터프라이즈 자가호스팅·코드 학습 격리에 집중. "회사 사내 코드만 학습한 모델"을 제공.
• Copilot이 너무 강해진 시장에서 "프라이버시·온프레미스" 포지션을 잡았다.

11.3 LSP 완성과 LLM 완성은 같이 가야 한다

• LSP 완성은 정확한 타입·심볼을 안다. 환각이 없다.
• LLM 완성은 긴 컨텍스트·패턴 일반화가 강하다. 모르는 이름도 추측.
• 좋은 에디터(Cursor, Zed, VS Code+Copilot, Neovim+lsp+ai 플러그인)는 두 흐름을 동시에 보여주고, 사용자가 고를 수 있게 한다.

자동완성 = LSP + LLM의 하이브리드가 2026년의 표준이다.

12장 · 한국·일본 현장

12.1 한국 — 토스의 LSP·내부 도구 활용

토스는 사내 도구·플랫폼팀 글에서 자주 LSP·Tree-sitter 기반 도구를 언급한다.

• 거대 모노레포에서 타입 인식 grep(ast-grep) 으로 API 마이그레이션·deprecation 검색.
• vtsls + Biome 조합으로 프론트엔드 자동완성·포맷을 빠르게.
• 자체 디자인 시스템·내부 SDK를 위한 ESLint/Biome 룰을 사내에서 유지.
• 보안팀은 Semgrep 룰셋을 코드베이스 정책으로 운영.

요점은 에디터 자유다. 누구는 IntelliJ, 누구는 Cursor, 누구는 Neovim을 쓰지만, LSP·Tree-sitter·Biome·ast-grep 같은 표준 위에 있으면 팀의 룰셋이 모두에게 동일하게 적용된다.

12.2 일본 — メルカリ의 Tree-sitter 활용

メルカリ(Mercari)는 사내 기술 블로그에서 Tree-sitter 기반 도구로 다음을 자주 언급한다.

• 코드 검색·심볼 인덱스 — 거대 모노레포에서 정확한 함수·심볼 추출.
• GitHub Actions에서 ast-grep / Semgrep 룰셋 으로 사내 코드 정책 검사.
• Go + gopls·Rust + rust-analyzer가 사내 표준 LSP 조합. 결제·검색 등 백엔드의 기본.
• 모바일 쪽에서는 kotlin-language-server / sourcekit-lsp 가 빌드 인프라와 묶여 사용된다.

일본의 다른 회사들 — DeNA·CyberAgent·SmartHR·LINE — 도 비슷한 그림이다. LSP·Tree-sitter는 2026년의 "당연한 인프라"로 자리잡았다.

13장 · 누가 무엇을 골라야 하나

13.1 시나리오별 추천

"VS Code를 그대로 쓰고 싶다"

• VS Code + 언어별 공식 LSP 확장 (rust-analyzer, gopls, basedpyright, ...).
• 자동완성: Copilot 또는 Cursor 포크.
• 린트/포맷: Biome (JS/TS), 언어별 표준 (rustfmt, gofmt, ruff).

"VS Code가 무겁다, 빠른 네이티브 에디터로"

• Zed. 빌트인 LSP·TS·협업·AI. 가장 부담 없는 이주.
• Helix. 더 가볍고 더 키보드 중심. 모달 에디터에 익숙하다면.

"무한 커스터마이즈와 키보드 워크플로"

• Neovim + lsp-zero + nvim-treesitter + telescope + nvim-cmp.
• 첫 셋업은 가파르지만, 한 번 자리 잡으면 가장 강한 워크플로.

"거대 모노레포 리팩토링·정책"

• 코드 검색·리라이트: ast-grep.
• 보안·정책: Semgrep.
• 깊은 분석: CodeQL.
• 일회성 가벼운 리라이트: Comby.

"마크다운 위주 작업(노트·문서·블로그)"

• 에디터는 무엇이든, LSP로 Marksman.
• Obsidian 사용자는 외부 에디터 + Marksman 조합도 좋은 선택.

13.2 모든 경우의 공통점

14장 · 함정과 안티패턴

14.1 흔한 함정

• LSP 서버를 너무 많이 켠다. Neovim에서 같은 파일에 LSP 두 개(예: tsserver + vtsls)가 동시에 붙으면 진단이 중복되고 메모리가 새어 나간다. 한 언어당 하나로 줄여라.
• 거대 모노레포에서 인덱싱 비용을 무시. 첫 인덱스가 10분 걸리는 건 흔하다. CI 캐싱·서버 재시작 시점을 신경 써야 한다.
• 포맷터 충돌. Prettier·Biome·ESLint --fix·언어 공식 포맷터를 동시에 켜면 저장할 때마다 코드가 진동한다. 단 하나의 "포맷 권위"만 둬라.
• Tree-sitter grammar 버전 불일치. 에디터마다 grammar 버전이 다르면 같은 파일이 다르게 강조된다. 큰 문제는 아니지만 헷갈린다.

14.2 안티패턴

• 정규식으로 리팩토링. 다섯 군데 이상이면 거의 항상 ast-grep / Comby / Semgrep이 빠르고 안전하다.
• 수동 임포트 정리. LSP의 organize imports 또는 Biome로 자동화.
• LSP 없이 거대 코드베이스 탐색. 정의 이동·참조 검색이 없으면 잃는 시간이 어마어마하다.
• 로컬에만 LSP, CI에는 없음. Lint·타입 체크·정책 검사는 CI에도 같이 있어야 한다.

15장 · 정리 — 표준 위에 사는 법

2026년의 코드 도구 생태계는 두 개의 표준 위에 서 있다.

• LSP — 코드 지능.
• Tree-sitter — 코드 구조.

이 두 표준 덕분에:

• 에디터를 바꾸는 비용이 폭락했다.
• 새 언어를 지원하는 비용이 폭락했다.
• 회사 정책을 코드로 표현하는 비용이 폭락했다.

그 위에 자라난 생태계 — ast-grep, Biome, Marksman, Helix, Zed, Neovim의 lsp-zero/treesitter 체인, 그리고 언어별로 잘 만들어진 LSP들 — 는 모두 이 두 축의 직접적인 후예다.

선택할 때 기억할 것 하나: 도구가 LSP·Tree-sitter 같은 표준 위에 있다면, 잘못된 선택이 거의 없다. 언제든 옮길 수 있고, 팀 룰셋이 이주를 따라간다.

참고 / References

• LSP 공식 사양 — https://microsoft.github.io/language-server-protocol/
• Tree-sitter — https://tree-sitter.github.io/tree-sitter/
• ast-grep (sg) — https://ast-grep.github.io/
• BiomeJS — https://biomejs.dev/
• Marksman — https://github.com/artempyanykh/marksman
• Helix editor — https://helix-editor.com/
• Zed editor — https://zed.dev/
• Neovim — https://neovim.io/
• nvim-treesitter — https://github.com/nvim-treesitter/nvim-treesitter
• nvim-lspconfig — https://github.com/neovim/nvim-lspconfig
• lsp-zero.nvim — https://github.com/VonHeikemen/lsp-zero.nvim
• mason.nvim — https://github.com/williamboman/mason.nvim
• rust-analyzer — https://rust-analyzer.github.io/
• gopls — https://pkg.go.dev/golang.org/x/tools/gopls
• pyright — https://github.com/microsoft/pyright
• basedpyright — https://github.com/DetachHead/basedpyright
• jedi-language-server — https://github.com/pappasam/jedi-language-server
• pylyzer — https://github.com/mtshiba/pylyzer
• typescript-language-server — https://github.com/typescript-language-server/typescript-language-server
• vtsls — https://github.com/yioneko/vtsls
• clangd — https://clangd.llvm.org/
• jdtls — https://github.com/eclipse-jdtls/eclipse.jdt.ls
• Solargraph — https://solargraph.org/
• ruby-lsp — https://github.com/Shopify/ruby-lsp
• elixir-ls — https://github.com/elixir-lsp/elixir-ls
• haskell-language-server — https://github.com/haskell/haskell-language-server
• nimlsp — https://github.com/PMunch/nimlsp
• ocaml-lsp — https://github.com/ocaml/ocaml-lsp
• sumneko/lua-language-server — https://github.com/LuaLS/lua-language-server
• zls — https://github.com/zigtools/zls
• Comby — https://comby.dev/
• Semgrep — https://semgrep.dev/
• CodeQL — https://codeql.github.com/
• GitLens (VS Code) — https://github.com/gitkraken/vscode-gitlens
• Difftastic — https://github.com/Wilfred/difftastic
• Tabnine — https://www.tabnine.com/
• 토스 기술 블로그 — https://toss.tech/
• メルカリ Engineering Blog — https://engineering.mercari.com/