DHH 에이전트 코딩 강연, 37signals가 손코딩을 멈춘 이유

Rails 창시자 DHH(David Heinemeier Hansson)가 컨퍼런스 기조 강연에서 밝힌 에이전트 코딩 관점을 발화 순서대로 옮겼습니다. 49분짜리 영상의 요지는 하나입니다. 37signals는 몇 주 전 손으로 코드 쓰는 일을 끝내기로 했고, DHH 본인은 지난 20개월 동안 이전 21년 치 코드의 절반만큼을 썼다는 것. 강연 끝의 가장 실용적인 요구인 "앱에 CLI를 달아라"를 실제로 어떻게 시작하는지는 글 뒤쪽에 편집자 정리로 덧붙였습니다.

영어 자동 자막을 기준으로 정리했고 화면은 대조하지 못했습니다. 강연 첫 2분 정도는 자막이 판독 불가 텍스트뿐이라 내용을 알 수 없고, 중간에도 자막이 비는 구간이 아홉 군데 있습니다. 영상 시연이나 박수로 추정되지만 확인하지 못했습니다. 강연 장소와 행사명도 발화에 없습니다.

이 강연은 절차가 아니라 관점을 말합니다. DHH는 자기가 쓰는 에이전트 도구 이름이나 프롬프트 문구를 말하지 않습니다. 그래서 강연 부분은 무엇을 주장했고 무엇을 하라고 했는지만 옮깁니다.

에이전트 코딩의 변곡점, 2025년 11월 24일

DHH는 2025년 11월 24일 Opus 4.5 출시를 "우리 시대의 Kodak Brownie(누구나 사진을 찍게 만든 코닥의 보급형 카메라)"라고 부릅니다. 감당할 수 있는 하네스(AI 모델을 감싸 도구 사용과 작업 흐름을 관리하는 실행 환경) 안에서 새로운 형태의 지능과 짝 프로그래밍을 처음 경험하게 한 사건이고, 에이전트 시대의 변곡점이었다는 겁니다.

그 뒤로 도구가 폭발했고, 같은 수준의 지능이 곧 오픈 웨이트(모델 가중치를 공개해 누구나 내려받아 돌릴 수 있는 모델)로도 나왔습니다. DHH는 Kimi K2.5를 fast 모드로 초당 200토큰으로 써 봤다고 합니다.

환멸의 골짜기, 그리고 Fable 5

2월부터 5월까지는 "환멸의 골짜기"였다는 것이 DHH의 회고입니다. 새 모델이 계속 나왔는데 뒷걸음질하는 것 같았고, Opus 4.6에 실망하는 반응이 있었고, OpenAI 신모델의 벤치마크가 부진해 주가와 평가가 떨어졌다는 이야기입니다. 이 시장 평가 부분은 DHH 개인의 발언이고 근거 자료는 제시되지 않았습니다.

6월에 Fable 5가 나오면서 환멸이 풀렸습니다(자막 뒷부분은 알아들을 수 없었습니다). 변화는 이렇게 요약됩니다. Opus 단계에서 이미 "머지하고 싶은 결과"가 나오기 시작했고(DHH는 이를 Opus의 계시라고 부릅니다), Fable 5부터는 문제나 아이디어만 주면 자기 지시 없이 구현된다는 것입니다.

생산성 격차, 100배는 논란거리가 아니다

DHH는 10x 프로그래머 논쟁(자막상 "45년간 논쟁", 앞뒤 맥락 일부 누락)이 끝났다고 봅니다. 도구 없는 최악의 프로그래머와 도구 쓰는 최고의 프로그래머 사이 100배 차이는 이제 논란거리가 아니고, 1,000배도 "그럴듯하다"는 의견입니다.

여기서 그 수치가 나옵니다. 지난 20개월에 이전 21년의 절반만큼 코드를 썼다. 다만 코드 줄 수는 "이상하고 흐릿한 척도"이고 Ruby 한 줄은 Rust나 C++ 한 줄보다 훨씬 가치가 크다고 스스로 덧붙입니다. 측정 방법이나 저장소는 말하지 않았습니다. 전부 DHH 주장이며 검증되지 않은 수치입니다.

