Buz – 최신 Zig와 1초 미만 증분 빌드를 지원하는 Bun 포크

• Buz는 Bun의 Rust 재작성 직전 커밋에서 출발해, 최신 Zig 기반의 호환 가능한 대체재를 목표로 개발 중인 초기 단계 포크임
• JavaScriptCore 벤더링 소스까지 전체 빌드 그래프를 build.zig로 옮기고 Zig에 소규모 패치를 적용해 1초 미만 증분 빌드를 구현함
• Rust 버전 Bun의 새 기능·버그 수정 테스트를 가져왔지만 실패하는 테스트가 많아, 업스트림 기능과 JavaScriptCore 변경을 계속 따라가야 함
• 사용되지 않는 코드 11,000줄 이상을 제거하고 일부 구현을 Zig 표준 라이브러리 중심으로 현대화하는 과정에서 여러 버그도 수정함
• 아직 프로덕션에 쓸 수 없으며, LLM과 사람의 감독을 함께 활용해 기술 부채를 줄인 뒤 LLM 없이도 유지보수하기 좋은 코드베이스를 만드는 것이 장기 목표임

---

프로젝트 목표와 개발 상태

• Buz는 Bun이 Rust로 재작성되기 전 마지막 커밋을 기반으로 한 개발 중인 포크임
• Bun과 호환되는 대체재이면서 기존보다 정돈된 코드베이스를 만드는 데 초점을 맞춤
• 개발이 매우 초기 단계라 프로덕션에 사용할 준비가 되지 않았음
• 유사한 Zig 기반 Bun 프로젝트가 이미 Ziggit에 공개된 상황에서 개발 작업의 중복을 피하고자 Buz를 공개함
  • 공개 당시에는 해당 프로젝트를 아직 검토하지 않은 상태였음

최신 Zig 포팅과 증분 빌드

• Bun을 현재 업스트림 Zig로 포팅하고, 증분 재빌드를 위해 Zig에 소규모 패치를 적용함
• JavaScriptCore의 벤더링 소스를 포함한 전체 빌드 그래프를 build.zig에 통합함
• 이 구성으로 증분 빌드 시간이 1초 미만으로 줄어 개발 반복 주기가 빨라짐
• 프로젝트에는 증분 빌드 패치를 적용한 Zig master 서브모듈이 포함됨
• 당시 업스트림 Zig 커밋 2b1c663에서도 정상적으로 빌드 가능함

호환성 테스트와 업스트림 추적

• Rust 버전 Bun에 추가된 테스트를 가져왔으며, 새 기능과 버그 수정을 검증하는 테스트도 다수 포함됨
• 아직 통과하지 못하는 테스트가 많아 Bun 업스트림을 계속 따라잡아야 함
• 기능 호환성을 유지하면서 코드를 정리하고 기술 부채를 줄이는 작업도 병행함
• JavaScriptCore 변경 역시 지속해서 추적해야 함

코드베이스 정리와 현대화

• Bun에서 전혀 사용되지 않는 코드 11,000줄 이상을 제거함
• 일부 코드를 재작성·현대화하면서 Zig 표준 라이브러리 활용을 늘림
• 정리와 현대화 과정에서 여러 버그도 함께 수정함
• 기존 Bun 코드베이스는 약 60만 줄 규모이며, 정돈된 상태에 도달하려면 상당수 하위 시스템을 다시 작성해야 한다고 봄

LLM 활용과 기여 방침

• 복잡한 기존 코드를 정리하기 위해 LLM을 광범위하게 활용하되, 사람의 감독과 더 나은 개발 관행을 함께 적용할 계획임
• 코드베이스가 충분히 정돈됐다고 판단할 때까지 사람이 직접 작성한 기여는 받지 않을 방침임
• 기술 부채 축소와 관용적인 Zig 코드 작성을 우선하며, 수주 또는 수개월 안에 Rust Bun 1.4.0의 호환 대체재로 내놓을 수 있는 코드베이스를 목표로 함
• Sol 또는 Fable을 사용할 수 있는 개발자의 지원을 요청함
• 장기적으로는 LLM의 도움 없이도 유지보수하기 편한 코드베이스를 만들고, 개발 과정에서 Zig 역량도 높이려 함

[GN⁺]

