Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

TL;DR Highlight

Anthropic이 인수한 Bun 런타임이 Zig 코드베이스를 AI로 Rust에 재작성했는데, 가장 기본적인 메모리 안전성 검사(miri)조차 통과하지 못하는 UB(Undefined Behavior)가 발견됐다는 이슈가 제기됐다.

Who Should Read

Bun이나 Deno 같은 JavaScript 런타임을 프로덕션에서 사용 중이거나, AI를 활용한 대규모 코드 마이그레이션을 고려하는 시스템 개발자 및 테크 리드.

Core Mechanics

Bun은 원래 Zig로 작성된 JavaScript 런타임인데, Anthropic에 인수된 이후 코드베이스 전체를 Rust로 재작성하는 작업을 AI 에이전트를 활용해 단 몇 주 만에 진행했다.
제보된 문제는 safe Rust(unsafe 블록 없이도 안전해야 하는 코드)에서 UB(Undefined Behavior, 정의되지 않은 동작)가 발생하는 것이다. 구체적으로 PathString::slice()가 이미 drop(해제)된 메모리를 가리키는 댕글링 레퍼런스(dangling reference)를 반환해서 miri(Rust 코드의 메모리 안전성을 실행 중에 검사하는 인터프리터)가 오류를 잡아낸다.
실제 오류 메시지는 'constructing invalid value of type &[u8]: encountered a dangling reference (0x20933[noalloc] has no provenance)'로, 이미 해제된 Box를 가리키는 포인터를 slice로 재구성하는 코드가 문제다.
이슈 제보자는 AI가 Rust를 잘 못 쓰는 만큼 '바이브 코딩(vibe coding, 직관과 AI에만 의존해 검증 없이 코드를 생성하는 방식)'을 하지 말고 실제 Rust 전문가를 채용하라고 촉구했다.
기존 Zig 코드는 그대로 안정 버전으로 유지 중이고, Rust 재작성 버전은 아직 릴리즈되지 않은 상태라, 실제 프로덕션 사용자에게 직접적인 위험이 당장 생긴 건 아니다.
miri 같은 검사 도구를 CI/테스트에 처음부터 붙이지 않은 것도 문제로 지적됐다. LLM이 코드를 생성할 때 좋은 테스트와 검증 도구가 있으면 더 나은 결과를 낼 수 있는데, 그 기반이 없었다는 것이다.
이슈 자체가 GitHub에 대량으로 올라오면서 소란이 커졌고, 일부 댓글은 아직 개발 중간 단계에 있는 코드를 공개적으로 비판하는 것이 적절한지에 대한 논쟁으로 번졌다.

Evidence

Zig에서 Rust로 변환하려면 `zig translate-c`와 `c2rust`를 파이프라인으로 연결해 결정론적(deterministic) 변환을 하는 방법도 있었을 텐데, AI 에이전트를 굳이 쓴 이유를 이해하기 어렵다는 의견이 있었다. AI로 변환한 결과는 입력(Zig)보다 신뢰도가 낮은데, 아무도 실제로 코드를 검토하지 않은 상태라는 점에서 더 위험하다는 주장이다.
이슈 자체가 오해를 일으킨다는 반론도 있었다. 진짜 문제는 'miri가 잡는 UB가 존재한다'는 것 자체가 아니라, unsafe 코드를 safe API로 잘못 노출해서 외부에서 UB를 유발할 수 있다는 점이고, 이는 초기 포팅 단계에서 충분히 발생할 수 있는 일이라는 것이다. 다만 실제 릴리즈 전에 고쳐야 한다는 것에는 동의하는 분위기였다.
Anthropic이 Bun을 인수한 이후의 방향성에 대한 신뢰 문제도 제기됐다. 원래 Zig와 Bun을 선택했던 이유가 개발자의 기술적 판단력과 취향을 믿었기 때문인데, 이런 식의 AI 에이전트 전환 결정은 그 신뢰를 깬다는 의견이 나왔다.
TypeScript 컴파일러와 비슷한 야심의 사이드 프로젝트(tsz.dev)를 만들고 있다는 개발자는, 몇 주 만에 완전히 동작한다는 주장 자체가 놀라웠다고 했다. TypeScript 자체 테스트를 통과한 후에도 버그가 계속 나오는 경험을 하고 있기 때문에, 이 속도로 코드를 생성할 수 있는 지금이야말로 검증(verification)이 100배 더 중요해졌다고 강조했다.
동일한 문제가 원래 Zig 코드에도 존재했는지 궁금하다는 의견도 있었다. 만약 Zig에도 같은 버그가 있었다면, Rust 생태계의 miri 같은 도구로 문제를 더 쉽게 발견할 수 있다는 점에서 오히려 Rust 전환의 장점 중 하나로 볼 수도 있다는 시각이다.

