Bun을 Rust로 다시 작성하기

 (bun.com)
3P by GN⁺ | ★ favorite | 댓글 2개
  • Zig로 시작한 Bun은 월 2,200만 회 이상 다운로드되는 런타임으로 커졌지만, GC 기반 JavaScript 엔진과 수동 메모리 관리가 맞물리며 반복된 안정성 문제를 Rust 전환의 계기로 삼음
  • 535,496줄의 Zig 코드를 사람이 1년간 옮기는 대신, Claude Code의 동적 워크플로우 약 50개와 최대 64개 Claude 인스턴스를 11일 동안 병렬 실행함
  • 포팅은 PORTING.md, LIFETIMES.tsv, 구현자 1명과 적대적 리뷰어 2명 이상, 기존 TypeScript 테스트 스위트로 검증됐고 6개 플랫폼 CI에서 100% 통과함
  • Rust 전환 후 Bun v1.4.0은 v1.3.14에서 재현되는 128개 버그를 고치고, instrumentable 메모리 누수를 모두 수정했으며, Linux·Windows 바이너리 크기를 약 20% 줄임
  • Bun v1.3.14는 마지막 Zig 버전이고 v1.4.0은 첫 Rust 버전으로 canary에 제공되며, 팀은 borrow checker, Miri, LeakSanitizer, 24/7 커버리지 기반 퍼징을 안정성 개선 도구로 사용함

Zig로 시작한 Bun과 안정성 문제

  • Bun은 esbuild의 JavaScript·TypeScript 트랜스파일러를 Go에서 Zig로 라인 단위 포팅한 프로젝트로 출발함
  • 첫 Zig 코드는 2021년 4월 16일 작성됐고, Zig의 낮은 수준 제어와 성능 지향 설계가 Bun 초기 구현을 가능하게 함
  • 초기 Bun은 한 명이 1년 동안 Zig로 작성했으며, 범위가 매우 넓었음
    • JavaScript, TypeScript, CSS 트랜스파일러·미니파이어·번들러
    • npm 호환 패키지 매니저
    • Jest 유사 테스트 러너
    • Node.js·TypeScript 호환 모듈 해석
    • HTTP/1.1·WebSocket 클라이언트
    • fs, net, tls 등 Node.js API 구현
  • 현재 Bun CLI는 월 2,200만 회 이상 다운로드되고, Claude Code와 OpenCode가 런타임으로 사용하며, Vercel, Railway, DigitalOcean 등이 1st-party 지원을 제공함

반복된 메모리 안정성 버그

  • Bun v1.3.14에서 수정된 버그 샘플에는 use-after-free, double-free, 메모리 누수, out-of-bounds 접근, race condition이 포함됨
    • node:zlib의 async .write() 중 .reset() 호출로 인한 heap-use-after-free
    • node:http2의 재진입 JS 콜백이 hashmap rehash를 유발해 내부 스트림 포인터가 무효화되는 use-after-free
    • UDPSocket.send()와 sendMany()에서 valueOf() 또는 toString() 콜백이 ArrayBuffer를 detach하는 문제
    • Buffer#copy, Buffer#fill에서 인자 coercion 중 ArrayBuffer detach 또는 resize로 인한 crash와 out-of-bounds read
    • crypto.scrypt, tlsSocket.setSession(), fs.watch() 관련 메모리 누수
    • CSS parser의 vendor prefix와 multi-layer background 처리 중 double-free
    • BroadcastChannel 또는 MessagePort의 동시 접근 중 MessageEvent race condition crash
  • 기존에도 안정성 강화를 위해 여러 장치를 사용함
    • Zig compiler에 Address Sanitizer 지원을 패치하고 모든 커밋에서 ASAN 테스트 스위트를 실행함
    • Windows에는 Zig safety-checked ReleaseSafe 빌드를 배포함
    • Fuzzilli로 Bun 런타임 API를 24/7 퍼징함
    • end-to-end 메모리 누수 테스트를 다수 운영함
  • Zig 자체가 문제라는 입장은 아니며, GC 값과 수동 관리 메모리를 함께 다루는 요구가 안정성 문제의 주요 원천이었음

Rust를 선택한 이유

  • JavaScript는 GC 언어이고 JavaScriptCore와 V8 같은 엔진은 예외 처리와 GC에 엄격한 규칙을 가짐
  • Zig는 C처럼 메모리를 자동 관리하지 않으며, 생성자·소멸자가 없고 cleanup은 대부분 각 call site에서 defer로 명시해야 함
  • Bun에서는 GC 값과 수동 관리 값의 lifetime을 올바르게 처리하는 일이 안정성 문제의 큰 원천이었음
    • 할당된 바이트가 어디서 해제되는지 확인해야 함
    • 한 번만 해제되는지 보장해야 함
    • JavaScript 예외 처리를 올바르게 확인해야 함
    • GC 포인터가 conservative stack scanner에 보이는지 확인해야 함
  • Zig의 cleanup 방식은 명시적인 defer, errdefer이고, C++은 destructor와 move, Rust는 Drop을 사용함
  • Bun의 기존 Zig 코드에서는 arena lifetime, reference counting, 세심한 리뷰가 혼합돼 있었음
  • 스타일 가이드와 코드 리뷰로 ownership 규칙을 강제할 수도 있지만, Rust의 안전한 코드에서는 use-after-free, double-free, error path의 누락된 free가 컴파일러 오류가 됨
  • Bun 코드의 약 20%는 C++이고 여러 C/C++ 라이브러리를 내장함
    • JavaScriptCore
    • uWebSockets와 usockets
    • lshpack과 lsquic
    • BoringSSL
    • SQLite
  • C++도 선택지가 될 수 있었지만, 여전히 스타일 가이드와 코드 리뷰에 의존하고 ASAN이 있어도 메모리 손상과 누수가 발생할 수 있음

재작성 전략: 한 번에, 기계적으로

  • 기존 Bun Zig 코드는 주석 제외 535,496줄이었고, 전통적인 재작성은 작은 엔지니어 팀이 1년가량 걸릴 작업으로 평가됨
  • 버그 수정, 보안 수정, 기능 개발을 1년 동안 멈출 수 없었기 때문에 사용자 동작 변경을 최소화하는 기계적 포팅이 가장 낮은 위험 접근법으로 선택됨
  • Bun의 테스트 스위트는 TypeScript로 작성돼 런타임 구현 언어에 의존하지 않았음
  • 증분 재작성은 임시 코드를 만들고 나중에 삭제되길 기대해야 하므로 단기·중기적으로 고통스럽다고 판단해 전체를 한 번에 옮김
  • Rust 코드는 Zig 코드를 transpile한 것처럼 보이도록 작성하고, Bun v1.4 이후 점진적으로 unsafe를 줄이며 idiomatic Rust로 리팩터링하는 방향을 택함

