Rails는 이제 어디로 가나요?

AI 요약

David Heinemeier Hansson(DHH)은 Rails World 2026 기조연설에서 Rails의 미래보다 LLM이 바꿀 개발 방식과 37signals의 새 전략을 이야기했습니다. 글쓴이는 Rails 기반 제품을 만드는 개발자에게 DHH의 선택이 직접 영향을 준다고 말하며, 연설에서 빠진 질문을 짚습니다. Rails는 앞으로 어떤 제품과 개발 방식을 뒷받침하며, 누가 그 방향을 이끌까요?

Hey가 Rails를 떠나는 이유

DHH는 자신을 전문 프로그래머가 아니라 ‘메이커’라고 부르며, LLM이 코드를 만들면 사람이 결과물을 읽지 않아도 된다고 주장합니다. 손으로 코드를 쓰는 일은 대부분의 회사에서 경제적으로 생산적이지 않다는 입장입니다. 37signals는 Hey의 다음 버전을 웹 앱이 아닌 플랫폼별 네이티브 앱으로 만들고, 서버에는 Rust를 쓰기로 했습니다. DHH는 Rust를 사람이 쓰기에는 끔찍하지만 LLM에는 좋다고 말합니다.

그는 올해 8월 LLM으로 코드 15만 줄을 작성했다고 밝혔습니다. LLM 시대 전에는 연간 약 3만 줄을 썼고, 지난 20년간 작업의 절반을 차지했던 Ruby는 올해 작성한 코드에서 3%에 그쳤다고 합니다. 앞으로는 사람이 코드를 읽는 일이 Sentry에서 버그를 보는 일처럼 예외가 될 거라고도 했습니다. 연말이면 거의 모든 분야와 개발자, 회사가 이 흐름에 들어설 거라고 내다봤습니다. 서비스마다 CLI를 제공해 에이전트가 UI 없이 조작하게 하자는 주장도 내놨습니다.

Rails의 방향이 빠졌습니다

글쓴이는 Rails가 오랫동안 ‘적은 인원으로 야심 찬 제품을 만드는 프레임워크’로 소개됐다고 짚습니다. Rails 덕분에 작은 팀이 많은 일을 해낸 경험은 자신과 다른 개발자에게도 익숙합니다. 그러나 이번 연설에서 DHH가 설명한 Rails의 역할은 웹 앱을 만들어야 할 때 쓰는 안정적인 프레임워크, 또는 AI 개발에 적합한 프레임워크에 가까웠습니다. Rails의 창시자가 대표 제품을 Rails에서 옮기겠다고 발표하면서도 Rails 자체의 다음 계획은 제시하지 않았다는 게 글쓴이의 불만입니다.

글쓴이는 Rails가 성숙하고 안정적이라는 점은 에이전트 기반 개발에 유리할 수 있다고 인정합니다. 다만 안정성을 유지보수 전략으로 삼을지, 새로운 개발 방향을 제시할지 밝히지 않았다고 말합니다. DHH가 Rails 개발자들에게 건넨 말은 “최고 중의 최고”라는 격려였지만, 글쓴이는 구체적인 계획 대신 자신감을 북돋우는 말만 남았다고 봅니다. Mosscap은 정치적 이유로 Rails에서 갈라져 나온 프로젝트이며, Rails가 사실상 끝났다는 주장을 펼칩니다. Hanami는 Ruby 웹 개발의 미래를 위한 로드맵을 제시하고 있습니다. 글쓴이는 Rails 역시 누가 이끌며 어디로 향할지 설명해야 한다고 요구합니다.

생산성·성능 수치에 대한 의문

글쓴이는 DHH가 코드 줄 수를 생산성 지표로 쓰기 어렵고 언어 간 비교도 공정하지 않다고 인정한 뒤, LLM이 만든 Rust 15만 줄과 과거 Ruby 3만 줄을 비교한다고 비판합니다. DHH가 LLM의 Rust 코드는 자신이 Ruby에서 허용할 수준보다 장황해도 받아들인다고 말한 만큼, 두 수치를 같은 기준으로 볼 수 없다는 지적입니다. ‘코드를 썼다’는 표현도 실제로 읽지 않은 생성 코드를 포함해 모호하다고 봅니다.

