DHH 의 Rails World 2026 키노트 Part 2: 옹호와 반박, 그리고 제3의 길

이 글은 Claude Fable 5.1 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며#

Part 1 에서는 2026년 9월 23일 Rails World 2026 개막 키노트에서 DHH 가 실제로 말한 것을 챕터 순서대로 재구성하고 숫자를 검증했습니다. 이번 편은 그 뒤에 벌어진 일입니다.

수집 범위는 다음과 같습니다.

• Hacker News 스레드 두 개. 영상 자체를 올린 스레드 (9월 28일 기준 439점, 댓글 498개) 와, Jared Norman 의 비판 글 “What About Rails?” 를 올린 스레드 (331점, 댓글 230개)
• 참석자와 Rails 커뮤니티 구성원, 외부 관찰자의 블로그 글 열댓 편 (9월 24일~28일)
• Ruby Users Forum 스레드, YouTube 댓글 (2차 인용), 한국 GeekNews 의 댓글
• 이틀 뒤 같은 무대에서 열린 Aaron Patterson 의 폐막 키노트

수집하지 못한 것도 밝혀 둡니다. Reddit 과 X 는 이 글을 쓰는 환경에서 접근할 수 없었고, 9월 24일 열린 Matz 와 DHH 의 대담은 영상은 있으나 전사본을 확보하지 못해 다루지 않습니다. 따라서 이 글은 “인터넷 전체의 여론” 이 아니라 공개 글로 남은 반응 의 정리입니다.

반응의 지형#

읽어 나가기 전에 지형을 그려 두겠습니다. 반응은 크게 세 갈래였고, 각 갈래 안에서도 근거가 달랐습니다.

flowchart LR
    K["DHH 키노트<br/>2026-09-23"]
    K --> C["비판"]
    K --> S["옹호"]
    K --> T["제3의 길"]
    C --> C1["Rails 는 어디 갔나<br/>키노트 범위 불일치"]
    C --> C2["스위스 치즈의 교훈은<br/>모델이 아니라 소유권"]
    C --> C3["숫자와 방법론"]
    C --> C4["돈과 계급<br/>「방 분위기를 읽어라」"]
    C --> C5["정치와 공동체<br/>Mosscap 포크"]
    S --> S1["현장은 장례식이<br/>아니었다"]
    S --> S2["경제 논리는<br/>맞다"]
    S --> S3["개인용 소프트웨어의<br/>귀환"]
    T --> T1["Notation Up<br/>Rails 를 컴파일하라"]
    T --> T2["언어와 아키텍처를<br/>분리해서 보라"]
    T --> T3["Aaron Patterson<br/>폐막 키노트"]
    style K fill:#FFD700,color:#000000
    style C fill:#FF9999,color:#000000
    style S fill:#90EE90,color:#000000
    style T fill:#87CEEB,color:#000000

먼저 밝혀 둘 것이 있습니다. 반응의 총량은 비판 쪽이 훨씬 많았습니다. 그러나 비판의 다수는 “AI 가 코드를 쓴다” 는 명제 자체를 부정하지 않았습니다. 쟁점은 다른 곳에 있었습니다.

1. 비판#

1-1. “Rails 는 어디 갔나”#

가장 많이, 가장 일관되게 나온 비판입니다.

세션 안내 페이지에 적힌 이 키노트의 설명은 “Rails 의 새 소식, 다음에 올 것, 그리고 Rails 가 향하는 곳” 이었습니다. Global Nerdy 의 Joey deVilla 는 63분 동안 “Ruby” 라는 단어가 11번 나왔다고 셌습니다. HN 의 stephenhuey 는 현장 채팅에서 “Rails World 를 여는 키노트로는 최악” 이라는 반응이 나왔다고 전했고, Aurornis 는 이렇게 썼습니다.

“블로그 글 한 편이면 됐을 내용이었다. 사람들은 699달러짜리 티켓과 여행 경비를 내고 Rails 이야기를 들으러 왔는데, AI 와 Rust 강의를 듣고 ‘패배자가 되지 말라’ 는 훈계를 받았다.”

