Bun의 Rust 재작성은 정말 '11일, 16만 달러'였나 — AI 재작성 시대의 완료 정의
Bun의 Rust 재작성은 정말 ‘11일, 16만 달러’였나 — AI 재작성 시대의 완료 정의
코드가 main에 머지되면 재작성은 끝난 것인가. AI가 붕괴시킨 것은 재작성의 비용인가, 아니면 “완료”라는 단어의 의미인가.
도입
7월 27일, 개발자 Tom Lockwood가 올린 “Bun의 Rust 재작성은 어떻게 되어 가고 있나”라는 글이 Hacker News에서 453포인트와 348개의 댓글을 모았다. 발단은 7월 8일로 거슬러 올라간다. JavaScript 런타임 Bun의 창시자 Jarred Sumner는 Bun의 코드베이스를 Zig에서 Rust로 전면 재작성했으며, 이 작업을 Anthropic의 Claude를 활용해 완료했다고 발표했다. 공개된 수치는 업계를 술렁이게 하기 충분했다 — 5월 3일부터 14일까지 11일, API 비용 $165,000 (하루 약 $15,000).
수백만 명이 쓰는 런타임의 언어 전환을 2주 만에, 시니어 엔지니어 한 명의 연봉보다 적은 돈으로. 이것이 사실이라면 소프트웨어 산업의 비용 구조에 대한 통념 하나가 무너지는 사건이다. Lockwood의 글은 바로 그 “사실이라면”을 검증하려는 시도다. 그리고 그가 공개 데이터에서 끌어낸 그림은 발표문과 상당히 다르다.
Bun이 어떤 프로젝트인지를 상기하면 무게가 더해진다. Bun은 Node.js보다 빠른 시작 시간과 내장 번들러·테스트 러너를 무기로 2022년 등장해, npm을 대체하는 패키지 매니저로 광범위하게 쓰이는 인프라급 소프트웨어다. Zig라는 비주류 언어의 최대 규모 실전 사례이기도 했다. 그 코드베이스 전체를 다른 언어로, AI로, 2주 만에 옮겼다는 발표는 그래서 단순한 프로젝트 소식이 아니라 업계 전체를 향한 실증 주장이었다.
이 글이 다루는 것은 Bun이라는 프로젝트 하나의 진위 공방이 아니다. AI 에이전트가 대규모 재작성의 한계 비용을 극적으로 낮춘 시대에, “완료”를 무엇으로 정의하고 무엇으로 검증할 것인가라는, 앞으로 모든 엔지니어링 조직이 마주할 질문의 첫 공개 사례 연구다.
발표문과 공개 데이터의 간극
Lockwood가 짚은 사실들을 나열해 보자. 모두 공개 저장소와 CI 대시보드에서 확인 가능한 수치다.
첫째, 릴리스가 없다. 재작성 브랜치가 main에 머지된 지 6주가 지난 7월 27일 시점에도 릴리스 태그가 없다. 직전 릴리스는 5월 12일 — 11주 전이다. 몇 주 간격의 릴리스를 유지해 온 Bun의 역사에서 전례 없는 공백이다. 재작성이 “끝났다”면, 그 결과물은 왜 아직 사용자에게 도달하지 않았는가.
둘째, PR 적체가 폭증했다. Claude가 생성한 PR을 올리는 봇 계정 robobun의 미처리 PR은 7월 9일 1,277건에서 7월 27일 2,475건으로 18일 만에 거의 두 배가 되었다. 머지 1건당 CI가 40-90분 걸리는 현재 파이프라인 처리량으로는 이 적체를 소화하는 데만 86일 치의 CI 시간이 필요하다는 계산이 나온다. 생성 속도가 검증 속도를 압도하고 있다.
셋째, 회계가 불완전하다. $165,000는 Anthropic API 비용만이다. 다중 플랫폼 테스트를 도는 Buildkite CI 비용은 공개되지 않았고, Anthropic 직원이 직접 관여한 정황은 계산에 없는 인건비를 시사한다. Lockwood는 재작성 발표 이후에도 하루 $10,000 규모의 지출이 계속되는 것으로 추정하며, 총비용이 $800,000 방향으로 향하고 있을 수 있다고 본다.
HN 스레드에서 Sumner도 반론을 폈다. 요지를 옮기면, Rust로 재작성된 Bun은 이미 한 달 넘게 Claude Code에 실려 출하되어 있었고 아무도 눈치채지 못했다는 것이다 — 수백만 사용자 환경에서 가시적 문제 없이 돌아갔다면 그것이 실전 검증이라는 논리다. CI 비용에 대해서는 다중 플랫폼 테스트에 필연적인 지출이라고 방어했다. 이에 대한 재반론도 날카로웠다. 한 코멘터는 Claude Code라는 단일 워크로드가 쓰는 기능 부분집합만으로 재작성의 완성을 주장하는 것은, Unreal Engine 5를 다른 언어로 이식해 놓고 테트리스가 돌아간다고 완성을 선언하는 것과 같다고 꼬집었다 (HN 코멘트 요지 발췌).
’완료’의 세 가지 정의
이 공방을 정리하면, 쟁점은 사실관계가 아니라 “완료”의 정의다. 역사적 맥락을 먼저 깔아 두자. 전면 재작성은 소프트웨어 공학에서 오랫동안 금기였다. Joel Spolsky가 2000년에 쓴 “절대 하지 말아야 할 일”은 Netscape가 브라우저 엔진을 처음부터 다시 쓰기로 한 결정을 “단일 최악의 전략적 실수”로 지목했고, 이 교훈은 한 세대의 엔지니어링 조직에 내면화되었다. 재작성이 금기였던 이유는 두 가지 비용 때문이다 — 다시 쓰는 동안 멈추는 기능 개발의 기회비용, 그리고 기존 코드에 축적된 엣지 케이스 지식의 소실. AI 재작성은 첫 번째 비용을 극적으로 줄인다. 11일이면 기회비용은 무시할 수준이다. 그래서 이번 사례가 중요하다 — 금기를 지탱하던 두 비용 중 하나가 사라졌을 때, 나머지 하나(지식의 소실)만으로 금기가 유지되는지를 보여주는 첫 실험이기 때문이다.
그 위에서, 세 개의 서로 다른 완료가 경합하고 있다.
정의 1: 코드가 존재한다 (머지 기준). Sumner의 발표가 딛고 선 정의다. Rust로 작성된 코드베이스가 main에 있고 컴파일되며 주력 워크로드를 돌린다. AI 재작성은 이 정의의 달성 비용을 실제로 붕괴시켰다. 11일과 $165,000라는 숫자 자체는 아마 거짓이 아닐 것이다 — 그 정의 안에서는.
정의 2: 사용자에게 출하되었다 (릴리스 기준). 전통적 정의다. 모든 지원 플랫폼에서 테스트를 통과하고, 버전이 태깅되고, 기존 사용자가 업그레이드할 수 있다. 이 정의로는 재작성은 11주째 미완이다. 릴리스 공백과 2,475건의 PR 적체는 정의 1과 정의 2 사이의 거리를 보여주는 계기판이다.
정의 3: 조직이 코드를 이해한다 (유지보수 기준). 가장 조용하지만 가장 무거운 정의다. HN의 한 경험 많은 개발자는 앞으로의 지원과 수정의 필요를 지적하며, 급속한 LLM 재작성은 개발자의 깊은 이해를 만들지 못하고, 그런 프로젝트가 역사적으로 어떻게 방치되어 왔는지를 경고했다 (HN 코멘트 요지 발췌). 인간 팀이 재작성을 하면 그 과정에서 조직에 코드 이해가 축적된다. AI가 재작성을 하면 코드는 새것이 되지만 이해는 축적되지 않는다 — 오히려 기존 Zig 코드베이스에 대한 이해마저 감가상각된다.
흥미로운 대조군이 같은 주에 나타났다. 7월 24일 HN에는 Buz — Bun을 현대적 Zig 관행으로 포크해 1초 미만의 증분 빌드를 달성했다는 프로젝트 — 가 304포인트를 모았다. Buz 측 주장의 요지는 Bun의 문제가 Zig라는 언어가 아니라 자초한 구조에 있었다는 것이다 (커뮤니티 주장 요지, 검증되지 않음). 진위와 별개로, 이 포크의 존재는 “Zig에서 Rust로”라는 프레임 자체가 재작성의 본질이 아니었을 가능성을 시사한다. 언어 전환이 목적이었다면 포크가 보여주듯 다른 길이 있었다. 그렇다면 이 재작성의 실제 기능은 무엇이었나 — 기술적 필요인가, AI 역량의 실증인가.
Lockwood는 후자의 냄새를 맡는다. 그는 동료들이 이 재작성을 AI 능력의 증명으로 “숨 가쁘게” 축하하는 것을 경계하며, 기업의 높은 밸류에이션을 떠받치는 주장에는 회의주의가 기본값이어야 한다고 쓴다. Bun은 Anthropic과 협업 관계이고, “Claude가 11일 만에 런타임을 재작성했다”는 서사는 양쪽 모두에게 상업적 가치가 있다. 서사의 이해관계자가 서사의 검증자를 겸하고 있는 구조 — 이것이 이 사례에서 가장 구조적인 문제다.
재작성 경제학의 재편
이 사례에서 실무자가 꺼낼 수 있는 교훈을 정리한다.
병목의 이동을 계획하라. AI는 코드 생성의 비용을 붕괴시켰지만 검증의 비용은 건드리지 못했다. robobun의 2,475건 적체는 이것의 정량적 증거다. 생성이 공짜에 가까워질수록 조직의 처리량은 CI 용량, 리뷰 인력, 릴리스 엔지니어링이 결정한다. AI 도입 계획에서 토큰 예산보다 먼저 세워야 하는 것은 검증 파이프라인의 증설 계획이다.
CI 경제학을 다시 계산하라. 머지 1건당 40-90분이라는 CI 시간은 인간 개발자의 PR 빈도에 맞춰 설계된 것이다. 하루 수십 건을 올리는 에이전트 앞에서 이 설계는 즉시 파산한다. 대응은 두 방향뿐이다 — CI를 에이전트 처리량에 맞춰 증설하거나(비용 폭증), 에이전트의 생성량을 CI 처리량에 맞춰 스로틀링하거나(AI 도입 효과 반감). robobun의 적체는 이 선택을 미룬 결과로 읽힌다. AI 도입 품의서에 토큰 비용만 적혀 있다면 그 품의서는 총비용의 절반 이하를 보고 있는 것이다.
완료 선언에 릴리스 기준을 요구하라. “AI로 X를 했다”는 발표가 앞으로 쏟아질 것이다. 그때마다 물어야 할 질문은 이번 사례가 정확히 가르쳐 준다 — 어느 정의의 완료인가. 태그가 있는가. 전체 테스트 스위트가 도는가. 롤백 계획이 있는가. 발표 시점과 릴리스 시점의 간격이야말로 AI 성과 주장의 가장 정직한 지표가 될 것이다.
이해의 감가상각을 회계에 넣어라. 재작성 전의 Bun에는 Zig 코드를 깊이 아는 소수의 인간이 있었다. 재작성 후의 Bun에는 Rust 코드를 깊이 아는 인간이 몇 명인가. AI가 짠 코드의 장애를 AI가 디버깅하게 하면 되지 않느냐는 반론이 있겠지만, 그 루프가 실전 장애 상황에서 검증된 사례는 아직 없다. 유지보수 가능성은 코드의 속성이 아니라 코드와 조직 사이의 관계의 속성이고, 재작성은 그 관계를 리셋한다.
전망하자면, 이런 유형의 공방은 늘어날 수밖에 없다. AI 재작성의 한계 비용이 낮아질수록 “일단 다시 쓰고 발표하는” 유인은 커지고, 검증되지 않은 완료 선언과 실제 출하 사이의 간극은 커뮤니티의 탐정 작업 — 이번처럼 공개 PR 카운트와 릴리스 태그를 대조하는 — 으로만 드러난다. 어쩌면 필요한 것은 AI 시대의 새로운 관례다. 재작성 발표에 릴리스 태그와 전체 테스트 통과 증거를 첨부하는 것, 말하자면 성과 주장의 재현 가능성 규범이다.
결론
리드 질문으로 돌아가자. AI가 붕괴시킨 것은 재작성의 비용이 아니라 “완료”라는 단어의 해상도다. 코드 생성이라는 의미의 완료는 정말로 11일과 $165,000에 가능해졌을 것이다. 그러나 출하라는 의미의 완료는 11주째 오지 않았고, 조직적 이해라는 의미의 완료는 측정조차 시작되지 않았다. 세 정의의 간극을 한 단어로 뭉뚱그린 발표는, 의도가 무엇이든, 업계 전체의 기대치를 왜곡한다.
Lockwood의 결론 문장이 적절한 마침표다 — “재작성이 ‘끝났다’는 것, 혹은 $165,000로 ‘끝났다’는 것을 액면 그대로 받아들일 수는 없다”. 당신의 조직에서 다음 AI 성과 보고를 받을 때, 그 “완료”는 세 정의 중 어느 것인지 — 그리고 나머지 두 정의의 비용은 누구의 예산에 계상되어 있는지 물어보라.
출처: