DEV Community: Jeong-seok Oh

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

Jeong-seok Oh — Sat, 03 Oct 2026 13:30:07 +0000

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 채널)의 썸네일이다.

코드 리뷰의 종말? 에이전트 시대에 PR을 읽지 말아야 하는 이유

Jeong-seok Oh — Sat, 03 Oct 2026 11:48:20 +0000

출처: Laurie Voss(Arize AI DevRel 총괄, npm 공동 창업자)의 AI Engineer World's Fair 2026 발표 "The Death of the Code Review" — 원본 영상 https://youtu.be/_mi3alkqy4s

에이전트가 만든 diff를 끝까지 읽지도 않고 머지 버튼을 누르면서 찜찜했던 적이 있다면, 이 발표를 한번 볼 만하다. 발표자 본인도 청중 대부분이 그러고 있다고 말한다. 그리고 이 문제를 숫자로 보여 주면서, 해법이 "더 꼼꼼히 읽기"는 아니라고 한다.

코드는 741% 늘었는데 출시는 30%만 늘었다

경제학자 세 명이 GitHub 개발자 10만 명 이상을 추적했다. 자율 에이전트를 켠 사람들은 코드를 741% 더 썼고, 실제로 출시된 소프트웨어는 30% 늘었다. 연구진은 리뷰를 원인으로 꼽는다. 프로덕션으로 가는 길이 여전히 사람을 거치고, 그중에서도 코드 리뷰가 하류 전체를 막고 있다는 것이다.

코드를 만드는 건 이제 싸다. 그 코드를 믿어도 되는지 확인하는 건 여전히 비싸다. 발표자는 Stripe가 5천만 줄짜리 Ruby 코드베이스를 하루 만에 옮긴 일, Bun이 100만 줄 넘는 Zig를 6일 만에 Rust로 바꾼 일을 예로 든다.

더 열심히 읽는다고 해결되지 않는다

"그럼 리뷰를 더 빡세게 하면 되지 않나?" 발표자는 20년 전 Cisco 연구를 꺼낸다. 리뷰 2,500건을 분석했더니, 한 번에 400줄쯤 넘게 읽거나 시간당 450줄보다 빨리 읽으면 결함을 제대로 못 잡았다. 이 속도로 계산하면 에이전트 하나가 만든 1만 줄짜리 PR을 사람이 검토하는 데 사나흘이 걸린다. 요즘은 한 사람이 에이전트를 열두 개씩 돌릴 수 있다. 발표자는 그런 사람은 좀 의심스럽다고 농담하지만, 어쨌든 계산이 안 맞는다. 리뷰만 맡은 사람은 지루해서 금방 지치기도 한다.

테스트를 통과했다고 머지해도 되는 건 아니다

사람이 못 읽으면 테스트에 맡기면 될까. METR이 해 본 결과는 그렇지 않았다. SWE-bench 채점을 통과한 PR을 실제 오픈소스 메인테이너들에게 보여 줬더니, 머지해도 된다고 본 건 절반쯤이었다. 탈락 이유는 정확성이 아니라 코드 품질과, 테스트 바깥의 코드를 조용히 깨뜨리는 변경이었다.

Cognition의 FrontierCode도 같은 얘기를 한다. 동작 정확성, 회귀, 안전성, 범위 규율, 테스트 품질, 유지보수성처럼 리뷰어가 실제로 보는 기준으로 채점했더니, SWE-bench Pro에서 88%를 받은 모델이 가장 어려운 구간에서는 29%였다.

가장 극적인 건 Bun이다. 기존 테스트의 99.8%를 통과했으니 테스트는 제 할 일을 했다. 그런데 이식된 코드에 unsafe 블록이 13,044개 있었다. 비슷한 규모로 사람이 쓴 프로젝트는 73개쯤이라고 한다. unsafe는 메모리를 제대로 다룬다는 걸 증명하지 않고 작성자가 "맞다"고 주장하는 자리다. 테스트는 공개 인터페이스의 동작만 보증하니까, 애초에 확인하도록 설계되지 않은 1만 3천 개의 주장이 검증 없이 남은 셈이다. 여담으로, Zig 코드를 한꺼번에 지우는 PR은 다른 봇이 AI 슬롭이라며 표시했다고 한다.

자동 리뷰어는 이미 돌고 있고, 잘 속는다

발표에 따르면 GitHub Copilot 리뷰어는 GitHub 전체 코드 리뷰의 5건 중 1건 넘게 맡고 있고, CodeRabbit은 PR 1,300만 건 이상을 검토했다. Cursor가 공개한 리뷰어 구조에서는 배울 점이 두 가지 있다.

하나는 오탐이다. 멀쩡한 코드를 나쁘다고 하는 리뷰어는 곧 무시당한다. 그래서 Cursor의 첫 버전은 diff 하나를 여덟 번 리뷰하면서 매번 순서를 섞었다. 순서에 따라 결과가 달라졌기 때문이다. 베이징대 연구진도 같은 발상으로 여러 번 돌려서 의견이 겹치는 지적만 남겼고, 리뷰 품질이 최대 44% 올랐다고 한다.

