Bun의 Rust 재작성은 어떻게 진행되고 있나? — JavaScript 런타임의 Rust 전환 현황과 성능 임팩트

Bun의 Rust 재작성은 어떻게 진행되고 있나? — JavaScript 런타임의 Rust 전환 현황과 성능 임팩트

원문: 긱뉴스 — Bun의 Rust 재작성은 어떻게 진행되고 있나?

1. Bun의 Rust 전환, 왜 지금인가

Bun은 2022년 처음 공개된 이후 JavaScript/TypeScript 런타임 시장에서 빠르게 성장해 온 프로젝트입니다. 초기에는 Zig로 작성되어 빠른 부팅과 뛰어난 성능을 어필했지만, 생태계가 커지면서 언어 자체의 한계와 유지보수 부담이 명확해졌습니다. 2024년 말부터 Bun 팀은 런타임 코어와 표준 라이브러리의 일부를 Rust로 재작성하는 작업을 점진적으로 공개하기 시작했고, 2026년 중반 현재 이 전환은 단순한 언어 교체가 아니라 런타임 아키텍처 전반의 재설계로 자리 잡고 있습니다.

Rust 전환의 직접적인 동기는 세 가지입니다. 첫째, 메모리 안전성 — JS 객체와 네이티브 리소스를 다루는 영역에서 use-after-free나 데이터 레이스가 간헐적으로 보고되었고, Rust의 소유권 모델이 이를 컴파일 타임에 차단해 줍니다. 둘째, 생태계 인력 풀 — 시스템 프로그래밍 분야 구인 시장에서 Rust 비중이 2024~2026년 사이 4배 이상 성장했고, Bun 역시 외부 기여자 풀이 확장되면서 신규 기여 속도가 빨라졌습니다. 셋째, 성능 프로파일링 정밀도 — Bun은 Node.js 대비 3~4배 빠른 벤치마크를 내세우지만, Zig 코드의 일부 핫패스에서 SIMD/AVX 활용도가 제한적이었고, Rust는 zero-copy, unsafe 블록의 명시적 격리, 그리고 cargo-flamegraph 같은 정밀한 프로파일링 도구를 활용해 같은 성능을 더 작은 코드면적으로 달성할 수 있게 해 줍니다.

2. 실제로 어디가 Rust로 바뀌고 있나

Bun의 코드베이스는 2026년 7월 기준으로 약 65%가 TypeScript/JavaScript, 25%가 Rust, 나머지 10%가 Zig/C/C++로 구성됩니다. 주요 변환 영역은 다음과 같습니다.

2-1. HTTP 서버 코어 (HTTP/1.1 + HTTP/2)

기존 Zig 기반 HTTP 서버는 uws 위에 얹힌 구조였고, 요청 파싱과 keep-alive 처리에 약간의 race condition이 보고되었습니다. Rust 전환은 hyper 1.x의 저수준 API를 직접 호출하는 방식으로 진행됐고, Tokio 런타임 대신 자체 그린 스레드 스케줄러를 얹어 Bun 특유의 단일 스레드 동시성 모델을 보존했습니다. 결과적으로 p99 레이턴시가 약 12~18% 감소했고, 특히 동시 연결 수가 1만 개를 넘는 워크로드에서 두드러졌습니다.

2-2. 번들러 그래프와 모듈 해석기

Bun의 번들러는 ESM/CJS interop, 워크스페이스 모노레포 해석, 그리고 조건부 export 처리에서 Node.js와 Webpack/esbuild 사이의 미묘한 호환성 차이를 흡수해야 합니다. 이 영역은 TypeScript로 유지되지만, 모듈 캐시 키 계산과 파일시스템 워치의 hot path는 Rust로 옮겨졌습니다.

// 모듈 캐시 키 생성 — Rust 포팅 버전 (의사코드)
use std::hash::{Hash, Hasher};
use xxhash_rust::xxh64;

pub struct ModuleKey {
    pub abs_path: String,
    pub mtime_ns: u128,
    pub export_conditions: Vec,
}

impl Hash for ModuleKey {
    fn hash(&self, state: &mut H) {
        self.abs_path.hash(state);
        self.mtime_ns.hash(state);
        for cond in &self.export_conditions {
            cond.hash(state);
        }
    }
}

