2026년 9월 Rust 컴파일러 속도를 높이는 방법

Rust 열풍에 결국 새 프로젝트를 Rust로 만들었지만, 정확히는 에이전트들이 만들었지만, 거의 바로 후회하게 됨. 2TB HDD와 24코어를 갖춘 머신도 에이전트들이 각자 샌드박스에서 빌드하자 금세 버거워짐.
TS, Go, Elixir 프로젝트에서는 에이전트 10개 이상을 무리 없이 병렬로 돌렸지만, Rust에서는 작업자를 5개로 제한하고 디스크가 찰 때마다 정리하는 전용 자원 감시 도구까지 만들어야 했음. 다른 언어보다 빌드와 테스트에 훨씬 많은 시간이 들어 개발 진척도 느려짐. 결국 Go로 다시 작성했고, Rust의 실행 성능 이점은 이 비용을 감수할 만큼 크지 않았음.

이번 주말에 컴파일러 팀에 보여주려고 개인 브랜치를 다듬는 중임. rust-analyzer처럼 의존성이 깊게 중첩된 프로젝트에서는 함수 타입 메타데이터를 타입 검사 완료 전에 내보내면 의존하는 다른 크레이트의 컴파일을 더 일찍 시작할 수 있음.
다른 크레이트에는 대체로 필요하지 않은 함수 본문 타입 검사를 기다리는 대신, 가용 작업 슬롯을 모두 활용하는 방식임. 전체 소요 시간 약 40% 단축, 병렬 프런트엔드를 켠 상태에서는 약 10~15% 단축이 가능해 보임.

대기업의 오픈소스 유지보수자 후원이 Rust 사용 경험에 측정 가능한 개선을 만들어내니 반가움. 직원들이 컴파일을 기다리는 시간이 5% 줄었다고 알려주면, Nick을 비롯한 개발자들에게 더 투자할 동기가 될 수 있음.

대여 검사기(borrow checker)를 개선하면서도 5% 빨라졌다는 점이 특히 좋음. 이전에는 검사기가 처리하지 못하던 코드까지 유효하다고 판정할 수 있게 됐으니, 기능과 성능을 함께 얻은 셈임.

OpenAI Codex 팀이 Rust 성능 개선을 위해 100억 토큰 정도를 기부하지 않는 게 의외임.

OpenAI는 Rust Foundation 플래티넘 후원사임. 유지보수자 인건비로 쓸 수 있는 현금을 지원했으니, 내 생각에는 그쪽이 더 나음. 다만 OpenAI의 영향력이 커질 위험을 우려해 반발한 사람도 많아서 모두를 만족시키기는 어려움.
오픈소스 유지보수자에게 무료 구독도 제공함. https://developers.openai.com/community/codex-for-oss 현재는 기간 제한이 있지만 선정 기준은 꽤 관대한 편이며, 이전에는 Rust 기여 이력을 증명할 수 있으면 받을 수 있었음.

OpenAI와 Anthropic 모두 일정 수준 이상 기여하는 오픈소스 유지보수자가 신청할 수 있는 무료 토큰 지원 프로그램을 운영함. 제안한 일이 사실상 이미 이뤄지고 있을 수 있음.

오늘날 소프트웨어에서 가장 중요한 목표 중 하나임. Rust는 에이전트형 LLM의 출력을 코드로 구현하기에 가장 좋은 언어라고 봄. 네이티브 언어이고 설계가 탄탄하며, 언어 설계 덕분에 결함이 적고 필요할 때 사람이 읽고 디버깅하기도 쉬움.
가장 큰 걸림돌은 컴파일 시간이므로 개발 주기를 더 짧게 만들어야 함. 여러 에이전트가 동시에 작업하도록 빌드 산출물 캐시를 비차단 방식으로 만드는 것도 고민해야 함. 큰 작업이겠지만, 에이전트 샌드박스 클러스터를 띄우는 대신 한 머신에서 작업을 가속하려면 필수임. 물론 클러스터가 더 나은 대안일 가능성도 있음.

하드웨어가 충분히 빠르면 Rust 컴파일 시간은 이미 그렇게 큰 부담이 아님.

