레일즈 월드 2026 기조연설 무대에서 Basecamp 로고 티셔츠를 입은 DHH 가 리모컨을 쥐고 말하는 장면 (출처: Rails Foundation 기조연설 영상 프레임)

“손으로 코딩하는 분?” 천여 명 중 다섯 명만 손을 든 레일즈 월드

지난 9월 23일, 미국 오스틴에서 열린 레일즈 월드 2026 첫 기조연설에서 루비 온 레일즈를 만든 DHH(David Heinemeier Hansson)가 객석에 이렇게 물었다. “아직도 매주 상당한 양의 코드를 손으로 쓰는 분 계신가요?” 레일즈 개발자 천여 명이 앉은 강당에서 손을 든 사람은 다섯 명 남짓이었다. 그리고 그는 자기 회사 37signals 에서 코드를 만드는 기본 경로는 이제 에이전트이고, 사람이 손으로 쓰는 건 에이전트가 원하는 결과를 내지 못했을 때만 꺼내 드는 예외 상태라고 못 박았다.

기조연설 중 DHH 가 손차양을 하고 객석을 둘러보는 장면. 위에는 "아직도 매주 손으로 코드를 쓰는 분 계신가요?", 가운데에는 "천여 명 중 5명", 그 아래 작게 "객석 천여 명 · 정원 1,200"이 적혀 있다 (출처: Rails Foundation, Rails World 2026)
기조연설 중 DHH 가 손차양을 하고 객석을 둘러보는 장면. 위에는 “아직도 매주 손으로 코드를 쓰는 분 계신가요?”, 가운데에는 “천여 명 중 5명”, 그 아래 작게 “객석 천여 명 · 정원 1,200″이 적혀 있다 (출처: Rails Foundation, Rails World 2026)

뉴스로만 보면 유명 개발자 한 사람이 AI 코딩 쪽으로 넘어간 이야기다. 그런데 필자가 이 건에 오래 붙잡혀 있었던 이유는 따로 있는데, 이 이야기를 17분짜리 영상으로 만드는 일 자체를 AI 에이전트에게 맡겼고, 그 과정에서 DHH 의 비판자들이 경고한 실패를 내 작업이 그대로 재현했기 때문이다. 그 얘기는 뒤에서 하고, 먼저 그가 무엇을 말했는지부터 적어 둔다.

14개월 전 “실력이 손끝으로 빠져나간다”던 사람

이 손 코딩 졸업 선언이 화제가 된 건 말한 사람이 DHH 이기 때문이다. 그는 불과 14개월 전 렉스 프리드먼 팟캐스트와 한 6시간짜리 인터뷰에서 AI 가 자기 코드를 몰게 두지 않는다고 잘라 말했고, AI 에게 코딩을 맡겨 보니 실력이 손끝으로 빠져나가는 게 느껴지더라는 말까지 했다. 기타를 직접 잡는 기쁨처럼 코드를 직접 치는 것이 프로그래머의 기쁨이라며, 젊은 개발자들에게 바이브 코딩만 할 줄 알면 프로그래머가 아니라고까지 했던 사람이다. 그런데 이번 기조연설에서는 사람이 손으로 쓰는 건 에이전트가 일을 그르쳤을 때뿐이라며, 오류 추적기에 버그 알림이 떴을 때처럼 잠깐 연필을 꺼내 급한 곳을 메우더라도 곧바로 에이전트 쪽을 고치는 예외일 뿐이라고 선언했다. 연설 뒤 X 에는 대부분의 프로그래머에게 손 코딩은 더 이상 경제성 있는 기술이 아니라는 말까지 남겼다.

말로만 끝난 것도 아니었다. 메일 서비스 HEY 는 웹앱 개발을 멈추고 네이티브 앱 여섯 개로 다시 만들기 시작했는데, 연설 약 일주일 전에 착수했고 서버는 레일즈가 아니라 Rust 로 옮기는 중이라고 밝혔다. 그 새 서버가 CPU 를 99%, 메모리를 95% 덜 써서 피크 트래픽마저 라즈베리파이 한 대에 들어갈지 모른다고 어림하기도 했다. 모든 앱에 커맨드라인 도구를 붙여 앱 안에 챗봇을 두는 대신 각자 자기 에이전트를 데려와 쓰게 하겠다는 계획도 덧붙였다.

