# Bun의 실험적 Rust 재작성판이 Linux x64 glibc에서 99.8% 테스트 호환성에 도달 > Clean Markdown view of GeekNews topic #29348. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29348](https://news.hada.io/topic?id=29348) - GeekNews Markdown: [https://news.hada.io/topic/29348.md](https://news.hada.io/topic/29348.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-10T09:55:31+09:00 - Updated: 2026-05-10T09:55:31+09:00 - Original source: [twitter.com/jarredsumner](https://twitter.com/jarredsumner/status/2053047748191232310) - Points: 1 - Comments: 1 ## Topic Body - Bun의 **Rust 재작성판**은 Linux x64 glibc 환경에서 기존 테스트 스위트의 **99.8%** 를 통과함 - 코드베이스는 “기본적으로 같은 코드베이스”이며, Rust 전환으로 컴파일러가 **타입 생명주기**를 강제하고 필요한 시점에 소멸자를 사용할 수 있게 됨 - 안전하지 않은 부분은 Rust의 **unsafe**로 더 분명해져 리팩터링을 유도하는 효과가 있음 - 재작성 이유는 **메모리 누수**, 크래시, 안정성 문제를 걱정하고 수정하는 데 많은 시간을 쓰는 데 지쳤고, 언어가 이를 막는 더 강력한 도구를 제공하길 원했기 때문임 - 전체 규모는 **960,000 LOC** 재작성으로 표현됐고, Linux에서 테스트 스위트를 통과하며 다른 플랫폼도 곧 대상이 될 예정임 --- ### Rust 재작성 상태 - Bun의 **Rust 재작성판**은 Linux x64 glibc 환경에서 기존 테스트 스위트의 **99.8%** 를 통과함 - 코드베이스는 “기본적으로 같은 코드베이스”이며, Rust로 바꾸면서 컴파일러가 타입의 생명주기를 강제하고 필요한 시점에 소멸자를 사용할 수 있게 됨 - 안전하지 않은 부분은 Rust에서 **unsafe**로 더 분명하게 드러나며, 리팩터링을 유도하는 효과가 있음 - 재작성 배경에는 메모리 누수, 크래시, 안정성 문제를 걱정하고 수정하는 데 많은 시간을 쓰는 데 지쳤고, 언어가 이런 문제를 막는 더 강력한 도구를 제공하길 원했다는 이유가 있음 - 전체 규모는 **960,000 LOC** 재작성으로 표현됐고, 코드는 실제로 동작하며 Linux에서 테스트 스위트를 통과하고 다른 플랫폼도 곧 대상이 될 예정임 ### 향후 공개될 내용과 빌드 관련 답변 - Bun에 대한 의미, 벤치마크, 메모리 사용량, 향후 유지보수성, 실제 재작성 과정은 별도 블로그 글에서 다룰 예정임 - 재작성 과정은 단순히 “claude, rewrite bun in rust. make no mistakes”라고 한 것이 아니며, 끝까지 동작하는 상태에 도달하기 위한 작업은 6일 전부터 시작됨 - 수작업이었다면 막대한 작업량이었을 것이라고 표현됨 - 컴파일 시간은 더 빠른 Zig 컴파일러를 쓰는 기존 Zig 버전과 기본적으로 비슷하며, upstream Zig 컴파일러를 썼다면 Rust 포트가 더 빠르게 컴파일됐을 것이라고 함 - 성능은 별도 블로그 글에서 다룰 예정임 - libc 자체를 Rust 버전인 [frankenlibc](https://github.com/Dicklesworthstone/frankenlibc)로 대체하는 다음 단계에 대해서는, 그 전에 직접 libc를 만들겠다고 함 ## Comments ### Comment 57148 - Author: neo - Created: 2026-05-10T09:55:31+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48073680) - 4일 전에도 이런 내용이 있었음: [https://news.ycombinator.com/item?id=48019226]() Bun 작업자가 자기 브랜치라며, 당시 스레드는 작동하지 않는 코드에 대한 과잉반응이고 아직 재작성에 확정한 적 없으며 코드가 전부 버려질 가능성이 높다고 했음 작동하는 버전이 어떤지, 성능과 유지보수성이 어떤지, Bun 테스트 스위트를 통과시키기 얼마나 어려운지 확인해서 **Rust 버전과 Zig 버전**을 나란히 비교하고 싶다고 했었음 - 그 메시지를 썼을 때 `cargo check`가 **컴파일러 오류 16,000개 이상**을 냈고, 버전 번호 출력도 JavaScript 실행도 못 했음 이렇게 빨리 작동할 줄도, 성능이 이렇게 경쟁력 있을 줄도 몰랐고, 자세한 내용은 블로그 글로 나올 예정임 - 유지보수성, 성능, 테스트 스위트 검사를 해보고 결정을 내린 것 같음 - 그렇다면 지금까지는 **실험으로서 매우 성공적**이라는 뜻임 - 며칠 전에는 “오픈소스는 반대 방향으로 갈 것 같다. 인간 기여 금지. 슬롭은 2025~2026년의 향수 어린 유물이 될 것”이라고도 했음 Anthropic에 인수된 뒤라 예상했어야 했지만 여전히 실망스럽다. 대규모 언어 모델 기술 자체에 반대하는 건 아니지만, 이런 “AI” 회사들이 소프트웨어 산업과 사회 전반을 먹어치우며 권력을 얻은 방식이 역겹고, 매우 건강하지 못한 의존성을 만들고 있음 몇 수 앞을 내다보고 **슬롭 없는 소프트웨어 스택과 커뮤니티**를 준비해야 함. 여기에는 Zig와 그 생태계도 포함됨. 우리와 미래 세대가 슬롭 없이 완전히 살 수 없더라도, 자유로서의 자유를 갖춘 지속 가능한 컴퓨팅 문화를 보장하는 일이 어느 때보다 중요함 - 이렇게 빨리 해낸 건 매우 인상적임. 비슷하게 **TypeScript를 Rust로 포팅**하는 프로젝트를 5개월째 하고 있는데, Mythos와 무제한 토큰 접근권은 없음 그래도 거의 100% 통과율에 가까워졌고, 작성 시점에는 99.6%임: [https://tsz.dev]() Rust는 대규모 언어 모델로 코드를 작성하기에 아주 적합함. 엄격한 타입 시스템 덕분에 다른 언어라면 허용할 수 있는 아주 멍청한 실수를 덜 하게 됨 다만 대규모 언어 모델로 코드를 쓴다고 해서 프로젝트를 만들 때 필요한 설계 비전과 트레이드오프 판단이 사라지지는 않음. 그래서 Jarred와 팀은 대규모 언어 모델로 엄청난 양의 코드를 활용해 쓸 수 있는 적절한 사람들임 - Rust의 컴파일 시점 불변식 강제는 대규모 언어 모델이 빠른 피드백을 받아 되돌아갈 수 있게 하므로 동작하는 코드를 생성하는 데 도움이 됨 반면 Rust는 복잡한 언어라 작은 변경이 멀리 떨어진 코드의 리팩터링을 강제하는 **리팩터링 눈사태**가 생기기 쉬움. 초기 아키텍처가 나쁘거나 부족하면, 대규모 언어 모델이 보통 하듯 점진적으로 코드베이스를 키울수록 스파게티화될 위험이 큼 결국 컴파일되고 실행도 되지만 사람이 읽거나 유지보수할 수 없는 프로그램이 될까 걱정됨 - 비슷하게 **멀티스레드 Postgres**도 하고 있음. 1개월 만에 pg 회귀 테스트 96%를 통과했고 823K LOC까지 갔음 Mythos 없이 월 $200짜리 Codex 계정 8개가 쓸 수 있는 전부였음 Rust의 장점도 여기서 봤고, Postgres 경험을 바탕으로 사람들이 오랫동안 pg에서 어려워하던 여러 부분에 좋은 설계 결정을 내릴 수 있다고 보고 있음. AI 덕분에 과거에는 실용적이지 않았던 복잡한 소프트웨어 개선이 더 가능해지는 게 기대됨 [0] [https://github.com/malisper/pgrust]() [1] [https://malisper.me/the-four-horsemen-behind-thousands-of-po...]() - Microsoft가 이를 Go로 다시 썼을 때, 리드 중 한 명이 Rust 대신 Go를 택한 이유로 **패러다임 유사성**을 들었음. 가비지 컬렉션 등이 비슷하고, Rust는 더 어렵고 많은 우회가 필요했을 거라고 했는데, 직접 해본 입장에서 어떤지 궁금함 - Rust는 훌륭하지만, 대규모 프로젝트에서 대규모 언어 모델과 함께 Rust 소프트웨어를 만들려 하면 원하는 방식이 무너짐 깨끗한 경계를 유지하거나 세우는 일조차 몰입 상태가 아니라 고통스러운 리뷰가 되고, 결국 미루기 모드로 빠지게 됨 - Opus가 Rust 관용구를 무시하고 가능한 한 이상한 Rust를 쓰지 않게 만드는 데 애를 먹었음. 팁이 있는지 궁금함 - 근거가 강한 건 아니지만 더는 Bun과 엮이고 싶지 않음. 직감에 가깝지만 신뢰도 지지도 못 하겠음 LLM 재작성을 활용하려고 Zig를 포크하고, Zig 팀이 명백히 꺼린 **비결정적 컴파일** 같은 걸 만들었음 이제는 징징대듯 Rust로 LLM 재작성을 하고 있음. Zig의 설계 철학이 어려우면서도 정확한 결정을 강제했기 때문에 지금 위치까지 온 것일 수 있고, Rust 재작성이 몰락의 시작일 가능성도 실제로 있음 기술보다 정치에 가까운 판단이지만, Bun은 Claude에게 완전히 떠받들어지는 것처럼 보임. Anthropic의 다음 마케팅 문구가 “Claude Mythos가 선도적인 950K LOC JS 런타임을 Rust로 재작성”이어도 놀랍지 않음 - 자기 저장소에 코드를 쓰는 개발자가 징징대는 아기인지, Hacker News에서 그걸 불평하는 사람이 그런 건지 모르겠음 - Jarred가 징징댄 건 못 봤고, 감정이 잘못 향한 것 같음 링크된 Twitter 스레드는 **명확한 기술적 근거**를 제시하고 있음 - Bun에 개인적으로 그렇게 몰입해 있지는 않지만, 이게 왜 중요한지 모르겠음. 다른 의존성들도 이렇게 검토하는지 궁금함 JS/NPM 생태계에서 일한다는 건 이미 검증 안 된 의존성에 대한 순수한 믿음에 크게 의존하는 일이고, LLM 재작성 전후가 달라 보이지 않음. 원래 목표와 API 계약을 만족한다면 차이가 있나? 기존 소스 코드는 꼼꼼히 읽고 있었는지도 의문임 - 동의함. Bun은 처음부터 설계 철학이 분명했음. 런타임, 번들러, 테스트 스위트, 패키지 매니저까지 원하는 걸 전부 하고, 매주 깨지는 패치를 내는 식이었음 매번 기존 경쟁자를 더 좋고 빠르고 강하게 압도한다는 식이었지만, **Keep It Simple Stupid**만은 절대 하지 않을 게 너무 뻔했음 가까운 미래에 실제 운영 환경에서 보게 될 곳은 가속제를 뿌린 듯 하나씩 타버리는 YC 스타트업들뿐일 것도 분명했음. 이제는 되돌릴 수 없는 지점을 지난 듯함 - Bun은 사실상 죽었음 Anthropic은 자기들의 “성능” 문제를 해결하려는 다소 멍청한 시도로 Bun을 샀음. 애초에 형편없는 코드가 문제였다는 걸 몰랐던 듯함 그래도 실제로 유능한 개발자들을 데려왔으니 어느 정도 도움이 됐을 수는 있음 하지만 그 과정에서 Bun은 공개 프로젝트에서 Anthropic 내부 도구에 가까워졌고, 지금은 AI 자금으로 과보호받으며 초점을 꽤 잃고 있음 거품이 꺼질 때 Bun에 들어간 노력이라도 일부 건질 수 있기를 바람. Anthropic이 장기적으로 유지보수할 것 같지는 않음. 그들은 런타임 지원을 파는 사업을 하는 회사도 아니고, 옆에서 런타임을 유지할 만큼의 Google급 규모도 없음 - AI 개입을 잠시 빼고 보면 좋은 변화라고 생각함 Bun은 Zig를 사용하면서 **크래시와 메모리 버그**가 극도로 많았고, Rust 기반인 Deno와 달랐음 물론 Bun의 Rust 포트에 `unsafe`가 많다면 마법처럼 전부 해결되지는 않겠지만, 그래도 나아질 것임 - Bun에 크래시와 메모리 버그가 극도로 많다는 통계나 출처가 있는지 궁금함. 틀렸다고 생각하는 건 아님 보기 흉한 부분이 `unsafe`로 더 분명하게 보이니 리팩터링을 유도한다는 점은, 언어만의 문제가 아니라 Bun 자체가 어느 정도 자초한 면도 있어 보임 - Zig를 쓰면 “크래시와 메모리 버그가 극도로 많아진다”는 주장인지 궁금함 그렇다면 그런 도구로 고품질 소프트웨어를 만드는 게 사실상 불가능하다는 뜻 아닌가? C/C++로도 품질 좋은 것들이 많이 만들어졌는데, Zig는 무엇을 잘못하고 있는지 의문임 - `unsafe`로 명확히 표시되니 찾기 쉽고, 해결해야 할 이슈 목록이 자연스럽게 생김 - 이걸 하는 데 **6일**이 걸렸음. 최종적으로 의미 있는 결과가 되지 않더라도, 지금과 앞으로 토큰과 작업량이 어떻게 연결될지 보여줌 더 많은 컴퓨팅 자원을 가진 개인이나 회사와 경쟁하기 어려워질 것임. 그들은 내가 못 하는 일을 그냥 할 수 있게 됨 - 좋은 테스트 스위트가 있는 프로젝트를 한 언어에서 다른 언어로 번역하는 건 대규모 언어 모델이 잘하는 대표적인 사례로 알려져 있음 완성된 코드베이스를 예시로 쓰고 테스트 스위트로 검증할 수 있으면 원하는 목표를 향해 반복하기 훨씬 쉬움. 모델은 목표가 무엇인지, 그리고 한 번 구현된 방식이 무엇인지 이미 볼 수 있으므로, 명세에서 시작하는 것보다 훨씬 쉬운 문제임 - 증기력이나 전기에 대해서도 같은 말을 할 수 있었음. 단순한 비유만도 아님. 이런 것들의 마법은 **범용 정보 엔진**이라는 데 있음 자본을 들여 잘 이해된 확장 가능한 기법으로 만들고, 전기를 꽂으면 가치가 나옴 요지는 현대 세계에서 전기가 그렇게 되지 않았듯, “가진 자와 못 가진 자”가 생길 가능성은 없다는 것임 - 분명하지 않음. 아주 좋은 제품은 대체로 한두 가지를 아주 잘하는 데서 나오지, 많은 것을 하는 데서 나오지 않음 지금까지 보이는 건 “와, 이제 나는 10배 엔지니어야!”라며 더 많은 코드를 내보내지만 명확한 방향성과 취향은 없는 모습임. 현재 대규모 언어 모델 기반 작업의 대부분은 그냥 잡음처럼 보임 - 아님. 이런 에이전트들은 로컬에서 돌리기가 점점 쉬워지고 있음 **Qwen 3.6 27b**를 써봤는지 모르겠지만, 크기에 비해 할 수 있는 일이 미쳤음. 문맥 관리를 잘하면 작은 프로젝트는 100% 바이브 코딩도 가능함 이런 모델들도 컴퓨팅처럼 결국 가격 경쟁으로 내려갈 것임 - Anthropic 표준 요금으로 냈다면 이게 달러로 얼마 들었을지 궁금함. 대략이라도 추산할 수 있는 사람이 있을까? - 이걸 있는 그대로 받아들이는 사람이 많은데, 상당 부분은 이전에 구축된 **표준 이상으로 광범위하고 포괄적인 테스트 스위트** 덕분에 가능했음 - 그래도 가장 유능한 엔지니어라도 훨씬 더 오래 걸렸을 성과라 인상적임 나중에 마케팅할 때, 이 속도를 가능하게 한 테스트 스위트를 설계하고 큐레이션하는 데 얼마나 많은 인간 노력이 들어갔는지도 함께 적히면 좋겠음 테스트 스위트는 현 세대 대규모 언어 모델에 거의 이상적인 환경처럼 작동함. 충분히 포괄적인 테스트 스위트는 에이전트가 원하는 방식으로 구현할 수 있는 명세가 되며, 여기서는 그 대상이 Rust였음 Bun 같은 프로젝트처럼 잘 만들어진 테스트라면, 경우에 따라 실제 소스 코드를 전부 버리고 테스트만 접근하게 해도 전체를 처음부터 다시 구현할 수 있을 것 같음 - 이게 다른 프로젝트와 비교해 이 작업을 유일하게 가능하게 할 정도의 “표준 이상” 테스트 스위트라면, Bun이 다른 Zig 프로그램보다 유독 불안정해서 재작성할 필요가 있다는 말과는 어떻게 양립하는지 의문임 책임이 테스트 스위트에도 일부 있다면, Rust 포트에 대해서는 무엇을 뜻하는지도 궁금함 - 6일 만에 이렇게 할 수 있다는 것만 보라니 그걸 가능하게 만든 원래 아키텍처와 테스트 스위트에 들어간 **수십만 시간**은 무시하라는 건가 - AI를 이용한 Rust 포팅의 주의 사례로 볼 만함 [https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...]() - 테스트 통과가 곧 작동을 의미하지는 않음 Claude code C 컴파일러는 gcc 테스트를 100% 통과했지만 `hello world`조차 실행하지 못했음 - 그 사례들에서 얻을 교훈은 조금 다름. 대규모 언어 모델은 피드백 루프로 준 것을 기준으로 만듦 논리 테스트만 주면 속도는 전혀 고려하지 않음. 속도를 측정하는 테스트를 포함하고 성능을 맞추라고 하면 그것도 하게 됨 대규모 언어 모델의 다른 오류와 같은 부류임. 사람이 중요하다고 여기는 것들에 대한 상식적 맥락이 없음. 경계를 강제하지 않으면 무시함 - 관심 있으면 여기서 논의됐음: LLMs work best when the user defines their acceptance criteria first - [https://news.ycombinator.com/item?id=47283337]() - 2026년 3월, 댓글 422개 - 살아 있는 시대가 참 대단함 업계와 직업의 근본적인 동역학이 너무 짧은 시간에, 사실상 하룻밤 사이에 바뀌었음 어떤 날은 지금 내가 할 수 있는 일이 너무 많아져서 흥분됨. 원하는 건 뭐든 거의 즉시 만들 수 있고, 소프트웨어로 꿈꾸던 것의 100%가 현실이 될 수 있음 어떤 날은 **일자리 시장**에 무슨 일이 벌어질지 두려움 갑자기 아주 적은 것으로 아주 많은 것을 얻을 수 있게 됐고, 세상에 필요한 소프트웨어의 양은 한계가 있음 소프트웨어 판매를 핵심 사업 모델로 하는 모든 회사가 망하게 될까? 최고의 모델에 특정 회사나 정부만 접근하게 되면 어떻게 될까? - 티켓팅 시스템 같은 소프트웨어 사업을 생각해보자 10억 토큰을 가진 기업 100곳이, 1000억 토큰을 가진 전문 벤더보다 더 나은 제품을 만들 수 있을까? “로고 생성기” 같은 소프트웨어 벤더와 SaaS는 이미 죽은 게 맞지만, 다음 세대 대규모 언어 모델에 티켓팅 시스템이 내장되지 않는 한 티켓팅 시스템 벤더는 괜찮을 것임. 인력은 줄 수 있지만 확실하진 않음 - 닷컴 붕괴 무렵에도 소프트웨어 산업은 “너무 포화됐다”며 학생과 구직자에게 들어오지 말라는 이야기가 꽤 있었음 몰려드는 사람 수에 비해 나눠 가질 일이 별로 없다는 식이었고, 붕괴가 그 서사를 강화했음 하지만 당시 학생이었어도 소프트웨어의 범위가 사실상 무한하다는 걸 알 수 있었음. 우리가 수작업으로 하는 거의 모든 인지적 일은 소프트웨어로 할 수 있음. 한 번 그런 것들을 열거해보려다가 할 일이 너무나 많다는 걸 금방 깨달았음 게다가 일을 새로운 방식으로 할수록 상상도 못 했던 더 많은 일이 튀어나온다는 것도 이해했음. 가능성은 셀 수 없었고, “포화” 서사는 소프트웨어가 무엇인지에 대한 상상력과 이해 부족에서 나온 게 분명했음 그래서 이 분야는 절대 포화되지 않을 거라고 알았음. 소프트웨어로 만들 대상이 바닥나는 건 불가능했기 때문임 그런데 요즘은 다름. 앞으로도 새 소프트웨어는 늘 만들겠지만, 이제는 우리가 새로 할 일을 상상하는 속도보다 소프트웨어를 쓰는 속도가 더 빨라질 수 있는지 고민하게 됨 - 회사와 정부는 대중보다 더 나은 모델에 접근할 것임. 실제로 Mythos가 이미 그런 사례임 대중도 최전선보다 뒤처진 모델로 스스로를 도울 수는 있을 것임 - 최소한 이런 시도가 진행되는 걸 구경하는 건 흥미로움 가장 먼저 궁금한 건 애초에 **테스트 스위트의 포괄성과 품질**이 어느 정도냐는 것임. 흠집을 내려는 건 아니지만, 모든 플랫폼에서 100%가 나와도 Bun 팀이 마이그레이션에 얼마나 확신을 가질 수 있을지 궁금함 - 지난주 Ubuntu coreutils 일 때문에 **99.8% 테스트 호환 Rust 재작성**에 대한 인상이 정말 나빠졌음 여기 링크된 트윗을 눌러보니 몸서리치는 느낌이었고, 이제 이런 걸 보면 정반대의 감정이 듦. 거의 출구를 찾게 됨