오픈소스 거버넌스가 무너질 때 — 루비 센트럴 사태와 세 개의 축

들어가며 — 열 달이 지나도 끝나지 않은 분쟁
루비 센트럴 — 확인 가능한 타임라인
양쪽의 주장 — 무엇이 사실이고 무엇이 성격 규정인가
Artichoke Ruby의 종료 — 같은 시기, 다른 이유
세 개의 축 — 상표, 패키지 인프라, 자금
같은 패턴의 반복
엔지니어가 실제로 점검할 것
마치며 — 포크할 수 있는 것과 포크할 수 없는 것
참고 자료

들어가며 — 열 달이 지나도 끝나지 않은 분쟁

2026년 7월 30일, Bundler를 만든 André Arko가 Ruby Central's Destructive Legacy를 발표했습니다. 다음 날 Hacker News에 올라 43포인트에 댓글 23개를 받았습니다.

2025년 10월에 마츠모토 유키히로(Matz)와 루비 코어 팀이 RubyGems와 Bundler 저장소의 관리를 넘겨받았을 때, 여러 매체가 이 분쟁이 종결됐다고 보도했습니다. 그 보도는 절반만 맞았습니다. 코드 관리권은 정리됐지만 분쟁 자체는 정리되지 않았습니다. Arko의 진술에 따르면 2026년 3월에 루비 센트럴의 변호사가 그를 FBI에 신고했고, 4월에 그가 제시한 합의안에는 30일이 지나도록 실질적인 답이 오지 않았습니다.

이 글은 누가 옳은지를 판정하려는 글이 아닙니다. 양쪽 다 1차 진술을 공개했고, 사실관계 자체가 갈리는 지점이 명확히 있습니다. 대신 이 사건에서 구조를 읽으려고 합니다. 같은 형태의 위기가 core-js에서, event-stream에서, xz-utils에서, Nix에서, Redis와 Terraform에서 반복되는 이유가 있기 때문입니다. 그 이유는 세 개의 축이 서로 다른 주체에게 흩어져 있다는 데 있습니다.

루비 센트럴 — 확인 가능한 타임라인

먼저 양쪽 진술이 대체로 일치하는 사실관계입니다. 출처는 루비 센트럴의 2025년 9월 25일 성명, 2026년 3월 말에 나온 자체 사후 보고서, 그리고 Arko의 2025년 10월 9일 반박문입니다.

배경부터 봅니다. 루비 센트럴은 RubyConf와 RailsConf를 운영하고 rubygems.org 인프라를 운영해 온 비영리 단체이고, 2021년에 Bundler와 RubyGems 개발에 자금을 대던 Ruby Together를 흡수했습니다. 2025년에 들어서면서 Sidekiq의 연간 후원(약 25만 달러 규모로 보도됨)이 끊겼고, 재정적으로 Shopify 의존도가 높아진 상태였습니다.

2025년 6월 3일 — Arko가 루비 센트럴 자문 역할에서 사임합니다. 오픈소스 쪽 자문은 계속하되 단체를 대표하지는 않겠다는 취지였습니다.
2025년 8월 18일 — 루비 센트럴이 전임으로 채용했던 보안 담당 Samuel Giddins가 2주 전 통보로 사직합니다.
2025년 8월 25일에서 26일 — Arko가 Ruby 버전 관리 도구 rv와 Spinel 조직을 공개합니다. 루비 센트럴은 자체 보고서에서 이 시점을 촉발 사건으로 명시합니다.
2025년 9월 9일에서 10일 — GitHub의 RubyGems 엔터프라이즈 계정 이름이 "Ruby Central"로 변경되고, Arko(indirect), Giddins(segiddins), Martin Emde(martinemde)의 관리자 권한이 제거됩니다.
2025년 9월 15일 — 이 조치가 대외적으로 "실수"라고 설명되고 일부 접근이 잠시 복구됩니다. 같은 주에 npm 생태계를 겨냥한 대규모 피싱 공급망 공격이 발생했고, 루비 센트럴은 이후 이를 보안 근거의 정황으로 인용합니다.
2025년 9월 18일 — 위 세 명과 Ellen Dash(duckinator)가 GitHub 조직에서 완전히 제거됩니다. 같은 날 이사회가 프로덕션 접근과 커밋 권한 회수를 정식 의결합니다.
2025년 9월 18일에서 19일 — 여섯 명이 항의 사퇴합니다. Arko, David Rodríguez, Ellen Dash, Josef Šimánek, Martin Emde, Samuel Giddins입니다.
2025년 9월 30일 — Arko가 자신에게 여전히 rubygems.org 프로덕션의 AWS 루트 접근 권한이 남아 있다는 사실을 발견하고 루비 센트럴에 이메일로 알립니다.
2025년 10월 5일 — Martin Emde가 gem.coop을 발표합니다. Homebrew의 거버넌스를 참고한 협동조합 형태의 gem 호스트로, 초기에는 rubygems.org의 실시간 미러로 동작합니다.
2025년 10월 17일 — ruby-lang.org 공지로 Matz와 루비 코어 팀이 RubyGems와 Bundler 저장소의 관리를 맡고, rubygems.org 인프라 운영은 루비 센트럴이 계속하는 분리가 확정됩니다.
2026년 3월 말 — 루비 센트럴이 Richard Schneeman이 작성한 사후 보고서를 공개합니다.
2026년 4월 19일 — 루비 센트럴의 사무총장이 해임되고, 단체가 재정 위기를 이유로 홍보 대행사 계약과 CFO 직위, 외부 계약자를 정리하고 이사회를 무보수 실무 이사회로 전환합니다.
2026년 7월 30일 — Arko의 최신 글이 나옵니다.

