Bun의 Rust 재작성은 어떻게 진행되고 있나?

• 11일 만에 끝난 작업으로 알려졌지만, main 병합 후 6주가 지난 2026년 7월 27일에도 릴리스 태그가 없고 관련 작업이 계속되고 있음
• 최초 재작성에는 2026년 5월 3~14일 Anthropic API 비용 16만5천 달러가 들었으나, Buildkite CI/CD와 후속 작업 비용은 포함되지 않은 것으로 보임
• robobun의 열린 PR은 7월 9일 1,277개에서 7월 27일 2,475개로 증가했으며, PR당 파이프라인이 약 40분 걸린다면 모두 처리하는 데 86일간 연속 실행해야 함
• Claude 사용량이 재작성 시작과 함께 급증하고 robobun과 Anthropic 직원의 Rust 작업 참여도 늘어, 완료 시점과 실제 총비용을 16만5천 달러로 단정하기 어려움
• Bun 팀이 재작성 완료와 총비용을 직접 단정한 것은 아니므로, AI 코딩 성과를 기업 가치 평가의 근거로 삼으려면 비용 대비 가치와 지속적인 인력 개입까지 살펴야 함

---

병합 이후에도 이어지는 재작성

• Jarred Sumner는 Rewriting Bun in Rust에서 2026년 5월 3~14일 11일 동안 Anthropic API 호출에 16만5천 달러를 쓰고 재작성 결과를 main에 병합했다고 밝힘
  • 하루 약 1만5천 달러로, 많은 오픈소스 유지보수자가 감당하기 어려운 규모임
  • 조직의 Buildkite 클러스터에서 계속 실행된 것으로 보이는 CI/CD 비용은 이 수치에 포함되지 않은 것으로 보임
• 2026년 7월 27일 기준 병합 후 6주가 지났지만 새 릴리스 태그가 없으며, 마지막 태그 bun-v1.3.14 이후로는 11주가 지남
  • 이전에 한 달 이상 릴리스가 없었던 때는 2022년 10월 26일 v0.2.2부터 12월 7일 v0.3.0까지 이어진 6주 공백이었음
• Claude Code가 만든 PR의 대리 지표인 robobun 열린 PR은 7월 9일 1,277개에서 7월 27일 2,475개로 늘어남
  • Buildkite 검사와 main 병합에는 대체로 약 40분, 때로는 1시간 30분까지 걸리는 것으로 관찰됨
  • PR당 40분을 적용하면 2,475개를 모두 병합하려면 파이프라인을 86일 연속 실행해야 함
  • 일부 PR은 Rust 코드와 관련이 없으며, 개별 PR 중에는 매우 많은 검토를 거친 사례도 있음

공개 비용과 실제 투입의 차이

• 재작성 시작 시점에 Claude 사용량이 크게 증가했고, 이후 Anthropic 직원과 robobun의 Rust 작업 참여도 늘어나는 흐름을 보임
  • 분석에는 재작성 기간 Jarred Sumner의 커밋이 Claude를 사용했다는 가정이 포함됨
  • 일부 PR은 Anthropic 직원이 작성했으므로 토큰 비용뿐 아니라 직원의 직접 개입도 고려해야 함
• 재작성이 계속 하루 1만 달러씩 든다고 가정하면 누적 비용은 약 80만 달러에 가까워지지만, 이는 공개된 실제 비용이 아니라 가정에 따른 추산임
• Bun 팀은 재작성이 완전히 끝났거나 총비용이 16만5천 달러뿐이라고 주장하지 않았음
  • 이번 사례만으로 AI가 오픈소스 유지보수자의 작업을 더 빠르게 대체했다고 받아들이기는 어려움
  • Anthropic은 자사 도구를 내부 적용하고 있으며, 자동화 작업과 직원 참여도 계속되고 있음
• AI 자체를 부정하기보다 현재의 과도한 기대와 기업 가치 평가를 경계하며, 투입 비용만큼 가치가 있었는지와 해당 기업 가치가 정당한지를 따져야 함
• Anthropic의 C compiler와 Cursor의 FastRender 웹 브라우저는 수개월 동안 커밋이 없었음

[GN⁺]

Hacker News 의견들

