오픈 소스의 영원한 9월에 오신 것을 환영합니다. 유지 관리자를 위해 우리가 계획한 내용은 다음과 같습니다.

Source: GitHub Blog

Source: …

기여 비용이 낮아질 때

메일링 리스트 시대에는 오픈소스에 기여하려면 실제 노력이 필요했습니다. 다음과 같은 과정을 거쳐야 했죠:

1. 리스트에 구독하기.
2. 잠수하면서 커뮤니티 문화를 이해하기.
3. 패치를 올바르게 포맷하기.
4. 변경이 왜 중요한지 설명하기.

노력이 품질을 보장하지는 않았지만 참여도를 필터링했습니다. 대부분의 기여는 프로젝트에 진심으로 투자한 사람들로부터 나왔습니다.

높은 장벽의 문제점

• 배제: 높은 장벽 때문에 많은 잠재 기여자가 배제되었습니다.
• 노력 대비 보상: 누구든지 도움을 주기 위해서는 먼저 많은 작업을 해야 했습니다.

프로젝트들은 이를 인식하고 진입 장벽을 낮추기 위해 노력했으며, 오픈소스를 보다 환영받는 환경으로 만들었습니다.

풀‑리퀘스트 혁명

GitHub에 프로젝트를 호스팅하고 풀 리퀘스트를 사용하며 “Good First Issues”(첫 기여하기 좋은 이슈) 라벨을 붙이는 것이 마찰을 크게 줄였습니다:

• 즉시 PR 생성: 풀 리퀘스트를 몇 초 안에 만들 수 있습니다.
• 가이드형 온보딩: “Good First Issue” 태그가 신규 기여자를 위험도가 낮은 작업으로 안내합니다.
• 참여 확대: 커뮤니티가 성장하고 기여가 더 접근하기 쉬워졌습니다.

그것은 좋은 일이었습니다.

새로운 균형: 마찰 vs. 신뢰

마찰은 균형 잡기가 필요합니다:

• 마찰이 너무 많으면 → 아이디어와 기여자가 배제됩니다.
• 마찰이 너무 적으면 → 유지보수자가 과부하돼 신뢰가 무너질 수 있습니다.

오늘날 생성형 AI 덕분에 코드, 이슈, 보안 보고서를 대규모로 쉽게 만들 수 있게 되었습니다. 생성 비용은 크게 낮아졌지만 검토 비용은 여전히 높습니다.

대부분의 기여자는 여전히 가치가 있는 이유

• 선의: 대부분은 자신이 관심 있는 프로젝트를 돕고 싶어합니다.
• 학습 및 가시성: 기여는 실력을 향상하고 평판을 얻는 방법입니다.
• 경력 혜택: 널리 사용되는 오픈소스에 참여하면 이력서에 큰 도움이 됩니다.

이러한 동기는 새로운 것이 아니며 잘못된 것도 아닙니다—수십 년 동안 오픈소스 참여를 이끌어 온 동일한 동기입니다.

실제 도전 과제

저품질 기여가 대규모로 들어오면 검토 작업량이 유지보수자의 역량을 초과할 수 있습니다. 선의의 제출이라 할지라도 프로젝트를 압도해 다음과 같은 문제를 초래합니다:

• PR 백로그
• 피드백 지연
• 협업 과정에 대한 신뢰 감소

협업의 기반인 신뢰가 흔들리면 생태계 전체의 건강이 위협받습니다. 낮은 진입 장벽과 지속 가능한 검토 관행 사이의 균형이 현대 오픈소스 커뮤니티의 핵심 과제가 되었습니다.

Source: …

새로운 소음 규모

“저품질 기여”나 “AI 슬롭”을 최근에 등장한 독특한 현상으로 보는 것은 유혹적입니다. 실제로는 그렇지 않습니다—유지보수자는 언제나 시끄러운 외부 제출물을 다뤄왔습니다.

