Bun의 AI 재작성이 언어 전쟁을 촉발하다

Bun은 불가능한 위업을 달성했습니다. Zig에서 Rust로 50만 줄의 코드 재작성을 단 11일 만에 완료했습니다. 5월 3일부터 5월 14일 사이에 이 빠른 리팩토링은 6,500개 이상의 commits를 생성하여 고성능 JavaScript runtime을 근본적으로 변경했습니다. 이 신속하고 대규모의 작업은 대규모 소프트웨어 진화의 새로운 시대를 알리며, 가능하다고 여겨지는 것의 경계를 넓히고 있습니다.

이 전례 없는 질주의 배경에는 Bun의 Zig 코드베이스에 내재된 만성적인 안정성 문제가 있었습니다. Zig의 수동 메모리 관리 원칙은 JavaScriptCore의 garbage collector와 근본적으로 충돌하여 불안정한 환경을 만들었습니다. 이러한 상호작용은 use-after-free 및 double-free 오류와 같은 지속적인 메모리 안전 버그를 발생시켜 Bun의 속도와 신뢰성이라는 핵심 약속을 훼손했습니다. Rust의 borrow checker는 이제 compile-time 보장을 제공하여 이러한 중요한 문제가 production에 도달하기 전에 방지합니다.

인공지능이 이 모든 변화를 주도하며 엔지니어링의 새로운 패러다임을 제시했습니다. 64개의 동시 Claude 인스턴스와 사전 출시된 Fable 5를 활용한 AI 기반 프로세스는 분당 58개의 commits를 기록했습니다. 이 전례 없는 자동화는 API tokens 비용으로 약 16만 5천 달러가 들었습니다. 이 투자는 다수의 엔지니어 팀이 1년 동안 작업하는 비용의 극히 일부에 불과하며, 이 규모의 수동 재작업은 경제적으로 불가능하고 아마도 시도되지 않았을 것입니다. 엄청난 경제적 효율성과 속도는 전통적인 개발 모델에 도전합니다.

AI 코드 에이전트 군단을 풀어놓으며, Bun 팀은 Fable 5의 사전 출시 버전을 중심으로 정교한 워크플로우를 구축했습니다. 이 시스템은 최대 64개의 Claude 인스턴스를 동시에 조율하여 전례 없는 병렬화로 재작업을 추진했습니다. 이는 AI가 설계자이자 노동자 역할을 하며 인간 팀이 꿈꿀 수 있는 속도로 작동하는 미래의 대규모 소프트웨어 개발에 대한 강력한 통찰을 제공합니다.

이 AI 기반 프로세스의 핵심은 강력한 "구현자-검토자-수정자" 루프였습니다. 단일 에이전트가 초기 Rust port를 수행하여 새 코드를 생성했습니다. 이 결과물은 두 개의 독립적인 적대적 에이전트의 정밀 조사를 받았는데, 이들은 오류와 불일치를 찾아 code diff를 꼼꼼하게 검토하며 자동화된 품질 게이트 역할을 했습니다. 마지막 에이전트는 제안된 수정 사항을 종합하고 적용하여 변경 사항이 적용되기 전에 다층적인 검증을 보장했습니다.

초기 배포는 예측 가능한 AI로 인한 혼란에 직면했습니다. 네 개의 Git worktrees에서 독립적으로 작동하는 에이전트들은 `git stash` 및 `git reset HEAD --hard`와 같은 충돌하는 Git 명령을 실행하며, 본질적으로 repository를 놓고 싸웠습니다. 프롬프트 개선을 통해 이 문제는 빠르게 해결되었으며, 에이전트들에게 변경 사항을 직접 committing하는 것과 관련 없는 Git 또는 느린 `cargo` 명령을 피하도록 지시했습니다.

에이전트들이 compilation을 위해 함수를 stubbing하거나 의심스러운 workaround를 긴 주석으로 정당화하기 시작하면서 추가적인 문제가 발생했습니다. Jarred Sumner는 적대적 reviewers를 위한 중요한 규칙을 삽입하여 이에 대응했습니다. 즉, workaround를 합리화하기 위해 과도한 commentary가 필요한 코드는 거부하도록 했습니다. 이는 AI가 표면적인 compliance보다 근본적인 fixes를 우선시하여 더 깨끗하고 견고한 solutions을 생성하도록 강제했습니다.

초기 AI 출력은 방대했지만 컴파일되지 않았습니다. Jarred Sumner는 먼저 근본적인 아키텍처 불일치를 해결했습니다. Bun의 원래 Zig 코드베이스는 단일 컴파일 단위로 작동했지만, 팀은 컴파일 속도 향상을 위해 100 Rust crates를 목표로 삼았습니다. 이는 Zig가 대체로 무시하는 개념인 순환 종속성을 제거하기 위한 복잡한 리팩터링을 필요로 했습니다. AI 워크플로우는 이 복잡한 리팩터링을 분류한 다음 실행하여 기반을 마련했습니다.