Claude Code 동적 워크플로우

  • Rust 재작성에는 Claude Code에서 약 50개 동적 워크플로우가 11일 동안 계속 실행됨
  • 워크플로우는 포팅 가이드 작성부터 파일 변환, 컴파일 오류 수정, subcommand 복구, 전체 테스트 통과, 대규모 cleanup까지 이어짐
    • Zig 패턴과 타입을 Rust 패턴과 타입으로 매핑하는 포팅 가이드 생성
    • 모든 .zig 파일을 PORTING.md와 LIFETIMES.tsv에 맞춰 .rs 파일로 기계적 포팅
    • crate별 컴파일러 오류 수정
    • bun test, bun build 같은 subcommand 동작 복구
    • 전체 테스트 스위트 통과
    • 대규모 리팩터링과 cleanup
  • 대부분의 기간 동안 사람이 워크플로우 출력을 읽고 문제와 버그를 확인하며, Claude가 루프를 수정하도록 프롬프트를 조정함
  • 사전 작업으로 Claude와 약 3시간 동안 Zig 코드베이스의 패턴을 Rust로 매핑하는 방식을 논의했고, 이 결과가 PORTING.md로 직렬화됨
  • 수동 메모리 관리 코드에 Rust lifetime을 추가하기 위해 모든 struct field의 lifetime을 분석하는 워크플로우를 실행함
    • 복잡한 lifetime을 가진 field를 찾음
    • lifetime을 제안함
    • 적대적 리뷰 agent 2개가 검토함
    • 피드백을 반영해 LIFETIMES.tsv로 저장함

적대적 리뷰 방식

  • 각 구현 Claude와 별도 context window에 적대적 리뷰어 Claude를 두고, 리뷰어는 diff만 받은 상태에서 코드가 틀렸다고 가정하고 버그를 찾도록 지시받음
  • 기본 구조는 구현자 1명, 적대적 리뷰어 2명 이상, fixer 1명으로 구성됨
  • 리뷰어가 실제로 잡은 버그는 모두 컴파일은 통과했지만 동작상 문제가 있었음
    • uv_close가 비동기인데 Box<uv::Pipe>가 match arm 끝에서 drop되어 libuv가 freed memory를 들고 있게 되는 use-after-free와 double-free
    • 음수 비정수 file time에서 trunc()를 쓰면 음수 nsec가 생기는 timespec 오류
    • unwrap_or가 인자를 eager 평가해 color-mix() percentage 생략 케이스에서 panic하는 오류
  • 사람 리뷰와 마찬가지로 작성자와 리뷰어 context를 분리해, 구현자가 merge를 원해 생길 수 있는 편향을 줄임

대규모 포팅 실행과 병렬화

  • 전체 1,448개 .zig 파일을 옮기기 전에 먼저 3개 파일로 절차를 검증함
    • 구현자 1명이 .rs 파일을 작성함
    • 리뷰어 2명이 .zig와 동작이 일치하고 PORTING.md, LIFETIMES.tsv를 따르는지 확인함
    • fixer 1명이 제안을 적용함
  • 전체 파일 포팅 초기에 여러 Claude가 git stash, git stash pop, git reset HEAD --hard를 실행하며 서로 충돌함
  • 이후 워크플로우에 git stash, git reset, 특정 파일 커밋이 아닌 git 명령, cargo 같은 느린 명령을 금지하는 규칙을 추가함
  • 최종적으로 4개 workflow shard와 4개 worktree를 사용하고, 각 shard에서 16개의 Claude가 파일을 커밋·푸시함
  • 병렬화와 사전 준비 덕분에 peak에서 Claude는 분당 약 1,300줄 코드를 작성함
  • 포트 브랜치의 merge 제외 커밋은 6,502개, peak hour는 695 commits였고, 최종 landed diff는 +1,009,272줄임
  • EC2 인스턴스의 기본 IOPS를 늘리지 않아 느린 grep 하나로 디스크 읽기·쓰기가 몇 분간 멈추는 문제도 있었음

컴파일 오류와 crate 분리

  • 모든 코드를 작성한 뒤 Claude 워크플로우가 컴파일러 오류를 수정함
  • Zig 코드베이스는 사실상 하나의 compilation unit이었고, Rust 코드는 더 빠른 컴파일을 위해 약 100개 crate로 나누려 했음
  • 가장 까다로운 오류 범주는 순환 의존성이었음
    • Rust 재작성 직전의 crate 분리 PR만으로는 충분하지 않았음
    • 별도 워크플로우가 순환 의존성이 있는 코드를 어디에 둘지 분류하고 기록함
    • 또 다른 워크플로우가 해당 리팩터링을 수행함
  • 순환 의존성 해결 후 약 16,000개 컴파일러 오류가 드러남
  • 이 오류들은 crate별로 병렬 처리됨
    • 각 crate에서 cargo check를 실행함
    • 출력을 파일별로 묶어 저장함
    • 해당 crate의 컴파일 오류를 수정함
    • 적대적 리뷰어 2명이 변경을 검토함
    • fixer 1명이 수정사항을 적용함
  • Claude가 “모든 crate를 컴파일되게 하자”를 함수 stub 생성으로 해석하는 false start도 있었음
  • 긴 설명 주석으로 workaround를 정당화하려는 패턴이 생기자, “문단 길이 주석이 필요하면 코드는 틀렸고 코드를 고쳐야 한다”는 리뷰 규칙이 추가됨