여기까지가 날짜와 함께 확인되는 사실입니다.

양쪽의 주장 — 무엇이 사실이고 무엇이 성격 규정인가

루비 센트럴의 설명은 대략 이렇습니다. 두 명(Arko, Giddins)이 이미 조직을 떠난 상태에서 프로덕션 인프라의 관리자 권한을 유지하는 것은 공급망 공격 표면이 커지는 상황에서 받아들이기 어려웠고, 이사회의 수탁 책임상 최소 권한 원칙에 맞는 접근 모델로 옮기는 것이 목표였다는 것입니다. 자체 보고서에서 인정하는 실패는 실행 쪽에 몰려 있습니다 — 문서화된 오프보딩 절차나 체크리스트가 없었고, 접근 변경 사실과 이유가 당사자들에게 제대로 전달되지 않았으며, 의사 결정자들이 GitHub 권한과 프로덕션 서버 접근이 어떻게 연결되는지 서로 다른 수준으로 알고 있었다는 것입니다. 보고서는 "이것은 우리 모두의 실수"라는 취지로 마무리됩니다. 다만 9월의 권한 제거에 대해서는, 외부에서 단순 실수로 규정된 것과 달리 실제 문제는 타이밍과 내부 소통이었다는 쪽으로 다시 설명합니다.

떠난 유지보수자들의 설명은 다릅니다. Arko는 이것을 적대적 인수로 규정하고, 자신을 겨냥한 표적 조치였다고 봅니다. 근거로 드는 것은 루비 센트럴 자체 보고서가 rv와 Spinel 공개를 촉발 사건으로 명시했다는 점입니다. 그는 AWS 루트 권한 잔존을 발견해 책임 있게 신고했는데 오히려 "해킹" 혐의로 소송 위협을 받았고, 세 차례의 감사에서 아무 피해가 없었음이 확인됐다고 적습니다. 그가 요구하는 것은 소송 위협 철회, 피해가 없었다는 공개 확인, 변호사 비용 보전, 그리고 증거 없이 이루어진 공개 비난에 대한 사과입니다.

여기서 정직하게 구분해 둘 것들이 있습니다.

양쪽이 사실상 일치하는 것. 루비 센트럴의 9월 25일 성명 자체가 rubygems.org 데이터가 무단으로 복사되거나 보관된 정황은 없다고 밝혔습니다. 이건 Arko의 감사 결과 주장과 방향이 같습니다.

한쪽 진술에만 존재하는 것. FBI 신고, 합의 협상의 내용과 진행 상황은 전적으로 Arko의 진술입니다. 루비 센트럴이 이를 확인하거나 부인한 공개 자료를 찾지 못했습니다.

입증되지 않은 정황. Shopify가 자금을 지렛대로 삼아 Arko의 배제를 요구했다는 서사는 여러 2차 보도와 커뮤니티 인사들의 글에 반복해서 등장하지만, 루비 센트럴이나 Shopify가 공식적으로 확인하거나 부인한 기록을 찾지 못했습니다. 루비 센트럴의 공개 문서는 이사회의 수탁 책임과 공급망 보안을 근거로 들 뿐 특정 후원사를 언급하지 않습니다. 이 부분은 주장으로 읽어야 합니다.

