슈퍼개발자 DHH "프로그래머로서 은퇴" 선언

DHH(데이비드 하이네마이어 한슨)

• 웹 개발 프레임워크 Ruby on Rails와 리눅스 기반 운영 환경 Omarchy를 만든 개발자. dhh.dk

• 37signals의 공동 소유주이자 CTO로, 협업 도구 Basecamp와 이메일 서비스 HEY를 개발. world.hey.com

• 『REWORK』·『REMOTE』 공동 저자이자 르망 24시간 레이스 클래스 우승자로, 개발·경영·레이싱을 넘나드는 인물.

• 제가 아주 좋아하는 고수개발자입니다. (5시간 15분 짜리 영상도 찾아본..)

9월 24일에 있었던 한 행사에서 DHH가 재밌는 키노트 연설을 했더군요.

내용이 매우 흥미로와서 스크립트를 긁어서 AI에게 최대한 자세히 정리해달라고 요청했습니다.

정라한 내용이 너무 길어서 영상을 바로 보시는 것이 더 나을 지도 모르겠습니다만…;;
누군가에게 도움이 될 수도 있을 것 같아 걍 올립니다.

전 전체 21개의 꼭지 중 4, 5, 7, 10, 11, 14, 15, 16, 19, 이 9개의 꼭지가 눈에 들어와서 꼭꼭 읽어봤네요.

이 연설의 핵심은 “AI가 코드를 대신 쓰기 시작하면, 개발자의 역할뿐 아니라 기술 선택·제품 설계·개발 조직·소프트웨어의 경제성까지 다시 생각해야 한다”는 것입니다. DHH는 이를 개발자의 몰락보다 더 많은 것을 만들 수 있게 되는 전환으로 받아들이자고 주장합니다.

원문 「DHH on AI euphoria」는 문서상 Rails World 2026 강연의 약 63분 분량 영어 자막입니다. 아래는 강연 전체를 순서와 논리에 따라 상세히 정리한 내용입니다. 회사 사례·제품명·출시일·성능 수치는 원문에 담긴 DHH의 설명이며, 별도 외부 검증을 거친 사실은 아닙니다. 특히 생산성 배수와 미래 전망은 측정 결과와 의견을 구분해 읽어야 합니다.

1. 강연의 출발점: AI에 대한 흥분과 불안을 동시에 인정한다 — 0:07~1:49

DHH는 지금이 자신이 컴퓨터를 사용하고 개발해 온 기간 중 가장 흥미로운 순간이라고 말합니다. AI 에이전트를 통해 컴퓨터가 할 수 있게 된 일들이 그만큼 놀랍다는 것입니다.

그는 자신의 상태를 ‘AI 정신병’이라는 부정적인 표현 대신 ‘AI 도취’, ‘AI 환희’라고 부릅니다. 강연 제목의 AI euphoria는 이 감정을 뜻합니다.

그러면서도 불안이 생기는 것은 자연스럽다고 인정합니다.

• 기술이 어디까지 발전할지 알 수 없다.

• 개발자의 일이 어떤 모습으로 바뀔지 알 수 없다.

• 변화가 너무 빨라 미래 예측이 금방 낡는다.

• 지금까지 쌓아 온 전문성이 앞으로도 같은 가치를 가질지 확신하기 어렵다.

강연은 이러한 불안을 부정하기보다, 과거의 기술 전환과 자신의 개발 경험을 통해 불확실한 상황에서도 적극적으로 참여할 이유를 설명하는 방식으로 진행됩니다.

2. 첫 번째 비유: 초상화 화가에게 카메라는 무엇이었는가 — 1:50~7:43

DHH는 AI와 개발자의 관계를 설명하기 위해 초상화와 사진의 역사를 꺼냅니다.

18세기에 자신의 모습을 남기려면 화가에게 초상화를 의뢰해야 했습니다. 모델은 오랜 시간 앉아 있어야 했고, 화가는 수개월 동안 그림을 그렸습니다. 뛰어난 결과물을 얻을 수 있었지만, 비용과 시간이 많이 들어 일부 부유층과 왕실에 집중된 서비스였습니다.

그는 조슈아 레이놀즈의 그림을 예로 들며 고객이 발목이 드러났다는 이유로 그림을 거절해 다시 작업해야 했다는 일화도 소개합니다. 오늘날 개발자가 고객의 요구 변경 때문에 작업을 다시 하는 상황과 연결한 농담입니다.

이어 덴마크 화가 라우리츠 툭센이 왕실 가족의 모습을 그리는 데 수년을 들였다고 설명합니다. 이 그림은 예술품이면서 동시에 사람의 모습을 기록하는 기능을 수행했습니다.

그러나 카메라가 등장하고 사진 촬영이 저렴해지면서 그 기능의 경제성이 바뀌었습니다.

• 사람의 모습을 정확하게 재현하는 일이 화가만의 능력으로 남지 않았다.

• 시간이 많이 드는 수작업과 빠르고 저렴한 기계적 재현이 경쟁하게 됐다.

• 화가들은 기존 기술을 그대로 판매하기보다 다른 표현과 영역을 찾아야 했다.

그는 인상주의와 입체주의 같은 새로운 예술적 방향을 이 변화와 연결합니다. 강연의 논리에서는 기존 기능이 자동화되면서 인간의 창작이 새로운 방향으로 이동했다는 것입니다.

또한 툭센이 자신의 고조부이고, 그림 속 인물이 자신의 증조모라고 소개합니다. 기술 변화로 직업의 성격이 달라지는 이야기를 자신의 가족사와 연결해 전달합니다.

