프로토콜 버퍼(Protobuf)는 gRPC, ConnectRPC를 비롯한 수많은 서비스의 데이터 스키마를 정의하는 사실상의 표준 언어다. 그러나 정작 이 스키마를 작성하는 개발 경험은 오랫동안 뒤처져 있었다. 대부분의 주류 프로그래밍 언어가 정의로 이동, 자동 완성, 참조 찾기, 문맥을 이해하는 구문 강조 같은 기능을 편집기에서 기본으로 누리는 동안, .proto 파일을 다루는 개발자는 단순 문법 하이라이팅 수준의 지원에 만족해야 했다. Buf가 이번에 공개한 프로토버프용 LSP 서버는 바로 이 공백을 메우려는 시도다.
LSP가 왜 중요한가
LSP(Language Server Protocol)는 편집기와 언어 지원 기능을 분리해 연결하는 표준 API다. 원래 VSCode에서 출발한 이 규격은 이제 IntelliJ, Neovim 등 거의 모든 주요 편집기가 지원한다. 편집기마다 언어별 플러그인을 따로 만들 필요 없이, 언어 쪽에서 LSP 서버 하나만 구현하면 여러 편집기가 그 지능을 공유할 수 있다는 것이 핵심이다. 그동안 프로토버프에 이런 서버가 없었다는 것은, 뒤집어 말하면 정의로 점프하거나 메시지 필드를 자동 완성하는 기본적인 편의를 프로토버프 개발자만 누리지 못했다는 뜻이다.
Buf는 자사 CLI에 이 LSP 서버를 번들로 포함시켜 배포한다. VSCode 사용자는 Buf 확장 프로그램을 설치하기만 하면 되고, 확장은 이미 설치된 Buf CLI를 자동으로 사용하거나 필요 시 새로 설치한다. Buf 엔지니어들이 선호한다는 Neovim의 경우 Buf CLI를 설치한 뒤 이를 LSP 서버로 지정하고 vim.lsp.enable('buf-lsp')로 활성화하면 된다. 그 밖의 편집기라도 buf lsp serve 명령으로 서버 프로세스를 띄우는 방식만 맞춰주면 연동이 가능하다. 특정 편집기에 종속되지 않는 구조라는 점이 실무 도입에서 부담을 줄인다.
protoc가 아니라 새로운 컴파일러 프런트엔드
이번 발표에서 기술적으로 더 눈여겨볼 대목은 LSP 자체보다 그것을 떠받치는 컴파일러다. Buf는 이미 파일을 파싱하고 플러그인을 호출하는 컴파일러 프런트엔드 protocompile을 운영해 왔는데, 표준을 완전히 준수하면서도 protoc보다 빠르고 유연하다고 설명한다. 구글조차 방대한 자사 코드베이스 일부에서 protoc와 함께 이 컴파일러를 쓰고 있다는 점은 성숙도를 가늠하는 하나의 지표다.
LSP를 만들면서 Buf는 이 프런트엔드를 한 단계 더 발전시켜, 증분 컴파일과 한층 정밀한 진단을 가능하게 하는 쿼리 기반 프런트엔드를 새로 개발했다. 대표적인 예로, protoc가 놓치는 repeated 수식어 중복 선언 같은 오류를 정확히 잡아낸다. 이를 위해 기존의 FileDescriptorProto에 의존하는 대신 전용 AST와 중간 표현(IR)을 새로 설계했다는 점이 핵심이다. 편집기에서 오류를 즉각적으로, 그리고 정확한 위치에 표시하려면 코드의 구조적 정보를 세밀하게 보존하는 내부 표현이 필요한데, 기존 디스크립터 기반 방식으로는 여기에 한계가 있었기 때문이다.
이 새 구조는 실용적인 이점도 함께 겨냥한다. Buf는 Editions 2024처럼 앞으로 추가될 프로토버프의 새 언어 기능을 손쉽게 반영할 수 있을 만큼 유연하며, 동시에 메모리 효율이 좋아 대규모 Buf 모듈을 포함한 워크스페이스도 감당할 수 있다고 밝혔다. 편집기 지원은 프로젝트가 커질수록 응답성과 자원 사용량이 문제가 되기 마련인데, 처음부터 이 지점을 고려해 설계했다는 의미다.
실무자가 따져볼 지점
Buf는 이 LSP를 Protobuf-ES(크로미움에서 사용), Protovalidate, ConnectRPC, Buf 스키마 레지스트리로 이어지는 자사 생태계의 연장선으로 규정한다. 즉 개별 도구가 아니라 프로토버프를 '가장 쉬운 선택'으로 만들려는 제품군 전략의 일부다. 실무 관점에서 이는 편의와 종속성을 동시에 뜻한다. LSP 서버가 Buf CLI에 묶여 있는 만큼, 이미 Buf 도구 체인을 쓰는 조직이라면 추가 비용 없이 편집기 경험을 끌어올릴 수 있다. 반대로 순수 protoc 기반 워크플로를 유지하는 팀에게는 새로운 도구를 도입하는 판단이 필요하다.
또 하나 유의할 점은 이 기능이 아직 진행형이라는 사실이다. Buf 스스로 진단 품질을 계속 개선하고 기능을 추가할 계획이라고 밝힌 만큼, 현시점의 완성도와 향후 로드맵을 함께 감안해 도입 시점을 정하는 편이 안전하다. 그럼에도 프로토버프에 프로덕션급 LSP가 처음 등장했다는 사실 자체는, 스키마 우선 개발을 표방하는 팀의 일상적인 편집 경험을 실제로 바꿔놓을 만한 변화다. 도구가 오류를 편집 시점에 잡아주고 정의를 즉시 따라갈 수 있게 되면, 스키마는 더 이상 별도의 컴파일 단계를 거쳐야만 검증되는 텍스트가 아니라, 코드처럼 다룰 수 있는 대상이 된다.