universal-lsp

하나의 저장소에 두 프로젝트가 있으며, 하나가 다른 하나를 필요로 하기 때문에 함께 빌드됩니다:

Universal LSP — Lua로 선언된 플러그인을 통해 많은 언어를 지원하는 단일하고 빠르며 메모리 사용량이 적은 C++ 언어 서버입니다. 의미론적 분석을 포함한 모든 분석 계층은 하나의 프로세스에서 네이티브로 실행됩니다. rust-analyzer, pyright, clangd 또는 다른 어떤 바이너리나 네트워크 서비스도 생성하거나 프록시하거나 의존하지 않습니다. 터미널 우선, 에이전트 중심의 세계를 위해 설계되었습니다: 편집기용 표준 LSP over stdio, 에이전트용 MCP 프런트엔드, CI용 헤드리스 batch-query CLI.

graph-lite — 그래프를 위한 누락된 SQLite: 단일 헤더만으로 어떤 프로젝트든 포함할 수 있는 작고 의존성이 없으며 임베딩 가능한 속성 그래프(property-graph) 라이브러리입니다. 공개 표면은 C ABI이므로 Ruby, JavaScript, Python, Rust, Go, C는 자체 FFI를 통해 동기화할 래퍼 없이 포함할 수 있습니다 — SQLite가 그만큼 널리 쓰이게 된 것과 같은 방식입니다. LSP는 이 라이브러리의 첫 번째이자 가장 까다로운 소비자입니다 — 대규모 코드베이스에서 인터랙티브 지연 시간 안에 호출 그래프, 임포트 그래프, 심볼 관계를 처리해야 합니다 — 하지만 graph-lite의 API는 그러한 용어와 무관하게 유지되며, 기계적으로 그러한 용어를 학습하지 못하도록 차단됩니다.

상태: 구현 전 단계. 저장소, 게이트, 문서, 계획이 준비되어 있습니다. 현재 작업은 빌드 1단계(graph-lite 코어)입니다. 아직 배포되는 것은 없습니다. 범위는 docs/spec.md에 있고, 진행 상황은 마일스톤에 있습니다.

이유

오늘날 모든 언어는 자체 서버, 자체 프로세스, 자체 메모리 사용량, 그리고 "정의로 이동"이 얼마나 비용이 드는지에 대한 자체적인 생각을 가지고 있습니다. 네 가지 언어로 네 개의 프로젝트를 열면 아무것도 공유하지 않는 수십 개의 프로세스가 실행됩니다 — 캐시도, 인덱스도, 관계 그래프도 없습니다. 그리고 그중 어느 것도 현재 읽기와 편집의 대부분을 수행하는 클라이언트를 위해 설계되지 않았습니다: 편집기가 연결되지 않은 터미널에서 작업하며 디스크에 직접 일괄 변경을 가하는 AI 에이전트입니다.

Universal LSP는 이 모든 것을 위한 하나의 프로세스입니다. 언어를 추가한다는 것은 새 서버를 작성하는 것이 아니라 선언적 Lua 규칙을 작성하는 것을 의미합니다.

Related MCP server: code-auditor-mcp

계층

언어는 해당 플러그인의 규칙이 설명하는 깊이를 정확히 얻습니다 — 더도 덜도 아니며, 시스템에 설치된 것에 의존하지도 않습니다.

계층 4는 에이전트가 실제로 원하는 것입니다: 이것을 전이적으로 호출하는 것과 이것을 변경하면 무엇이 깨지는지 — 수백 번의 파일 읽기 대신 미리 계산된 그래프에서 답을 얻습니다.

아키텍처

      editor  ──stdio LSP──┐
      agent   ──MCP────────┤
      CI      ──batch CLI──┘
                           │
                    ┌──────▼──────┐
                    │  shim/cli   │  thin entrypoints, no logic
                    └──────┬──────┘
                           │ unix socket
                  ┌────────▼─────────┐
                  │     daemon       │  one per user, many sessions,
                  │  engine/         │  warm caches, per-workspace state
                  └────┬────────┬────┘
              tree-sitter        │
              + Lua rules        │
                   │             │
              ┌────▼─────┐  ┌────▼─────┐
              │ analysis │──▶ graph-lite│  generic nodes + typed edges
              └──────────┘  └──────────┘  (knows nothing about code)

의존성은 한 방향으로만 흐릅니다: analysis → graph-lite, 절대 반대 방향은 없습니다. 두 개의 린트 가드와 독립 빌드 CI 작업이 이를 유지합니다. 대안 — 추출 시점에 알아차리는 것 — 은 재작성이기 때문입니다.

빠른 시작

git clone https://github.com/developerz-ai/universal-lsp.git
cd universal-lsp
bin/setup          # prerequisites → configure → link compile_commands.json
bin/check          # the full gate: format, guards, build, tests, sanitizers
bin/dev doctor     # one row per thing that can drift

저장소 도구에는 CMake ≥ 3.24, Ninja, C++20 컴파일러, clang-format, Bun이 필요합니다. bin/setup이 누락된 항목과 설치 방법을 알려줍니다.

graph-lite 단독 포함

graph-lite는 이 저장소에 대한 지식 없이 빌드됩니다 — 모든 PR에서 이를 확인하므로, 나중에 추출할 때 재작성이 아니라 git mv로 끝납니다:

cmake -S graph-lite -B build/graph-lite -G Ninja
cmake --build build/graph-lite

#include "graph-lite.h"     /* the contract: C linkage, opaque handles, status codes */

#include "graph-lite.hpp"   // C++ ergonomics over the same entry points, header-only

require "ffi"               # and the same from Ruby, JS, Python, Rust, Go
module GraphLite
  extend FFI::Library
  ffi_lib "graph-lite"
  attach_function :graph_lite_version_string, [], :string
end

테스트 스위트의 C 번역 단위는 C로 컴파일되어 링크됩니다. 따라서 C 호환성이 깨진 헤더는 여러분의 통합이 아니라 우리의 빌드를 실패시킵니다.

API 및 데이터 모델: docs/graph-lite/README.md · C를 사용하는 이유: ADR 0004.

출시 시 지원 언어

TypeScript · JavaScript · Ruby · C · C++ · Lua · Python · Java · Kotlin · Swift · Rust

계층 1과 2는 열한 개 언어 모두에서 먼저 제공됩니다 — 편집기와 에이전트 모두에게 가장 큰 가치입니다. 계층 3의 깊이는 언어별로 성장하며, 잘못된 타입이 아니라 "unknown type"으로 저하됩니다.

문서

기여

먼저 CONTRIBUTING.md를 읽고, 그다음 CLAUDE.md를 읽으세요. 공식 열한 개 언어 외의 플러그인은 승인도 필요 없고 이 저장소에 포함될 필요도 없습니다 — git 저장소를 게시하고 고정하세요.

라이선스

엔진은 Apache-2.0입니다. **graph-lite는 MIT**이며 의도적으로 독립적으로 버전이 관리됩니다: 단일 헤더를 포함할 때, 그것을 키워낸 대상의 라이선스에 대해 생각할 필요가 없어야 합니다.