Hey의 새 서버가 CPU 사용량을 99%, 메모리를 95% 줄이고, 단일 Raspberry Pi에서도 최대 트래픽을 처리할 수 있다는 주장에도 비교의 한계가 있다고 말합니다. 새 버전은 웹 프런트엔드를 없애고 네이티브 앱을 쓰므로, 개선분 가운데 Rust가 차지하는 몫과 구조 변경이 차지하는 몫을 구분하기 어렵습니다. 같은 구조를 사람이 Rust로 작성해도 성능을 얻을 수 있지만, DHH는 사람이 Rust 코드를 쓰지 않아도 된다는 주장을 하고 있습니다.

개발자 생산성이 10배, 100배, 1000배 높아진다는 주장도 근거가 충분하지 않다고 지적합니다. DHH가 언급한 연구는 개발자 생산성이 아니라 개발 도구 사이의 차이를 측정했으며, ‘평균 10배’라는 수치도 원래 논문에 없었다고 설명합니다. 또한 Basecamp 5의 아키텍처가 ‘스위스 치즈’처럼 됐다는 DHH의 발언을 들어, 검토 없이 조율되지 않은 기여가 쌓이면 사람이 작성했든 에이전트가 작성했든 구조가 나빠질 수 있다고 말합니다. 자동화에 맡긴 연설의 ATM 역사 설명도 시기와 경제학자, 은행 창구 직원 수가 틀렸다고 지적합니다. 코드를 읽지 않아도 된다는 주장과 보안에 대비해야 한다는 경고 사이에 설명이 빠져 있다는 문제도 제기합니다.

낙관론보다 계획을

글쓴이는 DHH의 AI 주장 자체가 가장 큰 문제는 아니라고 선을 긋습니다. 37signals가 어떤 도구로 제품을 만들지는 그들의 선택입니다. 문제는 Rails World에서 대표 제품을 Rails 밖으로 옮긴다고 발표하면서도, Rails 개발자에게 향후 방향을 제시하지 않았다는 점입니다. Rails가 안정성을 중심으로 유지보수 단계에 들어섰다면 누군가 그 계획을 말해야 하고, 그렇지 않다면 다음 목표를 설명해야 한다고 요구합니다. 연설은 AI에 대한 낙관론과 비관론을 거부하라는 말로 마무리됐지만, 글쓴이는 낙관론이 전략이나 근거를 대신하지 못한다고 주장합니다.

Hacker News 반응

• @potato-peeler — 연설을 보면 Rails는 포크가 필요하다는 점이 분명합니다.
  • @homarp — https://mosscap.dev/가 포크 아닌가요?
  • @ernsheong — 이 일이 DHH 때문에 시작된 것처럼 보입니다. 기술은 기술 자체로 판단해야 합니다. 그렇지 않으면 우리는 특정한 죄를 짓지 않았다는 이유로 남보다 도덕적으로 우월하다고 여기는 태도를 보이게 됩니다. 자기 자신을 솔직하게 돌아보면 우리도 같은 죄를 여럿 짓고 있습니다. 기술은 기술 자체로 판단하고 개인의 이념은 빼야 합니다. 제 생각입니다. 어차피 반대표를 받겠지만요.
