# Bun의 Rust 재작성 PR이 머지됨 > Clean Markdown view of GeekNews topic #29526. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29526](https://news.hada.io/topic?id=29526) - GeekNews Markdown: [https://news.hada.io/topic/29526.md](https://news.hada.io/topic/29526.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-15T10:17:14+09:00 - Updated: 2026-05-15T10:17:14+09:00 - Original source: [github.com/oven-sh](https://github.com/oven-sh/bun/pull/30412) - Points: 9 - Comments: 4 ## Topic Body - PR #30412는 **Bun을 Rust로 재작성**하는 변경으로, 2026년 5월 14일 `claude/phase-a-port` 브랜치에서 `main`으로 머지됨 - 변경 규모는 **6,755개 커밋**, 2,188개 파일, `+1,009,257`/`-4,024` 라인으로 표시됨 - Jarred-Sumner는 상세 내용이 담긴 **블로그 글**이 곧 나온다고 밝힘 - 이 변경은 Bun의 기존 **테스트 스위트**를 모든 플랫폼에서 통과하며, 여러 메모리 누수와 불안정한 테스트를 고쳤다고 설명됨 - 바이너리 크기는 **3MB~8MB 감소**했고, 벤치마크는 중립적이거나 더 빠른 범위라고 설명됨 - 가장 중요한 이유로, 팀이 수년간 큰 개발·디버깅 시간을 쓴 **메모리 버그**를 컴파일러 보조 도구로 잡고 예방할 수 있게 됐다고 제시됨 - 코드베이스는 대체로 동일하며, **아키텍처와 자료구조**도 그대로 유지됐다고 설명됨 - Bun은 여전히 서드파티 라이브러리를 적게 사용하며, **async Rust**는 사용하지 않는다고 명시됨 - 사용자는 `bun upgrade --canary`로 이 변경을 시험해볼 수 있음 - Jarred-Sumner는 문제가 생기면 이슈를 올려달라고 요청했고, 스레드가 과열되면 잠글 수 있다고 밝힘 - 비-canary 버전에 들어가기 전 아직 **최적화 작업**이 남아 있음 - 정리 작업도 아직 남아 있으며, 이는 후속 PR 시리즈로 진행될 예정임 ## Comments ### Comment 57528 - Author: xguru - Created: 2026-05-15T10:55:05+09:00 - Points: 2 와 백만라인짜리 PR 머지. Zig에서 Rust로 그냥 한번에 넘어가네요. 이거 머지될지 안될지 몰라요~~ 라고 얘기하더니, 일주일만에 잘 동작하던 코드를 한방에 언어교체 ㅎㅎ 뭔가 AI어시스트 코딩 때문에 기념비 적인 일이 일어나는 느낌. ### Comment 57546 - Author: heycalmdown - Created: 2026-05-15T15:02:48+09:00 - Points: 1 - Parent comment: 57528 - Depth: 1 진짜요 그냥 테스트 하는거고 안 쓸 가능성이 높다고 하더니 ### Comment 57550 - Author: freedomzero - Created: 2026-05-15T15:48:01+09:00 - Points: 1 zig에서 안해주니까 바로 러스트로 넘어가는 대범함 ㄷㄷ ### Comment 57517 - Author: neo - Created: 2026-05-15T10:17:14+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48132488) - 발표에서 리라이트가 **1주일** 걸렸다고 하면, Zig 관용구를 Rust 관용구로 매핑하는 이 매우 상세한 지침 파일을 준비하는 데는 시간이 얼마나 들어갔는지 궁금해짐: [https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...]() 게다가 `Pointers & ownership`와 `Collections` 섹션을 보면 Bun 코드베이스는 이미 내부 스마트 포인터 타입을 써서 Rust 대응물과 1:1로 매핑되도록 준비돼 있었고, `bun_collections` Rust 크레이트도 이미 존재함 이 리라이트는 오래전부터 준비돼 있었고 Anthropic 인수 협상 중 Bun 팀이 제안한 것처럼 보임 - LLM 관련 글을 읽을 때 뭐가 사실인지 모르겠고, 여기 Hacker News 댓글도 마찬가지임 걸린 돈이 너무 크니 커뮤니티에 **마케팅 알바**를 심을 유인이 분명하고, 일부는 그냥 진영 논리에 빠져 있음 Anthropic이 Bun을 소유한 이상, 이 작업이 실제보다 쉬워 보이게 만들 유인도 충분함 - 결과로 나온 Rust 코드의 품질이 좋은지, 줄 수가 적절한지, 코드베이스가 애초에 이 작업에 얼마나 준비돼 있었는지 같은 요소를 제쳐두면, 약 **100만 줄 출력**의 일관성이나 품질을 높일 수 있는 선행 산출물로 622줄짜리 문서는 상대적으로 작은 비용이라고 볼 수 있지 않나 싶음 출력 규모가 워낙 커서 여기에는 곱셈 효과가 있어 보임 다만 이 규칙을 만들기 위해 얼마나 많은 암묵지가 필요했는지, 이 파일을 얼마나 반복 개선했는지도 궁금함 예를 들어 이 규칙 중 얼마나 많은 것이 번역 반복 과정에서 만난 실패 사례에서 나온 것인지 알고 싶음 - `using internal smart pointer types that map 1-to-1 to Rust equivalents`라고 했지만, **스마트 포인터**는 Rust가 발명한 게 아님 포인터가 있는 다른 언어로 코드를 짜면 이미 머릿속으로 같은 타입들을 모델링하고 있음 그리고 `bun_collections` Rust 크레이트가 이미 있었다는 건 틀렸음 코드베이스의 PR 일부일 뿐이고, 이전부터 존재한 게 아님 - 이건 Anthropic의 **gcc 시연** 때와도 같음 의심을 덜고 IPO 분위기를 더 띄우는 건 아주 쉬울 텐데, AI를 몰아가기 위해 필요했던 숨은 작업을 별도 저장소로 공개하고 모두가 결과를 재현하게 하면 됨 결국 고객들이 이루려는 것도 “7일” 만에 쓸 수 있는 코드 100만 줄 아닌가 모두가 자기 워크플로에 재현해 보면서 Anthropic 사용량 지표도 올라갈 것임 정말 멋진 결과였다면 링크와 지침이 달린 블로그 글부터 냈을 것 같음 지금 이 순간 블로그 글이 작성 중이라 내가 틀렸음이 증명될 수도 있긴 함 - Zig 버전 Bun에는 기존 Rust 포인터 타입에 깔끔하게 매핑되는 포인터 타입이 3개 있었던 것 같고, 나머지 7~8개는 새 타입을 만들어야 했던 듯함 그게 음모론의 핵심인가 `bun_collections`도 포팅 가이드보다 훨씬 오래돼 보이진 않음 - `+1009257 -4024`라니, Bun은 이제 **Rust 코드 100만 줄**을 넘김 Rust 컴파일러 자체의 크기에 가까워지고 있음 다만 BunJS는 대체로 JavaScript 인터프리터 래퍼와 NodeJS 라이브러리 재구현, 즉 Rust 표준 라이브러리 래퍼에 가까움 BunJS는 LLM 시대의 **소프트웨어 복잡도 관리**를 보여주는 카나리아가 되어가는 것 같음 - `mostly a JavaScript interpreter wrapper`는 정확하지 않음 Bun은 배터리 포함 JavaScript 및 CSS 트랜스파일러(파서), 축소기, 번들러, npm 같은 패키지 관리자, Jest 같은 테스트 러너이고, 내장 Postgres, MySQL, Redis 클라이언트 같은 런타임 API도 갖고 있음 자연히 코드가 엄청 많아질 수밖에 없음 - Bun은 JavaScript 인터프리터가 아니라 NodeJS 라이브러리와 여러 다른 라이브러리의 재구현에 가까움 Bun은 JavaScriptCore를 JS 엔진으로 사용하므로 Bun 자체는 JavaScript 파싱, 해석, JIT를 하지 않거나 적어도 하지 않아야 함 수정: 잘못 읽었음. “JavaScript interpreter wrapper”라고 했으니 맞는 표현임 - iOS에서 전화번호로 감지되는 게 앞의 `+` 때문인지 다른 요인도 있는지는 모르겠지만, 모바일에서는 **줄 수 변경량**에 밑줄이 생기고 탭하면 전화를 걸 수 있음 diff 크기 때문에 그런 거라면 꽤 웃김 - Bun 코드베이스는 리라이트 전에도 **비슷한 코드 줄 수**였음 리라이트 결과가 비슷한 LOC로 나오는 건 이상한 일이 아님 - JavaScriptCore 래퍼가 **100만 줄**이라는 건 에이전트가 무엇을 할 수 있는지 보여주는 훌륭한 예임 - `$ rg 'unsafe [{]' src/ | wc -l` 결과가 10428이고, `$ rg 'unsafe [{]' src/ -l | wc -l` 결과가 736임 언어별로는 Rust 1443파일 929213줄, Zig 1298파일 711112줄, TypeScript 2604파일 654684줄, JavaScript 4370파일 364928줄, C 111파일 305123줄, C++ 586파일 262475줄, C Header 779파일 100979줄임 - Rust에서는 잠재적으로 안전하지 않은 코드를 이렇게 특정해서 검색할 수 있다는 점은 좋음 Zig에서 **안전하지 않은 코드**는 어떻게 검색함? 아니면 그냥 어디에나 있다고 가정해야 하나 - 파일 절반에 `unsafe` 키워드가 들어간다면 좋은 리라이트처럼 보이지 않음 코드의 절반 가까이가 여전히 unsafe라면 Rust로 리라이트하는 **의미**가 뭔가 - Mythos가 자기들 주장처럼 세계 최고이길 바람. 이제 정말 필요할 테니까 - 집에 **메모리 안전성** 있어! 집에 있는 것: `10428` - 아직 이 내용을 다룬 블로그 글을 쓰는 중이고, 더 자세히 공유할 예정임 배경이 궁금하면 Bun v1.3.14와 그 이전 릴리스 노트의 버그 수정 목록을 훑어보면 됨 Rust가 이 전부를 잡아주진 않음. 참조를 너무 오래 잡고 있어서 생기는 누수나 JS 경계를 넘어 재진입하는 모든 문제는 여전히 우리가 책임져야 함 하지만 그 목록의 상당수는 **use-after-free**, **double-free**, 오류 경로에서 해제를 잊는 문제이고, 이런 것들은 컴파일 오류가 되거나 자동 정리로 바뀜 - 9일 전에 이렇게 말했었음[0]: `I work on Bun and this is my branch` `This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.` 어쩌면 과잉반응이 아니었을지도? [0]: [https://news.ycombinator.com/item?id=48019226]() - 블로그 글이 기대됨 버그를 걸러내기 위해 Zig와 Rust 바이너리를 폭넓은 실제 애플리케이션에서 나란히 돌리거나, 가능하면 프로덕션에서 **섀도 실행**할 계획이 있는지 궁금함 - 유료 고객이라면 이 작업 비용이 얼마나 들지 궁금함 대략적인 추정치를 줄 수 있나 - 두 바이너리를 비교하는 일종의 **종단 간 퍼즈 테스트**를 구현했거나 구현할 계획이 있는지 궁금함 이 릴리스를 사용자 워크플로를 깨지 않게 내보내기 위한 구체적인 계획도 있는지 알고 싶음 - 이게 Bun Workers API의 안정성 문제를 고칠 가능성이 있나? [https://bun.com/docs/runtime/workers]() - 약 9일 전에 Jarred는 이게 병합될지 전혀 확실하지 않고 과잉반응이라고 썼음 아이러니함 - **오픈소스 리더십**의 모범 사례 같음 Linus가 Linux 커널을 리라이트하지 않겠다고 말해놓고 어느 날 일어나 전체를 기계 보조 Rust 리라이트로 병합했다면 어떤 난리가 났을지 상상해보라 - 회사를 더 이상 소유하지 않게 되면, 본인이 하는 말은 안전하게 무시해도 됨 쓴 **토큰 비용**을 정당화해야 할 게 뻔했음 - 그렇다고 병합될 가능성이 배제되는 건 아님 - 와, 앞으로 지켜보는 재미가 있겠음 이 코드가 검토됐을 가능성은 전혀 없지만, 어쩌면 이제는 모델이 코드를 쓰고 검토하는 걸 믿을 수 있는 **포스트 휴먼 시대**에 들어섰는지도 모름 이건 Gastown 같지만 훨씬 더 유명한 프로젝트에서 벌어진 일임 앞으로 이 프로젝트가 새 기능을 어떻게 추가할 수 있을지, 아니면 추가 자체가 가능할지 흥미로움 Anthropic이 Bun을 정확히 어떻게 쓰는지 아는 사람 있나? Claude Code의 일부인가? 앞으로 Bun을 쓰는 게 꽤 걱정되는데, 그 걱정이 Claude 사용에도 어느 정도 적용되는지는 잘 모르겠음 - 모델이 코드를 쓰고 검토하는 걸 믿을 수 있다는 건 절대 아님 - 모든 테스트를 통과했음 자동 언어 번역을 잡아낼 **테스트 스위트**를 믿을 수 없다면, 애초에 그 테스트 스위트를 전혀 믿으면 안 됨 :) - Anthropic이 Bun을 어떻게 쓰는지는 모르겠지만, 수백만 줄을 **무작정 병합**해도 괜찮다는 쪽으로 논의의 창을 옮기는 데 쓰는 것처럼 보임 - 테스트 스위트는 어떤 상태인가 - 자동 번역을 실험하는 건 사실 기대되지만, **하위 호환성 문제**가 많이 생길까 봐 걱정됨 커밋을 보기 시작했는데, 기본적으로 “테스트가 통과하지 않음” 문제를 테스트 자체를 바꾸는 식으로 해결하고 있음 이미 배포된 프로그램에서 제대로 동작하게 만드는 진짜 작업은 이제 시작일 뿐임 그나마 다행인 건 서버 쪽 JS 커뮤니티가 어떤 이유에서인지 이미 잦은 깨짐에 익숙하다는 점임 - 내가 쓰는 **런타임**에 한 사람도 들여다보지 않은 코드가 들어간다는 생각은 불편함 하지만 이게 큰 문제 없이 실제로 동작한다면 꽤 놀라운 일임 - 이 결정들을 LLM이 했는지는 모르겠지만, Claude는 문제의 올바른 해법을 찾기보다 테스트를 수정하는 식의 **수상한 행동**을 더 잘 하는 경향이 있다고 항상 느꼈음 GPT/Codex는 이 점에서는 더 정직함 - 곧바로 안정 릴리스가 될 것 같지는 않지만, 틀렸다는 게 증명되면 기쁘겠음 이 리라이트 전체에 회의적이고, Jarred Sumner는 인터넷 팔로워가 엄청나서 광고처럼 느껴짐 - “테스트가 통과하지 않음” 문제를 테스트 자체를 바꿔 해결한다는 예: [https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...]() 훌륭함! 테스트에 임의로 `sleep(1)`만 추가하면 됨. 걱정하지 마, 다 잘될 거야! - 테스트를 훑어보면서 실제로 중요한 변경이 있었는지 보고 싶은데, GitHub가 diff조차 로드하지 못함 - Bun을 쓰는 내 몇 안 되는 프로젝트는 다른 것으로 옮길 예정임 이런 **무모한 변경**을 허용하는 거버넌스는 신뢰하지 않음 - Deno는 훌륭한데, 그만큼 사랑받지 못한다고 생각함 애초에 잘 작성됐기 때문에 리라이트할 필요도 없음 - 나도 그냥 node를 계속 쓸 예정임 한편으로는 **불의 세례**가 어떻게 될지 지켜보는 건 흥미롭겠고, 장기적으로는 결국 문제들이 해결될 것 같긴 함 - 교육용으로 볼 만한 스레드가 있음. 일주일 전 Jarred가 다시 병합 결정에서 비켜나가고, 수많은 보병들이 곧 병합될 거라고 예측한 사람들을 공격했던 스레드임: [https://news.ycombinator.com/item?id=48073680]() 지금 보니 잘 버티지 못한 말이었지? - “이 스레드 전체가 과잉반응이다. 동작하지 않는 코드에 댓글 302개라니. 우리는 리라이트를 확정하지 않았다. 이 코드가 전부 버려질 가능성이 매우 높다”에서, 실험적 호기심 정도처럼 보이던 것까지 합쳐 **10일 만에 전체 병합**이라니 정말 미친 일처럼 보임 - 세상에는 어느 장화를 핥는지는 별로 신경 쓰지 않는 **권력 추종자**가 얼마나 많은지 볼 때마다 놀라움 - 이게 조금이라도 잘못되면, 자기 물건에 취한 마약상이라는 조롱이 끝도 없고 암울하게 이어질 것임 - 조금도 잘못되지 않을 가능성에 감정적으로 준비되지 않은 사람이 너무 많음 - 유출된 Claude Code 소스를 본 것만으로도 이미 조롱거리로 충분하지 않았나 - 이미 자기 물건에 취해 있음 Mythos 논문 읽어봤나? 의인화가 정말 심함 그냥 싸구려 관심 끌기일 수도 있지만, 정말로 LLM이 의식이 있다고 믿는다면… 와우