그 무렵 업계 분위기도 그와 크게 다르지 않았다. 같은 여름 발표된 설문에서 개발자 열 명 중 여덟은 AI 를 쓰거나 쓸 생각이었지만, 그 결과를 믿는 사람보다 믿지 않는 사람이 더 많았다. 연구 단체 METR 가 숙련 오픈소스 개발자 16명을 실제로 재 봤더니 AI 를 쓴 쪽이 19% 느려졌는데, 정작 본인들은 20% 빨라졌다고 믿었다(2025년 7월). 올해 초 METR 가 같은 실험을 다시 하려 하자 이번엔 개발자들이 AI 없이는 일하지 않겠다며 참가를 거부했다고 한다. 봄에는 아마존이 토큰 사용 순위표를 닫고 우버가 넉 달 만에 한 해 AI 예산을 다 썼다는 소식이 나왔다. 손에서 놓지는 못하는데 불어나는 비용과 코드를 믿지는 못하는 상태였던 셈이다.

METR 실험(숙련 오픈소스 개발자 16명 · 2025년 7월) 도해. 사전 기대 +24%, 끝난 뒤 체감 +20% 막대는 검은색이고 실측 −19% 막대만 빨간색으로 반대쪽에 뻗어 있다
METR 실험(숙련 오픈소스 개발자 16명 · 2025년 7월) 도해. 사전 기대 +24%, 끝난 뒤 체감 +20% 막대는 검은색이고 실측 −19% 막대만 빨간색으로 반대쪽에 뻗어 있다

DHH 의 생각은 이번 연설에서 갑자기 뒤집힌 게 아니었다. 올해 1월 블로그에 에이전트를 승진시키겠다는 글을 올리면서, 지난여름의 저항은 모델이 모자랐던 탓이 컸다고 털어놓았다. 그가 꼽은 계기는 2025년 11월 24일 앤트로픽이 내놓은 Opus 4.5 였다. 덴마크 화가였던 고조부 라우리츠 툭센이 덴마크 왕실 가족 초상화 한 점에 3년을 바치다 1900년 누구나 사진을 찍게 만든 싸구려 카메라 브라우니의 등장을 맞았던 것처럼, 이 모델이 우리 시대의 브라우니라는 것이다. 20년 넘게 한 해 3만 줄 남짓이던 자신의 코드 생산량도 올해 8월 한 달에만 15만 줄로 뛰었다고 했다.

스위스 치즈처럼 구멍 난 Basecamp 5

업계가 망설이는 사이 그가 오히려 한 걸음 더 나아간 데는 다섯 가지 이유가 있었다. 모델의 도약이 그 시작이었고, 타이핑 중에 끼어드는 자동완성이 아니라 일을 통째로 넘기고 검토하는 에이전트라는 형태가 둘째였다. 그는 루비보다 영어가 더 좋은 프로그래밍 언어가 되었다며 영어로 프로그램을 쓰는 게 더없는 기쁨이라고까지 말했다. 비용도 크게 작용했다. 읽는 것조차 질색하던 Rust 로 파이썬 라이브러리를 통째로 옮기게 했더니 한 번에 돌아가는 것을 보고, 언어를 모르는 게 오히려 장점이라 여겼다. 여기에 관례가 뚜렷한 프레임워크일수록 에이전트가 덜 헤매고 토큰도 아낀다는 레일즈 자체의 성격이 더해졌는데, 실제로 지난 3월부터 저장소에 AGENTS.md 안내 파일이 들어갔다. 마지막은 조직 구조였다. 엔지니어 20여 명에 디자이너 10명인 회사에서 디자이너가 곧 구현자가 되자, 자랑하던 6주 개발 주기마저 느리게 느껴질 만큼 속도가 붙었다는 것이다.

물론 박수만 나온 건 아니다. 그가 2월부터 5월까지를 환멸의 골짜기라 부른 그 봄, Basecamp 5 의 마지막 기능을 디자이너들이 바이브 코딩으로 붙였더니 구조가 스위스 치즈처럼 구멍이 났고 팀은 다시 손으로 검토하는 쪽으로 돌아갔다. DHH 는 지금 그 결정을 잘못된 결론이었다고, 조금만 기다렸으면 새 모델이 나와 원래 계획이 통했을 거라고 말한다. 게다가 불과 연설 두 달 전, 독일 비영리 코드 저장소 Codeberg 는 회원 투표 358 대 144 로 사람 손이 거의 닿지 않은 바이브 코딩 프로젝트를 받지 않기로 결의했다.

