Rust 컴파일러, Zig로 재작성 중인 현황과 논쟁

커뮤니티에서는 Zig의 증분 빌드(Incremental Build) 기능이 컴파일 시간을 획기적으로 단축시킨다는 점을 높이 평가합니다. 이는 개발 생산성 향상에 직접적인 영향을 미치기 때문입니다. 반면, Rust 역시 향후 빌드 시스템 최적화(Build System Optimization)를 통해 유사한 성능 개선을 이룰 수 있을 것이라는 기대도 존재합니다. 하지만 현재로서는 Zig의 속도가 매력적인 전환 요인으로 작용하고 있음을 시사합니다.

Zig의 메모리 안전성에 대한 의문이 제기되었습니다. 특히 Use-after-free(UaF)와 같은 오류를 런타임에 효과적으로 탐지하는지에 대한 증거가 부족하다는 지적이 있습니다. Zig 문서에는 관련 기능이 명시적으로 언급되지 않아, 디버그 할당자(Debug Allocator)를 릴리즈 빌드에서 사용하는 경우에 한정될 수 있다는 추측이 나옵니다. 이는 컴파일러와 같이 메모리 제어(Memory Control)가 중요한 시스템에서 잠재적 위험 요소로 간주됩니다.

Rust 컴파일러의 런타임(Runtime) 및 메모리 관리(Memory Management) 복잡성이 재작성의 주요 동기 중 하나로 분석됩니다. 일부 개발자는 컴파일러 자체의 메모리 안전성(Memory Safety)을 위해 `unsafe` 코드가 불가피하게 사용되는 부분을 지적하며, 이는 Rust의 핵심 가치와 상반될 수 있다는 의견을 제시합니다. 반면, `unsafe`는 주로 핫 패치(Hot Patching)와 같은 특정 기능 구현에 필요하며, 일반적인 코드 생성에는 해당되지 않는다는 반론도 있습니다.

초기 프로토타입 단계에서 OCaml의 유연성과 표현력이 활용되었으나 최종 구현 언어로 Zig가 선택된 배경에 대한 궁금증이 제기됩니다. OCaml의 성숙도와 Zig의 점진적 빌드(Incremental Build) 성능을 고려할 때, 메모리 제어(Memory Control)의 중요성이 컴파일러 개발에서 결정적인 요소로 작용했을 가능성이 높습니다. 이는 Rust 역시 초기 OCaml로 개발되었다는 역사적 맥락과도 연결됩니다.

Zig의 보안 문제에 대한 언급이 '손으로 흔드는(hand-waving)' 수준에 그친다는 비판이 있습니다. 이는 메모리 안전성(Memory Safety)에 대한 우려를 증폭시킵니다. 해당 커뮤니티 멤버는 C/C++ 환경에서 이미 수십 년간 사용되어 온 성숙한 할당자 디버거(Allocator Debugger) 도구들이 존재하므로, Zig의 디버깅 기능이 특별히 혁신적이지 않다는 시각을 보입니다. 이는 Zig의 보안 및 디버깅 생태계(Security and Debugging Ecosystem)에 대한 추가적인 검증 필요성을 시사합니다.