언어 기능을 여러 도구에 붙일 때, 왜 LSP가 여전히 필요한가

Show Notes

언어 분석을 편집기마다 다시 만들지 않으려면 무엇을 표준화해야 할까요? 문서 동기화와 지원 기능 협상, 설치·수명주기 책임을 짚고 2026년 10월 CSS 변수 서버 제작기로 재사용과 분석 한계의 경계를 살펴봅니다.

전체 대본 보기

참고 자료

• Microsoft — Language Server Protocol Overview
• lmn451 — Building a CSS variable language server
• Visual Studio Code — Language Server Extension Guide
• Neovim — LSP documentation
• CSS Variable LSP — Current Limitations
• MDN — CSS: Cascading Style Sheets
• MDN — Document Object Model

이 에피소드의 음성은 TTS로 합성되었습니다.

What is kalee's 공부방?

kalee 가 공부하고자 하는 내용들을 두서없이 업로드하는 팟캐스트

진행자: 사내 설정 언어에 자동 완성과 정의 찾기를 붙였다고 해 볼게요. 그런데 팀원이 다른 편집기에서도 쓰고 싶다고 합니다. 분석기까지 다시 만들어야 할까요? 오늘은 언어 기능을 여러 도구에 붙일 때 LSP가 왜 여전히 필요한지 이야기합니다.

전문가: 핵심은 분석 결과를 구하는 일과, 그 결과를 편집기에 보여 주는 일을 나누는 겁니다. Microsoft의 공식 개요는 LSP를 통해 하나의 언어 서버를 여러 개발 도구에서 재사용하려는 설계를 설명해요. 다만 이 문서의 날짜는 확인되지 않았으니, 최근에 새로 나온 기능 소개는 아닙니다.

진행자: 최근 사례는 따로 준비했죠. 오늘 기준은 2026년 11월 13일이고요. 먼저 약어부터 풀어 주세요.

전문가: LSP는 Language Server Protocol, 언어 서버 프로토콜입니다. 편집기 같은 도구와 언어 분석 서버가 어떻게 대화할지 정한 규약이에요. 자동 완성, 정의 찾기, 오류 진단 같은 기능을 주고받는 공통 약속이라고 생각하면 됩니다.

진행자: 공통 라이브러리 하나를 만들어서 각 편집기에 넣으면 안 되나요? 꼭 서버라는 경계가 있어야 하는 이유가 궁금해요.

전문가: 라이브러리를 공유하는 선택도 있겠죠. 다만 VS Code 공식 가이드는 분석 도구의 구현 언어가 편집기 실행 환경과 다를 수 있다는 문제를 짚습니다. 분석을 별도 프로세스에서 실행하고 규약대로 통신하면, 두 쪽을 같은 언어로 작성하지 않아도 연결할 수 있어요.

진행자: 서버라고 하니까 원격 클라우드 서비스를 먼저 떠올리게 되는데요. 여기서는 다른 프로세스로 분리된 분석 도구라는 쪽에 가깝군요.

전문가: 네. 가이드 예제에서도 편집기 확장이 서버를 실행합니다. 또 분석은 많은 파일을 읽고 구문을 해석하면서 자원을 사용할 수 있어요. 프로세스를 분리한다는 건 편집기와 실행 경계를 나눈다는 뜻이지, 분석에 드는 메모리나 연산이 공짜가 된다는 뜻은 아닙니다.

진행자: 그럼 어디까지 공통으로 만들죠? 모든 언어의 내부 구조를 똑같은 형식으로 맞추려면 그것도 큰일일 것 같은데요.

전문가: 그래서 공식 개요는 구문 트리나 컴파일러의 심벌 모델을 모두 통일하는 접근과 구별해요. 정의 찾기를 예로 들면, 어느 문서의 어느 위치를 물었는지 보내고, 정의가 있는 문서와 위치를 돌려받습니다. 각 언어가 그 답을 어떻게 계산하는지는 서버 안에 남겨 두는 거죠.

진행자: 서버 내부의 사고 과정 전체를 공유하는 게 아니라, 도구가 사용할 질문과 답의 모양을 맞추는 거네요. 식당마다 조리법은 달라도 주문을 받는 방식은 맞출 수 있다는 비유가 떠오릅니다.

전문가: 그 비유에서 주의할 건 주문서가 같다고 요리 수준까지 같아지는 건 아니라는 점이에요. 분석 모델은 각 서버에 남아 있습니다. LSP는 통신을 표준화하지만, 모든 서버가 같은 분석 능력이나 모든 기능을 갖도록 만드는 규약은 아닙니다.

진행자: 편집기와 분석기가 서로 다른 프로세스라면, 제가 지금 고치는 파일도 따로 보고 있을 텐데요. 저장하기 전 내용은 어떻게 맞춥니까?

전문가: 바로 그 지점에서 문서 동기화가 중요해집니다. 공식 개요는 문서를 열면 내용의 기준이 파일 시스템이 아니라 도구의 메모리에 있다고 설명해요. 편집기가 문서를 열었다는 사실과 내용을 알리고, 수정이 생기면 변경을 알려 서버의 문서 표현도 갱신합니다.

