Rust 컴파일러의 주요 장기 프로젝트, 성능 개선, 프로젝트 목표와 자금 지원의 변화, 그리고 저자의 Rust 프로젝트 참여 여정을 돌아봅니다.
2026년은 Rust 컴파일러에 조금 특별한 해처럼 보인다는 점을 이미 눈치채셨을지도 모릅니다. 정말 많은 일이 벌어지고 있는 듯합니다. 이 글을 쓰기 시작한 뒤에도 몇몇 사항이 이미 발표되었지만, 아직 눈에 잘 띄지 않는 일도 훨씬 더 많습니다. 제가 개인적으로 흥미롭게 생각하는 몇 가지를 공유하겠습니다.
약간의 맥락을 설명하자면, 올해 일어난 일은 여러 서로 다른 이니셔티브가 동시에 마지막 단계에 도달하고 있다는 것입니다. 다시 말해, 2026년이 진행 중인 작업량 면에서 특별한 것은 아니지만, 여러 장기 투자가 결실을 맺기 시작하는 해입니다.
아마 가장 큰 일은 차세대 트레이트 솔버일 것입니다. 이는 타입 시스템의 큰 부분을 재구현한 것으로, 매우 오랫동안 개발되어 왔습니다. 다양한 형태를 거쳐 거의 10년이나 되었습니다. 수많은 건전성 버그를 해결하고, 오랫동안 이어진 문제를 위한 여러 기능과 수정의 길을 엽니다.
이 일이 컴파일러에 얼마나 큰 사건인지 과소평가하기 쉽습니다. 이 작업은 수년간 많은 컴파일러 개발자가 꿈꿔 온 기술 부채의 주요 부분을 해소합니다. 또한 타입 시스템을 새롭고 깊이 이해하는 많은 사람이 새로운 작업을 할 수 있게 합니다. 그로 인해 가능해지는 작업 목록에는 언어의 흔한 불편함이 많이 포함되며, 얼핏 무해해 보이거나 관련 없어 보이는 것들도 있습니다. async Rust의 큰 문제나 impl Trait의 여러 한계에 대한 해결책도 포함됩니다.
또 다른 큰 일은 오랫동안 개발되어 온 새로운 대여 검사기 구현인 Polonius입니다. 더 많은 코드가 컴파일되도록 하며, 내부 참조를 포함한 여러 관련 기능의 길을 엽니다. 적어도 언젠가는 그렇게 되기를 바랍니다. 컴파일러에 미치는 영향은 새 솔버만큼 크지는 않지만, 그래도 상당히 큰 일입니다.
제 주된 관심 분야는 컴파일러 성능이며, 이 분야에서는 꽤 많은 일이 진행되고 있습니다. 1~2년간 일종의 정체기를 겪은 뒤(적어도 결과 측면에서는), 갑자기 여러 일이 한꺼번에 벌어지고 있습니다. 너무 많아서 모든 것을 기억하기조차 어렵지만, 생각나는 것부터 말하자면 다음과 같습니다.
수년 전 불분명한 장애 요인이 많아 몇 년간 중단되었던 매우 오래된 이니셔티브입니다. 몇 년 전 새 기여자인 @SparrowLi와 함께 개발이 다시 시작되었고, 시간이 흐르며 여러 사람이 이 노력에 기여했습니다.
수년에 걸쳐 이것은 거대한 난제 꾸러미로 드러났습니다. 사실상 아무도 이 설계에 정말 만족하지 않는다는 느낌이 듭니다. 하지만 가까운 미래에 더 나은 대안도 없어 보이고, 병렬 프런트엔드는 매우 바람직합니다. 그래서 결국 남은 것이 없을 때까지 성가시고 까다로운 문제들을 하나씩 끈질기게 해결하는 방식이 답이 되었습니다.
현재의 프로젝트 목표는 @petrochenkov이 이끌고 있으며 안정화에 가까워지고 있습니다.
LLVM 23은 성능 면에서 명백하고 예상보다 큰 긍정적 변화였습니다. 오랫동안 LLVM 업그레이드는 rustc 성능에 특별히 좋지 않았습니다. 이는 대규모 10% 회귀를 초래한 LLVM 10 업그레이드 이후 바뀌었고, 현재 LLVM의 수석 개발자인 @nikic은 자신의 블로그 글 Make LLVM fast again에서 이를 지적했습니다. 그 글에서 그는 rustc에 사용하는 것에서 영감을 받은, 시간에 따른 LLVM 성능 추적 시스템도 소개했습니다.
그 이후 LLVM은 성능 회귀를 더 일찍 포착하기 시작했고, rustc의 업그레이드 결과는 “덜 나쁨”에서 “다소 엇갈림”, 그리고 “주의점은 있지만 대체로 긍정적”으로 바뀌었습니다. 그 마지막 사례가 LLVM 22로, icount 벤치마크에서는 녹색이었지만 실제 경과 시간에서는 거의 전반적으로 적색이었습니다.
LLVM 23은 거의 전적으로 긍정적입니다. 저는 LLVM 개발을 그리 많이 따르지는 않지만, 제 이해로는 성능을 악화시키지 않으려는 노력 없이 기능을 개발하는 것과 달리 실제 최적화 작업이 이제 더 많아졌기 때문입니다. 요즘 개선은 새 최적화에서 오기도 하고(이는 부트스트랩 중 컴파일러 최적화에 도움이 됩니다), LLVM 자체가 더 빨라진 결과이기도 합니다.
컴파일러 성능은 지난 몇 달 동안 꾸준히 개선되고 있습니다. 아마 하나의 설명으로는 부족할 것이며, 새 기여자의 유입, 기존 기여자가 더 많은 성능 작업을 할 수 있게 된 점, 그리고 도구 개선과 구조 정리가 결합해 새 기회를 열어 준 결과일 것입니다.
이 분야에서 작업하는 사람이 늘면서, 특정 아이디어가 몇 사람의 머릿속을 오가는 상호 수분도 많이 보게 되었습니다. 사람들이 서로의 풀 리퀘스트에서 영감을 받고 관련된 시도를 하기 때문입니다.
또한 회귀를 관리하는 능력, 즉 분류하고 대응하는 능력이 크게 좋아졌다고 느낍니다. 이는 부분적으로 도구에 대한 투자 덕분이지만, 절차와 사회적 구조에 관한 일이기도 합니다. 여기서 중요한 발전은 특히 @JonathanBrouwer로 대표되는 트리 운영과 성능 분류의 연결입니다.
이는 병합을 관리하는 사람들이 성능 영향을 직접 분류하는 경우가 많다는 뜻입니다. 대응 시간을 줄인다는 점에서 중요하지만, 이 연결은 다른 이유에서도 유용합니다. 예를 들어 성능 영향은 풀 리퀘스트를 롤업으로 묶는 방식을 알려 줍니다. 콘웨이의 법칙은 여전히 법칙인 것으로 드러났습니다.
저는 사람들이 측정 결과를 해석하고 회귀를 진단하도록 돕는 일도 무척 즐깁니다. 수년간 매일 결과를 살펴본 사람이 몇 문장만 해도, 회귀가 해결되도록 하는 데 큰 도움이 되는 경우가 많습니다.
종합하면, 컴파일 시간에 대한 우려가 그 어느 때보다 개발 과정에 잘 통합되어 있다는 느낌입니다.
이것은 올해 초 갑자기 등장한 듯하며, 꽤 흥미롭습니다. @Amanieu는 LLVM이 최적화하기 어려워하는 복사를 컴파일러가 제거할 수 있도록 하는 MIR 최적화 패스를 제안했습니다. 이는 컴파일 시간과 실행 시간을 모두 단축합니다.
이는 LLVM 대신 MIR에 구현하는 것이 타당한 패스 중 하나입니다. 컴파일러의 Rust 부분이 이것을 Rust에 특별히 적용해도 유효한지에 관한 더 나은 정보를 갖고 있기 때문입니다. MIR 의미론 자체를 약간 바꿔야 한다는 점까지 고려하면 더욱 그렇습니다.
Rust가 주된 LLVM 대상인 C(++)보다 일반적으로 더 많은 이동을 생성하기 때문에, 이는 특히 Rust에 중요합니다.
이것은 제가 아주 오랫동안 노력을 지켜봐 왔기에 특히 애착이 갑니다. 다형화는 우리가 할 수 있는 컴파일러 성능 최적화 중 가장 영향력 있는 것 가운데 하나이지만, 안타깝게도 구현하기가 정말 까다롭습니다.
제가 아는 한 이것은 세 번째 실험입니다. 이번에는 이전 것들과 약간 다르며, Swift의 유사한 메커니즘에서 영감을 받았습니다.
차이는 원래의 다형화가 중복되거나 불필요한 단형화만 피하려 한다는 점입니다. 따라서 이는 실행 시간 영향이 없는 순수한 컴파일 시간 최적화입니다. 반면 Swift 스타일 방식은 모든 것을 다형화하고 제네릭 매개변수의 레이아웃을 인수로 전달하려 합니다. 이는 실행 시간 비용이 있으므로 컴파일러 플래그로 조정할 수 있는 대상이 될 것입니다.
제 이해가 아직 최신이라면, 차세대 솔버는 원래 의도한 방식의 다형화도 가능하게 할 것입니다. 어느 쪽이든 두 선택지는 같은 문제에 부딪히므로, 이 작업은 양쪽 모두에 유용합니다. 두 선택지가 이 같은 노력에서 모두 나올 가능성도 있습니다. 어느 쪽이든 이는 해결해야 할 문제가 많은 실험일 뿐이므로, 결과가 어떻게 될지는 기다려 봐야 합니다. @camelid가 프로젝트 목표를 제안하고 이끌고 있습니다.
cargo check와 cargo build의 캐시 공유🔗@blyxyas는 cargo가 cargo check와 cargo build 사이에서 아티팩트를 공유할 수 있도록 하는 프로젝트 목표를 작업하고 있습니다. 목표 자체는 실제로 더 일반적이지만, 이것이 아마 가장 알아보기 쉬운 결과일 것입니다. 우리는 이를 오랫동안 원했으므로, 이 방향에서 진전이 보이는 것은 정말 멋진 일입니다.
이는 이미 발표되었으며, 작업 부하에 따라 대상 디렉터리 크기를 5~30% 줄일 것입니다.
이 역시 이미 발표되었으며, 꽤 오랫동안 진행되어 온 또 하나의 프로젝트입니다. 위의 다른 사항들과 마찬가지로, 이는 다른 일을 가능하게 하는 주요 내부 구조 개편입니다. 구체적으로는 대상 디렉터리의 세분화된 잠금과 워크스페이스 간 캐싱입니다.
no-link/link-only🔗@bjorn3는 빌드 스크립트와 프로시저 매크로의 파이프라이닝을 가능하게 하는 이 두 플래그의 지원을 수정하는 작업을 해 왔습니다. 제안에서 볼 수 있듯, 이는 내부 문제와 구조적 문제의 긴 목록을 고치다가 어느 순간 큰 기능이 가능해지는 또 하나의 작업 흐름입니다.
컴파일러 구조에 관한 여러 이니셔티브가 있었습니다. 큰 일은 갑자기 등장하는 일회성 대형 프로젝트에서 일어나는 것이 아니라, 건강한 시스템에 대한 지속적인 장기 투자의 결과로 일어난다는 점을 다시 한번 강조하기 위해 몇 가지만 언급하겠습니다.
2년 전 @jdonszelmann은 컴파일러에서 속성을 표현하고 검사하는 방식을 통합하고 정리하는 노력을 시작했습니다. 불과 며칠 전 마지막으로 남은 속성이 새 시스템으로 이식되었습니다. 이는 속성 검사 방식을 크게 개선하고 진단 및 다른 부분의 개선을 가능하게 합니다.
올해 초 @Zalathar와 @nnethercote는 rustc의 쿼리 시스템 구현을 정리했습니다. 이는 성능을 개선했을 뿐 아니라, 더 중요하게는 시스템을 이해하기 쉽게 만들었습니다. 이전에는 이것이 시스템을 개선하는 데 자주 장애물이 되었습니다. 이 시스템은 여전히 코드베이스에서 꽤 무서운 부분이지만, 이는 큰 진전입니다.
사실 이 분야에는 더 많은 구조 작업이 있습니다. @oli-obk는 확장 시점 평가를 위한 구조적 토대를 작업해 왔고, @cjgilot, @petrochenkov, 그리고 제가 잊은 다른 분들(죄송합니다)이 쿼리와 증분 컴파일 전반에 많은 작업을 했습니다. 마찬가지로 const 제네릭이 더 나아갈 수 있도록 하는 작업도 많이 이루어졌습니다. 이러한 노력의 공통된 주제는, 이전에는 주로 일부 컴파일 단계의 엄격한 순서 때문에 제한되던 더 많은 맥락에서 컴파일러가 자신의 기능을 사용할 수 있게 한다는 점입니다.
메타적인 일도 꽤 많습니다. Rust 프로젝트는 “프로젝트 목표”라는 새 조직 프레임워크를 실험해 왔습니다.
여러 변경과 실험을 거치며 여러 차례 반복되었지만, 마침내 이 시스템이 최적의 안정 상태에 도달했고 그 이점이 드러나고 있는 듯합니다. 위 목록에서 이를 분명히 볼 수 있다고 생각합니다.
이제 빠른 빌드 로드맵과 여러 성능 관련 프로젝트 목표가 있습니다. 꽤 흥미진진합니다.
자금 지원에도 여러 새로운 변화가 있습니다. 하나는 프로젝트 목표에 명시적으로 연결되어 있고, 새로운 “상주 유지 관리자” 프로그램도 생겼으며, 새 자금 지원 팀도 구성되었습니다.
지난 한 해 동안 Hexcat가 여러 사람을 고용한 결과가 얼마나 많이 나왔는지도 눈에 띕니다.
마지막으로, 2026년은 저에게도 흥미진진한 해입니다. 몇 년간 곁에서 지켜보다가 마침내 성능 분류 작업에 합류한 뒤, 저는 Rust 프로젝트를 더 진지하게 작업하기 시작하기로 결정했습니다.
올해 초에는 다음으로 무엇을 할지 결정해야 한다는 점이 분명해졌습니다. 현재 작업은 서서히 마무리되어 유지 관리로 바뀌고 있었고, 웹 기반 작업에는 약간 지치기 시작했습니다. 한동안 저는 더 기술적이고 도전적인 무언가로 돌아가고 싶다는 욕구를 느껴 왔습니다.
몇 가지 선택지를 고려했지만, 그중 무엇을 선택할지 다소 결정하지 못했습니다. Marie Kondo의 표현을 빌리자면, 딱히 “설렘을 주는” 것은 없었습니다. 어느 날 저녁, 지치는 일들을 겪고 이 모든 일로 약간 기분이 가라앉아 있던 중 Rust All Hands 초대장을 받았습니다. 기분 좋은 놀라움이었습니다. 그해 초에 신청하기는 했지만, 초대받을 가능성을 알지 못했기에 큰 기대는 하지 않았습니다. 저는 이것을 우주가 준 일종의 신호 같은 것으로 받아들이고 여행을 예약했습니다.
경험은 압도적으로 긍정적이었습니다. 오랜만에 참석한 행사 중 가장 흥미진진한 행사 가운데 하나였다고 말해야겠습니다. 제 삶에는 거의 누구와도, 특히 현실에서, 나누지 못하는 커다란 부분이 있다는 사실을 다시 떠올리게 했습니다. 실제로 다시 경험하기 전까지는 그것을 잊기가 너무 쉬운 듯합니다.
물론 Rust 컴파일러의 흥미로운 측면 몇 가지를 친구들과 이야기할 수는 있습니다. 하지만 실제로 작업하며 여러분이 말하는 바를 깊은 수준에서 이해하는 사람들과 이야기하는 것은 완전히 다른 차원입니다. 작업을 통해 알던 사람들을 만나고 언어 개발에 관한 토론에 참여할 수 있어 정말 좋았습니다.
긴 이야기를 짧게 하자면, 이것이 바로 제가 하고 싶은 일이라는 점이 분명해졌습니다. 전에도 생각해 봤지만, 제 감정을 의심하지 않고 결정을 내리도록 강제할 강한 “설렘의 순간”이 필요했던 것 같습니다.
물론 이제 문제는 실제로 어떻게 그것을 해내느냐입니다. 아시겠지만(위에서 약간 암시했듯이), 이 프로젝트에서 일자리를 찾는 일은 정확히 말해 간단하지 않습니다. 이력서를 보낼 수 있는 “Rust 주식회사”는 없습니다. 각자가 어떻게든 자신만의 길을 찾는, 분열되어 있고 다양한 가능성의 공간이 있습니다.
새 프로그램들 덕분에 더 접근하기 쉬워지고는 있지만, 그래도 시간이 좀 걸릴 것으로 예상합니다. 그 일부는 인맥과 신뢰에 달려 있고, 그런 것들은 시간에 걸쳐 쌓입니다. 서두를 필요는 없으므로, 무언가를 알아낼 때까지 계속 작업할 것입니다.
충분한 자금이 있다면 대상 디렉터리 크기 감소 프로젝트 목표를 작업하기로 합의했습니다. MiR 프로그램에도 지원했지만, 자금이 제한되어 있고 이 특정 자금이 필요한 더 중요한 분야가 있기 때문에 곧 가능해지지는 않을 것 같습니다.
참고로 GitHub Sponsors도 열었으니, 컴파일러 성능 작업을 지원하고 싶으시다면 자유롭게 함께해 주세요 ;)
프로젝트에서 너무 많은 일이 벌어지고 있어서, 이를 제대로 다루는 일이 정말 어렵게 느껴집니다. 흥미로운 작업을 아주 많이 빠뜨린 것 같지만, 어디선가는 멈춰야 합니다. 이 불완전한 개요만으로도 흥미로웠기를 바랍니다.
모든 일이 긍정적이지만은 않았다는 점도 말해야 할 것 같습니다. 연초에는 많은 사람이 자금 지원을 잃은 일과 인공지능 정책을 둘러싼 격렬한 논의가 그림자를 드리웠습니다. All Hands 불과 며칠 전에 누군가가 정책 초안을 소셜 미디어에 게시했고, 작은 운영 팀과 다른 사람들은 피해를 제한하려 애쓰며 스트레스가 큰 주말을 보냈습니다.
그런 점에서 All Hands는 모두가 재충전하고, 다시 집중하며, 긍정적인 에너지를 프로젝트로 가져갈 수 있었던 전환점이었다는 느낌이 듭니다. 저는 분명 그렇게 느끼며, 저 혼자만은 아니기를 바랍니다.