여기서 개발자에게 전달하려는 메시지는 다음과 같습니다.

지금까지 가치 있었던 수작업이 저렴해졌다고 해서, 무언가를 만드는 능력과 창작의 가능성까지 사라지는 것은 아니다. 다만 가치가 생기는 지점은 이동한다.

3. 사진의 진짜 변화는 발명보다 ‘마찰의 제거’에서 일어났다 — 7:43~11:19

DHH는 카메라가 발명된 시점과 사진이 일상에 폭발적으로 확산된 시점을 구분합니다.

그의 설명에서 기술 발전은 매년 일정한 속도로 진행되지 않습니다. 큰 도약이 일어난 뒤 한동안 변화가 작아 보이다가, 다시 비용과 사용상의 제약이 줄면서 새로운 도약이 일어납니다.

자신의 어린 시절 사진이 많지 않았다는 경험을 통해 이를 설명합니다. 일반 가정도 사진을 찍을 수 있었지만, 필름을 사고 현상하고 인화하는 비용과 번거로움이 있었기 때문입니다.

반면 디지털 사진과 스마트폰 시대에는 상황이 달라졌습니다.

• 사진을 추가로 한 장 찍는 비용이 거의 느껴지지 않는다.

• 필름과 현상 과정이 필요 없다.

• 항상 카메라를 가지고 다닌다.

• 아이의 모습이나 산책 중 풍경을 수없이 기록할 수 있다.

그는 원문에서 2026년 연간 사진 촬영량이 약 2조 장에 이른다고 언급합니다. 이 숫자의 역할은 정확한 시장 규모를 분석하는 데 있지 않고, 생산 비용과 번거로움이 줄면 사용량이 이전과 전혀 다른 규모로 커진다는 주장을 뒷받침하는 데 있습니다.

소프트웨어에서도 같은 일이 일어날 수 있다는 것이 그의 생각입니다. 지금까지 개발비와 인력 때문에 만들지 않았던 작은 도구, 개인용 프로그램, 특정 업무만을 위한 기능이 대량으로 만들어질 수 있다는 것입니다.

4. DHH가 보는 AI의 전환점: ‘쓸 만한 코드’에서 ‘문제와 아이디어를 맡길 수 있는 지능’으로 — 11:20~16:01

DHH는 자신에게 결정적이었던 시점을 원문상 2025년 11월 24일, Opus 4.5의 등장으로 지목합니다.

그는 이를 코닥 브라우니 카메라에 비유합니다. 새로운 기술이 존재하는 수준을 넘어, 많은 사람이 접근하고 실제 생산 활동에 활용할 수 있는 단계로 넘어갔다는 의미입니다.

이때 경험한 변화는 AI가 코드를 출력한다는 사실 자체보다, 에이전트가 만든 결과물을 실제 코드에 합칠 수 있겠다고 느낀 것입니다.

이후 원문에는 다음과 같은 발전 과정이 등장합니다.

이 표의 이름과 시기는 자막의 표기를 그대로 옮긴 것입니다. 실제 출시 이력과 일치하는지는 이 정리에서 확인하지 않았습니다.

강연에서 더 중요한 구분은 에이전트에게 맡기는 대상의 변화입니다.

• 초기에는 구체적인 작업을 지시했다.

• 이후에는 해결할 문제나 원하는 결과를 제시할 수 있게 됐다.

• 구현에 대한 세부 개입이 줄어들어도 결과가 나오는 경험을 했다.

DHH가 느끼는 혁명은 코드 자동완성을 넘어, 구현의 상당 부분을 다른 지능에 위임할 수 있게 된 것입니다.

5. ‘10배 개발자’ 논쟁에서 ‘100배·1,000배 차이’의 가능성으로 — 16:02~18:12

DHH는 오래된 ‘10배 개발자’ 논쟁을 소개합니다.

원문에 따르면 1968년 연구에서 개발자별 과제 수행 차이가 약 5~30배, 평균적으로 10배 수준으로 나타났고, 업계는 이후 수십 년 동안 이러한 차이가 실제로 존재하는지 논쟁했습니다.

그는 AI 시대에는 논쟁의 기준 자체가 달라진다고 주장합니다.

비교 대상이 이제 다음과 같이 바뀌기 때문입니다.

• AI 도구를 쓰지 않는 역량이 낮은 개발자

• AI 도구를 능숙하게 사용하는 역량이 높은 개발자

이 두 집단 사이에는 100배, 나아가 1,000배의 차이도 가능하다는 것이 그의 주장입니다.

다만 강연에는 이 100배·1,000배를 입증하는 공통 과제, 품질 기준, 실험 설계가 제시되지 않습니다. 모든 개발자가 AI를 사용하면 그만큼 빨라진다는 의미로 받아들이면 안 됩니다.

그가 강조하는 실질적 문제는 다음과 같습니다.

• 개발자 간 성과 차이가 더 커질 수 있다.

• 적은 인원으로도 이전보다 큰 제품을 만들 수 있다.

• 기업의 경쟁력이 개발자 수와 같은 방식으로 비례하지 않을 수 있다.

• 기존의 인력 규모와 개발 기간을 전제로 한 사업 계산을 다시 해야 한다.

즉, 정확한 배수보다 개발 생산성의 격차와 소규모 조직의 가능성이 크게 달라질 수 있다는 주장에 무게가 있습니다.

6. Rails와 AI를 관통하는 철학: ‘내가 하지 않아도 되는 일’이 늘어나는 즐거움 — 18:13~20:53