2005년 브라질 발표 클립("Look at all the things I'm not doing")을 21년 만에 다시 틀고, 지금은 그때보다 훨씬 더 많은 코드를 "안 쓰고" 있다고 합니다. 약 5개월간 코드를 안 썼는데도 모든 꿈과 불만과 사소한 기능이 갑자기 손에 닿게 됐다는 표현을 씁니다.

37signals의 결정, 손코딩 연필을 내려놓다

몇 주 전 37signals는 일상 업무로서 손코딩을 끝내기로("pencils down") 했습니다. 손코딩은 이제 예외 상태입니다. Sentry(서비스 오류를 모아 보여 주는 모니터링 도구)에서 버그를 보는 것과 같은 일이라는 비유입니다. 에이전트가 원하는 걸 못 만들면 잠시 연필을 꺼내 쓰되, 그 뒤엔 "기계(공장)를 고친다", 즉 같은 실패가 반복되지 않게 에이전트 쪽 환경을 손봅니다.

DHH가 청중에게 물었습니다. 매주 상당량의 코드를 손으로 쓰는 사람? 약 5명이었습니다. 두세 달 전이었다면 이 질문 자체가 "나사 빠진 소리"로 들렸을 거라고 합니다.

실패담도 있습니다. 봄에 Basecamp 5를 마무리하면서 디자이너들에게 바이브 코딩(코드를 직접 읽지 않고 말로 지시해 AI가 만들게 하는 방식)을 시켰는데, 개별 PR(코드 변경 제안)은 괜찮았지만 20~30개를 합치니 아키텍처가 "스위스 치즈"처럼 구멍이 났습니다. 당시엔 "기술이 아직 아니다"라고 결론 냈는데, 그게 틀린 결론이었다고 DHH는 돌아봅니다. 몇 달만 기다렸으면 Fable로 해결됐을 거라는 겁니다.

지금 소프트웨어 개발에서 유일하게 진지한 질문은 "이 지능 폭발에서 최대치를 어떻게 끌어내느냐"이고, 나머지는 그 아래 순위라는 게 DHH 입장입니다.

Hey 신버전, 네이티브 앱 6개와 Rust 백엔드

이메일 앱 Hey가 웹 앱이었던 건 웹 앱이 되고 싶어서가 아니라, 소규모 팀이 생산적이려면 그래야 했기 때문이라는 설명입니다. 네이티브 앱 6개를 유지하는 건 "5분 전" 세계에선 터무니없는 일이었고, 그래서 React Native나 Hotwire Native 같은 도구가 있었다는 겁니다.

약 1주 전 시작한 네이티브 앱 6개의 데모를 뒤에 틀면서, "한 줄의 코드도 안 쓰고" 프롬프트만 많이 줬다고 합니다. Windows 앱은 첫 프롬프트 결과가 "출시 불가" 수준이었고, 20분 뒤 수정본이 왔습니다. 6개 앱의 대상 플랫폼 목록은 Windows 외에는 언급이 없습니다.

Rust를 두고 한 말이 재밌습니다. "지난 40년 중 가장 못생긴 언어"이고 사람이 쓰기엔 비인간적이지만, 직접 안 봐도 되고 30~100배 빠른 앱과 밀리초 미만으로 뜨는 실행 파일을 얻을 수 있다면 "I LOVE RUST"라고 합니다.

수치는 이렇습니다. 웹 렌더링을 없애고 Rust 메일 서버로 바꾸면 백엔드 CPU 99%, 메모리 95%를 줄일 수 있고, 호스트 10대가 필요한 건 중복성 때문일 뿐이며, Hey의 피크 트래픽을 Raspberry Pi 한 대로 처리할 수 있을 것이라는 추산입니다. DHH 스스로 "봉투 뒷면 계산"이라고 부르는 수치이고 측정 조건은 말하지 않았습니다.

에이전트와 일하는 방식은 비동기

DHH는 Basecamp 안의 에이전트에게 지시하는 방식을 시도 중입니다(에이전트 이름은 자막으로 알아들을 수 없었습니다). 채팅창에서 토큰이 흘러나오길 기다리지 말고, 동료에게 하듯 과제를 주고 보낸 뒤 준비되면 검토하는 비동기 방식이 최선이라는 겁니다.

이 모든 게 작년 11월 24일에 시작돼 1년도 안 됐고, "과제가 아니라 결과와 문제를 맡길 수 있는" 지능은 몇 달밖에 안 됐으니 아무도 정답을 모른다는 단서도 붙입니다.

