Bun이 6일 만에 Rust로 다시 작성된 건에 대하여
요약
Bun의 창립자가 Zig에서 Rust로 약 96만 행에 달하는 대규모 코드를 단 6일 만에 재작성하여 main 브랜치에 머지시킨 사건을 분석한 글입니다. 이 과정은 Anthropic이 자사 AI인 Claude를 활용해 자체 런타임을 포팅했다는 점에서 주목받습니다. 필자는 이 거대한 코드 변경이 전통적인 '코드 리뷰'의 개념을 근본적으로 변화시키고 있으며, 단순히 기술적 난이도를 넘어선 개발 프로세스에 대한 질문을 던지고 있습니다.
핵심 포인트
- Anthropic은 자사 AI인 Claude를 활용하여 Bun 런타임을 Zig에서 Rust로 대규모 포팅(약 96만 행)했습니다.
- 이러한 초고속 코드 생성 및 머지 과정은 전통적인 '코드 리뷰'의 개념을 무력화시키며, 자동 테스트와 AI 신뢰에 의존하는 새로운 개발 표준을 제시하고 있습니다.
- Bun의 재작성 동기 중 하나는 기존 Zig 구현에서 발생하던 만성적 메모리 누수 문제를 해결하기 위함입니다.
- 이 사건은 대규모 코드 변경 시 인간의 검토(review)가 아닌, 자동화된 테스트와 AI의 재생성 가능성을 신뢰하는 방향으로 개발 프로세스의 패러다임 변화를 예고합니다.
서론
2026년 5월 14일, JavaScript 런타임 Bun의 Zig→Rust 대규모 이식 PR이 main 브랜치에 머지(merge)되었다. 약 96만 행의 코드를 6일 만에 AI(Claude)가 작성했다. 테스트는 99.8% 통과하였고 바이너리 크기도 축소되었으나, unsafe 블록은 13,000곳을 넘어섰으며, Sumner 본인도 "전부 폐기할 가능성이 높다"라고 발언했다.
이 일련의 움직임을 쫓으며, 처음 보았을 때 품었던 5가지 소박한 의문을 정리했다.
우선, 무슨 일이 일어났는가
시계열로 압축하면 다음과 같다.
2026/05/05: Bun 창립자 Jarred Sumner, "Anthropic 내부에서 Zig→Rust 시험 포팅을 진행 중"이라고 공표
2026/05/09: Linux x64 (glibc)에서 테스트 99.8% 통과를 본인이 발표
2026/05/12: Bun 1.3.14 릴리스. Sumner "만약 머지된다면, 이것이 마지막 Zig 버전"이라고 발언
2026/05/14: 100만 행 이상의 단일 PR이 main에 머지
규모감을 숫자로 나열한다.
| 항목 | 수치 |
|---|---|
| 추가된 Rust 코드 | 약 96만 행 |
| ... | unsafe 블록 |
| 13,000곳 초과 |
참고로 Bun은 Anthropic에 인수된 프로젝트이며, AI 코딩 도구로는 **Claude (Anthropic 자사 제작)**가 사용되었다. 즉, 이것은 Anthropic이 자사의 AI로 자사의 런타임을 다시 작성했다는 구도이기도 하다. 이 점은 의문 ③ 이후에서 몇 번 등장한다.
공식 상세 블로그는 2026/05/15 시점에서는 미공개 상태이다. 정보는 Sumner의 X 게시물, PR 타임라인, The Register 등의 보도에 흩어져 있다.
의문 ① 100만 행, 아무도 안 읽었잖아
솔직히 말해서, 이것이 첫 번째 걸림돌이었다. 100만 행의 코드를 6일 만에 생성했는데, 누가 리뷰했을까.
「읽을 수 있는」 물리량의 문제
가령 1초에 1행을 리뷰할 수 있다고 가정하면, 100만 행은 약 11.5일이 걸린다. 목욕도 화장실도 수면도 없이 말 그대로 눈으로 쫓기만 하는 속도다. 실제 리뷰에서는 "읽기", "생각하기", "테스트하기", "문맥을 거슬러 올라가기"가 포함되므로, 시간당 60행 정도가 현실적이라는 통계도 있다. 그것을 적용하면 100만 행은 약 1.9년 동안 풀타임으로 계속 리뷰해야 겨우 한 바퀴를 도는 규모가 된다.
Bun은 이것을 6일 만에 생성하고, 5일 만에 main에 넣었다.
GitHub도 곤란해하고 있다
실제 PR에서, Bun 리포지토리의 Zig 삭제 PR이 GitHub의 자동 시스템에 의해 "AI slop" 플래그가 지정되는 작은 사건이 발생했다. GitHub가 "이것은 AI가 생성한 저품질 코드인가?"라고 자동으로 의심했다는 것이다.
즉 AI 스스로가 AI 생성 코드의 대규모 삭제를 보고 의심했다는, 다소 초현실적인 상황이 발생하고 있다.
「읽을 수 없음」을 분해하기
"아무도 안 읽었다"를 분해하면 다음과 같다.
| 「읽는다」의 의미 | 100만 행에 대해 성립하는가? |
|---|---|
| 각 행의 문법·의미를 눈으로 쫓는다 | 물리적으로 불가능 |
| ... |
즉 Bun의 Rust 이식에서는, "자동 테스트가 통과함"을 "리뷰가 통과함"으로 조용히 대체하고 있다고 읽을 수 있다. 이것은 전통적인 코드 리뷰의 관념과는 다른 무언가다.
소감: 놀라운 것은 AI가 아니라 리뷰 개념 쪽이다
내가 놀란 것은 "AI가 96만 행을 쓸 수 있다"는 것보다, **"인간이 코드를 읽지 않고 머지할 수 있다고 판단한 것"**이다. 리뷰의 정의가 코드를 읽는 것에서 "테스트와 AI의 재생성 가능성을 믿는 것"으로 조용히 슬라이드하고 있다.
이것이 Bun이기 때문에 허용되는 특수한 사례인지, 앞으로의 표준인지. 나는 알 수 없다. 다만, AI 시대의 리뷰란 무엇인가라는 질문은 이제 피할 수 없는 지점에 와 있다는 느낌이 든다.
의문 ② 돌아가고 있는데, 왜 다시 작성하는가?
Bun은 **이미 실무(production)에서 작동 중인 JS 런타임 (JS Runtime)**이다. 그것을 6일 만에 처음부터 다른 언어로 다시 작성한다는 것은 일반적인 의사결정이 아니다. 왜 지금, 이런 일을 하는가?
보도와 Sumner의 발언을 읽어보면, 동기는 하나가 아니라 적어도 세 가지가 겹쳐 있음을 알 수 있다.
동기 ①: Claude Code가 Bun의 메모리 누수(Memory Leak)로 인해 죽어가고 있었다
이것이 가장 직접적인 트리거인 듯하다.
무슨 일이 일어나고 있었나
메모리 누수 (Memory Leak)란, 확보한 메모리를 해제하는 것을 잊어버려 불필요한 메모리가 프로세스 내에 쌓여가는 현상을 말한다. 장시간 구동되는 서버나 에디터가 점차 무거워지는 원인 중 하나다. Zig는 수동으로 메모리를 관리하는 언어로, allocator.free()를 호출하는 것을 잊으면 누수가 발생한다.
Bun에는 만성적인 메모리 누수 문제가 있었으며, Bun의 **최대 고객인 Claude Code (Anthropic이 자체 제작한 AI 코딩 도구)**의 세션에서 메모리 사용량이 14GB, 심한 경우 23GB까지 부풀어 오르는 현상이 보고되고 있었다.
※ "Rust로 바꾸면 누수가 전부 사라지는가?"에 대해서는 의문 ④에서 심층적으로 다룬다. 먼저 결론만 말하자면,
사라지는 것은 일부뿐이다.
여담: 사실 나도 같은 문제와 싸우고 있었다
솔직하게 써두겠다. 내 환경에서도 Claude Code는 무거웠다. Bun 프로세스의 메모리가 계속해서 부풀어 올랐고, 쉘(Shell)이나 MCP 서버 등의 자식 프로세스도 좀비(Zombie) 상태로 남았다. 참다못해, claude clean이라는 자작 쉘 명령어로 Claude Code 관련 프로세스를 매번 전부 kill 하는 운영 방식으로 타협하고 있었다.
즉, Anthropic이 런타임 자체를 다시 작성하여 해결하려 했던 문제와, 내가 claude clean으로 대증요법을 하고 있던 문제는,
뿌리를 공유하고 있었다는 뜻이 된다. 당사자로서 쓸 수 있는 기사가 되어버렸다.
구도
Anthropic이 2026년에 Bun을 인수했다는 점을 떠올리면, 구도는 다음과 같다.
- Anthropic이 인수한 Bun이, Anthropic의 주력 AI 코딩 도구인 Claude Code를 불안정하게 만들고 있었다 $\rightarrow$ 해결책으로서, **Anthropic의 AI (Claude)**를 사용하여 Bun 자체를 메모리 안전한 언어 (Rust)로 다시 작성했다
Dogfooding이 극단적으로 작용한 것이라기보다, 자사의 문제를 자사의 AI에게 자사의 손으로 풀게 했다는 구도에 가깝다. 투명성은 높은 반면, 외부에서 보기에는 "Bun의 의사결정은 이제 Anthropic의 제품 편의성과 강력하게 결합되어 있다"라고도 읽힐 수 있다.
동기 ②: Rust 생태계의 "contributor pool"
Sumner 본인이 반복해서 언급하고 있는 것은, Rust = 컨트리뷰터(Contributor) 인구가 압도적으로 많다는 현실적인 계산이다.
| 관점 | Zig |
|---|---|
| 언어의 안정성 | 1.0 미발표 |
| ... |
Sumner는 "Rust로의 이행은 raw performance 때문이 아니라 생태계 통합을 위한 것"이라고 명시했다. 인수 후의 Bun은 "개인 OSS"에서 "회사 제품"으로 성격이 변하고 있으며, 회사 제품으로서 필요한 인력을 채용할 수 있는 언어로 옮겨갔다는 것이 현실적인 해석이다.
동기 ③: Zig 커뮤니티의 "AI 컨트리뷰션 금지" 방침
이것은 간과하기 쉽지만 중요한 요소다.
Zig는 공식적으로 **"AI 생성 코드를 통한 컨트리뷰션(Contribution)을 받지 않는다"**는 방침을 내세우고 있다. Bun은 Zig의 포크(Fork) 버전을 사용하고 있었으나, **Zig 메인테이너(Maintainer)는 "AI 없이도 Bun의 업스트림(Upstream) 머지는 환영하지 않는다"**라고 표명했다.
즉 Bun은, 자신들의 개발 스타일 (AI를 전면 활용)이 업스트림인 Zig와 양립할 수 없다는 정치적인 막다른 길에 처해 있었다. Rust로의 이행은 기술적 판단인 동시에, "AI를 당당하게 사용할 수 있는 커뮤니티"로의 이주이기도 하다.
정리: 세 가지 동기의 무게
나열하면 다음과 같다.
| 動機 | 種類 | 緊急度 |
|---|---|---|
| ① Claude Code のメモリリーク | 自社事業の損害 | 高（即時） |
| ... | ||
| ①が「なぜ今やったか」、②③が「なぜ Rust なのか」 を説明している、と読むのが自然だろう。 |
所感：合理性はあるが、急ぐ必要はあったか
3 つの動機はどれもそれなりに筋が通っている。「無謀に見えてビジネス的には合理的」 という典型例だ。
ただ、①の解決策として「ランタイム全体を別言語に書き換える」は オーバーキル にも見える。リークの根本原因を特定して個別修正する、という選択肢もあったはずだ。それを採らなかったのは、「人力で直し続けるより AI に書き直させる方が速い」 と判断した、ということだろう。
この判断が正しかったかどうかは、これから半年〜1年で答えが出る。 私としては「合理性は分かる、ただし健全性は別物」というところで止めておきたい。
疑問③ パフォーマンス落ちないのか？
ランタイム全体を別言語に書き換えたら、普通は 速度が落ちないか心配する はず。Bun の場合はどうなのか。
Sumner 本人の発言
Sumner は「performance is neutral or faster（性能は同等か速くなる）」と発言している。ただし、2026/05/15 時点で具体的なベンチマーク数値は未公開。公式ブログでの詳細発表が予告されている段階だ。
つまり、「現時点で性能は落ちていないと本人は言っている、ただし第三者の独立検証はまだ存在しない」 というのが正確な状況。
なぜそんなに変わらないと言えるのか？
実は Bun の速さの大半は、Zig/Rust という言語選択ではなく、アーキテクチャ的な決定 から来ている。これが今回の移植で重要な前提になる。
| Bun が速い理由 | 移植で変わる？ |
|---|---|
| JavaScriptCore を採用（V8 ではなく） | |
| 変わらない | |
| libuv なしの内蔵 HTTP サーバー | |
| 変わらない | |
| 統合ネイティブバンドラ | |
| 変わらない | |
| データ構造・アルゴリズム | 同じ設計を Rust に移植 |
つまり「JS の実行速度」「HTTP throughput」のような ユーザーが体感するメトリクス は、ランタイムの実装言語を変えても 構造的にほぼ動かないはず、というのが理屈だ。
補足：JavaScriptCore とは何者かJavaScriptCore（JSC）は
C++ で書かれた JS エンジン。Apple 製で、Safari に積まれている。Bun は Zig 時代も Rust 時代も「JSC を呼び出すホスト言語」というポジションで、JS の高速実行は JSC の手柄。つまり Bun の「JS が速い」は Zig や Rust の手柄ではなく、JSC を選んだという建築的決定の手柄だ。
コンパイル時間
Sumner によると、コンパイル時間は次のような関係になっている。
- Bun の
custom Zig compilerを使った場合 →Rust 版は Zig 版と同等 -
上流の Zig compilerを使った場合 →Rust 版の方が速くコンパイルされる
「ビルドが激遅になる」というネガティブインパクトは、現時点では報告されていない。
独立検証はまだ存在しない
ここまでの主張は すべて Sumner 自身か Anthropic 由来。第三者による「Rust Bun vs Zig Bun」の差分ベンチマークは、2026/05/15 時点では公開されていない。
dev.to などに早期ベンチマーク記事はあるが、それらは 「Bun vs Node」の比較 であり、「Rust Bun vs Zig Bun の差分検証」ではない。両者を混同しないよう注意が必要だ。
所感：性能はもう論点じゃない
性能観点で言えば、「Rust にしたから速くなる」という売り方は弱い。Sumner 自身もそう売っていない（エコシステム判断だと明言している）。「同等のパフォーマンスを、より管理しやすいコードベースで」 が今回の Rust 移植の現実的な spin だ.
이것을 프론트엔드 진영의 언어로 번역하자면 **「React vs Vue는 성능 차이가 아니라 개발 경험(DX)으로 선택한다」**라는 논의와 구조가 유사하다. 성능의 극대화는 별도의 레이어(JSC 등)에서 수행하고, 런타임 본체는 개발 용이성을 기준으로 선택한다는 레이어 분리가 깔끔하게 드러난 사례라고도 읽을 수 있다.
성능은 떨어지지 않았지만, 성능을 위해 Rust로 바꾼 것도 아니다. 논점은 더 이상 그곳에 있지 않다는 것이 의문 ③에 대한 잠정적인 답변이다.
의문 ④ 그렇게 한꺼번에 바꿔도 버그는 괜찮을까?
이 부분이 아마도 가장 조마조마한 논점일 것이다.
Sumner 본인의 보험 발언
먼저 중요한 사실로서, Sumner 자신이 「전부 폐기될 가능성이 높다」라고 발언했다. Phase A라고 불리는 현재 단계는 「intent capture」, 즉 「일단 컴파일이 통과되지 않더라도 의도를 Rust로 표현하는」 단계로 위치 지어지고 있다.
즉, main 브랜치에 머지(merge)는 되었지만 「이것으로 확정」은 아니다라는 것이 Sumner 본인의 인식이다. 이는 제작자 나름의 보험이며, 동시에 「현시점에서의 품질 보증은 제한적이다」라는 시그널이기도 하다.
unsafe 13,044라는 숫자의 무게
공개된 정보에 따르면, Rust 버전 Bun에는 unsafe 블록이 13,044개 존재한다.
비교를 위해 살펴보면,
libuv의 Rust 호환 구현인 UV(동등한 역할을 하는 라이브러리)는 약 73개.
약 178배다.
이에 대해 Theo Browne(t3.gg)의 평가가 뼈아프게 다가온다.
"They aren't really writing Rust. They are writing C++ with Rust syntax."
(그들이 쓰고 있는 것은 진정한 의미의 Rust가 아니다. Rust의 문법으로 C++를 쓰고 있는 것이다)
이는 기술적으로도 타당한 지적으로, Rust의 안전성 보증 대부분은 unsafe의 외곽에서만 작동한다. 13,044곳에서 "컴파일러, 네 체크는 필요 없어"라고 말하고 있는 상태라는 뜻이다.
**「Zig였던 부분의 안전성 문제가 unsafe라는 형태로 이동했을 뿐」**이라는 해석도 가능하다.
Rust로 바꿔도 메모리 누수(Memory Leak)는 사라지지 않는다 (의문 ②의 복선 회수)
의문 ②에서 "Rust로 바꾼다고 해서 모든 누수가 사라지는 것은 아니다"라고 예고했던 부분의 확인이다.
Rust가 구조적으로 막아주는 것은 다음 세 가지에 한정된다.
| 막을 수 있는 것 | 막을 수 없는 것 |
|---|---|
| use-after-free | 메모리 누수 전반 |
| double-free | Rc의 순환 참조 |
| 데이터 경합 (Data Race) | 장수명 캐시 (Long-lived cache) |
| 버퍼 오버플로우 (일부) | 「사용하지 않지만 참조를 계속 유지하는」 상태 |
Rust 공식 문서에서도 「메모리 누수는 safe Rust에서도 발생할 수 있다」라고 명시하고 있다 (Box::leak()와 같이 의도적으로 누수시키는 API조차 존재한다).
Sumner 본인도 The Register에 "Rust가 모든 누수를 포착하는 것은 아니다"라고 인정하는 코멘트를 남겼다.
즉, Bun의 누수 문제가 **「해제 누락 타입」**이었다면 Rust 이행으로 크게 개선되겠지만, **「장수명 참조 타입」**이었다면 언어를 바꿔도 남는다. 「Zig에서 발생하기 쉬웠던 타입의 누수」를 Rust가 구조적으로 방어한다는 것이 정확한 해상도다.
Charlie Marsh (Ruff/uv의 제작자)의 질문
이와 관련하여, Charlie Marsh(Astral CEO, Ruff / uv의 제작자)가 매우 날카로운 의문을 던졌다.
"One fear I have… are you trading 200 known issues for an unknown number of unknown issues?"
(한 가지 두려운 점은... 200개의 알려진 문제를 알 수 없는 개수의 알 수 없는 문제로 맞바꾸고 있는 것은 아닌가 하는 점이다)
이것이 의문 ④의 핵심이다.
Zig 버전 Bun에는 알려진 버그가 대량으로 있었다 (그래서 누수 문제가 발생했다). 하지만 알려진 문제에는 대처할 수 있다. 보고된 버그를 해결하면 되기 때문이다.
Rust 버전 Bun에서는 그러한 알려진 버그 중 일부가 사라질 수도 있다. 하지만 AI가 6일 만에 생성한 96만 행에는 아무도 발견하지 못한 버그가 몇 개나 들어있을지 알 수 없다. 테스트 99.8% 통과(pass)는 "기존 테스트를 통과한다"는 의미이지, "새로운 버그가 없다"는 의미가 아니다.
테스트 커버리지 (Test Coverage)가 완벽하지 않는 한, 99.8% 통과는 "모르는 것을 모르는 상태"를 해소하지 못한다.
소감: 의도적으로 "모르는 상태"로 발을 들이고 있다
"버그는 괜찮은가?"라는 질문에 대한 나의 잠정적인 답변은, **"모른다기보다 의도적으로 모르는 상태로 발을 들이고 있다"**이다.
- Sumner는 "폐기 가능성이 높다"며 보험을 들어두고 있다
- unsafe 13k를 사용하여 Rust의 안전성 (Safety) 이점을 절반 정도 버렸다
- 알려진 버그를 미지의 버그로 교체하고 있을 가능성이 있다
이것들은 모두 개별적으로는 합리적인 판단이지만, 전체적으로는 큰 도박으로 보인다. 빠른 쪽으로 거는 도박이라기보다, "빠르게 할 수밖에 없는 지점까지 와 있었다"는 도박이라는 표현이 더 가까울지도 모른다.
적어도, "Rust이기 때문에 안전해졌습니다"라는 단순한 서사가 아님은 확실하다.
의문 ⑤ 제대로 작동하는가, 어떻게 검증했는가?
"테스트 99.8% 통과"라는 말이 독자적으로 떠돌고 있지만, 이 숫자가 무엇을 의미하고 무엇을 의미하지 않는지 정리한다.
검증된 것은 무엇인가
공개된 검증 정보를 나열하면 다음과 같다.
| 검증 항목 | 내용 |
|---|---|
| Linux x64 (glibc) | 기존 테스트 99.8% 통과 |
| 타 플랫폼 (macOS / Windows / ARM) | "모든 플랫폼에서 통과한다"고 Sumner가 발언, 단 구체적인 수치의 독립적 공표는 제한적 |
| 벤치마크 (Benchmark) | "neutral or faster" 발언, 상세 내용은 공식 블로그 대기 |
| 장시간 운용 / 실전 부하 | Anthropic 사내의 Claude Code dogfooding |
요컨대, 공식적으로 "99.8%"라는 숫자가 나온 것은 Linux x64 glibc의 테스트 통과율뿐이다. 그 외에는 발언 기반이거나 내부 운용에 의존하고 있다.
테스트가 담보하는 것 / 담보하지 않는 것
이 부분이 은근히 중요하다.
| 테스트가 담보하는 것 | 테스트가 담보하지 않는 것 |
|---|---|
| 작성된 테스트 케이스가 통과하는 동작 | 테스트가 작성되지 않은 동작 |
| 알려진 입력에 대한 알려진 출력 | 경합 상태 (Race Condition) |
| 동기적·단시간의 정확성 | 장시간 운용 시의 메모리 점진적 감소 (Memory Attrition) |
| 단일 프로세스의 정확성 | 플랫폼 간의 미세한 차이 |
| "고장 남"을 검출 | "미묘하게 다름"을 검출 (성능, 메모리 프로파일) |
99.8%라는 숫자는 **"Zig 시대에 작성된 테스트 스위트(Test Suite)를 Rust 버전이 통과할 수 있다"**는 뜻이다. 이는 **"Rust 버전은 Zig 버전과 거의 동일한 동작을 한다"**는 증명은 될 수 있지만, "Rust 버전에 새로운 버그가 없다"는 증명은 되지 않는다.
특히 **메모리 누수 (Memory Leak)**는 테스트로 잡아내기 어렵다. 장시간 구동해야 비로소 스며 나오는 타입의 문제이기 때문이다. 아이러니하게도, Bun의 Rust화 동기가 바로 이것이었다.
Phase A는 "intent capture" 단계
여기서 의문 ④의 Sumner 발언을 다른 각도에서 재검토한다.
Phase A는 **"컴파일이 통과하지 않더라도 좋으니, 우선 Zig의 의도를 Rust로 표현한다"**는 단계로 정의되어 있다. 컴파일을 통과시키는 것, 하물며 엄격한 검증을 마치는 것은 Phase A의 목적이 아니다.
즉, 현재 main에 있는 코드는 **"Phase A의 잠정적인 스냅샷"**이며, "Phase B에서 제대로 검증할 테니까"라는 전제가 붙은 임시 배치에 가깝다.
Anthropic의 dogfooding이 사실상의 실전 검증
여기서 Anthropic 인수가 다시 한번 작용한다.
Claude Code는 Bun 위에서 돌아가고 있다. Anthropic 사내에서는 Claude Code가 매일 수백만 명의 사용자에 의해 구동되고 있다. 이는 사실상, 테스트로는 절대 잡아낼 수 없는 타입의 문제를 찾아내는 거대한 실전 검증이 되고 있다.
다만, 여기에는 두 가지 주의점이 있다.
- Claude Code 용도에 특화된 경로만 해결할 수 있음 — Bun의 다른 사용법(Bundler, HTTP 서버, CLI 등)에 대한 검증은 별도로 필요함
- Anthropic 내부의 피드백 루프는 외부에서 보기 어려움 — "내부에서는 작동하고 있다"는 말을 믿을 수밖에 없는 부분이 남아 있음
Charlie Marsh의 "200개의 알려진 문제(known issues)를 미지의 미지(unknown unknowns)와 맞바꾸는 것"이라는 말이 검증의 맥락에서 다시금 울려 퍼진다.
외부에서 검증되지 않은 코드는 내부에서 아무리 잘 작동하더라도 "unknown unknowns" 상태로 남아 있다.
소감: 99.8%는 수치로서는 훌륭하지만, 의미상으로는 한정적이다
"제대로 검증했는가?"라는 질문에, **"수치상으로는 검증했으나, 의미상으로는 검증이 이제부터 시작이다"**라고 답하는 것이 솔직한 심정이다.
- 99.8%는 "Zig 버전과의 동작 호환성" 지표이지, **"품질 보증 (QA)"**이 아니다.
- 진정한 검증은 멀티 플랫폼 / 커뮤니티에서의 장기 사용 / 제3자 벤치마크를 통해 이루어진다.
- Phase A가 "의도 파악 (intent capture)" 단계이며 "Phase B에서 다시 작성할 가능성"을 포함하고 있는 이상, 현재의 Rust 버전으로 프로덕션(production) 채택을 판단하기에는 시기상조이다.
즉, **"Bun을 사용하는 사람은 당분간 Zig 버전 1.3.14로 상황을 지켜보는 것이 합리적"**이라는 해석도 가능하다. 이는 기술적인 판단의 문제이지, Bun을 비판하는 것이 아니다. 새로운 코드는 누군가가 먼저 밟아본 뒤에야 비로소 진짜가 된다는 것뿐이다.
남겨진 질문들
5가지 의문을 쫓아갔지만 답은 나오지 않았다. 글을 마치기 전에, 가져가고 싶은 질문 4가지를 나열해 둔다.
-
AI 생성 코드의 "리뷰"는 앞으로 무엇을 의미하게 될까?
인간이 코드를 읽지 않고, 테스트와 AI의 재생성 가능성만을 믿는 리뷰가 당연해지는 것일까? -
"알려진 버그를 대량으로 안고 있는 안정판"과 "미지의 버그를 안고 있는 재작성판", 어느 쪽을 더 신뢰할 수 있는가?
Charlie Marsh의 "200개의 알려진 문제 vs 미지의 미지"는 AI 대규모 생성 시대의 핵심적인 질문이라고 생각한다. -
이것은 Bun의 특례인가, 아니면 새로운 표준인가?
Anthropic이라는 거대한 스폰서, Claude라는 강력한 AI, Bun이라는 비교적 젊은 코드베이스. 이 세 가지 조건이 겹쳐서 비로소 가능해진 이야기로 보이기도 한다. -
오픈 소스(OSS)가 "단일 기업의 사정"으로 대개조될 때, 커뮤니티는 어떻게 관여해야 하는가?
Bun은 OSS이지만, 이번 의사결정은 거의 Anthropic 단독으로 이루어졌다. OSS의 의사결정 모델이 흔들리고 있는 것처럼 보인다.
나의 잠정적인 기분은 "대단하다"와 "무섭다"가 반반이다. AI로 96만 줄을 6일 만에 써낼 수 있는 시대의 입구에 서 있다는 사실은 인정할 수밖에 없다. 한편으로, 그것을 프로덕션 브랜치에 넣는 판단은 아무나 따라 해서는 안 되는 일이라고도 생각한다.
나는 조금 더, 스스로 코드를 들여다보는 삶을 계속하고 싶다.
참고 링크
- Anthropic's Bun Rust rewrite merged at speed of AI - The Register (2026/05/14)
- Anthrophic's Bun team trials port from Zig to Rust - The Register (2026/05/05)
- The Great Zig-to-Rust Experiment - Rust Bytes
- Theo: Bun Rewrites 960,000 Lines From Zig to Rust in Six Days — 13,000 Unsafe Blocks Remain - BigGo Finance
- Bun Migrates from Zig to Rust: What My Real Benchmarks Say - dev.to
- Bun v1.3.14 - Bun Blog
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기