◆ ESSAY
10년쯤 전 카카오에서 일할 때는 서버 대부분이 Ruby on Rails(이하 Rails)로 돌아갔다. 내가 입사하기 전부터 쓰던 기술이었다. 주니어였던 나는 왜 Rails를 골랐는지까지는 생각하지 않았다. 주변에서 장점을 설명해 주면 그런가 보다 했고, 우리도 그걸 살려서 일하고 있다는 정도만 어렴풋이 알았다.
개발하기도 좋았고 쓰기도 편했다. 지금이라면 온갖 미사여구를 붙여 가며 장점을 설명할 수 있겠지만, 그 시절에는 뭐가 좋으냐고 물으면 제대로 답하지 못했을 것 같다. 좋다는 건 알았지만 왜 좋은지는 몰랐다.
한참 뒤에 뜻밖의 자리에서 그 이유를 다시 생각하게 됐다. 2026년 9월 23일, Rails를 만든 DHH(David Heinemeier Hansson)가 Rails World 오프닝 키노트에 나와 손으로 코드를 쓰는 일을 그만뒀다고 했다. 그 말을 듣고 나서야 내가 Rails에서 무엇을 얻었는지 조금 알 것 같았다.
키노트 이야기를 하기 전에 DHH와 Rails, 그리고 RailsConf와 Rails World부터 조금 짚고 가려 한다.
Rails World 이전에는 RailsConf가 있었다. Ruby 커뮤니티의 비영리 단체 Ruby Central이 주관하던 행사로, 2006년 시카고에서 처음 열렸다. 오프닝 키노트는 오랫동안 DHH가 맡았다. Rails를 만든 사람이 앞으로의 방향을 이야기하며 행사를 여는 게 관례였다.
2022년에는 달랐다. RailsConf 프로그램 위원회는 DHH에게 "지난 1년 동안 대부분 오프라인이었으니, 오프닝 키노트 무대를 다른 기여자들과 나누는 것이 커뮤니티에 가치 있겠다고 판단했다"는 이메일을 보냈다. DHH는 No RailsConf에 이 이메일을 그대로 싣고 반발했다. 정치와 이념 때문에 갈라져 이제는 컨퍼런스에서 Rails를 좋아하는 마음조차 나누지 못하느냐는 것이었다. 여기서 "지난 1년"은 Basecamp 사태가 있었던 2021년을 가리킨다. 그 일은 조금 뒤에 적겠다.
같은 해 11월, Rails Foundation이 출범했다. 37signals, Shopify, GitHub 등 여덟 곳이 창립 멤버로 참여해 100만 달러를 모았다. 문서화와 교육, 마케팅, 행사로 Rails 생태계를 돕겠다는 재단이었다. 이듬해부터는 Rails World를 열었다.
2023년 암스테르담에서 열린 첫 Rails World의 티켓 650장은 45분도 안 돼 매진됐다. 2024년 토론토에는 57개국에서 1,000명 넘게 왔다. 2025년에는 다시 암스테르담으로 갔고, 2026년에는 미국 오스틴에서 열렸다.
그 사이 RailsConf는 끝났다. Ruby Central은 행사를 한 해에 하나로 줄이고 RubyGems 같은 오픈소스 인프라에 더 투자하겠다며 종료를 알렸다. 2025년 7월 필라델피아에서 열린 대회가 마지막 RailsConf였다. 주제는 "Rails의 과거, 현재, 미래"였고 DHH와의 대담(fireside chat)도 예정돼 있었다. Rails라는 이름을 건 대표 행사는 이제 Rails World가 됐다.
Rails World에서도 오프닝 키노트는 DHH의 몫이었다. 2023년에는 "One Person Framework"를 위한 도구 일곱 가지를 공개했다. Kamal 1.0, Solid Cache, Solid Queue 등이었고, 같은 날 Rails 7.1도 나왔다. 2024년에는 Rails 8 베타, 2025년에는 Rails 8.1 베타와 새 기능을 발표했다. 2025년에는 Arch Linux와 Hyprland로 꾸린 자기 개발 환경 Omarchy를 노트북에 설치한 뒤 곧바로 Rails 앱을 띄우기도 했다. 새 버전이든 도구든, Rails로 무엇을 더 할 수 있는지 보여 주던 자리였다.
2026년 세션 페이지의 소개도 "Rails의 새로운 것, 다음에 올 것, 그리고 Rails가 앞으로 향할 방향을 짚는 오프닝 키노트"였다. AI와 Ruby, Rails의 미래를 다루는 시간은 따로 있었다. 다음 날 Ruby를 만든 마츠(Matz, 마츠모토 유키히로)와 DHH가 대담을 하기로 돼 있었다.
DHH가 Rails를 공개한 건 2004년이다. Basecamp를 만들다가 그 안에서 프레임워크를 뽑아냈다. 지금도 Basecamp와 HEY를 만드는 37signals의 공동 소유주이자 CTO로 일한다. Rails에 어떤 생각을 담았는지는 The Rails Doctrine에 적혀 있다. 아홉 가지 원칙 중 맨 앞에 놓인 건 "프로그래머의 행복을 최적화하라"다. "설정보다 관례(Convention over Configuration)", "메뉴는 오마카세", "아름다운 코드를 떠받들라", "큰 텐트를 세워라" 같은 원칙이 뒤따른다.
주니어 때 들었던 Rails의 장점도 여기에서 비롯되었을 것이다. 관례를 따르면 사람마다 코드 구조가 크게 달라지지 않고, 적게 써도 꽤 많은 일을 할 수 있다. 작은 팀이 웹 서비스를 빨리 만들어 운영하기에도 좋다. "One Person Framework"라는 말에는 아예 한 사람이 웹 애플리케이션 전체를 만들고 운영하게 하겠다는 뜻이 담겨 있다.
그런 생각을 꾸준히 이야기해 온 사람이지만, 그만큼 논란도 많았다.
2014년의 TDD is dead. Long live testing.이 한 예다. "나는 테스트를 먼저 작성하지 않는다"고 밝히고, 테스트 우선 개발(TDD)을 도덕처럼 강요하는 분위기를 비판했다. 켄트 벡(Kent Beck), 마틴 파울러(Martin Fowler)와의 공개 대담으로 이어질 만큼 큰 논쟁이었다.
2020년에는 Apple과 부딪쳤다. HEY의 iOS 앱 업데이트가 거절됐는데, 앱을 받아도 바로 쓸 수 없고 앱 안에서 결제도 할 수 없다는 이유였다. 공개적으로 맞선 끝에 앱에서 14일짜리 무료 임시 주소를 발급하는 것으로 타협했다. 2022년에는 "꾸준히 성장하는 중간 규모 회사에게 컴퓨터를 빌려 쓰는 건 대체로 손해"라며 클라우드를 떠나겠다고 했다. 2023년에는 Turbo에서 TypeScript를 걷어내는 PR을 올라온 날 바로 병합했다. 기여자들은 사전에 논의도 없었다며 반발했다.
이런 주장을 다 받아들이기는 어려워도 무엇을 중요하게 여기는지는 알 만했다. 단순하게 만들고, 대형 플랫폼에 덜 기대고, 사람이 즐겁게 읽고 쓸 수 있는 코드를 남기는 것. 동의 여부와 별개로 다음에는 무슨 말을 할지 대강 짐작되는 사람이었다고 생각한다.
기술 이야기만으로 끝나지는 않았다. 2021년 Basecamp(지금의 37signals)에서는 직원들이 회사를 떠나는 일이 있었다. 이 회사 고객 지원 직원들은 2009년 무렵부터 '웃긴' 고객 이름을 모아 왔고, 그 목록에는 아시아계와 아프리카계 이름도 들어 있었다. 2021년 4월, 예전에 이름을 보탰던 직원 두 명이 사내 Basecamp에 사과 글을 올렸다. 토론은 이 웃긴 이름 목록에 관한 문제에서 회사의 다양성과 포용 문제로 번졌다(Platformer).
4월 26일 CEO 제이슨 프라이드(Jason Fried)는 여섯 가지 방침을 발표했다. 첫 번째가 사내 Basecamp 계정에서 "사회적, 정치적 논의를 더는 하지 않는다"는 것이었다. 직원들이 주도하던 다양성과 포용(DEI) 위원회도 해산하기로 했다. DHH는 같은 날 자신의 글로 이를 옹호했다. 민감한 사회 문제를 회사에서 이야기해 봐야 갈등만 생길 뿐 누구의 생각도 바뀌지 않는다는 주장이었다.
반대하는 직원들이 받아들인 뜻은 달랐다. 회사 안에서 생긴 일을 문제 삼았는데 그것까지 "정치 이야기"로 묶어 막는다고 본 것이다. 직원 약 57명 중 3분의 1 정도가 회사에서 제안한 퇴직 보상을 받고 떠났다.
2025년 9월 15일에는 As I Remember London이 올라왔다. DHH는 "2000년에는 런던 인구의 60% 이상이 토박이 영국인(native Brits)이었는데 2024년에는 약 3분의 1로 줄었다"고 썼다. 나머지 지역만큼은 "지난 20년 동안 런던에 닥친 것과 같은 인구 대체(demographic replacement)"에 내줄 수 없다는 정서도 전했다. 비판하는 쪽에서는 "토박이 영국인"이 사실상 백인을 뜻한다며 인종차별적인 글이라고 지적했다(Jake Lazaroff). 이로 인해 Rails 코어 팀과 Ruby 커뮤니티에 보낸 공개서한도 나왔다. 이 글을 근거로 "DHH와 그의 작업과 관계를 끊을 것", "Rails를 새 이름으로 하드 포크할 것", "현대적인 행동 강령을 채택할 것"을 요구했고, 300명 넘게 서명했다. 옹호하는 쪽에서는 "토박이"가 인종이 아닌 혈통과 출신을 가리킨다며 글을 지나치게 나쁘게 해석한 비판이라고 반박했다(Felipe Contreras).
2026년 7월 21일에는 Wolves, sheep, and gypsies를 썼다. 덴마크에서 늑대가 늘어 가축을 해치는 일과, 코펜하겐 공원에서 노숙을 허용한 뒤 야영지가 생긴 일을 나란히 놓은 글이다. 둘 다 이념 때문에 방치한다고 주장하며 "늑대가 통제를 벗어나면 쏜다. 집시가 공공장소를 차지하면 추방한다"는 말로 끝냈다. 집시(gypsy)는 로마인(Roma)을 가리키는 말로, 멸칭으로 여겨지기도 한다. 엿새 뒤에는 I'm sorry, Dave가 올라왔다. 앞의 글을 이탈리아어로 번역해 달라고 했더니 Claude가 "민족 집단을 비인간화한다"며 거절했다는 내용이었다. DHH는 AI 회사가 안전을 내세워 말할 수 있는 범위를 정하는 일을 경계했고, 그래서 오픈 웨이트 모델이 필요하다고 썼다. 비판하는 쪽은 번역 거절을 검열의 문제로 돌리면서 정작 로마인을 추방하자는 발언은 가려졌다고 반박했다(Kitzy).
이런 논란을 어떻게 받아들일지는 사람마다 다를 것이다. 여기서 그 판단까지 하려는 건 아니다. 이어지는 키노트 이야기는 그날 무대에서 나온 말을 놓고 썼다.
63분짜리 키노트의 첫머리에서 DHH는 자기 상태를 이야기했다. 누군가는 AI 정신병(AI psychosis)이라고 하겠지만 자기는 AI 섬망(delirium), AI 도취(euphoria) 쪽이 더 좋다는 것이었다. 그 뒤로 9분 가까이 사진의 역사를 설명했다. 사진이 등장하면서 초상화가들이 인상주의와 입체파로 옮겨 갔다는 이야기였다.
그에게 2025년 11월 24일, Opus 4.5가 나온 날은 "우리 시대의 코닥 브라우니"였다. 코닥 브라우니는 1900년에 나와 사진을 대중화한 보급형 카메라다. 브라우니가 사진의 문턱을 낮췄듯, Opus 4.5도 더 많은 사람이 소프트웨어를 만들 수 있게 한 전환점으로 봤다는 뜻이다. 그렇다고 줄곧 AI에 만족한 건 아니었다고 한다. 2026년 2월부터 5월까지는 실망했지만, 6월에 Fable 5와 Mythos를 쓰고 확신하게 됐다고 했다.
37signals에서는 몇 주 전 손으로 코드를 쓰는 일을 그만두기로 했다. 이제 손코딩은 Sentry(에러 추적 서비스)에 뜬 버그와 같은 예외 상황이라고 했다. 누군가 손으로 코드를 쓰고 있다면 에이전트가 제 몫을 못 했다는 신호로 보고, 에이전트 쪽을 고친다는 것이다. 아직 매주 상당한 양의 코드를 손으로 쓰는 사람이 있느냐고 청중에게 묻기도 했다. 손을 든 사람은 다섯 명 남짓이었다.
HEY도 웹앱에서 벗어난다고 했다. 일주일 전부터 여섯 개의 네이티브 앱을 만들기 시작했고, 백엔드는 Rust로 다시 쓴다는 것이다. CPU 사용량은 99%, 메모리는 95% 줄어든다고 했다. 대략 계산해 보면 HEY의 최대 트래픽도 라즈베리 파이 한 대로 감당할 것 같다는 말까지 나왔다. Rust는 "지난 40년 동안 나온 가장 못생긴 언어"라면서도 직접 볼 일이 없다면 훌륭하다고 했다. 자기가 Rust를 전혀 모른다는 것도 장점으로 꼽았다.
Rails 얘기가 아예 없지는 않았다. 설치까지 하지는 않을 사용자를 만나기에는 여전히 웹이 좋고, 설정보다 관례를 따르는 방식은 에이전트의 토큰도 아껴 준다고 했다. 그런데 곧 올해 자기 작업에서 Ruby가 차지한 비중은 3% 정도라는 말로 넘어갔다. 8월 한 달에 15만 줄을 썼고, Ruby보다 좋아하는 프로그래밍 언어도 생겼다고 했다. 그 언어는 바로 영어였다. 그러니까, 프로그래밍 언어로 직접 코딩하는 것보다 자연어로 요청하는 것이 더 즐겁다는 말이었다. 3월쯤에는 이미 전업 프로그래머에서 은퇴했다고 밝혔다.
뒤로 갈수록 그의 말의 세기가 더 커졌다. 손코딩은 대부분의 회사에서 이미 경제성이 없고, 올해 말에는 사실상 모든 영역의 모든 프로그래머와 회사가 그렇게 될 것이라고 했다. 추상화도 에이전트 시대에는 예전만큼 의미가 없다고 했다. CLI가 없는 앱이라면 다음 주 금요일까지 CLI를 만들라는 요구도 나왔다.
Omarchy에는 약 2,000만 달러가 모였고 설치 시간은 35초로 줄었다고 했다. 에이전트로 만든 계산기, 글쓰기 앱, 영상 편집기와 발표 도구 이야기도 이어졌다. 끝나기 몇 분 전부터는 AI를 걱정하는 사람들에게 답했다. 보안은 대비하면 되고, 경제학자들은 어차피 미래를 맞히지 못한다는 것이다. 파국의 확률을 뜻하는 P(doom) 대신 P(bloom)을 택하라고 했다. 마지막은 "black pill은 루저의 것이다. 루저가 되지 마라"였다. black pill은 온라인에서 체념적인 비관을 뜻하는 속어다.
이 컨퍼런스가 있었던 직후 커뮤니티에서 내가 본 반응 중에는 비판이 더 많았다. 영상이 올라온 Hacker News(이하 HN) 스레드에는 Rails 컨퍼런스에서 왜 Rails 이야기를 안 하느냐는 불만이 눈에 띄었고, 수백만 달러가 있으니 낙관하기 쉽다는 말도 있었다. Global Nerdy는 YouTube에 달린 "내가 겪어 본 가장 혼란스러운 장례식"이라는 댓글을 제목으로 골랐다.
다들 그렇게 본 건 아니다. 현장에 있던 한 사람은 분위기가 비관과는 거리가 멀었다고 전했다. Rails에는 필요한 것이 거의 다 갖춰져 있으니 에이전트와 일할 때 오히려 빠르다는 의견도 있었다.
나도 매일 코딩 에이전트를 쓴다. AI 덕에 개발 생산성이 달라졌다는 말에는 동의한다. 이번 키노트에도 고개를 끄덕일 만한 얘기는 있었다. 특히 앱마다 챗봇을 욱여넣지 말고 CLI를 열어 사용자가 자기 에이전트를 데려오게 하라는 제안이 실용적이었다. 채팅창 앞에 앉아 기다리는 대신 동료에게 맡기듯 비동기로 일을 맡기라는 말도 요즘 업계에서 하는 시도와 비슷했다.
네이티브 앱이나 저수준 언어로 다시 쓰는 데 드는 비용이 크게 줄었다는 관찰도, 내가 웹 개발자인 것을 감안하고 보더라도 대체로 맞다고 본다. 그러니 그가 왜 그렇게 들떴는지는 이해한다. 그럼에도 발표를 듣는 내내 불편한 대목이 있었다.
이게 Rails World의 오프닝 키노트였다는 사실부터 걸린다. Rails의 새 기능과 앞으로 갈 방향을 소개하는 자리였고, AI를 이야기할 시간은 다음 날 따로 있었다. 63분 중 Rails의 자리를 다룬 건 3분 남짓이었다. 그때 나온 첫 답마저 "HEY의 답은 네이티브와 Rust"였다. 새 기능도 로드맵도 없었다. Rails를 만든 사람이 공동체의 무대에 서서 자신은 다른 길로 간다고 알린 셈이다.
말투는 더 불편했다. 연구실에서 무서운 것을 봤다는 연구자들을 오펜하이머에 빗댄 뒤, 그를 다시는 보고 싶지 않다던 트루먼이 옳았다고 했다. 마지막에는 "black pill은 루저의 것"이라고 했다. 바로 앞에서는 청중을 "best of the best"라고 불렀으니 청중 모두를 루저라고 한 것은 아니다. 그렇지만 걱정하는 사람을 루저로 만드는 말인 건 마찬가지다. 그 걱정에 근거가 있는지보다 어떤 태도를 가졌는지를 따지는 말로 들렸다.
에이전트가 가져올 변화를 "컴퓨터의 종교개혁"이라고도 했다. 에이전트는 성직자 계급을 무너뜨릴 "Agent Luther"였다. 기술 얘기를 듣고 있었는데, 어느 순간부터 무언가를 믿게 된 사람의 말을 듣는 기분이었다.
"앱에 CLI가 없으면 다음 주 금요일까지 보여 달라. 변명은 없다. 토큰은 있지 않느냐. 가능하다고 말했으니, 그걸 내놓는 건 여러분의 의무다"라는 요구도 있었다. 농담이 절반쯤 섞였을 것이다. 그래도 동료에게 하는 말보다는 고용주가 하는 말에 가까웠다. 예측이 나중에 다 맞더라도 이 무대에서 그렇게 말한 일까지 적절해지는 건 아니라고 생각한다.
특히 납득하기 어려웠던 건 확신의 차이였다. 남의 비관적인 전망에는 "아무도 미래를 모른다"고 했다. 자기 낙관에도 그 말을 똑같이 적용했으면 모르겠는데, 그렇지는 않았다.
| 비관론에 댄 잣대 | 낙관론에 댄 잣대 |
|---|---|
| "경제학자는 6개월 뒤 주가도 못 맞힌다. 사회가 어떻게 될지 그들은 모른다" | "올해 말이면 사실상 모든 프로그래머, 모든 회사에서 손코딩이 끝난다" |
| "미래 예측에는 조금 겸손할 필요가 있다" | 20초 뒤, "풍요와 기쁨에 이를 가능성이 파멸보다 압도적으로 크다" |
| "아무도 미래를 모른다. 그러니 행복해하는 것이 합리적이다" | 30초 뒤, "유토피아가 거의 왔다. 우리는 그걸 얻게 된다" |
낙관하는 쪽에서도 "모른다"는 말이 나오긴 한다. 하지만 무엇을 네이티브로 만들지, 일하는 방식과 아키텍처를 어떻게 바꿀지 같은 "어떻게"만 불확실했다. "좋아질 것인가"를 두고는 망설이지 않았다. 도구가 개발 속도를 얼마나 높일지 "정확히는 모른다"고 해 놓고도, 1분이 채 지나기 전에 최악과 최고의 격차가 1,000배라는 말에 "그쯤 되겠다"고 했다.
올봄 Basecamp 5를 마무리하던 때의 경험도 이야기했다. 디자이너들에게 바이브 코딩(vibe coding, 코드를 직접 보지 않고 AI에게 말로 시켜 만드는 방식)으로 기능을 맡겼는데, PR을 따로 보면 그럴듯해도 합쳐 놓으니 아키텍처가 스위스 치즈처럼 구멍투성이였다고 한다. 여기까지 들으면 적어도 무엇이 잘못됐는지 따져 볼 만한 실패다.
그런데 DHH가 잘못됐다고 한 건 "아직 기술이 준비되지 않았다"는 당시의 결론이었다. 조금만 더 기다렸다면 Fable이 나와서 아마 원하는 대로 됐을 거라는 것이다. 실패할 때는 다음 모델을 기다리면 되고, 성공하면 AI가 옳았다는 증거가 된다. 그렇게 보면 어떤 결과가 나와도 믿음을 거둘 이유가 없어진다.
트루먼 이야기도 나는 다르게 받아들였다. DHH의 설명은 원자폭탄을 만든 오펜하이머가 걱정했지만 트루먼은 그를 내쳤고, 결국 세상이 멸망하지 않았으니 걱정하던 쪽이 틀렸다는 얘기였다.
세상이 멸망하지 않은 데에는 걱정한 사람들도 기여했을 수 있다. 쿠바 미사일 위기 뒤 미국과 소련 정상을 바로 잇는 핫라인이 생겼고, 핵실험과 핵무기를 제한하는 조약들도 이어졌다. 위험하다고 생각해서 대비한 덕에 파국을 피했을 가능성은 왜 빼는지 모르겠다.
(나이 든) 개발자라면 Y2K가 더 익숙할 것이다. 많은 사람이 미리 고쳐 놓아 큰 사고 없이 지나갔더니, 나중에는 괜한 호들갑이었다는 말이 나왔다. 대비가 잘될수록 걱정이 쓸데없던 것처럼 보이는 현상을 대비의 역설(preparedness paradox)이라고 부른다. "아무 일도 없었으니 걱정할 필요가 없었다"고 말하기 전에, 아무 일도 없게 하려고 무엇을 했는지도 봐야 하지 않을까.
발표를 보면서는 AI에 구현뿐 아니라 판단까지 맡겼다는 느낌도 받았다. 특정 회사에 의존한다는 뜻은 아니다. 오히려 Anthropic이 최전선 모델을 독점할까 하는 걱정을 GPT-6 Astra가 덜어 줬다고 반겼다. DeepSeek 덕에 최전선 모델이 미국 대기업만의 것은 아니라는 점도 드러났다고 했다. 오픈 웨이트 모델을 지지한다는 것도 앞에서 봤다.
걸리는 건 무엇을 중요한 질문으로 보느냐였다. "지금 소프트웨어 개발에서 진지한 질문은 하나뿐이다. 이 지능의 폭발에서 어떻게 최대한을 끌어낼 것인가. 다른 모든 질문은 가치의 우선순위에서 그 아래에 있다"고 했다. Rust를 전혀 모른다는 것은 "특권"이었다. 직접 만든 C++ 글쓰기 앱은 코드를 한 줄도 보지 않았고, 에이전트가 5년 전 메일을 어떻게 찾았는지도 "아직도 잘 모르고 묻기도 조금 무섭지만 무한히 기쁘다"고 했다.
보안에는 대비하자고 한다. 기술로 대응할 수 있는 문제이니 "뭔가 온다, 대비하자", "정당한 문제라면 기술을 발명하면 된다"는 것이다. 일자리나 사회에 대한 걱정으로 넘어가면 답은 "아무도 모른다, 그러니 행복하라"가 된다. AI로 풀 수 있을 때만 대비가 합리적이고, 나머지는 우울한 태도쯤으로 보는 것 같았다. 그가 "순수한 게임 이론"이라 부른 논리도 걱정과 슬픔을 같은 것으로 봐야 성립한다. 보안을 걱정하면서 대비하는 자기 모습은 그 계산에 들어가지 않는지 의문이었다.
7월에 쓴 프론트엔드는 어디서 왔고, 에이전트 이후 어디로 가는가에서도 비슷한 문제를 생각했다. 나는 에이전트가 대부분의 코드를 쓰더라도 사람은 자기가 읽을 수 있는 익숙한 스택을 고를 가능성이 높다고 썼다. 배포를 승인하는 사람, 장애가 나면 불려 나오는 사람은 그대로이기 때문이다. 무엇을 배포하는지 확인하려면 읽을 수 있어야 한다고 봤다.
DHH는 정반대의 선택을 했다. 전혀 모르는 Rust를 고르고, "프로그래머에게 일을 맡겨 온 사업주"처럼 결과물을 바깥에서 블랙박스로 평가하겠다고 한다. 사실 그 가능성은 내 글에도 단서로 적어 뒀다. 검수가 코드를 읽는 일에서 동작을 확인하는 일로 옮겨 갈 수 있다는 것. DHH가 하겠다는 일이 바로 그것이다.
그가 회사의 주인이라는 점은 생각할 필요가 있다. 나는 그 글에서 검수 책임이 조직과 법에 묶여 있다고 썼다. 회사의 주인이라면 그 책임을 스스로 지겠다고 결정할 수 있지만, 승인 버튼을 누르고 결과를 책임져야 하는 대부분의 개발자에게 같은 선택지가 쉽게 주어지지는 않는다. 내 글의 논지가 가장 덜 들어맞는 자리에 있는 사람인 셈이다. 그의 선택만으로 그 글을 반박하기는 어렵다고 보는 이유다.
키노트 이틀 뒤, DHH는 Omarchy의 화면보호기 엔진(ttfx)을 Rust에서 x86-64 어셈블리로 옮긴 일을 X에 소개했다. Opus 5.5로 한 번에 이식했고, 실행 속도가 최대 17배 빨라졌다는 것이었다. 에이전트를 드릴에 빗대며 기반암에 닿을 때까지 계속 파고들겠다고도 했다. 이에 어셈블리로 옮겼다는 이유만으로 어떻게 17배나 빨라질 수 있느냐는 반응이 나왔다. 실제로 무엇을 바꿨는지는 PR에 자세히 적혀 있다.
검증을 대충 하지는 않았다. 기존 Rust 엔진을 기준으로 37개 효과의 출력이 바이트 단위까지 맞는지 CPU 네 단계와 에뮬레이션 환경에서 비교했다. 코드 리뷰에서는 버그 세 개와 메모리 누수 하나를 찾아 고쳤다. 이런 식으로 "코드를 읽는 대신 동작을 검증하는" 방법에는 나도 동의한다.
다만 비교하는 도구도 AI와 함께 만들었다. 비교 스크립트와 테스트가 같은 PR에 추가됐고, 커밋 187개 중 131개에는 Claude가 공동 작성자로 올라 있다. 버그를 찾은 리뷰는 Codex가 했다. 기준으로 삼은 Rust 엔진부터가 한 달 반 전에 Python 원본(TerminalTextEffects)을 에이전트와 함께 옮긴 것이었다. 그때도 원본의 출력과 비트 단위로 맞췄다.
그러니 처음 정답으로 삼은 것은 Python의 출력이고, 거기서부터 번역하는 코드와 검증 도구를 대부분 AI와 함께 만든 셈이다. 정답과 비교한다는 방식은 믿을 만하다. 다만 이러한 케이스는 비교가 제대로 돌아간다는 조건이 붙을 뿐이다. Codex가 찾아낸 문제 중에는 테스트가 빠진 채 조용히 통과하던 경우도 있었다. 비교 도구 자체를 확인하는 일은 여전히 남는다.
속도가 어디서 나왔는지도 PR에 적혀 있다. 모든 효과를 처음 옮겼을 때는 단일 코어 기준 4.11배였다가, 더 최적화한 뒤 기하평균 7.53배(두 코어에서는 9.79배)가 됐다. 효과가 큰 순서는 데이터 배치, 반복 작업 제거, 메모리 최적화, SIMD와 스레드였다. 전부 어셈블리 없이도 할 수 있는 일이다.
실제로 다른 기여자가 Rust로 더 빠른 엔진을 만들어 올렸다. 속도를 목표로 설계부터 다시 짰더니 두 코어 기준으로 기존 Rust보다 11배, 어셈블리 엔진보다도 1.26배 빨랐다(PR #44). DHH가 어셈블리로 옮겨 얻었다던 속도를 Rust로도 넘어선 것이다. 더 빨라지기 위해 언어부터 바꿀 필요는 없었다.
DHH도 이 결과를 받아들였다. 자기 Zen 5 환경에서도 어셈블리 엔진보다 단일 코어에서는 1.20배, 두 코어에서는 1.25배 빨랐고, 37개 효과의 출력이 바이트 단위까지 같았다며 기여자에게 감사를 전했다. 그러고는 자신이 에이전트로 만든 어셈블리 엔진을 걷어내고 그 기여자의 Rust 엔진으로 교체했다. 9월 28일(한국 시각), 기존 커밋을 살리고 리뷰 수정 사항을 더한 후속 PR #47이 병합되면서 ttfx 0.5부터 fx가 기본 엔진이 됐다. #44가 병합 없이 닫힌 것도 이 과정에서였다.
그 기여자의 커밋에도 Claude가 공동 작성자로 올라 있다. 양쪽 모두 AI와 함께 만들었는데 다른 설계를 고른 쪽이 더 빨랐고, DHH도 그 결과를 보고 자기 선택을 바꿨다. 테스트는 두 엔진이 같은 동작을 하는지 확인해 줬다. 하지만 어셈블리가 꼭 필요한지, 설계를 바꾸면 더 나아질 수 있는지는 별도로 판단해야 했다. 이 일에서 성능을 바꾼 것은 언어보다 그 판단이었다고 생각한다.
DHH의 마음이 바뀌었다는 사실을 탓할 생각은 없다. 그는 예전에 한 말을 숨기지도 않았다. 키노트 중간에 그는 예전의 자기 모습이 담긴 짧은 영상을 직접 틀었다. 영상 속 그는 결과만 원했다면 20년 전에 프로젝트 매니저가 됐을 것이라며, 프로그래밍과 사랑에 빠졌기 때문에 그걸 포기하느니 차라리 은퇴하겠다고 말한다. 영상이 끝나자 그는 3월쯤 전업 프로그래머에서 은퇴했다고 밝히고, 영상 속 말은 전부 사실이었다고 덧붙였다. 프로그래밍을 포기할 바엔 은퇴하겠다고 했으니, 손코딩을 그만둔 지금은 정말로 은퇴한 셈이라는 것이다. 말을 바꾼 것이 아니라 예전 말을 지킨 것이라는 식으로 앞뒤를 맞춘 설명이다.
같은 키노트에서 2005년 브라질 발표 영상도 틀었다. "내가 하지 않고 있는 것들을 보라"는 말이 Rails의 순간이었다고 했다. 설정을 일일이 쓰지 않아도 관례 덕에 알아서 이어지던 장면이다. 쓰지 않아도 되는 코드가 그때의 자랑이었다.
2026년에는 "8월 한 달에 15만 줄, 장기 평균의 60배"가 자랑이 됐다. 그중 상당수는 Ruby였다면 용납하지 않았을 만큼 장황한 Rust라고 본인도 인정했다. 예전에는 사람이 읽고 고칠 코드를 적게 남기는 데 가치를 뒀다면, 이제는 에이전트로 얼마나 많은 것을 만들 수 있는지에 더 관심이 있는 듯했다.
예전의 원칙과 이번 발언을 놓고 보면 차이가 드러난다.
| 그가 남긴 원칙 | 2026년 키노트 |
|---|---|
| Rails Doctrine의 "아름다운 코드를 떠받들라" | Ruby였다면 절대 용납하지 않았을 장황함을 에이전트에게 허용한다. C++는 블랙박스로 쓰기에 훌륭한 언어다 |
| Rails Doctrine의 "큰 텐트를 세워라": "우리에게는 이견이, 다양한 생각과 사람이 필요하다." 사상 검증이 거의 없기에 큰 공동체를 한 텐트 아래 품을 수 있다는 원칙 | 생각이 달라 비관하는 사람은 루저라는 말: "black pill은 루저의 것이다" |
| Rails 가이드가 꼽는 두 원칙 중 하나인 DRY(Don't Repeat Yourself) | 이제 반복의 비용은 거의 0이다 |
| 제이슨 프라이드와 함께 쓴 『It Doesn't Have to Be Crazy at Work』(2018) | 다음 주 금요일까지, 최고의 중독, 전속력으로 |
그렇다고 Rails의 가치를 몽땅 버렸다고 하기는 어렵다. 관례를 따르면 토큰도 아낀다며 Rails의 장점을 여전히 이야기했다. 대형 플랫폼에 덜 기대려는 태도는 오픈 웨이트 모델을 지지하는 데서도 보인다. 작은 팀으로 더 많은 것을 만들겠다는 생각은 이어지고 있다고 본다. 그걸 위해 사람이 코드를 직접 읽고 쓰는 일은 얼마나 중요하냐는 질문에 답이 달라진 것 같다.
단언하는 방식은 여전하다. TDD를 비판할 때도, Apple과 맞설 때도, 클라우드를 떠날 때도 그랬다. 20년 동안 비슷했던 기질이라고 생각한다. 두세 달 전에 지금과 같은 말을 했다면 나사 빠진 사람 취급을 받았을 거라고 본인도 말한다. 그렇다면 이번 입장도 얼마든지 바뀔 수 있을 것이다. 그런데 그 확신은 이미 올해 말이면 사실상 모든 프로그래머가 손코딩을 그만둔다는 데까지 가 있다. 판단을 오래 배워 온 사람과 이제 배우는 사람도 한꺼번에 묶인다.
주니어 때의 나에게 Rails가 준 것은 관례와 적게 쓰는 코드, 작은 팀으로도 만들어 운영할 수 있는 웹이었다. 내가 이유를 몰라도 일하기 좋았던 건 누군가 그 이유를 먼저 따져 관례로 만들어 놓았기 때문일 것이다. 누군가 먼저 내린 판단이 프레임워크에 담겨 있었고, 나는 그걸 따르면서 조금씩 배웠다.
Rails Doctrine의 "날카로운 칼을 제공하라(Provide sharp knives)"를 읽으면 도구를 믿고 맡기는 이야기 다음에 가르치는 이야기가 나온다. DHH는 이렇게 적었다.
언어와 프레임워크는 누구든 전문가의 경지까지 이끌어 주는 참을성 있는 선생이어야 한다. 다만 그곳에 이르는 믿을 만한 길은 실수의 땅을 지나는 것뿐이다. 도구를 잘못 쓰고, 피와 땀과 어쩌면 눈물도 조금 흘리는 길. 다른 길은 없다.
Rails로 일을 빨리 끝낸 것도 좋았지만, 그 일을 하면서 판단을 익혔다는 게 지금은 더 크게 느껴진다.
그래서 손코딩을 두고 한 말들이 씁쓸했다. 25년 동안 매 순간을 사랑했다는 일을 이제는 Sentry에 뜬 버그처럼, 뭔가 잘못됐다는 신호로 여긴다. 대부분의 프로그래머에게 더는 경제적으로 생산적인 일도 아니라고 한다. 내게는 손으로 코드를 쓰는 게 미련한 일이 됐다는 말처럼 들렸다. 나는 그 시간을 보내며 조금씩 배운 사람이다.
DHH가 코드를 읽지 않고 결과만 보겠다고 할 수 있는 데에도 그동안 쌓은 판단이 있을 것이다. 요즘 책을 쓰느라 X와 HN에 살다시피 하는데, 내가 본 범위에서 AI가 너무 좋다는 사람들은 대부분 돈이나 자리 걱정을 덜 해도 되는 사람들이었다. 그 사람들이 틀렸다는 말은 아니다. 다만 도구가 같다고 처지까지 같지는 않다. "black pill은 루저의 것"이라는 말은 잃을 게 적은 쪽에서 하기 쉬운 말이라는 생각이 든다. HN에서도 그 점을 짚는 댓글이 보였다.
키노트 영상에서 공감을 많이 받은 댓글 하나는 돈을 주는 쪽과 받는 쪽을 나눠 이야기했다. AI는 임금을 주는 사람에게 바라던 힘이 되지만, 일하는 사람에게는 그동안 가진 협상력을 스스로 없애는 도구가 된다는 내용이었다.
ttfx PR에서도 비슷한 차이가 보였다. 체감할 이득도 없이 이식성만 잃었다는 댓글에 DHH가 답했다. 다른 무언가를 희생한 일이라고 생각한다면 파이가 정해져 있다는 사고에 아직 갇혀 있다는 것이다. 이어서 이렇게 썼다. "나는 토큰이 무제한이다. 우리는 모든 걸 고칠 수 있고, 무엇이든 할 수 있다."
Omarchy 설치 시간을 줄이는 일을 두고 "중독이 좀 있다, 하지만 최고의 중독"이라고 했던 말도 생각났다. 그에게는 트레이드오프가 더는 비용으로 느껴지지 않는 것 같다. 토큰을 무제한으로 쓸 수 있다면 하고 싶은가만 따지게 되기도 쉬울 것이다.
앞서도 언급했듯, 구현을 에이전트에 맡기는 방향 자체는 나도 매일 체감한다. 그게 틀렸다고 생각하지 않는다. 다만 이미 판단을 배운 사람이 택한 방식을 이제 배우는 사람에게도 그대로 권해도 될지는 모르겠다. 코드를 직접 쓰는 시간이 줄어도 다른 데서 배울 수 있다면 좋겠다. 나는 이 무대에서 Rails가 그 배움을 어떻게 도울지 듣고 싶었다. 걱정하는 사람을 루저라고 부르면 그 얘기를 할 수 없을 것이다.
10년 전에는 이유도 모르면서 Rails를 좋아했다. 그 덕에 배운 게 무엇인지 이제야 생각하는데, 정작 만든 사람에게서 그 배움을 이어 갈 이야기는 듣지 못했다. 그게 아쉽고 마음도 심란하다.
AI가 코드를 쓰는 시대의 개발자와 판단에 대한 에세이입니다. 초고를 읽고 의견을 주실 베타리더를 9월 30일까지 모집합니다. 인터뷰는 종료되었습니다.
판단을 비싸게 만든 마찰이, 동시에 판단을 못 배우게 만든다. AI 시대에 가장 비싸지는 능력이 가장 덜 길러지는 이유
『남은 판단은 누가 배우는가』 인터뷰가 종료되었습니다. AI와 함께 일하는 경험을 나눠주신 모든 분께 감사드립니다. 인터뷰는 예외 없이 익명으로 처리합니다.
층은 왜 쌓였고, 왜 서버로 돌아왔고, 에이전트 이후에도 스택이 남는 이유는 무엇인가. 그리고 스택이 이기는 것과 그 스택을 아는 사람의 가치는 왜 별개인가