Ruby와 Rails는 어디로 가나

Hey의 답은 네이티브 프런트엔드와 Rust 백엔드지만, 설치를 요구하지 않는 웹은 여전히 훌륭한 플랫폼이고 Rails는 거기서 잘 자리 잡고 있다는 것이 DHH의 주장입니다. 25년간 지켜 온 "설정보다 관례(convention over configuration, 정해진 규칙을 따르면 설정을 따로 쓸 필요가 없게 하는 설계)"는 토큰 효율로 직결되고, 1인 개발자 프레임워크 지향이 에이전트 시대 요구와 맞아떨어진다는 겁니다.

Rails Foundation을 대신해 Evil Martians가 에이전트 평가(eval)를 시작했는데, 첫 버전은 에이전트가 95% 완료율로 포화시켜서 더 어렵게 바꿨습니다. 평가 항목이나 점수표는 말하지 않았습니다.

컴퓨터를 너무 잘 아는 사람의 함정도 짚습니다. 지나치게 처방적으로 굴지 말 것. 초심자 마음가짐으로 더 높은 수준의 프롬프트를 던지는 편이 낫다는 조언입니다. DHH는 Rust를 전혀 모르고, 그걸 "특권"으로 여기며, Rust 결과물을 블랙박스로 평가합니다.

"Ruby보다 좋은 언어는 English"

DHH가 Ruby보다 좋아하게 된 언어는 영어라고 합니다. 더 표현력이 있고, 조금 더 모호하고 비결정적이지만, 절대적인 기쁨이라는 겁니다.

약 4~5개월 전, 아마 3월에 전문 프로그래머에서 은퇴했다고 밝힙니다. 25년간 손으로 코드를 깎은 시간을 후회가 아니라 기쁨으로 돌아보라고 권합니다.

그리고 선언합니다. 손코딩은 대다수 회사의 대다수 프로그래머에게 더 이상 경제적으로 생산적이지 않다. 오늘 기준으로. 연말이면 거의 모든 영역, 거의 모든 프로그래머, 거의 모든 회사에 해당될 것이라는 건 DHH의 예측입니다.

반대편에는 "전문 메이커"로서의 새 커리어가 있다고 합니다. 컴퓨팅 역사상 가장 큰 사건이고, 인터넷과 비슷하지만 훨씬 크다는 표현을 씁니다.

다시 생각해야 할 것들

DHH가 꼽은 첫째는 소프트웨어 아키텍처 전반, 특히 추상화입니다. 수백에서 수만 개의 프로세스가 동시에 앱을 바꾸는 시대엔 추상화라는 병목이 오히려 방해가 될 수 있습니다. 반복의 비용과 동기화 유지 비용이 거의 0이 됐기 때문입니다.

둘째는 방법론, 주기 길이, 누가 무엇을 명세할지. 아무도 답이 없고 "새 산업의 1층"에 있는 것이니 함께 정하자는 제안입니다.

가장 실용적인 요구, 앱에 CLI를 달아라

초기의 "앱마다 챗봇 끼워 넣기"는 사양한다는 것이 DHH의 입장입니다. 그에게는 CLI(명령줄 인터페이스, 터미널에서 명령어로 프로그램을 조작하는 방식)로 Basecamp, Hey 등 수많은 앱을 넘나드는 "개인 집사"(에이전트)가 있으니, "당신의 컨시어지는 필요 없다, 토큰 아껴라"라는 겁니다.

이 강연에서 가장 실용적이고 처방적인 요구가 여기 나옵니다. "당신 앱에 CLI가 없다면 다음 주 금요일까지 보고 싶다. 변명 없음."

Hey CLI 사례가 근거로 나옵니다. Elasticsearch(검색 엔진 소프트웨어) 검색은 "그럭저럭"인데, 에이전트는 키워드가 아니라 개념으로 검색해서 5년 전 "스니커즈와 팟캐스트" 관련 메일을 몇 분 만에 찾아냈다고 합니다. 어떻게 했는지는 DHH도 모른다고 합니다.

DHH가 에이전트로 직접 만든 앱들

