[번역] Bun의 Rust 재작성에 대한 나의 생각

라이브러리, 프레임워크•2026.07.13

원문: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

Andrew Kelley - 2024년 5월 21일

역사

약 5년 전 Jarred가 Zig 커뮤니티에 합류했을 때, 나는 그를 강한 "초보자 에너지(beginner energy)"를 가진 사람으로 묘사했습니다. 즉, 그는 매우 빠르게 움직이며 다양한 시도를 했고, 아직 해결할 준비가 되지 않은 문제들에 머리부터 들이밀었습니다. 그 결과 엔지니어링 측면에서는 평범한 결과물이 나왔지만, 그 과정에서 엄청나게 많은 것을 배웠습니다. 나는 이것이 특히 젊은이나 학생들에게 매우 건강한 태도라고 생각합니다. 이것이 레벨업을 하고 새로운 것을 배우는 가장 좋은 방법이기 때문입니다.

그가 Bun에 노력을 집중하기 시작하면서 사람들의 관심을 끌기 시작했습니다. JavaScript는 세계에서 가장 인기 있는 프로그래밍 언어이기에, 유망한 새로운 툴체인에는 수많은 잠재적 시선이 쏠립니다.

이러한 관심은 몇 가지 다른 방식으로 활용될 수 있었습니다. 예를 들어, 그는 크라우드펀딩을 통해 샌프란시스코 기준으로도 충분히 넉넉한 생활비를 쉽게 벌 수 있었을 것입니다. 하지만 그는 대학 대신 틸 펠로우십(Thiel Fellowship) 사고방식을 거친 학교를 졸업했기에, 어린 나이부터 실리콘밸리의 마인드셋을 무비판적으로 수용하도록 길들여졌고, 결국 벤처 캐피털(VC)의 투자를 받았습니다.

처음부터 Jarred는 Zig 프로젝트에 감사하는 마음을 가졌습니다. 그는 Bun 웹사이트에서 프로젝트의 성능 성과를 Zig의 공으로 돌렸습니다. 그는 Zig Software Foundation(ZSF)에 연간 6만 달러에 달하는 월간 기부금을 설정했습니다. 그가 굳이 그럴 필요는 없었지만 그렇게 했고, 그것은 꽤 멋진 일이었습니다. 심지어 내가 언급하고 있는 그의 블로그 포스트에서도 그는 Zig 프로젝트에 대해 진심 어린 감사를 표하고 있습니다.

하지만 Bun이 VC의 지원을 받는 스타트업이 되자, 그는 결승선을 향해 질주하기 시작했습니다. 이제 Jarred는 자유 오픈 소스 프로젝트를 작업하며 커뮤니티와 함께 배우고 성장하는 대신, 비즈니스를 운영하게 되었습니다. 그가 갑자기 관리자가 된 이 시점부터, 그의 "초보자 에너지"는 나에게 다르게 다가오기 시작했습니다. 자신을 위해 열악한 워라밸을 선택하는 것과 타인에게 그것을 요구하는 것은 완전히 다른 문제입니다.

"Oven에서 일하는 것 고될(grind) 것입니다. 특히 처음 9개월 정도는요. 만약 워라밸이 일하지 않는 시간을 많이 갖는 것을 의미한다면, 아마 우리와는 맞지 않을 것입니다."

역자 주: Oven은 Bun을 개발하던 회사입니다. 지금은 Bun 프로젝트가 Anthropic에 인수되었습니다.

재미있는 사실은, 사람들은 서로 대화를 한다는 것입니다.

나는 Oven의 면접을 본 사람들과 이야기를 나눴습니다. 그곳에서 일했던 사람들과도 이야기를 나눴습니다. 그 사람들은 또 서로 이야기를 나눴죠. 소문은 무성했고, 그 모든 소문은 같은 메시지를 담고 있었습니다. Jarred는 형편없는 관리자였다는 것입니다. 부족한 소통, 비현실적인 기대치, 낮은 공감 능력, 경험 부족. 고용 측면에서 볼 때 그야말로 엉망진창이었습니다.

결과적으로, Zig 커뮤니티 멤버들이 업무 시간에 Zig로 코딩하는 일을 간절히 원했음에도 불구하고, 대부분의 인재는 Oven과 Bun을 멀리했습니다.