toobulkeh 는 “성전에 와서 다른 종교를 설교하는 것처럼 어이없이 무례하다” 고 했고, robgough 는 조금 더 구조적인 지적을 합니다. DHH 의 관점이 프레임워크를 책임진 사람이 아니라 프레임워크를 쓰는 사용자의 관점 이며, 에이전트 시대에 맞춰 Rails 를 어떻게 바꾸고 있는지에 대한 이야기가 전혀 없었다는 것입니다. GeekNews 의 한 댓글도 같은 결을 짚었습니다. “에이전트 코딩에 적극적이지만 프레임워크를 맞춰가는 모습은 보이지 않음.”

이 비판을 가장 길게 쓴 글이 Jared Norman 의 “What About Rails?” (9월 24일) 입니다. 그는 자신이 DHH 의 AI 주장에 회의적이라고 밝히면서도 “그것이 진짜 문제는 아니다” 라고 씁니다. 진짜 문제는 이것입니다.

“그는 자기 제품을 Rails 에서 옮기겠다고 모두에게 말했고, 아직 Rails 를 쓰는 사람들에게 해 줄 수 있는 최선의 말이 ‘여러분은 최고 중의 최고’ 였다.”

Norman 이 요구하는 것은 명확한 신호입니다. Rails 가 이제 유지보수 위주로 가는 것인지 (2026년 8월 Lucas Dohmen 이 “Rails is done” 이라는 글에서 주장한 대로), 아니면 전략적 개발이 계속되는 것인지, 둘 중 어느 쪽이든 리더가 말로 해야 한다는 것입니다. “낙관은 전략이 아니다” 가 그의 결론입니다. HN 에서 ksec 는 같은 요구를 한 문장으로 줄였습니다. “누군가는 말해야 한다.”

Ruby Users Forum 의 스레드는 더 직설적이었습니다. 한 참여자는 회사가 이제 Rust, Java, Swift 로 만든다는 발표를 두고 “DHH 는 정신이 나갔다” 고 썼고, 다른 참여자는 “1인 프레임워크”¹ 라는 개념을 버린 것에 당혹감을 표했습니다. 독일 heise 는 이 발표가 X 의 알림 시스템을 마비시킬 정도였고 참석자들이 “키노트 전통에서 내파 (implosion) 로의 분위기 전환” 을 느꼈다고 보도했습니다.

1-2. 스위스 치즈의 진짜 교훈은 모델이 아니라 소유권#

Part 1 에서 예고한 반박입니다. 전 CISO 이자 창업자인 Jared Smith 는 키노트의 방향에 상당 부분 동의하면서도 Basecamp 5 이야기에서 DHH 가 잘못된 교훈 을 끌어냈다고 씁니다.

DHH 의 서사는 이렇습니다. 디자이너들이 바이브 코딩한 PR 20~30개가 개별적으로는 괜찮았지만 합쳐지자 아키텍처가 스위스 치즈가 되었고, 수동 리뷰로 되돌린 것은 틀린 결론이었으며, 더 나은 모델 (Fable) 이었다면 괜찮았을 것이라는 이야기입니다.

Smith 의 반론은 이것입니다.

“합리적인 결정 스무 개가 합쳐져 비합리적인 시스템이 되는 일은, 그 결정이 엔지니어 스무 명에게서 왔든, 에이전트 스무 개에게서 왔든, 아주 좋은 모델 하나에게 스무 번 따로 물어서 왔든 똑같이 일어난다.”

모델의 품질은 국소적 정확성 을 높이지만 시스템 전체의 책임 을 만들어 주지는 않습니다. 실패의 원인은 코드 품질이 아니라 소유권의 부재였고, 한 사람이 한 달에 15만 줄을 만드는 세상에서는 그 문제가 사라지는 것이 아니라 기본 상태 가 된다는 것입니다. 그는 DHH 의 DRY 무용론에도 같은 논리를 적용합니다. 반복은 원래 쓰기 비싼 것이 아니라 동기화하고 리뷰하기 비싼 것 이었고, 모델이 함수 열 벌을 복사한다고 리뷰어의 부담이 열 벌에서 한 벌로 줄지는 않는다는 것입니다.

현장의 목소리도 있었습니다. HN 의 rglullis 는 자기 팀의 경험을 이렇게 썼습니다.

“팀 전원이 AI 가 내놓는 것에 도장이나 찍는 사람이 되었다. 산더미 같은 문서를 만들어 내지만 시스템을 이해하는 사람은 없다. 우리는 슬롭 홀의 청소부가 된 기분이다.”²

