Turborepo가 Go에서 Rust로 마이그레이션하는 이유

Turborepo 팀이 버전 1.7부터 Go 코드베이스를 점진적으로 Rust로 전환하기 시작했다. 빌드 시스템이 데이터센터가 아닌 엔드유저에게 직접 배포되는 소프트웨어라는 점에서 Go의 설계 철학이 요구사항과 어긋났고, Rust의 타입 시스템이 컴파일 타임에 더 많은 오류를 잡는다는 판단이다. Turbopack 팀과 공통 언어를 쓰게 되는 팀 통합 효과도 결정을 가속시켰다.

핵심 포인트

Go는 데이터센터 환경(런타임 오류 허용 가능)을 위해 설계됐지만, Turborepo는 엔드유저 소프트웨어라 실수 비용이 훨씬 크다.
Rust 타입 시스템은 잘못된 사용을 컴파일 타임에 차단한다 — 예: Go에서는 Windows에 Unix 파일 권한 설정이 오류 없이 통과되지만 실제 적용되지 않고, Rust는 컴파일 오류로 차단한다.
Rust FFI가 CGO보다 효율적이다 — bindgen·cxx 크레이트로 C/C++ 라이브러리 래핑이 로컬라이즈드·안전하게 이뤄지며, CGO처럼 전역 빌드 설정 변경이 불필요하다.
Turborepo·Turbopack 팀이 Rust를 공유하면서 중복 문제 해결이 제거되고 유틸리티를 함께 유지보수할 수 있게 됐다.
전면 재작성 대신 "Rust-Go-Rust 샌드위치" 점진적 전환 — Rust 바이너리가 진입점이 되어 각 CLI 명령을 Rust 또는 Go 구현으로 라우팅한다.

상세 정리

Go 채택 배경: esbuild 성공을 보고 채택했다. 빠른 실행 속도, 최소 Node.js 오버헤드, 빠른 반복 개발이 장점이었다.
Go 설계 불일치: Go는 네트워크 데이터센터 컴퓨팅을 위해 단순성을 우선시하며 런타임 오류가 허용 가능한 환경을 전제한다. 엔드유저 도구는 릴리즈마다 실수 비용이 더 높다.
파일 권한 크로스플랫폼 버그: Go는 Windows에서 Unix 파일 권한 설정을 오류 없이 허용하지만 실제로 적용되지 않는다. Rust는 Unix 전용 API에 명시적 어노테이션을 강제해 컴파일 타임에 차단한다.
FFI 비교: Go CGO는 전역 빌드 변경이 필요해 의존성 관리가 복잡해진다. Rust bindgen·cxx는 로컬라이즈드·안전한 래퍼를 생성한다. Turborepo는 git2 크레이트로 libgit2를 연동해 Rust와 C 에코시스템 장점을 동시에 취한다.
Turbopack 팀 통합: 두 팀이 같은 언어를 쓰면서 중복 문제 해결이 사라지고, 공유 유틸리티 유지보수가 단순해졌다.
개발자 만족도·채용: Rust 개발은 번아웃을 줄이고 문제 해결력을 높인다는 리서치가 있다. 웹 개발자의 두 번째 언어로 Rust 채택이 늘어 기여자 풀도 확대된다.
마이그레이션 전략(Rust-Go-Rust 샌드위치): Rust 바이너리가 CLI 진입점이 되어 각 명령을 Rust 구현인지 Go 구현인지 판단한다. 양방향 FFI로 Rust→Go, Go→Rust 호출이 모두 가능해 기능 단위 점진적 전환을 지원한다.
현황: Turborepo 1.8에서 추가 기능들이 Rust로 구현됐으며, 팀은 지속적인 "oxidation(Rust화)"을 계획한다.