"90%는 멀었다"던 DHH, 7개월 만에 "코드 한 줄도 손으로 안 썼다"

렉스 프리드먼은 공개 당일 X에 대화 전체 영상을 올리며 프로그래밍의 미래와 AI, 리눅스, 인류 문명을 다룬 5시간짜리 대화라고 소개했습니다. DHH는 37시그널스의 CTO이고, 1년 전 첫 출연 때는 AI 자동 완성이 자기 생각을 끊는다며 회의적이었던 사람입니다.

「90%는 멀었다」에서 「100%」까지 7개월

DHH의 생각이 달라진 속도는 그가 쓴 글에 날짜와 함께 남아 있습니다. 1월 7일 블로그에서 그는 에이전트에게 승진을 주겠다며 실제 코드베이스에 넣을 만한 결과물을 낸다고 인정했습니다. 같은 글에는 이런 문장도 있습니다.

에이전트가 코드의 90% 이상을 쓴다는 온라인의 자랑과는 거리가 한참 멉니다. 품질과 일관성을 지키려면, 제가 도달할 수 있는 수준과는 동떨어진 이야기입니다.— DHH, 블로그 「Promoting AI agents」 (2026년 1월 7일)

7개월 뒤 팟캐스트에서 그는 8월 14일 나온 Omarchy 4, 별칭 Quattro를 예로 들었습니다. 3개월 전부터 에이전트 비중이 100%에 가까워졌고 최근 2개월은 100%였다는 것입니다. 전체 구조는 모두 검토했고 데이터와 로직을 담는 모델 부분처럼 중요한 코드는 한 줄씩 읽었지만, UI 코드와 보조 코드는 상당 부분 보지 않았다고 했습니다.

그가 꼽은 분기점은 앤트로픽이 Claude Opus 4.5를 내놓은 2025년 11월 24일입니다. 이틀 뒤 과제 몇 개를 줘 봤더니 결과물이 자기가 쓴 것과 소름 끼치게 비슷했다고 했습니다. 이어 봄에는 일을 쪼개 여러 서브에이전트에게 나눠 주는 하네스가 나왔고, 여름에 Opus 5와 Fable, GPT Sol이 나오면서 가는 길을 알려 주지 않고 문제만 말해도 되는 단계가 됐다는 것이 그의 구분입니다. 초기 내비게이션이 사람을 항구로 몰아넣는다는 기사가 나오던 시절을 떠올리며, 지금은 경로를 고르는 일에서 자신이 선택 사항이 됐다고 했습니다.

그는 늦게 올라탄 쪽이었다고 스스로 말했습니다. 클로드 코드는 2025년 2월 24일 연구 프리뷰로 나왔지만 자기가 설치한 것은 9월이었고, 2025년 4월 토비 뤼트케 쇼피파이 CEO가 사내에 돌린 AI 메모를 읽고는 조금 과하다고 생각했다고 했습니다. 9개월 전 자기가 지금처럼 말하는 것을 들었다면 AI 정신병이라고 불렀을 거라는 말도 덧붙였습니다.

100%라는 말에 붙은 조건

Omarchy 4 릴리스 노트를 보면 데스크톱 셸 전체를 Quickshell로 다시 짰고, 설치 이미지를 1GB 넘게 줄여 6GB 아래로 낮췄으며, 설치 속도를 30% 올렸습니다. 플러그인 체계와 함께 글쓰기 앱 Omawrite, 클립 편집기 Omacut, 계산기 Omacalc가 기본 앱으로 들어갔고, 기본 코딩 에이전트를 지정해 두면 앱이 멈췄을 때 원인을 진단해 주는 기능도 붙었습니다.

Omawrite는 DHH의 실험이었습니다. 쓰던 마크다운 편집기 Typora에서 필요한 기능이 5%뿐이라며 C++와 Qt로 만들어 달라고 했고, 20분쯤 뒤 첫 버전이 나와 이틀 만에 Typora를 그만 썼습니다. C++ 코드는 한 줄도 보지 않고 완전한 블랙박스로 다뤘다고 했습니다. 러스트는 지난 40년 사이 나온 가장 못생긴 언어라 싫어하지만, 결과물이 빠르고 메모리 안전해서 에이전트에게 맡기기에는 훌륭하다고도 했습니다.

