Bun의 Zig→Rust 전환, AI가 엔지니어링을 대체했다는 증거일까?

Bun의 Zig→Rust 전환, AI가 엔지니어링을 대체했다는 증거일까?

AI 뉴스 썸네일

Bun이 대규모 Zig 코드를 Rust로 옮긴 일은 AI 코딩의 속도를 보여주는 사례로 소개됐어요. 그러나 이 전환만으로 AI가 소프트웨어 엔지니어링을 대체했다고 보기는 어려워요. 언어를 바꾼 이유, 검토한 대안, 전환 비용을 함께 봐야 기술적 판단과 홍보 문구를 구분할 수 있어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
전환 배경	Bun은 반복된 메모리 오류를 줄이기 위해 Zig 코드를 unsafe Rust로 옮겼어요	AI가 얼마나 빨리 코드를 만들었는지보다 어떤 안전장치를 택했는지가 더 중요해요
논쟁의 초점	비판은 Rust 선택 자체보다 대안과 비용을 충분히 공개하지 않은 설명 방식에 향해요	기술 의사결정은 장점만 나열하면 사후 정당화로 보일 수 있어요
Zig의 대안	정적 할당과 엄격한 규칙으로 메모리 오류를 줄이는 TigerStyle 같은 접근도 있어요	언어 교체 전에 현재 언어의 운용 방식을 바꿀 선택지도 비교해야 해요
AI의 역할	대규모 이식은 빨라졌지만 설계 규칙, 메모리 모델, 검토와 테스트는 계속 필요해요	코드 생성 속도와 엔지니어링 책임은 같은 문제가 아니에요

1. Bun의 언어 전환이 남긴 질문은 속도보다 의사결정 과정이에요

Bun은 TypeScript와 JavaScript를 실행하는 런타임이에요. 초기부터 Zig로 개발됐지만, 프로젝트가 커지면서 use-after-free와 메모리 누수 같은 오류를 반복해서 고쳤어요. Bun 창업자 Jarred Sumner는 Rust의 소유권 모델과 borrow checker가 이런 문제를 구조적으로 줄일 수 있다고 설명했어요. 실제 이식은 기존 구조를 최대한 유지한 채 파일별로 진행했고, 처음부터 안전한 Rust만 고집하지 않고 unsafe Rust를 활용했어요. 한 번에 재설계하지 않아 전환 위험을 낮춘 점은 현실적인 선택이에요. 3

논쟁은 Rust를 골랐다는 사실보다 전환 이유를 설명한 방식에서 커졌어요. 원문 저자 Ray Myers는 Bun의 글이 메모리 안전성과 유지보수 장점을 자세히 다루지만, 검토했던 대안과 비용은 충분히 비교하지 않았다고 지적해요. 대규모 Rust 코드베이스에서 길어질 수 있는 컴파일 시간이나 개발 흐름의 변화가 설명에서 빠졌어요. 장점과 비용을 같은 표에 올리지 않으면 독자는 기술적 결론이 먼저 정해졌다고 느낄 수 있어요. 2

Zig 창시자 Andrew Kelley도 비슷한 지점을 더 직설적으로 짚었어요. Bun이 겪은 메모리 오류를 Zig라는 언어의 한계로만 읽기 전에 프로젝트 운영 방식과 코드 규칙을 살펴야 한다는 반론이에요. 표현의 강도와 개인을 향한 비판에는 논란의 여지가 있어요. 그래도 언어 선택, 팀 운영, 자동화 수준을 한 원인으로 뭉치면 안 된다는 문제 제기는 남아요. 4

현재 언어를 다르게 쓰는 방법도 비교 대상이에요. Zig 기반 금융 데이터베이스 TigerBeetle은 시작할 때 메모리를 정적으로 할당하고, 초기화 뒤에는 동적 할당과 해제를 피하는 TigerStyle을 사용해요. use-after-free가 생길 경로를 설계 단계에서 줄이고 시뮬레이션 테스트로 상태 변화를 폭넓게 확인해요. 모든 프로젝트가 이 방식을 그대로 쓸 수는 없어요. 네트워크 런타임인 Bun과 금융 데이터베이스는 요구사항이 다르기 때문이에요. 다만 스타일 규칙 강화, 정적 분석, 구조 변경도 언어 교체와 함께 검토할 수 있었다는 점은 분명해요. 5