해석이 갈리는 것. 2021년 Ruby Together 흡수로 루비 센트럴이 Bundler와 RubyGems에 대해 어떤 권리를 확보했는가입니다. 루비 센트럴의 서술은 스튜어드십을 전제하고, 반대편은 그 자산이 애초에 Ruby Together의 것이 아니었으므로 이전된 바 없다고 봅니다. 이건 감정의 문제가 아니라 법적 소유의 문제이고, 이 글의 다음 절이 다루는 지점이기도 합니다.

Artichoke Ruby의 종료 — 같은 시기, 다른 이유

이 사태와 함께 자주 언급되는 것이 Artichoke Ruby의 종료입니다. Rust로 작성된 Ruby 구현으로, Ryan Lopopolo가 2019년 RubyConf에서 처음 공개한 프로젝트입니다.

확인해 본 결과를 그대로 적습니다. 종료 글은 Winding Down Artichoke Ruby이고 2026년 2월 15일에 나왔으며, 저장소는 그보다 앞선 2025년 11월 3일에 아카이브됐습니다. 그리고 이 글에는 루비 센트럴이나 RubyGems 분쟁에 대한 언급이 전혀 없습니다. 저자가 드는 이유는 전부 개인적이고 프로젝트 내적입니다 — 나이가 들면서 일과 가족으로 우선순위가 옮겨 갔고, 현재 직장(OpenAI)의 일이 충분히 몰입할 만하며, 언어 런타임을 유지하는 기회비용이 크고, MRI Ruby와의 호환성을 계속 추적하는 부담이 끝없으며, 그 부담을 정당화할 사용자 기반이 없다는 것입니다.

Hacker News 노출도 크지 않았습니다. 제가 확인한 제출은 2026년 7월 25일자 하나이고 5포인트에 댓글 0개였습니다. 두 사건은 시기가 겹칠 뿐 인과 관계가 없습니다. 이걸 굳이 적는 이유는, 거버넌스 위기 서사에 인접한 사건들이 사후적으로 엮이는 일이 흔하기 때문입니다.

다만 Artichoke 종료문에는 이 글의 주제와 이어지는 대목이 하나 있습니다. 유지보수를 지속하게 만드는 것은 자금만이 아니라 사용자 기반과 개인적 동기라는 점입니다. 뒤에서 다시 나옵니다.

세 개의 축 — 상표, 패키지 인프라, 자금

오픈소스 프로젝트에서 실제로 힘이 되는 자산은 코드가 아닙니다. 코드는 라이선스가 허용하는 한 언제든 포크할 수 있습니다. 포크로 복제되지 않는 것이 세 가지 있습니다.

상표. 이름을 법적으로 누가 갖고 있는가. 포크가 원래 이름을 쓸 수 있는지가 여기서 결정됩니다.
패키지 레지스트리. 실제 배포가 일어나는 인프라를 누가 운영하는가. 저장소를 포크해도 사용자가 gem install이나 npm install로 받는 것은 여전히 원래 레지스트리에서 옵니다.
자금. 유지보수자에게 실제로 돈을 주는 주체가 누구인가.

이 셋이 한 주체에 모여 있으면 그 주체의 성격이 프로젝트의 성격이 되고, 흩어져 있으면 조정 비용이 생깁니다. 위기는 흩어진 상태에서 셋 중 하나가 다른 하나를 지렛대로 쓰려 할 때 발생합니다.

생태계	상표	레지스트리 운영	저장소 관리
Ruby	Ruby Association이 스튜어드십 역할(단일 등록 상표 소유자는 확인하지 못함)	rubygems.org: Ruby Central	루비 코어 팀(2025-10 이후)
Bundler	André Arko 개인 보유(본인 주장)	위와 동일	위와 동일
Python	Python Software Foundation	PyPI: Python Software Foundation	코어 개발자 + PSF
JavaScript	해당 없음	npm: GitHub, 즉 Microsoft	패키지별로 분산
Rust	Rust Foundation	crates.io: crates.io 팀 + Rust Foundation	Rust 프로젝트
Java	해당 없음	Maven Central: Sonatype(영리 기업)	패키지별로 분산