DHH는 2005년 자신의 Rails 발표 장면을 보여줍니다.

당시 그는 이름과 관례만 맞추면 컨트롤러, 템플릿 등이 자동으로 연결되고, 많은 설정과 반복 코드를 쓰지 않아도 된다는 점에 흥분했습니다.

그가 반복하는 표현은 “내가 하지 않는 일들을 보라”는 취지입니다.

Rails의 가치는 개발자에게 더 많은 일을 시키는 데 있지 않았습니다. 반복 작업과 설정 부담을 줄여, 실제로 원하는 기능을 만드는 데 집중하게 해 주는 데 있었습니다.

그는 AI를 같은 방향의 훨씬 더 큰 변화로 봅니다.

• Rails가 일부 반복 작업과 설정을 없앴다면,

• AI는 구현 작업의 훨씬 넓은 부분을 대신 수행한다.

• 사람이 직접 쓰는 코드는 줄지만, 만들어 낼 수 있는 결과는 늘어난다.

원문에서 그는 최근 20개월 동안 만들어 낸 코드량이 이전 21년 동안의 절반에 해당한다고 말합니다. 동시에 코드 줄 수는 언어에 따라 의미가 다르고 생산성의 불완전한 지표라는 점도 인정합니다.

이 부분의 중심은 코드를 직접 많이 썼다는 자부심에서, 원하는 것을 더 많이 실현했다는 만족으로 이동하는 것입니다.

7. 37signals의 선언: 손으로 코드를 쓰는 일을 기본 업무에서 예외로 바꾼다 — 20:54~22:11

강연에서 가장 직접적인 조직 운영 변화입니다.

DHH는 37signals가 몇 주 전부터 손으로 코드를 작성하는 방식을 정상적인 기본 업무로 삼지 않기로 했다고 말합니다.

그의 설명에 따르면 이제 사람이 직접 코드를 쓰는 상황은 에이전트가 원하는 결과를 내지 못한 예외입니다.

그가 제시하는 대응은 다음과 같습니다.

1. 에이전트에게 원하는 결과를 맡긴다.

2. 에이전트가 해결하지 못하면 원인을 살펴본다.

3. 당장 필요한 경우 사람이 직접 수정한다.

4. 이후 같은 문제가 반복되지 않도록 에이전트와 작업 체계를 개선한다.

그는 이를 ‘기계’와 ‘공장’을 고치는 일에 비유합니다. 사람의 직접 작업으로 계속 빈틈을 메우기보다, 자동으로 생산하는 체계의 성능을 높이는 데 관심을 돌리자는 것입니다.

다만 이 선언을 ‘개발자의 모든 책임을 없앤다’는 뜻으로 확대해서 읽어서는 안 됩니다. 강연의 핵심은 코드 작성 방식의 변화이며, 뒤에서는 결과 검토와 평가의 필요성을 계속 언급합니다.

또한 강연장 청중에게 아직 매주 상당량의 코드를 손으로 쓰는 사람이 있는지 묻고, 손을 든 사람이 매우 적다고 반응합니다. 이는 현장의 분위기를 보여 주는 장면이며, 전체 개발자 시장을 대표하는 조사 결과는 아닙니다.

8. Basecamp 5의 시행착오: 개별 기능이 괜찮아도 전체 구조는 망가질 수 있다 — 22:12~24:09

DHH는 자신의 낙관론만 이야기하지 않고 실패 경험도 소개합니다.

37signals는 봄에 Basecamp 5를 마무리하면서 디자이너들이 원하는 마지막 기능을 직접 바이브 코딩으로 만들도록 했습니다.

결과는 엇갈렸습니다.

• 디자이너가 개별적으로 만든 변경 제안은 그럴듯했다.

• 그러나 20~30개의 변경을 합치자 전체 아키텍처에 문제가 생겼다.

• 그는 구조가 구멍이 난 스위스 치즈처럼 됐다고 표현합니다.

당시 팀은 기술이 아직 준비되지 않았다고 판단했습니다. 다시 사람이 모든 변경을 검토하고 개발자 중심으로 작업하는 방향으로 돌아갔습니다.

그러나 강연 시점의 DHH는 그 결론이 잘못됐다고 말합니다. 이후 모델의 발전을 경험하면서, 당시의 한계를 장기적인 한계처럼 해석했다고 보는 것입니다.

그가 여기서 강조하는 질문은 다음과 같습니다.

“이 지능의 발전에서 어떻게 최대한의 성과를 얻을 것인가?”

다른 개발 방식과 도구에 관한 질문도 이 질문 아래에 놓여야 한다고 주장합니다.

이 사례에서 동시에 읽을 수 있는 중요한 문제는 개별 작업의 성공과 제품 전체의 일관성은 서로 다른 평가 대상이라는 점입니다. 모델이 개선되더라도 여러 변경을 합쳤을 때 구조와 동작이 유지되는지는 별도로 확인해야 합니다.

9. HEY의 전면 재설계: 작은 팀도 여러 플랫폼의 네이티브 앱을 만들 수 있다는 주장 — 24:10~28:19

다음 사례는 이메일 서비스 HEY입니다.

DHH는 새로운 HEY를 기존 웹앱 중심에서 여러 플랫폼의 네이티브 앱으로 바꾸고 있다고 설명합니다.

그가 제시하는 기존 웹앱 선택의 이유는 경제성입니다.

• 작은 팀이 여러 플랫폼의 앱을 각각 만들기 어려웠다.

• 플랫폼마다 다른 언어와 도구를 유지해야 했다.