booty 는 거대한 AI 생성 PR 을 사람이 리뷰할 수 있게 제시하는 문제가 “가장 큰 미해결 문제 중 하나” 라고 했고, mattm 은 “이 조증 국면이 지나면” 작고 집중된 커밋이라는 오래된 관행이 다시 이길 것이라고 예측했습니다.

1-3. 숫자와 방법론#

Part 1 의 검증 표와 겹치는 부분이므로 새로운 지적만 추립니다.

Jared Norman 은 비교의 기준이 어긋나 있다고 지적합니다. 에이전트가 만든 장황한 Rust 와 손으로 쓴 간결한 Ruby 를 줄 수로 비교하는 것, HEY 의 성능 개선을 전부 Rust 덕으로 돌리면서 웹 프론트엔드를 없앤 효과를 빼놓는 것 모두 그렇습니다. 그는 또 하나의 모순을 짚습니다. UI/UX 가 HEY 전면 재작성을 정당화할 만큼 중요하다면서 에이전트를 위해 CLI 를 우선하라는 것은 앞뒤가 맞지 않고, 보안 우려와 “코드를 절대 보지 않는다” 는 실천이 15분 간격으로 나왔는데 둘을 조화시키려는 시도가 없었다는 것입니다.

GeekNews 의 댓글 하나도 같은 문제를 정확히 짚었습니다. “렌더링 전체를 클라이언트로 옮겼으니 성능 수치만으로는 의미가 없음.” LaunchKit 은 이 점을 조금 더 친절하게 풀었는데, 서버 사이드 렌더링을 없애면 언어를 바꾸기도 전에 CPU 소비의 대부분이 사라지므로 Raspberry Pi 수치는 Rust 대 Ruby 의 이야기가 아니라 아키텍처의 이야기 라는 것입니다.

1-4. 돈과 계급: “방 분위기를 좀 읽어라”#

HN 영상 스레드에서 가장 긴 하위 스레드는 AI 도구 비용에 관한 것이었습니다. nickjj 는 프리미엄 모델 구독이 월 200달러 이상이고 이것이 연봉 10만 달러 개발자에게는 수입의 2~8% 라고 계산했습니다. farlight 는 미국 밖에서 “월 수백 달러” 는 월급의 대부분이며 “AI 냐 굶느냐” 의 선택이 된다고 썼고, tomgp 는 프리미엄 모델이 정당하다 해도 그 비용은 개인이 아니라 고용주가 내야 한다고 했습니다.

생산성이 임금으로 돌아오느냐는 질문에는 냉소가 많았습니다. oefrha 는 “AI 로 생산성이 올랐으니 10% 올려 달라” 고 하면 “그럼 네가 왜 필요한데” 라는 답이 돌아올 것이라고 했고, andrewmutz 가 “HEY 는 예전에 네이티브 팀 여섯 개를 감당할 수 없었는데 이제 해고 없이 그것을 할 수 있다” 고 옹호하자 didibus 는 “그건 해고처럼 들리는데” 라고 받았습니다.

그리고 DHH 개인의 위치에 대한 지적이 있었습니다. lbrito 는 “수백만 달러를 가진 사람은 낙관하기 쉽다” 고 썼고, jstummbillig 는 AI 가 자기 수입원을 위협할 때 태연한 부자는 드물다고 했습니다. YouTube 댓글 중 여러 글이 인용한 두 줄은 이것입니다.

“Rails 이야기를 들으러 왔는데 패배자라는 소리를 들었다.”

“방 분위기를 좀 읽어라, 제발.”

이 비판의 핵심은 AI 의 능력이 아니라 톤 입니다. 불안한 현직 엔지니어 천 명 앞에서 “검은 알약은 패배자들 것”³ 이라고 끝맺은 것이 문제였다는 것입니다.

1-5. 배경: 정치와 공동체#

이 키노트가 유독 격한 반응을 만든 데는 연설 바깥의 맥락이 있습니다. Global Nerdy 는 이 키노트를 두 위기의 교차점으로 놓습니다. 하나는 생성형 AI 가 장인 기술로서의 소프트웨어 개발에 가하는 충격이고, 다른 하나는 DHH 의 정치적 발언과 권력 집중을 둘러싼 Ruby 생태계 내부의 다년간의 반발 입니다.