How to Apply

AI 에이전트로 unsafe 언어(C/Zig/C++)를 Rust로 대규모 포팅하는 프로젝트를 진행 중이라면, 포팅 시작 시점부터 `cargo miri test`를 CI에 의무적으로 추가하라. LLM이 생성한 unsafe 블록이나 raw pointer 조작 코드는 사람이 직접 miri 없이 검토하기 매우 어렵기 때문에, 도구를 먼저 붙이면 오류를 자동으로 조기에 잡을 수 있다.
AI로 생성한 Rust 코드에서 unsafe 코드를 safe API로 감싸는 패턴을 쓴다면, 반드시 해당 API에 대한 소유권(ownership) 경계 테스트를 작성하라. 위 사례처럼 Box가 drop된 이후에도 참조를 유지하는 시나리오를 테스트에 명시적으로 포함시켜야 miri가 댕글링 레퍼런스를 잡아낸다.
레거시 코드를 AI로 다른 언어로 마이그레이션할 때, 결정론적 변환 도구(예: `zig translate-c` → `c2rust` 파이프라인)를 먼저 검토하라. AI 에이전트 번역은 유연하지만 검증이 어렵고, 기계적 변환은 입력 코드와 동일한 수준의 보장을 가지면서 재현 가능하다는 장점이 있다.

Code Example

snippet

// 문제가 된 코드 패턴 (miri가 UB로 잡아내는 사례)
fn main() {
    let test = Box::new(*b"Hello World");
    let init = PathString::init(&*test);
    drop(test); // test가 해제됨
    println!("{:?}", init.slice()); // ← 이미 해제된 메모리를 참조: UB!
}

// miri 실행 방법
// cargo +nightly miri test

// miri 오류 메시지 예시:
// error: Undefined Behavior: constructing invalid value of type &[u8]:
// encountered a dangling reference (0x20933[noalloc] has no provenance)
// --> src/main.rs:97:18

Terminology

miriRust 코드를 실제로 실행하면서 메모리 안전성 위반을 잡아내는 인터프리터 도구. C의 Valgrind와 비슷하다고 보면 된다. `cargo miri test`로 실행한다.

UB (Undefined Behavior)언어 스펙상 어떤 결과가 나와도 되는 동작. 크래시가 날 수도 있고, 조용히 잘못된 데이터를 쓸 수도 있어서 디버깅이 매우 어렵다. Rust는 원칙적으로 이걸 컴파일 타임에 막는 언어인데, unsafe 코드를 잘못 쓰면 뚫린다.

dangling reference이미 해제(free)된 메모리를 가리키는 포인터나 참조. 해당 주소에 뭐가 있을지 알 수 없어서 읽으면 UB가 된다.

safe Rustunsafe 블록 없이 작성된 Rust 코드. 컴파일러가 메모리 안전성을 보장해야 하는 영역인데, unsafe 코드를 잘못 wrapping하면 safe 코드처럼 보이면서도 UB를 유발할 수 있다.

vibe coding구체적인 검증 없이 AI나 직관에만 의존해서 빠르게 코드를 생성하는 개발 방식. 빠르지만 결과물의 정확성을 보장하기 어렵다.

provenanceRust/C에서 포인터가 어떤 메모리 할당으로부터 유래했는지를 추적하는 개념. miri는 이 출처가 없는 포인터 접근을 UB로 판단한다.