"Rails is done" 글은 "Rails는 끝났다" 와 "Rails는 완성됐다" 로 모두 읽히지만, 이 글이 택한 건 후자임
즉, Rails가 창시자 없이도 살아남을 만큼 충분히 완성됐다는 것
최근 Rails 코어를 포크해 새로운 커뮤니티 주도 프레임워크를 만들려는 움직임이 시작됨
가칭 Amiko, Rails 8.x 호환 LTS를 목표로 하며 기존 앱도 gem 교체와 몇 번의 검색/치환만으로 옮길 수 있게 한다는 계획
흥미로운 건 포크의 이유가 기술적 불만이 아니라는 점
Rails는 여전히 훌륭하지만 DHH의 가치관과 리더십은 더 이상 받아들이기 어렵다는 개발자들이 Rails와 DHH를 분리하려는 것
그리고 이 시도는 갑자기 튀어나온 것이 아님
2025년 공개서한에 이은 두 번째 분리 시도이고, 그사이 Ruby 생태계는 이미 한 번 거버넌스로 크게 데였음
Rails는 원래 DHH의 강한 의견으로 만들어진 프레임워크
Rails는 37signals가 Basecamp를 만들던 과정에서 시작됨
DHH가 Ruby로 Basecamp에 필요한 도구를 만들고 이를 추출해 2004년 오픈소스로 공개
15분짜리 블로그 만들기 데모와 Java 진영을 겨냥한 과감한 마케팅을 통해 빠르게 확산
Convention over Configuration이라는 Rails의 핵심도 수많은 선택지를 제공하기보다 "우리는 이 방식이 맞다고 생각한다" 는 강한 의견에서 출발
프로젝트마다 폴더 구조와 라이브러리 조합을 다시 결정하지 않아도 되고, 작은 팀이 제품 자체에 집중할 수 있다는 Rails의 장점은 이 일관된 방향에서 나옴
Shopify/GitHub 같은 대규모 서비스도 지금까지 Rails를 사용 중이고, Rails는 지난 20년 동안 웹 프레임워크의 설계와 개발 방식에 큰 영향을 줌
Ruby on Rails 다큐멘터리는 Rails가 어떻게 만들어지고 확산됐는지를 잘 보여줌
초기 Rails 컨퍼런스에서 DHH가 부당한 요구에 "F()c% You" 라는 슬라이드로 답한 일화도 이 방향성이 어떻게 지켜졌는지를 보여줌
오픈소스는 상업적 관계가 아니며 사용자가 프로젝트의 방향을 지시할 수 없다는 입장
Rails의 매력은 DHH의 성향과 분리하기 어려웠음
유행을 따르기보다 자신의 방식이 더 낫다고 밀어붙이고, 복잡한 기술을 단순한 선택으로 압축하는 능력
문제는 그 강한 의견이 기술 밖에서도 같은 방식으로 작동하기 시작했다는 점
5년간 쌓이고 최근 1년 사이 폭발한 압력
- 2021. 04 - Basecamp가 사내 정치/사회 논의를 금지하는 정책을 발표하고 직원 상당수가 회사를 떠남
- 2022. 02 - 캐나다 트럭 시위 계좌 동결을 계기로 "내가 틀렸다, 우리에게 암호화폐가 필요하다"며 기존 입장을 뒤집음
- 2023 - RailsConf와 별도로 Rails World를 만들며 Rails 생태계의 중심이 분리되기 시작
- 2024. 11 - DHH가 Shopify 이사회에 합류, Rails와 최대 후원 기업이 인적으로도 연결됨
- 2025 중반 - Rails 코어 팀에 DHH와 관계를 끊고 하드 포크하라는 공개서한이 전달됐지만 실제 포크로 이어지지는 않음
- 2025. 09 - Sidekiq의 후원 철회와 Ruby Central의 Shopify 의존 심화 뒤 RubyGems/Bundler 강제 인수 발생
- 2026. 07 - DHH의 Roma 관련 글을 계기로 HEY 구독 취소, MINASWAN 비판, Ruby Central 결산이 며칠 사이에 몰림
- 2026. 08 - Rails 호환 포크 Amiko 시작
앞의 17년은 한 사람의 방향성이 프레임워크를 만든 시간이고, 뒤의 5년은 그 방향성이 프레임워크 밖으로 넘친 시간
포크 소식만 떼어 놓으면 갑작스러워 보이지만, 연표로 놓으면 5년간 쌓인 압력이 최근 1년 사이 폭발한 결과에 가까움
기술 독설에서 정치로
DHH는 기술적인 주장에서도 상대를 조심스럽게 설득하기보다 논쟁을 시작하는 제목을 자주 선택
서버리스에 대해서는 일부 워크로드에 유용할 수 있지만, 지속적인 컴퓨팅 자원이 필요한 서비스까지 서버리스로 옮기는 것은 비싸고 락인만 강화한다며 "서버리스에 속지 말라"고 주장
이런 태도는 기술 논쟁에 재미와 새로운 관점을 제공하기도 함
클라우드가 모든 문제를 해결한다는 분위기에서 비용과 락인을 다시 계산하게 만든 공은 분명함
전환점으로 자주 지목되는 건 2021년 Basecamp 사태
사내 정치/사회 논의를 금지하는 정책이 논란이 되며 직원 상당수가 회사를 떠남
Amiko 제안자들은 이 시기 이후 Rails 코어 팀의 프런트엔드 전문성이 약해졌고, 그 결과 자산 파이프라인이 여러 접근으로 분산됐다고 진단함
이 진단이 맞다면 회사의 정치적 결정이 프레임워크의 기술 구성에도 흔적을 남긴 셈
2022년 암호화폐 전향도 같은 흐름에서 볼 수 있음
에너지 소비/낮은 처리량/높은 비용/가격 변동성을 이유로 암호화폐에 부정적이었지만, 캐나다 트럭 시위 과정에서 기부금 전달이 막히고 계좌가 동결되는 모습을 본 뒤 "내가 틀렸다, 우리에겐 암호화폐가 필요하다"며 입장을 바꿈
국가와 제도가 개인의 자유를 통제할 수 있다는 불신은 이후의 정치적 발언에서도 반복됨
2026년의 DHH가 2022년과 단절된 다른 사람이라고 보기는 어려움
그리고 사람에 대한 발언
Amiko 제안자들은 DHH가 최근 반이민/반트랜스/반DEI 성향의 글과 발언을 이어왔다고 비판함
Ruby/Rails 커뮤니티 내부에서도 이를 둘러싼 반발이 커지는 중
극우가 대규모 추방을 뜻하는 표현으로 사용하는 remigration을 요구했고, Roma인을 늑대에 빗대 집단 추방을 옹호하는 것으로 해석된 글도 게시함
이 글은 오랫동안 HEY를 사용하던 고객이 구독을 취소하는 계기가 됨
구독을 취소한 이유는 단순히 정치적 견해가 달라서가 아니었음
일부 사람의 행위를 전체 민족 집단으로 확대하고, 무고한 사람이 입을 피해를 언급하지 않는 판단을 더 이상 신뢰하기 어렵다는 것
물론 반대 시각도 존재함
문제의 글이 Roma 전체의 추방을 주장한 것은 아니라거나 유럽에서 드물지 않은 정서라는 반박도 있고, DHH의 주장에 동의하는 개발자도 적지 않음
이 사안을 Ruby/Rails 커뮤니티 전체의 합의로 볼 수는 없음
그러나 논쟁은 한 사람의 발언을 넘어 생태계의 권력 구조로 확장됨
Ruby 커뮤니티가 오랫동안 내세운 MINASWAN, "Matz is nice and so we are nice" 라는 구호도 다시 질문받는 중
Matz 개인의 친절함이 생태계 전체의 친절함이나 건강한 권력 구조를 보장하지 않으며, Rails와 Ruby의 주요 권한이 소수의 개인과 기업에 집중돼 있다는 비판
"Matz가 친절하다"는 사실은 중요하지 않다
Rails 상표는 DHH가 소유하고 Rails Foundation이 독점 라이선스로 관리하며, DHH가 재단 이사회 의장과 프로젝트 리더십을 함께 맡는 구조
이미 한 번 무너진 거버넌스
Rails 포크론의 온도를 이해하려면 코드가 아니라 소유권에서 벌어진 일을 봐야 함
Sidekiq은 RailsConf의 DHH 초청을 이유로 Ruby Central에 대한 연 25만 달러 후원을 철회했고, 재정난에 몰린 Ruby Central은 Shopify에 크게 의존하게 됨
2025년 9월 Ruby Central은 기존 유지관리자 동의 없이 RubyGems/Bundler의 GitHub 저장소와 gem 소유권을 인수함
10년 넘게 프로젝트를 관리하던 팀이 접근 권한을 잃었고, Ruby Central은 공급망 보안을 이유로 들었지만 실제 쟁점은 누가 프로젝트를 소유하고 결정할 수 있는가였음
DHH는 이 인수를 지지했지만 과거 WordPress 플러그인 강제 인수에는 반대했던 터라 일관성 부족도 지적받음
강제 인수 과정을 거친 뒤 RubyGems/Bundler 소유권 일부는 Matz와 Ruby 코어 팀으로 이관됐지만 조직의 신뢰는 회복되지 못함
컨퍼런스는 향후 일정을 잡지 못했고 주요 유지관리자와 이사진이 대거 떠남
자세한 경과는 Ruby Central이 남긴 파괴적 유산에 정리돼 있음
여기서 중요한 건 개별 인물의 잘잘못보다 구조
Ruby Central은 커뮤니티가 이사를 선출하지 않으며 새 이사도 기존 이사들이 선임함
기업 후원에 크게 의존하는 조직이 생태계의 핵심 인프라와 권한을 함께 통제하면서 이해충돌 문제도 불거짐
Rails 포크가 지금 진지하게 받아들여지는 건 Ruby 커뮤니티가 이미 "코드는 오픈소스인데 권한은 아니었다" 는 경험을 했기 때문
오픈소스 코드는 누구나 복사할 수 있지만 상표/릴리스 권한/코어 팀 구성/커뮤니티 규범까지 자동으로 분산되는 것은 아님
Rails가 완성됐기 때문에 가능한 포크
Amiko를 만들려는 개발자들은 Rails를 새로 설계할 필요가 없다고 봄
rails new --minimal에 포함되는 railties, actionpack, activesupport, activemodel, activerecord, actionview 같은 핵심 gem은 Rails 6.0이 나온 2019년 이후 큰 변화 없이 안정적으로 유지되고 있음
이후 추가된 주요 기능도 코어 자체보다 선택적으로 결합하는 구성 요소에 가까움
- 여러 세대의 자산 파이프라인
- 다른 프레임워크에서도 사용할 수 있는 JavaScript 라이브러리
- 컨테이너 배포 도구와 Go로 작성된 리버스 프록시
- ActiveJob/ActionCable/캐시를 위한 새로운 기본 백엔드 gem
Rails가 소형 앱부터 대규모 서비스까지 만드는 데 필요한 기본 구조를 이미 갖췄으므로, 보안 패치와 성능 개선을 따라가는 것만으로도 소수의 자원봉사자가 포크를 유지할 수 있다는 판단
Amiko가 목표로 하는 것도 더 혁신적인 Rails가 아니라 "지루할 만큼 안정적이고 친근한 프레임워크"
여기에 명시적인 가치 선언이 따라붙음
Amiko는 나치/트랜스포비아/인종차별을 비롯한 편견을 용납하지 않는 커뮤니티가 개발과 거버넌스를 맡는 것을 목표로 함
리더십에서 벗어나는 중립적인 포크가 아니라 어떤 커뮤니티가 될 것인지를 먼저 선언한 포크
하지만 유지보수는 끝나지 않음
포크 계획에서 가장 자주 지적받는 지점은 "완성됐다"는 전제 그 자체
사용자 관점에서는 주요 API가 안정화됐으므로 완성으로 볼 수 있음
완벽해서가 아니라 지금 크게 깨뜨릴 때의 비용이 이득보다 훨씬 크기 때문
하지만 유지보수자 관점에서는 전혀 끝나지 않았음
버그 수정, 보안 신고 처리, 생태계 호환성 유지, 성능 개선만으로도 상당한 작업량이 필요함
Rails 본체도 새 PR과 이슈를 따라잡는 데 어려움을 겪고 있고 AI 등장 이후 그 부담이 더 커졌다는 지적
더 큰 난점은 네트워크 효과와 생태계 분열
수백 개의 인기 gem이 Rails 내부와 긴밀하게 통합돼 있어 포크가 원본과 갈라질수록 호환성 문제가 커짐
관련 프로젝트들이 원본 Rails와 Amiko를 함께 지원할 이유도 없음
정리하면 "코드는 쉽고 거버넌스가 어렵다"가 아니라 "코드도 생각보다 쉽지 않고, 거버넌스는 그보다 더 어렵다" 에 가까움
포크가 갈 수 있는 길
Amiko의 미래로는 대체로 네 가지 경로를 생각할 수 있음
- 이름만 다른 완전 호환판으로 남는 경우
- 호환성을 유지하면서 패치와 라이브러리를 정리해 더 나은 오마카세 경험을 제공하는 경우
- 오래 운영되며 호환성을 깨고 Rails와 다른 프레임워크가 되는 경우
- 포크의 아이디어가 원본 Rails에 흡수되는 경우
마지막 경로에는 Rails 자신의 역사라는 선례가 있음
2000년대 후반 Merb는 더 빠르고 가벼운 경쟁 프레임워크로 등장했지만 결국 Rails 3.0에 병합됨
Rails 내부를 구성 가능하고 모듈화된 구조로 바꾸는 큰 작업이 뒤따랐고, 경쟁 구현이 원본을 개선한 사례로 남음
다만 Merb는 기술적 이견에서 출발했고 Amiko는 그렇지 않음
기술이 갈등의 원인이 아닐 때 무엇을 계기로 다시 합칠 수 있는지가 이번 포크의 다른 점
Ruby 생태계에는 Rails 대안인 Hanami 가 이미 존재함
Hanami는 현재 Dry, ROM과 함께 Hanakai라는 하나의 커뮤니티 아래에서 개발되고 있음
Amiko 역시 Hanakai의 사명과 가치에 동의하며 이를 대체하거나 Ruby 생태계를 하나로 통일하려는 프로젝트가 아니라고 밝힘
별도 포크를 만들지 말고 Hanakai에 참여해야 한다는 비판도 있지만 Amiko가 내세우는 근거는 이전 비용
대형 Rails 애플리케이션을 다른 프레임워크로 다시 작성하기 어렵거나, Rails의 설계는 선호하지만 현재 리더십에는 동의하지 않는 사용자를 위한 선택지라는 것
여기에 이번 포크의 역설이 있음
Rails가 포크될 수 있을 만큼 완성된 건 DHH가 20년 동안 강한 방향성을 유지했기 때문
Rails를 포크해야 한다는 요구가 나온 것도 DHH 한 사람에게 너무 많은 방향성과 상징성이 묶여 있기 때문
코드와 창시자를 분리할 수 있을까
Amiko의 어려움은 Rails 코드를 유지하는 데만 있지 않음
Rails 특유의 단호한 설계 결정을 여러 사람이 합의하는 거버넌스에서도 유지할 수 있는지가 더 큰 문제
모든 의견을 수용하는 순간 Rails의 장점이었던 일관성이 사라질 수 있고, 반대로 또 다른 강한 지도자에게 의존한다면 기존 구조를 반복하게 됨
Ruby Central 사태가 보여준 것도 결국 선출되지 않은 소수가 결정하는 구조는 누가 앉든 같은 문제를 만들 수 있다는 점
DHH 없는 Rails가 성공하려면 기존 Rails와 호환되는 코드를 만드는 것만으로는 부족함
- 한 사람의 취향에 의존하지 않으면서도 Rails다운 선택을 할 수 있는 구조
- 리더의 정치적 발언과 프로젝트 전체의 정체성을 분리할 수 있는 거버넌스
- 커뮤니티가 참여하는 의사결정과 공개적으로 운영되는 상표/릴리스 권한
이는 추상적인 이야기가 아님
Ruby 커뮤니티에서는 gem.coop처럼 유지관리자가 공개적으로 운영하는 거버넌스, PSF처럼 커뮤니티가 이사를 선출하는 조직이 구체적인 대안으로 제시되고 있음
Amiko가 Codeberg에 거버넌스 저장소부터 열어 둔 것도 같은 맥락
"Rails는 완성됐다" 는 말은 기술적인 평가이면서 동시에 독립 선언임
물론 Rails가 DHH의 가장 큰 작품이라는 사실은 바뀌지 않음
Rails의 다음 과제는 DHH의 작품을 넘어 공동체가 이어가는 기반으로 자리 잡는 것