• 개발 인력이 많이 필요했다.

• 하나의 웹 기반 구현을 여러 환경에서 활용하는 편이 현실적이었다.

그는 React Native와 Hotwire Native 같은 도구도 이러한 제약을 해결하기 위한 선택이었다고 봅니다. 개발 생산성을 얻는 대신, 일부 사용자 경험과 플랫폼 고유의 완성도에서는 타협했다는 평가입니다.

하지만 AI가 구현 비용을 크게 낮추면 선택이 바뀔 수 있습니다.

공통 코드의 유지 편의성을 위해 선택했던 기술에서, 각 플랫폼의 사용자 경험에 더 적합한 기술로 이동할 수 있다는 것입니다.

원문에서 DHH는 약 일주일 전에 시작한 6개 네이티브 앱의 진행 상황을 보여 줍니다. 다만 텍스트에는 이 6개 플랫폼의 전체 목록이 나오지 않습니다.

Windows 앱 사례도 설명합니다.

• 첫 프롬프트 결과는 바로 출시할 수준이 아니었다.

• 방향을 수정한 뒤 약 20분 후 훨씬 나은 결과가 나왔다.

따라서 이 사례는 ‘한 번 요청하면 항상 완성된다’는 이야기가 아닙니다. 초안을 만들고 방향을 수정하는 속도가 크게 빨라졌다는 이야기입니다.

그는 Shopify의 Shop 앱 재작성도 언급하며 비슷한 변화가 다른 회사에서도 나타난다고 말합니다. 이 사례 역시 원문에서 소개된 내용이며 별도 검증은 하지 않았습니다.

10. Rust에 대한 태도 변화: 사람이 쓰기 좋은 언어와 기계가 실행하기 좋은 언어를 분리한다 — 28:20~31:45

DHH는 Rust를 사람이 직접 읽고 쓰기에는 매우 불쾌한 언어라고 강하게 표현합니다. 문법과 표현 방식에 대한 개인적인 취향입니다.

그러나 에이전트가 Rust 코드를 작성해 주면 평가는 완전히 달라진다고 말합니다.

• 자신은 무엇을 만들지 설명한다.

• 에이전트는 Rust로 구현한다.

• 자신은 결과물의 성능과 동작을 평가한다.

• 언어의 세부 문법을 직접 다룰 필요는 줄어든다.

그가 좋아하는 것은 Rust를 쓰는 경험보다 Rust로 만든 결과물의 특성입니다.

• 빠른 실행

• 적은 자원 사용

• 작은 실행 파일

• 빠른 시작

• 하드웨어에 가까운 효율성

이 주장에는 기술 선택의 기준이 바뀔 수 있다는 의미가 있습니다.

그는 HEY가 웹 화면을 만들어 제공하는 서비스의 형태에서 벗어나, 핵심인 메일 서버에 집중하면 백엔드 구조도 바꿀 수 있다고 설명합니다.

원문에서 제시한 수치는 매우 큽니다.

• CPU 사용량 99% 감소

• 메모리 사용량 95% 감소

• 10개 호스트가 필요한 이유는 처리량보다 이중화

• 대략적인 계산상 최대 트래픽을 Raspberry Pi 한 대로 처리할 가능성

마지막 내용은 DHH 자신도 대략적인 계산이라고 표현합니다. 강연 자막에는 비교 조건, 부하 시험, 장애 대응 조건, 실제 운영 검증 자료가 없습니다. 확정된 운영 성능으로 받아들이기에는 근거가 부족합니다.

강연에서 이 사례가 수행하는 역할은 개발 인건비 때문에 포기했던 성능과 효율을 다시 추구할 수 있다는 점을 강조하는 것입니다.

11. 에이전트와 일하는 방식: 채팅을 기다리기보다 업무를 맡기고 결과를 검토한다 — 31:46~33:09

DHH는 에이전트의 성능만큼 협업 방식도 중요하다고 봅니다.

그가 선호하는 방식은 비동기 작업입니다.

• 동료에게 업무를 맡기듯 에이전트에게 과제를 준다.

• 에이전트가 작업하는 동안 자신은 다른 일을 한다.

• 검토할 결과가 준비되면 돌아와 확인한다.

그는 채팅창에서 토큰이 나오는 것을 계속 지켜보는 방식보다 이런 방식이 적합하다고 말합니다.

Basecamp 안에서 ‘Chef Marie’라는 에이전트를 통해 업무를 지시하는 실험도 소개합니다.

이 변화는 개발자의 시간 사용 방식과 연결됩니다. AI가 코드를 빨리 출력하더라도 사람이 계속 붙어서 세부 지시를 해야 한다면, 작업 속도는 사람의 주의력에 묶입니다. 문제와 결과를 맡길 수 있어야 여러 작업을 진행할 가능성이 열립니다.

다만 DHH는 협업 방식이 아직 정립되지 않았다고 인정합니다.

• 기술이 계속 바뀐다.

• 이런 지능과 협업한 경험이 충분하지 않다.

• 구체적인 작업보다 문제와 결과를 맡기는 방식은 더욱 새롭다.

따라서 그는 특정 방법론이 완성됐다고 선언하기보다 지금이 그 방법을 실험하고 만들어 가는 시기라고 설명합니다.

12. Ruby와 Rails의 미래: 웹의 역할은 여전히 있고, 관례는 에이전트에게도 도움이 된다 — 33:10~36:27

HEY를 네이티브 앱과 Rust 백엔드로 바꾼다는 설명 뒤에, DHH는 Ruby와 Rails가 어디에 남는지 질문합니다.