동시에 Zig와 Jarred 사이의 간극은 넓어지기 시작했습니다. 생산성과 스타트업의 엑시트(Exit) 전략에만 매몰된 그의 시각은 Zig 프로젝트에 대한 나의 장기적인 비전과 점점 더 충돌했습니다. 그는 내가 더 큰 계획을 가지고 있음에도 불구하고, 다른 모든 우선순위를 제쳐두고 언어 서버 프로토콜(LSP) 구현과 VSCode 통합 작업을 해달라고 계속해서 나를 괴롭혔던 기억이 납니다.

하지만 가장 큰 문제는 코드 품질이었습니다.

Zig 팀은 정기적으로 사용자들의 프로젝트를 점검합니다. 언어가 사용자에게 어떤 영향을 미치는지 알아보기 위해 소스 코드를 읽고, 변경 사항이 얼마나 문제가 될지 테스트하며, 성능 저하가 있는지 확인합니다.

우리는 Bun의 코드베이스에서 목격한 프로그래밍 관행에 점점 더 경악하게 되었습니다. 해킹 위에 해킹을 얹은 구조. 단언문(Assertion)의 남용. 무엇보다도, 성찰이나 버그 및 기술 부채 제거를 위한 시간은 거의 갖지 않은 채 무모하게 기능만을 추가하며 속도를 냈습니다. Jarred는 LLM을 사용하기 훨씬 전부터 이미 조잡한 코드(slop)를 쓰고 있었습니다. 물론 사용자가 무엇을 하든 간섭하는 것은 우리의 소관이 아니지만, 사람들이 우리에게 메모리 안전성(Memory Safety)에 대해 끊임없이 소리 지르는 것을 보셨을 겁니다. 무책임한 소프트웨어 엔지니어링 관행으로 인해 사람들이 비판하기 딱 좋은 빌미를 제공하는 프로젝트와 우리 사이에 어느 정도 사회적 거리를 두고 싶어 했던 우리의 마음을 상상하실 수 있을 것입니다.

우리는 그들을 더 나은 프로그래밍 관행으로 인도하려고 헛된 시도를 했습니다. 기능하지 않는 회사 안에서 최선을 다했던 몇몇 예외적인 영웅들이 있었습니다. 여러분이 누구인지 스스로 알 것입니다. 하지만 밀려오는 파도를 막을 수는 없었습니다.

이 무렵, 우리 ZSF(역자 주: Zig Software Foundation) 구성원 모두는 Bun이 순전한 골칫덩어리라고 느꼈습니다. 그리고 이것은 RoboBun(AI)이 기여도 1위가 되기 전의 일이었습니다. Zig 프로그래밍 언어의 대표 사례로 대중에게 인식되는 프로젝트가 실제로는 'Zig 코드를 짜지 않는 법'의 전형적인 예시라는 불편함과 더불어, 언젠가 그들이 회사를 팔아넘길 것이고(솔직히 그들의 모호한 "클라우드 무언가를 판다"는 비즈니스 계획은 처음부터 억지였습니다), 우리는 대리인 격으로 부정적인 평판을 얻게 될 것이며, 정기적인 기부도 끊길 것이라는 점을 알고 있었습니다.

그래서 마침내 Anthropic의 인수가 일어났을 때, 우리 ZSF는 안도의 한숨을 내쉬었습니다. 기부가 소리 없이 중단되었을 때, 우리의 은행 계좌는 이미 준비되어 있었습니다. 그들이 우리와의 월간 회의를 취소하지도 않고 나타나지도 않았을 때도 우리는 놀라지 않았습니다. 관계는 끝난 것이었습니다.

결과는 불 보듯 뻔했습니다. 불과 이틀 만에 우리는 이미 Rust 재작성이 진행될 것임을 짐작했습니다. 그리고 우리는 그것을 응원했습니다! 대형 AI 기업에 인수된 것은 부담이었습니다. Claude가 Bun으로 작성되고 Bun이 Zig로 작성되었다는 간접적인 연결만으로도 무분별한 AI 생성 코드 기여가 급증했을 뿐만 아니라, 포럼 게시물에 LLM 출력물을 붙여넣는 것이 반사회적 행동이라는 점을 일일이 설명해 주어야 하는 무분별한 AI 열성론자들이 Zig 커뮤니티로 유입되었기 때문입니다. 잠시 동안 나는 Zig의 정체성이 구어체로 'AI와 관련된 프로그래밍 언어'로 알려지게 될까 봐 두려웠습니다.

