Bun의 Rust 재작성에 대한 내 생각

https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html
Andrew Kelley = Zig 창시자

배경: Bun을 Rust로 다시 쓰다

지난 이야기

Jarred가 약 5년 전 Zig 커뮤니티에 합류했을 때, 나는 그를 "초심자 에너지(beginner energy)"가 넘치는 사람이라고 표현했다. 빠르게 움직이며 이것저것 다양하게 시도하고, 아직 해결할 역량이 안 되는 문제에도 겁 없이 뛰어드는 사람이라는 뜻이다. 그래서 엔지니어링 결과물은 평범한 수준에 그쳤지만, 그 과정에서 정말 많은 것을 배웠다. 나는 이것이 특히 젊은 사람과 학생에게는 꽤 건강한 태도라고 본다. 실력을 키우고 새로운 것을 배우는 데는 이만한 방법이 없다.

그가 Bun에 힘을 쏟기 시작하면서 주목을 받기 시작했다. JavaScript는 세계에서 가장 인기 있는 프로그래밍 언어이니, 유망한 새 툴체인에 쏠릴 수 있는 눈길은 엄청나게 많다.

이 주목은 여러 방식으로 활용할 수 있었다. 예를 들어 크라우드펀딩만으로도 샌프란시스코 물가 기준으로도 넉넉한 생활을 꾸리기에 충분했을 것이다. 하지만 그는 대학 대신 틸 펠로우십(Thiel Fellowship)식 사고방식을 몸에 익힌 사람이었고, 어린 시절부터 실리콘밸리 사고방식을 무비판적으로 받아들이도록 길러진 셈이었다. 그리고 그는 벤처캐피털 투자를 받았다.

Jarred는 처음부터 Zig 프로젝트에 고마움을 표하는 사람이었다. Bun 웹사이트에 프로젝트의 성능 성과가 Zig 덕분이라고 명시했고, Zig 소프트웨어 재단에 연간 6만 달러에 이르는 월 기부를 시작했다. 둘 다 의무가 아니었는데도 그렇게 했고, 꽤 멋진 일이었다. 내가 지금 언급하는 그의 블로그 글에서도 그는 Zig 프로젝트에 진심 어린 감사로 느껴지는 마음을 표현하고 있다.

하지만 Bun이 벤처캐피털의 투자를 받은 스타트업이 되자 그는 결승선을 향해 내달리기 시작했다. 이제 Jarred는 커뮤니티와 함께 배우고 성장하는 자유·오픈소스 프로젝트가 아니라 사업을 운영하는 사람이었다. 그가 갑자기 관리자가 된 바로 이 시점부터, 그 "초심자 에너지"가 내게는 다르게 느껴지기 시작했다. 스스로 워라밸을 포기하는 것과 남에게 그것을 요구하는 것은 전혀 다른 문제다:

"Oven에서 일하는 건 고된 일이 될 겁니다. 특히 처음 9개월 정도는요. 워라밸이 일하지 않는 시간을 많이 갖는 것을 뜻한다면, 아마 잘 맞지 않을 거예요."

재미있는 사실 하나: 사람들은 서로 이야기를 나눈다.

나는 Oven에 면접을 본 사람들과 이야기했다. 거기서 일했던 사람들과도 이야기했다. 그 사람들끼리도 서로 이야기했다. 모두가 모두와 이야기했다. 소문의 포도덩굴은 크고 무성해서 즙 많은 포도가 주렁주렁 달려 있었는데, 그 포도알 하나하나에 담긴 즙은 전부 같은 메시지였다. Jarred는 형편없는 관리자라는 것. 소통은 엉망이고, 기대치는 비현실적이고, 공감 능력은 낮고, 경험은 없었다. 고용이라는 관점에서 보면 그야말로 총체적 난국이었다.

그 결과, Zig 커뮤니티 구성원들은 업무 시간에 Zig 코드를 짜는 일자리를 간절히 원했음에도, 인재풀 대부분이 Oven과 Bun을 피해 갔다.