후자를 짧게 정리하면 이렇습니다.

• 2025년 초, Sidekiq 의 Mike Perham 은 Ruby Central 이 DHH 를 RailsConf 2025 연사로 초청한 데 항의해 연 25만 달러의 후원을 철회했습니다.
• 2025년 9월, Ruby Central 이 RubyGems 와 Bundler 의 저장소와 주요 gem 의 통제권을 예고 없이 가져가면서 장기 유지보수자들이 “적대적 인수” 라고 반발하고 일부가 사임했습니다. 그 뒤에 Shopify 의 자금 압박이 있었다는 보도가 이어졌습니다. 이때 Rails 팀과 Ruby 커뮤니티가 DHH 와 관계를 끊어야 한다는 공개 서한도 나왔습니다.
• 2026년 8월, Lucas Dohmen 이 “Rails is done” 이라는 글과 함께 Mosscap 이라는 Rails 포크를 시작했습니다. 목표는 Rails 8.x 의 LTS⁴ 를 “편견을 용납하지 않는 공동체” 가 유지하는 것이고, 프로젝트 사이트는 이유로 DHH 가 극우 정치인을 지지하고 유럽의 “재이주 (remigration)”⁵ 정책을 옹호했다는 점, 그리고 Rails Core 팀이 이에 대응하지 않았다는 점을 듭니다. Mosscap 은 BDFL⁶ 을 두지 않는 위원회 거버넌스를 표방합니다.

이 맥락에서 보면 “Rails 를 쓰는 사람은 최고 중의 최고” 라는 격려가 왜 위로가 되지 못했는지 이해가 됩니다. Global Nerdy 가 인용한 한 비판자의 말은 이렇습니다. “그는 기술적 취향은 뛰어나지만 좋은 리더가 아니다.” GeekNews 에도 “개발자 행사가 특정 태도를 드러내는 사람에게 발표 기회를 준다” 는 취지의 댓글이 있었습니다.

이 글은 이 논쟁의 옳고 그름을 판정하지 않습니다. 다만 키노트에 대한 반응을 읽을 때 이 배경이 상당 부분을 설명한다는 점은 적어 둡니다.

2. 옹호#

2-1. “현장은 장례식이 아니었다”#

가장 많은 추천을 받은 옹호 댓글은 HN 영상 스레드의 robbyrussell 이 썼습니다. oh-my-zsh⁷ 의 원작자이고 Rails 에이전시 Planet Argon 의 CEO 로, 현장에 있었습니다.

“현장의 분위기는 파멸과 우울과는 거리가 멀었다. 우리 대부분은 처음부터 설계하는 사람이 아니라 물려받은 시스템을 고치는 사람 (menders) 이다. 새 도구는 물려받은 오래된 결정을 다시 들여다볼 기회를 준다. Ruby 여 영원하라, Rails 여 영원하라.”

andrewmutz 는 키노트가 “Rails 는 죽었다” 는 말이 아니라고 정리합니다. 에이전트 이전에 HEY 는 네이티브 팀 여섯 개를 감당할 수 없었고, 지금은 해고 없이 그것을 하고 있으며, 이것은 “당신의 팀이 훨씬 더 많은 것을 할 수 있다” 는 뜻이라는 것입니다. 그는 rubyonrails.org/ai 의 벤치마크를 근거로 Rails 가 에이전트 개발에 최적화되어 있다고도 주장합니다.

MattyMc 는 DHH 가 이튿날 “새 앱을 지금 만든다면 Rails 로 만들겠다” 고 정정했으며, 다만 인기가 그것을 요구하면 Rust 로 다시 쓰겠다고 덧붙였다고 전했습니다. 이 발언의 1차 출처는 확인하지 못했으므로 전언으로만 적습니다.

2-2. 경제 논리는 맞다#

Anton Zolotov 는 키노트의 여섯 가지 요지를 정리하며 대체로 동의합니다. 그가 특히 공감한 것은 맞춤 소프트웨어의 경제학 입니다. 개발 비용이 내려가면 사소한 불편도 개인 소프트웨어로 해결할 가치가 생기고, SaaS 만이 답이던 시대가 끝난다는 것입니다. 그 자신도 SaaS 가 맞지 않아 회계와 할 일 관리 도구를 직접 만들었다고 씁니다. Bring Your Own Agent 에도 동의합니다.