Hacker News 의견들

• 이 포크에서 가장 흥미로운 사실은 Bun도 진작 빠르게 빌드할 수 있었다는 점을 입증했다는 것임
  아직 Zig 증분 컴파일은 aarch64를 지원하지 않고 바이너리 패치도 Linux 링커에서만 가능하지만, 주요 플랫폼 지원은 시간문제로 보임
  • 빌드 속도를 높이려고 Zig 컴파일러를 포크한 일을 둘러싼 소란을 생각하면 이게 최상단 댓글이 아닌 것이 놀라움
    1인 팀이 1초 빌드를 달성했다는 사실은 느린 빌드가 부주의한 개발 관행의 결과였고, 포크에 시간을 쓴 것은 완전히 잘못된 자원 배분이었음을 보여줌
• LLM이 망가뜨린 코드를 다시 LLM으로 정리한다니, 2026년에 기술의 정점에 도달한 듯함
  • 지금까지도 인간이 망가뜨린 코드를 인간이 정리해 왔으니 논리적 모순은 아님
  • LLM의 결과물은 이를 지시하는 사용자의 역량만큼 좋아짐
  • AI에 회의적이지만 사용할 의향은 있는데, LLM이 정말 자기 결과물을 스스로 정리할 수 있다면 판도를 바꿀 만함
  • 같은 생각이었지만 바로 뒤에서 인간이 주도권을 잡고, 기술 부채를 줄이며 관용적인 Zig 코드를 작성해 몇 주나 몇 달 안에 Rust Bun 1.4.0을 대체할 만한 코드베이스를 만들겠다고 밝힘
    결국 더 많이, 혹은 더 잘 지시하겠다는 뜻으로 보임. 코드 구조는 취향의 영역 같기도 한데, 어제는 HTTP 요청 하나를 처리하는 데 백엔드 프로세스 네 개가 필요하다고 고집하는 친구와 황당한 대화를 나눴음
  • 애초부터 이런 방향이었음. 인간이 읽거나 이해할 수 없는, 소프트웨어 모양만 한 망가진 LLM 출력물이 코드가 되고 있으니 결국 모든 코드는 기계가 읽고 쓰도록 만들어질 수밖에 없음
    인간이 개입하는 시대는 처음부터 임시 단계였다고 봄
• Bun에서 완전히 죽은 코드 11,000줄을 제거하고 표준 라이브러리를 더 활용하도록 현대화하면서 수많은 버그까지 고쳤다니 놀라움
  대규모 프로젝트에서는 흔한 일인데 단지 내가 몰랐던 것인지 궁금함
  • 전체가 60만 줄이므로 죽은 코드는 약 1.8% 임. 큰 코드베이스일수록 코드가 실제로 사용되지 않는지 판단하려면 넓은 범위를 살펴야 하고, 시간이 지나며 멀리 떨어진 변경이 죽은 코드를 만들기도 해 더 흔함
    if (false) { dead_code(); }처럼 명백한 코드인지, 동적 디스패치는 가능하지만 논리상 호출될 수 없는 코드인지는 불분명함. 전자라면 1.8%는 높지만 후자라면 낮을 수도 있으며, 오래된 기능 플래그 뒤에 사실상 영원히 실행되지 않을 코드가 쌓인 프로젝트도 많음
    단순한 유틸리티나 생성 코드처럼 소량의 죽은 코드는 남겨도 괜찮지만, 제거가 연쇄적인 삭제와 단순화로 이어질 때도 있음
  • 이전 회사에서 1만 줄짜리 컴포넌트를 2천 줄로 축소하면서 주요 버그를 모두 고쳤음
    엄밀히 말해 죽은 코드는 아니었지만 작은 잘못된 추상화 하나를 정리하면 다음 정리 기회가 연이어 열리고, 결국 의도한 일만 하는 소프트웨어가 남게 됨. 코드베이스는 시간이 지나며 비대해지므로 Bun 규모에서 11,000줄밖에 찾지 못했다는 쪽이 더 놀라움
  • Zig 컴파일러는 지연 컴파일하므로, 컴파일된 함수 어디에서도 호출되지 않는 죽은 함수를 탐지하지 않음
  • Bun의 개발 방식을 고려하면 예상보다 적으며, 코드베이스에 훨씬 더 많이 남아 있을 듯함
  • 대규모 코드베이스에서 이 정도 죽은 코드에 놀라는 것이 오히려 놀라움. 보통 크기의 PR 약 10개 분량에 불과함