• Linux kernel – 신뢰의 웹 철학 하에 운영되며, SubmittingPatches 가이드를 공식화하고 2004년에 Developer Certificate of Origin (DCO) 를 도입했습니다.
• Mozilla와 GNOME – 대부분의 들어오는 버그 보고서가 유지보수자가 더 깊이 시간을 투자하기 전에 필터링이 필요하다는 현실에 기반한 공식 트리아지 시스템을 구축했습니다.
• 자동화 스캐너 – GenAI 이전부터 유지보수자는 상용 및 오픈소스 스캔 도구에서 발생하는 자동 보안 및 코드 품질 보고서의 물결을 처리해 왔습니다.

“정말 나를 도와주려는 건가, 아니면 자신만을 도우려는 건가?”

유지보수자들의 질문은 종종 동일했습니다. 정적 분석기든 LLM이든 도구가 보고서나 수정을 쉽게 만든다고 해서 그 기여가 프로젝트에 가치가 있다는 뜻은 아닙니다. 생성이 쉬워질수록 유지보수자에게는 부담이 늘어나는데, 이는 이득의 불균형 때문입니다: 기여자는 인정(또는 CVE, 가시성)을 얻을 수 있지만, 유지보수자는 유지보수 부담을 떠안게 됩니다.

최근 사례

• cURL – AI가 생성한 보안 보고서가 폭증하면서 각각 검증에 몇 시간이 소요돼 버그 바운티 프로그램을 종료했습니다.
  공지사항 읽기
• Ghostty – 코드 기여를 받기 전에 토론을 요구하는 초대 전용 기여 모델로 전환했습니다.
  기여 가이드라인
• 다양한 프로젝트 – AI가 생성한 기여에 대한 명시적 규칙을 채택하고 있습니다.

이러한 조치는 기여 생성이 쉬워지는 것과 이를 유지보수하는 데 필요한 노력 사이의 불균형에 대한 합리적인 대응입니다.

GitHub에서 우리가 하는 일

GitHub에서는 단순히 상황을 지켜보는 것이 아닙니다. 유지관리자 지속 가능성은 오픈 소스의 근본이며—우리에게도 근본입니다. 오픈 소스의 중심지로서 우리는 여러분이 들어오는 것을 관리하도록 도울 책임이 있습니다.

우리는 여러 관점에서 접근하고 있습니다: 지금 당장 즉각적인 구호를 제공하면서도 장기적이고 체계적인 개선을 구축해 나가고 있습니다. 이 중 일부는 도구와 관련이 있고, 일부는 유지관리자가 제한된 시간을 어디에 투자할지 결정할 수 있도록 더 명확한 신호를 만드는 것입니다.

이미 출시된 기능

• Pinned comments on issues – 댓글 메뉴에서 직접 이슈 상단에 댓글을 고정합니다.
• Banners to reduce comment noise – “+1” 또는 “같은 생각” 댓글 대신 반응이나 구독을 유도하는 배너를 표시하여 불필요한 알림을 줄입니다.
• Pull‑request performance improvements – 최적화된 diff 덕분에 새로운 Files changed 뷰가 최대 67 % 빠르게 로드됩니다. 특히 대형 풀 리퀘스트에서 효과적입니다.
• Faster issue navigation – 향상된 탐색 속도로 유지 관리자가 버그를 보다 효율적으로 분류할 수 있습니다.
• Temporary interaction limits – 공개 리포지토리에서 특정 사용자의 활동을 일시적으로 제한합니다.

이러한 개선 사항은 리뷰 부담을 줄이고 개발자 워크플로우를 간소화하는 데 목적이 있습니다.

곧 제공될 기능

• Repo‑level pull request controls
  유지 관리자가 협업자에게만 풀 리퀘스트 생성을 제한하거나 풀 리퀘스트 자체를 완전히 비활성화할 수 있습니다. 풀 리퀘스트는 오픈 소스 성장의 핵심이었지만, 유지 관리자는 프로젝트를 효과적으로 관리하기 위한 도구가 필요합니다.

• Pull request deletion from the UI
  스팸이나 악용되는 풀 리퀘스트를 UI에서 직접 삭제할 수 있어 저장소를 보다 관리하기 쉬워집니다.

다음 단계 탐색