애초에 컴파일러가 느린 이유가 무엇인가? Rust를 전혀 모르는데, C 컴파일러와 비교하면 어느 정도로 느리며 무엇이 성능을 잡아먹는지 궁금함.

컴파일러가 하는 일에는 비용이 듦. Go가 현대 언어 중 비교적 빨리 컴파일되는 가장 큰 이유는 최적화와 검사를 덜 하고, 파일 하나를 컴파일하려고 수많은 헤더를 읽는 등의 작업을 피하도록 언어를 설계했기 때문임. 좋든 나쁘든 해야 할 일이 적음.
Rust의 수많은 보장과 검사에 매크로, 단형화, 트레이트를 통한 암묵적 코드 생성까지 더해지면 비용이 커짐. 이런 검사를 항상 O(n)이나 O(n log n)으로 구현할 수 있는 것도 아님. 최적화할 여지는 있겠지만, 파레토 최적 경계에서는 검사가 많은 언어가 적은 언어보다 컴파일이 느릴 수밖에 없음. Rust의 결함이라기보다 본질적인 절충임.

무비용 추상화도 컴파일 시간까지 공짜는 아님. 고수준 추상화는 컴파일러가 최적화로 제거해야 할 대량의 상용구 코드로 변환됨.
최적화를 끈 빌드에서는 링커가 병목인 경우가 많음. Rust/Cargo가 빌드 대부분을 병렬화하며 코드와 디버그 정보를 대량 생성해도, 링커는 이를 한꺼번에 처리해야 함. 목적 파일과 실행 파일 형식은 오래전에 설계되어 증분 처리나 병렬 처리가 어렵지만, 이를 시도하는 링커도 있음.

지금도 유효한지는 모르겠지만, 컴파일 시간을 가장 많이 쓰는 부분이 매크로와 코드 생성이라고 들은 적이 있음. 둘 다 Rust 컴파일러 자체에서 통제하기 어려운 면이 있음. 매크로는 거의 임의의 복잡도를 가질 수 있어 작성한 만큼 비용을 치르고, 코드 생성은 LLVM에 의존함. Cranelift로 바꿀 수 있지만 다른 부분에서 대가를 치르게 됨.
제네릭과 단형화도 자주 등장하는 원인인 반면, C++ 등보다 추가로 수행하는 정적 분석 비용은 큰 비중이 아니라는 것이 일반적인 이해인 듯함. 매크로를 가볍게 유지하고 제네릭을 줄이는 등 사용자도 협조해야 효과를 보더라도, 컴파일러 성능 개선은 반가움.

글에서 컴파일러의 속도를 높였다고 해서 곧바로 기존 컴파일러가 느리다는 뜻은 아님. 구체적인 비교 기준 없이 느리다고 하는 것은 의미가 없음.
rustc가 clang보다 얼마나 느리고 왜 느린지는 별개의 복잡한 질문임. 대상에 따라 다르지만 컴파일 시간이 대략 1~5배, 때로는 그 이상 걸릴 수 있다고 봄. 단형화, 복잡한 트레이트 해석과 타입 추론, 대여 검사 등 C보다 훨씬 많은 일을 수행하는 것이 전반적인 이유임.

결국 Rust의 주요 기능을 설계할 때 컴파일 시간을 최우선 고려사항으로 삼지 않았기 때문임. 그 결과를 사후에 완화하는 데는 한계가 있음.

내게 가장 효과가 컸던 방법은 거대한 크레이트 하나를 세 개로 나누는 것이었고, 그제야 병렬 처리 효과가 제대로 나타남.

지금 내 프로젝트에서도 실험 중임. 아직 결론을 내리지는 못했지만 이론적으로는 좋아 보임. 그래도 링크 비용은 그대로 치러야 하지 않나?

이 방법이 주된 해법으로 보임. 여기에 dyn 트레이트를 이용한 의존성 주입을 더하면 Rust의 컴파일 문제를 대부분 해결할 수 있을 듯함. 코드를 작게 나누는 편이 테스트와 에이전트 작업에도 더 나을 수 있음.

에이전트 시대에는 빠른 반복 개발이 큰 이점이라서 대부분의 작업을 Rust에서 Go로 옮겼음. Rust 컴파일은 Go보다 훨씬 느림. Rust가 더 적합한 때도 있지만, 대다수 작업에는 Go로 충분함.