• Bun의 Rust 재작성판은 한 달 넘게 Claude Code에서 운영 중이지만 거의 아무도 눈치채지 못했고, 전반적으로 잘 작동하고 있음
  Bun v1.4 영상에서 약속한 만큼 Node.js 호환성 테스트를 통과하기 전에는 출시하지 않을 예정이며, 관련 PR이 병합되면 다음 주 화요일쯤 v1.4를 출시할 가능성이 큼

  • 소프트웨어 품질을 위해 필요한 만큼 시간을 써도 됨. 한 달간 출시가 없는 건 큰일이 아니며, 특정 기능이 급하면 직접 기여하거나 빌드할 수 있음
    Node.js도 보안 수정을 제외하면 매년 12월에 4~6주씩 의미 있는 출시가 없으므로, 당사자에게 먼저 묻지도 않고 화난 글부터 쓴 이번 비판은 근거가 약함. Node.js 유지보수자로서 하는 말임
  • Claude Code 자체에 버그와 출시 후 장애가 잦아서, 사용자가 Rust 기반 Bun 전환으로 생긴 버그와 평소 버그를 구별하지 못한 것도 놀랍지 않음
  • 글에서 추산한 비용, 특히 Buildkite 비용에 관해 답변해 줄 수 있는지 궁금함
  • 많은 바이브 코딩 프로젝트가 강하게 출발했다가 Anthropic C처럼 방치될 수 있어 Bun의 미래를 걱정하는 이유는 이해함. Bun은 빠르고 사용하기 좋으니 GCC처럼 오래 지속되길 바람

• 대규모 리팩터링이나 재작성 직후에는 평소 개발 속도를 되찾는 데 시간이 필요하므로, 커밋 수와 출시 주기만으로 많은 것을 판단하기 어려움
  개발자들은 구조가 익숙하더라도 Rust 코드베이스에는 새로 적응해야 하며, 사용자 기능보다 unsafe 사용처 추적 같은 작업에 집중하고 있을 가능성이 큼. 카나리아 채널에서도 큰 문제나 변화가 거의 감지되지 않았으므로, 서둘러 출시하기보다 밀린 작업을 처리할 이유가 충분함
  Anthropic의 C 컴파일러와 Cursor의 FastRender 브라우저는 지속 프로젝트가 아니라 역량 실험으로 봤으며, 지금 직접 사용하는 사람이 없기를 바람

  • 한 달 전에 모든 Claude Code 사용자를 새 버전으로 이전했으니, 어떤 의미에서는 이미 실서비스 출시를 한 셈임. 주목을 많이 받는 데다 정식 출시를 서두를 필요가 없어 점진적으로 진행하는 듯함
  • CI/CD 비용 관점은 흥미로움. 보통 AI 투자수익률을 반박할 때 코드가 많다고 가치가 커지는 것은 아니라고 하지만, CI 실행마다 과금한다면 실제 매출은 늘어남
    특히 AI가 만든 반복 작업이 통제 불능이 되는 것을 막으려면 CI와 추가 테스트가 핵심이라는 점도 맞물림
  • 글을 쓴 입장에서도 이 수치들로 얼마나 판단할 수 있을지 확신하지 못함. 다음 출시 후 Anthropic이나 Bun이 전체 비용을 밝히는 회고를 내놓길 기대함