필자는 여기서 고개를 갸웃했다. 모델이 좋아진다고 해서 하나하나 괜찮은 변경이 모여 구조를 망가뜨리는 문제가 사라지지는 않기 때문이다. 이 선언에 붙은 반론 가운데 가장 날카로운 것도 같은 자리를 찔렀는데, 그 변경의 합계를 누가 책임지느냐는 질문이었다. 기조연설 영상에는 가장 혼란스러운 장례식이었다는 댓글이 달렸고, 비관하는 개발자를 패배자라 부른 대목은 거센 반발을 샀다. 해커뉴스 토론도 댓글이 사백 개를 넘었다. 보안 걱정도 컸다. AI 가 만든 API 가 인증 없이 출시돼 급히 막았다는 개발자의 증언이 나왔고, DHH 본인 역시 AI 를 쓰는 보안 연구자들이 취약점을 전례 없이 빨리 찾아내고 있으니 대비해야 한다고 경고했다. 클라우드를 떠나 자체 서버로 독립하자던 회사가 가장 중요한 생산 도구를 소수 모델 회사에 맡기게 되었다는 독립의 역설도 뼈아팠다. 숫자도 조심해서 봐야 한다. 줄 수는 생산성이 아니고, 새 서버가 CPU 를 99% 덜 쓴다는 것도 본인이 어림한 값인 데다 화면 그리기를 기기로 넘긴 효과와 Rust 로 바꾼 효과가 섞여 있다.

"하나하나는 괜찮은 변경(PR) 20개"를 검은 칸 스무 개로 그린 도해. 그중 몇 칸이 빨간 점선으로 비어 있어 구멍처럼 보인다
“하나하나는 괜찮은 변경(PR) 20개”를 검은 칸 스무 개로 그린 도해. 그중 몇 칸이 빨간 점선으로 비어 있어 구멍처럼 보인다

“내가 경고한 치즈를 네가 재현했다”는 검수 메모

여기부터가 내 작업 이야기다. 이 영상은 처음부터 끝까지 Claude 에이전트에게 맡겨 만들었다. 나는 웹 창구에서 지시와 검수 메모만 넣고, 자료 수집과 대본, 도해, 나레이션 합성, 자막, 렌더는 맥에서 에이전트가 돌린다. 완성본은 17분 2.9초, 66컷, 30,687프레임이고, 자료는 마흔 건 남짓을 대조했다.

첫 판은 과학 채널에 올렸다가 쓴맛을 봤다. 첫날 노출 136회, 클릭률 1.5%, 16분짜리 영상의 평균 시청 시간이 23초였고 검색 유입은 0이었다. 채널과 주제가 안 맞았던 거라 영상을 비공개로 내리고 테크 채널에서 패키징부터 다시 하라고 맡겼는데, 에이전트는 62컷짜리 서사를 36컷, 6분짜리 요약판으로 잘라 왔다. 겉보기엔 깔끔했다. 문제는 앞뒤 맥락을 잇던 문장들이 빠져 이야기가 성긴 그물이 됐다는 것이었다. 그날 검수 메모에 난 이렇게 적었다.

기존 영상을 보완하라고 했지 이렇게 난도질 해놓으라고 하진 않았어. 이 영상 안에서 지적한 그럴 듯하지만 구멍 뚫린 치즈를 지금 니가 정확히 재현했어.

하나하나 그럴듯한 편집이 모여 전체를 망가뜨린다는 것, 영상이 설명하던 바로 그 실패였다. 결정은 단순했다. 62컷 서사를 한 줄도 지우지 않고 되살리되 56컷은 글자와 소리까지 그대로 두고, 맥락이 끊긴 6컷에만 말을 덧붙이고, 앞의 훅만 새로 짜게 했다. 잘린 판과 원래 판은 따로 백업해 두었는데 나중에 교육 자료로 쓸 생각이다.

기계 검사가 전부 통과한 뒤에 사람이 잡아낸 것

재미있는 건 그 뒤다. 요약판을 걷어 내고 서사를 되살린 뒤에도 몇 차례 검수가 더 돌았는데, 에이전트의 검사 스크립트는 매번 초록불이었다. 프레임 수, 키프레임 간격, 라우드니스(−14.0 LUFS), 오디오와 영상의 어긋남(최대 0.1ms), 자막 싱크까지 전부 통과였다. 그런데 사람 귀에는 걸리는 게 있었다. 나레이션이 “다시 한 두 번째 인터뷰”를 “한두 번째”로 읽었고, 타이틀의 “14개월”에서 14 만 흰색으로 떴다. 둘 다 스크립트가 재는 항목이 아니었다.