루비의 줄을 보면 문제가 그대로 보입니다. 상표, 레지스트리, 저장소 관리가 세 개의 다른 주체에 걸쳐 있고, 그중 하나(Bundler 상표)는 개인이 갖고 있습니다. Python의 줄과 비교하면 대비가 분명합니다. PSF는 상표와 PyPI를 함께 보유하고 있어서, 최소한 "누가 결정할 수 있는가"라는 질문에 답이 있습니다.

세 번째 축인 자금 쪽 데이터도 붙여 두겠습니다. Tidelift의 2024년 유지보수자 조사는 응답자 437명 기준으로 60퍼센트가 무보수이고, 약 60퍼센트가 자신이 유지보수하는 프로젝트를 그만두었거나 진지하게 고민한 적이 있으며, 그 이유로 번아웃을 꼽은 비율이 44퍼센트였습니다. 같은 조사는 보수를 받는 유지보수자가 보안에 더 많은 시간을 쓰고 취약점을 더 빨리 고친다는 결과도 냈습니다. 반대편에는 GitHub Sponsors가 2026년 7월 21일 기준 누적 1억 달러를 넘겼고 7만 명 이상의 유지보수자와 조직을 지원했다는 발표가 있습니다. 두 숫자를 나란히 놓으면 상황이 보입니다 — 자금은 늘고 있지만 분배는 여전히 소수 프로젝트에 몰려 있고, 대다수 유지보수자에게 자금 축은 사실상 존재하지 않습니다.

같은 패턴의 반복

세 축의 관점에서 과거 사례들을 다시 보면 분류가 됩니다.

자금 축의 부재. core-js가 대표적입니다. 2023년 2월 14일, 사실상 단독 유지보수자였던 Denis Pushkarev가 "So, what's next?"를 올려 무료 오픈소스가 근본적으로 망가져 있다고 적었습니다. 주간 수천만 건의 다운로드를 감당하면서 후원금은 월 수백 달러 수준이었다는 것이 요지였고(구체적 금액은 출처마다 달라 신뢰도가 낮습니다), 그는 유료화를 검토한다고 밝혔습니다. 결과적으로 이 글이 확산되면서 후원이 늘었고, core-js는 여전히 그가 독립적으로 유지보수합니다. 자금 축의 부재는 폭발하지 않으면 그냥 조용히 마모됩니다.

유지보수자 축의 인수. event-stream(2018)과 xz-utils(2024)가 같은 형태입니다. event-stream에서는 원저자 Dominic Tarr가 유지보수를 놓은 상태에서 자원한 계정에게 커밋과 npm 배포 권한을 넘겼고, 그 계정이 flatmap-stream이라는 의존성을 추가해 Copay 비트코인 지갑을 표적으로 하는 악성 코드를 심었습니다. xz-utils에서는 2년 반에 걸친 사회공학이 있었습니다 — 여러 개의 가짜 신원이 메일링 리스트에서 번아웃 상태의 원 유지보수자 Lasse Collin에게 릴리스가 느리다고 압박했고, 그렇게 들어온 공동 유지보수자가 2024년 3월에 sshd를 겨냥한 백도어를 심었습니다. Microsoft의 Andres Freund가 SSH 로그인 지연이라는 우연한 관측에서 발견하지 않았다면 어디까지 갔을지 알 수 없습니다. 두 사건 모두 자금 축의 부재가 유지보수자 축의 취약점을 만들었다는 점에서 앞의 사례와 이어집니다.

거버넌스 축의 정통성 위기. Nix가 여기 해당합니다. 2024년 4월, 100명 이상이 서명한 공개 서한이 창시자 Eelco Dolstra의 사퇴를 요구했습니다. 쟁점은 커뮤니티 조정 절차를 훼손했다는 지적과, 그가 소속된 회사와의 이해충돌, 그리고 NixCon 후원사로 방위산업체 Anduril을 받아들이려 한 결정이었습니다. Dolstra는 NixOS 재단 이사회에서 물러났습니다. 코드에는 아무 문제가 없었고, 무너진 것은 누가 무엇을 결정할 권한이 있는가에 대한 합의였습니다.

소유권 축의 행사. Redis, Terraform, Elasticsearch는 모두 저작권자가 라이선스를 바꾼 사례이고, 모두 대형 포크로 이어졌습니다. Redis는 2024년 3월 BSD에서 RSAL과 SSPL 이중 라이선스로 바꿨고 리눅스 재단이 Valkey를 포크했습니다. HashiCorp는 2023년 8월 Terraform을 BUSL로 바꿨고 3주 만에 OpenTofu 포크가 조직되어 9월에 리눅스 재단에 들어갔습니다. Elastic은 2021년에 SSPL로 옮겼고 AWS가 OpenSearch를 포크했습니다.

