Reddit

Upstream Rust maintenance report (August-September 2026)

Rust 상류 유지보수 보고서: 2026년 8~9월

Sovereign Tech Fellow로 Rust 툴체인을 유지보수하는 작성자가 두 달간의 컴파일러 성능 개선, 빌드 인프라 작업, 저장소 정비를 정리했습니다. 메타데이터 중복 제거로 target 디렉터리 용량을 줄이는 실험을 안정화 단계로 옮겼고, Polonius 성능 개선과 ARM 벤치마크도 진행했습니다.

AI 요약

Rust 프로젝트에서 Sovereign Tech Fellow로 활동하는 작성자가 2026년 8~9월 오픈소스 유지보수 작업을 정리했습니다. 컴파일러 최적화 실험뿐 아니라 CI와 병합 대기열, crates.io 보안, 기여 통계 도구까지 다루며 두 달간의 진행 상황과 수치를 공유합니다.

빌드 산출물과 컴파일러 성능

Rust 크레이트 메타데이터가 빌드 산출물에 중복 저장되는 문제를 줄이기 위해 nightly 채널에서 -Zembed-metadata=no를 기본 적용했습니다. 실제 프로젝트에서는 target 디렉터리 크기가 5~35% 줄어들 수 있습니다. 빌드 시스템은 메타데이터를 .rmeta 파일에만 보관하고, --extern으로 rustc에 전달하는 방식으로 변경하고 있습니다. 컴파일러 쪽 안정화 제안은 FCP 투표 단계에 들어갔습니다. 안정화 플래그인 -Cembed-metadata와 기존 nightly 플래그를 일정 기간 함께 지원한 뒤, 사용자가 옮겨갈 시간을 주고 이전 플래그를 제거할 계획입니다. Cargo 쪽에서는 .rlib, .dylib, .rmeta 산출물의 안정성 보장을 어떻게 다룰지 논의가 남아 있습니다.

컴파일러 성능 개선으로는 문자열 이스케이프의 빠른 경로 추가, 매크로 확장 과정의 불필요한 .clone() 제거, 성능 회귀 수정 등을 진행했습니다. Arena 할당을 여러 컴파일러 자료구조에 적용하는 실험은 뚜렷한 성과를 내지 못했습니다. Cranelift에는 LTO를 적용했지만 개선 폭은 크지 않았습니다.

파서와 Polonius 최적화

Rust 파서의 토큰 표현을 중첩된 트리에서 하나의 평평한 Vec으로 바꾸는 실험에서는 렉싱 성능이 약 30% 개선됐습니다. 그러나 매크로 확장 과정에서 토큰을 자주 수정하는 Rust 컴파일러의 구조와 기존 TokenStream 사용처를 함께 바꾸자 전체 성능은 오히려 나빠졌습니다. 중첩 표현은 구분된 그룹을 따로 할당하는 비용이 있지만, 매크로 확장처럼 토큰을 자주 고치는 작업에는 유리합니다. 작성자는 두 표현의 장점을 결합하는 방법을 더 살펴볼 계획입니다. 파서 상태를 저장할 때 부모 그룹 스택을 매번 복제하는 비용도 조사했지만, 포인터나 불변 자료구조를 쓰는 시도는 성능 회귀를 일으켰습니다.

nightly 기본값으로 전환된 Polonius 차용 검사기는 도입 초기에 serde 검사 빌드에서 기존 NLL보다 명령어 수가 약 15% 많았습니다. 이후 Polonius 담당자들의 최적화로 차이는 약 3~5%까지 줄었습니다. 작성자가 적용한 자료구조 변경도 serde 검사 빌드에서 명령어 수를 약 2% 낮췄습니다. 병렬 프런트엔드는 nightly 기본 활성화를 준비 중이며, ARM에서도 rustc-perf 벤치마크를 기본 실행하기 시작했습니다. 비동기 클로저를 수정할 때 불필요하게 넓은 범위를 다시 컴파일하는 문제를 고친 실험에서는 bors의 증분 재컴파일 시간이 14초에서 8초로 줄었습니다.