회사 제품은 사정이 달랐습니다. 37시그널스가 5월 26일 내놓은 베이스캠프 5는 에이전트를 쓴 첫 제품이었는데, 2월 막바지 작업 때 기능을 아는 디자이너들에게 바이브 코딩을 맡겼다가 풀리퀘스트 하나하나는 그럴듯해도 합쳐 놓으니 시스템 구조가 무너졌다고 했습니다. 사람 손으로 치워야 했고, 그래서 사용자가 많은 기존 코드베이스라면 구조를 지킬 줄 아는 프로그래머가 필요하다고 봤습니다. 다만 그건 2월 이야기이고 지금은 많이 달라졌다고 덧붙였습니다.

Quattro에 들어간 코드는 한 줄도 손으로 쓰지 않았습니다.— DHH, 37시그널스 CTO (Lex Fridman Podcast)

같은 이식 작업, Fable은 550달러, 딥시크는 23달러

DHH가 모델을 비교한 방식은 우연히 생긴 시험이었습니다. Omarchy 화면보호기에 쓰던 파이썬 라이브러리 TerminalTextEffects가 노트북에서 CPU를 많이 먹자, 의존성 없는 러스트 실행 파일로 프레임 하나하나까지 똑같이 옮기라는 한 문장짜리 지시를 여러 모델에 줬습니다. 그가 기억하는 결과는 이렇습니다.

표에는 조건 두 가지가 붙어 있습니다. Fable은 구독 한도를 3분의 2쯤 쓴 뒤 자동으로 Opus 5로 넘어갔고, 550달러는 구독 대신 토큰값을 냈다면 들었을 금액입니다. Sol에게는 Fable이 만든 8단계 계획을 그대로 줬습니다. 그래도 DHH는 러스트를 배워 직접 옮겼다면 9개월짜리 일이었을 거라며 550달러도 헐값이라고 했습니다. 모델 순위로는 Fable을 1위, Opus 5를 2위로 꼽았고, Sol은 아주 좋다고, Grok 4.6은 며칠 전 시험을 시작했다고 했습니다.

기록도 대체로 맞습니다. 8월 9일 만들어진 ttfx 저장소는 원본과 같은 입력이면 같은 프레임을 내는 동등 이식이라고 적었고, 커밋 기록에는 처음 잰 속도 향상 중간값 9.6배가 최적화를 거쳐 14.1배, 다시 27.5배(효과별 17.1~47.4배)로 올라간 과정이 남아 있습니다. 8월 11일 README 기준 시작 시간은 0.5ms로 파이썬 원본(64ms)의 128분의 1이고, 커밋 공동 작성자에는 Claude Opus 5가 적혀 있습니다. Fable과 Opus 5의 가격 차이는 Fable 5 반값에 나온 Opus 5에 정리했습니다.

버그를 찾는 능력에도 놀랐다고 했습니다. Omarchy 개발 도구를 관리하는 패키지 매니저 mise에서 에이전트가 경쟁 상태 버그를 찾았는데, 소스 코드를 받아 보니 개발자가 이미 고친 부분이 아직 출시 안 된 판에서도 문제를 완전히 풀지 못한다는 것까지 짚어 냈습니다. 개발자는 출시도 안 한 소프트웨어의 버그 제보를 처음 받았다고 답했답니다. DHH는 쇼피파이 CTO가 운영 사고를 거꾸로 추적해 보니 에이전트가 검토한 풀리퀘스트가 사람이 검토한 것보다 사고를 덜 냈다는 사내 분석도 전했습니다.

한 모델이 짜고 다른 모델이 검토합니다

작업 방식도 달라졌습니다. 손으로 코드를 다듬던 때는 문제 하나에 깊이 빠지는 것이 몰입으로 가는 길이었는데, 에이전트는 답이 오기까지 기다려야 해서 한 개만 돌리면 할 일이 없다고 느꼈답니다. 그래서 터미널 탭을 여러 개 띄우고, 에이전트가 끝나면 알림을 주는 도구 Herdr와 원격 제어 장비로 벽장 속 미니 PC까지 묶어 4~5대에서 16개 작업을 동시에 돌린다고 했습니다.

