Rust 팀이 CPU 쪽 시스템 코드는 깔끔하게 관리하면서도, 성능이 필요한 순간만 오면 CUDA C++ 파일과 별도 빌드 체인으로 넘어가야 하는 상황은 꽤 익숙합니다. 문제는 문법 취향이 아닙니다. GPU 커널을 누가 작성하고, 누가 리뷰하며, 버그가 host/device 경계를 넘을 때 누가 책임지는가의 문제입니다.
그런 점에서 NVlabs의 cuda-oxide는 "Rust로 CUDA를 쓴다"는 뉴스보다 조금 더 실무적인 질문을 던집니다. 이제 커스텀 GPU 커널을 Rust 코드베이스 안에 포함시킬 수 있다면, 어느 시점부터 CUDA/C++ 섬을 유지하는 것보다 Rust-native 커널이 더 나은 선택이 될까요? MarkTechPost도 이 프로젝트를 표준 Rust 코드를 PTX로 직접 컴파일하는 실험적 Rust-to-CUDA 백엔드로 소개했습니다.1
핵심은 문법이 아니라 GPU 코드의 소유권이다
공개된 저장소 설명에 따르면 cuda-oxide는 커스텀 rustc 코드 생성 백엔드입니다. #[kernel]이 붙은 Rust 함수를 CUDA PTX로 컴파일하고, host 코드와 device 코드를 같은 파일에서 cargo oxide build로 함께 빌드하는 단일 소스 흐름을 지향합니다.2
컴파일 경로도 흥미롭습니다. Rust 소스가 MIR을 거쳐 Pliron 기반 IR, LLVM IR, 최종 PTX로 내려갑니다. 즉 Rust 코드를 CUDA C++로 변환하는 트랜스파일러라기보다, Rust 컴파일러 파이프라인 안에서 GPU 타깃을 다루려는 시도에 가깝습니다.2
실무적으로 중요한 부분은 "커널도 Rust 리뷰 문화 안으로 들어올 수 있다"는 점입니다. 제네릭, 캡처가 있는 클로저, 사용자 정의 구조체·enum, 패턴 매칭 같은 Rust 기능을 커널 쪽에서 활용할 수 있고, cuda-core, cuda-async 같은 host-side 런타임도 함께 제공됩니다.2
다만 "safe-ish"라는 표현을 과대해석하면 안 됩니다. GPU 병렬 실행의 데이터 레이스, 동기화, 메모리 계층 문제는 언어만 바꾼다고 사라지지 않습니다. Rust 타입 시스템이 줄여줄 수 있는 오류는 분명 있지만, SIMT 프로그래밍 자체의 난이도는 여전히 남습니다.
먼저 이득을 볼 프로젝트는 '작은 커스텀 커널'이다
cuda-oxide가 당장 빛날 가능성이 큰 영역은 cuBLAS를 대체하는 거대한 선형대수 라이브러리가 아닙니다. Rust 기반 시스템 안에 작지만 자주 호출되는 커스텀 커널이 있고, 그 커널 때문에 C++ 빌드·FFI·소유권 경계가 생기는 프로젝트입니다.
예를 들면 시뮬레이션, 데이터 전처리, 커스텀 연산자, 연구용 프로토타입, Rust로 작성된 inference/runtime 주변 로직이 여기에 들어갑니다. 이 경우 최고 성능보다 "커널을 같은 언어, 같은 패키지, 같은 리뷰 흐름 안에서 관리한다"는 장점이 더 클 수 있습니다.
프로젝트 예제도 꽤 넓습니다. 저장소에는 vecadd, 캡처 클로저를 쓰는 host_closure, 제네릭 커널, async 실행, cross-crate kernel 등이 포함되어 있고, 총 46개 예제가 제공됩니다.2 B200에서 GEMM 예제가 868 TFLOPS, cuBLAS 대비 58% 수준을 기록했다는 수치도 공개되어 있습니다.2 다만 이는 "알파 컴파일러가 이미 cuBLAS를 대체한다"는 뜻이 아니라, 저수준 CUDA 기능까지 노출하려는 방향성을 보여주는 신호로 보는 편이 맞습니다.
그래도 CUDA C++, cuBLAS, 기존 바인딩을 버릴 때는 아니다
반론도 분명합니다. 프로덕션 ML, 대규모 행렬 연산, 이미 최적화된 수치 라이브러리 중심 워크로드라면 지금은 cuBLAS, cuDNN, CUTLASS, Triton, CUDA C++ 생태계가 여전히 더 안전한 선택입니다. 성능뿐 아니라 profiler, debugger, 문서, 실패 사례, 운영 경험이 쌓여 있기 때문입니다.
cuda-oxide 자체도 현재 alpha이며, 버그·미완성 기능·API 변경 가능성을 명시하고 있습니다.2 요구 사항도 가볍지 않습니다. Rust nightly, CUDA Toolkit 12.x 이상, LLVM 21 이상, Clang/libclang, Linux 환경이 필요합니다.2 CI에 바로 넣기에는 부담이 있는 조합입니다.
또 하나 조심할 점은 이름 혼동입니다. docs.rs에 있는 기존 cuda-oxide 크레이트는 CUDA를 다루는 safe wrapper 성격이며, 문서에서 "Rust를 PTX로 컴파일하지 않는다"고 설명합니다.3 이번에 화제가 된 것은 NVlabs의 Rust-to-CUDA compiler backend입니다. 검색 결과만 보고 같은 프로젝트로 착각하면 안 됩니다.
실험은 하되, 로드맵을 걸지는 말자
지금 가장 현실적인 접근은 "한 개의 작은 커널"을 포팅해보는 것입니다. 벡터 연산처럼 사소한 예제가 아니라, 실제 코드베이스에서 C++/CUDA 경계를 만들고 있는 커스텀 커널 하나가 좋습니다.
평가 기준은 네 가지면 충분합니다.
기존 CUDA C++ 결과와 bit-level 또는 허용 오차 내에서 일치하는가
생성된 PTX와 실행 시간이 납득 가능한가
디버깅과 profiling 흐름이 팀에 받아들여질 만한가
Rust 코드베이스 안에 넣었을 때 리뷰·테스트·배포 비용이 줄어드는가
여기서 성능만 보면 판단을 그르칠 수 있습니다. cuda-oxide의 초기 가치는 "최고 성능을 즉시 얻는 것"보다 "GPU 커널의 소유권을 Rust 팀 안으로 가져올 수 있는가"에 있습니다.
따라서 지금 신경 써야 할 사람은 CUDA C++ 전문가 전체가 아니라, Rust 중심 시스템을 만들면서 GPU 커널 때문에 언어와 빌드 체인이 갈라진 팀입니다. 실험해볼 가치는 충분합니다. 하지만 production track에 올릴지는 컴파일러의 성숙도, 지원되는 Rust 기능의 범위, NVIDIA 최신 아키텍처 대응, 그리고 팀의 디버깅 가능성을 보고 천천히 판단해야 합니다.
참고
2GitHub - NVlabs/cuda-oxide: cuda-oxide is an experimental Rust-to-CUDA compiler
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.