CI, 저장소와 배포 보안

bors 병합 대기열의 CI 작업을 CodeBuild에서 EC2 실행기로 옮겨 x64 사전 검사 시간을 약 1시간으로 줄였습니다. PR CI가 끝나기 전 승인자가 @bors r+를 남기면 검사 결과에 따라 병합을 진행하는 기능도 추가했습니다. 여러 PR을 묶은 rollup을 병합한 뒤 개별 PR별 성능 검사를 위해 다시 나누는 작업도 rustc-perf 봇에서 bors로 옮겼습니다. 실패한 작업을 재시도하기 쉬워졌고, 성능 봇 계정의 저장소 쓰기 권한도 없앴습니다.

Rust 프로젝트가 관리하는 crates.io 크레이트는 전용 rust-lang-owner 계정에 소유권을 모으고, CI 기반 Trusted Publishing을 적용하는 작업을 진행하고 있습니다. 개인 계정이 침해돼도 공격자가 배포 설정을 바꾸거나 몰래 새 버전을 올리는 위험을 줄이려는 조치입니다. 이 계정은 몇 주 사이 250개가 넘는 크레이트의 소유자가 됐습니다. 팀 데이터베이스에 크레이트별 담당 팀과 배포 저장소를 연결하고, Rust Zulip 명령으로 팀원이 크레이트를 yanking하거나 복구하는 기능도 마련했습니다.

Git 저장소 동기화에는 git subtree 대신 Josh를 적용하는 작업을 이어갔습니다. rustc_codegen_cranelift와 rustfmt는 이전을 마쳤고, portable-simd, rustc_codegen_gcc, Clippy는 남은 문제를 해결하고 있습니다.

유지보수 도구와 작업량

기여 통계를 만드는 thanks.rust-lang.org의 계산 방식을 다시 작성해, 약 100개 Rust 릴리스의 통계 생성 시간을 10분 이상에서 노트북 기준 약 20초로 줄였습니다. 커밋을 중복 제거한 뒤 한 번씩만 처리하고, 하위 저장소를 병렬로 체크아웃한 결과입니다. 개선된 도구에는 Rustup, crates.io, docs.rs 통계와 여러 프로젝트를 한눈에 보는 페이지도 추가했습니다. 한동안 관리자가 없던 rustup-components-history도 복구하고 CI와 코드베이스를 정비했습니다.

작성자는 두 달 동안 Rust 관련 저장소에 PR 262개를 열고 214개를 리뷰했으며, GitHub에 댓글 889개를 남겼습니다. PR 수정 줄 수의 중앙값은 20줄입니다. 많은 PR이 CI, 문서, 인프라를 손보는 작은 변경이라며 숫자만으로 작업량을 판단하지 말아 달라고 덧붙였습니다. Maintainer in Residence 프로그램은 시작과 함께 7명을 지원했습니다.

Reddit 반응

  • @u/CouteauBleu — tracing이 한동안 유지보수되지 않은 것 같다고 합니다. tracing에 의존하는 크레이트가 많다는 점을 생각하면 안타깝습니다.
    • @u/Tastaturtaste — README에는 Tokio 프로젝트가 tracing을 유지보수한다고 적혀 있습니다. Tokio 프로젝트가 맡기로 한 크레이트가 어떻게 유지보수되지 않을 수 있는지 진심으로 궁금합니다.
  • @u/nnethercote — Jakub은 기계 같네요. 칭찬으로 하는 말입니다.
  • @u/Kobzol — Sovereign Tech Agency Fellowship의 일환으로 지난 두 달 동안 Rust 툴체인 유지보수 분야에서 무엇을 했는지 궁금하다면 이 글을 확인해 보세요.
  • @u/raoul_lu — 훌륭한 작업에 감사합니다. 참고로 목차의 첫 번째 링크가 조금 어긋난 것 같습니다.
    • @u/Kobzol — 감사합니다. 수정했습니다 :)

원문: kobzol.github.io / 번역·요약: Trawling