코드를 사람이 읽지 않는 시대? Bun 1.4가 남긴 논쟁

지난주 공개된 Bun 1.4는 자바스크립트 런타임 Bun을 Zig에서 Rust로 다시 쓴 버전이다. 100만 줄이 넘는 새 Rust 코드가 포함됐다고 알려지면서 커뮤니티에서는 언어 교체 자체를 둘러싼 논쟁이 일었다. 그러나 InfluxDB 창업자 폴 딕스(Paul Dix)는 자신의 글 'The End of Programming'에서 정작 주목해야 할 지점은 언어가 아니라 '어떻게, 얼마나 큰 규모로' 이 재작성이 이뤄졌는지라고 짚는다. 그는 이번 사례를 사람이 손으로 코드를 쓰고 다른 사람이 한 줄씩 검토하던 방식이 저물어가는 신호로 읽는다.

11일과 100만 줄이 말하는 것

딕스가 인용한 내용에 따르면 이 재작성은 개발자 한 명, 재러드 섬너(Jarred Sumner)가 프리릴리스 단계의 모델과 사실상 제한 없는 토큰 예산으로 진행했다. 여러 에이전트가 병렬로 Zig 코드를 Rust로 옮기도록 하는 하네스와 프레임워크를 그가 직접 짰고, 11일 동안 에이전트들이 6,778건의 커밋을 만들어냈다. API 정가로 환산하면 약 16만 5천 달러어치의 토큰을 태운 셈이다. 초기 병합에는 +1,009,257 / -4,024라는 변경 규모가 찍혀 있었다. 중요한 것은 이 프로토타입이 곧바로 출시된 게 아니라, 이후 수개월간 에이전트가 계속 개선·검증을 반복한 뒤에야 공식 지원 버전으로 나왔고 지금은 수백만 대의 개발자 머신에서 돌아간다는 점이다.

딕스는 '비교할 원본이 있으니 언어 변환은 쉬운 일 아니냐'는 반론을 인정하면서도, 핵심은 검증 시스템을 세우고 방향을 제대로 주면 AI가 복잡한 소프트웨어를 만들고 '동작할 때까지' 다듬어낼 수 있다는 사실이라고 본다. 그는 GitHub의 8월 17일 장애 관련 게시물에 실린 그래프를 근거로, 지난해부터 생산되는 코드량이 가파른 지수 곡선을 그린다고 말한다. 다만 그 대부분은 사이드 프로젝트나 사내 실험, 개인용처럼 비핵심으로 분류되는 것이며, 실제 사업을 굴리는 제품에서는 여전히 조직적 마찰이 크다고 덧붙인다.

실무자에게 남는 것

주목할 만한 대목은 프런티어 기업 개발자들의 작업 방식 변화다. 딕스의 해석에 따르면 앤트로픽과 오픈AI 개발자들은 주당 수십에서 수백 건의 PR을 올리며, 물리적으로 모든 코드를 정밀 검토하기 어려운 만큼 초점을 더 위로 옮겼다. 즉 코드 한 줄 한 줄을 보는 대신 프롬프트, 검증 도구, 시스템을 설계해 AI가 대량·고속으로 소프트웨어를 뽑아내게 만든다는 것이다. 여기서 실무적 함의가 분명해진다. 앞으로 경쟁력은 '코드를 잘 쓰는' 역량보다 요구사항과 아키텍처를 명확히 정의하고, 자동화된 QA·검증 파이프라인을 구축하는 역량으로 이동한다.

딕스 자신의 경험도 이를 뒷받침한다. 그는 InfluxDB 포크에서 두 가지 기능을 실험했다. 하나는 Iceberg REST와 외부 S3·Glue 카탈로그로 데이터를 노출하는 통합 기능으로, 러프한 설계와 요구사항만 주고 서브에이전트에 맡긴 뒤 14시간 만에 동작하는 버전을 얻었다. 다른 하나는 여러 InfluxDB 노드가 압축 데이터를 중앙 클러스터로 주기적으로 복제하는 엣지 복제 시스템으로, 약 28시간 뒤 대체로 동작하는 구현이 나왔고 AWS 테스트 인프라에서 몇 차례 반복 끝에 엔드투엔드로 작동했다. 그는 이 결과를 단순히 '프로토타입을 빨리 만드는 도구'로 깎아내리는 시각에 반대한다. 프로토타입 자체가 동작하는 소프트웨어이고, 이후 개선은 사람의 코드 리뷰가 아니라 사용과 테스트, 검증 루프로 이뤄진다는 것이다.

한계와 유보

다만 딕스 스스로 이 기능들이 아직 출시되거나 지원되는 상태가 아니며 프로덕션 레벨도 아니라고 밝힌다. 결정적 제약은 비용이다. 그는 주간 할당량을 쓰며 한 주씩 기다려 실험했고, 최상위 에이전트를 24시간 돌리는 클라우드 개선 루프는 월 수십만 달러가 들어 감당할 수 없다고 말한다. 또한 그가 언급하는 여러 차세대 모델과 하드웨어 명칭, 그리고 '내년 말이면 대부분이 상시로 이런 지능을 쓸 것'이라는 전망은 검증된 사실이 아니라 저자 개인의 예측이라는 점을 분리해 읽어야 한다. 그는 조직 관성 탓에 앞으로도 십수 년은 사람이 손으로 코드를 쓰고 동료가 검토하는 방식이 이어질 것이라고도 인정한다.

결국 이 글은 선언이라기보다 하나의 관측에 가깝다. 검증 가능한 문제, 비핵심 내부 도구, 명확한 정답지가 있는 작업에서는 에이전트 주도 개발이 이미 현실적 생산성을 낸다. 반면 규제·안정성·책임이 걸린 핵심 제품에서는 여전히 사람의 판단과 검토가 병목이자 안전장치로 남는다. 한국 IT 실무자에게 필요한 태도는 이 두 세계를 구분하고, 어느 영역부터 검증 자동화와 에이전트 워크플로를 안전하게 들일지 실험해 보는 일이다.