벽은 커뮤니티를 만들지 못합니다. 앞으로 나아가면서 우리의 목표는 유지보수자에게 더 많은 제어권을 부여하면서 오픈‑소스가 작동하게 하는 협업 정신을 보호하는 것입니다.

유지보수자와 협의하여 탐색 중인 방향

• 기준‑기반 게이팅

  • 풀 리퀘스트를 열기 전에 연결된 이슈가 있어야 합니다.
  • 기여가 받아들여지기 전에 충족해야 할 규칙을 정의합니다.

• 향상된 트라이에지 도구

  • 자동 트라이에지를 활용해 프로젝트 자체 가이드라인(예: CONTRIBUTING.md)에 따라 기여를 평가합니다.
  • 유지보수자의 주의를 먼저 끌어야 할 풀 리퀘스트를 표시합니다.

이러한 도구는 지원을 위한 것이며, 의사결정을 대체하지 않습니다. 유지보수자는 여전히 제어권을 가집니다.

트레이드‑오프 및 안전장치

• 제한은 선의의 첫 번째 기여자에게 불균형하게 영향을 미칠 수 있습니다.
• 모든 제어는 선택적이며 구성 가능하게 하여 그 위험을 완화합니다.

커뮤니티 실험

이러한 접근 방식은 상호 배타적이지 않습니다:

• 교육은 선의의 기여자가 성공하도록 돕습니다.
• 가드레일은 유지보수자가 규모를 관리하도록 돕습니다.

하나의 솔루션으로는 모두에게 맞지 않음

프로젝트마다 고유한 가치가 있습니다. 플랫폼을 둘러싼 도구들은 나중에 더 널리 채택될 수 있는 기능들의 시험장이 됩니다. 우리는 이러한 실험을 면밀히 관찰하고 있습니다.

인센티브 재고

“차단과 금지”만 구축한다면 요새가 될 뿐, 장터는 되지 못합니다.

• “기여” 개념 확대
  • WordPress에서는 수동으로 작성한 “props”가 코드, 문서, 테스트, 커뮤니티 지원 등 다양한 기여를 인정합니다.
  • 다양한 기여를 인정하면 신뢰 신호(예: 지속적인 이슈 트라이에지, 문서 병합)가 표면화되어 유지보수자가 더 빠르고 정확한 결정을 내리는 데 도움이 됩니다.

우리는 GitHub가 사람들이 프로젝트를 앞으로 나아가게 하는 모든 방식을 드러내고 축하하기를 원합니다.

Source: …

Tell us what you need

우리는 커뮤니티 토론을 열어 현재 탐색 중인 방향에 대한 피드백을 수집하고 있습니다: Exploring Solutions to Tackle Low‑Quality Contributions on GitHub.

여러분의 의견을 듣고 싶습니다. 여러분의 프로젝트에서 잘 작동하는 부분, 격차가 있는 부분, 그리고 오픈 소스 유지 관리 경험을 의미 있게 개선할 수 있는 방안을 공유해 주세요.

오픈 소스의 Eternal September는 축하할 만한 현상의 징후입니다: 이전보다 더 많은 사람들이 참여하고 싶어합니다. 기여량은 계속 증가할 것이며, 이는 좋은 일입니다. 하지만 초기 인터넷이 규모에 맞는 커뮤니티를 유지하기 위해 규범과 도구를 발전시킨 것처럼, 오픈 소스도 같은 과정을 거쳐야 합니다. 방어적인 접근이 아니라, 유지 관리자가 더 나은 신호, 더 나은 도구, 그리고 그 에너지를 프로젝트 발전에 연결할 수 있는 더 좋은 방법을 제공함으로써 말이죠.

함께 그 길을 만들어 갑시다.

---

Written by

Ashley Wolf – Director, Open Source Programs at GitHub

저는 GitHub 내부와 전체 생태계에서 유지 관리자를 지원하는 오픈 소스 전략 및 프로그램을 담당하고 있습니다. 또한 TODO Group의 Steering Committee 위원으로 활동하며, 조직이 오픈 소스를 책임감 있게 사용하고 지속할 수 있도록 돕고 있습니다.

GitHub에서 더 알아보기