가장 애먹은 건 소리였다. 0:02 부근을 짚어 “발화 중에 순간적으로 깨지는 소리가 영상 전반에 있다, 잘라 붙인 곳 같다”고 적었는데, 에이전트가 파형을 재 보니 이음매 문제가 아니었다. 음성 합성 원음 자체에 폭 0.2ms 짜리 튀는 점이 64컷에서 1,071건 박혀 있었던 것이다. 여기서 내가 흡족했던 건 고친 방식인데, 지적한 한 곳만 메우지 않고 음성을 읽어 들이는 단계에 틱 메우기를 넣어 1,710곳을 0.5ms 씩 메웠고(말 1,000초 중 0.9초 분량), 검사에 “나레이션 틱 0건”을 새로 걸었다. 고치기 전 상태로 되돌리면 그 검사가 1,071건으로 실패하는 것까지 확인했다.

DHH 가 에이전트가 실수하면 급한 곳을 손으로 메우더라도 곧바로 에이전트 쪽을 고친다고 한 게 바로 이런 일일 것이다. 코드를 고치면 그 한 번으로 끝나지만 규칙을 고치면 다음 작업이 전부 달라진다. 그래서 이번 작업에서도 에이전트 규칙에 한 줄을 남겼다. “다시 기획하라”를 “요약하라”로 읽지 않는다. 앞선 다큐 작업 이야기는 AI 와 5일 만에 다큐멘터리 한 편을 만든 글에, 검수 메모를 넣는 창구는 검수용 앱을 만든 글에 적어 두었다.

이득이 나는 과제와 손해가 나는 과제는 어디서 갈리나

그럼 사람과 AI 를 붙이면 언제 이득이 날까. 영상에서 가장 오래 붙잡은 대목이 이것이었다. 에이전트는 팀 사정을 모른 채 일을 시작하므로 적혀 있지 않은 빈칸을 학습한 평균으로 채우려 하고, 토큰을 덜 쓰는 무난한 답으로 때우려 한다. 그래서 우리가 요구하는 최소한의 수준(SLA)을 일깨우는 규칙 파일이 필요한 것이다. 이 원리를 먼저 증명한 곳은 체스였다. 2005년 프리스타일 체스 대회에서 그랜드마스터들을 꺾고 우승한 팀은 미국 뉴햄프셔의 아마추어 두 사람이었다. 체스 점수가 1685점과 1398점에 불과했던 이들은 PC 세 대에 체스 프로그램 네 개(프리츠, 슈레더, 주니어, 체스 타이거)를 나눠 돌리며 컴퓨터를 코치했고, 결승에서 러시아 그랜드마스터 팀을 2.5 대 1.5 로 꺾었다. 카스파로프는 약한 사람과 기계라도 더 나은 과정을 갖추면 강한 조합을 이긴다고 평했다.

수치로 봐도 분명하다. 하버드 경영대학원과 BCG 가 컨설턴트 758명으로 한 실험에서, AI 가 잘하는 과제에서는 일을 12% 더 많이, 25% 더 빨리 끝냈고 품질도 40% 넘게 올랐다. 반면 AI 의 능력 밖 과제에서는 AI 를 쓴 쪽의 정답률이 오히려 19%포인트 떨어졌다. 의사 50명에게 GPT-4 를 준 실험에서도 진단 점수는 74% 에서 76% 로 거의 제자리였는데, 정작 GPT-4 혼자 푼 점수는 의사들보다 16%포인트나 높았다. MIT 연구진이 실험 106건을 모아 보니 사람과 AI 를 합친 팀은 평균적으로 둘 중 잘하는 쪽 혼자보다 못했고, 이득은 무언가를 만들어 내는 과제에서, 손실은 AI 가 낸 답을 받아들일지 고르기만 하는 판단 과제에서 났다.

판정 기준도 마찬가지다. 에이전트는 지치지 않고 검사를 돌리지만 주어진 테스트만 통과하려 든다. 켄트 벡이 경계한 신호도 에이전트가 테스트를 꺼 버리거나 지워 버리는 순간이었다. 버튼이 눌리는지는 테스트가 재지만 화면 흐름이 자연스러운지는 사람의 눈이 잰다. 사람이 먼저 판정 기준을 세우지 않으면 에이전트가 만든 결과가 곧 기준이 되어 버린다.

