엔비디아가 2026년 9월 러스트로 GPU 커널을 네이티브하게 작성하는 방향에 힘을 싣겠다고 밝혔다. 오랜 기간 성숙해 온 CUDA C++와 CUDA Python은 그대로 발전시키되, 새로 공개한 CUDA Rust는 2027년 이후까지 계속 다듬어 나가겠다는 계획이다. 이는 실험적 곁가지가 아니라 별도의 장기 트랙으로 취급하겠다는 신호에 가깝다.
배경에는 AI 시스템 계층 전반이 러스트로 옮겨가는 흐름이 있다. 추론 엔진, 서빙 인프라, 드라이버, 에이전트 런타임처럼 모델과 기법 변화에 따라 끊임없이 다시 쓰이는 영역일수록, 컴파일 시점에 통째로 버그 부류를 잡아내면서도 성능을 포기하지 않는 러스트의 장점이 크게 작동한다. 엔비디아 자신도 Nova 리눅스 드라이버를 러스트로 작성했고, NVIDIA Dynamo는 러스트 코어 위에 서 있으며, NVTX에는 러스트 바인딩이 있다. 유독 GPU 커널만이 예외였다. 러스트에서 커널을 실행(launch)할 수는 있었지만, 커널 본체 자체는 다른 언어로 써야 하는 경우가 많았다. CUDA Rust는 바로 이 공백을 메운다. 이제 커널을 러스트로 작성해 PTX로 직접 컴파일할 수 있고, 다른 언어 코드를 감싸는 래퍼가 아니다.
두 트랙: SIMT와 타일
러스트 지원은 CUDA 자체의 두 프로그래밍 모델을 그대로 따라 두 갈래로 나뉜다. 하나는 이미 CUDA C++나 numba-cuda에서 쓰던 SIMT 모델로, 스레드 하나가 무엇을 하는지 정의하고 수천 개를 띄우는 방식이다. 다른 하나는 비교적 새로운 타일(Tile) 모델로, 데이터 한 타일이 무엇을 하는지만 기술하면 Tile IR 컴파일러가 나머지를 처리한다. 엔비디아는 새로 시작한다면 먼저 타일을 잡으라고 권한다. 어떤 타일을 각 아키텍처에 어떻게 매핑할지를 컴파일러가 결정하므로 소스 코드에 아키텍처별 선택이 박히지 않기 때문이다. 반대로 메모리나 스레드를 직접 통제해야 할 때는 SIMT로 내려가면 된다. 어떤 언어를 쓸지와 어떤 모델을 쓸지는 별개의 질문이며, 두 프로젝트는 이미 스택이 러스트인 경우를 위한 선택지다. 향후 언어 간 상호운용도 지원할 계획이라 한쪽을 고른다고 다른 쪽이 막히지는 않는다.
안전성을 타입으로 증명하는 방식
러스트 트랙의 핵심 매력은 GPU 프로그래밍에서 고질적인 메모리 별칭(aliasing) 오류를 컴파일 단계에서 걷어낸다는 점이다. 수천 개의 스레드가 순서 보장 없이 같은 버퍼에 접근할 때, 두 스레드가 같은 주소에 닿고 그중 하나가 쓰기라면 실행 순서가 결과를 좌우한다. 이런 버그는 재현이 잘 안 되고 테스트를 통과한 뒤 운영 환경에서 터진다. SIMT 트랙인 cuda-oxide는 커널 출력 버퍼를 자기 입력으로 넘기는 코드를 아예 컴파일 거부한다(cannot borrow as mutable ... also borrowed as immutable). 여기서는 DisjointSlice라는 전용 타입이 하나의 가변 대여를 스레드별 조각으로 쪼개 각 스레드에 자기 원소만 배타적으로 넘긴다. 인덱스도 정수가 아닌 전용 타입으로 반환되고, 범위 초과는 메모리 오류가 아니라 Option 분기로 처리된다. 실행 역시 #[launch_contract]로 선언한 계약을 검증한 뒤 안전한 호출 경로에만 통행증을 내주는 방식이다.
타일 트랙인 cutile-rs는 한 단계 더 높은 곳에서 같은 주장을 편다. 호스트에서 .partition([128])을 호출하면 각 타일이 128개짜리 청크를 배타적으로 소유하고, 이 소유권이 실행 경계를 넘어 텐서를 따라간다. 별도의 DisjointSlice 없이 러스트의 &mut가 이미 보장하는 배타성만으로 충분한 셈이다. 파티션 하나가 배타성 확보, 실행 형상(1,024÷128=8타일 그리드) 확정, 타일 폭 공급까지 세 가지 일을 동시에 한다. 실행 자체도 게을러서, ones·zeros·커널 호출·호스트 복사까지 모두 지연 기록되었다가 .sync_on(&stream) 시점에 한 번에 제출된다. 엔비디아는 소유권이 실행 경계를 넘어 추적되는 cutile 쪽 보증이 호출별로 검사하는 cuda-oxide보다 더 강하다고 평가한다.
안전함의 대가와 현재 성숙도
타일이 안전한 이유는 공유 메모리도, 스레드 인덱싱도 개발자에게 노출하지 않기 때문이다. 타일 블록은 하나의 논리적 스레드라서 경합을 일으킬 스레드가 없다. 그러나 그 통제권을 통째로 넘긴다는 점이 곧 트레이드오프다. SIMT는 통제권을 유지하는 대신, 현재 공유 메모리 접근에 unsafe가 필요하다. 공유 메모리는 빠른 SIMT 커널의 근간이므로 이 경로를 안전하게 만드는 작업이 진행 중이다. 요구 환경도 다르다. cuda-oxide는 리눅스와 컴퓨트 능력 8.0 이상 GPU, CUDA 12.x 이상, clang/libclang, 그리고 고정된 나이틀리 툴체인을 요구하며, cutile-rs는 CUDA 13.3과 안정판 러스트 1.89 이상이면 충분하고 나이틀리도 자체 LLVM도 필요 없다.
두 프로젝트 모두 초기 단계이고 아직 프로덕션급은 아니다. cuda-oxide는 이른 알파 수준이고, cutile-rs는 좀 더 나아가 crates.io에 공개되어 허깅페이스의 Grout 추론 엔진과 mistral.rs 등 엔비디아 외부에서도 이미 쓰인다. 커버리지는 불완전하고 API는 계속 바뀔 예정이다. 실무자 관점에서 지금 이것을 곧바로 도입하기보다는, 러스트로 통일된 스택을 지향하는 팀이 커널 계층까지 한 언어로 묶는 미래를 미리 실험해 볼 무대로 보는 편이 정확하다. 특히 나이틀리 툴체인 고정 요구처럼 진입 장벽이 남아 있다는 점, 그리고 rust-cuda·rust-gpu·CubeCL·cudarc 같은 선행 프로젝트 및 VectorWare 팀과의 협업 위에 이 작업이 놓여 있다는 점은 이 흐름이 엔비디아 단독이 아니라 러스트 생태계 전체와 맞물려 움직인다는 사실을 보여준다.