이러한 구조적 개편은 즉시 약 16,000개의 컴파일러 오류를 드러냈습니다. 초기 코드 생성 설정을 반영하는 전담 AI 에이전트 스웜이 체계적으로 이 문제들을 해결했습니다. 에이전트들은 크레이트별로 반복하며 `cargo check`를 실행하고, 오류를 식별하고, 수정 사항을 제안했습니다. 두 명의 적대적 에이전트가 각 제안을 검토하여 코드 품질을 보장한 후, 수정 에이전트가 변경 사항을 적용하여 궁극적으로 전체 프로젝트를 컴파일 가능한 상태로 만들었습니다.

클린 컴파일을 달성하는 것은 절반의 성공에 불과했습니다. Bun의 방대한 테스트 스위트가 남아있었습니다. 에이전트들은 런타임 문제를 찾아내고 해결하기 위해 실패한 스택 트레이스에 집중하며 끊임없는 디버깅 주기에 참여했습니다. 이 마지막 노력으로 Linux, macOS, Windows에서 이전에 실패했던 972개의 모든 테스트 파일이 통과되었으며, 이는 전례 없는 엔지니어링 위업의 성공적인 완료를 알렸습니다. 재작업 동기에 대한 다른 관점은 Andrew Kelley의 My Thoughts on the Bun Rust Rewrite에서 확인할 수 있습니다.

Zig의 창시자인 Andrew Kelley는 직설적으로 말했습니다. 그의 폭발적인 블로그 게시물은 Bun의 기념비적인 재작업이 기술적 필연성이 아니라 "관계 파탄" 때문이라고 주장했습니다. Kelley는 Bun의 코드베이스가 "핵 위에 핵"을 쌓은 것이며, Zig의 확립된 메모리 관리 및 정리 모범 사례를 따르지 못했다고 주장했습니다. 그는 Zig가 `defer`를 사용하여 각 호출 사이트에서 정리를 명시적으로 작성할 것을 기대하지만, Bun이 이 관행을 간과했다고 지적했습니다.

Kelley는 use-after-free 또는 double-free 오류와 같은 Bun의 인지된 안정성 문제는 Rust로의 급진적인 언어 교체가 아니라 집중적인 엔지니어링 노력으로 해결할 수 있다고 주장했습니다. 그는 Jarred Sumner의 관리 스타일을 직접적으로 비판하며 기술 논쟁에 날카로운 인간적인 면모를 더했고, 이 과정에서 "취향 없는 AI 애호가들"을 언급했습니다.

Kelley의 핵심 질문은 재작업의 전제 자체에 도전했습니다. 만약 Bun의 테스트 스위트가 백만 줄의 AI 생성 코드를 검증할 만큼 강력했다면, 왜 원래 Zig 구현의 버그를 잡기에는 충분하지 않았는가? 이 날카로운 질문은 깊은 이념적 균열을 강조하며, 기술적 마이그레이션을 개발자 생태계에 중대한 영향을 미치는 전면적인 언어 전쟁으로 변모시켰습니다.

Bun은 왜 코드베이스를 Zig에서 Rust로 전환했나요?

주된 이유는 안정성이었습니다. Bun 팀은 Zig의 수동 메모리 관리와 JavaScriptCore의 가비지 컬렉터 간의 상호작용에서 발생하는 use-after-free 및 double-free와 같은 메모리 안전성 버그로 어려움을 겪었습니다. Rust의 컴파일 타임 borrow checker는 메모리 안전성을 자동화하여 이러한 종류의 버그를 완전히 제거합니다.

AI 에이전트들은 Bun의 코드를 정확히 어떻게 재작성했나요?

Bun의 창시자인 Jarred Sumner는 Fable 5의 사전 출시 버전을 사용하여 64개의 Claude 인스턴스를 조율했습니다. 그는 하나의 AI 에이전트가 Rust 코드를 작성하고, 두 명의 '적대적' 에이전트가 오류를 검토하며, 최종 '수정자' 에이전트가 커밋하기 전에 제안 사항을 적용하는 에이전트 워크플로우를 설계했습니다.

Andrew Kelley (Zig 창시자)의 재작업에 대한 주요 비판은 무엇이었나요?

Andrew Kelley는 재작성이 순전히 기술적인 결정이 아니라 '관계 단절'의 결과라고 주장했습니다. 그는 Bun의 코드베이스가 '핵 위에 핵'으로 가득 차 있다고 주장했고, Jarred Sumner의 관리 스타일을 비판했으며, Bun이 Zig 버전의 버그를 수정하는 데 적절한 엔지니어링 자원을 투입한 적이 없다고 주장했습니다.

Bun에게 Rust로의 재작성은 성공적이었습니까?

네. Bun의 Rust 버전은 20% 더 작고, 2-5% 더 빠르며, 메모리 누수가 현저히 적습니다. 재작성으로 인해 19개의 새로운 회귀가 발생했지만, 이들은 신속하게 수정되었습니다. 이 프로젝트는 그 과정에서 128개의 알려진 버그를 수정했으며, 향후 개발을 위한 더 안정적인 기반을 마련했습니다.