테스트 통과까지의 과정

  • cargo check가 통과한 뒤에는 링크 오류, 시작 직후 panic, bun --version, bun test <file> 실행을 순서대로 해결함
  • CLI subcommand별 실패 stacktrace를 파일로 저장하고, 구현자·리뷰어·fixer 루프로 고치는 워크플로우를 사용함
  • 테스트 파일 워크플로우는 약 100개 랜덤 테스트 파일을 4개 worktree에 shard하고, 실패별 stacktrace와 오류를 저장해 수정함
  • 테스트 스위트에는 debug build에서 timeout될 수 있는 메모리 누수 테스트와 통합 테스트가 있었음
    • next dev를 실행하고 hot module reloading이 100회 변경을 감지하는 테스트
    • TCP socket 최대 수를 소진하는 stress test
    • 기가바이트 단위 디스크 읽기·쓰기 테스트
    • 약 1만 개 프로세스를 spawn하는 테스트
  • 격리를 위해 systemd-run과 cgroups로 메모리·CPU 사용량을 제한하고 pid namespace를 분리함
  • 그래도 머신은 디스크 공간 부족으로 여러 번 crash함
  • 첫 CI 실행 이틀 뒤 실패 테스트 파일은 972개에서 23개로 줄었고, 그로부터 하루 반 뒤 Linux가 완전히 green이 됨
  • 최종적으로 6개 플랫폼의 CI 전체 테스트가 통과함
    • macOS x64
    • macOS arm64
    • Linux x64
    • Linux arm64
    • Windows x64
    • Windows arm64
  • 100% 테스트 통과 후 사람이 테스트가 실제 실행되고 skip되지 않았는지 수동 확인하고 merge함
  • main에 merge된 시점은 versioned release가 아니며, release할 만큼의 확신은 아직 아니었고 rewrite에 전념할 만큼의 확신을 얻은 상태였음

테스트 규모와 비용

  • 11일 동안 May 3부터 May 14 merge까지 6,778 commits가 생성됨
  • 테스트는 삭제되거나 skip되지 않음
  • 플랫폼별 테스트 규모는 다음과 같음
    • Debian 13 x64: expect() 1,386,826회, 테스트 60,624개, 파일 4,174개
    • macOS 14 arm64: expect() 1,259,953회, 테스트 58,850개, 파일 4,175개
    • Windows 2019 x64: expect() 1,007,544회, 테스트 57,337개, 파일 4,173개
  • pre-merge 작업에는 uncached input token 59억, output token 6억 9천만, cached input token read 720억이 사용됨
  • API 가격 기준 비용은 약 16만 5천 달러임
  • 사람이 직접 했다면 코드베이스 전체 context를 가진 엔지니어 3명이 약 1년 걸렸을 것으로 평가됨
  • 사용 모델은 pre-release Claude Fable 5이고, Bun은 2025년 12월 Anthropic에 인수됐다는 disclosure가 포함됨

보안 리뷰, 퍼징, unsafe 현황

  • Rust 포트 merge 이후 Claude Code Security로 11라운드 보안 리뷰를 완료하고 findings를 처리함
  • Bun의 모든 parser에 대해 24/7 커버리지 기반 퍼징이 추가됨
    • JavaScript
    • TypeScript
    • JSX
    • CSS
    • JSON5
    • JSONC
    • TOML
    • YAML
    • Markdown
    • INI
    • Bun Shell scripts
    • semver ranges
    • .patch files
    • CSS colors
  • fuzzer는 찾은 버그를 Claude에 보내 재현과 수정을 포함한 PR을 제출하게 하고, 사람은 PR을 리뷰함
  • 지금까지 parser 실행은 1,000억 회였고 약 15개 PR로 이어짐
  • 작성 시점 기준 Rust 코드의 약 4%가 unsafe block 안에 있음
    • 약 13,000개의 unsafe keyword
    • 약 27,000줄 / 전체 약 780,000줄
    • unsafe block의 78%는 한 줄짜리이며, C++에서 온 포인터 또는 C 라이브러리 호출임
  • JavaScriptCore 같은 C/C++ 라이브러리를 계속 사용하기 때문에 순수 Rust 프로젝트보다 unsafe는 항상 더 많을 것이라고 밝힘

Rust 전환 후 발견된 regression

  • Rust rewrite는 대규모 변경이어서 19개의 알려진 regression을 만들었고, 모두 수정됨
  • 대부분은 두 언어에서 문법은 비슷하지만 의미가 다른 코드에서 나옴

  • debug_assert! 안의 side effect

    • Zig의 assert는 함수라 인자가 모든 build에서 실행됨
    • Rust의 debug_assert!는 macro라 release build에서는 전체 표현식이 제거됨
    • insert_stale 호출이 release build에서 사라져 React를 사용하는 HTML route 프로젝트의 특정 HMR 케이스가 깨짐
    • 관련 이슈: #30678

  • 홀수 길이 slice

    • Bun의 Zig helper reinterpretSlice(u16, bytes)는 @divTrunc를 사용해 trailing odd byte를 무시했음
    • Rust의 bytemuck::cast_slice는 홀수 길이에서 panic함
    • UTF-16 BOM 뒤에 홀수 바이트가 오는 Blob.text()가 문자열을 반환하지 않고 process를 panic시키는 regression이 있었음
    • 수정은 &buf[..buf.len() & !1]로 odd byte를 다시 무시하는 방식임
    • 관련 이슈: #31188

  • Bounds checks

    • macOS와 Linux의 Zig 코드는 ReleaseFast로 컴파일돼 bounds check가 제거됐고, Rust release build는 bounds check를 유지함
    • Bun module resolver의 overflow block 크기가 placeholder 64로 남아 ceiling이 840만 interned filenames에서 270,272로 낮아짐
    • port된 ptrs[4095] off-by-one이 실제 프로젝트에서 도달 가능해졌고, Rust는 out-of-bounds write 대신 panic함
    • 관련 이슈: #31503

  • comptime format strings

    • Zig의 Output.pretty는 fmt가 comptime이라 <r>, <d> color marker가 인자 치환 전에 ANSI escape로 변환됨
    • Rust 함수는 comptime parameter가 없어 완성된 string에서 marker를 처리했고, 인자까지 잘못 rewrite함
    • bun update -i에서 OSC 8 hyperlink termination과 trailing <r> marker가 충돌해 r이 텍스트로 출력됨
    • Rust에서는 macro bun_core::pretty!("<r>{}<r>", hyperlink)가 필요했음
    • 관련 이슈: #30693

수정된 버그와 메모리 누수

  • Bun v1.4.0은 v1.3.14에서 재현되는 128개 버그를 수정함
  • 범위는 메모리 누수, crash, 잘못 색칠된 help text까지 포함됨
  • Rust의 Drop은 값이 scope를 벗어날 때 자동으로 drop 함수를 호출함
  • Zig에서는 각 call site에 defer를 추가해야 해서 cleanup 누락 또는 중복 cleanup이 발생하기 쉬웠음
  • Rust의 Drop은 hidden control flow를 받아들이는 대신 흔한 footgun을 줄이는 선택임
  • Drop은 error handling code의 file path 관련 메모리 누수 여러 개를 수정함
  • Bun의 LeakSanitizer 통합이 개선돼 모든 native code memory allocations를 추적함
  • instrumentable memory leak는 모두 수정됨

  • Bun.build() 누수 개선

    • 기존 Bun v1.3.14에서는 in-process Bun.build() 호출마다 parsed source text와 AST symbol table이 build 수명보다 오래 살아남아 수 MB씩 누수됨
    • 같은 60-module 프로젝트를 한 process에서 2,000번 bundle하는 테스트에서 v1.3.14는 build마다 약 3MB를 계속 누수함
    • Bun v1.4.0에서는 메모리 사용량이 수평화됨
    • | Builds | Bun v1.3.14 | Bun v1.4.0 |
    • | --- | ---: | ---: |
    • | 500 | 1,914 MB | 526 MB |
    • | 1,000 | 3,506 MB | 586 MB |
    • | 1,500 | 5,097 MB | 608 MB |
    • | 2,000 | 6,745 MB | 609 MB |

