1차 공개일 · 8월 18일1차 강의가 모두 공개됩니다
TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 28 READS

이제 .proto 파일도 자동완성 되고 정의로 점프해요 — Buf가 만든 Protobuf 공식 LSP

이제 .proto 파일도 자동완성 되고 정의로 점프해요 — Buf가 만든 Protobuf 공식 LSP
SOURCE IMAGE · HACKER NEWS
이제 .proto 파일도 자동완성 되고 정의로 점프해요 — Buf가 만든 Protobuf 공식 LSP

gRPC로 마이크로서비스를 만들어본 분이라면 공감할 불편이 하나 있어요. 정작 모든 것의 출발점인 .proto 파일을 편집할 때는 에디터가 메모장 수준이 된다는 거예요. 다른 파일에 정의된 메시지 타입을 확인하려면 직접 파일을 열어서 눈으로 찾아야 하고, 오타를 내도 컴파일을 돌려봐야 알 수 있었죠. Go나 TypeScript를 쓸 때 당연하게 누리던 자동완성과 '정의로 이동'이 protobuf에는 없었던 건데요. Protobuf 생태계의 핵심 기업인 Buf가 공식 LSP를 내놓으면서 이 오랜 불편이 드디어 해소되고 있어요.

LSP가 뭐냐면

먼저 LSP부터 설명할게요. Language Server Protocol의 약자로, 마이크로소프트가 VS Code를 만들면서 정립한 표준이에요. 원래는 에디터마다, 언어마다 자동완성이나 오류 표시 기능을 따로 구현해야 했어요. 에디터가 10개고 언어가 10개면 100개의 플러그인이 필요한 셈이죠. LSP는 '언어의 지능'을 별도의 서버 프로그램으로 분리하고, 에디터와는 표준 프로토콜로 대화하게 만들었어요. 언어 서버 하나만 만들면 VS Code든 Neovim이든 LSP를 지원하는 모든 에디터에서 그대로 쓸 수 있는 거예요. 지금 여러분이 쓰는 대부분의 언어 지원 기능이 이 구조 위에서 돌아가고 있어요.

이번에 뭐가 되는 건가요

Buf의 언어 서버는 buf CLI에 내장되어 있어서 별도 설치가 거의 필요 없어요. 기능을 보면, import된 다른 파일의 메시지나 enum 정의로 바로 점프하는 정의로 이동, 타입 이름과 필드 자동완성, 커서를 올리면 주석 문서를 보여주는 hover, 저장할 때 buf format으로 자동 정렬, 그리고 buf lint의 스타일 규칙 위반을 타이핑하는 순간 실시간으로 표시해주는 진단까지 지원해요. 필드 번호 중복 같은 실수를 컴파일 단계가 아니라 입력하는 순간에 잡아주는 거죠. VS Code용 공식 확장이 있고, Neovim 등 LSP를 지원하는 에디터라면 설정 몇 줄로 붙일 수 있어요.

왜 이제야 나왔을까요

여기엔 기술적인 이유가 있어요. protobuf의 import는 파일 시스템의 상대 경로가 아니라, 컴파일 시점에 -I 옵션으로 지정하는 include 경로를 기준으로 해석되거든요. 그러니까 에디터가 .proto 파일만 열어서는 import 문이 실제로 어느 파일을 가리키는지 알 수가 없었던 거예요. 빌드 설정을 모르면 해석이 안 되는 구조였던 거죠. Buf는 몇 년에 걸쳐 모듈과 워크스페이스라는 개념, 그리고 스키마 레지스트리(BSR)를 만들면서 protobuf에 패키지 매니저 같은 의존성 해석 체계를 세웠는데요. 이 기반이 갖춰지니까 비로소 언어 서버가 import를 정확히 따라갈 수 있게 된 거예요. LSP는 갑자기 나온 기능이 아니라 그 기반 공사의 결실인 셈이죠.

업계 맥락

사실 그동안 커뮤니티의 시도가 없었던 건 아니에요. VS Code의 vscode-proto3는 문법 하이라이팅 위주였고, IntelliJ 계열의 protobuf 플러그인이나 커뮤니티가 만든 언어 서버들도 있었지만, 앞서 말한 include 경로 문제 때문에 반쪽짜리인 경우가 많았어요. Buf는 lint, breaking change 검사(스키마 변경이 기존 클라이언트를 깨뜨리는지 확인하는 기능), 포맷터, 코드 생성, 레지스트리에 이어 에디터 지원까지 protobuf 개발 경험 전체를 수직 통합하고 있는데, 이번 LSP로 그 퍼즐의 마지막 조각이 맞춰진 느낌이에요.

한국 개발자에게 주는 시사점

국내에서도 MSA로 전환하면서 gRPC를 도입한 팀이 많은데요. 스키마 파일이 수십 개를 넘어가는 규모라면 체감 효과가 클 거예요. 좋은 점은 buf를 전면 도입하지 않았어도 LSP만 먼저 써볼 수 있다는 거예요. buf CLI를 설치하고 에디터 확장을 깔고 프로젝트 루트에 buf.yaml 하나 만들면 바로 동작하거든요. 이렇게 에디터 경험으로 먼저 맛보고, 팀이 익숙해지면 lint나 breaking change 검사를 CI에 붙이는 식으로 점진적으로 확장하는 경로가 자연스러워요.

정리하면

protobuf가 드디어 일반 프로그래밍 언어와 같은 일급 대접을 받기 시작했다는 신호예요. 여러분 팀은 .proto 파일을 어떻게 관리하고 계세요? 스키마 리뷰나 하위 호환성 때문에 고생한 경험이 있다면 나눠주세요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://buf.build/blog/protobuf-lsp
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...