같은 시기에 Zig와 Jarred 사이의 골도 벌어지기 시작했다. 생산성과 자기 스타트업의 엑싯 전략에만 몰두하는 그의 태도는 Zig 프로젝트를 향한 나의 장기 비전과 점점 더 부딪혔다. 내게는 더 큰 계획이 있었는데도, 그가 다른 우선순위를 전부 내려놓고 Language Server Protocol 구현과 VSCode 통합부터 하라고 계속 졸라댔던 기억이 난다.

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

Zig 팀은 사용자들의 프로젝트를 정기적으로 살펴본다. 언어가 사용자에게 어떤 영향을 주는지 소스 코드를 읽어 확인하고, 언어 변경이 얼마나 심각한 호환성 파손을 일으킬지 테스트하고, 성능 퇴행 여부도 점검한다.

우리는 Bun 코드베이스에서 목격한 프로그래밍 관행에 점점 더 경악하게 됐다. 임시방편 위에 또 임시방편. Assertion 남용. 무엇보다도, 버그와 기술 부채를 돌아보고 정리하는 시간은 거의 갖지 않은 채 기능에서 기능으로 무모하게 내달리는 것. Jarred는 LLM을 손에 넣기 훨씬 전부터 이미 슬롭(slop)을 쓰고 있었다. 물론 사용자가 무엇을 하든 우리가 단속할 일은 아니지만, 사람들이 메모리 안전성 문제로 우리 면전에서 끊임없이 소리를 질러댄다는 건 다들 눈치챘을 것이다. 사람들이 벼르고 있는 바로 그런 비판을 자초하는, 무책임한 소프트웨어 엔지니어링 관행의 프로젝트와 우리가 왜 거리를 두고 싶어 했을지 짐작이 갈 것이다.

우리는 더 나은 프로그래밍 관행으로 이끌어 보려 했지만 소용없었다. 제대로 굴러가지 않는 회사 안에서 최선을 다한 몇몇 특별한 영웅들도 있었다. 본인들은 알 것이다. 하지만 밀려오는 파도를 막을 수는 없는 법이다.

이 무렵 ZSF의 우리 모두는 Bun이 득보다 실이 큰 존재라고 느끼고 있었다. RoboBun이 기여자 1위가 되기 전의 일이다. 세간에서 Zig 프로그래밍 언어의 간판으로 여겨지는 프로젝트가 실은 "Zig 코드를 이렇게 쓰면 안 된다"의 대표 사례라는 불편함에 더해, 언젠가 그들은 회사를 매각할 것이고(솔직히 말해 "클라우드 뭐시기를 팔겠다"는 그들의 두루뭉술한 사업 계획은 애초부터 우스운 얘기였다), 우리는 불똥이 튀어 부정적인 여론을 뒤집어쓸 것이고, 그 정기 기부도 끊길 터였다.

그래서 마침내 Anthropic의 인수가 성사되었을 때, ZSF의 우리는 안도의 한숨을 내쉬었다. 기부가 소리 소문 없이 끊겼을 때도 우리 은행 계좌는 이미 대비가 되어 있었다. 그들이 우리와의 월례 미팅을 취소하지도, 나타나지도 않았을 때도 놀라지 않았다. 관계는 끝난 것이었다.

재작성의 조짐은 이미 뚜렷하게 보였다. 불과 며칠 만에 우리는 벌써 Rust 재작성이 다가오고 있음을 직감했다. 그리고 우리는 그것을 응원하고 있었다! 거대 AI 회사에 인수됐다는 사실은 부담이었다. Claude가 Bun으로 작성됐고 Bun이 Zig로 작성됐다는 간접적인 연결 고리만으로도 지나가며 던지는 슬롭 기여가 급증했을 뿐 아니라, 포럼 게시글에 LLM 출력물을 붙여넣는 게 몰상식한 행동이라는 것부터 가르쳐 줘야 하는 눈치 없는 AI 열성팬들까지 Zig 커뮤니티로 밀려들어 왔기 때문이다. 한동안은 Zig의 정체성이 "AI와 엮인 프로그래밍 언어"로 통하게 될까 봐 두렵기까지 했다.