두 칸짜리 도해. 왼쪽 "이득이 난 곳"에는 글·그림처럼 무언가를 만들어 내는 과제와 사람이 AI 보다 잘하는 과제, 오른쪽 "손실이 난 곳"에는 AI 가 낸 답을 받을지 고르기만 하는 판단 과제와 AI 가 사람보다 잘하는 과제가 적혀 있고, 아래에 "AI 가 만들고, 사람이 판정한다"
두 칸짜리 도해. 왼쪽 “이득이 난 곳”에는 글·그림처럼 무언가를 만들어 내는 과제와 사람이 AI 보다 잘하는 과제, 오른쪽 “손실이 난 곳”에는 AI 가 낸 답을 받을지 고르기만 하는 판단 과제와 AI 가 사람보다 잘하는 과제가 적혀 있고, 아래에 “AI 가 만들고, 사람이 판정한다”

내 작업에 대 보면 딱 맞아떨어진다. 컷을 만들고 소리를 고르는 일은 에이전트가 사람보다 빠르고 지치지 않는다. 그런데 이야기가 앞뒤로 이어지는지, 발음이 어색한지는 내가 판정했고, 그 판정 기준을 먼저 적어 두지 않았을 때는 에이전트가 만든 결과가 곧 기준이 되어 버렸다. 6분 요약판이 딱 그랬다. 그러니 에이전트에게 일을 넘기기 전에 내가 먼저 적어야 하는 건 지시문보다 “무엇이 끝난 상태인가”였다.

자동조종이 풀린 순간 조종간을 잡을 다섯 명

영상의 끝은 1983년 인지심리학자 리잔 베인브리지가 쓴 “자동화의 아이러니”로 간다. 자동화가 발전할수록 사람에게는 가장 어려운 예외만 남는데, 그 예외를 다룰 연습 기회는 자동화가 가져간다는 얘기다. 2009년 에어프랑스 447편은 속도계가 얼음 결정에 막혀 자동조종이 풀리자 조종사들이 비행기를 손으로 되살리지 못했고 228명이 모두 숨졌다. 그 뒤 미국 연방항공청은 2013년 항공사들에 조종사가 손으로 비행할 기회를 일부러 만들라고 권고했다.

코드도 같은 길 위에 서 있다. 판정하는 사람의 가장 무거운 짐은 에이전트가 막힌 순간 직접 연필을 들고 전체 구조를 책임지는 것뿐만 아니라, 바로 다음 판정자를 길러 내는 일이다. 신입 개발자가 손으로 쓸 일이 사라지면 판정하는 눈을 기를 기회도 함께 사라지기 때문이다. 조종사들에게 수동 비행 기회를 일부러 주듯, 우리 팀에도 사람이 직접 쓰고 읽는 시간을 일부러 남겨 두어야 하는 이유다.

"에이전트가 하는 일" 막대 대부분이 검은색이고 끝의 짧은 빨간 구간에 "예외 상태 · 사람이 연필을 든다"는 표시가 붙어 있다. 아래 카드에는 "그 순간을 버티게 하는 것"과 "손으로 써 본 시간", 큰 글씨로 "조종간을 잡을 사람"
“에이전트가 하는 일” 막대 대부분이 검은색이고 끝의 짧은 빨간 구간에 “예외 상태 · 사람이 연필을 든다”는 표시가 붙어 있다. 아래 카드에는 “그 순간을 버티게 하는 것”과 “손으로 써 본 시간”, 큰 글씨로 “조종간을 잡을 사람”

그래서 손을 든 다섯 명이 시대에 뒤처진 사람들로만 보이지는 않는다. 오히려 에이전트의 결과를 판정할 수 있는, 지금 가장 비싸진 사람들일지도 모른다. 나도 이번에 연필은 거의 들지 않았지만, 그럴듯한 6분 요약판을 보고 구멍을 알아챈 건 예전에 손으로 편집해 본 시간 덕이었다고 생각한다. 영상 본편은 유튜브에 있다.

연필을 버리지 말고 서랍에 넣어 두자. 코드를 짜는 분들의 팀에는 그 서랍을 열 줄 아는 사람이 몇 명이나 남아 있을까?

이 글 공유하기X페이스북스레드네이버 블로그

Similar Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다