루비 온 레일스(Ruby on Rails)의 창시자 데이비드 하이네마이어 한손(DHH)이 Rails World 2026 개막 기조연설에 올랐다. 세계 최대 규모의 Rails 컨퍼런스이고, 관례상 이 자리는 프레임워크의 향후 방향을 제시하는 무대다. 그런데 정작 이번 발표에서 Rails에 관한 내용은 놀라울 만큼 적었다. 개발자 야르도(jardo.dev)가 이 연설을 정리하고 반박한 글은, DHH가 정작 자신이 책임진 프레임워크에 대해 거의 아무 말도 하지 않았다는 점을 문제 삼는다.
DHH는 스스로 "전문 프로그래머에서 은퇴했다"고 선언했다. 소프트웨어 개발을 그만둔다는 뜻이 아니라, 이제 자신을 '메이커(maker)'로 규정하며 손으로 코드를 짜는 일이 대다수 기업의 대다수 프로그래머에게 더는 경제적으로 생산적인 활동이 아니라고 주장했다. 그는 영어가 최고의 프로그래밍 언어이며(LLM 때문에), LLM이 만든 코드를 굳이 읽을 필요조차 없다고까지 말했다. 코드를 사람이 직접 들여다보는 일은 "센트리(Sentry)에서 버그를 발견하는 것"처럼 예외적인 사건이 되어야 한다는 것이다.
자신의 대표 제품을 Rails에서 떼어내다
가장 상징적인 대목은 37signals가 만드는 이메일 서비스 Hey의 차기 버전이 Rails를 떠난다는 발표였다. DHH는 오랫동안 "작은 팀이 야심찬 제품을 만들 수 있게 해주는" 도구로 Rails를 내세워 왔다. 그러나 이제는 병목이 사라졌다며, 지원하는 모든 플랫폼용 네이티브 앱을 LLM으로 만들고, 서버는 Rust로 간다고 밝혔다. 그는 Rust를 "흉측하고 사람이 겪어서는 안 될 언어"라고 평하면서도, 어차피 코드를 읽지 않으니 언어의 성능과 안정성만 취하면 된다고 했다.
수치도 함께 제시됐다. DHH는 올해 8월 한 달에 15만 줄의 코드를 작성했다고 주장했다. LLM 이전 시대에 연평균 약 3만 줄이던 것과 비교한 수치다. 지난 20여 년간 그의 작업 절반가량이 Ruby였지만, 올해는 3%에 불과하다고 했다. 야르도는 이 비교 자체가 성립하지 않는다고 지적한다. DHH 스스로 "줄 수는 나쁜 지표"이고 언어 간 비교가 불공정하다고 인정한 뒤, 손으로 쓴 간결한 Ruby와 LLM이 쏟아낸 장황한 Rust를 곧바로 나란히 놓았기 때문이다. Hey Next의 "CPU 99% 절감, 메모리 95% 절감" 같은 수치도 Rust 전환 덕분인지, 웹 앱이라는 형태를 버린 덕분인지 구분할 수 없다는 것이 반박의 요지다.
Rails 개발자에게 남긴 것은 격려뿐
연설에서 DHH가 Rails 개발자를 직접 향해 말한 유일한 순간, 그가 꺼낸 것은 전략이 아니라 격려였다. "당신은 Rails 프로그래머다. 최고 중의 최고다. 약간의 경쟁을 두려워할 이유가 없다"는 식의 말이었다. 야르도는 이것이 계획이 아니라 안심시키기에 불과하며, 같은 문장을 Django나 Laravel, 스프링 부트 개발자 앞에서 토씨 하나 안 바꾸고 그대로 해도 통했을 것이라고 꼬집는다. 컨벤션 오버 컨피규레이션은 이제 'AI 토큰 효율성'으로 재포장됐고, Rails는 '선택'이 아니라 '어쩔 수 없는 웹 앱을 위한 차선책'으로 위상이 좁아졌다는 해석이다.
연설 곳곳의 모순도 짚인다. 37signals는 원래 새 버전을 만들 때마다 앱을 통째로 다시 쓰는 회사이며, 성공의 동력은 어려운 기술 문제 해결이 아니라 제품과 마케팅이었다. 그런데 DHH는 웹의 완성도가 부족하다며 Hey를 여섯 개 네이티브 앱으로 다시 쓴다고 하면서도, 동시에 모든 서비스가 에이전트가 다룰 CLI를 제공해야 한다고 요구했다. UI가 완전 재작성을 정당화할 만큼 중요하다면서, 다른 한편으로는 모두가 CLI만 원한다는 주장은 서로 충돌한다. 또한 그가 인용한 '10배 개발자' 근거는 원래 개발 도구 차이를 측정한 연구였고 논문 어디에도 '평균 10배'라는 수치는 없다. AI가 은행 창구 직원을 늘렸다는 ATM 일화 역시 시대와 경제학자, 직원 수치가 모두 틀렸다고 지적된다.
실무자가 읽어낼 것
한국의 Rails·Ruby 실무자에게 이 연설이 갖는 의미는 기술 선택보다 거버넌스에 있다. DHH가 자신의 대표 제품을 스택에서 빼고 Ruby 작성 비중을 3%로 줄인 상황에서, Rails의 방향을 앞으로 누가 이끌 것인가라는 질문이 남는다. 정치적 이유로 갈라진 Mosscap 진영은 Rails가 이미 완성되어 유지보수만 필요하다고 보고, Hanami는 별도의 로드맵과 비전을 내세운다. 일상적인 Rails 유지보수 상당 부분은 Shopify 등에서 나오지만, 비전은 역사적으로 DHH가 이끌어 왔다.
에이전트 기반 개발의 한계 역시 남의 이야기가 아니다. DHH는 LLM으로 만든 Basecamp 5의 아키텍처가 "스위스 치즈 같았다"며 모델 탓을 했지만, 검토도 조율도 없는 기여는 사람이 하든 에이전트가 하든 구조를 망가뜨린다. 토비 뤼트케가 언급한 '슬롭 수류탄(slop grenades)' 위험도 같은 맥락이다. "코드를 절대 보지 말라"는 주문과 "보안, 뭔가 오고 있으니 대비하라"는 경고가 한 연설 안에서 15분 간격으로 등장하는 것 자체가, 손을 떼는 개발과 검증 사이의 메울 수 없는 간극을 드러낸다. 사람이 검증하고 다시 지시하는 루프가 있는 한 작은 앱과 쉬운 문제에서는 잘 작동하지만, 그것을 "12월까지 사실상 모든 프로그래머, 모든 기업"으로 확대하는 근거는 연설 어디에도 제시되지 않았다. 결국 Rails가 유지보수 단계로 접어드는 것이라면 그렇다고 말해야 하고, 아니라면 어디로 가는지 밝혀야 한다. DHH는 둘 다 하지 않은 채 낙관만 남겼다.