엔비디아, CUDA 커널을 러스트로 — cuda-oxide·cutile-rs 두 갈래 공식 지원 | 뉴스

엔비디아가 러스트로 GPU 커널을 작성하는 공식 경로를 열었다. 9월 8일 기술 블로그로 처음 공개된 CUDA Rust는 두 갈래로 구성된다. 하나는 기존 CUDA 프로그래밍 모델을 러스트 바인딩으로 노출하는 방향이고, 다른 하나는 네이티브 러스트 커널을 PTX(엔비디아 GPU의 저수준 어셈블리)로 직접 컴파일하는 방향이다.

핵심 메시지는 위상 변화다. 그동안 러스트 GPU 지원은 커뮤니티 프로젝트 영역이었다. 이제 엔비디아가 1급 도구로 취급하고 2027년 이후까지 성숙시키겠다고 명시했다.

나는 몇 해 전 러스트에서 GPU를 써 보려다 포기한 적이 있다. 바인딩은 있었지만 유지보수가 끊겼고, 빌드 스크립트가 CUDA 툴킷 버전에 따라 매번 다르게 깨졌다. 결국 커널만 C++로 쓰고 러스트에서 FFI로 부르는, 아무도 행복하지 않은 구조로 마무리했다. 이번 발표가 의미 있는 건 그 지점을 공식이 책임지겠다고 말했기 때문이다.

두 갈래가 각각 무엇인가

접근	성격	적합한 팀
CUDA 모델을 러스트로 노출	기존 CUDA 개념(그리드·블록·스트림)을 그대로 쓰되 호스트 측을 러스트로	이미 CUDA 자산이 있고 호스트 코드를 러스트로 옮기려는 팀
러스트 커널 → PTX 직접 컴파일	커널 자체를 러스트로 작성해 PTX로 낮춤. C++ 경유 없음	러스트 단일 언어로 스택을 통일하려는 신규 프로젝트

둘의 차이는 "어디까지 러스트로 쓰느냐"다. 전자는 경계를 안전하게 만드는 데 집중하고, 후자는 커널 내부의 표현력까지 러스트로 가져온다. 후자가 더 매력적이지만, 커널 최적화에서 필요한 인트린직·인라인 PTX·워프 수준 프리미티브가 얼마나 덮여 있느냐가 실사용을 가른다.

PTX가 뭔가 PTX는 엔비디아 GPU의 가상 ISA다. CUDA C++ 컴파일러도 최종적으로는 PTX를 거쳐 실제 아키텍처용 SASS로 내려간다. 러스트 커널을 PTX로 컴파일한다는 건 C++ 경유 없이 동일한 지점에 합류한다는 뜻이다.

왜 러스트인가 — 커널에서 메모리 안전이 의미하는 것

GPU 커널에서 가장 흔한 버그는 범위를 벗어난 인덱싱과 공유 메모리 경쟁이다. 호스트 코드와 달리 커널은 크래시가 친절하게 알려 주지 않는다. 잘못된 인덱스가 이웃 스레드의 데이터를 조용히 덮고, 결과는 그럴듯한 숫자로 나온다. 며칠 뒤 학습 손실 곡선이 이상하다는 걸 눈치챌 때쯤이면 원인을 역추적하기 어렵다.

러스트가 잡아 주는 것

호스트–디바이스 버퍼 수명 관리 오류
널·해제 후 사용 같은 포인터 실수
빌드 재현성(카고 기반 의존성 관리)
에러 처리 누락(Result 강제)

러스트가 못 잡는 것

커널 내부 인덱스 계산 오류
워프 다이버전스·뱅크 충돌 같은 성능 문제
동기화 누락으로 인한 논리적 경쟁
메모리 접근 패턴에서 오는 대역폭 병목

오해하면 안 되는 지점이 여기다. 러스트로 쓴다고 커널이 빨라지지 않는다. 성능은 여전히 접근 패턴·점유율·공유 메모리 사용에서 결정된다. 러스트가 주는 건 속도가 아니라 리팩터링 용기다. 컴파일러가 경계를 지켜 주면 커널을 더 자주 갈아엎을 수 있고, 그게 결과적으로 성능으로 이어진다.

