跳到正文
原文
Google AI:DEV 作者专属(RSS)· Jeong-seok Oh·· 3 小时前AI 评分59

DHH 在 Rails World 2026 宣布停止手写代码,作者逐条核对演讲中的数字与漏洞

DHH의 손코딩 중단 선언, Rails World 2026 키노트의 숫자와 빈틈

AI 导读

DHH 在 Rails World 2026 主题演讲中宣布手写代码时代结束:37signals 已把手写代码移出正常业务(保留例外流程),他本人自称 5 个月没写代码、已从专业程序员退休,起点是 2025 年 11 月 24 日 Opus 4.5 发布。

正文

Rails World 2026 개막 무대에서 DHH가 손으로 코드 짜는 시대는 끝났다고 말했다. 한 시간 넘는 영어 키노트를 보고, 한국어로 풀어 준 AgentOS의 해설 영상도 이어서 봤다. 보는 내내 걸린 건 하나였다. 이 말을 어디까지 사실로 받고, 어디부터는 이 사람의 기질로 받아야 할까.

무슨 말을 했나

37signals는 키노트 몇 주 전에 손코딩을 정상 업무에서 뺐다. 금지는 아니다. 예외로 돌렸다. 사람이 직접 코드를 고쳐야 하는 순간은 Sentry에 버그가 찍힌 것과 같은 취급이고, 그때 할 일은 몇 줄 고친 뒤 왜 에이전트가 원하는 걸 못 만들었는지 따져서 코드를 만드는 공장 쪽을 고치는 것이다. 회사 결정과 별개로 DHH 본인은 5개월째 코드를 안 쓰고 있다고 했고, 스스로 전문 프로그래머에서 은퇴했다고 말했다. 은퇴 시점은 3월께라고 했는데, 자동자막으로 들은 거라 날짜까지 단정하진 않겠다.

출발점으로 삼은 건 2025년 11월 24일, Opus 4.5가 나온 날이다. 그는 이 날을 1900년에 1달러로 나온 코닥 브라우니에 빗댔다. 사진이 싸지자 초상화가들이 사실 묘사를 내려놓고 입체파와 인상주의로 갔다는 이야기인데, 그 화가 중 한 명인 라우리츠 툭센이 DHH의 고조부라는 대목에선 좀 반칙이다 싶었다. 2~5월에 환멸의 골짜기를 지나고, 6월 Fable 5부터는 에이전트에게 시켜 보는 수준을 넘어 결과물을 그냥 머지하고 싶어졌다고 한다.

그리고 HEY. 웹앱을 접고 네이티브 앱 6종으로 가며, 무대에선 약 한 주 전에 킥오프했다는 앱들을 띄웠다. 백엔드는 러스트로 다시 짠다. 그가 가장 뜻밖의 발견이라며 꺼낸 말은 이거였다. "English is a better programming language than Ruby." 루비를 그렇게 아끼던 사람이.

줄 수 비교는 반만 믿는다

먼저 짚어 둘 것. 아래 숫자는 전부 DHH 본인 슬라이드, 본인 커밋 기록에서 나온 자기 보고다. 밖에서 검증된 값은 아니다.

에이전트 이전 21년 동안 64만 7천 줄, 이후 20개월 동안 32만 1천 줄. 2026년 8월 한 달에만 약 15만 줄을 썼는데, 지난 21년의 연평균(약 3만 1천 줄)을 한 달 만에 넘긴 셈이고 월평균으로는 60배쯤이다.

줄 수 자체는 별로 믿지 않는다. 줄 수가 생산성 지표로 나쁘다는 건 오래된 얘기고, 여기선 사정이 더 나쁘다. 8월 분량 대부분이 장황한 러스트이고 DHH가 그걸 읽지 않는다는 걸 본인이 먼저 인정했다. 아무도 읽지 않는 코드의 줄 수는 성과일 수도 있지만 그냥 유지보수해야 할 표면적일 수도 있다. 슬라이드만 봐서는 어느 쪽인지 모른다.

