그다지 프로메테우스답지 않은

AI 요약

DHH는 Rails World 기조연설에서 웹 앱이 네이티브 앱으로 바뀌고 백엔드에는 Rust가 쓰일 것이라 전망합니다. 근거는 특정 기술의 우월성이 아니라 개발 비용이 거의 0에 가까워졌다는 주장입니다. 앞서 José Valim은 “가장 강력한 도구와 1000배 생산성을 얻었는데, Rails를 10배 낫게 만들 생각은 왜 못 하느냐”고 물었습니다. 글쓴이는 DHH의 답을 살펴보며, LLM이 코드를 싸게 만들더라도 개발의 다른 비용까지 없애지는 않는다고 주장합니다.

비용이 낮아져도 병목은 옮겨갑니다

Dan Luu는 LLM 덕분에 성능 최적화 같은 전문 작업의 비용이 크게 낮아졌다고 썼습니다. 다만 에이전트는 벤치마크에 과적합하고, 사람의 도움 없이 실험을 설계하는 데 서툽니다. 흥미로운 결과를 얻는 시간은 줄어도 엄밀한 결과를 얻는 시간은 줄지 않았다고 지적합니다.

Varun Gandhi는 비용 논리의 적용 범위를 따져봅니다. “X는 너무 비쌌지만 LLM이 비용을 크게 줄였으니 이제 사람들이 X를 할 것”이라는 주장은 Luu처럼 자기 프로젝트를 다루는 전문가에게는 맞을 수 있지만, 그런 사례는 드뭅니다. Rust 백엔드, 네이티브 앱 여섯 개, 지난 금요일까지 CLI를 만들자는 DHH의 제안도 같은 논리입니다. DHH는 자기 제품을 만들고 회사의 결정을 내리는 전문가입니다. 그에게서 잘 작동하는 방식이 거의 모든 개발자와 회사에 곧바로 적용되지는 않습니다.

무엇보다 코드 작성은 전체 비용에서 가장 큰 몫이 아니었습니다. 변경 사항을 배포하고 유지하며 회귀를 막는 일도 남습니다. DHH가 소개한 Hey Next는 개발을 시작한 지 일주일밖에 되지 않았고, 아직 프로덕션 시스템도 아닙니다. Basecamp 5의 ‘스위스 치즈’ 아키텍처도 코드보다 조정 비용이 더 비쌌던 현실에서 나왔습니다. Gandhi가 든 Bun의 사례도 비슷합니다. LLM의 도움으로 Zig를 포크해 네 배 빠르게 컴파일하는 버전을 만들었지만, 비결정적 컴파일러를 원하지 않아 업스트림에 반영하기 어렵습니다.

코드 작성이라는 병목을 없애면 대기열까지 사라지는 게 아닙니다. 배포와 검토, 유지보수가 다음 병목으로 드러납니다. 글은 DHH가 이 문제를 건너뛰려 한다고 봅니다.

기다림이 사라지면 허용 범위도 넓어집니다

DHH는 Rust 같은 언어가 장황하고 사람이 읽기 불편하다며, 에이전트가 필요 이상으로 많은 코드를 쓰도록 내버려둔다고 말합니다. Gandhi는 에이전트가 비동기적으로 작업하면 사람들이 느린 빌드나 자동완성 지연을 덜 신경 쓸 수 있다고 설명합니다. 사람이 결과를 기다리지 않으니 불편함을 참는 기준도 달라집니다.

DHH의 방식에서는 작업을 동료에게 맡기듯 에이전트에 넘긴 뒤 결과가 나오면 확인합니다. 글쓴이는 여기서 ‘검토’가 코드 리뷰가 아니라 버튼이 의도한 대로 작동하는지 확인하는 수준이라고 해석합니다. 개인 프로젝트에는 괜찮을 수 있으며, 일주일째인 Hey Next에서는 잘 작동하는 듯합니다. 하지만 DHH가 Hey Next의 내부 코드에 무관심해도 Rails 사용자들은 Rails 코드에 관심을 둡니다. 한 사람의 허용 범위가 다른 개발자와 회사에도 그대로 적용되지는 않습니다.

토큰보다 아이디어가 부족합니다

Valim의 질문으로 돌아가면, 토큰을 무한히 쓰고 생산성이 1000배가 된 개발자는 Rails에 무엇을 더할 수 있을까요? 글쓴이는 문제가 예산이 아니었다고 답합니다. 작업 속도가 빨라져도 우선순위는 저절로 바뀌지 않습니다. DHH가 올해 만든 것은 자신이 원한 것들이며, Rails를 개선해야만 만들 수 있는 제품은 없었습니다.

그가 떠올린 결과물은 계산기, 동영상 편집기, 프레젠테이션 소프트웨어, 또 하나의 Linux 배포판, 그리고 자기 제품의 재작성입니다. 글쓴이는 이 목록에 새로운 아이디어가 하나도 없다고 봅니다. LLM은 이미 존재하는 것을 만드는 데 뛰어납니다. Luu도 이를 인정하며, 초기 모델은 우스울 정도로 기존 사례에 과적합했습니다. 계산기는 안전한 요청이지만 2004년의 Rails는 새로웠고, 그 새로움으로 주목받았습니다.

글쓴이는 DHH의 기조연설이 손으로 코드를 쓰던 시대를 이미 지나온 단계처럼 다룬다고 지적합니다. 그러나 아이디어를 실행하는 데 필요한 수고가 줄어도 먼저 아이디어를 떠올리는 불꽃은 여전히 필요합니다. 2005년에는 “아직 하지 않은 일이 이렇게 많다”는 말이 자랑이었습니다. 글쓴이의 눈에는 DHH가 이제 그만둔 일이 새 아이디어를 내는 일처럼 보입니다.

원문: jardo.dev / 번역·요약: Trawling