그의 답은 애플리케이션의 성격에 따라 다르다는 것입니다.

웹은 설치 없이 접근할 수 있다는 강점이 있습니다.

• 처음 방문한 고객

• 잠깐 참여하는 협업자

• 파일 하나를 받으려는 외부 사용자

• 서비스를 오래 쓸지 아직 결정하지 않은 사람

이런 사용자에게 앱 설치를 요구하는 것은 큰 마찰이 될 수 있습니다. 그는 Basecamp처럼 외부 사람이 잠깐 참여하는 협업 서비스가 웹에 적합한 예라고 설명합니다.

Rails의 기존 철학도 에이전트 시대에 도움이 된다고 봅니다.

• 설정보다 관례: 구조를 예측하기 쉬워 설명 부담을 줄일 수 있다.

• 한 명의 개발자가 폭넓게 만들 수 있는 프레임워크: 에이전트를 활용하는 개인의 능력을 확장하기 좋다.

• 통합된 개발 방식: 구성요소마다 다른 접근법을 설명해야 하는 부담을 줄일 수 있다.

그는 Rails의 관례가 토큰 효율과 연결된다고 주장합니다.

Rails Foundation을 대신해 Evil Martians가 수행하는 에이전트 평가도 소개합니다. 실제 예제 애플리케이션에 기능을 구현하는 방식이며, 초기 평가에서 에이전트가 약 95% 완료율에 빠르게 도달해 더 어려운 평가로 바꿨다고 설명합니다.

이 숫자 역시 해당 평가에 대한 강연자의 설명입니다. 다른 언어·프레임워크·실제 운영 환경 전체로 일반화할 수는 없습니다.

13. 전문가의 세부 지시가 에이전트의 가능성을 좁힐 수 있다는 주장 — 35:16~36:11

DHH는 컴퓨터를 잘 아는 사람이 오히려 에이전트에게 지나치게 구체적인 구현 방법을 지시할 수 있다고 경고합니다.

사람이 익숙한 방식으로 해결 절차를 고정하면, 에이전트가 다른 접근법을 선택할 여지가 줄어들 수 있다는 것입니다.

그는 초보자의 마음가짐이 도움이 되는 경우가 있다고 말합니다.

• 구현 방법부터 고정하지 않는다.

• 더 높은 수준의 문제를 제시한다.

• 원하는 결과를 설명한다.

• 익숙하지 않은 기술의 결과도 평가해 본다.

자신이 Rust를 잘 모른다는 점을 오히려 장점으로 설명하는 것도 이 맥락입니다. 결과물을 외부에서 평가하는 ‘블랙박스’로 다룬다는 것입니다.

그는 이를 기업 대표가 개발자에게 시스템을 의뢰하는 상황과 비교합니다. 모든 대표가 코드를 이해하는 것은 아니지만, 원하는 결과를 정의하고 실제 사용 결과를 판단해 왔다는 논리입니다.

다만 세부 구현을 덜 지시하는 것과 품질·보안 책임을 줄이는 것은 별개의 문제입니다. 강연은 결과 중심의 위임을 강조하지만, 블랙박스 평가만으로 어디까지 안전하게 운영할 수 있는지는 구체적으로 설명하지 않습니다.

14. 생산량의 변화와 ‘영어로 프로그래밍하기’의 즐거움 — 36:28~39:20

DHH는 자신의 작업이 언어 구성과 코드량 모두에서 크게 달라졌다고 말합니다.

원문상 수치는 다음과 같습니다.

여기서 그가 ‘작성했다’고 말하는 코드에는 에이전트가 생성한 코드가 포함됩니다.

그는 Rust 같은 언어가 Ruby보다 장황하고, 사람이 직접 쓸 때는 허용하지 않았을 코드량을 에이전트가 출력하도록 두는 점도 인정합니다. 따라서 이 숫자를 그대로 사업 성과나 제품 품질의 60배 증가로 해석하면 안 됩니다.

이어 그는 Ruby보다 더 좋아하게 된 프로그래밍 언어가 있다고 말합니다. 그것이 ‘영어’입니다.

그가 느끼는 장점은 다음과 같습니다.

• 원하는 동작과 아이디어를 풍부하게 표현할 수 있다.

• 문제와 목적을 자연스럽게 설명할 수 있다.

• 언어 문법과 구현 세부에 덜 묶인다.

• 결과를 만드는 과정 자체가 즐겁다.

동시에 자연어는 더 모호하고 결정적이지 않다는 점도 인정합니다.

그의 설명은 프로그래밍의 입력 방식이 코드에서 자연어로 넓어지고 있다는 의미입니다. 자연어만으로 모든 요구사항이 명확해진다는 주장은 아닙니다.

15. ‘프로그래머 은퇴’ 선언의 뜻: 직접 코드를 쓰는 직업에서 결과물을 만드는 직업으로 — 39:21~42:52

DHH는 자신이 전문 프로그래머에서 은퇴했다고 말합니다.

앞뒤 내용을 보면, 소프트웨어를 만드는 일을 그만뒀다는 의미보다 직접 코드를 작성하는 일을 주된 직업 활동으로 삼지 않게 됐다는 뜻에 가깝습니다.

그는 약 25년간 직접 코드를 작성한 경험을 매우 소중하게 평가합니다.

• 배우는 즐거움이 있었다.

• 몰입하는 경험이 있었다.

• 직접 구현하는 만족감이 있었다.

• 여러 사업과 프레임워크를 만들 수 있었다.

