Perry vs Bun
Bun은 JavaScript/TypeScript 런타임이자 번들러, 패키지 매니저, 테스트 러너를 모두 갖춘 올인원 도구로, 자체 런타임을 코드와 함께 묶어 단일 실행 파일을 만들 수도 있습니다. Perry는 다른 길을 택합니다 — LLVM을 통해 TypeScript를 곧바로 네이티브 머신 코드로 컴파일합니다. 바이너리 안에는 JavaScript 엔진도, 런타임도 없으며 작은 네이티브 실행 파일만 남습니다. Bun과 Perry는 TS-바이너리 출력이라는 점에서는 겹치지만, 그 바이너리에 JavaScript 엔진이 들어가야 하는지에 대해서는 의견이 갈립니다.
Bun란 무엇인가?
Bun은 Zig로 작성된 빠른 올인원 JavaScript·TypeScript 툴킷입니다. `.ts` 소스를 사전 컴파일 단계 없이 바로 실행하며, JS 엔진으로 JavaScriptCore를 사용하고 번들러, 패키지 매니저, 테스트 러너를 내장하고 있습니다. `bun build --compile`은 Bun 런타임을 애플리케이션과 함께 단일 실행 파일로 번들링합니다. Bun은 x64 및 arm64 환경의 Linux, macOS, Windows를 타겟으로 합니다.
Perry란 무엇인가?
Perry는 Rust로 작성된 네이티브 TypeScript 컴파일러입니다. LLVM을 통해 TypeScript를 곧바로 네이티브 머신 코드로 컴파일합니다 — JavaScript 엔진도, 런타임도, JIT도 없습니다. 출력은 단일 바이너리로, hello world의 경우 약 330 KB이며 Fastify 서버처럼 표준 라이브러리를 모두 포함하는 앱은 약 48 MB 정도입니다. Perry는 macOS, iOS, iPadOS, Android, Linux, Windows, watchOS, tvOS, WebAssembly, 웹을 포함한 10개 플랫폼을 타겟으로 합니다.
나란히 비교
| 기능 | Perry | Bun |
|---|---|---|
| 출력 형태 | 네이티브 머신 코드 (LLVM) | 사용자 코드 + Bun 런타임이 하나의 바이너리에 번들링됨 |
| 바이너리 내 JavaScript 엔진 | 기본값 없음. --enable-js-runtime 옵션으로 V8 추가 가능 (+~15 MB) | JavaScriptCore, 항상 포함 |
| Hello-world 바이너리 크기 | 약 330 KB | 약 50–100 MB (Bun 런타임 포함) |
| JIT | 없음 (AOT 컴파일) | 있음 (JavaScriptCore JIT) |
| 모바일 타겟 (iOS, Android) | 지원 — UIKit/JNI를 통한 네이티브 UI | 지원하지 않음 |
| 워치·TV 타겟 | watchOS, tvOS, Wear OS | 지원하지 않음 |
| 네이티브 UI 위젯 | AppKit, UIKit, GTK4, Win32, JNI 기반 25개 이상 | 없음 (서버·CLI 중심) |
| npm 생태계 | 순수 TS/JS 패키지는 네이티브 컴파일 가능, 그 외에는 선택적 V8을 통해 지원 | Node 호환 npm 전체 지원 |
| 안정성 | 1.0 이전 (알파) | 안정 (1.x) |
| 구현 언어 | Rust | Zig |
Perry가 앞서는 점
- +더 작은 바이너리 — Perry의 hello world는 약 330 KB이며, Bun --compile로 만든 hello world는 Bun 런타임을 포함해 수십 MB에 이릅니다.
- +JavaScript 엔진 비용이 없습니다. Perry로 컴파일된 바이너리에는 인터프리터나 JIT가 들어가지 않습니다 — TypeScript 자체가 실행 파일이 됩니다.
- +모바일, 워치, TV. Perry는 iOS, iPadOS, Android, watchOS, tvOS, WebAssembly로 컴파일됩니다. Bun은 서버·데스크톱 전용입니다.
- +네이티브 UI. Perry의 perry/ui 모듈은 실제 플랫폼 위젯으로 컴파일됩니다 (macOS의 AppKit, iOS의 UIKit, Linux의 GTK4, Windows의 Win32, Android의 JNI). Bun은 UI에 대한 답이 없습니다.
- +M1 Max에서 동일 조건으로 측정한 대부분의 연산 마이크로벤치마크에서 더 빠릅니다 (RUNS=11, v0.5.279, 2026-04-25): fibonacci 318 ms vs Bun 589 ms; object_create 1 ms vs 6 ms; nested_loops 18 ms vs 21 ms. 전체 표는 perry/benchmarks를 참고하세요.
- +동적 타입 런타임 그룹의 JSON validate-and-roundtrip에서 더 빠릅니다: 동일한 1만 레코드 워크로드에서 Perry의 지연 JSON 테이프는 중앙값 75 ms를 기록한 반면 Bun은 259 ms입니다.
Bun이 앞서는 점
- +1.x 릴리스를 가진 성숙하고 안정적인 런타임. Perry는 1.0 이전입니다.
- +JSON parse-and-iterate (모든 값을 실제로 순회하는 워크로드)에서 더 빠릅니다: 동일 워크로드 기준 Bun 254 ms vs Perry 466 ms 중앙값 — 순회가 강제되면 Perry의 지연 테이프는 지름길을 쓸 수 없습니다.
- +기본 제공되는 Node 호환 npm 생태계 전체. Perry는 일부를 네이티브로 실행하고 나머지는 선택적으로 임베디드 V8로 폴백합니다.
- +내장 테스트 러너, 번들러, 패키지 매니저. Perry는 컴파일러이며 부가 도구는 별도입니다.
- +JIT 워밍업 후의 성능은 핫 이너 루프가 많은 반복 위주 코드에서 AOT를 앞설 수 있습니다. Perry에는 JIT가 없습니다.
- +`loop_data_dependent`에서는 실행 간 노이즈 범위 안에서 Perry와 동률입니다 (232 ms vs 235 ms) — 양쪽 컴파일러 모두 명령어 재배치가 불가능한 진정으로 폴딩 불가능한 f64 커널입니다. 출처: perry/benchmarks RUNS=11.
Perry을 선택해야 할 때
바이너리 크기가 중요할 때 (모바일 배포, 임베디드 환경, 빠른 콜드 스타트), 하나의 TypeScript 코드베이스로 모바일·워치·TV에 배포하고 싶을 때, 네이티브 UI 위젯이 필요할 때, 또는 배포되는 산출물에 JavaScript 엔진이 들어가는 것 자체를 원치 않을 때 Perry를 선택하세요.
Bun을 선택해야 할 때
지금 당장 안정적이고 성숙한 런타임이 필요할 때, npm 호환성이 절대적으로 중요할 때, 런타임 + 번들러 + 패키지 매니저 + 테스트 러너를 단일 도구로 쓰고 싶을 때, 또는 콜드 스타트 크기보다 장기 실행 워크로드의 JIT 워밍업 후 성능이 더 중요할 때 Bun을 선택하세요.
결론
Bun과 Perry는 모두 TypeScript 프로그램을 단일 바이너리로 배포할 수 있게 해주지만, 답하는 질문이 다릅니다. Bun의 바이너리는 Bun 런타임을 포함하며 JIT와 완전한 Node 호환성이 강점이 되는 백엔드·CLI 워크로드에 최적화되어 있습니다. Perry의 바이너리는 JS 엔진을 포함하지 않으며 크기, 콜드 스타트, 모바일, 네이티브 UI에 최적화되어 있습니다. 서버를 배포한다면 오늘날 Bun이 더 검증되어 있습니다. 네이티브 앱을 배포하거나 바이너리 크기가 중요하다면 Perry가 그 용도로 만들어진 도구입니다.