바이너리 크기, 스택 사용량, 성능

  • Rust rewrite 초기 변경만으로 바이너리 크기가 줄어듦
    • Windows: 3.8 MB 감소
    • macOS: 5.5 MB 감소
    • Linux: 6.8 MB 감소
  • 주요 원인은 Zig 코드에서 comptime을 너무 많이 사용한 점이었음
  • 이후 동일 코드 접기(Identical Code Folding), ICU의 unused data 제거, libicu 일부를 zstd dictionary로 지연 압축 해제하는 방식도 적용됨
  • Rust rewrite, ICU 변경, identical code folding을 합치면 Linux와 Windows에서 Bun 바이너리 크기가 약 20% 감소함
Version Platform Size
Bun v1.4.0 canary Windows 76 MB
Bun v1.3.14 Windows 94 MB
Bun v1.4.0 canary Linux 70 MB
Bun v1.3.14 Linux 88 MB
  • TOML parser와 Bun의 recursive-descent parser들은 stack space를 덜 사용하게 됨
  • Rust의 LLVM IR codegen이 stack variable에 llvm.lifetime.start와 llvm.lifetime.end intrinsic을 내보내 LLVM이 stack slot을 재사용할 수 있음
  • 이전에는 Zig의 open issue를 우회하기 위해 특히 큰 함수를 여러 작은 함수로 수동 리팩터링했음
  • Rust는 C/C++와 Rust 사이의 cross-language link-time optimization을 지원해 언어 간 inlining이 가능함

  • Linux x64 벤치마크

    • Bun v1.3.14와 Bun v1.4.0을 Linux x64 EC2 Xeon Platinum 8488C에서 비교함
    • HTTP throughput은 oha, app workload는 hyperfine으로 측정함
    • | server | Bun v1.3.14 | Bun v1.4.0 | Δ |
    • | --- | ---: | ---: | ---: |
    • | Bun.serve | 169.6k req/s | 177.7k req/s | +4.8% |
    • | node:http | 103.8k req/s | 108.5k req/s | +4.5% |
    • | Elysia | 158.9k req/s | 163.3k req/s | +2.8% |
    • | express | 64.5k req/s | 66.6k req/s | +3.2% |
    • | fastify | 91.5k req/s | 95.9k req/s | +4.8% |
    • | workload | Bun v1.3.14 | Bun v1.4.0 | Δ |
    • | --- | ---: | ---: | ---: |
    • | next build | 13.62 s | 13.03 s | +4.5% |
    • | vite build | 1.69 s | 1.65 s | +2.2% |
    • | tsc -b --force | 0.94 s | 0.89 s | +4.7% |

실제 사용 사례와 릴리스 상태

  • Prisma는 Bun의 Rust rewrite 위에서 Prisma Compute public beta를 출시함
  • Prisma 측은 VM pause/resume 이후 복구되지 않는 connection pool과 memory leak failure mode를 Rust rewrite에서 테스트했고, 해당 failure mode를 잘 처리했다고 밝힘
  • Claude Code v2.1.181, 6월 17일 릴리스 이후 버전은 Rust 포트 Bun을 사용함
  • Claude Code의 Linux startup은 10% 빨라졌고, 그 외에는 대부분 사용자가 거의 알아차리지 못했다고 함
  • Bun v1.3.14는 Zig로 작성된 마지막 Bun 버전임
  • Bun v1.4.0은 Rust로 작성된 첫 Bun 버전이며 canary로 제공됨