Ruby Flow 를 통해 daily.dev 에 실린 한 베테랑 프로그래머의 글은 DHH 의 사진 비유를 자기 경력으로 받습니다. APL 부터 시작해 여러 언어 전환을 겪었고, 취미인 사진에서 필름, 디지털, 컴퓨테이셔널 사진으로의 이행을 직접 지났으며, 매번 기계적 작업에서 풀려나 더 높은 수준의 창의적·구조적 관심사로 옮겨 갔다는 것입니다. 다만 이 글도 Basecamp 5 의 소유권 문제와 Raspberry Pi 수치의 한계는 인정합니다.

HN 에서는 경제학 논거가 오갔습니다. conductr 는 엘리베이터 운전사가 자동화로 사라진 것이 받아들여진 진보였듯 직업의 진화는 불가피하다고 했고, aogaili 는 제번스 역설⁸ 을 들어 생산성 향상이 새로운 소프트웨어 시장 층을 만들고 1인 개발자가 에이전시 규모의 일을 하게 되어 총 기회가 늘어난다고 주장했습니다. 이에 pjmlp 는 특정 소프트웨어에 대한 세계 수요는 유한하므로 생산성이 고용을 비례해서 늘리지는 않는다고 반박했습니다.

비용 논쟁에서도 옹호가 있었습니다. sroerick 은 연봉 5만 5천 달러에 월 200달러를 오픈소스 모델에 쓰는데 “정말 재미있다” 고 썼고, 한 주에 15억 토큰을 썼다고 밝혔습니다. geraldwhen 은 프리미엄 모델이 “수입의 최소 10% 가치가 있다” 고 했고, julianeon 과 marcus_holmes 는 더 싼 모델로도 큰 차이 없이 쓸 수 있으므로 비용 우려는 과장이라고 했습니다.

2-3. 한국 반응 중의 옹호#

GeekNews 댓글 중에는 옹호도 있었습니다. 한 댓글은 “p(bloom) 에 대한 두려움” 속에 사는 것보다 낙관적 가능성을 좇는 쪽을 택하겠다며 “미래가 좋아진다면 미리 비관한 시간이 아깝다” 고 썼습니다. 다른 댓글은 초상화에서 사진으로의 전환이라는 비유와 미술사 활용을 두고 “기조연설이 무척 좋았다” 고 평했습니다. 2025년 11월 24일을 사진의 Brownie 순간에 비긴 대목이 설득력 있었다는 댓글도 있었습니다.

3. 제3의 길#

옹호도 반박도 아닌, 키노트의 전제 일부를 받아들이면서 다른 결론을 내는 글들이 있습니다. 개인적으로는 이 갈래가 가장 읽을 만했습니다.

3-1. Sam Ruby: “연필은 내려놓되, 표기법은 올려라”#

Sam Ruby 는 Apache 소프트웨어 재단 회장을 지냈고 『Agile Web Development with Rails』 의 공저자이기도 한 사람입니다. 그의 글 “Pencils Down, Notation Up” (9월 25일) 은 LLM 이 변혁적이라는 데 동의하면서 DHH 의 “선택지는 하나뿐” 이라는 주장에 반대합니다.

DHH 는 에이전트라는 “드릴 비트” 가 추상화 층을 뚫고 “컴퓨팅의 암반” 까지 내려간다는 이미지를 썼습니다. Sam Ruby 는 그 이미지를 받아들인 뒤 묻습니다. 맨 위에는 무엇이 남는가. 그는 Basecamp 의 Campfire 를 손대지 않고 그대로 C 로 컴파일해 20만 2천 줄짜리 C 파일을 만들어 보였습니다. 그리고 묻습니다. 에이전트가 고치기에 더 나은 것은 Rails 앱인가, 생성된 C 인가.

그가 제시하는 소스의 다섯 가지 조건은 이렇습니다.

“그러면 프롬프트를 유지하면 되지 않느냐” 는 뻔한 반론에는 이렇게 답합니다. “그 정도로 정밀한 프롬프트는 프로그램이다.” 그리고 그런 명세 언어는 이미 있습니다. 수십 년 다듬어졌고 모든 LLM 이 알고 있는 Rails 의 문법입니다.