따라서 과거를 후회하거나 무의미했다고 생각하지 말라고 말합니다. 좋은 시대를 경험했다는 기쁨을 가지고, 다음 단계도 받아들이자는 것입니다.

그는 이어 매우 강한 전망을 제시합니다.

• 현재 대부분의 회사와 개발자에게 수작업 코딩은 경제적으로 생산적인 방식이 아니라고 본다.

• 연말에는 거의 모든 영역으로 이 변화가 확대될 것이라고 예상한다.

이 부분은 강연자의 전망이며, 강연 안에서 산업 전반의 자료로 입증되지는 않습니다. 회사별 규제, 시스템 특성, 도구 접근성, 검증 비용 등의 차이가 충분히 다뤄지지 않습니다.

그가 제안하는 새로운 정체성은 ‘전문적으로 무언가를 만드는 사람’입니다.

• 만들 문제를 선택한다.

• 원하는 결과를 정의한다.

• 에이전트의 지능을 지휘한다.

• 실제 결과를 평가한다.

• 제품을 개선한다.

천공카드 시대와 인터넷 시대도 언급하면서, 자신은 이번 변화가 컴퓨팅 역사에서 가장 큰 변화라고 평가합니다. 이는 기술사의 객관적 순위라기보다 자신이 느끼는 변화의 크기를 전달하는 표현입니다.

16. 아키텍처 재검토: 사람이 다루기 좋게 만든 구조가 에이전트에게도 최선일까 — 42:53~45:26

DHH는 개발 방식이 바뀌면 소프트웨어 아키텍처도 다시 생각해야 한다고 말합니다.

그가 특히 질문하는 것은 ‘추상화’와 ‘중복 제거’입니다.

기존에는 사람이 코드를 이해하고 변경해야 했습니다. 반복되는 내용을 한곳으로 모으고 공통 개념을 만들어 관리하는 것이 중요했습니다.

하지만 많은 에이전트가 동시에 시스템을 변경한다면 공통 추상화가 병목이 될 수 있다고 봅니다.

• 여러 작업이 공통 부분에 몰릴 수 있다.

• 하나를 바꾸면 여러 기능에 영향을 줄 수 있다.

• 병렬 작업 간 충돌이 생길 수 있다.

• 공유 구조를 이해하고 조율하는 비용이 생긴다.

반면 에이전트가 반복 코드를 만들고 여러 위치를 함께 수정하는 비용은 낮아질 수 있다는 주장입니다.

따라서 사람의 노동 비용을 줄이기 위해 선택했던 구조가, 에이전트의 병렬 작업에도 항상 최적이라고 볼 수는 없다는 것입니다.

다만 그는 새로운 정답을 제시하지 않습니다. 추상화를 전부 없애자는 구체적 설계안도 없습니다. 기존의 절충 관계가 달라졌으므로 다시 연구하고 실험해야 한다는 문제 제기입니다.

개발 방법론에 대해서도 같은 질문을 던집니다.

• 작업 주기는 얼마나 길어야 하는가?

• 누가 무엇을 명세해야 하는가?

• 사람과 에이전트는 어떻게 역할을 나눠야 하는가?

• 어떤 단위로 병렬 작업을 맡겨야 하는가?

그는 지금을 새로운 산업의 작업 방식을 만드는 출발점으로 봅니다.

17. 가장 구체적인 제품 제안: 앱마다 챗봇을 붙이기보다 사용자의 에이전트가 접근하게 하라 — 45:27~48:07

강연의 사업적 의미가 큰 부분입니다.

DHH는 각 서비스가 자기만의 AI 챗봇이나 상담 도우미를 넣는 방식에 회의적입니다.

사용자는 이미 자신이 쓰는 에이전트가 있을 수 있습니다. 그 에이전트가 여러 서비스를 연결해 일을 처리할 수 있다면, 서비스마다 다른 AI를 사용하는 것은 번거로울 수 있다는 것입니다.

그는 이를 비서에 비유합니다.

• 각 서비스가 제공하는 안내원보다,

• 자신이 데려온 개인 비서가,

• 여러 서비스를 오가며 일을 처리하기를 원한다는 것입니다.

그가 요구하는 구체적인 수단은 CLI, 즉 명령줄 인터페이스입니다. 에이전트가 사람이 화면을 누르는 방식에 의존하지 않고 서비스의 기능을 실행할 수 있게 해 달라는 뜻입니다.

원문에서는 “앱에 CLI가 없으면 다음 금요일까지 만들라”는 강한 표현까지 사용합니다. 정확한 일정 제안이라기보다 이 기능의 중요성을 강조하는 수사입니다.

그가 CLI를 통해 기대하는 변화는 다음과 같습니다.

• 사용자가 앱 화면을 직접 열지 않아도 작업할 수 있다.

• 여러 서비스의 작업을 하나의 에이전트가 연결할 수 있다.

• 서비스 내부의 검색이나 조작 방식을 에이전트가 보완할 수 있다.

• 제품의 기능을 사람이 사용하는 화면 밖으로 확장할 수 있다.

구체적인 예로 HEY 이메일 검색 경험을 소개합니다.

DHH는 오래전 이메일을 찾고 싶었지만 다음 정보가 거의 기억나지 않았습니다.

• 누구와 이야기했는지

• 어느 회사였는지

• 언제였는지

• 정확히 어떤 단어를 썼는지

기억나는 것은 운동화와 팟캐스트에 관한 이야기였다는 정도였습니다. 에이전트는 몇 분 후 해당 이메일을 찾아 줬다고 합니다.

