Rust Glancer 0.3: 새 트레이트 솔버와 여러 개선

AI 요약

Rust Glancer는 Rust 코드 분석을 위한 언어 서버입니다. 0.3.0에서는 정의 탐색, 인레이 힌트, 호버를 비롯한 기능을 보강했습니다. 글에 나온 88.5%는 완성된 LSP 서버와의 기능 비교가 아닙니다. 작성자가 rust-analyzer와 비교하려고 만든 정적 쿼리 141개에서 얻은 수치이며, 작성자도 실제 기능 전체를 놓고 보면 완성도의 88.5%에 해당하지 않는다고 선을 긋습니다.

편집기 기능 개선

문서 주석에 구문 강조와 내부 링크를 적용했습니다. 에디터와 호버 양쪽에서 문서를 읽기 쉬워졌습니다. Clone, Debug 같은 기본 derive도 지원합니다. 작성자는 proc macro 지원을 먼저 진행할 생각이었지만, 일반 코드 분석부터 더 완성하기로 했습니다. 함수 호버의 시그니처 표시를 다듬었고 코드 블록 접기도 추가했습니다. 그 밖에도 std::ops::Try, 인덱스, 범위 추론을 개선했습니다. 트레이트 메서드에서 정의로 이동하면 트레이트 선언이 아니라 관련 impl로 이동하며, 구현체 검색 결과도 더 많이 표시합니다.

타입 추론과 트레이트 솔버

작성자는 처음에 타입 추론을 직접 이해하며 구현하려고 했습니다. 처음 선택한 방법은 함수 본문 전체를 고정 횟수 반복해서 살피고, 표현식의 타입이 더는 바뀌지 않을 때까지 다시 계산하는 방식이었습니다. 간단하게 시작할 수 있었지만 느렸고, Chalk를 도입한 뒤에는 더 느려졌습니다. 속도를 높이려고 캐시와 각종 최적화를 덧붙이는 과정에서 코드 동작을 이해하기 어려워졌습니다.

이후 rust-analyzer의 접근을 살펴보고 추론 알고리즘을 재작성했습니다. rust-analyzer는 표현식을 불필요하게 반복해서 살피지 않고 재귀 방식으로 처리합니다. 뒤늦게 얻은 타입 정보가 이미 만들어 둔 추론 변수를 해결하도록 설계했습니다. Rust Glancer도 재귀 스케줄러를 적용한 뒤 속도가 빨라졌고, 작성자 설명으로는 코드 구조도 단순해졌습니다.

트레이트 솔버 작업에서는 Chalk의 SLG 솔버를 사용하던 기존 구현을 Rust 컴파일러의 새 솔버로 바꿨습니다. 작성자는 자신이 선택한 SLG 방식이 솔버 상태 관리 문제에 영향을 줬을 가능성을 언급하지만, 원인이라고 단정하지는 않습니다. 새 솔버 통합에는 반복 코드가 필요했지만, 추론 구현을 컴파일러의 타입과 접근 방식에 맞추면서 구조를 개선했다고 설명합니다. rust-analyzer를 참고할 수 있었고 LLM도 활용했기 때문에, rust-analyzer가 새 솔버를 도입한 작업과 같은 수준의 성취로 보기는 어렵다고 덧붙입니다.

작성자는 바퀴를 다시 발명하느라 시간을 썼지만, 타입 추론을 이해하는 데 도움이 됐다고 말합니다. 기존 구현을 계속 확장했다면 기능은 적은데 복잡도만 커져 개발이 막혔을 수 있다고 봅니다. 새 추론 방식과 솔버를 도입한 뒤 인덱싱이 빨라졌고, 이후 확장하기 쉬운 코드가 됐다고 합니다. 다음 버전인 0.4에서는 분석 품질과 지원 사례를 더 늘릴 계획입니다.

유지보수와 배포

LLM을 개발에 활용할수록 코드 유지보수가 더 중요해진다고 작성자는 말합니다. CI에서 벤치마크를 운영하는 도구로 codspeed를 소개합니다. GitHub 실행 환경의 변동에도 성능 회귀 오탐이 없었고, 회귀 원인을 살피는 인터페이스가 유용했다고 합니다. 이전에는 gungraun을 썼지만 codspeed가 자신의 상황에 더 잘 맞았다고 설명합니다. 또 dylint로 Clippy와 비슷한 사용자 정의 린트를 작성해, LLM이 반복해서 잘못 생성하는 코드 스타일을 검사했다고 합니다.