성능 주장에도 대답합니다. 컴파일한 Rails 가 처리량 85~140배, 메모리 96% 감소를 보였다는 자체 벤치마크를 제시하며, 오버헤드의 대부분은 Ruby 자체가 아니라 연관과 라우트에 대한 런타임 결정 에서 온다고 설명합니다. 결론은 “notation up” 입니다. Rails 를 형식 명세 층으로 유지하고, 어떤 타깃으로든 컴파일하라는 것입니다.

3-2. 언어와 아키텍처를 분리해서 보라#

LaunchKit 은 이틀에 걸쳐 두 편을 냈습니다. 첫 편은 자신들이 영상을 보지 못했고 전사본도 없었다고 명시한 채 보도된 내용만으로 정리한 글이고, 둘째 편 “Rails vs Rust in 2026” 은 HEY 의 발표가 언어 교체와 아키텍처 교체를 한데 섞었다 는 점을 분리합니다.

그들이 짚는 HEY 의 특수성은 이렇습니다. 37signals 는 이미 AWS (연 320만 달러 이상) 를 떠나 자체 하드웨어로 옮긴 회사이고, Raspberry Pi 수치는 Rust 백엔드와 네이티브 클라이언트가 HTML 렌더링을 대체한 효과의 합입니다. 컴파일 언어 백엔드가 정당화되는 워크로드는 네 가지 (지속적 CPU 작업, 메모리 제약 하의 대량 연결, 한 자릿수 밀리초 지연, 다른 기계로 배포하는 바이너리) 이며, 소규모 팀의 CRUD 제품에서 병목은 대개 인터프리터가 아니라 DB 쿼리, 외부 API, 브라우저 렌더링입니다. 결론은 “2026년에도 한두 명이 DB 기반 CRUD 제품을 만든다면 Rails 가 답” 입니다. 관례가 에이전트의 추측을 없애 주기 때문입니다.

Rustify 의 Max Wells 는 Rust 진영에서 비슷한 절제를 보였습니다. HEY 수치는 검증되지 않았고 모든 Rust 프로젝트로 일반화하면 안 되며, 병목이 “타이핑” 에서 “에이전트 지휘” 로 옮겨 갔을 뿐 프로그래밍이 끝난 것은 아니라는 것입니다. 에이전트 출력을 평가하려면 Rust 를 아는 것이 여전히 가치 있다고 덧붙입니다. byteiota 는 1,000배는 DHH 개인의 고점이고 대부분의 개발자에게 현실적인 배수는 2~10배이며, 기업의 진짜 병목은 코드 생성 속도가 아니라 승인 계층과 의사결정 구조 라고 썼습니다.

솔로 개발자의 시선도 있습니다. Pagecord 를 혼자 만드는 Olly 는 “우리가 알던 Rails World 의 끝 (그리고 나는 괜찮다)” 이라는 글에서, 프로그래머의 행복을 위해 설계된 프레임워크는 프로그래머가 코드를 쓰지 않는 세상에서 존재 이유를 잃는다는 DHH 의 논리를 받아들입니다. 20년의 애착 때문에 “조금 우울하다” 면서도, 자기 제품은 계속 Rails 로 만들 것이고 에이전트 개발의 이점은 부정할 수 없다고 씁니다.

3-3. Aaron Patterson 의 폐막 키노트: “타라, 패배자야. 프로그래밍하러 간다”#

이틀 뒤인 9월 24일 오후, Rails World 는 언제나처럼 Aaron Patterson (tenderlove) 의 폐막 키노트로 닫혔습니다. Shopify 의 Senior Staff Engineer 이자 Ruby 와 Rails 양쪽의 코어 멤버입니다. Global Nerdy 는 이 키노트를 “시체를 되살린 아일랜드식 밤샘 장례”⁹ 라고 불렀습니다. 아래는 그 요약을 경유한 내용이며, 영상은 공식 채널에 올라와 있습니다.

그는 DHH 의 설치 시간 집착을 놀리는 것으로 시작했습니다. 100밀리초에 설치되는 가상의 배포판 “Aaron XP” 입니다. 그 다음 청중에게 물었습니다. 사람이 몇 시간을 들여 리뷰해야 하는 2,000줄짜리 AI 생성 PR, 그가 “슬롭 수류탄 (slop grenades)” 이라 부른 것을 받는 것을 즐기는 사람이 있는지. 손을 든 사람은 두세 명이었습니다. DHH 의 “손코딩하는 사람 다섯 명” 거수에 대한 답가였습니다.