Jarred가 Rust 재작성을 발표했을 때 우리는 뛸 듯이 기뻤다. 너무 좋아서 믿기지 않을 정도였다. 솔직히 이런 곡예를 해낼 만큼 기술이 무르익었다고는 생각하지 못했다. 하지만 그는 해냈고, 지금 나는 "이제 내 문제가 아닌 맛(It Tastes Like It's Not My Problem Anymore)"이라고 적힌 머그잔으로, 비유하자면 맛 좋은 차를 홀짝이고 있다.

블로그 글 짚어보기

그 블로그 글은 아주 능숙하게 쓰였다. 마치 시가총액 1조 달러짜리 회사의 마케팅 부서가 이 글 하나에 큰돈을 걸기라도 한 것 같다.

다만 몇 가지 따지고 싶은 점이 있다.

이 글은 버그를 피하려면 "스타일 가이드"와 프로그래밍 언어 기능 중 하나를 택해야 한다는 식의 이분법을 내세운다. 이런 눈속임은 버그를 없애는 진짜 핵심, 즉 거기에 엔지니어링 자원을 투입하는 일에서 독자의 시선을 돌려놓는다. TigerBeetle에 대한 평가도 한참 박하다. 그들은 그저 시간을 들여 버그를 찾아 없앴고, ZSF와 건강한 관계를 유지하려 노력했다. Bun은 그 둘 중 어느 것도 하지 않았다.

리뷰도 거치지 않은 코드 100만 줄을 통째로 내보내도 된다는 근거는 테스트 스위트가 모든 걸 잡아낼 만큼 훌륭하다는 것이다. 그렇다면 Zig 코드에 성가신 버그가 그렇게 많다는 말은 왜 하는가? 모든 걸 잡아내기에 충분하다던 테스트 스위트는 어디로 갔는가? Zig 코드의 버그를 잡기에는 부족한데, 리뷰 안 된 슬롭 100만 줄의 버그를 잡기에는 충분하다고?

성능 향상의 공은 LTO에 돌리고 있는데, LTO는 Bun이 존재한 내내 Zig가 지원해 온 기능이다. 원래는 기본으로 켜져 있었지만 LLVM 버그를 너무 많이 만나서 껐고, 그 버그들은 전부 Rust에도 똑같이 영향을 준다. 우리가 켜 보라고 분명 말했을 텐데 듣지 않았을 것이다. 우리 조언은 쓸 만하다니까, 젠장!

그 글은 마치 Zig 코드를 부지런히 퍼징(fuzzing)해 온 것처럼 이야기하지만, 우리와의 통화에서 Bun 팀은 아무것도 퍼징하고 있지 않다고 말했다.

블로그 글은 "Rust로 만든 Bun이 더 낫다"는 주장을 뒷받침하려고 바이너리 크기를 줄이기 위해 수행한 여러 엔지니어링 작업을 늘어놓는다. 하지만 그 엔지니어링 작업은 전부 재작성과는 아무 상관이 없다. 블로그 글이 나오기까지 그렇게 오래 걸린 이유가 바로 이것(특히 글의 "바이너리 크기" 섹션)이라고 생각한다. 처음부터 Zig 코드베이스에서 했어야 할 엔지니어링 작업을 그제야 하고 있었던 것이다. 우리는 몇 년째 comptime 남용을 경고해 왔다. comptime/inline 사용과 컴파일 시간을 점검해야 하는 프로젝트를 위해 이런 타임 리포트 기능까지 만들어 뒀을 정도다.