• @pantulis — 이번 기술 변화에 대한 DHH의 견해에는 대체로 동의하지만, 이 글은 비판을 아주 잘 구성했습니다.
• @Lio — Ruby 세계에서 실제로 개선된 내용을 이야기했다면 더 관심이 갔을 겁니다. YJIT, ZJIT, JRuby, TruffleRuby 같은 빠른 JIT가 있고, RBS 정적 타입과 Spinel AOT 컴파일러도 있으며, Crystal을 임베드할 수도 있습니다. RBS를 쓰는 TruffleRuby나 Spinel은 Go와 성능 차이가 아주 크지 않습니다. 정적 타입을 쓰더라도 Ruby는 같은 해결책을 표현하는 데 Go보다 컨텍스트 창 토큰을 적게 씁니다. Hotwire도 Apple 앱스토어 심사를 거치지 않고 네이티브에 가까운 경험을 제공한다는 게 DHH의 주장이었습니다. 긍정적으로 이야기할 내용이 많았지만 그러지 않았습니다.
• @Twey — “사람들은 UI를 쓰고 싶어 하지 않으니 UI를 만들지 말고, 모든 앱을 챗봇으로 쓰는 API로 만들자”는 이야기를 요즘 자주 봅니다. 예전에는 소프트웨어가 기능과 가치 면에서 유연하고 조합 가능해야 한다는 주장을 셸 파이프라인을 두고 했습니다. 하지만 소프트웨어를 신발처럼 제품으로 팔려는 모델과는 맞지 않습니다. 제품으로 팔려면 큰 단일 앱과 인상적인 UI가 필요하기 때문입니다. LLM은 기술 지식이 많지 않은 사람도 사람이 쓰도록 만든 데이터와 인터페이스 위에 ‘프로그래밍 가능한’ 층을 쉽게 덧붙이게 합니다. 결국 API에서 UI로 갔다가 다시 API로 돌아오는 비싼 경로가 생깁니다. 다만 챗봇은 대부분의 작업에 좋은 UI가 아니며, 범용 UI를 만드는 문제도 남아 있습니다.
  • @zsoltkacsandi — 스마트폰이 처음 나왔을 때도 ‘모바일 우선’이라며 데스크톱은 죽고 모든 앱을 스마트폰 중심으로 만들어야 한다고 했습니다. 결국 스마트폰은 어떤 일에는 좋고 다른 일에는 적합하지 않은 또 하나의 인터페이스였습니다. 클라우드 네이티브도 마찬가지였습니다.
  • @jon-wood — 모든 사람이 그걸 원한다고 생각하지 않습니다. 제가 원하는 소프트웨어는 주요 작업을 잘 설계한 UI로 제공해, 데이터 모델을 어떻게 조작할지보다 이루려는 목표에 집중하게 합니다. 여기에 기반 데이터도 접근 가능하게 해주세요. 로컬에서 쓸 수 있는 API가 가장 좋고, 필요하면 원격 API도 괜찮습니다. CLI도 제공하면 좋습니다.
• @xiphias2 — 글은 DHH가 연설을 시작할 때 청중에게 손으로 코딩하는 사람이 몇 명인지 물었고, 다섯 명만 손을 들었다는 점을 빼먹었습니다. 저도 작년 Rails의 단순화가 마음에 들어서 새로운 변화를 기대했습니다. DHH가 AI로 Rails 개발을 가속할 수도 있었지만, 성숙한 시스템을 망가뜨리지 않도록 이제 안정된 상태라고 말하는 선택도 이해합니다.
  • @tene80i — 그건 대중 연설 기법에 가까웠습니다. “아직도 X를 하는 사람이 몇 명인가요?”라고 물으면 그 행동을 어리석고 뒤처진 것처럼 규정하므로 손을 드는 사람이 적기 마련입니다.