AI가 대규모 이식 시간을 줄인 성과도 무시할 필요는 없어요. 기존 파일 경계를 유지하고 반복 변환을 자동화하면 사람이 처음부터 다시 작성하는 것보다 빠르게 결과를 만들 수 있어요. 문제는 생성된 코드의 규모가 곧 판단의 품질을 뜻하지 않는다는 데 있어요. 어떤 포인터 규칙을 적용할지, unsafe 범위를 어디까지 허용할지, 성능과 빌드 시간을 어떻게 측정할지는 여전히 사람이 정해야 해요.

728x90

이번 사례는 코드 가독성에 관한 모순도 보여줘요. Bun은 Zig에서 소유권을 명시하는 포인터 래퍼가 코드를 장황하게 만든다고 봤어요. 동시에 사람이 검토하기 어려운 규모의 자동 변환은 받아들였어요. 코드가 계속 사람의 유지보수 대상이라면 몇 줄의 문법 비용과 대규모 자동 변경의 검토 비용을 같은 기준으로 비교해야 해요.

Bun 공식 글과 비판 글은 서로 다른 목적을 갖고 있어요. Bun은 실제 장애와 이식 방법을 설명하고, Myers는 그 설명에서 빠진 선택지와 Anthropic의 이해관계를 문제 삼아요. 어느 한쪽만 보면 Rust가 모든 문제를 해결했다거나 AI 홍보가 전부 허구라는 단순한 결론에 빠지기 쉬워요. 확인할 수 있는 사실은 Bun이 메모리 오류를 겪었고, Rust 이식을 택했으며, AI 도구가 그 작업을 빠르게 진행하는 데 쓰였다는 점이에요. 이 결정이 장기적으로 유지보수성과 안정성을 얼마나 높였는지는 운영 결과를 더 지켜봐야 해요.

왜 중요한가요

개발팀이 이 사례에서 가져갈 교훈은 특정 언어의 승패가 아니에요. 큰 기술 전환을 설명할 때 동기, 검토한 대안, 장단점, 측정 기준을 함께 남겨야 해요. 그래야 팀 밖에서도 결정을 재현할 수 있고, 몇 달 뒤 결과가 달라졌을 때 무엇을 다시 검토할지 알 수 있어요. 2

AI 코딩 도구의 성과도 같은 방식으로 평가할 수 있어요. 변환한 코드 줄 수와 소요 시간만 기록하면 속도만 보여요. 회귀 오류 수, 검토 시간, 빌드 시간, 성능 변화, 배포 뒤 장애까지 함께 봐야 실제 비용을 알 수 있어요. Rust의 borrow checker나 엄격한 코드 규칙은 AI를 없애는 장치가 아니에요. 자동 생성 결과가 넘지 말아야 할 경계를 코드와 도구로 명시하는 장치에 가까워요.

코딩 자동화와 소프트웨어 엔지니어링의 종말을 같은 문장에 놓으면 설계와 검증에 들어가는 일이 사라져 보여요. Bun의 전환은 오히려 반대 장면도 담고 있어요. 빠른 코드 변환 뒤에도 언어 선택, 메모리 안전성, 테스트 전략, 가독성, 팀의 설명 책임을 두고 긴 논쟁이 이어졌어요. 자동화가 강해져도 이런 판단을 기록하고 검증하는 일은 개발팀이 직접 맡아야 해요.

참고 자료

1. Zig 창시자는 진실을 말하지만, Anthropic은 허풍을 떨고 있다 — GeekNews
2. Zig Creator Calls Spade a Spade, Anthropic Blows Smoke — Ray Myers
3. Rewriting Bun in Rust — Bun Blog
4. My Thoughts on the Bun Rust Rewrite — Andrew Kelley
5. TigerStyle — TigerBeetle