메모리 100분의 1로 줄인 Rust LSP, '러스트 글랜서'가 던진 질문

러스트(Rust)로 개발해 본 사람이라면 rust-analyzer의 메모리 사용량 앞에서 한 번쯤 한숨을 쉬어봤을 것이다. 코드 자동완성, 정의로 이동, 타입 힌트 같은 편의 기능을 제공하는 이 언어 서버는 강력하지만, 그만큼 램(RAM)을 넉넉히 먹는다. 최근 공개된 '러스트 글랜서(Rust Glancer)'는 바로 이 지점을 정면으로 겨냥한 대안 LSP 구현체다. 개발자는 4개월간 혼자 작업했다고 밝혔으며, 시연 영상 내내 사용 메모리가 100MB 아래에 머물렀다고 강조한다. 8GB 램을 탑재한 2020년형 맥북 프로 M1에서 테스트했을 때도 쓸 만했다는 것이 그의 설명이다.

왜 다른 설계를 택했나

러스트 글랜서의 핵심은 rust-analyzer와 정반대되는 아키텍처 결정에 있다. rust-analyzer는 키 입력 한 번마다 즉각 반응하기 위해 분석 결과를 메모리에 상주시키는 증분(incremental) 방식을 택했고, 이 선택은 속도라는 목적에는 잘 들어맞는다. 반면 러스트 글랜서는 '증분 LSP를 아예 포기하면 어떨까'라는 발상에서 출발한다. 워크스페이스를 한 번 인덱싱해 그 결과를 파일시스템에 저장해 두고, 쿼리가 특정 정보를 필요로 할 때마다 그때그때 디스크에서 로드해 쓴다. 분석 결과는 저장(save) 시점에 갱신되는 '얼어붙은(frozen)' 상태로 유지된다.

이 방식이 공짜는 아니다. 파일시스템에서 데이터를 읽어 역직렬화하는 일은 메모리에서 꺼내 쓰는 것보다 본질적으로 느리다. 개발자는 이를 완화하기 위해 몇 가지 트릭을 동원했다. 타이핑할 때마다 전체 분석을 다시 돌리는 대신, 현재 편집 중인 코드 본문만 얕게 분석하고 이전에 완성된 인덱스를 재활용하는 식이다. 덕분에 자동완성은 무리 없이 빠르지만, 대신 새로 추가한 임포트나 구조체, 트레잇 같은 항목은 문서를 저장하기 전까지 인덱싱되지 않는다는 제약이 생긴다. 개발자는 이 감각에 금방 익숙해진다며 직접 써보길 권한다.

이미 쓸 만하지만, 완성품은 아니다

4개월은 러스트 LSP처럼 방대한 프로젝트를 완성하기엔 짧은 시간이다. 개발자 본인도 러스트 글랜서가 아직 완전하지 않으며 누락된 기능과 알려진 버그가 있다고 인정한다. 그럼에도 타입 추론과 트레잇 해석기(chalk)를 포함한 전체 인덱싱 파이프라인을 갖췄고, 일반적인 러스트 문법 대부분과 정의로 이동·호버·인레이 힌트·자동완성 같은 표준 LSP 동작 상당수가 작동한다. 개발자는 약 한 달 반 전부터 rust-analyzer 대신 이 도구를 상시 개발 환경으로 쓰고 있다고 밝혔다. VS Code 확장으로 설치하거나 저장소에서 직접 빌드해 시험해볼 수 있다.

흥미로운 지점은 에이전트 기반 워크플로에 대한 대응이다. AI 에이전트가 코드를 편집할 때 rust-analyzer에서는 인레이 힌트가 어긋나는 현상이 관찰되는데, 러스트 글랜서도 초기엔 같은 문제를 겪다가 자체 파일 감시기를 구현해 해결했다고 한다. 또 에디터 바깥에서 일어나는 변경에는 서버가 더 낮은 우선순위를 부여해, 에이전트가 대량으로 파일을 수정해도 급격한 재인덱싱이 일어나지 않도록 설계했다. 에이전트 코딩이 늘어나는 흐름을 염두에 둔 실용적 판단으로 읽힌다.

LLM으로 만든 코드를 둘러싼 태도

이 프로젝트는 원래 'LSP'가 아니라 '러스트용 스마트 ctags'를 목표로 시작됐다. 개발자는 러스트를 7년간 다뤄왔고 rustc·clippy·rust-analyzer에 기여한 경험이 있어, 자신의 러스트 지식이면 완전한 LSP 없이도 더 가볍고 단순한 도구로 충분하리라 봤다. 그러나 선언부 인덱싱에서 시작한 작업이 본문 분석, 단순 타입 전파, impl 헤더 매칭 기반 트레잇 해석으로 하나씩 확장되면서 결국 '진짜 LSP'가 되어버렸다. 표준 라이브러리(sysroot)가 나이틀리 기능에 의존한다는 사실을 뒤늦게 깨달은 대목은 이 여정의 예측 불가능함을 잘 보여준다.

개발자는 이 프로젝트가 LLM을 적극 활용해 만들어졌지만 '바이브 코딩'은 아니라고 선을 긋는다. 모든 풀 리퀘스트를 직접 검토하며, 1만 줄이 넘는 대규모 diff라도 며칠 간격을 두고 반영한 깃 이력이 그 증거라는 것이다. 그는 LLM이 도메인 전문가 역할은 잘하지만 큰 프로젝트를 스스로 끌고 가는 데는 약해서, 코드가 잠시 나빠지더라도 자신이 배워가며 개선하는 과정을 반복했다고 설명한다. 그러면서 'AI가 짠 슬롭'이 아니라 '내 코드, 내 슬롭으로 불러달라'는 요청을 덧붙였다. 이는 오늘날 개발 커뮤니티에서 LLM 활용 코드를 둘러싼 논쟁의 온도를 그대로 드러낸다.

실무자가 새겨둘 지점

러스트 글랜서는 rust-analyzer의 대체재라기보다 다른 트레이드오프를 택한 선택지다. 개발자 스스로도 'rust-analyzer보다 모든 면에서 나은 도구'가 되는 일은 거의 없을 것이라 못박는다. 완전성과 키 입력 단위의 정확성이 중요한 프로젝트라면 rust-analyzer가 여전히 기본값일 것이고, 러스트 글랜서는 성능이 약한 장비를 쓰거나 램 절약을 위해 약간의 불편을 감수할 수 있는 사용자에게 맞다. 다중 디스플레이에 여러 IDE를 띄워 16GB까지 치솟던 개발자 본인의 사용 패턴이 이 도구가 겨냥하는 전형적 상황이다.

한계도 분명하다. 신뢰할 수 없는 코드 실행이 필요한 빌드 스크립트나 프로시저 매크로 호출 지원처럼 처음부터 계획에서 배제된 영역이 있고, 나이틀리 기능이나 새 트레잇 솔버 이관 같은 작업은 프로젝트가 안정 버전에서 성숙해질 때까지 뒤로 미뤄져 있다. 결국 지금 시점에서 러스트 글랜서는 '가벼움을 위해 무엇을 포기할 것인가'라는 질문을 도구 형태로 던진다. 메모리 예산이 빠듯한 개발자라면, 저장 시점 인덱싱이라는 낯선 감각을 며칠 견딜 각오로 한 번쯤 시험해볼 만하다.