컴파일 속도 얘기는 쏙 빼놓은 것도 눈에 띄었다. Zig 컴파일러 프로젝트는 약 60만 줄로, 재작성 전 Bun과 거의 같은 규모다. 내 기준으로 캐시를 비운 상태에서 처음부터 빌드하면 16초, 증분 컴파일을 켜면 이후 수정마다 90ms가 걸린다. 재작성 후 Bun의 같은 측정치는 얼마인가?

이제 앞으로

여기서 핵심 문제는 Zig 대 Rust라는 언어 기능과는 아무 관련이 없다. 문제의 전부는 두 프로젝트의 가치관이 갈라진 것, 그리고 그에 뒤따른 관계의 파탄이었다.

시야를 조금 넓혀서, 한 가지는 분명히 해 두고 싶다.

Bun을 Zig의 망신거리로 만든 것에 대해 Jarred에게 분한 마음이 있고, 우리가 겪어 온 슬롭의 일부는 그의 책임이라고 보며, 그의 리더십에 대한 내 비판도 거두지 않겠지만, 동시에 그에게 공감도 한다. 그는 나와 가치관이 다르고, 인생에서 원하는 것도 나와 다르다. 하지만 그는 지금 있는 바로 그 자리에서 실제로 행복하고 성공했다고 생각한다. 그는 자기가 원하는 것들을 전부 이뤄내는 법을 알아냈다. 자신의 생산성 판타지라는 열병 같은 꿈을 실제로 살아내고 있고, 아마 이미 엄청난 부자일 것이다. 테크 업계의 소소한 유명인 지위도 갖고 있다.

솔직히 그는 자기 인생을 잘 꾸렸다고 생각한다. 분한 감정이 남아 있고 지금 내가 Anthropic의 마케팅 조직과 싸우는 처지가 됐음에도, 그가 잘못되기를 바라지는 않는다. 이 답답함 속에서도, 그의 기준에서 이룬 그의 성공을 진심으로 축하한다.

이 블로그 글은 Jarred에 대한 인신공격으로 받아들여졌지만, 원래 나는 실패한 비즈니스 관계의 이야기를 들려주려는 글로 썼다. 내 의도대로 읽히지 않은 이유는, 독자에게는 뻔히 보이는데 정작 나 자신은 몰랐던, 소화되지 않은 분노의 감정이 남아 있었기 때문이다. 자기 성찰과 친구들과의 대화 끝에 이 결론 섹션을 고쳐 썼다. 원래 글이 궁금하다면 이 웹사이트의 공개 소스 저장소에서 얼마든지 확인해 봐도 좋다.

이 글에서 내가 저지른 또 하나의 결정적 실수는, 꽤 뻔하고도 중요한 지점을 놓친 것이다. 이런 사정을 거의 모르는 채 "언어 창시자가 Zig를 떠난 사용자를 헐뜯고 있다"는 겉모습만 아는 Zig 사용자들에게 이 글이 어떻게 다가갈지 생각하지 못했다. 그런 사람들이 "나한테도 저럴 수 있겠구나" 하고 걱정하는 건 당연한 일이다. 그렇게 느끼게 만든 분들께 미안하다. 지금 시점에서 내가 말할 수 있는 건, 나와 ZSF 동료들은 Zig를 공개적으로 사용하고 이야기하는 거의 모든 사람과 아주 좋은 관계를 맺고 있으며, 이번 일이 유일한 예외라는 것뿐이다. 아무런 잡음 없이 Zig를 떠나기로 한 사람도 많다. 시가총액 1조 달러짜리 회사가 먼저 포문을 열었다는 점을 감안해서, 조금은 너그럽게 봐주면 좋겠다.

여기서 내가 갈 길은 분명하다. 요즘 작업 중인 것들을 시연하는 것처럼 긍정적인 내용에 블로그의 초점을 맞추는 것이다. 그래야 Zig 커뮤니티에서 실제로 벌어지고 있는 일, 즉 느긋한 사람들이 모여 멋진 것을 함께 만들며 즐겁게 지내고 있다는 현실을 더 정확하게 전할 수 있을 테니까.