지그 창시자가 본 Bun의 러스트 재작성: “이젠 내 문제가 아니다”

• 지그(Zig) 창시자 앤드루 켈리가 Bun의 러스트(Rust) 재작성에 대해 길고 매운 글을 썼음

  • 포인트는 “러스트가 지그보다 낫다” 같은 단순 언어 싸움이 아님
  • Bun이라는 프로젝트가 어떻게 지그 커뮤니티와 가까워졌다가, 스타트업과 코드 품질 문제로 멀어졌는지에 대한 내부자 시점 회고에 가까움
  • 표현은 꽤 직설적이고, 중간중간 거의 커뮤니티 게시판급으로 날카로움

• 초반 관계는 꽤 좋았음. Bun은 지그를 성능의 핵심 배경으로 공개적으로 인정했고, 지그 소프트웨어 재단에 돈도 냈음

  • Bun 창업자 Jarred는 웹사이트에서 Bun의 성능 성과에 Zig를 크레딧으로 올렸음
  • 지그 소프트웨어 재단에는 월간 기부를 설정했고, 규모는 연 6만 달러였음
  • 글쓴이도 이 부분은 고맙다고 인정함. 지그 기여자들에게 돈을 지급하는 데 실제로 도움이 됐다고 함

• 갈등의 시작은 Bun이 벤처 투자 받은 스타트업이 되면서였다고 봄

  • 글쓴이는 Jarred가 초기에 “beginner energy”가 강했다고 표현함. 빠르게 부딪히고 많이 배우는 태도 자체는 젊은 개발자에게 건강한 방식이라고 봤음
  • 그런데 회사가 되고 매니저가 되자, 그 속도와 압박이 다른 사람에게 전가되는 문제가 생겼다고 비판함
  • Oven 채용·근무 경험자들과 이야기해보니 커뮤니케이션, 기대치, 공감, 관리 경험이 다 엉망이었다는 식으로 꽤 세게 말함

• 가장 큰 문제는 결국 코드 품질이었다고 함

  • 지그 팀은 사용자 프로젝트를 주기적으로 읽으면서 언어가 실제 코드에 어떤 영향을 주는지 확인한다고 함
  • Bun 코드베이스에서는 해킹성 구현 위에 또 해킹성 구현이 쌓이고, assert 남용, 버그와 기술부채를 정리할 시간 없이 기능만 빠르게 밀어붙이는 패턴을 봤다고 주장함
  • 글쓴이는 “LLM이 나오기 전부터 이미 slop을 쓰고 있었다”는 식으로, 요즘식 AI 코드 논쟁과도 연결해서 깜

• Anthropic이 Bun을 인수했을 때, 지그 재단 쪽은 오히려 안도했다고 함

  • 기부가 조용히 끊겼지만 이미 예상하고 있었다고 함
  • 정기 미팅을 취소하지도 않고 참석하지도 않았을 때도 놀라지 않았다고 적음
  • Claude가 Bun 위에서, Bun이 Zig로 작성됐다는 간접 연결 때문에 Zig 커뮤니티에 AI 관련 저품질 기여와 분위기 변화가 몰려오는 것도 부담이었다고 함

• Bun의 러스트 재작성 발표는 지그 쪽에서 “잘됐다”는 반응이었다고 함

  • 글쓴이는 러스트 재작성이 올 것이라고 며칠 안에 예상했고, 실제 발표가 나오자 기뻤다고 함
  • 심지어 “이제 내 문제가 아니다”라는 문구가 적힌 머그잔에서 차를 마시는 기분이라고 비유함
  • 이 정도면 언어 경쟁에서 졌다는 느낌이 아니라, 부담스러운 연결고리가 끊겼다는 해방감에 가까움

• Bun의 공식 블로그에 대한 반박도 구체적임. 특히 “테스트가 충분하니 100만 줄짜리 미리뷰 코드도 괜찮다”는 논리에 의문을 던짐

  • 테스트 스위트가 그렇게 좋다면 기존 Zig 코드의 짜증 나는 버그들은 왜 못 잡았냐는 질문임
  • Zig 코드의 버그는 못 잡는데, 100만 줄의 리뷰 안 된 새 코드 버그는 잡을 수 있다는 주장이 앞뒤가 맞냐는 것
  • 여기서 언어 기능보다 버그 제거에 투입한 엔지니어링 리소스가 핵심이라고 강조함