기술 내용은 Ruby 그 자체였습니다. Ruby 4.1 의 Ractor¹⁰ 별 가비지 컬렉션, 할당을 70% 줄이는 인터프리터 인라이닝, 1,000번 할당하는 루프를 8번으로 줄이는 ZJIT¹¹ 의 고수준 중간 표현. 그리고 컴파일러 이론의 “as-if 규칙”¹² 을 꺼냈습니다. 컴파일러는 관찰 가능한 동작을 보존하는 한에서만 변환한다는 프로그래머와의 계약입니다.

“당신의 AI 는 당신에게 이 약속을 하지 않았습니다. 당신의 영어에는 as-if 규칙이 없습니다. 나는 내 운명을 AI 에 양도하지 않을 겁니다. 나는 계속 내 코드를 읽을 것이고, 여러분도 그러길 바랍니다.”

보안 사례도 하나 공개했습니다. 2026년 5월 RubyGems 를 노린 공격에서 AI 구동 봇이 RubyGems 웹훅에서 rubydoc.info, YARD 설정을 거쳐 악성 스크립트에 이르는 제로데이 연쇄를 스스로 찾아냈고, 자격 증명을 폐기하자 캐시된 HTTP 취약점으로 우회했다는 것입니다.¹³ DHH 가 “보안은 진짜 문제” 라고 한 줄로 넘긴 자리에 구체적 사례를 놓은 셈입니다.

그는 Mike Dalessio 의 Rails Core 합류를 축하하며 개인의 자아보다 유지보수자의 기여를 강조했고, 영화 Mean Girls 의 대사를 비틀어 끝냈습니다.¹⁴ “타라, 패배자야. 우리 프로그래밍하러 간다.” DHH 의 “패배자가 되지 마라” 에 대한 답이었습니다.

Global Nerdy 는 두 키노트를 표로 대비했습니다. 톤은 “공격적, 메시아적” 대 “따뜻하고 자기 비하적”, 코드에 대한 입장은 “손코딩은 실패 상태” 대 “계속 코드를 읽어라”, 기술적 베팅은 “네이티브 앱과 블랙박스 Rust” 대 “Ractor 와 ZJIT 라는 Ruby 심층 투자”. 참석자들의 초기 반응은 “드디어 Rails 이야기를 들었다” 는 안도였다고 합니다.

4. 정리: 세 개의 질문이 하나로 뭉쳐 있었다#

반응 전체를 읽고 나면, 이 키노트가 서로 다른 세 질문을 하나의 연설로 묶었기 때문에 반응도 뒤엉켰다는 것이 보입니다.

첫째, 에이전트가 이제 코드의 대부분을 쓰는가. 놀랍게도 이 명제는 비판자들도 대체로 받아들였습니다. Jared Norman 도 Jared Smith 도 Sam Ruby 도 이것을 부정하지 않습니다. 손을 든 다섯 명이 그 증거입니다. 논쟁은 “그래서 무엇이 달라지는가” 에 있었지 “정말 그런가” 에 있지 않았습니다.

둘째, Rails 는 어디로 가는가. 이것이 진짜 불만이었고, 키노트는 답하지 않았습니다. 옹호자들의 “Rails 는 여전히 웹에 좋다” 는 재확인은 비판자들이 원한 것이 아니었습니다. 그들이 원한 것은 프레임워크 리더의 로드맵이었습니다. Aaron Patterson 의 폐막 키노트가 안도를 준 이유는 그것이 정확히 Ruby 의 로드맵이었기 때문입니다.

셋째, 코드를 읽지 않는 시스템의 책임은 누가 지는가. Jared Smith 의 소유권 논증과 Aaron Patterson 의 as-if 규칙은 같은 곳을 가리킵니다. 더 나은 모델은 국소적 정확성을 올리지만 시스템 전체를 이해하는 사람을 만들어 주지 않습니다. DHH 는 이 질문에 “5분만 더 기다렸으면 Fable 이 왔을 것” 으로 답했고, 그 답이 충분하다고 본 사람은 많지 않았습니다.