그가 강조하는 변화는 정확한 키워드가 없어도 개념과 불완전한 기억을 가지고 정보를 찾을 수 있다는 경험입니다.

다만 자막에는 에이전트가 실제로 어떤 검색 절차를 사용했는지 나오지 않습니다. 특정 검색 기술의 성능을 입증하는 사례라기보다 사용자 경험의 변화에 관한 사례입니다.

18. Omarchy와 개인용 앱: ‘내가 불편한 것’을 직접 고칠 수 있는 범위가 넓어진다 — 48:08~53:55

DHH는 Omarchy를 통해 자신의 관심이 개별 앱을 넘어 컴퓨터 전체로 확장됐다고 말합니다.

핵심은 운영체제 자체의 소개보다 좋은 아이디어나 불편함이 있으면 직접 바꿀 수 있다는 감각입니다.

그는 Omarchy에 자신의 여러 아이디어를 구현했고, 이전에 사용했던 컴퓨터 환경보다 훨씬 만족스럽다고 평가합니다. 이 과정에서 약 2,000만 달러를 모았다고도 말합니다. 자금의 구체적인 성격은 자막에서 설명되지 않습니다.

설치 시간에 관한 사례도 소개합니다.

• 이전 발표에서는 전체 설치에 3분 33초가 걸렸다.

• 최근 특정 AMD 노트북에서는 35초가 걸렸다.

• 실험실에서는 9초까지 줄였다고 한다.

이 숫자는 하드웨어와 측정 조건이 다른 사례이므로 일반 사용자의 설치 시간을 보장하는 수치로 읽으면 안 됩니다.

그가 설치 속도에 집착하는 이유는 경제적 필요만으로 설명되지 않습니다. ‘탁월함을 추구하는 데 반드시 정당화가 필요한 것은 아니다’라는 취지의 말을 인용하며, 원해서 개선하는 일 자체가 가능해진 것을 즐깁니다.

이어 자신이 만든 작은 프로그램들을 소개합니다.

계산기는 프롬프트 후 약 7분 만에 결과를 얻었고, 약 15분 뒤 공개 저장소에 올렸다고 말합니다. 이후 이를 포함한 새 운영체제 설치 이미지를 만들었다고 합니다.

글쓰기 앱은 원하는 느낌을 맞추기 위해 더 많은 조정이 필요했지만, 생성된 코드를 직접 보지 않았다고 설명합니다.

이 사례의 의미는 자신이 이미 잘 아는 언어와 프레임워크 안에서만 제품을 만들어야 한다는 제약이 줄어들었다는 것입니다.

또한 모든 프로그램이 처음부터 대규모 사업일 필요도 없습니다. 개인의 취향, 특정 작업, 작은 불편을 해결하는 소프트웨어도 만들 가치가 생긴다는 관점입니다.

19. 또 하나의 변화: 개발 인건비 때문에 포기했던 최적화가 가능해진다 — 53:56~55:09

DHH는 지난 20년 동안 컴퓨터 성능이 좋아진 만큼 소프트웨어가 가벼워진 것은 아니라고 지적합니다.

그의 설명에서는 개발자 생산성을 높이는 도구가 늘어나는 동안, 앱은 커지고 느려지는 측면도 있었습니다. 그러나 당시에는 합리적인 선택이었을 수 있다고 인정합니다.

사람이 직접 최적화하는 비용이 높았기 때문입니다.

• 개발자 한 시간의 비용이 크다.

• 앱의 용량을 조금 줄이기 위해 많은 시간을 쓰기 어렵다.

• 성능을 높이는 일보다 기능 출시가 더 중요할 수 있다.

• 편리한 도구를 쓰는 편이 사업적으로 나을 수 있다.

하지만 에이전트가 최적화를 수행한다면 경제성이 달라질 수 있다고 봅니다.

• 밤새 성능 개선을 시도할 수 있다.

• 사람이 직접 작성하기 부담스러운 구현을 사용할 수 있다.

• 작은 프로그램에도 최적화 작업을 적용할 수 있다.

• 기능을 만드는 비용과 성능을 개선하는 비용을 함께 줄일 수 있다.

그는 Hype의 실행 파일이 약 0.5MB라고 강조하고, 원문상 약 1.2GB라는 Spotify 앱의 크기와 대비합니다.

다만 서로 다른 제품의 기능과 포함 범위가 설명되지 않으므로, 이 비교로 성능이나 품질의 우열을 판단하기는 어렵습니다. 그가 전달하는 핵심은 ‘이제 최적화를 포기할 이유가 줄었다’는 것입니다.

밤새 모델을 실행해 10배·30배 개선을 얻을 수 있다는 표현도 등장하지만, 모든 시스템에서 가능한 일반적 성능 보장으로 제시된 것은 아닙니다.

20. AI 위험과 고용 전망: 문제는 인정하되, 비관적 예측을 확정된 미래처럼 보지 말자 — 55:10~1:00:54

강연 후반에서 DHH는 AI에 대한 우려를 다룹니다.

그는 우려를 공개적으로 논의해야 한다고 말하면서도 일부가 과장됐다고 봅니다. 특히 보안 문제는 준비해야 할 실제 문제로 인정합니다.

그러나 대응 불가능한 운명처럼 받아들이지는 않습니다.

• 위험을 줄이는 기술을 만들 수 있다.

• 격리와 방어 장치를 마련할 수 있다.

• AI의 지능을 방어에도 활용할 수 있다.