팀이 얻은 도구와 남은 작업

  • 새 Rust 코드베이스는 기존 Zig 코드베이스와 매우 비슷한 형태를 유지함
  • 원래 Zig 코드를 이해하는 사람은 기계적으로 번역된 Rust 코드도 이해할 수 있도록 작성됨
  • Rust rewrite PR 리뷰는 적대적 리뷰 agent가 Zig와 Rust 간 불일치, 포팅 가이드, lifetime guide 준수 여부를 제대로 잡는지 확인하고, 사람이 많은 코드를 side-by-side로 읽는 방식으로 진행됨
  • Bun v1.4는 Bun을 더 빠르고 작게 만들고 메모리 사용을 줄이며, 안정성 개선을 위한 도구를 제공함
    • Rust borrow checker
    • Miri
    • LeakSanitizer
    • parser 대상 24/7 coverage-guided fuzzing
  • 아직 리팩터링할 부분은 남아 있으며, bun-unsafe-audit이 연결됨
  • 한 명의 엔지니어가 Fable과 Claude Code를 면밀히 모니터링해, 전체 테스트 스위트가 모든 플랫폼에서 통과하는 상태까지 11일 만에 도달함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글은 자동 재작성에 규율과 주의, 사람의 개입이 있었다는 점을 꽤 잘 보여줬고, AI로 할 수 있는 한 성실하게 진행됐다는 느낌을 줌
    별개로 2026년에 왜 메모리 안전하고 가능하면 경쟁 상태에도 안전한 언어를 쓰지 않으려는지 잘 모르겠음
    Rust는 성능까지 갖춘 형태로 그걸 제공하니, 성능 때문에 가비지 컬렉션이나 불변성이 싫어도 Rust라는 선택지가 있음
    최고 성능이 절대적으로 필요해서 C++로 내려가는 경우나 개인 취향은 이해하지만, 그 외에는 거의 당연한 선택처럼 보임

    • Rust 컴파일러는 매우 느림. 속도를 높이는 가장 좋은 방법은 코드베이스를 여러 크레이트로 나누는 것처럼 보이는데, 많은 사람에게는 좋은 개발 경험이 아님
      게다가 많은 문제에서는 가비지 컬렉터가 글에서 나온 결함까지 포함해 많은 결함을 추가 마찰 없이 없애지만, Rust는 소유권 관점으로 생각하라고 요구함
      예를 들면 많은 게임 개발자는 마찰이 낮은 언어로 반복 개발하길 선호함. 게임 코드는 프론트엔드 UI 코드처럼 까다롭고 빌드 과정도 독특할 수 있으며, 핫 리로딩으로 반복하는 경우가 많음
      느린 컴파일러를 쓰라는 건 그 반복 주기의 지연 시간을 더 받아들이라는 뜻이 됨. 물론 이런 이유가 모두에게 적용된다고 보지는 않음
    • “사람의 개입”이라니, 과거와 미래의 사람 개입을 모두 없애는 데 성공한 프로젝트라면 아이러니함
    • 사람들은 수십 년 써온 것에 애착을 가짐. 또한 세상의 대부분은 아직 C/C++ 로 작성돼 있어서, 임계 질량을 넘어서려면 맞서야 할 것이 많음
      Rust가 완벽하진 않지만 C++의 함정을 많이 해결함. 정의되지 않은 동작뿐 아니라 패키지 관리, 끔찍한 CMake 파일, 링커 오류 같은 것들도 포함됨
    • Rust에서 C++로 간다는 건 이상한 선택처럼 보임. 거의 같은 문제를 얻으면서 메모리 안전성만 잃기 때문임
      Zig, Odin, C3, 심지어 오래된 C라면 적어도 Rust와 C++ 모두가 제공하지 않는 장점이 있음. 그게 단지 컴파일 속도뿐이라도 말임
    • Rust 빌드에 필요한 디스크 용량을 볼 때마다 놀람. 기억이 맞다면 Zed를 컴파일하는 데 50GB가 넘게 듦

  • 중요한 건 이 방식이 소프트웨어 엔지니어링 팀을 고용하는 것보다 훨씬 싸다는 점임. 나를 20만 달러에 고용했더라도 1년 안에 이걸 못 했을 것 같음
    맥락도 없고 Zig나 Rust도 모르며, 한 달 안에 익힐 수는 있겠지만 매우 느렸을 것임
    특이점 같은 예측을 빼더라도, 지금의 AI만으로도 20만 달러짜리 소프트웨어 엔지니어 고용을 정당화하기 어려워질 것임
    Google이나 Anthropic처럼 소프트웨어 중심 회사의 최상위 영역에서는 AI가 아직 잘 못하는 새 소프트웨어를 만들 우수한 엔지니어를 계속 뽑겠지만, 소프트웨어가 단순 비용 센터인 Walmart나 Target 같은 회사, 이미 개발을 외주화하거나 저렴한 H1B 인력을 쓰던 회사에는 평균 엔지니어보다 훨씬 나은 AI 대안이 생김
    미국의 소프트웨어 개발자 약 160만 명은 크게 줄어들 가능성이 큼. FAANG의 L6급 최상위는 괜찮겠지만, 이름 없는 은행의 평균 개발자나 McDonalds 웹사이트를 만드는 사람은 다른 걸 배워야 하고, 아니면 곧 일자리를 잃을 수 있음
    1년 전에는 이렇게 예측하지 않았겠지만, 이제는 이런 변화가 일어날 것이 분명해 보임

    • “경제학에서 제본스 역설은 자원 사용 효율을 높이는 기술 개선이 그 자원의 총소비를 줄이기보다 늘릴 때 발생한다고 한다. 효율이 높아지면 응용당 필요한 자원량이 줄어 실질 비용이 낮아지고, 수요가 충분히 가격 탄력적이면 수요가 유발되어 총자원 소비가 순증하는 경우가 많다”
      https://en.wikipedia.org/wiki/Jevons_paradox
    • 그 일에 맞는 20만 달러 비용의 엔지니어가 더 큰 가치를 가져오지 못했을지는 충분히 논쟁적임
      또한 이 작업에서 실제로 가치가 생겼는지도 논쟁적임. unsafe Rust를 써보고 Zig도 써본 사람이라면 unsafe Rust가 비교하면 훨씬 더 위험하다는 걸 알 것임
    • 그렇게 비관적이진 않음. 할 수 있는 일은 무한히 많음. 이 전에는 프로젝트를 Rust로 다시 쓰자는 생각 자체를 누구도 진지하게 받아들이지 않았을 것임
      실제 일자리를 대체한 것도 아니고, 결국 이걸 해내려면 고액 엔지니어를 고용해야 했음
      사람을 덜 뽑기보다는 더 많은 코드 변경을 만들어낼 가능성이 크다고 봄
    • 오히려 반대로 봄. 이렇게 광범위한 변경은 시니어 엔지니어에게만 맡길 수 있음
      이제 이런 변경을 실제로 해낼 수 있는 시니어 엔지니어를 더 고용하고 싶어질 가능성이 큼
    • 그뿐만이 아님. 작성자를 포함해 대부분은 이게 실제로 가능하다고 생각하지 않았을 것임
      들인 시간과 비용이 많은 사람이 예상한 것보다 낮았을 뿐 아니라, 머지않아 이런 사람의 상호작용, 실수, 시간, 비용이 2배, 5배, 심지어 10배 이상 더 줄어들 수 있다고 예상할 수 있게 됨
      블로그 글 자체가 Claude와 LLM 전반의 홍보물 역할도 한다는 점도 감안해야 함

  • Bun 프로젝트 자체나 재작성의 성격을 논하지 않더라도, 순진한 방식으로 Zig에서 벗어난 재작성만으로 메모리 누수가 고쳐지고, 안정성이 좋아지고, 바이너리 크기가 20% 줄고, 성능이 5% 향상됐다면 Zig에는 좋게 보일 수 없음

    • 이걸 “Zig에서 벗어난 순진한 재작성”으로 분류하는 건 공정하지 않다고 봄. Jarred는 이 프로젝트에 5년 동안 깊이 들어가 있었고, 그동안 배운 모든 걸 활용했으며, 누구나 접근 가능한 가장 진보한 코딩 LLM에 토큰 16만 5천 달러를 썼음
      Zig 버전에 Fable을 16만 5천 달러어치 돌렸다면 5% 성능 향상도 얻었을 가능성이 큼
    • Zig가 이 블로그 글에 적대적으로 답하지 않길 바람. 다만 Zig의 미래에서는 더 나은 도구와 컴파일러 검사로 이런 문제 상당수를 고치거나 옮길 수 있을 것 같음
      꽤 오래전부터 Rust와 LLM은 잘 맞는 조합이라는 얘기가 많았음. 언어의 많은 마찰이 LLM 보조 프로그래밍으로 매끄러워짐
    • Zig를 쓰려는 사람들은 그런 것들이 프로젝트 차원의 문제이지 언어 차원의 문제가 아니라는 걸 이해한다고 봄
    • 맞지만, 재작성 자체가 이런 이점을 주는 경우가 많음. Zig로 다시 썼더라도 같은 개선 일부가 나왔을 가능성이 있음
    • 어려운 교훈을 통해 어려운 결정을 내리는 사람에게는 주의를 기울임. ORM을 쓰는 사람 대부분은 그냥 들어봤거나 SQL을 배우기 싫어서 고르지만, ORM을 제거하는 사람은 직접 공포를 겪어본 경우가 많다는 식임

  • Bun을 Rust로 다시 쓰는 데 AI를 쓴 것 자체는 신경 쓰지 않음. 1.4가 충분히 좋지 않더라도 시간이 지나며 나아질 가능성이 큼
    나를 Node로 다시 밀어낸 건 전환 과정이 너무 아마추어처럼 처리됐다는 점임
    Zig 버전에 CVE 등을 위한 LTS 지원이 없고, 블로그 글에 나온 3MB 메모리 누수 같은 큰 버그를 Zig 버전에 방치해 사실상 프로덕션 앱을 고치려면 Rust 버전으로 가게 만들었으며, 이런 중대한 결정에 Bun 커뮤니티와의 관여가 전혀 없었음
    어느 날은 “드라마 만들지 마라, 그냥 가지고 노는 중이다”였다가 며칠 뒤엔 “YOLO, main에 머지”가 됨
    Jarred는 사실상 여전히 자기 개인 프로젝트를 하는 혼자 해커처럼 운영함

    • Zig 버전의 CVE 등에 LTS 지원이 없다는 건, 릴리스마다 CVE가 잔뜩 나올 테고 엄청난 노력이 들 것임
      예컨대 블로그의 메모리 문제 예시처럼 말임. 보안 측면에서는 Zig 버전이 없었다고 생각하는 편이 나음. 자기 책임으로 써야 함
      Jarred가 개인 프로젝트처럼 운영한다는 점은, 그래도 그들에게 그럴 권리는 있음. 특히 회사가 소유한 경우라면 예상 가능한 일임
    • 유료 고객은 LTS를 받음. 유료 고객 중 Zig 브랜치 LTS를 요구하는 사람이 있나? 아니면 오픈소스 유지관리자에게 특별한 이유 없이 무료 노동을 기대하는 건가?
    • 1.4가 1.3에서 깨지는 변경을 만들지 않는다면, 왜 1.3에 머무는 사람들을 위한 LTS와 보장이 있어야 하나? 내가 보기엔 다른 릴리스처럼 알려진 회귀는 모두 고쳐졌음
    • 호환성이 깨졌을 때 LTS가 더 관련 있음. 아직 1.4를 릴리스하지도 않았고, 현장에서의 모든 지표로는 매우 잘 진행된 것처럼 보임. 수많은 사람이 한 달 동안 Claude Code로 쓰면서 회귀가 없었음
      부주의하다고 볼 만한 점은 보이지 않음
      오히려 그는 모든 코드 변경, 모든 줄마다 적대적 검토자 Claude 인스턴스 두 개를 붙였음. 우주왕복선 소프트웨어를 작성한 사람들 정도를 제외하면, 모든 줄에 대해 두 번의 독립 리뷰를 하는 인간 팀은 하나도 모름
      메모리 누수도 고쳤음. 어떤 언어로 쓰였는지가 왜 중요한가? 결국 사람들은 Bun으로 TypeScript 코드 등을 실행함
      Bun 사용자가 Bun이 Zig로 쓰였다는 걸 얼마나 신경 쓰나? 나는 전혀 아님. Bun을 2년 써왔고 Zig는 한 번 찾아본 정도임. 그냥 관련성이 없음
      더 안정적이 됐나? 그렇다. 더 작아졌나? 그렇다. 더 빨라졌나? 그렇다. 덜 안전해졌다는 증거가 있나? 없다. 코드는 두 달 동안 공개돼 있었고, 지금쯤 반대론자들이 결정적 증거를 찾았어야 하는데 못 찾았음
      이게 큰 성공이었다는 데 얼마나 더 많은 증거가 필요한가?
      이것이 새로운 현실임. 에이전트가 충분히 좋아져서 이런 프로젝트가 가능한 영역에 들어왔고, 그건 흥미로운 일임

  • “이 Rust 재작성은 코드베이스 전체 맥락을 가진 엔지니어 팀이 1년 걸릴 일이었다. Fable을 쓰고 Claude Code를 면밀히 모니터링한 엔지니어 1명으로, 시작부터 모든 플랫폼에서 테스트 스위트 100% 통과까지 11일이 걸렸다”
    기술적으로는 인상적이지만, Bun이 Anthropic의 일부가 아니었다면 토큰 비용 16만 5천 달러가 들었다는 사실을 슬쩍 넘김
    비교가 완전히 공정하진 않음. 추가 비용을 0달러로 잡으면 소규모 팀이 1년 걸려 포팅한다는 뜻임
    11일 동안 Claude에 16만 5천 달러를 쓰는 것과, 그 돈을 50명에게 나눠 Zig 코드를 줄 단위로 재작성하게 하는 걸 비교해보고 싶음. Claude가 더 빠르고 그래서 더 쌀 것 같긴 하지만, 차이가 아주 크지 않을 수도 있음

    • 대충 계산은 꽤 쉬움. 사람 한 명은 1년에 약 250일 일하고, Bay Area 급여를 가정하면 보수적으로도 완전 부담 비용이 연 30만 달러쯤 됨
      하루 1,200달러임
      50명 * 11일이면 66만 달러로, Claude 비용의 4배임
      게다가 그 50명이 막히거나 서로 발을 밟거나 조율 문제 없이 일한다는 가정임. 조율 복잡도만으로도 엄청남
      마음에 들진 않지만 여기서는 Claude가 쉽게 이김. 근소한 차이도 아님
    • 50명을 의미 있게 조율하는 데만 적어도 11일은 걸릴 것 같음
    • 핵심 차이는 AI 구현자는 더 싸고 빠르게, 실제로는 균일하게 더 좋게 될 수 있지만, 같은 인간들이 그렇게 되기는 매우 어렵다는 점인 듯함
      오늘의 정답이 아니더라도 최소한 가능한 미래를 알리는 신호로는 볼 수 있지 않나?
    • 이 일에 50명을 쓴다는 예시는 고전적인 “여자 아홉 명이 한 달 만에 아기를 만들 수는 없다”를 떠올리게 함
      힌트: 그 50명은 조율되어야 함
    • Jarred는 Mythos급 모델을 썼지만, 일부 오픈 가중치 모델이 그만큼 유능하다면 특히 GLM 5.2는 겉보기엔 그래 보이며, 전문가보다 훨씬 훨씬 쌀 것임
      대략 비용은 DeepSeek v4 Pro & Mimo v2.5 Pro 3,426달러, Tencent HY3 3,892달러, GLM 5.2 30,016달러, Qwen 3.7 Max 37,925달러, Claude Opus 4.8 & GPT 5.5 xhigh 82,750달러 수준임
      캐시되지 않은 입력 토큰 59억 개, 출력 토큰 6억 9천만 개, 캐시된 입력 토큰 읽기 720억 개 기준임

  • 이게 강한 테스트 스위트의 힘임. LLM은 검증 가능한 보상이 있을 때 뛰어남
    앞으로 Rust로 재작성되는 프로젝트가 훨씬 많아질 것 같음. Rust는 타입 시스템을 통한 많은 검증을 제공하고, 가비지 컬렉션 없이 낮은 오버헤드를 가지기 때문에 이런 재작성의 이상적인 목표이기도 함
    에이전트 코딩 시대에는 가비지 컬렉션 언어를 쓸 이유가 점점 줄어듦
    Rust는 LLM 코딩의 국소 최적 목표라고 봄. 미래에는 더 나은 언어가 나올 수 있겠지만, 꽤 오랫동안 Rust가 지배할 것 같음

    • 더 빠른 반복 개발 때문일 수도 있음. Rust의 안전성 보장은 공짜가 아니며, 여전히 훌륭하지만 반복 시간에 영향을 줌
      30만 줄이 넘는 개인 프로젝트를 Python에서 TypeScript로 옮긴 적이 있는데, Rust를 못 쓴 이유는 확실히 반복 개발 시간이었음

  • Anthropic이 Bun을 어떤 방식으로 쓰는지 궁금함. Claude Code의 “런타임”으로 쓰인다는 건 알지만, Zig 100만 줄을 Rust로 옮길 바에야 Claude Code를 Rust로 포팅해서 JS 런타임을 아예 번들하지 않으면 안 되나?
    Anthropic이 그 외에도 Bun을 쓰나? Claude 응답 안의 JS 실행 도구 호출 같은 용도일 수도 있음

    • 나도 같은 게 궁금했음. 특히 Codex는 Rust로 작성돼 있으니까 더 그럼
      왜 그냥 Claude Code를 옮기지 않았을까
      추측하자면 테스트 스위트가 그만큼 견고하지 않을 수도 있음
      이번 일이 그들을 대담하게 만들 수도 있음

  • “역사적으로 재작성은 끔찍한 생각이다”라는 생각은 지난 5년 사이에 달라졌음
    첫 번째 경우는 거의 작동하지 않는 소프트웨어 제품이 있는 회사에 합류했을 때였음. 전통적인 점진적 리팩터링과 재작성을 했지만, 결국 핵심이 너무 썩어 있어서 처음 원칙부터 다시 쓰는 게 최선이라는 걸 배움
    여기서 얻은 교훈은 기존 통념이 아마 복잡하지만 작동하는 시스템을 다시 쓰는 경우에만 적용된다는 것임
    이후 에이전트 코딩 시대에 여러 상황을 겪음. 본업과 취미를 오가며 Salesforce, Gmail, Pioneer Rekordbox 같은 복잡한 소프트웨어의 큰 덩어리를 매우 작은 팀으로 재현했음
    블로그 글과 마찬가지로 핵심은 컴파일러, 린터, 테스트 하네스와 테스트 스위트로 핵심 동작 주변에 뛰어난 검증 루프를 만드는 것임
    점점 더 종합적인 테스트 하네스 설계와 구현이 진짜 일처럼 느껴짐. 일단 그게 있으면 LLM이 요리하게 두면 됨

    • 나도 비슷하게 생각함. 우리의 일은 코딩 에이전트 목동으로 바뀔 수 있음
      이 경우 테스트 하네스, 린터, 워크플로 같은 것들이 우리의 양치기 개가 될 듯함

  • 흥미로웠던 점은 이 주제를 둘러싼 논의 대부분이 재작성이 Fable이 아니라 Opus 같은 모델로 진행됐다는 가정 위에서 이뤄졌다는 것임
    그런 가정은 재작성이 가능하지 않다거나 좋은 생각이 아니라는 논거로 적어도 부분적으로 쓰였음
    모델 자체가 서사를 완전히 바꾸는 건 아니지만, 개인적으로는 Anthropic과 관련 조직 내부에서 쓰는 모델의 능력을 추정할 때 더 조심해야겠다고 느낌

    • 나도 같은 생각을 했음. 돌아보면 5월에 Jarred가 “모든 .zig 파일을 .rs로 다시 쓰기” 패턴을 설명하면서, 마치 내가 그 패턴을 따라 5월에 할 수 있었던 일처럼 말했을 때 오해했을 가능성이 큼
      말하지 않았던 건 그가 출시 전 Fable을 쓰고 있었다는 점임. [1]
      다음번 신호가 될 수 있는 건 Anthropic 소유 회사가 Claude Co-Authored-By 트레일러를 끄는 경우임. [2] IPO가 있는 해라면 Claude를 홍보할 모든 기회를 잡아야 하는데, 당시 5월에는 알리면 안 되는 Fable 같은 것이었을 때만 예외가 됨
      [1]: https://xcancel.com/jarredsumner/status/2060050586024743376#...
      [2]: https://github.com/oven-sh/bun/commit/23427dbc12fdcff30c23a9...

  • 큰 프로젝트를 다시 쓸 때마다 더 작고 빠르게 만들었고, 큰 버그는 모두, 작은 버그도 대부분 고쳤음
    현재 팀도 비슷한 경험을 했음. 같은 규모로 Zig에서 Zig로 재작성했다면 품질에 어떤 영향을 줬을지 궁금함

