2025년에 내가 올린 Rust 관련 PR과 리뷰의 통계, 오픈소스 유지보수에 대한 생각, 그리고 저장소별 PR 목록을 정리한다.
Kobzol's blog- [x]
2026년 1월 5일 | Reddit 토론
연말은 돌아보는 시간이라, 지난 한 해를 되짚어 보아야겠다고 생각했다. 그리고 내 본업이 현재 오픈소스에 기여하는 일인 만큼, 2025년에 내가 열었던 Rust 풀 리퀘스트를 전부 나열해 보는 것보다 더 좋은 방법이 있을까. 이 글에서는 지난 1년간의 Rust 기여 통계와 함께, 요즘 매우 중요한 주제인 오픈소스(Rust) 유지보수에 대한 몇 가지 생각도 공유해 보려 한다.
우선 통계부터. GitHub GraphQL API에 따르면:
plaintext1497
개(2024년 755개에서 +98%)였다.
plaintext1160
개(77.49%)는
plaintextrust-lang
조직 또는 기타 상류(upstream) Rust 작업과 관련된 PR이었다1. 이 글에서는 이것들만 다룬다.
plaintext50
개에 기여했다.
plaintext976
개(2024년 421개에서 +131%)였다.
plaintext753
개(77.15%)는 상류 Rust와 관련된 것이었다2.
이 통계를 계산하기 위해 이 스크립트를 사용했다.
이 숫자들을 보고 꽤 놀랐다. 너무 많은 것 같아서 계산에 사용한 스크립트를 다시 확인해야 했을 정도였다. 하지만 내가 열었던 PR 목록을 훑어보고, Rust에서 내가 해 온 기여를 좀 더 생각해 보니 납득이 갔다. 내가 열었던 PR 수가 많은 이유는, 내가 Rust에서 하는 일이 상당히 유지보수 중심이기 때문이다3. Rust 인프라 팀 구성원으로서, CI를 고치거나 설정/문서를 업데이트하거나 도구를 세팅하는 등 다양한 저장소에 작은 ‘드라이브 바이’(잠깐 들러 처리하는) 기여를 많이 한다. 만약 그 PR들이 전부 새로운 컴파일러/언어 기능 구현 같은 것들이었다면, 1년에 천 개를 여는 건 절대 불가능했을 것이다4.
이런 작업은 집안일처럼 화려하지 않은 경우가 많다. 지난 1년간의 PR 중에서 “이거 멋진 거 했지”라고 누군가에게 보여줄 만한 것은 아마
plaintext50
개도 안 될 것이다. 나머지는 대부분 “해야만 했던” 일들이다. 그리고 그런 일은 정말 많다!
plaintext1160
개 PR이 많아 보일 수 있지만, 상류 Rust 세계에서는 바다의 한 방울에 불과하다. 2025년에는 plaintext rust-lang/rust 저장소 하나만 해도
plaintext10483
(!)개의 풀 리퀘스트를 받았다5. 나는 그중
plaintext307
개만 열었다. 이는 Rust를 유지보수하는 데 얼마나 많은 일이 들어가는지 잘 보여준다(게다가 이것은 가장 중요하고 방대한 저장소 하나에 불과하다). 나는 종종(항상은 아니지만) 내 작업을 밀어붙이기보다 다른 Rust 프로젝트 기여자들의 막힌 부분을 풀어 주는 일을 우선순위로 두려고 한다. 그 편이 장기적으로 더 큰 효과를 내는 경우가 많기 때문이다.
또한 PR을 여는 것은 전형적인 오픈소스 기여자/유지관리자가 하는 일의 일부에 불과하다는 점도 짚고 넘어가야 한다. 나는 코드 리뷰, 설계 문서 쓰기/읽기, Zulip과 GitHub에서의 논의, 블로그 글 읽기/쓰기, 이슈 트리아지, 거버넌스와 의사결정, 영감을 얻기 위한 팟캐스트 듣기, 컨퍼런스 참가 및 발표, 라이브로 못 본 발표 영상 시청, 혹은 강아지 산책하면서 컴파일러 최적화를 생각하기 같은 일도 한다 :) 오픈소스는 코드를 쓰는 것만큼이나 커뮤니케이션에 관한 것이다(그리고 코드 자체도 커뮤니케이션의 한 형태다). 따라서 단순히 ‘열었던 PR 수’만으로 일을 정량화하면 전체 그림을 보여주지 못한다.
특히 기업에 이런 종류의 작업 가치(value)를 설명하기는 꽤 어렵다. 이 문제는 Rust Foundation Maintainer Fund 같은 노력(및 유사한 여러 노력)을 통해 개선하려고 하고 있다. Rust가 어제만큼 오늘도 잘 돌아가게 유지하는 것만 해도 일이 많다. 그리고 새로운 기능을 추가해 앞으로 나아가게 만드는 일은 더 어렵다6. 그래서 나는 Rust를 유지하고 발전시키는 기여자들을 지원하는 것이 매우 중요하다고 생각한다. 그들이 없다면 Rust는 번성하고 진화할 수 없다.
나는 현재 상류 Rust 작업에 대한 자금을 지원받는 ‘운 좋은’ 사람들 중 하나이지만7, 많은 Rust 기여자들은 안정적인 재정 지원을 받지 못한다. Rust Foundation(그리고 Rust 프로젝트)은 풀타임 Rust 유지관리자들을 지속가능하게 지원할 메커니즘을 어떻게 만들지 고민 중이지만, ‘소규모로’ 개별 기여자를 돕는 더 직접적인 방법들도 있다. 마음이 넉넉하다면, 매일 Rust를 더 좋게 만드는 사람들을 개인 후원해 보는 것도 고려해 달라.
아래는 2025년에 특히 눈에 띄는 몇 가지를(순서 없이) 간단히 요약한 것이다. 2025년에 나는:
Leadership Council에 선출되었고 컴파일러 팀에도 초대되었다.
올해는 무려 19(!)개의 프로젝트로 Rust GSoC 프로그램을 다시 주관했다. 결과도 꽤 괜찮았다고 생각한다!
RustWeek와 Rust All Hands에 참석했다. 아마도 내가 가 본 컨퍼런스/이벤트 중 최고였을 것이다.
Linux에서 LLD 링커를 기본값으로 사용하는 이니셔티브가 마무리되도록 도왔다. 마침내 @lqd 및 여러 사람이 해 온 훌륭한 작업이 많은 Rust 사용자에게 전달되었다.
ARM의 James Barford와 함께 Rust 컴파일러 벤치마크 스위트를 크게 개선했다. Rust의 Project Goals 중 하나로 진행된 작업이다. 이를 통해 CI에서 컴파일러 벤치마크를 기다리는 시간이 줄었고, ARM 같은 더 다양한 하드웨어 아키텍처에서 벤치마킹할 수 있는 길도 열렸다.
bootstrap(Rust 툴체인 빌드 시스템)의 심연을 들여다보는 데 건강에 좋지 않을 정도로 많은 시간을 썼다. 리팩터링을 통해 대규모 stage0 재설계가 들어온 뒤 다소 무너진 일관성을 어느 정도 되찾게 만들었다. 하지만 아직 할 일이 많다.
여러 설문조사를 준비하는 데 도움을 줬다(Rust Compiler Performance 설문, Rust Contributor 설문, Leadership Council 설문, Variadic Generics 설문, Safety-critical 설문, 그리고 물론 State of Rust 설문).
인프라와 CI에서 많은 자잘한 개선을 하고 기술 부채를 조금 줄였다. git subtree 동기화를 더 쉽고 견고하게 해 주는 도구를 만들고,
plaintextrust-lang-ci/rust
저장소에서 CI를 옮기는 작업을(드디어!) 도왔으며, plaintext team 저장소에서 crates.io 크레이트 소유자를 동기화했고, Rust 웹을 정적 웹사이트로 옮겼으며, 여기에 멋진것들을 추가했다. 그리고 봇들(주로 triagebot과 bors)에도 많은 개선을 했다.
plaintextcargo build --timings
출력에 링킹 시간 시각화를 구현했다(아직 안정화되지 않음).
plaintext#[derive(From)]
기능)를 작성했고, 채택되었으며 구현까지 했다(https://github.com/rust-lang/rust/pull/144922). 다만 하위 호환되지 않는 이름 해석 문제 때문에 에디션을 넘겨서 적용해야 하므로, 안정화까지는 시간이 좀 걸릴 것이다.
위에 언급한 모든 것은 훌륭한 사람들—바로 그들이 Rust다—의 도움 없이 할 수 없는 팀 작업이었다.
그리고 약속했던 대로, 2025년에 내가 열었던 Rust PR 목록이다. 저장소별로 분류했으며(저장소는 PR 수 내림차순), 각 저장소 안에서는 생성 시간 오름차순으로 정렬했다. 별도 표기가 없는 한 PR은 머지되었지만, 오픈/클로즈된 PR도 열림/닫힘/머지 비율을 보여주기 위해 함께 남겨 두었다.
목록 아래에는 2025년 Rust 기여에 대한 몇 가지 추가 생각과 결론이 있다.
(원문은 매우 긴 PR 목록이 이어집니다. 전체 목록은 제공된 원문과 동일하며, 링크/번호/표기는 그대로 유지됩니다.)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
(생략)
위 목록을 되돌아보면, 꽤 많은 일을 해낸 것 같다. 박사 과정을 마무리하고 연초에는 Rust에 쓸 에너지와 시간이 많았지만, 새로운 가족 책임, 대학 강의, 그리고(설문, 멘토링, 거버넌스 같은) ‘비기술’ 작업이 많아지면서 하반기에는 다소 비생산적이라고 느꼈다. 특히 실제 코딩 측면에서는 더 그랬는데, 코딩은 여전히 내가 가장 즐기고 ‘가장 손에 잡히는’ 느낌을 주는 일이기 때문이다(물론 다른 형태의 일도 중요하다).
사실 2025년에는 내 개인 Rust TODO 목록이 줄기는커녕 오히려 늘었다. 이건 좀 우울하다. 그 이유의 상당 부분은, 박사 과정 동안 앞으로 밀어붙일 여력이 없어서 해를 넘겨 쌓여 있던 이니셔티브들을 마무리하려고 했기 때문일 것이다. 그러다 보니 새로운 아이디어들은 기다려야 했다.
또한 내가 아마도확실히 너무 많은 프로젝트와 이니셔티브를 유지관리하고 있다는 것도 분명하다. Rust 프로젝트에는 좋은 일일 수 있다. 내가 아니면 방치되거나 막혔을 일들을 유지할 수 있기 때문이다. 하지만 나 자신에게도 좋은 일인지는 모르겠다. 나는 여러 이니셔티브를 동시에 처리하는 것에 비교적 능숙하다고 생각하긴 하지만9, 하루에 여러 번이 아니라 한 시간에 여러 번 컨텍스트 스위칭을 한다고 해서, 더 적은 프로젝트에 집중할 때보다 생산성이 높거나 스트레스가 덜하다는 뜻은 아니다. 단기~중기 목표는 기여하는 Rust 프로젝트 수를 줄여서, 나에게 가장 영향력이 크고 즐거운 작업(예: 컴파일러 성능)에 더 집중하는 것이다. 최근 몇 달간은 컴파일러 성능을 거의 건드리지 못했다. 문제는, 내가 “떠나는” 것들을 이어받아 불이 꺼지지 않게 해 줄 사람을 찾는 일이 항상 어렵다는 것이다.
기여를 줄일까 고민하는 영역 중 하나는 Rust 설문 팀이다. 당시엔 다른 사람이 할 것 같지 않아 대부분 그 이유로 참여했다. 설문 분석을 부분적으로 자동화하는 스크립트를 만들긴 했지만, 설문 작업은 내게 그다지 즐거움을 주지 않아서, 다른 사람에게 넘기고 싶다. 하지만 쉽지 않다…
이 글이 흥미로웠길 바란다. Rust를 계속할 수 있는 동안은, 이런 연간 “회고” 글을 정기적으로 써 볼까 생각 중이다. 그러니 1년 뒤에 또 보자 :)
그리고 혹시 궁금해할 사람을 위해 덧붙이자면, 위에 나열한 PR 중 ‘바이브 코딩’으로 만든 것은 하나도 없다. 일반 개발에서는 AI를 많이 쓰지 않지만, GitHub 통계를 모으는 데 사용한 것처럼 일회성 스크립트를 만드는 데는 꽤 유용할 때가 있다.
새해를 맞아 흥미로운 오픈소스 데이터 시각화를 다른 곳에서 본 것이 있다면, Reddit에서 알려 달라.
plaintextrust-lang
조직 밖의 Rust 크레이트들에 대한 기여다. 다만 그런 건 많지 않았고, delegate나 cargo-pgo 같은 내 개인 크레이트에 대한 PR은 포함하지 않았다.↩
내가 열었던 PR과 리뷰한 PR 모두에서 상류 Rust 작업 비율이 이렇게 비슷하다는 게 좀 웃기다.↩
소프트웨어 유지보수에 대한 내 정의를 곧™ 이 블로그나 공식 Rust 블로그에 글로 쓸 계획이다. 기대해 달라.↩
첫 PR은 #134988였다. 평균적으로 하루에
plaintext28
개 이상의 PR이 열린 셈이다.↩
나는 “만약 풀타임 엔지니어 100명을 준다면, Rust 툴체인에서 바로 할 일을 전부 찾아 줄 수 있다”고 종종 말하곤 한다.↩
평균적으로 내 업무 시간의 약 70%를 Rust에 쓰며, 그 전부에 대해 지원을 받고 있다.↩
안타깝게도 이 부분의 컴파일러를 이해하는 사람이 더 필요하다(혹은 내가 그런 사람이 되어야 한다).↩
사실 현실에서는 나도 다른 사람들과 똑같이 컨텍스트 스위칭을 잘 못할 가능성이 크지만, 다른 방식으로 일하는 법을 몰라 기준점이 없다. 또한 한 가지 일에 오래 집중하는 것도 별로 못하는 편인데, 그래서인지 컨텍스트 스위칭에 거의 ‘미루기’의 한 형태로 집착하는 것 같다.↩
Kobzol's blog
프로그래밍 관련 글을 쓰는 블로그.
