핵심 요약

  • DHH는 AI가 코드를 보완하던 단계에서 문제를 듣고 구현 방향까지 제안하는 단계로 바뀌었다고 평가했다. 이는 자신이 작업하는 영역에서의 경험에 근거한 판단이다.
  • 리눅스 배포판 Omarchy의 Quattro 버전에 들어간 새 코드는 직접 작성하지 않았다고 밝혔다. 다만 전체 구조와 중요한 부분의 코드 줄은 검토했다.
  • 기존 제품 Basecamp에서는 AI가 만든 변경 사항을 쌓는 과정에서 설계 구조가 흐트러져 사람이 다시 정리해야 했다.
  • DHH는 구현이 빨라져도 팀의 의사소통, 제품 구상, 무엇을 채택할지에 대한 판단은 여전히 병목이 될 수 있다고 봤다.

코드 보조에서 문제 해결로

DHH는 1년 전까지 AI를 주로 자동완성 도구나 대화형 조언자로 사용했다. 작업 방식이 달라진 계기로는 2025년 11월에 사용해 본 Opus 4.5를 꼽았다. 결과물이 자신이 작성했을 법한 코드에 가까웠고, 도구를 사용하고 작업 결과를 확인하는 능력도 좋아졌다는 설명이다. 이후 작업을 나눠 여러 에이전트가 처리하면서 속도가 더 빨라졌다고 말했다.

그가 체감한 최근 변화는 역할의 이동이다. 이전에는 자신이 목표와 경로를 정하고 결과를 검토해야 했다면, 이제는 모호한 문제를 제시해도 에이전트가 방향과 방법을 제안한다는 것이다. 다만 그는 이 신뢰가 현재 자신이 작업하는 영역에 관한 것이라고 한정했다. 대담 진행자 렉스 프리드먼도 사용자용 웹 앱과 안전이 중요한 시스템은 검토 수준이 다를 수 있다고 짚었다.

Omarchy와 Basecamp가 보여준 차이

DHH는 Omarchy Quattro 작업의 마지막 두 달 동안 새 기능의 코드를 손으로 작성하지 않았다고 밝혔다. 전체적인 형태와 시스템의 중요한 부분은 살폈지만, 일부 사용자 인터페이스와 보조 코드의 개별 줄은 보지 않았다고 했다. AI가 코드를 전부 작성했다는 말과 사람이 제품 판단에서 빠졌다는 말은 같지 않다.

기존 제품에서는 다른 결과가 나왔다. DHH에 따르면 37signals는 Basecamp 5 개발 중 디자이너들이 원하는 기능을 AI로 구현하도록 했다. 개별 변경 제안은 그때그때 받아들일 만했지만, 누적되자 시스템의 설계 구조가 흐트러졌다. 결국 사람이 직접 정리했다. 그는 이미 규모가 있는 코드베이스의 구조를 유지하는 일에는 당시 프로그래밍 경험이 중요했다고 설명하면서도, 그 경험은 올해 2월의 작업에 관한 것이며 이후 도구가 달라졌다고 덧붙였다.

구현 능력이 늘어도 제품은 저절로 좋아지지 않는다

DHH는 기존 소프트웨어의 기능 출시가 AI 도입만큼 빨라지지 않는 이유로 팀의 의사소통을 들었다. 제품 관리자와 디자이너, 여러 승인 단계가 함께 움직이는 조직에서는 코드 작성이 전체 작업의 작은 부분일 수 있다는 것이다. 무엇을 만들지에 대한 구상과 취향이 부족하다면 구현 능력만 늘어도 좋은 제품이 나오지는 않는다고 주장했다.

개인용 도구는 다른 가능성을 보여줬다. DHH는 리눅스에서 쓰던 글쓰기 앱 Typora의 기능 중 자신에게 필요한 일부만 원했다. 에이전트에 C++와 Qt로 새 앱을 만들도록 맡겼고, 약 20분 뒤 첫 버전을 받았다고 회고했다. 처음부터 만족스럽지는 않았지만 수정 끝에 이틀 안에 Typora를 대신해 사용하기 시작했다. 이는 범용 앱을 통째로 대체한 사례가 아니라 한 사람이 필요한 기능을 좁혀 만든 사례다.

오픈소스에서는 검토 방식도 바뀌었다

DHH는 Omarchy Quattro 개발 석 달 동안 1,000건이 넘는 풀 리퀘스트, 즉 코드 변경 제안을 병합했다고 말했다. 전통적인 의미의 프로그래머가 아니거나 리눅스 배포판 개발 경험이 없는 사람도 AI를 통해 아이디어를 구현해 기여했다고 설명했다. 동시에 미병합 제안도 약 400건에 이르렀다고 밝혔다.

그는 들어온 제안을 모두 직접 읽는 대신 에이전트가 중복되거나 부적절한 변경을 걸러내고 버그 수정을 가상 머신에서 확인하게 한다고 했다. 최종적으로 병합할지는 사람이 결정한다. AI가 기여 문턱을 낮추는 만큼, 프로젝트의 방향에 맞는 제안을 고르는 일도 커진 셈이다.

코드의 품질과 개발자의 역할

DHH는 오랫동안 정돈된 코드가 작은 팀의 수정 비용과 오류를 줄인다고 봤다. AI가 코드를 바꾸는 시대에도 그 가치가 완전히 사라졌다고 말하지는 않았다. 현재는 에이전트가 쓸 수 있는 토큰에 한계가 있으므로, 이해하고 수정하기 쉬운 구조가 작업 비용을 낮춘다는 것이다. Basecamp에서 겪은 설계 문제도 변경을 계속 쌓을 때 생기는 위험을 보여준다.

대신 그는 개발자의 일이 코드를 직접 쓰는 데만 머물지는 않는다고 봤다. 에이전트에게 방법을 지나치게 지정하기보다 작은 결과물을 먼저 만들고 실제로 써 보면서 원하는 바를 구체화한다는 설명이다. 다만 일자리 전망에 대해서는 단정하지 않았다. 프로그램 제작 비용이 낮아져 수요가 늘 가능성을 언급하면서도, 같은 일을 더 적은 인원으로 처리하는 영역에서는 실직의 어려움이 생길 수 있다고 인정했다.

DHH의 경험은 AI가 구현 범위를 넓혔다는 사례와 기존 제품의 구조를 해칠 수 있다는 사례를 함께 담고 있다. 대담에서 반복된 판단 기준은 생성된 코드의 양이 아니라, 결과물이 필요한 문제를 풀고 이후에도 고칠 수 있는 형태인지였다.