• LLM으로 프로젝트를 단기간에 번역하거나 오피스 제품 복제품을 한 번에 만드는 일 자체는 놀랍지만, 소프트웨어의 본질은 빠른 초기 생성이 아니라 기능 개발과 장기 유지보수에 있음
  Word 복제품도 기본 기능은 금방 만들지만 페이지 구조, 표, 이미지, 회전 같은 세부 기능부터 LLM이 무너지기 시작함. SQLite를 C에서 Rust로 옮겨 테스트를 모두 통과시켜도 기존 구현의 수년간 최적화가 없어 느릴 가능성이 높고, 언어 전환에 따른 새 버그와 향후 지원도 감당해야 함
  Reddit에는 X, Y, Z를 구현했다는 프로젝트가 계속 올라오지만 버그 수정, 사용자 응대, 보안, 변화하는 데이터 구조와 데이터베이스 작업은 매력적이지 않아 바이브 코딩만큼 빠르게 방치되곤 함
  자신이 만든 소프트웨어를 깊이 이해하지 못하면 결국 폭발하며, X를 Y일 만에 Z로 재작성했다는 문구만으로는 아무 의미가 없음. 시작을 앞당기는 것과 포팅된 코드를 이해하고 성장시키며 유지하는 것은 전혀 다른 일이고, 유지되는 Zig판 대신 방치된 Rust판과 홍보성 글만 검색 결과를 오염시킬 수 있음

  • 이 과정을 더 많은 사람이 기록했으면 함. 개인적으로 LLM 의존도가 높은 프로젝트를 만들며 배우고 있는데, 복잡한 기능이 빠르게 작동할 때는 강한 쾌감을 주지만 통합, 정리, UI 다듬기는 초기 속도를 맛본 뒤라 오히려 더 고통스러움
    코드가 너무 임시방편으로 얽히면 LLM이 더 큰 혼란 없이 전진하지 못하는 관성 지점에 도달하며, 아키텍처를 고치거나 전부 버리고 다시 시작하거나 마지막으로 정상적이던 지점까지 되돌려야 함. 제트팩을 메고 개발하는 것처럼 목표에도 빠르게 가지만 벽에도 더 빠르고 아프게 충돌함
    AI가 최고인지 최악인지 따지는 논쟁과 도구 사용법 경쟁에 가려져, 무엇이 통하고 실패하는지, 사용 과정에서 행동을 어떻게 바꿔야 하는지에 관한 정보가 부족함. 직접 사용기도 쓰려 하지만 새 기능을 만들거나 UI 흠을 고치는 쪽이 더 재미있어 미루고 있음
  • GitHub에는 LLM 이전부터 방치된 게임 엔진과 가상 언어용 컴파일러가 수천 개 있었음. 2000년대 초 운영체제 게시판에서도 거의 모두가 자기 OS를 만들었고, 일부는 Firefox까지 실행했음
    모든 소프트웨어가 상업적이거나 완성도 높아야 유용한 것은 아니며, 학습용 실험만으로도 충분히 많은 것을 배울 수 있음
  • 기술적으로 깊어질수록 대체 가능하다고 여겨지기 쉬움. 조직에서 자신이나 관계가 아니라 순수한 기술력이 가치를 만든다는 전제를 받아들이기 때문임
    하지만 네트워크 효과, 소유권, 책임성 같은 우발적 요소도 중요하다는 사실을 받아들이기 시작한 듯함. 다만 많은 기술자가 그런 요소에 얽힌 연고주의, 자의적 평가, 기술보다 허풍이 중시되는 환경을 피해 기술 영역으로 들어왔다는 역설도 있음
  • 대규모 코드베이스를 기능 개발까지 멈추고 완전히 재작성한 스타트업에서 일했지만, 다른 프로젝트를 맡느라 과정 전체를 놓친 뒤 돌아와도 학습 곡선은 거의 없었음. 언어는 달라졌어도 핵심 아키텍처와 자료구조, 개념이 같았기 때문임
    Bun도 처음부터 재설계한 게 아니라 우선 새 언어로 그대로 옮긴 방식임. LLM 이전 경험에 비춰봐도 팀을 빨리 전환하려면 최대한 단순하고 신속하게 다른 언어로 옮기는 것이 옳으며, 재작성 기간 X일을 최소화하는 건 좋은 목표임
  • 자신이 작성한 코드를 깊이 이해하지 않는 태도는 극단적 단기주의임. 유지보수자들은 AI 생성 코드와 사람이 유지할 수 있는 코드 사이의 경계를 힘들게 배우게 될 것임

• 누군가 원래 Zig 구현을 현대화하고 모범 사례를 적용해 버그를 고치면서 1초 미만 증분 빌드를 달성했다고 함. 재작성을 정당화했던 문제가 사실 자체적으로 만든 것이며 해결 가능했음을 시사함
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  Zig판도 LLM을 사용하므로 문화 전쟁과는 무관함. 문제 영역을 제대로 이해하는 사람은 수십만 달러어치 토큰 같은 자원만 쏟아붓는 사람보다 늘 더 좋은 결과를 낼 수 있었음

  • 재작성을 정당화한 핵심은 빌드 속도가 아니라, 특히 가비지 컬렉션으로 관리되는 JavaScript 객체와 상호작용할 때 생기는 메모리 버그였음. Zig에는 이를 일반적으로 차단할 방법이 없고 Buz가 해결했다는 주장도 보이지 않음
  • 이 프로젝트는 진지한 시도보다 밈이나 농담에 가까워 보임. 기존 60만 줄을 AI가 만든 엉망인 코드라고 규정하고, 대부분의 하위 시스템을 다시 쓸 때까지 사람이 작성한 기여를 거부하겠다고 밝힘
    LLM으로 엉망인 코드를 정리하면서 인간 기여는 금지한다는 프로젝트를 진지하게 받아들이기 어려움

• Bun 재작성 덕분에 코드 포팅과 재작성, 외부 의존성 벤더링을 훨씬 과감하게 시도하게 됐으며, 상류 프로젝트에는 맞지 않더라도 내부 요구에 특화할 수 있게 됨
  코딩 모델에 더 야심 찬 작업을 맡기는 동시에 테스트 장치와 언어 경계 바깥의 검증에 훨씬 집중하게 됐음. 수년에 걸친 대규모 재작성에도 참여해 봤지만, 테스트와 기능 동등성을 유지하면서 개선까지 추가한 Bun은 엄청난 공학적 성공으로 평가함

