Rust 컴파일러에 기대되는 2026년, 그리고 필자에게도

Rust 컴파일러에서는 차세대 trait solver와 Polonius, 병렬 프런트엔드, LLVM 성능 개선 등 오래 진행한 작업이 함께 진척되고 있습니다. 필자는 이를 새 기능 하나의 성과보다 장기적인 내부 정비와 성능 투자가 결실을 맺는 시기로 설명합니다.

주제: Rust 컴파일러 성능

에디터 노트

가장 설득력 있는 대목은 성과를 개별 최적화 하나의 공으로 돌리지 않고 내부 구조와 성능 관리 방식의 축적으로 설명한 부분입니다. LLVM 회귀를 추적하는 체계와 병합 과정의 성능 분류, query 시스템 정리처럼 작업이 반복될 수 있는 기반을 함께 짚습니다. 다만 polymorphization은 아직 실험이고 두 접근법의 실행 비용도 다릅니다. 이를 확정된 성능 개선으로 읽으면 곤란합니다. 댓글은 Polonius와 never type, Allocator에 기대를 보태지만 직접적인 검증이나 반론은 제공하지 않습니다. 본문도 많은 작업을 열거하는 개요이므로 개별 프로젝트의 출시 시점이나 측정 결과까지 제시하지는 않습니다.

AI 요약

필자는 2026년을 Rust 컴파일러 개발의 장기 투자가 성과를 내기 시작하는 시기로 봅니다. 작업량 자체가 갑자기 늘었다기보다, 여러 해 이어진 타입 시스템과 컴파일러 구조 개선, 성능 작업이 비슷한 시기에 다음 단계에 도달하고 있다는 설명입니다.

타입 시스템과 borrow checker

차세대 trait solver는 타입 시스템의 큰 부분을 다시 구현하는 작업으로, 여러 형태로 거의 10년간 이어졌습니다. 필자는 이 작업이 soundness 버그를 해결하고, async Rust의 문제와 impl Trait의 제약을 비롯해 오랫동안 막혀 있던 기능과 수정 작업을 풀어줄 것으로 기대합니다. 타입 시스템을 깊이 이해한 개발자들이 새 작업에 참여할 수 있게 되는 점도 효과로 꼽습니다.

Polonius는 새 borrow checker 구현입니다. 더 많은 코드가 컴파일되도록 돕고 관련 기능을 열어주며, 필자는 장차 내부 참조도 가능해지기를 기대합니다. 다만 컴파일러에 미치는 영향은 차세대 solver만큼 크지는 않다고 구분합니다.

컴파일 성능과 Cargo

성능 작업은 1~2년간 성과가 정체된 뒤 최근 여러 갈래에서 진척을 보이고 있습니다. 병렬 프런트엔드는 설계에 대한 만족도가 높지 않고 까다로운 문제가 많았지만, 필자는 당장 더 나은 대안이 없고 병렬 처리가 바람직한 목표라서 문제를 하나씩 해결해 왔다고 설명합니다. 현재 프로젝트 목표는 안정화에 가까워졌습니다.

LLVM 23은 rustc 성능에 전반적으로 긍정적인 영향을 줬습니다. LLVM 10 업그레이드에서 10% 성능 저하가 발생한 뒤 LLVM은 성능 회귀를 더 일찍 찾는 체계를 도입했습니다. LLVM 22는 명령어 수(icount) 벤치마크에서는 양호했지만 실제 실행 시간(wall time)은 대부분 나빴고, LLVM 23에서는 새 최적화와 LLVM 자체의 속도 개선이 모두 성과를 냈다고 필자는 이해하고 있습니다.