생태계 관점 — 이 발표가 겨냥한 진짜 대상

AI 인프라 스택의 하단은 지난 3년간 조용히 러스트로 이동해 왔다. 추론 서버, 토크나이저, 벡터 인덱스, 데이터 로더, 에이전트 런타임까지 러스트로 쓰인 컴포넌트가 늘었다. 그 스택에서 GPU 커널만 C++ 섬으로 남아 있으면 빌드·배포·디버깅이 두 세계로 쪼개진다. 엔비디아가 보는 건 그 경계 비용이다.

지금 도입을 검토한다면

✓프로덕션 커널을 옮기기보다, 새 커널 한 개를 러스트로 써 보며 툴체인 성숙도를 측정할 것

✓필요한 인트린직(워프 셔플, 텐서 코어 접근 등)이 커버되는지 먼저 확인

✓프로파일링 도구(Nsight 계열)에서 러스트 커널의 심볼이 제대로 보이는지 확인

✓CI에서 툴킷 버전 고정 — 초기 단계 프로젝트는 버전 민감도가 높다

✓C++ 커널과 성능을 반드시 직접 측정해 비교할 것. 발표 자료가 아니라 내 워크로드로

냉정하게 — 지금 당장 갈아탈 이유는 아직 약하다

엔비디아 스스로 CUDA C++와 CUDA Python이 성숙한 엔터프라이즈 툴체인이고 CUDA Rust는 2027년 이후까지 성숙시켜 갈 대상이라고 밝혔다. 이건 마케팅 문구가 아니라 솔직한 상태 표현으로 읽는 게 맞다. 새 언어 지원의 초기 1~2년은 문서 공백, 예제 부족, 엣지 케이스 버그의 시간이다. 리스크를 감당할 수 있는 팀이 먼저 들어가서 이슈를 갈아 주면, 그 다음 팀이 편해진다.

출처

NVIDIA Technical Blog, "Introducing CUDA Rust: Two Tracks for Writing GPU Kernels" (2026-09-08) — https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels/
NVIDIA Developer Forums 토론 스레드 — https://forums.developer.nvidia.com/t/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels/382704
Hacker News 토론 (2026-09-17) — https://news.ycombinator.com/item?id=49724881

자주 묻는 질문

CUDA Rust로 무엇을 할 수 있나요?

러스트로 GPU 커널을 작성해 PTX로 컴파일하거나, 기존 CUDA 프로그래밍 모델을 러스트 바인딩으로 사용할 수 있습니다. 호스트 코드와 커널을 한 언어로 통일할 수 있다는 점이 가장 큰 변화입니다.

CUDA C++보다 빠른가요?

언어 선택만으로 빨라지지는 않습니다. GPU 성능은 메모리 접근 패턴, 점유율, 공유 메모리 사용, 워프 다이버전스에서 결정되며 이는 언어와 무관합니다. 러스트가 주는 이점은 메모리 안전성과 빌드 재현성, 그리고 그로 인한 리팩터링 용이성입니다.

기존 CUDA C++ 코드를 다시 써야 하나요?

아닙니다. 두 갈래 중 하나가 기존 CUDA 모델을 러스트에서 사용하는 방식이라, 커널은 그대로 두고 호스트 측만 옮기는 점진적 전환이 가능합니다. 검증된 프로덕션 커널을 서둘러 포팅할 이유는 현재로선 크지 않습니다.

프로덕션에 바로 써도 될까요?

권하지 않습니다. 엔비디아도 CUDA C++·CUDA Python이 성숙한 선택지이며 CUDA Rust는 2027년 이후까지 성숙시켜 나갈 대상이라고 밝혔습니다. 신규 실험 워크로드나 비핵심 커널부터 시작해 툴체인 안정성을 직접 측정해 보는 접근이 안전합니다.

AMD GPU나 다른 벤더에서도 쓸 수 있나요?

CUDA Rust는 엔비디아 플랫폼 대상입니다. 벤더 중립을 원한다면 wgpu·Vulkan 컴퓨트·SPIR-V 경로나 이식성 있는 커널 DSL을 검토해야 합니다. 다만 이식성을 택하면 텐서 코어 같은 벤더 고유 기능 활용도가 떨어지는 트레이드오프가 있습니다.