진행자: 제가 변수 이름을 바꿨는데 아직 저장하지 않았다고 해 볼게요. 그때 분석기가 디스크의 예전 파일만 보면, 제 커서가 가리키는 내용과 다른 질문에 답할 수도 있겠네요.

전문가: 맞습니다. 그래서 정의 찾기 요청 한 번만 연결하는 것으로 끝나지 않아요. 현재 열린 문서의 변경 내용을 서버와 맞춘 다음, 그 문서의 위치를 기준으로 요청하는 흐름이 필요합니다. VS Code 가이드의 예제는 변경된 부분을 전달하는 방식으로 문서를 동기화합니다.

진행자: 우리 도구에서 자동 완성은 되는데 이름 바꾸기는 안 된다면, 그건 규약을 반만 지킨 제품인가요?

전문가: 꼭 그렇지는 않습니다. LSP에는 capabilities, 지원 기능을 서로 알리는 장치가 있어요. 서버가 정의 찾기를 지원해도 작업공간 전체 심벌 검색은 지원하지 않을 수 있습니다. 클라이언트도 자신이 제공할 수 있는 기능을 알리죠. 연결됐다는 사실만으로 모든 기능을 가정하면 안 됩니다.

진행자: 여기서 지원 기능을 알린다는 건, 이름 바꾸기가 얼마나 정확한지까지 인증한다는 뜻은 아니겠죠?

전문가: 네. 무엇을 요청할 수 있는지와, 그 분석이 어떤 범위에서 타당한지는 별개로 봐야 합니다. 이 차이를 최근의 작은 구현 사례로 살펴보죠. 제작자 lmn451이 2026년 10월 27일에 공개한 CSS 변수 언어 서버 제작기입니다. 구현을 직접 실행해 성능이나 정확도를 검증한 결과는 아니라는 점도 먼저 말씀드릴게요.

진행자: 여기서 CSS는 웹 문서의 스타일을 정하는 Cascading Style Sheets죠. 화면의 색을 직접 보여 주기보다는, 변수의 정의를 찾아가는 문제에 집중해 보겠습니다.

전문가: 글에서 출발한 문제는 변수가 한 스타일 파일에서 선언되고, 다른 컴포넌트에서 쓰이며, 선택자나 프레임워크 설정을 통해 달라질 수 있다는 겁니다. 사용 위치에서 어느 정의가 관련 있는지를 설명하려면 선언 목록만 모으는 것보다 더 많은 맥락이 필요하다는 이야기예요.

진행자: 같은 이름의 변수가 두 군데에 있다고 가정해 볼까요. 둘을 찾아 주는 것과 지금 위치에서 어느 쪽이 적용되는지 설명하는 건 다른 질문이겠네요.

전문가: 제작자는 Rust 서버가 선택자의 우선순위, 소스에 나타나는 순서, DOM 맥락을 추적한다고 설명합니다. DOM은 Document Object Model, 문서의 요소와 계층을 표현하는 모델이에요. 그 맥락을 사용해 커서 위치와 맞는 정의를 설명한다는 겁니다. 모든 웹 실행 상황을 완벽히 재현한다는 주장으로 넓히면 안 됩니다.

진행자: 그 서버를 다른 편집기에서도 쓰게 만든 부분은 무엇인가요?

전문가: 제작기에서 Rust 서버는 LSP를 이해하는 편집기가 실행할 수 있는 독립 실행 파일로 소개됩니다. VS Code 확장은 지원 플랫폼의 Rust 실행 파일을 포함하고, 사용할 수 없으면 TypeScript 서버로 전환해요. Zed 쪽 확장도 Rust 릴리스 실행 파일을 이용하며 편집기별 실행 처리를 맡는다고 설명합니다.

진행자: 여기서 대체 경로가 있다는 말이, 어느 쪽으로 실행되든 기능이 똑같다는 말처럼 들리기 쉬워요.

전문가: 하지만 이 사례는 그 둘을 분명히 구별합니다. 제작기는 Rust 쪽의 문서 맥락 분석과 일부 설정 분석이 TypeScript 쪽과 같지 않다고 밝혀요. TypeScript 구현의 제한 문서도 실제 문서 요소의 부모 자식 계층은 알지 못한다고 적고 있습니다. 대체 경로는 호환성을 위한 경로이지, 기능 동등성의 약속은 아닙니다.

진행자: 그렇다면 같은 정의 찾기 버튼이 떠도, 서버가 무엇을 알고 답했는지까지 봐야겠군요. 오류가 없다는 표시도 너무 크게 해석하면 안 되겠어요.

전문가: 그 점도 제한 문서에 나옵니다. TypeScript 구현의 변수 진단은 변수가 어딘가에 있는지 확인하지만, 지금 맥락에서 접근할 수 있는지까지 확인하는 건 아니라고 해요. 존재 여부를 확인한 결과를 곧바로 올바른 적용 여부의 증명으로 받아들이지 말아야 합니다. 이건 이 구현에 적힌 한계입니다.