Jarred가 Rust 재작성을 발표했을 때, 우리는 열광했습니다. 사실이라고 믿기엔 너무 좋았습니다. 솔직히 말해서, 나는 그가 이런 묘기를 부릴 만한 기술적 역량이 있다고 생각하지 않았습니다. 하지만 그는 해냈고, 이제 나는 비유적으로 "이제 내 문제 아님"이라고 적힌 머그잔에 담긴 맛있는 차를 홀짝이고 있습니다.

블로그 포스트에 대하여

그 블로그 포스트는 아주 능숙하게 작성되었습니다. 마치 수조 달러 가치의 기업 마케팅 부서가 이 기사에 엄청난 돈을 걸고 있는 것만 같습니다.

하지만 몇 가지 따져볼 점이 있습니다.

포스트에서는 버그를 피하기 위해 "스타일 가이드"를 선택하거나 프로그래밍 언어 기능을 선택해야 한다는 이분법을 제시합니다. 이러한 눈속임은 버그를 제거하는 핵심 방법인 '엔지니어링 리소스 투입'으로부터 독자의 시선을 돌립니다. 당신은 TigerBeetle의 공로를 충분히 인정하지 않고 있습니다. 아주 간단히 말해서, 그들은 버그를 찾고 제거하는 데 시간을 투자했고, ZSF와 건강한 관계를 유지하기 위해 노력했습니다. Bun은 그중 어느 것도 하지 않았습니다.

검토되지 않은 수백만 줄의 코드를 배포할 수 있다는 논거는 테스트 스위트(Test suite)가 모든 것을 잡아낼 만큼 충분히 훌륭하다는 것입니다. 그렇다면 왜 Zig 코드에는 짜증 나는 버그가 그렇게 많다고 말하는 것입니까? 모든 것을 잡아내기에 충분하다던 테스트 스위트는 어떻게 된 것입니까? Zig 코드의 버그를 잡기에는 부족하지만, 검토되지 않은 100만 줄의 조잡한 코드 속 버그를 잡기에는 충분하다는 뜻입니까?

성능 향상의 원인을 LTO(Link Time Optimization) 덕분으로 돌리고 있는데, Zig는 Bun이 존재하는 내내 이를 지원해 왔습니다. 우리가 너무 많은 LLVM 버그를 마주하기 전까지는 기본적으로 활성화되어 있었고, 그 버그들은 Rust에도 똑같이 영향을 미칩니다. 우리는 아마 당신에게 그것을 활성화해 보라고 말하려 했을 텐데 당신은 듣지 않았을 것입니다. 제발, 우리의 조언은 유용하다고요!

포스트는 당신이 Zig 코드를 부지런히 퍼징(Fuzzing)하고 있었다고 암시하지만, 우리와의 통화에서 Bun 팀은 아무것도 퍼징하고 있지 않다고 말했습니다.

블로그 포스트는 "Bun은 Rust에서 더 낫다"는 주장을 뒷받침하기 위해 바이너리 크기를 줄이기 위해 수행된 수많은 엔지니어링 작업을 나열합니다. 하지만 그 모든 엔지니어링 작업은 재작성과는 아무런 관련이 없습니다. 나는 이것이(특히 블로그 포스트의 "바이너리 크기" 섹션) 블로그 포스트가 나오는 데 그렇게 오래 걸린 이유라고 생각합니다. 당신은 처음부터 Zig 코드베이스에서 했어야 할 엔지니어링 작업을 이제야 하고 있었던 것입니다. 우리는 수년 동안 당신의 comptime 남용에 대해 경고해 왔습니다. 우리는 심지어 comptime/inline 사용량과 컴파일 시간을 감사해야 하는 프로젝트를 위해 특별히 이 타임 리포트 도구를 만들기도 했습니다.

