러스트 언어 서버(LSP) 직접 만들어보면 왜 멘붕 오는지 아시나요? 개발자의 찐 개발기

요약 실험적인 러스트 언어 서버 'Rust Glancer'의 개발자가 작성한 글로, 러스트용 언어 서버(LSP)를 만드는 과정이 왜 생각보다 훨씬 까다롭고 복잡한지를 아키텍처 관점에서 설명하고 있습니다. 과거 rust-analyzer 관련 기술 글을 활발히 쓰던 개발자 matklad의 글이 뜸해진 상황에서, 저자는 실제 개발 경험을 바탕으로 기술적 난제들을 공유했습니다. 개발자가 꼽은 핵심 문제 중 하나는 LSP가 '불완전한 정보 속에서도 즉시 유용한 결과를 내놓아야 한다'는 점입니다. 전체 크레이트가 완전히 컴파일되어야 끝나는 일반적인 컴파일러와 달리, LSP는 에디터가 켜지자마자 프로젝트 전체를 인덱싱하느라 사용자를 수십 초 동안 기다리게 할 수 없습니다. 이 때문에 초기화 요청이 오면 최소한의 설정만 검증하고 곧바로 응답해야 하며, 그 직후 쏟아지는 파일 오픈, 심볼 분석 등의 요청을 처리해야 합니다. 또한 LSP 프로토콜 자체는 파일시스템 대신 열려 있는 문서와 편집 내역만을 다루도록 설계되어 있지만, 실제 코드 분석을 위해서는 전체 파일시스템 접근이 필수적이라는 구조적 괴리가 존재합니다. 게다가 에디터 외부에서 파일이 변경되거나 동기화가 어긋나는 문제를 방지하기 위해 가상 파일 시스템(VFS)을 메모리에 구축하고 소스 세대(generation)를 관리해 레이스 컨디션을 막아야 하는 등 수많은 엔지니어링 난관이 뒤따른다고 전했습니다.