Bun의 Zig→Rust 실험, AI 시대 런타임 팀이 언어 선택을 다시 묻기 시작했다

나는 런타임 뉴스를 볼 때 벤치마크 그래프보다 먼저 팀의 표정을 상상한다. 숫자는 화려하게 만들 수 있어도, 몇 년짜리 제품을 버티게 하는 건 결국 그 언어로 계속 고칠 수 있느냐, 사람을 더 태울 수 있느냐, AI까지 섞인 협업 구조를 감당할 수 있느냐 같은 질문이기 때문이다. 그래서 이번 Bun의 Zig→Rust 실험은 “리라이트 하나 또 나오네” 정도로 넘기기엔 꽤 큰 신호다.

Bun 팀은 최근 공개된 포팅 가이드에서 우선 Phase A는 논리를 Rust로 옮기는 단계, 그 다음 Phase B는 crate 단위로 실제 컴파일되게 만드는 단계라고 설명했다. 즉, 이미 손이 들어갔고, 그냥 아이디어 메모 수준은 아니다. 공개 compare 페이지에서도 변경 파일이 2천 개를 넘길 정도로 실험 규모가 작지 않다. 다만 팀도 아직 “무조건 리라이트”를 확정한 건 아니라고 선을 긋고 있다. 여기서 중요한 건 결과보다 질문이다. 왜 잘 나가던 Bun이 지금 언어 선택을 다시 묻기 시작했을까?

이번 이슈의 핵심은 성능보다 유지보수성이다

Bun을 바라보는 시장은 늘 속도에 먼저 반응했다. 빠른 설치, 빠른 실행, 빠른 번들링. 그런데 제품이 커지고 팀이 커지면 속도 하나만으로는 설명이 안 되는 순간이 온다. 이번 실험이 흥미로운 이유는 Bun이 이제 그 구간에 들어갔다는 점이다.

공개 보도에 따르면 Bun 팀은 이미 Zig를 포크해 macOS와 Linux에서 디버그 컴파일 시간을 4배가량 개선했다고 주장해왔다. 얼핏 보면 “그럼 Zig에서 계속 가면 되는 거 아냐?” 싶다. 그런데 바로 그 지점이 함정이다. 포크를 오래 끌고 가는 순간, 팀은 언어를 쓰는 게 아니라 사실상 언어 생태계 일부를 직접 운영하게 된다.

그 부담은 생각보다 빨리 커진다.

• 업스트림과 방향이 다르면 패치가 누적된다
• 언어 자체가 빠르게 변하면 제품 로드맵이 흔들린다
• 새 팀원을 뽑을 때 채용 풀이 좁아진다
• 디버깅 경험과 도구체인이 특정 소수에게 묶인다
• 런타임 버그가 언어 문제인지 제품 문제인지 경계가 흐려진다

Node가 여전히 C++라는 무거운 선택을 끌고 가는 이유도, Deno가 Rust를 택한 이유도 결국은 비슷하다. 런타임 팀에게 구현 언어는 취향이 아니라 운영 체제 같은 결정이다. Bun이 Zig로 차별화에 성공한 건 맞지만, 제품이 메인스트림으로 갈수록 “다르다”보다 “오래 버틴다”가 더 중요해진다.

Zig에서 Rust를 만져보는 순간, 팀 운영의 비용이 드러난다

이번 실험을 너무 단순하게 “Rust가 더 대중적이니까”로만 읽으면 반만 본 거다. 런타임 팀이 언어를 다시 고르는 순간에는 늘 세 가지가 같이 움직인다. 채용, 리뷰, 도구체인이다.

Rust는 적어도 여기서 분명한 장점이 있다. 생태계가 넓고, 리뷰 가능한 인력이 많고, 크레이트 단위로 경계를 나누기 쉽다. 특히 AI 코드 생성이 깊게 들어오는 시대에는 이 장점이 더 커진다. 사람이 처음부터 끝까지 다 쓰는 시대보다, AI가 초안을 만들고 사람이 검토·통합하는 시대에선 코드 자체만큼 “검토 가능한 구조인가”가 중요해지기 때문이다.

예를 들어 지금 런타임 팀이 실제로 고민할 법한 건 이런 질문이다.

- 이 코드를 새 엔지니어가 2주 안에 읽을 수 있는가?
- AI가 만든 초안을 사람이 안전하게 검토할 수 있는가?
- 성능 최적화와 메모리 안전성을 같은 리뷰 흐름 안에 넣을 수 있는가?
- 업스트림 언어 변화가 제품 출시 일정에 얼마나 영향을 주는가?

이 질문에 Rust는 비교적 익숙한 답을 준다. 물론 Rust가 공짜는 아니다. 학습 곡선은 있고, 컴파일 시간도 부담일 수 있고, unsafe 경계 설계도 만만치 않다. 그래도 “큰 팀이 오래 운영하기 위한 기본기”라는 관점에서는 훨씬 검증된 축에 가깝다. Bun이 바로 Rust로 완전히 이동하든 아니든, Rust를 진지하게 만져보기 시작했다는 사실 자체가 팀이 이제 언어의 낭만보다 운영의 신뢰를 먼저 보고 있다는 뜻이다.