흥미로운 것은 셋 다 상당 부분 되돌아왔다는 점입니다. Elastic은 2024년 8월에 AGPLv3을 추가했고, Redis는 2025년 5월 Redis 8.0에서 AGPLv3을 추가했습니다. 두 경우 모두 포크가 자리를 잡은 뒤에 나온 결정입니다. Terraform 쪽은 2024년 4월 HashiCorp가 OpenTofu에 코드 복제를 이유로 중지 요구서를 보냈지만, OpenTofu가 문제의 코드가 BUSL 이전의 MPL 라이선스 조상에서 왔음을 상세히 반박했고 소송으로 이어지지 않았습니다. HashiCorp는 2025년 2월 IBM에 인수되어 절차가 종료됐습니다.

여기서 나오는 관찰이 하나 있습니다. 라이선스 변경은 되돌릴 수 있지만, 신뢰와 사람은 되돌아오지 않습니다. Valkey와 OpenSearch와 OpenTofu는 원본이 라이선스를 되돌린 뒤에도 계속 살아 있습니다.

엔지니어가 실제로 점검할 것

이 분석이 실무로 이어지는 지점은 다음과 같습니다.

의존성을 볼 때 유지보수자 수를 세십시오. 다운로드 수나 GitHub 스타는 위험의 지표가 아닙니다. core-js와 event-stream과 xz-utils의 공통점은 다운로드가 많았다는 것이지 적었다는 게 아닙니다. 실제 지표는 최근 12개월간 커밋 권한을 실제로 쓴 사람의 수이고, 그게 하나면 그건 한 사람이 번아웃하거나 사회공학에 노출되는 순간 끊기는 의존성입니다.

레지스트리와 저장소를 분리해서 생각하십시오. 저장소가 포크되어도 배포 경로는 그대로일 수 있고, 반대로 저장소는 그대로인데 배포 경로가 바뀔 수도 있습니다. 사내 프록시나 미러를 두는 조직이라면, 상위 레지스트리가 하나뿐인지 확인해 둘 만합니다. gem.coop처럼 대안 호스트가 생기는 상황에서는 이 구분이 실질적인 의미를 갖습니다.

핵심 의존성에는 돈을 쓰십시오. Tidelift 조사 결과가 말해 주는 것은 감성적인 이야기가 아니라 위험 관리입니다. 보수를 받는 유지보수자가 취약점을 더 빨리 고칩니다. 조직이 매년 쓰는 클라우드 비용과, 그 위에서 도는 코드의 핵심 의존성에 지불하는 금액을 나란히 적어 보면 대개 비율이 우스꽝스럽습니다.

마치며 — 포크할 수 있는 것과 포크할 수 없는 것

정리하면 이렇습니다.

루비 센트럴 사태는 2025년 9월의 권한 회수에서 시작해, 2025년 10월에 저장소 관리가 루비 코어 팀으로 넘어가면서 코드 층위는 정리됐지만, 2026년 7월 현재 당사자 간 분쟁은 미해결 상태입니다.
양쪽 다 1차 진술을 공개했고, 실행 실패에 대해서는 루비 센트럴이 스스로 인정한 부분이 있습니다. Shopify의 개입 서사는 반복 보도되지만 당사자 확인이 없는 주장입니다.
같은 시기의 Artichoke Ruby 종료는 이 사태와 무관합니다. 종료문의 이유는 전적으로 개인적이고 프로젝트 내적입니다.
반복되는 위기의 구조는 상표, 패키지 인프라, 자금이라는 세 축이 서로 다른 주체에게 흩어져 있다는 데 있습니다.
라이선스는 되돌릴 수 있지만 포크와 사람은 되돌아오지 않습니다.

오픈소스에서 코드는 언제나 포크할 수 있습니다. 포크할 수 없는 것은 이름, 배포 경로, 그리고 사람입니다. 거버넌스라는 단어가 추상적으로 들린다면, 그 셋을 각각 누가 쥐고 있는지 적어 보는 것으로 충분히 구체적이 됩니다. 자기 조직이 의존하는 프로젝트에 대해 그 표를 채울 수 없다면, 그건 아직 위기가 오지 않았다는 뜻이지 위험이 없다는 뜻이 아닙니다.