진행자: 프레임워크 설정에서도 변수가 나온다고 했죠. 설정이 프로그램이라면, 분석하려고 그 프로그램을 전부 실행해야 할까요?

전문가: 이 제작자는 그렇게 하지 않는 쪽을 택했다고 설명합니다. 지원하는 문자열과 템플릿에서 스타일을 추출하고, Astro의 일부 글꼴 변수 설정이나 Vite의 일부 스타일 주입 설정처럼 알아볼 수 있는 형태를 정적으로 읽어요. 임의의 프로젝트 코드를 평가해서 모든 결과를 구하는 접근이 아닙니다.

진행자: 설정을 실행하지 않으니까 안전이 보장된다고 요약하면 지나치겠네요. 읽을 수 있는 형태를 제한했다는 설명과 보안 인증은 다른 말이니까요.

전문가: 그렇죠. 이 글로 확인할 수 있는 건 분석 범위를 의도적으로 제한했다는 설계 설명입니다. 모든 설정 생성 방식이 지원된다거나, 서버 전체에 보안 문제가 없다고 입증한 자료는 아니에요. 저는 도구를 도입할 때 지원 구문과 빠지는 경우를 같이 확인하겠습니다.

진행자: 분석 서버를 재사용해도 편집기 쪽 작업은 남는다는 얘기로 돌아가 보죠. 연결하는 쪽에서 구체적으로 무엇을 책임져야 하나요?

전문가: 공식 개요는 특정 도구에 언어 서버를 통합하는 방법 자체는 프로토콜이 정하지 않는다고 명시합니다. VS Code 예제는 어떤 서버를 실행할지, 어떤 문서에 연결할지, 무엇을 감시할지 정해요. 확장이 활성화될 때 시작하고 비활성화될 때 정리하는 코드도 클라이언트 쪽에 있습니다.

진행자: 서버를 누가 설치하고, 언제 켜고, 언제 끌지가 실제 사용 경험을 좌우하겠네요. 다른 편집기의 공식 문서에서도 이런 구분이 보이나요?

전문가: Neovim 공식 문서도 편집기는 클라이언트를 제공하지만 서버는 외부에서 제공된다고 설명합니다. 서버 시작 명령, 연결할 파일 형식, 작업공간의 기준 경로를 설정하고요. 실행 중인 클라이언트와 서버를 멈추거나 재시작하는 기능도 별도로 다룹니다. 공통 규약이 설치와 수명주기까지 없애 주지는 않는 거죠.

진행자: 제가 사내 언어 도구를 설계한다면 어떻게 판단해 보면 좋을까요? 처음부터 모든 기능을 채워야 한다는 압박은 피하고 싶거든요.

전문가: 저라면 먼저 재사용하고 싶은 분석이 무엇인지 적겠습니다. 그다음 첫 편집기에서 필요한 기능과 다음 도구에서 필요한 기능을 나눠 보겠어요. 여러 도구가 같은 분석을 원한다면 통신 경계를 두는 이유가 선명해지고, 한 도구의 작은 기능만 필요하다면 직접 통합하는 선택과 비교할 수 있겠죠. 이건 도입을 판단하는 제안입니다.

진행자: 만들고 나서는 어떤 질문을 던져 보면 될까요? 기능 목록만 채우는 것보다 실제 연결 상태를 점검하고 싶어요.

전문가: 저라면 저장하지 않은 변경이 분석에 반영되는지부터 보겠습니다. 지원하지 않는 기능을 요청하지 않는지, 실행 파일이 없는 환경에서 무엇을 안내하는지도 살펴보겠어요. 마지막으로 분석이 답하지 못하는 구문을 넣어 보겠습니다. 통신 성공과 답의 타당성을 별도로 확인하자는 점검 제안입니다.

진행자: 오늘 질문에 답을 붙여 보죠. 표준화할 것은 도구와 분석 서버가 문서, 위치, 기능을 주고받는 약속입니다. 남겨 둘 차이는 언어별 분석 방법과 지원 범위, 그리고 편집기별 설치와 실행 책임이고요. 재사용은 그 차이를 없애는 게 아니라, 다시 만들 필요가 없는 부분을 가르는 데서 시작하네요.

전문가: CSS 변수 서버 사례도 그렇게 읽으면 좋겠습니다. Rust 서버를 여러 도구에 연결할 수 있다는 점과, TypeScript 대체 경로의 분석 범위가 다르다는 점을 함께 보는 거죠. 같은 규약을 쓴다는 사실과 같은 답을 줄 수 있다는 기대를 분리하는 게 중요합니다.

진행자: 참고한 공식 문서와 제작기, 구현의 제한 문서는 설명란에 연결해 두었습니다. 오늘은 언어 분석을 편집기마다 다시 만들지 않기 위해 어떤 경계를 표준화하는지 살펴봤습니다. 들어 주셔서 감사합니다.