• 프로그래밍 경력이 얼마나 되기에 죽은 코드 11,000줄을 그렇게 이례적으로 보는지 궁금함
  • 경력은 10년이 넘음. 어떤 곳에서도 호출되지 않는 명백한 죽은 코드를 뜻했으며, 이 정도로 많은 다른 프로젝트가 있는지 궁금함
• 에이전트 중심 코딩 프로젝트마다 기능 개발과 코드 관리 사이에서 틱톡 진동이 나타났음
  틱 단계에서는 기능을 빠르게 추가해 정확하지만 극도로 지저분한 버전을 만들고, 톡 단계에서는 결과물을 소화하고 정리해 성능·유지보수성·변경 취약성을 개선함
  하루 동안 바이브 코딩으로 동작하는 앱을 만든 뒤, 카드로 쌓은 집처럼 무너지지 않고 기능을 계속 추가할 수 있는 프로젝트로 만드는 데 일주일을 쓰곤 함. AI 이전에도 비슷했지만 전문 개발자는 시스템에 대한 심성 모형이 더 강했고 작업 속도도 느려서 전환이 이만큼 급격하지 않았음
  • 결국 코드를 직접 살펴보며 로직이 곳곳에 중복되지 않고 실제로 유지보수 가능한지 확인해야 함
    코딩 모델은 캡슐화를 깨는 지름길을 택하거나 중복하면 안 되는 코드를 복제하는 경향이 강함
• 이를 과시성 성능 프로그래밍이라 부르고 싶음. 성능을 좋아하고 빌드 시간도 0초에 가까워야 하지만, 이제는 수확 체감 구간에 들어섰으며 현재 병목이 빌드 시간은 아닐 것임
  • Bun 개발자들은 증분 컴파일을 활용하지 못한 상황에서 직접 긴 대기 시간을 겪었으므로 이에 동의하지 않을 것임: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    큰 프로젝트에서는 테스트를 실행하거나 의미 오류를 확인할 때마다 몇 분씩 기다릴 수 없으므로 빌드 시간은 분명한 병목임
  • 이런 프로젝트에는 빠른 빌드가 필수이며, 유지보수를 쉽게 만드는 중요한 단계라고 봄
• 코드 품질을 중시하는 사람이 관리하는 Bun이라면 환영이지만, 헤라클레스급 과업임
  • 헤라클레스급보다는 끝없이 반복되는 시시포스급 과업에 가까움
• 정반대로 AI 기여만 받는 Zig 포크도 보고 싶음
  AI를 강하게 지지해서라기보다 개념 예술이나 실험으로 두 프로젝트가 어떻게 다르게 진화하는지 보면 재미있을 듯함
• 관련성이 높은 Cruller도 재작성 전 Bun 코드베이스를 사용하지만 프로덕션용 런타임 부분에만 집중함
  링크: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  HN 토론: https://news.ycombinator.com/item?id=49017344
• Bun이 왜 이렇게 화제인지 모르겠음. 그냥 Node + npm + Vitest + Vite로 돌아가면 안 되는지 궁금함
  • Bun의 장점을 Node에 제공하려는 Nub 프로젝트가 있으며, 사람들이 Bun을 선호하는 이유와 기존 도구의 간극도 잘 보여줄 수 있음
    https://nubjs.com
  • 바로 그 나열이 화제의 이유임. 수많은 도구를 조합하는 대신 필요한 일을 모두 처리하는 단일 런타임을 쓸 수 있음
    목적별 도구를 조합하는 것도 문제는 없지만 기본 상태에서 모든 문제가 해결되는 편이 매우 편리함. Bun 번들러에는 런타임 API도 있어, 자산을 제공하는 동일 프로세스가 외부 번들러와 조율하거나 정적 파일을 디스크에 쓰지 않고 메모리에서 바로 번들링할 수 있음
  • 네 가지 도구를 나열해야 한다는 사실 자체가 기존 상황이 얼마나 나쁜지 보여줌
  • 이제는 npm을 계속 사용해야 할 이유도 불확실함