• 성능 향상 원인으로 제시된 LTO(Link Time Optimization)에도 반박함

  • 글쓴이는 Zig가 Bun의 전체 역사 동안 LTO를 지원해왔다고 말함
  • 한때 기본 활성화였지만 LLVM 버그 때문에 꺼졌고, 그 버그는 러스트에도 영향을 준다고 설명함
  • 즉 “Rust라서 빨라졌다”기보단 “원래 해볼 수 있던 최적화를 이제 한 것 아니냐”는 뉘앙스임

• 퍼징(fuzzing) 주장도 정면으로 의심함

  • Bun 블로그는 Zig 코드에 퍼징을 했다고 말한 모양인데, 글쓴이는 과거 통화에서 Bun 팀 전체가 아무것도 퍼징하지 않는다고 말했다고 함
  • 그래서 이 부분은 “명백한 조작처럼 보인다”는 수준으로 강하게 표현함
  • 오픈소스에서 이런 주장은 꽤 치명적임. 테스트했다는 말은 신뢰 자산이라서 대충 쓰면 바로 역풍 맞음

• 바이너리 크기 개선도 러스트 재작성의 직접 성과로 보기 어렵다고 주장함

  • 블로그가 바이너리 크기 줄이기 작업을 많이 설명했지만, 글쓴이는 그건 언어 전환과 별개로 원래 Zig 코드베이스에서 했어야 할 엔지니어링이라고 봄
  • 특히 Zig의 comptime과 inline 남용을 수년간 경고해왔다고 함
  • 지그 쪽은 컴파일 시간과 comptime 사용을 감사하기 위한 리포트 도구까지 만들었다고 언급함

• 컴파일 속도 비교도 요구함

  • Zig 컴파일러 프로젝트는 약 60만 줄이고, 글쓴이 환경에서 클린 캐시 빌드는 16초라고 함
  • 증분 컴파일을 켜면 이후 편집마다 90밀리초 수준이라고 제시함
  • Bun 재작성 후 대응 수치는 뭐냐고 묻는데, 이건 꽤 실무적인 질문임. 런타임 성능만큼 개발 루프 속도도 중요하니까

---

기술 맥락

• 이번 논쟁에서 기술적 선택은 Bun 런타임을 Zig에서 Rust로 옮긴 거예요. 겉으로는 메모리 안전성과 생태계 선택처럼 보이지만, 글쓴이가 집요하게 묻는 건 “정말 언어 때문에 좋아졌냐, 아니면 미뤄둔 엔지니어링을 이제 한 거냐”예요.

• LTO 사례가 딱 그래요. 링크 단계에서 전체 프로그램을 보고 최적화하면 성능이나 바이너리 크기가 좋아질 수 있는데, Zig도 이미 지원하던 기능이었다는 거죠. 그래서 원인을 언어 하나로 돌리면, 실제로 어떤 작업이 성능을 만들었는지 흐려져요.

• 퍼징과 테스트도 마찬가지예요. 자바스크립트 런타임처럼 입력 표면이 넓은 프로젝트는 이상한 입력을 계속 넣어 깨지는 지점을 찾는 과정이 중요해요. 그런데 테스트가 충분하다는 말과 기존 버그가 많았다는 말이 동시에 나오면, 개발자 입장에서는 신뢰가 흔들릴 수밖에 없어요.

• comptime 이야기는 Zig 특유의 맥락이에요. 컴파일 시간에 강력한 일을 할 수 있지만, 남용하면 빌드 시간과 바이너리 크기를 잡아먹어요. 글쓴이는 Bun이 이 비용을 오래 방치했고, 나중에 한 정리 작업을 러스트 전환의 승리처럼 포장했다고 보는 거예요.

• 결국 이 글은 언어 벤치마크보다 조직의 품질 관리 체계가 더 중요하다는 얘기에 가까워요. 리뷰, 테스트, 퍼징, 빌드 시간 관리, 기술부채 정리를 꾸준히 하지 않으면 어떤 언어를 골라도 같은 문제가 다른 모양으로 돌아오거든요.