오히려 같은 슬라이드의 언어 구성 쪽이 오래 남았다. 21년 동안 루비가 55%였는데 최근 20개월은 3%이고, 매일 쓰는 언어가 12개가 됐다. 그는 C++도 Qt도 모르는 상태에서 Omarchy용 계산기를 프롬프트 7분 만에 만들었다고 했다. 나한테는 이게 줄 수보다 훨씬 설득력이 있었다. 한 사람이 손댈 수 있는 범위가 넓어졌다는 증거니까. 다만 그 뒤에 나오는 "도구 쓰는 최선과 안 쓰는 최악은 100배, 어쩌면 1,000배"라는 말은 DHH 자신도 그럴듯하게 들린다는 정도로만 말했다. 나도 딱 그 정도로 들었다.

읽지 않는 러스트, 누구에게 통하나

DHH는 러스트를 대놓고 싫어한다. 사람이 쓰기엔 비인간적인 언어라고. 근데 읽을 필요가 없다면 빠르고 가벼운 러스트는 완벽하다는 게 그의 논리다. 내가 시키고, 에이전트가 쓰고, 나는 안 읽는다. HEY의 메일 서버를 러스트로 옮기면 CPU 99%, 메모리 95%가 줄고 피크 트래픽도 라즈베리 파이 한 대로 버틸 수 있을 거라고 했는데, 해설 영상이 짚었듯 이건 그가 대략 계산해 본 추정치다.

품질은 블랙박스로, 밖에서 평가한다. 개발팀을 고용한 사업주가 결과물을 평가하는 방식과 같다는 비유를 들었다.

이 비유에서 걸렸다. 그 사업주가 고용한 팀은 자기 코드를 읽는다. 장애가 나면 새벽에 그 코드를 열어 볼 사람이 어딘가 있다. DHH의 구도에는 그 사람이 없다. 37signals처럼 작은 팀이고, 결정하는 사람이 CTO이자 공동 소유자이고, 잘못 판단한 비용도 같은 사람이 지는 조직이라면 이 방식이 성립할 수 있겠다고 생각한다. 수백 명이 한 코드베이스를 나눠 갖고 감사나 규제를 받는 조직에서 "아무도 안 읽지만 바깥에서 재 보니 괜찮다"가 통할지는 모르겠다. 블랙박스 평가는 결국 바깥의 테스트와 관측이 얼마나 촘촘한지에 전부 걸리는데, 그 평가 장치는 누가 만들고 누가 읽는지까지는, 적어도 내가 정리한 범위에선 키노트가 다루지 않았다.

Basecamp 5 일화도 같은 맥락에서 읽혔다. 봄에 디자이너들에게 마지막 기능을 바이브 코딩하게 했더니 PR 하나하나는 괜찮았는데 20~30개가 합쳐지자 아키텍처가 스위스 치즈가 됐고, 그래서 수동 리뷰로 돌아갔다고 한다. DHH는 그 결론이 틀렸다고, 조금만 기다렸으면 됐을 거라고 말한다. 그사이 Fable이 나왔으니까. 근데 같은 작업을 Fable로 다시 돌려 봤다는 얘기는 적어도 내 노트엔 없다. 그러면 이건 다음 모델이 고쳐 줬을 거라는, 언제든 할 수 있는 말에 가까워진다. 그래도 자기에게 불리한 일화를 숨기지 않고 꺼냈다는 점은 인정하고 싶다.

DRY를 다시 따지자는 대목

키노트에서 가장 오래 생각한 부분이다. 레일즈는 DRY를 앞세워 온 프레임워크인데, 그 창시자가 추상화를 다시 따지자고 나섰다. 해설 영상에 따르면 이 대목 슬라이드 제목이 다익스트라의 유명한 글 제목을 빌린 "추상화는 해롭다"였다고 하는데, 원본 쪽 노트에선 그 제목을 따로 확인하지 못했다. 근거는 단순하다. 에이전트 시대에는 같은 코드를 반복하는 비용도, 여러 사본을 맞춰 두는 비용도 0에 가까워진다. 원본 키노트 표현으로는 수백에서 수만 개의 프로세스가 동시에 코드를 고치는 환경이라면 한 곳에 모아 둔 추상화가 오히려 병목이 된다.