답변달기
GN⁺   [-]
Lobste.rs 의견들
  • C++을 썼어도 Bun에는 합리적인 선택이었을 것 같음. 생성자와 소멸자를 얻고 extern "C" 래퍼 코드도 많이 지울 수 있었겠지만, 여전히 코드 리뷰로 강제되는 스타일 가이드에 의존해야 하고 ASAN이 있어도 메모리 손상과 누수는 계속 났을 것임
    재미있게도 Node.js는 C++로도 잘 돌아가지만, Bun을 진지한 프로젝트로 본 적은 없음. 이제는 Anthropic 마케팅 부서의 테스트 벤치처럼 보여서 계속 멀리할 생각임
    • Node도 자체 라이브러리 코드에서 나온 메모리 안전성 CVE가 분명 있었음. 그냥 "nodejs memory cves"로 검색해도 여러 건이 바로 나옴
    • Node가 C++로 잘 돌아간다는 건 Bun이 Zig로 잘 돌아갔다는 말과 같은 수준임. Node는 관심과 사용자가 더 많아서 문제가 더 빨리 드러날 뿐이고, 결국 둘 다 “아주 조심하고 아무도 실수하지 않으면 완벽하게 동작한다”는 상황에 있음
      스포일러를 하자면, 실제로는 그렇게 조심하지도 않고 실수도 함
  • “Bun의 Rust 코드 중 약 4%가 unsafe 블록 안에 있고, 그중 78%는 한 줄짜리”라는 말은 안심시키려는 표현처럼 보이지만, unsafe 블록이 한 줄인지 여부는 중요하지 않음. 그 안에서 안전성 보장을 깨면, 블록 밖의 모든 코드도 잠재적으로 soundness가 깨질 수 있음
    Bun의 Rust 포트 초기 병합에는 이런 종류의 명백한 unsoundness가 들어 있었음: https://github.com/oven-sh/bun/issues/30719
    해당 이슈는 유지보수자들이 CI에서 Rust의 Miri 도구를 켜면서 대응됐고, 글의 “What's Next”에도 *Miri (which runs for a growing chunk of code in CI)*가 포함되어 있으니 그쪽으로 작업 중인 건 좋아 보임
    공정하게 보자면, 안전성 위반이 있는 Rust라도 대체한 Zig 코드의 품질에 따라 더 유지보수하기 쉬울 수는 있음. 그래도 unsafe 블록당 코드 줄 수는 품질 지표가 아니며, 특히 그 블록들에 다른 코딩 관행·전문성·자동 검사도 없었다면 더더욱 그렇지 않음
    • 저 문장은 안심시키려는 게 아니라, unsafe 블록이 포팅 과정에서 생긴 게 아니라 프로젝트 요구사항에서 나온다는 뜻에 가까워 보임. C 라이브러리를 호출한다면 unsafe 블록은 필요하고, 리팩터링만으로 없앨 방법은 없음
      물론 그 C 라이브러리까지 다시 작성한다면 가능하겠지만, 그건 나중에 검토할 수도 있겠음
  • Bun에서 가장 흥미로운 점 중 하나는 기본적으로 한 명의 엔지니어가 예상보다 훨씬 많은 일을 해낸 이야기라는 점임. Jarred는 처음엔 Zig 덕분이라고 했고, 이번엔 Claude 덕분이라고 하지만, Jarred 본인이나 그의 업무 윤리 덕분이라고 해도 이상하지 않음. 작은 팀의 힘일 수도 있고, 이미 존재하는 것들을 다시 작성하고 구현한다는 사실 때문일 수도 있음
    “Bun is joining Anthropic” 발표에서 Jarred는 Bun 작업을 위해 엔지니어를 더 채용한다고 했지만, GitHub만 보면 Bun 팀은 오히려 줄어든 것처럼 보임. 여기서 얻을 결론은 잘 모르겠고, 다만 “Bun은 작은 팀이다” 정도임
  • “재작성은 끔찍한 생각”이라고 해놓고 바로 재작성을 진행한 셈임
    방법 자체는 흥미롭지만 글은 마케팅 기사처럼 읽힘. 비용이 얼마나 들었는지에 대한 분석도 부족했고, Rust 재작성에 따르는 위험도 없으며, 애초에 왜 재작성이 일어났는지에 대한 구체적 설명도 약함. 추측하자면 Zig의 no ai policy 때문이거나, Anthropic 내부에서 Rust에 집중하려는 방침이 있었을 수도 있음
    • 비용에 대해서는 이 대목이 적어도 관련 있어 보임: “병합 전까지 캐시되지 않은 입력 토큰 59억 개, 출력 토큰 6억 9천만 개, 캐시된 입력 토큰 읽기 720억 개가 쓰였고, API 가격 기준 약 165,000달러였다”
      그리고 왜 재작성했는지는 글이 꽤 일관된 이야기를 하고 있다고 봄. Bun은 문제를 잡기 위한 조치를 했는데도 계속 크래시가 났고, 개발자들은 이런 문제를 더 체계적으로 막을 방법을 원했음
      처음 계획은 특정 코딩 스타일을 더 엄격히 강제하고 스마트 포인터를 도입하는 쪽이었지만, Jared는 자체 스마트 포인터가 Rust보다 사용성이 나쁘고 보장도 없다고 봤음. 그래서 “Anthropic의 새 모델이 Bun을 Rust로 다시 쓸 수 있는지 일주일 테스트해보면 어떨까?”가 되었고, 테스트 스위트 통과율이 높아지자 “해볼 만하다”에서 “병합하겠다”로 바뀐 흐름으로 보임
      즉 처음부터 Rust 재작성을 결정했다기보다는, “Rust가 문제 해결책을 주는 것 같지만 재작성 비용 때문에 못 한다. 그런데 LLM 포팅을 해보니 가능성이 있다. 그러면 LLM 재작성으로 가자”에 가까워 보임
    • “병합 전까지 캐시되지 않은 입력 토큰 59억 개, 출력 토큰 6억 9천만 개, 캐시된 입력 토큰 읽기 720억 개가 쓰였고, API 가격 기준 약 165,000달러였다”
    • 재작성 이유는 충분히 정당해 보임. 계속되는 메모리 안전성 문제와 끝없는 두더지 잡기식 버그 수정에 대한 두려움이 있었고, 일부 엔지니어는 다른 방식으로 대응했겠지만 LLM으로 Rust 재작성을 선택하는 것도 문제에 대한 하나의 해결책임
    • 확실히 마케팅 기사처럼 읽힘. 의도했든 아니든 그렇지만, 실제로는 비용 계산이 불가능에 가까움. 특히 개발자들이 출시 전 Anthropic 모델에 접근할 수 있었다면 더 그렇다. 다만 지금의 Claude 모델로 평범한 우리가 그 정도 규모를 다시 쓴다면 비용은 추정할 수 있음
  • 이런 버그들을 계속 하나씩 고치는 대신, 의존하는 사용자들을 위해 더 잘해야 하고 이런 버그가 반복되지 않게 체계적으로 막아야 한다는 건 훌륭한 이유임. 그래도 “Rust 분위기가 좋다”는 이유였어도 받아들였을 것 같음
    이걸 해낸 Jarred, Bun 팀, Anthropic에게 축하를 보냄
답변달기