David Heinemeier Hansson — 코드 작성이 사라진 뒤에도 엔지니어가 해야 할 일

원문: https://world.hey.com/dhh/over-my-dead-pencil-fb0f3647 | David Heinemeier Hansson, 2026년 10월 6일

핵심 요약

Ruby on Rails의 창시자이자 37signals의 CTO인 DHH는 최근 글 「Over my dead pencil」에서 프로그래머가 대부분의 코드를 손으로 타이핑하던 시대는 경제적으로 끝나가고 있다고 주장한다. 그의 비유에서 코딩 에이전트는 단순한 자동완성 도구가 아니라 빠르고 유능하지만 감독이 필요한 새 동료다. 핵심은 ‘사람이 코드를 전혀 쓰지 않는다’가 아니라, 코드 입력량이 더 이상 엔지니어의 희소한 가치를 설명하지 못하게 된다는 데 있다. 다만 이 낙관론이 현실이 되려면 리뷰·검증·제품 판단의 병목을 정면으로 다뤄야 한다.

연필을 내려놓으라는 말의 진짜 대상

DHH의 글은 자극적인 선언으로 시작한다. 에이전트가 Ruby, Rust, C++의 상당 부분을 작성할 수 있으니 프로그래머는 ‘연필’을 내려놓아야 한다는 것이다. 이를 곧바로 개발자 직업의 소멸 선언으로 읽으면 논점이 흐려진다. 그가 겨냥하는 것은 직업 그 자체보다, 줄 단위 생산량을 전문성의 중심에 놓아 온 업무 방식이다.

소프트웨어 개발에는 오랫동안 두 종류의 시간이 있었다. 요구를 이해하고, 시스템의 제약을 파악하고, 무엇을 바꿀지 결정하는 시간과 그 결정을 문법에 맞는 코드로 옮기는 시간이다. 전자는 맥락과 책임이 필요하고 후자는 반복 가능한 패턴을 많이 포함한다. 에이전트는 두 번째 시간을 급격히 압축한다. 그래서 질문은 ‘에이전트가 이 함수를 작성할 수 있는가’에서 ‘우리는 무엇을 만들지, 어떤 변경을 받아들일지, 실패하면 누가 설명할 것인가’로 이동한다.

이는 생산성 도구가 늘어날 때마다 되풀이된 이야기와 닮아 있다. 컴파일러, 프레임워크, 클라우드가 각각 저수준의 수고를 줄였지만 소프트웨어 수요 자체를 없애지는 않았다. 오히려 만들 수 있는 것이 늘어나며 새로운 복잡성이 생겼다. DHH가 말하는 ‘소프트웨어 개발의 개화’도 같은 논리다. 개발 단가가 떨어지면 이전에는 우선순위에서 밀렸던 자동화, 내부 도구, 틈새 업무 흐름이 사업 대상으로 돌아온다는 전망이다.

동료라는 비유가 맞는 이유와 빠지는 것

DHH는 AI를 망치나 IDE 기능보다 동료에 가깝다고 본다. 이 비유는 유용하다. 좋은 에이전트는 요청을 받아 여러 파일을 살피고, 테스트를 실행하고, 실패한 결과를 바탕으로 접근을 바꾼다. 즉 손이 빠른 ‘코드 생성기’보다 위임 가능한 작업 단위에 가깝다. 사람이 해야 할 일도 자연스럽게 달라진다. 문제를 작은 단위로 쪼개고, 성공 기준을 명확히 하며, 실행 권한과 되돌림 경로를 설계하고, 결과를 검토하는 일이다.

하지만 동료 비유에는 중요한 차이도 있다. 인간 동료는 조직의 암묵지, 사용자에게 약속한 수준, 과거 장애의 맥락을 장기적으로 학습한다. 반면 에이전트는 제공된 컨텍스트와 도구 권한의 경계 안에서만 일한다. 그 경계가 부정확하면 그럴듯하지만 잘못된 코드를 더 빠르게 생산할 수 있다. 속도가 빨라질수록 잘못된 가정이 퍼지는 속도도 빨라진다.

