--- title: "Bun의 Rust 재작성 PR이 머지됨" published: 2026-05-14T08:15:31.000Z canonical: https://jeff.news/article/2694 --- # Bun의 Rust 재작성 PR이 머지됨 Bun 프로젝트에서 기존 코드 일부를 Rust로 재작성한 대형 PR이 머지됐다. 기존 테스트 스위트를 모든 플랫폼에서 통과했고, 바이너리 크기는 3~8MB 줄었으며, 성능 벤치마크는 대체로 중립이거나 더 빨라졌다고 한다. - Bun의 ‘Rust로 재작성’ PR이 머지됨 - PR 번호는 30412이고, 작성자는 자세한 내용은 별도 블로그 글로 낼 예정이라고 밝힘 - 지금 써보려면 `bun upgrade --canary`로 카나리 빌드를 올리면 됨 - 이번 변화의 핵심은 성능 과시보다 메모리 안정성 쪽임 - Bun 팀은 그동안 메모리 버그 때문에 개발과 디버깅 시간을 많이 썼다고 함 - Rust로 옮기면서 컴파일러가 메모리 문제를 잡고 예방하는 도구가 생긴 게 가장 중요하다고 설명함 > [!IMPORTANT] > 벤치마크가 빨라졌다는 얘기보다 더 중요한 건, Bun 팀이 메모리 버그를 사람의 집중력 대신 컴파일러에 더 맡기게 됐다는 점임. - 기존 코드베이스가 완전히 새 프로젝트가 된 건 아님 - 아키텍처와 데이터 구조는 대체로 그대로 유지됐다고 함 - 여전히 서드파티 라이브러리를 많이 쓰지 않는 방향도 유지됨 - 비동기 Rust도 쓰지 않았다고 명시했는데, 런타임 내부 구조를 급격히 바꾸기보다는 안전한 언어 경계로 옮긴 느낌에 가까움 - 정량 지표도 꽤 좋게 나옴 - 기존 Bun 테스트 스위트를 모든 플랫폼에서 통과함 - 몇몇 메모리 누수와 불안정한 테스트도 같이 고쳤다고 함 - 바이너리 크기는 3MB에서 8MB 정도 줄어듦 - 벤치마크는 중립이거나 더 빠른 쪽이라고 설명함 - 아직 바로 안정 버전에 들어갈 단계는 아님 - 정식 비카나리 버전에 들어가기 전 최적화 작업이 남아 있음 - 코드 정리도 후속 PR 시리즈로 이어질 예정임 - 사용 중 문제가 있으면 이슈를 열어달라고 요청함 - 개발자 입장에서는 Bun이 ‘빠른 도구’에서 ‘장기 유지보수 가능한 도구’로 한 단계 가려는 신호로 볼 만함 - 자바스크립트 런타임은 성능도 중요하지만, 네이티브 코드가 많을수록 메모리 안정성이 신뢰도에 직결됨 - 특히 패키지 매니저, 번들러, 테스트 러너까지 한 프로세스 안에서 다루는 Bun 특성상 메모리 버그 비용이 누적되기 쉬움 --- ## 기술 맥락 - 이번 선택은 Bun을 새로 설계한 게 아니라, 기존 구조를 유지한 채 구현 언어의 리스크를 줄인 쪽이에요. 아키텍처와 데이터 구조를 그대로 둔 이유는 성능 특성과 동작 호환성을 크게 흔들지 않기 위해서로 읽혀요. - Rust를 고른 이유는 런타임 내부에서 자주 터지는 메모리 누수, 수명 관리, 포인터 계열 버그를 컴파일러가 더 일찍 잡아주기 때문이에요. 빠른 실행 속도만 보면 다른 선택지도 있지만, 팀이 강조한 건 디버깅 시간 절감이었어요. - 비동기 Rust를 쓰지 않았다는 점도 중요해요. 런타임의 이벤트 모델까지 바꾸면 변화 범위가 너무 커지는데, 이번 PR은 언어 전환으로 얻는 안전성에 집중한 셈이에요. - 카나리로 먼저 여는 건 이런 저수준 변경의 전형적인 배포 방식이에요. 테스트가 통과해도 플랫폼별 성능, 네이티브 모듈, 엣지 케이스는 실제 사용자 환경에서 더 잘 드러나거든요. ## 핵심 포인트 - Bun의 Rust 재작성 PR이 머지됐고 카나리 빌드에서 바로 테스트 가능함 - 기존 아키텍처와 데이터 구조는 대부분 유지됐고, 비동기 Rust도 쓰지 않았음 - 핵심 목적은 성능보다 메모리 버그를 컴파일러 도움으로 줄이는 것에 가까움 - 바이너리 크기는 3~8MB 감소했고 기존 테스트 스위트도 통과함 ## 인사이트 런타임 프로젝트가 Rust로 이동할 때 흔히 ‘새로 갈아엎기’처럼 보이지만, 이번 PR은 아키텍처를 유지하면서 메모리 안정성 도구를 얻는 쪽에 가깝다. Bun처럼 빠른 릴리스와 네이티브 코드가 섞인 프로젝트에서는 이 선택이 유지보수 비용을 꽤 줄일 수 있다.