검토는 출처가 다른 모델끼리 맞바꿉니다. Opus 5나 Fable이 작업을 끝내면 늘 Codex의 가장 높은 추론 설정으로 검토하고, 깃허브에 올린 뒤에는 코파일럿 리뷰까지 받습니다. 주로 쓰는 하네스는 클로드 코드입니다. 여러 에이전트를 오가며 관리하기가 가장 편하다는 이유였고, 오픈웨이트 모델은 OpenCode로 불러 중국 서버 대신 미국 추론 업체 파이어웍스에서 돌린다고 했습니다. 베이스캠프 안에 에이전트를 동료처럼 들여 할 일을 맡기는 실험도 하고 있는데, 바로 답을 기다리게 되는 채팅보다 비동기 협업 도구가 에이전트에게 더 맞는 그릇이라고 봤습니다.

앤트로픽에 대한 유보도 숨기지 않았습니다. 7월 27일 블로그에서는 클로드가 자기 블로그 글의 번역을 내용을 이유로 거절했다며, 그래서 강한 오픈웨이트 모델이 절실하다고 썼습니다. 그러면서도 클로드 구독은 터무니없이 싸다고 했고, 녹음 날 아침에는 한도가 바닥나 두 번째 구독을 샀다고 했습니다.

지시는 덜 할수록 좋은가

DHH가 가장 크게 바꾼 습관은 지시를 줄인 것입니다. 첫 에이전트 시기에는 25년 경험대로 하는 방법까지 정해 줬는데, 지금은 문제와 원하는 결과만 말할 때 더 좋은 답이 나온다고 했습니다. 그는 클로드 코드를 만든 보리스 체르니가 한 인터뷰에서 Opus 5용 시스템 프롬프트가 80% 줄었다고 말했다며, 모델이 지나치게 세세한 지시에 오히려 손상된다고 설명했습니다. 애자일 운동처럼 먼저 대충 만들어 써 보고, 선택지 세 개를 받아 직감으로 고르라는 것이 그의 방식입니다.

같은 회사 안에서도 강조점은 다릅니다. 클로드 코드 팀의 Thariq는 7월 3일 Fable 사용법을 정리하며, Fable은 사용자가 모르는 것을 얼마나 밝혀 주느냐에 결과의 질이 걸리는 첫 모델이라고 적었습니다(Claude Code 개발자의 Fable 사용법). 진행자 프리드먼도 좋은 프로그래머의 강점은 시스템을 설계하고 검증을 요구하는 엄격함이라고 반박했고, DHH는 6개월 전이었다면 자기도 같은 말을 했을 거라고 받았습니다.

그는 이 대목에서 프로그래머가 비프로그래머보다 불리한 경우도 있다고 봤습니다. 무엇을 누구에게 어떤 순서로 만들지 정하는 제품 관리 능력이 프로그래머에게 고르게 있지 않은데, 구현을 에이전트가 맡는 시대에 필요한 것이 그 능력이라는 이유입니다.

풀리퀘스트 1,000건과 깃허브 기록

오픈소스에서 DHH는 AI가 쓴 풀리퀘스트가 몰려드는 것을 반겼습니다. 품질이 들쭉날쭉하다는 관리자들의 불만을 스테이크 육즙이 너무 많다는 불평에 빗댔고, 사람이 쓴 것보다 에이전트가 쓴 풀리퀘스트를 받는 편이 낫다고 했습니다. 거절해도 마음이 덜 쓰이고, 에이전트가 먼저 검토해 요약을 보내 주기 때문입니다.

숫자는 기록과 조금 다릅니다. 그는 Quattro 작업 3개월 동안 풀리퀘스트 1,000건 넘게 병합했다고 했지만, omacom/omarchy 저장소에서 그가 녹음일로 예고한 8월 17일까지 3개월 동안 병합된 풀리퀘스트는 228건이었습니다. 같은 기간 새로 올라온 풀리퀘스트는 779건이었고, 1,000건을 넘는 것은 프로젝트를 연 뒤 누적 병합 수(1,091건)입니다. 열린 풀리퀘스트가 1주일 새 두 배가 됐다는 말은 기록(약 180건에서 약 360건)과 맞습니다.

