Bun이 Zig에서 Rust로 — Phase-A 포팅 가이드와 한국 팀 점검표

Bun 런타임 저장소(oven-sh/bun)에 2026년 5월 4일 Bun 창업자 Jarred Sumner가 등록한 commit 46d3bc2(“docs: add Phase-A porting guide”)는 Bun 코드베이스의 Zig→Rust 포팅을 공식 문서화한 첫 단계입니다. 본 글은 해당 commit 내용과 PORTING.md 가이드의 핵심 규칙, 그리고 Bun에 의존하는 한국 개발 조직이 점검해야 할 항목을 정리합니다. 인용한 라인 수와 규칙은 모두 commit 46d3bc2의 patch 본문 기준입니다.

1. 무엇이 추가되었는가

해당 commit은 두 개의 새 파일을 추가합니다.

• docs/PORTING.md — 576줄 분량 신규 문서. 첫 줄은 “Zig → Rust porting guide”로 시작합니다.
• scripts/port-batch.ts — 46줄 분량의 포팅 일괄 처리 스크립트.

실제 .rs 코드는 아직 옮기지 않았습니다. 작업 규칙만 문서화한 단계로, Bun 팀의 점진적 전환 의도를 보여주는 공식 신호로 읽을 수 있습니다.

2. Phase-A와 Phase-B의 분리

PORTING.md는 작업을 두 단계로 나눕니다. Phase A의 목표는 본문 표현 그대로 “각 .zig 파일 옆에 같은 basename의 .rs 초안을 만들되, 컴파일되지 않아도 된다”입니다. 컴파일 가능성을 일부러 포기하고 로직 충실도를 우선합니다.

Phase B는 크레이트 단위로 컴파일을 잡고 Cargo.toml을 연결합니다. 코드 변환과 빌드 결합을 분리해 PR 검토를 단순화하려는 의도가 보입니다.

3. Phase-A 가이드의 핵심 규칙

PORTING.md 기준으로 Phase A가 강제하는 일관성 규칙은 다음과 같습니다.

• Zig 함수 시그니처와 필드 순서, 제어 흐름을 그대로 보존합니다.
• 함수명은 snake_case로 변환하되 대문자 2자 이상 연속이면 한 단어로 취급합니다(예: toAPI → to_api, errorInCI → error_in_ci).
• 번역할 수 없는 부분은 // TODO(port): <reason> 주석으로 표시합니다.
• 성능 영향이 의심되는 부분은 // PERF(port): <zig idiom> 주석으로 표시해 Phase B에서 grep으로 일괄 점검합니다.
• Zig의 deinit은 Rust에서 동명 메서드가 아니라 impl Drop으로 옮깁니다.

가이드 목표는 .rs 결과물이 원본 .zig와 한 줄 단위로 대조 가능하도록 만드는 것입니다. PORTING.md 표현 그대로 “Phase B reviewers diff .zig ↔ .rs side-by-side”가 검토 기준이 됩니다.

4. 사용이 금지된 의존성

가이드는 Rust 생태계 표준 비동기·병렬·HTTP 크레이트를 명시적으로 사용 금지 처리합니다.

• 비동기 런타임: tokio 금지
• 데이터 병렬: rayon 금지
• HTTP: hyper 금지
• 트레이트 비동기 어댑터: async-trait, futures 금지
• 표준 I/O: std::fs, std::net, std::process 금지
• 언어 차원 비동기: async fn 금지

근거는 PORTING.md에 명시되어 있습니다. “Bun owns its event loop and syscalls” — Bun이 자체 이벤트 루프와 syscall을 직접 보유하므로 외부 비동기 런타임이나 표준 I/O가 끼어들면 동시성 모델이 깨지기 때문입니다. core·std의 slice, iter, mem, fmt, core::ffi처럼 I/O를 만지지 않는 모듈은 허용됩니다.

async fn 금지도 같은 원칙입니다. 가이드는 “everything is callbacks + state machines, same as the Zig”라고 명시해 Zig의 콜백·상태 머신 구조를 Rust에서도 그대로 보존하도록 강제합니다.

5. 메모리 모델: mimalloc 강제

모든 크레이트의 바이너리 루트에 다음 선언이 필수입니다.

#[global_allocator]
static ALLOC: bun_alloc::Mimalloc = bun_alloc::Mimalloc;

선언 누락 시 글로벌 allocator가 mimalloc 대신 glibc malloc으로 silent fallback되어 성능 회귀가 발생합니다. Phase B에서 assertion으로 검증한다고 PORTING.md에 적혀 있습니다.

unsafe 정책도 같은 가이드에 명시되어 있습니다. Zig 원본이 안전하지 않은 곳에서는 Rust도 unsafe를 그대로 사용하되 모든 블록에 // SAFETY: <why> 주석으로 Zig invariant를 옮겨 적도록 합니다.