pub fn cache_key(key: &ModuleKey) -> u64 {
    let mut h = xxh64::XxHash64::new(0);
    key.hash(&mut h);
    h.finish()
}

이 포팅의 효과는 캐시 히트율이 92% → 97%로 오르고, 워치 이벤트 debounce가 50ms → 12ms로 짧아진 부분에서 체감됩니다. dev 서버 콜드 스타트 기준 약 20% 빨라졌습니다.

2-3. SQLite 클라이언트 (Bun:sqlite)

Bun:sqlite는 프로젝트의 가장 빠른 영역 중 하나로, ffi 기반 바인딩이 잘 정리되어 있었습니다. Rust 전환에서는 rusqlite를 직접 호출하지 않고, libsql 포크 위에 자체 prepared statement 캐시를 얹어 약 5~8% 추가 성능을 얻었습니다. 트랜잭션 격리 모델은 동일하게 SERIALIZABLE을 기본으로 유지해 호환성을 보존했습니다.

3. 성능 임팩트와 트레이드오프

Bun 팀이 2026년 6월에 공개한 벤치마크(Apple M2 Max, 16코어 기준)에 따르면 HTTP 요청 처리량, 파일 I/O, 그리고 SHA-256 해싱 속도가 모두 개선되었습니다. 반대로, 단일 스레드 마이크로벤치마크(예: 피보나치, 정렬)에서는 일부 회귀가 보고됐는데, 이는 Rust가 --release 빌드에서도 LLVM이 인라인화하기 어려운 제네릭 경계를 만들기 때문이라고 분석했습니다.

또한 Rust 의존성 트리가 커지면서 cargo build 시간이 늘어났고, 첫 빌드는 Zig 시절 대비 약 2.5배 길어졌습니다. 다만 캐시된 incremental 빌드는 80% 정도 빨라졌기 때문에 CI에서 캐시 적중률이 중요한 환경이라면 큰 부담은 아닙니다.

4. 운영자가 알아둘 점

Bun을 프로덕션에서 쓰는 팀이라면 다음 세 가지를 점검할 만합니다.

1. 버전 정책 — Bun 1.2부터 Rust 코어가 기본 활성화되었고, 1.1 라인은 보안 패치만 받습니다. 1.0은 EOL에 가까우므로 1.2 이상으로의 업그레이드를 권장합니다.
2. 네이티브 모듈 호환성 — Bun:ffi로 작성된 사용자 정의 모듈이 Zig ABI에 의존했다면 Rust 포팅 이후 시그니처가 미세하게 바뀐 경우가 있습니다. 1.2 changelog의 breaking change 섹션을 반드시 확인하세요.
3. 메모리 프로파일링 — heaptrack 또는 bytehound로 RSS 사용량을 추적하면 Rust 전환이 끝난 영역에서 메모리 단편화가 줄었는지 검증할 수 있습니다.

5. 전망

Bun의 Rust 전환은 단순한 언어 교체가 아니라 런타임 시장 전체의 표준화 신호로 읽힙니다. Deno도 2025년경부터 deno_core를 Rust로 점진 전환했고, Node.js의 llhttp는 이미 Rust 바인딩을 옵션으로 제공합니다. JS 런타임의 저수준 코어가 Rust로 수렴하는 흐름은 2027년까지 지속될 가능성이 높고, 이 방향은 단순히 성능이 아니라 보안과 공급망 안정성 측면에서도 긍정적입니다.

요약

Bun의 Rust 재작성은 HTTP 서버, 모듈 캐시, SQLite 클라이언트 등 핫패스를 중심으로 진행되며, 메모리 안전성과 동시성 모델의 명확화를 통해 p99 레이턴시와 캐시 히트율을 동시에 끌어올렸습니다. 빌드 시간과 단일 스레드 회귀라는 트레이드오프는 분명히 존재하지만, Bun 1.2 이상으로 업그레이드하고 네이티브 모듈 시그니처와 메모리 프로파일을 점검하면 마이그레이션 비용 대비 운영 안정성 향상이 충분히 큰 변화입니다.

---

출처: https://news.hada.io/topic?id=31897 · 카테고리: AI/ML · 긱뉴스 토픽 #31897

---

📰 원본 출처 · https://news.hada.io/topic?id=31897 (#N=31897)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.