컴파일 속도에 대한 언급이 빠진 것을 확인했습니다. Zig 컴파일러 프로젝트는 약 60만 줄의 코드로 구성되어 있으며, 이는 재작성 전의 Bun과 거의 비슷한 크기입니다. 깨끗한 캐시 상태에서 처음부터 빌드하는 데 16초가 걸리고, 증분 컴파일(Incremental compilation)을 활성화한 상태에서 이후 수정 시마다 90ms가 걸립니다. 재작성 후 Bun의 해당 측정값은 얼마가 될까요?

앞으로 나아가며

여기서 주요 쟁점은 Zig 대 Rust의 언어 기능과는 아무런 관련이 없으며, 두 프로젝트의 가치 체계가 갈라지고 그에 따른 관계 파탄이 핵심입니다.

조금 더 넓게 보았을 때, 한 가지 분명히 하고 싶은 것이 있습니다.

Jarred가 Bun을 Zig의 수치(embarassment)로 만든 것에 대해 분개하고, 우리가 겪어온 조잡한 코드 문제에 대해 부분적으로 그를 탓하며, 그의 리더십에 대한 비판을 유지하고 있지만, 동시에 그에게 공감하기도 합니다. 그는 나와 다른 가치관을 가지고 있고, 삶에서 나와 다른 것을 원합니다. 하지만 나는 그가 지금 있는 자리에서 실제로 행복하고 성공적이라고 생각합니다. 그는 자신이 원하는 모든 것을 성취하는 방법을 알아냈습니다. 그는 자신의 생산성 판타지 열병을 마음껏 펼치고 있으며, 아마 이미 엄청난 부자일 것입니다. 그는 기술계의 소소한 유명 인사이기도 합니다.

솔직히 말해서, 그는 스스로 잘 해냈다고 생각합니다. 나의 분노와 Anthropic의 마케팅 부서와 싸우고 있다는 사실에도 불구하고, 그에게 악의를 품고 있지는 않습니다. 좌절감 속에서도, 나는 그가 자신의 기준에 따라 성공한 것에 대해 기쁘게 생각합니다.

이 블로그 포스트는 Jarred에 대한 개인적인 공격과 같은 성격을 띠어버리고 말았지만, 본래의 의도는 실패한 비즈니스 관계에 대한 이야기를 들려주고자 함이었습니다. 나의 의도대로 되지 않았던 이유는 나조차 인식하지 못했던, 하지만 독자들에게는 명백히 보였던 처리되지 않은 분노의 감정이 섞여 있었기 때문입니다. 자기 성찰과 친구들과의 대화 후에 이 결론 섹션을 업데이트했습니다. 이 웹사이트의 공개 소스 저장소에서 원문을 확인하셔도 좋습니다.

이 포스트에서 저지른 또 다른 치명적인 실수는, 이러한 사실을 거의 알지 못하고 그저 '전직 Zig 사용자가 언어 제작자에게 비난받고 있다'는 표면적인 이해만 가진 Zig 사용자들에게 미칠 영향을 고려하지 못했다는 점입니다. 그런 분들은 자신에게도 그런 일이 일어날까 봐 걱정하는 것이 당연합니다. 그렇게 느끼게 해 드린 분들께 사과드립니다. 이 시점에서 내가 말할 수 있는 것은, 나를 포함한 ZSF 구성원들은 Zig를 공개적으로 사용하고 이야기하는 거의 모든 분과 훌륭한 관계를 유지하고 있으며, 이번 사건이 유일한 예외라는 점입니다. 많은 분이 아무런 소란 없이 Zig를 떠나기로 결정해 왔습니다. 수조 달러 규모의 회사가 먼저 선공을 날렸다는 점을 고려하여 너그러이 이해해 주시길 바랍니다.

분명히, 여기서부터 할 일은 내 블로그를 내가 최근에 작업하고 있는 것들을 시연하는 것과 같은 긍정적인 일들에 집중하는 것입니다. 이를 통해 Zig 커뮤니티에서 실제로 어떤 일이 일어나고 있는지에 대한 정확한 인상을 심어주고 싶습니다. 수많은 멋진 사람들이 멋진 것들을 함께 만들며 즐거운 시간을 보내고 있다는 사실 말입니다.

제 블로그 포스트를 읽어주셔서 감사합니다.