최근에는 여러 마이크로 최적화와 회귀 대응도 이어졌습니다. 트리 작업을 관리하는 개발자가 성능 영향을 직접 분류하면 회귀 대응 시간이 줄고 PR을 묶는 방식에도 성능 정보가 반영됩니다. Amanieu가 제안한 MIR move elimination 패스는 LLVM이 최적화하기 어려운 복사를 없애 컴파일 시간과 실행 시간을 모두 줄이는 것을 목표로 합니다. Rust 컴파일러가 Rust 코드에 관한 정보를 더 잘 활용하고 MIR 의미도 조정해야 하므로 LLVM보다 MIR에서 처리하는 편이 적절하다는 설명입니다.

Polymorphization은 중복되거나 불필요한 monomorphization을 피하는 방식과 Swift와 비슷하게 제네릭 매개변수의 메모리 배치를 인자로 전달하는 방식이 논의되고 있습니다. 후자는 실행 비용이 생기므로 컴파일러 플래그로 조정하는 구상입니다. 아직 해결할 문제가 남은 실험 단계이며, 차세대 solver가 기존 방식의 polymorphization도 가능하게 할 수 있다고 필자는 덧붙입니다.

Cargo에서는 cargo check와 cargo build가 산출물을 공유하도록 하는 작업이 진행 중입니다. 기본 설정에서 no-embed-metadata를 적용하면 작업량에 따라 target 디렉터리 크기를 5~30% 줄일 수 있습니다. 새 build 디렉터리 구조는 세밀한 잠금과 여러 workspace 사이의 캐싱을 여는 기반이 됩니다. no-link와 link-only 플래그 지원을 고치면 build script와 proc macro의 파이프라이닝도 가능해집니다.

내부 구조와 프로젝트 운영

속성(attribute) 표현과 검사를 통합하는 작업은 마지막 속성까지 새 시스템으로 옮겼습니다. query 시스템 정리는 성능을 개선하고 구조를 더 이해하기 쉽게 만들었습니다. 필자는 이런 구조 개선과 const generics, 쿼리, 증분 컴파일 관련 작업이 컴파일러의 기능을 더 많은 맥락에서 쓰도록 기반을 다진다고 설명합니다.

Rust 프로젝트는 project goals 체계를 다듬었고 Fast Builds 로드맵과 성능 관련 목표를 마련했습니다. Maintainers in Residence 프로그램과 별도 funding team도 생겼습니다. 필자는 지난 한 해 Hexcat이 여러 개발자를 고용한 점도 성과에 기여했다고 언급합니다. 동시에 연초에는 여러 사람이 funding을 잃었고 AI 정책을 둘러싼 논쟁도 있었다고 밝혀, 프로젝트 상황이 모두 긍정적이지만은 않았다고 덧붙입니다.

필자의 참여 계획

필자는 웹 개발 일에서 벗어나 더 기술적인 일을 하고 싶던 중 Rust All Hands에 참석해 프로젝트 개발자들과 직접 논의한 경험을 계기로 Rust 프로젝트에 더 진지하게 참여하기로 했습니다. target 디렉터리 크기 축소 목표에 funding이 충분하면 참여하기로 했고, Maintainers in Residence에도 지원했지만 자금이 제한돼 당장 선정될 것으로 보지는 않습니다. Rust 프로젝트에서 일할 경로가 한 조직의 채용으로 정리되지 않고 신뢰와 관계를 쌓아야 해 시간이 걸릴 것으로 예상합니다. GitHub Sponsors도 열었습니다.

Lobsters 반응

@nrposner — Amanieu의 MIR move elimination 패스가 정말 궁금합니다. 이 주제에 대해 똑똑한 말을 할 수 있을 정도로 알면 좋겠네요!
@mikeyhew — Polonius 소식이 정말 기대됩니다. never type도 곧 안정화된다고 들었습니다! 대단하네요.
- @davidcornu — 네, 1.100은 큰 릴리스가 될 겁니다. never type과 Allocator가 둘 다 포함됩니다.
- @gavinmorrow — 의도한 일은 아니었을 것 같지만 100이라는 숫자가 큰 릴리스가 되는 게 재미있네요.

원문: yoyo-code.com / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