그래서 필요한 것은 ‘에이전트에게 더 많은 일을 시키는 법’만이 아니다. 요구사항, 설계 결정, 테스트, 관측 지표를 에이전트와 사람이 함께 확인할 수 있는 형태로 남기는 일이 중요해진다. 테스트가 없는 저장소에서 에이전트의 수정은 빠른 추측에 가깝다. 반대로 명확한 계약 테스트와 작은 배포 단위가 있으면, 에이전트는 더 큰 실험 공간을 안전하게 탐색하는 도구가 된다.

반응이 보여 주는 실제 병목

이 글의 Hacker News 제출은 검색 시점에 점수와 댓글이 거의 없어, 이를 개발자 사회 전체의 찬반으로 읽기는 어렵다. 오히려 아직 논쟁이 충분히 축적되지 않았다는 사실이 눈에 띈다. 그러나 같은 시기 현장 글들을 모은 Working Surface의 큐레이션은 더 구체적인 긴장을 보여 준다. 여러 팀이 에이전트로 PR을 빠르게 만들지만, 리뷰·승인·변경 책임이 새로운 병목이 된다는 것이다.

이 반론은 DHH의 전망을 부정한다기보다 조건을 단다. 코드 작성 비용이 낮아졌다고 제품 출시 비용 전체가 같은 비율로 낮아지는 것은 아니다. 보안 검토, 운영 책임, 고객 데이터, 호환성, 장애 대응은 자동 생성된 diff 바깥에 남는다. 특히 작은 팀일수록 ‘에이전트가 만든 변경을 누가 얼마나 깊게 읽을 것인가’가 핵심이다. 검토가 형식화되면 속도는 얻지만 시스템 이해는 잃을 수 있다.

경제적 관점도 빠뜨리기 어렵다. 생성 비용이 낮아지면 기능 하나의 제작비는 줄지만, 사용자가 그 기능을 신뢰하게 만드는 비용은 자동으로 줄지 않는다. 고객 지원, 데이터 복구, 규제 대응, 장기 유지보수는 출시 뒤에 남는다. 따라서 팀은 ‘더 많이 만들 수 있다’는 가능성을 곧바로 백로그의 양으로 바꾸기보다, 실패했을 때 되돌릴 수 있는 작은 실험을 더 자주 하는 방향으로 사용해야 한다. 에이전트의 생산성은 개발 조직의 총 산출물이 아니라 학습 속도를 높일 때 가장 큰 경제적 가치를 낸다.

그렇다고 손으로 작성하는 양을 지키는 일이 해답은 아니다. 더 현실적인 대응은 작성과 승인 사이의 계약을 강화하는 것이다. 변경 전에 수용 기준을 적고, 에이전트가 실행할 테스트와 건드릴 수 없는 영역을 제한하며, 위험한 작업에는 사람의 승인 지점을 둔다. 코드 리뷰도 모든 줄을 같은 밀도로 읽기보다 인증·결제·데이터 삭제·마이그레이션처럼 실패 비용이 큰 부분에 시간을 배분해야 한다.

‘무엇을 만들 것인가’가 다시 중심이 될 때

DHH의 가장 설득력 있는 지점은 두려움이 기술의 한계를 과장하게 만들 수 있다는 경고다. 에이전트가 틀릴 수 있다는 사실은 맞지만, 그 사실만으로 협업을 거부하면 새로운 도구가 열어 주는 실험 기회를 놓친다. 반대로 에이전트가 빠르다는 사실만 믿고 제품 판단과 검증을 생략하면, 더 빨리 잘못된 방향으로 갈 수 있다.

앞으로 엔지니어의 가치는 코드 한 줄을 기억하는 능력보다 문제의 경계를 설정하는 능력, 시스템이 실제로 지켜야 할 불변조건을 정의하는 능력, 생성된 결과에 책임지는 능력에서 더 크게 드러날 가능성이 높다. ‘연필을 내려놓으라’는 말은 손을 놓으라는 뜻이 아니라, 손이 담당하던 일을 더 높은 수준의 판단으로 옮기라는 도발로 읽는 편이 낫다. 그 판단을 뒷받침할 테스트, 로그, 문서, 그리고 멈출 수 있는 배포 절차를 갖춘 팀에게만 에이전트의 속도는 진짜 경쟁력이 될 것이다.