• Bun 재작성을 둘러싼 논의에는 극적인 비난과 개인 공격이 많고, 각자 더 깊은 이념적 관심사를 투영하는 듯함. 이 글은 AI가 프로그래머를 얼마나 성공적으로 대체할 수 있는지에 회의적이며, Zig 유지보수자의 논점은 LLM 시대의 오픈소스 윤리와 미래에 더 가까웠음
  AI 역량을 낙관적으로 보는 입장에서는 숙련 개발자가 최첨단 LLM을 이끌어 전체 라이브러리를 번역할 수 있다는 데 회의적일 이유가 크지 않음. 더 중요한 후속 질문은 현재 비용과 앞으로 AI 전면 채택 진영과 비채택 진영으로 갈라질지 여부임

  • 팀에는 Rust 경험자가 아무도 없었음
  • Bun의 Zig→Rust 포팅은 Zig, Rust, 언어 포팅, LLM 사용법에 관해 일반화할 교훈을 거의 주지 못함. 전후 코드베이스에는 정량화하기 어려운 특성이 너무 많고 언어와 포팅 방식, LLM 코딩에 대한 취향도 개입됨
    같은 결과를 내지 못하거나 토큰 비용이 더 들면 도구를 잘못 썼다고 하고, 결과가 실망스러우면 단지 개념 증명이었으며 최근 6개월 사이 모델이 좋아져 비교할 수 없다고 빠져나갈 수 있어 검증 가능한 결론을 얻기 어려움
  • LLM은 그럴듯해 보이지만 틀린 결과를 만드는 데 뛰어나므로 회의적으로 볼 이유가 많음. 이번 작업은 결과의 진위와 별개로 명백한 마케팅 행사이며, Anthropic은 과장되거나 사실과 다른 발표를 해온 전력이 있어 더 엄격한 검증이 필요함

• 승리를 선언한 발표와 솔직해 보였던 심층 분석조차 다소 성급했다고 의심했음
  LLM 열풍의 핵심 위험은 타이핑과 수작업 사고에 지친 숙련 개발자에게 즉각적인 성과를 주면서, 수십 년간 쌓인 소프트웨어 경험을 담보로 쓰게 만든다는 것임. 진짜 비용 청구서는 훨씬 나중에 도착함

  • 타이핑은 소프트웨어 공학에서 부차적이지만, 정말 타이핑이 병목인 상황에서는 LLM이 가치 있을 수 있음. 다만 그런 상황은 드묾

• Rust 기반 Bun은 6월 17일부터 Claude Code에서 운영됐고 main에 들어온 뒤 카나리아판으로도 제공됐다는 사실을 글에 반영하면 신뢰도가 높아질 것임. 이 정도 규모의 재작성이라면 긴 카나리아 기간이 충분히 정당함

  • 글에서 Anthropic의 내부 실사용을 이미 다뤘음

• Anthropic은 다음 버전을 공개 출시하는 데 별 관심이 없을 수도 있음. Rust판은 한 달 넘게 수백만 명이 쓰는 Claude Code에서 운영 중이며, Bun을 인수한 목적도 Claude Code였을 가능성이 큼
  오픈소스 프로젝트 자체는 그들에게 그다지 중요하지 않을 수 있음

  • 정말 Claude Code만 중요했다면 TypeScript 런타임의 언어를 바꾸기보다 Claude Code 자체를 Rust로 재작성하는 편이 훨씬 효율적이었을 것임. 약 80만 달러의 비용은 큰 홍보 효과를 노린 Anthropic의 마케팅 예산에서 나왔을 가능성이 있음
  • 더 넓은 공동체를 포기할 가능성은 낮으며, 다른 사용자가 많을수록 Anthropic도 이익을 얻음. 이번 출시에 문제가 생기면 강한 비판을 받고 공동체 신뢰가 훼손될 수 있으므로 평소보다 조심하는 듯함
  • Bun은 웹 생태계의 주요 구성요소이므로 Anthropic이 AI로 개발한다는 사실 자체가 거대한 홍보 효과를 줌
  • Claude Code는 어떤 JavaScript 런타임에서도 실행할 수 있을 텐데, 왜 Bun이 필요했는지 궁금함
  • 결국 Claude 기반 코드 재작성 광고를 위한 마케팅 행사로 보임. 불편한 코드베이스를 없애려면 Anthropic에 큰돈을 쓰라는 메시지는 성공적으로 전달됐음
    Claude Code가 목적이었다면 그것부터 재작성하면 됐고, 더는 직접 코드를 작성하지 않는다고 강조해 왔다면 구현 언어도 중요하지 않아야 함

• 소프트웨어를 재작성해 본 사람이라면 지금 단계를 이해할 수 있음. 대부분 작동하지만 회귀가 없도록 계속 고쳐야 하고, 출시에 따르는 압박도 매우 큼
  재작성 결정은 옳았다고 보지만 처음부터 운영 환경에 배포하고 싶지는 않음. Jarred가 바로 정식판을 내기보다 출시 후보판부터 제공하면 부담을 줄일 수 있음