진짜 뜨거운 포인트는 AI 시대의 오픈소스 협업 규범 충돌이다

이번 이슈가 더 재밌는 건 기술 선택만의 문제가 아니라는 점이다. Zig 커뮤니티의 강한 no-AI 정책과, Anthropic 산하에서 움직이는 Bun 팀의 AI 활용 기조가 정면으로 부딪히고 있다. 이건 앞으로 더 자주 보게 될 장면이다.

예전 오픈소스 논쟁은 라이선스나 거버넌스가 중심이었다. 이제는 거기에 하나가 더 붙었다. AI가 쓴 코드를 어디까지 받아들일 것인가. Zig 쪽은 노이즈, 환각, 대형 저품질 PR 문제를 이유로 강하게 막고 있고, Bun 쪽은 반대로 AI가 구현 속도를 크게 밀어줄 미래를 본다. 둘 다 논리는 있다. 문제는 제품을 굴리는 팀이 어느 쪽 규범과 더 잘 맞느냐다.

이 지점에서 Bun 실험은 런타임 업계 전체에 질문을 던진다.

• AI 작성 코드가 많은 팀은 어떤 언어/커뮤니티에서 더 빨리 움직일 수 있나
• 업스트림이 AI 친화적이지 않을 때 포크 유지 비용은 어디까지 커지나
• 리뷰어가 감당할 수 있는 코드량과 품질 기준은 어떻게 바뀌나
• “빠른 실험”과 “장기 신뢰”는 어떤 구조에서 같이 성립하나

나는 이게 단순히 Bun만의 문제가 아니라고 본다. 앞으로 런타임, 데이터베이스, 브라우저 엔진처럼 복잡한 시스템 소프트웨어 팀일수록 언어 선택 = AI 협업 정책 선택이 되는 순간이 많아질 거다. 예전엔 타입 시스템과 성능 모델이 1순위였다면, 이제는 그 위에 “우리 팀의 구현 방식과 커뮤니티 규범이 충돌하지 않는가”가 올라온다.

한국 개발자는 이제 Bun을 더 똑똑하게 평가해야 한다

한국 개발자 커뮤니티에서 Bun은 대체로 “빠르고 편한 자바스크립트 런타임”으로 소비돼왔다. 이 이미지는 여전히 유효하다. 다만 이번 실험 이후에는 질문을 조금 바꿔야 한다. Bun이 빠른가? 다음에 바로 **Bun을 프로덕션 깊숙이 넣었을 때 장기 유지보수 리스크는 어떤가?**를 붙여야 한다.

내가 지금 팀에 체크리스트를 준다면 이런 순서로 보라고 할 것 같다.

1) 속도보다 버전 고정 전략부터 확인

실험 단계일수록 CI와 배포 환경에서 Bun 버전을 더 엄격하게 고정하는 편이 낫다.

bun --version
cat package.json | grep packageManager

2) 빌드 벤치보다 회귀 테스트를 먼저 붙이기

속도 자랑은 데모에서 하고, 운영은 회귀 테스트가 지킨다.

hyperfine --warmup 2 \
  'bun run build && bun test' \
  'pnpm run build && pnpm test'

3) Node fallback 경로를 남겨두기

특정 서버 함수, 네이티브 의존성, 번들링 경로에서 문제 생길 때 빠르게 돌아갈 레인을 남겨야 한다.

4) 팀 안의 리뷰 가능성 점검

“이 코드를 우리 팀이 6개월 뒤에도 이해할 수 있나?”를 언어 선택 질문에 꼭 넣어야 한다.

이건 Bun을 버리라는 얘기가 아니다. 오히려 반대다. Bun은 여전히 매력적이고, 많은 팀에게 생산성을 준다. 다만 이제는 “빠르니까 도입”보다 “빠른데, 우리 팀이 신뢰 구조까지 감당할 수 있나”로 질문이 성숙해야 한다.

내 입장에서

김덕환 운영자가 봤을 때 이 이슈는 런타임 팬덤 싸움이 아니라, 작은 팀이 어떤 기술을 오래 믿고 사업 자산으로 쌓을 수 있느냐의 문제에 가깝다. log8.kr처럼 기술 변화를 계속 해석해야 하는 운영자 입장에선, Bun의 이번 움직임이 곧바로 “Rust가 답이다”를 뜻하진 않지만, AI 시대에는 언어 선택이 곧 팀의 신뢰 전략이 된다는 사실은 꽤 선명하게 보여준다.

결국 이번 Bun 실험의 진짜 메시지는 이거다. 앞으로 런타임 팀은 가장 멋진 언어보다, 가장 오래 검토 가능하고 유지 가능한 언어와 협업 규범을 고르게 될 가능성이 크다.