여기에 네 번째로 톤 이 있었습니다. 같은 내용을 “여러분은 최고이니 두려워하지 마세요” 로 끝냈어도 비판은 있었겠지만, “패배자” 라는 단어가 반응의 온도를 바꾸었습니다.

Rails 를 쓰지 않는 독자에게 남는 것을 추리면 이렇습니다.

• CLI 요구는 프레임워크와 무관하게 실행 가능합니다. 비판자 중에도 이 요구에 반대한 사람은 거의 없었고, Jared Smith 는 스코프 제한 토큰, 읽기 전용 기본값, 에이전트 명령 로깅 같은 안전장치 목록까지 덧붙였습니다.
• 무대의 숫자는 그대로 인용하지 않는 것이 좋습니다. Part 1 의 검증 표대로 자기 보고 수치는 검증할 수 없고, 역사적 유비의 숫자는 틀렸습니다.
• 언어 선택과 아키텍처 선택을 분리해서 읽어야 합니다. HEY 의 99% 는 Rust 의 성적표가 아니라 서버 렌더링을 버린 아키텍처의 성적표입니다.
• Sam Ruby 의 질문은 모든 프레임워크에 적용됩니다. 에이전트가 고칠 소스의 맨 위에 무엇을 둘 것인가. 그 답이 “프롬프트” 라면, 그 프롬프트는 이미 프로그램입니다.

DHH 는 키노트 몇 시간 전 X 에 “이번 연설은 깃털을 좀 흐트러뜨릴 수 있지만, 그냥 말해야 하는 것이기도 하다” 고 썼습니다. 깃털은 흐트러졌습니다. 다만 그 뒤에 나온 글 중 가장 좋은 것들은 그의 연설에 반대하기 위해서가 아니라, 그가 비워 둔 자리를 채우기 위해 쓰였습니다.

References#

반응: 비판 (2026)#

• Jared Norman, What About Rails? (2026-09-24) — HN 스레드
• Joey deVilla, DHH’s keynote at Rails World 2026: “The most confusing funeral I’ve ever experienced”, Global Nerdy (2026-09-27)
• heise online, Rust instead of Ruby – Rails founder Hansson’s new project (2026-09-26)
• Ruby Users Forum, Rails World 2026 Opening Keynote - DHH (2026-09)
• Hacker News, Rails World 2026 Opening Keynote [video] (2026-09) — 본문에 인용한 댓글은 2026-09-28 기준

반응: 옹호 (2026)#

• Anton Zolotov, Takeaways from DHH’s Rails World 2026 Keynote (2026-09-24)
• Ruby Flow via daily.dev, Pencils Down: My Take on DHH’s Rails World 2026 Keynote (2026-09-27)
• GeekNews, Rails World 2026 개막 기조연설 [영상] (2026-09) — 댓글 인용

반응: 제3의 길 (2026)#

• Sam Ruby, Pencils Down, Notation Up (2026-09-25)
• Jared Smith, DHH’s Rails World 2026 Keynote: Pencils Down, Now What (2026-09-24)
• LaunchKit, Pencils down: what DHH actually said at Rails World 2026 (2026-09-24)
• LaunchKit, Rails vs Rust in 2026, after HEY moved its backend (2026-09-24)
• Max Wells, Rails World 2026 Keynote: DHH, HEY, Rust, and AI Coding Agents, Rustify (2026-09)
• byteiota, DHH Says Pencils Down: End of Hand-Written Code (2026-09)
• Olly, It’s the end of Rails World as we know it (and I feel fine) (2026-09-24)
• Ruby on Rails, Rails World 2026 Closing Keynote - Aaron Patterson (2026-09)
• Joey deVilla, Aaron Patterson’s closing keynote (and antidote to the DHH funeral) at Rails World 2026, Global Nerdy (2026-09-28)

배경 (2025~2026)#

• Mosscap, Home — Rails 포크의 목표와 이유
• Lucas Dohmen, Rails is done (2026-08-09)
• heise online, Who owns an open source project? – RubyGems threatens to split (2025-09)
• The Register, Open source to closed doors: RubyGems control fight erupts (2025-09-25)
• Joel Drapper, Shopify, pulling strings at Ruby Central, forces Bundler and RubyGems takeover (2025-09)
• Ruby on Rails, See you at the last RailsConf (2025-05-29)
• Ruby on Rails, Rails and AI — Agents on Rails 벤치마크 결과 (2026-09)