Rust Glancer는 VS Code와 OpenVSX에서 사용할 수 있습니다. Zed용 공식 확장도 제공하며, 글을 게시할 당시 0.3.0 적용 PR이 열려 있었습니다. Neovim은 nvim-lspconfig 설정이 있고, 작성자가 파악한 바로는 Mason 연동도 배포됐지만 0.2 버전을 사용 중이었습니다. 클라이언트 쪽 변경은 없으므로 사전 빌드 파일을 이용해도 된다고 안내합니다.

Reddit 반응

• @u/popzxc — 평소처럼 영어가 모국어가 아니고 글을 쓸 때 LLM을 쓰지 않으므로 어색한 부분이 있다면 양해 바랍니다. 이번 릴리스는 이전 버전보다 개선 사항이 덜 한데 모여 있지만, 상당히 큰 작업이 여럿 있었습니다. 지금 프로젝트 상태가 무척 만족스럽고 다음 릴리스가 기대됩니다. 여러분도 마음에 들어 하길 바랍니다.
  • @u/TRKlausss — 완벽한 영어를 못한다는 이유로, 게다가 글을 다듬을 때 LLM을 쓰지 않는다는 이유로 사과해야 하는 인터넷이라니 참 슬픕니다. 직접 노력해 줘서 고맙습니다. 남의 생각을 그대로 따르지 않아서 좋습니다.
• @u/matthieum — 사실 새 서브레딧 규칙에 걸립니다. 제가 도구를 깜빡했거든요. ‘코드 덤프 금지’ 규칙은 Rust 바이너리와 라이브러리만 다루고 Rust 바이너리는 금지합니다. Rust 바이너리는 보통 Rust 개발자에게 쓸모없다는 게 규칙의 이유입니다. 코드 수천 줄을 뒤져서 드문 정보를 찾거나 아무것도 못 찾는 일을 누가 하겠느냐는 거죠. 하지만 Rust 개발 도구라는 경우를 전혀 고려하지 못했습니다. 이럴 때는 Rust로 만들었다는 사실보다 도구가 Rust 개발자에게 유용하다는 점이 중요합니다. 규칙을 컴퓨터가 아니라 사람이 적용해서 다행입니다.
  • @u/U007D — 새 정책에 들인 고민에 감사드리고 싶습니다. 정책이 시행된 뒤 대화의 질이 크게 좋아졌다고 생각합니다. 정책을 어떻게 개선할지도 계속 고민하는 점이 좋습니다. 고맙습니다.
  • @u/TRKlausss — 그렇다면 이 점을 반영해 규칙을 개정할 예정인가요?
• @u/crimsonscarf — 정확히 짚기는 어렵지만, LLM 특유의 표현이 있더라도 글을 잘 전달하려고 많은 노력을 기울인 느낌입니다. 잘하셨습니다. 계속 작업하고 글쓰기 실력도 다듬어 가길 바랍니다.
  • @u/popzxc — 감사합니다. 어떤 표현에서 LLM 느낌을 받았는지 설명해 주실 수 있나요? 이 글과 블로그의 다른 글도 전부 직접 썼습니다. 대시를 말하는 거라면 몇 년째 하던 대로 하이픈 두 개를 직접 입력한 것입니다. LLM이 제 대시를 가져가게 두지 않겠습니다. LLM과 너무 오래 대화해서 제가 LLM처럼 쓰기 시작한 걸 수도 있겠네요. 그렇다면 고칠 표현을 알고 싶습니다.
  • @u/crimsonscarf — LLM을 써서 글을 썼다고 말하려던 건 아닙니다. 글에 하이픈 두 개가 있고, “그게 제가 선택한 설계였고 꽤 잘 작동했습니다” 같은 짧고 단정적인 문장이 가끔 있습니다. LLM이 그런 문장을 좋아합니다. 글이 나쁘다는 뜻은 아닙니다. LLM 글을 읽을 때 그런 특징을 자주 보게 되고, LLM을 많이 쓰는 사람에게서도 더 자주 보이는 것 같다는 뜻입니다. 그런 표현을 과하게 쓰지 않았고 원래 그렇게 썼을 수도 있습니다. 영어가 모국어가 아니고 LLM을 자주 쓴다고 밝혔는데도 글이 사람답고 자연스럽다는 게 요점입니다.
  • @u/sasik520 — 작성자가 직접 쓴 글이라고 명시했는데도 LLM 특유의 표현을 찾는 건 r/rust의 AI 편집증을 잘 보여주는 사례입니다. 도를 넘었습니다.

원문: Rust Glancer 블로그 / 번역·요약: Trawling