이 주장을 따라가 보면 추상화를 하던 이유 상당수가 사람 머리 때문이었다는 게 드러난다. 한 곳만 고치면 되게 하려고, 이름을 붙여 기억하려고. 읽는 사람이 없어지면 그 이유도 같이 빠진다. 근데 이건 앞의 러스트 블랙박스와 상당 부분 같은 전제에 기댄다. 사람이 코드를 읽지 않는다는 전제. DHH가 직접 그렇게 묶어 말한 건 아니고 내 읽기다. 동시 수정 때문에 추상화가 병목이 된다는 논리는 그 전제 없이도 설 수 있으니, 둘이 꼭 같이 무너지진 않을 수도 있다.

남는 의문도 있다. 추상화는 반복을 줄이는 도구이기도 하지만 규칙을 한 곳에 고정하는 장치이기도 하다. 메일 발송 로직 사본이 수십 개인데 그중 하나만 정책이 조용히 다르면, 동기화 비용이 0이라는 말은 에이전트가 모든 사본을 빠짐없이 안다는 가정이 된다. DHH도 아직 설계도는 없다고 했고, 방법론이나 사이클 길이까지 다시 봐야 한다고 했다(해설 영상은 여기에 37signals의 Shape Up을 예로 붙인다). 답은 없다. 이 대목에선 그게 차라리 나았다.

낙관을 게임이론으로 정당화할 때

발표 후반부는 우려에 대한 답이다. 보안 같은 현실적 위험은 대비해야 한다고 인정하면서도, 경제와 사회에 대한 예측은 늘 틀려 왔다고 말한다. ATM이 나오면 창구 직원이 사라진다던 걱정이 반대로 흘러간 사례, 원폭을 만든 오펜하이머도 그 뒤 세상을 맞히지 못했다는 사례를 든다. 그리고 게임이론으로 정리한다. 일이 잘 풀리면 비관하며 보낸 시간이 낭비이고, 최악이라면 마지막 날을 즐겁게 보내는 편이 낫다. 그러니 합리적인 수는 낙관 하나뿐이고, 블랙 필은 루저나 삼키는 거라고.

약한 고리는 두 군데로 보였다. 하나, 예측은 다 틀린다고 해 놓고 본인은 연말이면 거의 모든 영역에서 손코딩이 경제성을 잃는다고 예측한다. 같은 칼날이 그 예측에도 똑같이 닿는다. 둘, 그 게임이론은 개인이 어떤 기분으로 하루를 보낼지에 대한 논증이다. 조직이 보안에 얼마를 쓸지, 읽지 않는 코드를 어디까지 허용할지는 기분이 아니라 비용과 책임의 문제이고, 거기엔 이 논증이 아무 말도 해 주지 않는다. 차라리 "우려가 있으면 도구를 발명해 대응하면 된다, 우리에겐 그럴 힘이 있다"고 한 쪽이 더 실질적이었다. 낙관론은, 글쎄. 논증보다는 선언에 가깝다.

해설 영상은 마지막에 이건 한 사람의, 그것도 아주 낙관적인 사람의 전망이라고 선을 긋는다. 맞는 말이다. 그런데 해설자 말대로 얼마 전까지 프로그래밍을 포기하느니 은퇴하겠다던 사람이 이런 말을 한다는 것도 사실이고, 그 무게를 어떻게 달아야 할지는 솔직히 아직 정하지 못했다. 반년쯤 뒤에 이 키노트를 다시 보면 낡아 있는 게 그의 숫자일지 내 의문들일지.

원본 키노트: https://www.youtube.com/watch?v=vDjW_dRyKXY
해설 영상(AgentOS): https://youtu.be/SGNaTI8h26A

대문 이미지는 원본 키노트 영상(Ruby on Rails 채널)의 썸네일이다.

来源:Google AI:DEV 作者专属(RSS) · dev.to