• @fhub — Rails 스택을 개발하고 유지보수합니다. 엔드포인트 응답 시간의 약 20%가 Ruby에서 발생합니다. New Relic 기준 Apdex는 99이고, 100ms를 넘는 엔드포인트는 드뭅니다. 대부분 80ms 이내입니다. 언젠가 LLM으로 이식하겠지만 사용자 응답 속도 때문은 아닙니다. Shopify 네이티브 앱처럼 빠른 제품 코어를 빠르게 테스트하고, 느린 UX 층을 분리하는 방식이 미래처럼 보인다는 점 때문에 전환을 고민합니다. 그런 세상에서는 Rails가 끝난 것처럼 보입니다.
• @bionsystem — SRE로서 “LLM이 만든 코드를 읽지 않아도 된다”는 주장에 경험 많은 개발자들이 어떻게 생각하는지 궁금합니다. 에이전트 하나보다 더 많은 에이전트를 관리하려면 그 방식이 유일한 길처럼 느껴집니다. 하지만 내부 동작을 사람이 이해하지 못하게 됩니다. LLM이 훌륭한 코드와 테스트를 쓴다고 믿으면 괜찮겠지만, 심각한 산업에서는 99.9% 신뢰로는 부족하고 100% 신뢰가 필요하지 않나요? 결국 배포 코드도 작성하고 배포 자체도 맡겨야 합니다. 그렇지 않으면 SRE가 병목이 됩니다.
  • @jmalicki — “코드 실행은 에이전트 한 개가 생성하는 것보다 항상 느리다”는 말은 많은 경우 전혀 사실이 아닙니다. 에이전트는 코드를 생성하는 데 무척 오래 걸립니다. 제 경험으로는 그 추론 과정을 실행 코드로 바꾸는 작업 흐름이 대체로 더 빠릅니다.
• @chvid — Rails가 창시자에게 크게 의존하므로 이미 죽었다는 건 분명해 보입니다. DHH가 다른 사람에게 주도권을 넘기지 않고 이런 식으로 끝내려는 점도 의미심장합니다. 기술적으로 보면 여러 네이티브 클라이언트를 쓰는 설계에는 서버 렌더링 HTML이 필요하지 않으므로, 언어와 무관하게 서버 부하가 줄어듭니다. Ruby로도 가벼운 JSON API를 만들 수 있으며, 컴파일 언어로 구현한 비슷한 서버와 비교해도 네트워크와 데이터베이스 사용량이 성능을 좌우할 겁니다.
  • @kjksf — https://github.com/rails/rails/commits/main/ 과 https://github.com/rails/rails/graphs/contributors?from=6%2F...를 보세요. DHH는 기여 기록에 커밋이 없습니다. 이미 주도권을 다른 사람에게 넘긴 것으로 보입니다.
• @jpgvm — Rails가 끝났다고 해도 나쁜 일은 아닙니다. 사람이 코드를 쓰지 않는다면 Rails가 주던 장점이 무엇인가요? Rails는 빠른 시작과 낮은 초기 비용을 주는 대신 성능과 타입 시스템을 포기했습니다. 이제 AI 덕분에 모든 생태계에서 빠르게 시작할 수 있습니다. 유지보수 비용은 토큰을 얼마나 효율적으로 써서 문제를 찾고 고치느냐에 달렸습니다. 사람이 프로그래밍 언어 선택에서 더는 지배적인 요소가 아니라는 사실이 아직 모두에게 받아들여지지 않았을 뿐입니다. Rails는 끝났지만, 다음에 올 일은 훨씬 더 흥미롭습니다.
• @jcmontx — Rails의 강점은 생산성, 개발자 경험, 강한 관례였습니다. 에이전트 기반 코딩 시대에는 그중 두 가지가 중립화됐지만, 2026년에 새 CRUD 중심 업무 앱을 만들 때 Rails를 선택하는 이유로 강한 관례는 여전히 유효합니다. Hey가 생산성과 성능 사이에서 고른 절충은 생산성이 크게 높아진 지금 더는 유리하지 않으니, 성능과 네이티브 UX를 우선하자는 선택도 이해합니다. 다른 프레임워크도 마찬가지입니다. Rails, Django, Laravel, .NET, JVM은 이미 성숙해 유지보수 모드로 바뀌어도 문제없을 만큼 기능을 갖췄습니다. 그렇다면 프레임워크의 미래가 무엇일지는 모르겠습니다.

원문: jardo.dev / 번역·요약: Trawling