• Omarchy(DHH가 만든 리눅스 배포판)에 맞춘 계산기: ChatGPT가 준 시안 스크린샷 1장으로 원샷 제작. 프롬프트 7분 뒤 앱 완성, 15분 뒤 공개 저장소 푸시, 새 ISO(설치용 디스크 이미지)에 포함. DHH는 C++도 Qt도 몰랐다고 합니다
• iA Writer를 대신할 글쓰기 앱: 에이전트가 낸 코드를 한 줄도 보지 않았다. "C++도 Rust처럼 블랙박스로는 훌륭한 언어"
• 영상 트리밍 앱, 그리고 목요일에 시작해 이 발표를 위해 만든 발표 소프트웨어 "Hype": markdown 기반, 바이너리 0.5MB

저장소 주소나 사용 도구는 말하지 않았습니다.

지난 20년은 컴퓨터 성능을 사람의 생산성에 썼기 때문에 앱이 느리고 비대해졌다는 진단도 있습니다(Spotify 1.2GB를 예로 듦). 이제 모든 최적화가 손에 닿아서 하룻밤에 10~30배 개선을 얻을 수 있다는 건 DHH 주장입니다.

낙관론, p(doom)보다 p(bloom)

DHH는 풍요와 기쁨이 올 확률(p(bloom))이 파멸 확률(p(doom))보다 훨씬 크다고 봅니다. 핵에너지를 40년간 낭비한 실수처럼 잘못은 고칠 수 있다는 겁니다.

보안 같은 진짜 문제는 기술로 해결한다는 입장입니다. C 이미지 라이브러리 관련 Rails CVE(공개된 보안 취약점 번호) 사례와 격리 노력(동료 Mike가 따로 발표 예정)을 언급합니다.

게임이론상 유일한 수는 "완전한 낙관"이라고 합니다. "Agent Luther"가 성직자 계급(프로그래머)을 탈중개화해 모두가 프로그래머가 될 수 있게 되지만, Rails 프로그래머는 "최고 중 최고(Top Gun)"이니 경쟁을 두려워 말라는 격려입니다.

아이들은 잊어야 할 500겹의 지식이 없어서 변화에 열광합니다. "Future's now, old man." 낙관의 알약을 먹고 완전 가속으로 미래를 받아들이라는 말로 마무리합니다.

DHH가 실제로 권한 것

• 손코딩을 기본 업무에서 내려놓고, 에이전트가 실패할 때만 예외적으로 손을 대라. 그 뒤엔 "기계(공장)를 고쳐라"
• 지금 유일하게 진지한 질문은 "이 지능 폭발에서 최대치를 어떻게 끌어내느냐"다
• 에이전트와는 채팅창에서 기다리지 말고, 동료에게 하듯 과제를 주고 보낸 뒤 준비되면 검토하라
• 컴퓨터를 잘 안다고 지나치게 처방적으로 굴지 말고, 초심자 마음가짐으로 더 높은 수준의 프롬프트를 던져라
• 생성된 코드(Rust, C++)는 블랙박스로 두고 바깥에서 결과로 평가하라
• 앱에 챗봇을 끼워 넣지 말고 CLI를 만들어라. "다음 주 금요일까지"
• 추상화, 방법론, 주기, 명세 주체 등 아키텍처 전반을 다시 생각하라. 반복과 동기화 비용이 거의 0이 됐다
• 손코딩 시대를 후회가 아니라 기쁨으로 돌아보고, 끝났음을 받아들이라
• 낙관을 택하라. 보안 같은 진짜 문제는 기술로 방어하라

우리 서비스 [서비스 이름]의 기존 API를 감싸는 CLI를 만들어 줘.
- 명령 구조: [서비스 이름] <대상> <동작> (예: tasks list, tasks create, tasks done)
- 모든 명령에 --help 설명과 --json 출력 옵션을 넣어 줘.
- 인증은 환경 변수 API_TOKEN으로 받아 줘.
- 삭제 명령은 --yes 없이는 실행되지 않게 해 줘.
먼저 명령 목록과 설계안만 보여 주고, 내가 승인하면 코드를 작성해 줘.

[목표] 무엇이 끝나면 완료인지 한 문장
[배경] 왜 필요한지, 관련 파일·문서 위치
[하지 말 것] 건드리면 안 되는 파일, 쓰면 안 되는 라이브러리
[완료 확인] 어떤 테스트가 통과하거나 어떤 화면이 떠야 하는지
[보고 형식] 바꾼 파일 목록, 남은 문제, 내가 결정해야 할 것

출처: youtu.be/…