6. 크레이트 분할 구조

PORTING.md의 “Crate map” 표는 Zig 네임스페이스를 Rust 크레이트로 1:1 매핑합니다. 주요 매핑을 정리하면 다음과 같습니다.

• bun.String, bun.strings, ZigString → bun_str
• bun.sys, bun.FD, Maybe(T) → bun_sys
• bun.jsc, JSValue, JSGlobalObject → bun_jsc
• bun.uws(WebSocket·HTTP I/O) → bun_uws_sys(raw) + bun_uws(wrapper)
• bun.allocators, MimallocArena → bun_alloc
• bun.threading, ThreadPool → bun_threading
• bun.ast, js_parser, js_lexer → bun_js_parser
• bun.path, bun.PathBuffer → bun_paths

bun_paths가 특히 눈에 띕니다. std::path::Path 대신 bun_paths::SEP: u8, is_absolute(&[u8]) 같은 byte slice 기반 API를 자체 정의합니다. std::path가 OsStr 위에서 동작하는 반면 Bun 내부 path 처리는 &[u8] 기반이라 타입이 맞지 않기 때문입니다.

7. Bun 의존 한국 팀의 점검표

commit은 도큐먼트만 추가한 단계라 사용자 코드에 즉시 영향은 없습니다. 다음을 미리 점검해 두면 Phase B 시점의 운영 리스크를 줄일 수 있습니다.

• 버전 핀 정책: 프로덕션에서 Bun 마이너 버전을 핀하고 있는지 확인하세요. 포팅 진행 기간에는 동일 마이너 안에서도 빌드 산출물 차이가 발생할 수 있습니다.
• CI 캐시 키: Bun 베이스 이미지를 사용하는 CI 워크플로의 cache key에 Bun 버전을 포함했는지 점검하세요. Rust 산출물 비율이 늘어나면서 빌드 의존성이 변할 수 있습니다.
• bun:ffi 사용 여부: bun:ffi로 Zig·C 라이브러리에 직접 연결한 코드가 있다면 Phase B에서 ABI 변경 가능성이 있는지 oven-sh/bun discussions를 모니터링하세요.
• Rust 도구체인 보안 검토: 사내 빌드 노드에 Rust 툴체인을 추가 설치할 수 있는지 사내 보안·라이선스 검토를 미리 진행하세요. 신규 컴파일러 도입 절차가 필요할 수 있습니다.
• 장애 시나리오: Bun을 의존하는 서비스에 “Bun 다운로드 실패 시 Node.js fallback” 시나리오가 있는지 점검하세요. 포팅 기간에는 릴리즈 채널이 일시적으로 불안정할 가능성을 가정합니다.

8. Zig 생태계 영향과 정리

이 변화가 Zig 생태계 축소를 의미하지는 않습니다. PORTING.md 본문은 Zig 단점을 명시하지 않으며 결정 동기도 단정적이지 않습니다. 함수 시그니처와 제어 흐름 보존 규칙은 오히려 Zig 코드 자산 가치를 인정하는 시각입니다. Zig 도입을 검토 중인 한국 팀도 결정을 뒤집을 필요는 없고, 대형 사용자의 점진 전환 사례만 의사결정 근거에 추가하면 충분합니다. 커뮤니티 반응은 HN 스레드 ID 48016880에서 살필 수 있습니다.

• commit 46d3bc2는 Bun의 점진적 Zig→Rust 포팅 1단계 가이드이며 구현 코드는 아직 옮기지 않은 단계입니다.
• Bun을 프로덕션에 사용 중인 한국 팀은 즉시 행동할 사항은 없으나 버전 핀과 CI 캐시 키를 점검하고 Phase B 변화를 모니터링하세요.
• oven-sh/bun discussions와 commit 히스토리를 정기 확인하면 변경 시점을 놓치지 않을 수 있습니다.

관련 글

Bun 사례와 비슷한 외부 도구·서비스 운영 리스크 점검 패턴을 다룬 다른 글을 함께 참고할 수 있습니다.

• Warp 터미널 오픈소스 전환 — AGPL과 agent-first 도입 점검표 — 도구 라이선스·운영 모델이 바뀔 때 점검할 항목을 정리한 글입니다.
• Ghostty가 GitHub을 떠난다 — 한국 개발 조직이 점검할 운영 리스크 — 개발 도구의 호스팅 변경이 사내 워크플로에 미치는 영향을 다룬 글입니다.
• 27년 운영 도메인이 사라졌다 — GoDaddy 도메인 탈취 사고와 운영자 점검표 — 외부 의존성 리스크 관리 관점에서 함께 읽을 만한 글입니다.

---

📌 함께 보시면 좋은 글

• 개발자 커리어 체크리스트 →
• 개발 커리어 결정 가이드 →

※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)