다른 하나는 모델에게 의심하라고 직접 말해야 했다는 점이다. Cursor가 리뷰어를 다시 만들 때, 모델은 "괜찮아 보이니 그냥 내보내자" 쪽으로 기울었다고 한다. 사람 리뷰어와 똑같다. 그래서 코드를 기본적으로 믿지 말고 뭔가 잘못됐다고 가정하라는 취지로 지시해야 했다는 게 발표자의 전언이다.

약점도 분명하다. 무해해 보이는 커밋 메시지로 포장한 취약한 코드가 자율 리뷰 에이전트를 88% 속였고, 같은 시도가 사람 리뷰어에게는 35%만 통했다는 연구가 소개된다. 자신 있게 포장된 나쁜 코드는 에이전트가 제일 잘 만드는 코드이기도 하다. 게다가 이 리뷰어들의 성공 지표는 전부 "사람이 내 지적을 받아들였나"다. 코드도 리뷰도 자동인데, 그 리뷰를 다시 사람이 보는 구조인 셈이다.

사람을 뺀 사례를 뜯어 보면

OpenAI는 엔지니어 3명이 직접 코드를 쓰지 않고 약 100만 줄짜리 내부 제품을 만들었다고 공개했다. Anthropic의 Nicholas Carlini는 에이전트 16개로 Rust C 컴파일러를 밑바닥부터 만들어, 약 2,000개 세션에 걸쳐 Linux 커널을 컴파일하게 했다.

그런데 자세히 보면 리뷰는 사라지지 않았다. OpenAI는 에이전트가 다른 에이전트의 리뷰를 다시 리뷰하게 했고, 한동안은 매주 금요일마다 사람이 AI 슬롭을 손으로 치웠다. 감당이 안 되자 슬롭을 찾는 에이전트를 따로 학습시켰다. Carlini 쪽은 코드를 승인한 사람이 없었지만, 정답을 확인하는 테스트 하네스와 피드백 시스템은 전부 사람이 만들었다. 발표자 표현으로는 사람이 루프 "안"에는 없어도 루프 "위"에는 있었다. 리뷰가 없어진 게 아니라 사람이 만든 시스템 쪽으로 옮겨 간 것이다.

반대 증언도 있다. Dexter Horthy는 6개월 동안 코드를 리뷰하지 말라고 하고 다니다가 올해 3월 무대에서 말을 거뒀다. 실제 시스템에서 해 보니 큰 부분을 뜯어내고 다시 만들어야 했다고 한다. 투자자 Sarah Guo는 이유를 이렇게 설명한다. 테스트 통과는 그 변경이 옳은 변경인지, 이 모듈에 기대는 외부 사용자나 주인 모를 크론 잡이 있는지 알려 주지 않는다.

그래서 뭘 하라는 건가

발표자의 결론은 PR 리뷰를 그만하라는 것이다. 2026년에 PR을 리뷰하는 건 맞는 추상화 수준이 아니라고 한다. 사람이 빠지라는 얘기는 아니다. 사람의 판단을 한 층 위, 즉 리뷰 시스템을 만들고 조율하는 쪽에 쓰라는 얘기다. 발표 내용을 실무 항목으로 옮기면 이렇다.

에이전트가 올린 PR 중 400줄 넘는 게 얼마나 되는지, 리뷰에 시간이 얼마나 걸리는지부터 재 본다.
자동 리뷰어를 쓴다면 오탐부터 잡는다. 여러 번 돌려서 겹치는 지적만 남기고, 프롬프트에 "기본은 의심"을 넣는다.
테스트 통과만으로 머지하지 않는다. unsafe 같은 증명 없는 주장, 외부 의존성, 크론 잡처럼 테스트가 못 보는 영역은 규칙과 eval로 따로 적어 둔다.
리뷰어를 직접 속여 본다. 무해해 보이는 커밋 메시지나 프롬프트 인젝션에 넘어가는지 정기적으로 시험하고, 그 리뷰 시스템을 누가 책임지는지 정해 둔다.
정확성을 싸게 확인할 수 없는 곳, 영향 범위가 큰 곳, 보안에 민감한 곳, 누군가 이름을 걸어야 하는 곳에는 사람 체크포인트를 남긴다.
배포한 뒤에는 트레이스와 로그를 마지막 리뷰어로 둔다.

발표는 이런 말로 끝난다. 앞으로 잘하는 팀은 코드를 제일 많이 만드는 팀이 아니라, 자기가 출시한 걸 왜 믿는지 증거로 말할 수 있는 팀이라는 것이다. PR을 읽는 시간 대신 "좋은 코드"의 기준과 회사 맥락, 도메인 지식을 리뷰 하네스에 코드화하는 데 시간을 쓰라는 게 발표자의 권고다.

이 글은 Laurie Voss의 발표 내용을 정리하고 풀어 쓴 것이다. 인용된 수치와 사례는 발표자의 주장이며, 원 연구와는 대조하지 않았다.