관리자 쪽 경험은 반대편에 있습니다. curl을 이끄는 다니엘 스텐베리는 2025년 7월 블로그에서 그해 들어온 보안 제보의 약 20%가 AI 슬롭이었고, 진짜 취약점은 5%뿐이었다고 적었습니다. DHH도 품질 점검용으로 에이전트 8개를 돌려 찾은 문제 28건을 12초 만에 한꺼번에 올리려다 깃허브에 스팸으로 찍혀 봇 계정이 막혔다고 했습니다.

병목은 사람 사이의 대역폭

그렇다면 왜 포토샵 같은 기성 소프트웨어는 빨라지지 않느냐는 물음에, DHH는 구현이 병목이었던 적이 드물다고 답했습니다. 제품 관리자와 디자이너, 그 위의 부사장과 CTO가 모두 모양을 정하는 데 끼어들면 생산성이 거기서 사라진다는 것입니다. 10배, 100배의 생산성을 내려면 사람을 거치지 않고 에이전트와 직접 일해야 하고, 대부분의 조직은 구현보다 아이디어와 안목에서 막혀 있다고 봤습니다. 수만 명의 프로그래머를 둔 회사가 코드만 많이 쓴다고 좋은 소프트웨어가 나오지 않았다는 것이 근거였습니다.

프로그래머에게 한 조언과 반대편 숫자

진로를 걱정하는 개발자에게 DHH는 앞날을 예측하려 들지 말라고 했습니다. 가장 똑똑한 사람들도 모델 두 세대 뒤를 내다보지 못하니, 지금 최신 도구가 어디까지 왔는지 억지로라도 배워 보라는 것입니다. 기계적으로 코드를 짜는 일만 좋아했다면 힘들겠지만 무언가 만드는 일을 좋아한다면 위협받지 않는다고 했고, 값이 내려가면 수요가 느는 제번스 역설과 ATM 뒤에 은행 창구 직원이 오히려 늘었던 사례를 들었습니다. 고용 통계는 흐릿하다고 스스로 인정했습니다.

실제 숫자도 한쪽으로 기울지 않습니다. 미국 22~25세 개발자 고용은 2022년 말 고점보다 19% 줄었지만 전체 개발자 수는 늘었고, 그 과정은 22~25세 개발자와 깃허브 가입자 3,600만 명에 정리했습니다. 비영리 연구소 METR이 2025년 경력 개발자 16명에게 실제 과제 246건을 맡긴 실험에서는 AI 도구를 쓸 때 오히려 19% 느렸고, 참가자들은 끝난 뒤에도 20% 빨라졌다고 믿었습니다. 이 실험은 DHH가 분기점으로 꼽은 2025년 11월 이전의 도구로 잰 것입니다.

영어로 코딩하는 3개월, 지속할 수 있나

DHH는 25년 동안 코드 한 줄 한 줄을 다듬은 이유를 경제성으로 설명했습니다. 아름다운 코드는 사람이 고치기 쉬워 작은 팀이 싸게 바꿀 수 있었다는 것입니다. 그 전제가 흔들리는 지금도 토큰이 아직 넉넉하지 않아서, 에이전트가 맥락을 다시 배우지 않아도 되는 깔끔한 구조가 여전히 값을 한다고 했습니다. 손 코딩은 코모도어 64 시절 프로그래밍처럼 낭만이 될 거라며, 지금은 영어로 프로그래밍한다고 했습니다.

루비보다 아름다운 프로그래밍 언어가 하나 있다면 그건 영어입니다.— DHH, 37시그널스 CTO (Lex Fridman Podcast)

대가도 털어놨습니다. 지난 3개월이 HEY를 출시한 뒤 5년 동안 한 어떤 프로젝트보다 지쳤고, 이 속도는 지속할 수 없다고 했습니다. 그가 그리는 다음 단계는 사람이 에이전트 곁을 지키지 않아도 되는 자동화입니다. 이미 만들고 있는 Omarchy 봇이 정해진 시간마다 풀리퀘스트와 이슈를 정리해 하루 한 번 메일로 보내면, 그는 병합할지 닫을지만 정하는 구조입니다. 다음 Omarchy에는 여러 AI 구독을 오가며 쓰는 기능도 넣겠다고 했습니다.

읽어 주셔서 고맙습니다.

초이 드림