# 더 건강한 Clippy를 위한 공동 리뷰 제안

> Clean Markdown view of GeekNews topic #31222. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31222](https://news.hada.io/topic?id=31222)
- GeekNews Markdown: [https://news.hada.io/topic/31222.md](https://news.hada.io/topic/31222.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-08T09:09:55+09:00
- Updated: 2026-07-08T09:09:55+09:00
- Original source: [blog.rust-lang.org](https://blog.rust-lang.org/inside-rust/2026/07/06/unite-for-clippy/)
- Points: 1
- Comments: 1

## Topic Body

- Rust 린터 **Clippy**는 최근 몇 달간 풀 리퀘스트 리뷰 병목을 겪고 있어, 기여자들이 서로의 변경을 먼저 살펴보는 공동 리뷰 절차를 도입함
- 유지보수 작업에 **자금 지원을 받는 Clippy 팀원**이 없어, 리뷰와 관리 부담이 메인테이너의 자유 시간에 집중되고 번아웃 위험이 커짐
- 새 절차에서는 기여자가 풀 리퀘스트를 열면 **@rustbot**이 아직 리뷰가 없는 다른 풀 리퀘스트를 우선 살펴보도록 안내함
- 다른 기여자의 풀 리퀘스트를 리뷰한 사람은 **secret list**에 올라가며, 이후 자신의 풀 리퀘스트가 팀 리뷰어에게 우선순위를 받음
- Clippy 팀은 **Rust Foundation Maintainers Fund**와 커뮤니티 참여가 메인테이너 부담을 줄이고 프로젝트 상태를 개선하는 데 도움이 되길 기대함

---

### Clippy가 겪는 리뷰 병목
- **Clippy**는 많은 기여자가 기능과 버그 수정을 풀 리퀘스트로 제출하는 Rust 린터 프로젝트임
- 최근 몇 달간 리뷰 역량이 부족해 풀 리퀘스트 처리에 병목이 생김
- 다른 일부 Rust 팀과 달리, 현재 Clippy 팀에는 Clippy 작업에 대해 자금을 받는 사람이 없음
  - 파트타임 기준으로도 지원을 받는 사람이 없음
  - 유지보수 부담은 메인테이너의 자유 시간에 놓임
  - 이런 구조는 번아웃으로 이어질 수 있음
- 팀은 새로 만들어진 **Rust Foundation Maintainers Fund**가 Clippy 메인테이너 자금 확보에 도움이 되기를 기대함
  - 기여를 원하는 사람은 [Rust Foundation Sponsors](https://github.com/sponsors/rustfoundation)에 기부할 수 있음

### 기여자가 서로 리뷰하는 절차
- 새 절차의 목표는 기여자들이 서로를 도와 풀 리퀘스트가 더 빠르게 리뷰되고 병합되도록 만드는 것임
- 기여자가 풀 리퀘스트를 열면, 다른 기여자의 풀 리퀘스트를 먼저 살펴보는 흐름으로 진행됨
  - 각 기여자는 최소 하나의 풀 리퀘스트를 리뷰함
  - 다른 사람의 기여가 오래 방치되지 않도록 하기 위한 구조임
- [@rustbot](https://github.com/rustbot)은 새 풀 리퀘스트 작성자에게 다른 풀 리퀘스트를 살펴보라고 안내함
  - 가능하면 아직 리뷰가 없는 풀 리퀘스트가 우선 대상임
- 리뷰를 마친 기여자는 특별한 **secret list**에 올라감
  - 이후 자신의 풀 리퀘스트는 팀 리뷰어에게 우선순위를 받음
- 이 방식은 Bevy 프로젝트의 [Open Code Review](https://shaping.systems/blog/open-code-review/) 시스템에서 영감을 받음
- Clippy는 이전에도 프로젝트 건강 상태를 개선하기 위한 업데이트를 진행한 적이 있음
  - 2025년 [Feature Freeze](https://blog.rust-lang.org/inside-rust/2025/10/22/clippys-feature-warming-up/)는 성공적이었음
  - 그 과정에서 팀은 지식, 신뢰, Rust 커뮤니티가 Clippy와 올바른 작업 방식에 관심을 가진다는 확신을 얻음
- Clippy 팀은 커뮤니티의 도움으로 Clippy가 더 강하고 건강해질 수 있다고 봄

## Comments



### Comment 61408

- Author: neo
- Created: 2026-07-08T09:09:56+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/709awc/together_for_healthier_clippy) 
- 솔직히 이번 발표보다, 글에 링크된 Bevy의 공개 리뷰 프로세스가 더 흥미로웠음. 예전에 [여기에도 올라왔지만 별로 논의되지는 않았던 글](https://lobste.rs/s/puaytj/open_code_review)인데, 정말 사려 깊고 똑똑한 접근이라고 봄  
  잘 작동한다니 기쁘고 놀랍지는 않음. Clippy도 비슷한 결과를 얻으면 좋겠음
  - 그 글 올린 게 나였음. 예전에 **Bevy 게임 엔진**에 꽤 활발히 기여했고, 리뷰 프로세스도 꽤 마음에 들었음  
    이 시스템은 작고 점진적인 PR을 장려하는데, 누구나, 심지어 첫 기여자도 훨씬 쉽게 리뷰할 수 있기 때문임. 큰 PR은 병합까지 훨씬 오래 걸렸고, 그래야 맞다고 봄. 리뷰가 더 어렵고 코드에 대한 어느 정도의 이해가 필요하니까. 보통 큰 기능이 많이 들어간 PR은 유지관리자나 해당 분야 전문가가 마무리까지 밀어줬음  
    그 글이 좋았다면 같은 작성자의 Bevy 유지보수 관련 글인 [Triage-by-controversy and community review](https://www.leafwing-studios.com/blog/triage-by-controversy/)와 [The Tyranny of Nits](https://www.leafwing-studios.com/blog/tyranny-of-nits/)도 좋아할 수 있음
  - Bevy에 기여해 본 적은 없지만, 그들의 [워킹 그룹](https://bevy.org/learn/contribute/project-information/working-groups/) 구조는 도입 이후 좋은 결과를 낸 것처럼 보임

- 내가 기여하는 오픈소스 프로젝트에서 PR 리뷰를 잘 돕지 않는 이유 중 하나는, 전문성이 거의 없어서 내가 그럴 자격이 있는지 확신이 안 들기 때문임  
  **Clippy와 Bevy의 프로세스**는 경험이 적은 리뷰어도 정당하게 참여할 수 있게 해주는데, 꽤 괜찮은 방식이라고 봄

- 제목만 보고는 [기대했던 것](https://en.wikipedia.org/wiki/Office_Assistant)과는 좀 달랐음
  - 맞음. 글만 보면 **Clippy가 실제로 무엇인지** 분명하지 않음. [알고 보니 Rust 린터였음](https://github.com/rust-lang/rust-clippy)

- 계정 몇 개를 만들어서 여러 계정으로 PR을 제출하면 쉽게 악용할 수 있어 보임  
  그렇게 해서 얻을 게 뭔지는 잘 모르겠지만, 멋진 기여자들의 비밀 목록에 올라간다는 것 자체가 유인이 될 수 있음
  - 이 방식에 영감을 준 Bevy의 리뷰 프로세스에서는 **리뷰 교환**이 아주 흔함. 나와 다른 기여자가 서로의 풀 리퀘스트를 리뷰하고, 결과적으로 둘 다 더 빨리 병합됨  
    기여자들이 [같은 프로젝트에서 작업할 때](https://lobste.rs/s/dmokfv/working_groups) 가장 잘 굴러갔지만, 관련 없는 작업에서도 이런 식으로 하는 걸 본 적 있음. Clippy도 비슷한 관행을 만들었으면 좋겠음. 리뷰 교환은 작업을 더 빨리 병합하게 해주고 협업적인 커뮤니티를 키워줌  
    다만 이 블로그 글에서 리뷰 메커니즘을 소개하는 문단은 개선될 수 있음. 지금은 “다른 PR을 대충 훑으면 네 PR을 더 빨리 병합해주겠다”처럼 읽히는데, 의도한 메시지는 그게 아닐 것 같음. 대신 다른 협업자와 함께 일하는 데 초점을 맞춰야 함. 사람들에게 Clippy의 Zulip 채널에 가서 리뷰 교환을 제안하고, 같은 프로젝트에서 함께 일하게 하면, 시스템 악용을 부추기지 않으면서 더 건강한 커뮤니티를 만들 수 있음
  - 비슷한 생각을 했음. 불공정한 참여자는 부계정으로 가짜 기능을 만들고, 본계정의 실제 작업에 **진짜 유지관리자 관심**을 끌어올 수 있음  
    둘 다 다음 방식으로 꽤 쉽게 피할 수 있어 보임. 리뷰 짝을 무작위로 정해서 같은 사람의 작업을 여러 번 리뷰하지 않게 하고, 최종적으로 병합된 PR에 대한 리뷰만 집계하면 됨

- 다른 사람의 PR과 이슈 리뷰를 돕는 서비스로 https://www.CodeTriage.com 를 운영하고 있음