• 개발자는 결과를 바꿀 수 있는 행동 능력을 갖고 있다.

그는 Rails에서 C 기반 이미지 라이브러리와 관련된 취약점이 있었고, 격리 방법과 HotCell 같은 대응 노력이 있다고 언급합니다. 자막에는 구체적인 취약점 번호나 방어 구조가 나오지 않습니다.

경제와 고용 전망에 대해서는 예측의 한계를 강조합니다. 가까운 미래의 주식시장도 정확히 예측하기 어려운데, AI라는 큰 변화 뒤의 사회를 단정하기는 더욱 어렵다는 논리입니다.

이를 설명하기 위해 ATM과 은행 창구 직원 사례를 듭니다.

• ATM이 직원의 일부 업무를 자동화했다.

• 그러나 지점 운영 비용이 낮아져 더 많은 지점을 열 수 있었다.

• 직원의 업무가 다른 서비스와 판매로 이동했다.

• 자동화된 업무의 감소가 전체 고용 감소로 곧바로 이어지지 않을 수 있다는 것이다.

여기서 원문에 등장하는 ATM 도입 연도와 직원 수는 검증 없이 재사용하기에 주의가 필요한 내용입니다. 강연이 설명하려는 경제적 구조와 해당 역사적 숫자의 정확성은 분리해야 합니다.

그는 이 논리를 제번스의 역설과 연결합니다. 효율 향상으로 비용이 낮아지면 수요가 늘어, 총사용량이 오히려 증가할 수 있다는 취지입니다.

소프트웨어에 적용하면 개발 단가가 낮아지는 동시에 소프트웨어 수요가 늘 수 있다는 전망입니다. 다만 이것이 기존 개발자의 고용과 임금이 모두 유지된다는 보장은 아닙니다.

오펜하이머와 트루먼, 원자폭탄과 원자력에 관한 비유도 사용합니다. 전문 연구자가 기술을 잘 이해한다고 해서 사회적 결과까지 정확히 예측하는 것은 아니라는 주장입니다.

이 대목은 역사적·윤리적 평가가 강하게 들어간 수사입니다. 강연에서는 직접 충돌의 억제와 원자력의 효용을 강조하지만, 핵무기와 냉전의 다른 피해와 위험을 균형 있게 분석하지는 않습니다.

21. 마지막 메시지: 파멸 가능성보다 번영 가능성에 참여하자 — 58:30~1:02:55

DHH는 P(doom), 즉 파멸의 가능성에 집중하는 태도보다 P(bloom), 번영과 개화의 가능성에 주목하자고 말합니다.

그가 기대하는 것은 다음과 같습니다.

• 소프트웨어 생산 비용의 감소

• 더 많은 사람이 만드는 일에 참여

• 개인의 아이디어를 실현할 기회 확대

• 더 빠르고 효율적인 프로그램

• 기존에 접근하기 어려웠던 기술의 활용

• 불편한 도구와 작업 방식의 개선

그는 이를 종교개혁에도 비유합니다. 에이전트가 전문가 집단을 거쳐야만 컴퓨터에 일을 시킬 수 있던 구조를 바꿀 수 있다는 것입니다.

개발자에게는 경쟁이 늘어나는 일이 두려울 수 있지만, 기존의 지식과 경험을 가지고 새로운 도구를 활용하면 더 잘 만들 수 있다고 격려합니다.

마지막에는 어린이가 Omarchy를 사용하는 사례를 보여 주며 세대 차이를 언급합니다. 다음 세대는 기존 방식에 대한 집착과 버려야 할 습관이 적어, 변화를 자연스럽게 받아들일 수 있다는 관점입니다.

‘낙관의 약을 먹으라’, ‘미래를 적극적으로 받아들이라’는 표현으로 강연을 마칩니다.

다만 그가 말하는 “미래를 모르므로 낙관하는 것이 유일하게 합리적이다”라는 주장은 엄밀한 위험 분석이나 게임이론의 입증보다 청중을 움직이려는 태도 선언에 가깝습니다. 낙관적 참여와 구체적인 위험 관리는 함께 할 수 있습니다.

22. 이 강연에서 구분해 읽어야 할 내용

강연은 실제 경험, 현재 진행 중인 실험, 미래 예측, 개인적 취향이 빠르게 섞여 있습니다. 의사결정에 활용하려면 다음과 같이 나누는 편이 정확합니다.

또한 강연 안에는 몇 가지 긴장이 있습니다.

• 미래는 예측하기 어렵다고 하면서, 수작업 코딩의 종말은 매우 확신합니다. 예측의 불확실성을 양쪽 주장에 똑같이 적용할 필요가 있습니다.

• 코드를 보지 않는 즐거움을 강조하면서, 보안 문제에 대한 대응도 요구합니다. 결과를 검증할 책임과 그 방법은 별도로 설계해야 합니다.

• Basecamp에서 전체 구조가 망가진 경험을 소개하면서, 모델 발전으로 이를 극복할 수 있다고 봅니다. 강연에는 실제로 구조 문제가 어느 수준까지 해결됐는지 보여 주는 자료가 없습니다.

• 비용이 낮아지면 수요가 늘 수 있다고 주장하지만, 고용의 분배 문제는 깊게 다루지 않습니다. 시장 전체의 성장과 개별 개발자의 경력 안정은 같은 문제가 아닙니다.

• 네이티브 앱의 가능성을 강조하면서 웹의 강점도 인정합니다. 따라서 강연을 모든 웹서비스를 네이티브로 전환하라는 주장으로 읽으면 내용이 왜곡됩니다.