Bun의 Rust 재작성, Zig와의 관계, 코드 품질, 그리고 해당 블로그 글에 대한 생각을 다룬 글입니다.
약 5년 전 Jarred가 Zig 커뮤니티에 합류했을 때, 나는 그를 강한 "초보자 에너지"를 가진 사람이라고 묘사했다. 즉, 그는 빠르게 움직였고 아주 다양한 것을 시도했으며, 아직 해결할 준비가 되지 않은 문제들에 머리부터 뛰어들곤 했다. 그 결과 엔지니어링 측면에서는 평범한 성과가 나오곤 했지만, 그 과정에서 엄청나게 많은 것을 배웠다. 나는 이것을 특히 젊은 사람들과 학생들에게 매우 건강한 태도라고 본다. 새로운 것들을 배우고 실력을 끌어올리는 가장 좋은 방법이기 때문이다.
그가 Bun에 집중하기 시작하면서 점점 주목을 받기 시작했다. JavaScript는 세계에서 가장 인기 있는 프로그래밍 언어이기 때문에, 유망한 새 툴체인을 바라보는 잠재적 시선도 아주 많다.
이 관심은 몇 가지 다른 방식으로 활용될 수도 있었다. 예를 들어, 그는 크라우드펀딩만으로도, 심지어 샌프란시스코 기준으로도 충분히 탄탄한 생계를 쉽게 이룰 수 있었을 것이다. 하지만 그는 대학이 아니라 Thiel Fellowship식 사고방식 속에서 성장했기 때문에, 본질적으로 어린 시절부터 Silicon Valley식 마인드셋을 비판 없이 받아들이도록 길러졌고, 결국 벤처 자본을 택했다.
처음부터 Jarred는 Zig 프로젝트에 대해 고마움을 표했다. 그는 Bun 웹사이트에서 프로젝트의 성능 성과에 대해 Zig의 공을 인정했다. 또한 Zig Software Foundation에 연간 60,000달러 규모의 월 정기 후원을 설정했다. 그는 그 어느 것도 할 필요가 없었지만 실제로 그렇게 했고, 그건 꽤 멋진 일이었다. 심지어 내가 여기서 언급하는 그의 블로그 글에서도, 내가 보기에는 Zig 프로젝트에 대한 진심 어린 감사가 드러난다.
하지만 Bun이 벤처 자본의 지원을 받는 스타트업이 되자, 그는 결승선을 향해 질주하기 시작했다. 이제 Jarred는 자유 오픈 소스 프로젝트를 하면서 커뮤니티와 함께 배우고 성장하는 대신, 사업을 운영하고 있었다. 그리고 바로 이 시점, 즉 그가 갑자기 관리자가 되었을 때, 이 "초보자 에너지"가 내게는 다르게 느껴지기 시작했다. 스스로에게 좋지 않은 워라밸을 선택하는 것과, 그것을 다른 사람에게 요구하는 것은 완전히 다른 문제다.
"Oven은 특히 처음 아홉 달 정도는 빡셀 것입니다. 워라밸이 일하지 않는 데 많은 시간을 쓰는 것을 의미한다면, 아마 잘 맞지 않을 겁니다."
재미있는 사실 하나: 사람들은 서로 이야기한다.
나는 Oven에서 면접을 본 사람들과 이야기했다. 그곳에서 일했던 사람들과도 이야기했다. 그 사람들도 서로 이야기했다. 모두가 모두와 이야기했다. 소문망은 크고 건강했고 과즙이 가득한 포도로 넘쳐났으며, 그 모든 포도에는 같은 메시지의 즙이 들어 있었다. Jarred는 형편없는 관리자였다는 것이다. 소통 부족, 비현실적인 기대, 낮은 공감 능력, 경험 부족. 고용 관점에서 보면 완전히 총체적 난국이었다.
그 결과, Zig 커뮤니티 구성원들은 근무 시간에 Zig 코드를 작성하는 일을 간절히 원했음에도, 인재 풀의 대부분은 Oven과 Bun을 피했다.
동시에 Zig와 Jarred 사이의 균열도 점점 벌어지기 시작했다. 생산성과 그의 스타트업의 출구 전략에만 집중하는 그의 태도는, Zig 프로젝트에 대한 나의 더 장기적인 비전과 점점 더 충돌했다. 나는 그가 내가 가진 다른 모든 우선순위를 내려놓고 Language Server Protocol 구현과 VSCode 통합 작업을 하라고 계속 성가시게 굴던 것을 기억한다. 하지만 나는 더 큰 계획을 갖고 있었다.
그러나 가장 큰 문제는 코드 품질이었다.
Zig 팀은 사용자 프로젝트를 정기적으로 점검한다. 우리는 언어가 사용자에게 어떤 영향을 주는지 알아내기 위해 소스 코드를 읽고, 변경 사항이 얼마나 문제를 일으킬 수 있는지 보기 위해 테스트하고, 성능 회귀도 확인한다.
우리는 Bun의 코드베이스에서 본 프로그래밍 관행에 점점 더 경악하게 되었다. 해킹 위에 해킹이 쌓여 있었다. assertion 남용. 무엇보다도, 반성하고 버그와 기술 부채를 제거하는 데 거의 시간을 쓰지 않은 채 기능 하나하나를 무모하게 너무 빠르게 밀어붙이고 있었다. Jarred는 LLM에 접근하기 훨씬 전부터 이미 엉터리 코드를 쓰고 있었다. 물론 사용자가 무엇을 하는지 우리가 단속할 일은 아니지만, 사람들이 메모리 안전성 문제를 두고 끊임없이 우리 면전에 대고 소리치는 상황을 여러분도 봤을 것이다. 그렇다면 무책임한 소프트웨어 엔지니어링 관행으로 인해 사람들이 기꺼이 퍼부으려 드는 바로 그 종류의 비판을 자초하는 프로젝트와는, 우리가 어느 정도 사회적 거리를 두고 싶어 한다는 점을 상상할 수 있을 것이다.
우리는 그들을 더 나은 프로그래밍 관행으로 이끌기 위해 헛된 시도를 했다. 기능 장애적인 회사 안에서도 최선을 다한 몇몇 뛰어난 영웅들이 있었다. 당신이 누구인지는 당신도 안다. 하지만 밀려오는 조류를 막을 수는 없다.
이 무렵 ZSF의 우리 모두는 Bun이 순손실이라고 느끼고 있었다. 그리고 이것은 RoboBun이 최다 기여자가 되기 전의 일이었다. 대중적으로는 Zig 프로그래밍 언어의 대표 사례처럼 여겨지던 것이 실은 Zig 코드를 어떻게 작성하면 안 되는지 보여주는 대표 사례라는 불편함에 더해, 결국 언젠가는 그들이 회사를 팔아치울 것이고(솔직히 말해, 그들의 모호한 "클라우드 뭔가를 팔겠다"는 사업 계획은 처음부터 허상이었다), 우리는 간접적으로 부정적 홍보를 뒤집어쓰게 될 것이며, 그 정기 후원도 끊길 것이었다.
그래서 Anthropic 인수가 마침내 일어났을 때, ZSF의 우리는 안도의 한숨을 내쉬었다. 후원이 조용히 중단되었을 때도, 우리 은행 계좌는 이미 그 상황에 대비되어 있었다. 그들이 우리와의 월간 회의를 취소하지도 않았고, 그렇다고 나타나지도 않았을 때에도, 우리는 놀라지 않았다. 관계는 끝난 것이었다.
징조는 이미 분명했다. 불과 며칠 안에도 우리는 이미 Rust 재작성이 올 것이라고 의심하고 있었다. 그리고 우리는 그것을 응원하고 있었다! 대형 AI 회사에 인수되었다는 사실은 부담이었다. Claude가 Bun으로 작성되고 Bun이 Zig로 작성되었다는 간접적 연결만으로도 무성의한 날림 기여가 급증했을 뿐 아니라, Zig 커뮤니티에 유입된 센스 없는 AI 열광자들에게 포럼 글에 LLM 출력을 붙여넣는 것이 반사회적 행동이라는 점을 알려줘야 하는 상황까지 생겼기 때문이다. 한때 나는 Zig의 정체성이 구어적으로 AI와 연관된 프로그래밍 언어로 알려지게 될까 두려웠다.
Jarred가 Rust 재작성을 발표했을 때, 우리는 몹시 기뻤다. 너무 좋아서 믿기지 않을 정도였다. 솔직히 말해, 나는 이런 일을 해낼 기술적 기반이 아직 마련되어 있다고 생각하지 않았다. 하지만 그는 해냈고, 이제 나는 "이젠 더 이상 내 문제가 아닌 맛"이라고 적힌 머그잔으로 맛있는 차를 홀짝이는 기분이다.
그 블로그 글은 아주 능숙하게 쓰였다. 거의 마치 시가총액 1조 달러 기업의 마케팅 부서가 이 글에 많은 돈을 걸고 있는 것처럼 말이다.
그래도 몇 가지 따지고 싶은 점이 있다.
여기서는 버그를 피하려면 "스타일 가이드" 아니면 프로그래밍 언어 기능 중 하나를 선택해야 한다는 식의 이분법이 제시된다. 이런 눈속임은 독자의 시선을 버그를 제거하는 주된 방법, 즉 그것에 엔지니어링 자원을 투입하는 일에서 돌려놓는다. TigerBeetle의 공로를 너무 과소평가하고 있다. 아주 단순하게 말해, 그들은 버그를 찾아 제거하는 데 시간을 들였고, ZSF와 건강한 관계를 유지하려고 노력했으며, Bun은 그렇게 하지 않았다.
검토되지 않은 100만 줄의 코드를 모두 출하해도 된다는 주장의 근거는 테스트 스위트가 모든 것을 잡아낼 만큼 충분히 좋다는 것이다. 그렇다면 왜 Zig 코드에 짜증 나는 버그가 그렇게 많다고 말하는가? 모든 것을 잡아내기에 테스트 스위트가 충분하다던 주장은 어디로 갔는가? Zig 코드의 버그는 못 잡아내면서, 검토되지 않은 100만 줄의 엉터리 코드에서는 충분하다는 말인가?
성능 향상은 LTO 덕분이라고 돌리고 있는데, Zig는 Bun이 존재한 내내 LTO를 지원해 왔다. 예전에는 기본적으로 활성화되어 있었지만, 너무 많은 LLVM 버그에 부딪히면서 비활성화하게 되었고, 그 버그들은 Rust에도 똑같이 영향을 준다. 아마 우리는 당신들에게 그것을 활성화해 보라고 조언했을 텐데, 당신들은 듣지 않았을 것이다. 우리 조언은 꽤 괜찮다고!
그 글은 그들이 Zig 코드를 fuzzing하고 있었다고 주장하지만, 우리와의 통화에서 Bun 팀 전체는 아무것도 fuzzing하지 않고 있다고 말했다. 이것은 노골적인 날조처럼 보인다.
블로그 글은 바이너리 크기를 줄이기 위해 수행한 여러 엔지니어링 작업을 나열하면서, "Bun은 Rust에서 더 낫다"는 주장을 강화하려 한다. 하지만 그 모든 엔지니어링 작업은 재작성 자체와는 아무 관련이 없었다. 내 생각에 바로 이것이 블로그 글이 나오기까지 그렇게 오래 걸린 이유다. 애초부터 Zig 코드베이스에서 했어야 할 엔지니어링 작업을 이제야 하고 있었던 것이다. 우리는 수년간 당신들에게 comptime 남용을 경고해 왔다. 심지어 comptime/inline 사용과 컴파일 시간을 감사해야 하는 프로젝트들을 위해 이 time report 기능까지 만들었다.
나는 당신들이 컴파일 속도에 대해서는 언급하지 않았다는 점도 눈치챘다. Zig 컴파일러 프로젝트는 약 600,000줄의 코드로, 재작성 전 Bun과 대략 비슷한 규모인데, 나는 깨끗한 캐시에서 처음부터 빌드하는 데 16초를 기록하고 있고, 그 뒤 증분 컴파일을 활성화하면 각 후속 수정마다 90ms가 걸린다. 재작성 이후 Bun의 해당 측정치는 얼마인가?
조금 더 크게 보자면, 몇 가지를 분명히 하고 싶다.
첫째, 나는 Bun으로부터 ZSF가 받은 후원에 진심으로 감사한다. 우리는 그 돈으로 기여자들에게 Zig 작업 대가를 지급했다.
둘째, 사실 나는 Jarred 개인에 대해 비판할 점이 없다. 그는 나와 취향이 다르고, 삶에서 원하는 것도 다르다. 하지만 그는 자신이 있는 자리에서 실제로 행복하고 성공한 사람이라고 생각한다. 그는 인생에서 자신이 원하는 것들을 어떻게 이룰지 알아냈다. 그는 자신의 생산성 판타지 열병 같은 꿈을 실현하며 살고 있고, 아마 이미 엄청난 부자일 것이다. 약간의 기술 업계 셀러브리티 지위도 갖고 있다.
솔직히 말해, 그는 자기 삶을 잘 꾸려냈다고 생각하고, 나는 그에게 어떤 악의도 품고 있지 않다.
그렇다고 해도 우리의 사업적 이해관계가 더 이상 얽혀 있지 않아서 기쁘다! 인터넷이 언어 선택을 기준으로 재작성이 Bun에 좋았는지 나빴는지를 두고 공개적으로 언쟁하는 일을 멈추기만 하면, 우리의 상호작용도 그걸로 끝이라고 생각한다.
내 블로그 글을 읽어줘서 고맙다.
