Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 릴리스 노트 헤드라인에 없던 한 줄
nvptx64 타깃이란 무엇인가
무엇이 바뀌었나 — 정확한 숫자
왜 잘라냈나 — 세 개의 구체적인 결함
커트라인은 왜 하필 CUDA 11인가
누가 깨지고, 무엇을 해야 하나
그런데 이걸 실제로 쓰는 사람이 있나 — 2026년 Rust-on-GPU 지형
정직한 트레이드오프 — 그리고 언제 쓰지 말아야 하나
마치며
참고 자료

들어가며 — 릴리스 노트 헤드라인에 없던 한 줄

Rust 1.97.0은 2026년 7월 9일에 나왔습니다. 릴리스 노트의 헤드라인은 세 개였습니다 — v0 심볼 맹글링의 stable 기본값 승격, Cargo의 build.warnings 설정, 그동안 숨어 있던 링커 출력의 노출. 이 셋은 며칠 전 글에서 이미 정리했습니다.

그런데 같은 릴리스의 Platform Support 섹션에는 헤드라인에 오르지 못한 한 줄이 더 있었습니다.

nvptx64-nvidia-cuda: drop support for old architectures and old ISAs   (PR #152443)

재미있는 건 이겁니다. 헤드라인 세 개는 전부 하위 호환을 지키는 변화였습니다. 심볼 맹글링이 바뀌어도 코드는 그대로 빌드되고, 경고 설정은 옵트인이고, 링커 출력은 그냥 더 보일 뿐입니다. 반면 이 한 줄은 1.97에서 유일하게 무언가를 실제로 깨뜨리는 변화입니다. 깨지는 사람이 아주 적을 뿐이죠.

그리고 이 변화의 배경에는 "Rust로 GPU 커널을 짠다"는, 2026년 들어 갑자기 조용하지 않게 된 이야기가 깔려 있습니다.

nvptx64 타깃이란 무엇인가

nvptx64-nvidia-cuda는 rustc가 NVIDIA GPU용 코드를 뱉는 타깃입니다. 여기서 나오는 건 기계어가 아니라 PTX입니다 — NVIDIA의 가상 ISA로, CUDA 드라이버가 런타임에 실제 GPU의 SASS로 JIT 컴파일합니다. rustc는 LLVM의 NVPTX 백엔드를 통해 이 PTX를 생성합니다.

rustc 플랫폼 지원 문서 기준으로 이 타깃의 성격은 이렇습니다.

Tier 2 타깃이고, 메인테이너는 @kjetilkjeka 한 명입니다.
no_std 타깃입니다. 기본 링커는 llvm-bitcode-linker이고, PTX를 얻으려면 crate-type을 cdylib으로 빌드합니다.
커널 함수는 extern "ptx-kernel"로 선언합니다.
문서의 빌드 예시는 nightly를 씁니다.

$ RUSTFLAGS='-Ctarget-cpu=sm_89' cargo +nightly rustc \
    --target=nvptx64-nvidia-cuda -Zbuild-std=core --crate-type=cdylib

Tier 2가 무엇을 보장하는지는 타깃 티어 정책에 정확히 적혀 있습니다 — "Rust's continuous integration checks that tier 2 targets will always build, but they may or may not pass tests." 즉 빌드는 보장하지만 테스트 통과는 보장하지 않습니다. Tier 1이 "빌드 + 테스트 통과"를 모두 보장하는 것과의 차이가 여기입니다. 이 문장을 기억해 두십시오. 아래에서 왜 결함이 쌓였는지를 설명하는 열쇠입니다.

무엇이 바뀌었나 — 정확한 숫자

2026년 5월 1일, 타깃 메인테이너인 Kjetil Kjeka가 예고 글을 올렸습니다. 글의 표현 그대로 새 최소 사양은 이렇습니다.

"The new minimum supported versions will be: PTX ISA 7.0 (requires a CUDA 11 driver or newer) SM 7.0 (GPUs with compute capability below 7.0 are no longer supported)"

rustc 문서의 표로 옮기면 변화의 폭이 한눈에 들어옵니다.

Rust 버전	SM 최소	PTX ISA 최소
~ 1.96	2.0	3.2
1.97 ~	7.0 (Volta+)	7.0 (CUDA 11+)

SM 2.0에서 7.0으로. 이건 점진적 조정이 아니라 한 번에 세대를 통째로 걷어낸 것입니다. 예고 글의 표현으로는 "Until now, Rust has supported emitting PTX for a wide range of GPU architectures and PTX ISA versions."였고, 그 "wide range"가 이제 Volta 이후로 좁혀졌습니다.

컴퓨트 능력 번호와 아키텍처 이름의 대응은 5.x가 Maxwell, 6.x가 Pascal, 7.0이 Volta입니다. 그러니까 잘려 나간 건 Maxwell과 Pascal 전체입니다 — NVIDIA의 레거시 GPU 목록 기준으로 GTX 1080(6.1), Tesla P100(6.0), Jetson TX2(6.2) 같은 것들입니다. Tesla V100과 TITAN V가 7.0으로 살아남는 첫 세대입니다.

참고로 NVIDIA의 현행 GPU 목록은 이미 7.5부터 시작하고, 그 아래는 레거시 페이지로 넘어가 있습니다. Rust가 그은 7.0 선은 NVIDIA가 "현행"이라 부르는 선보다 오히려 한 칸 아래입니다.

왜 잘라냈나 — 세 개의 구체적인 결함

여기가 이 변화의 진짜 내용입니다. 예고 글은 이유를 이렇게 요약합니다.

"In practice, several defects existed that could cause valid Rust code to trigger compiler crashes or miscompilations."

유효한 Rust 코드가 컴파일러 크래시나 잘못된 컴파일을 일으켰다는 뜻입니다. miscompilation은 조용히 틀린 코드를 뱉는 것이니, 크래시보다 나쁩니다.

"several defects"가 무엇인지는 예고 글에는 없지만, 이 변경을 통과시킨 컴파일러 팀 MCP #965에 구체적으로 적혀 있습니다. 2026년 2월 1일에 열려 major-change-accepted로 처리된 제안이고, 근거로 든 이슈는 셋입니다.

rust-lang/rust#147672 — PTX ISA 7.0 미만에서 디버그 심볼 생성에 LLVM 쪽 제약이 있습니다.
rust-lang/rust#150515 — SM 7.0보다 오래된 아키텍처에서 아토믹 순서(atomic ordering)가 충분히 지원되지 않습니다.
rust-lang/rust#141468 — PTX ISA 버전 체계가 Rust의 target-feature 메커니즘과 맞물리지 않습니다.

세 번째부터 보면 성격이 드러납니다. Rust의 -C target-feature는 "이 기능이 있다/없다"의 집합 모델입니다. 그런데 PTX ISA 버전은 집합이 아니라 선형적인 버전 번호입니다. 두 모델이 애초에 어긋나 있고, 지원 범위가 넓을수록 이 어긋남이 만들어내는 조합 폭발도 커집니다.

하지만 핵심은 두 번째입니다. MCP의 근거를 그대로 옮기면, SM 7.0 미만에서는 아토믹 순서가 충분히 지원되지 않고 — SM 7.0 이상은 공식 보장을 받지만 그 이전은 best-effort라는 것입니다. 이게 왜 Rust에게 치명적이냐면, Rust의 메모리 모델에서 core::sync::atomic의 acquire/release 의미론은 선택 사항이 아니기 때문입니다. C++ 쪽에서라면 "그 GPU에선 아토믹 쓰지 마세요"로 넘어갈 수 있는 문제가, 언어 차원에서 순서 보장을 약속한 Rust에서는 언어의 약속이 깨지는 문제가 됩니다. 잘못된 컴파일이 나온다는 말이 바로 이 뜻입니다. (참고로 Volta는 워프 내 독립 스레드 스케줄링을 도입한 세대이기도 합니다 — SM 7.0이 커트라인이 된 게 우연은 아닙니다.)

즉 이건 "오래된 하드웨어 정리"가 아니라 지킬 수 없는 약속을 걷어낸 것입니다. 예고 글의 문장도 그렇게 읽힙니다 — "Raising the baseline addresses these issues and enables more complete support for the remaining supported hardware." 넓고 부서진 지원보다, 좁고 온전한 지원을 택한 겁니다.

그리고 이건 앞서 본 Tier 2의 정의와 정확히 이어집니다. 빌드는 CI가 지키지만 테스트 통과는 보장하지 않는 타깃에서, 실제로 하드웨어를 물려 돌려보지 않은 오래된 아키텍처의 결함이 몇 년간 조용히 쌓여 있었던 것입니다.

커트라인은 왜 하필 CUDA 11인가

MCP가 버전 선택의 근거로 든 문장은 이겁니다 — "CUDA versions older than 12 are end-of-life, and PTX ISA 7.0 is supported starting with CUDA 11.0."

읽어 보면 두 문장이 서로 다른 선을 가리킵니다. EOL 논리만 따르면 커트라인은 CUDA 12여야 하는데, 실제로 잡은 건 CUDA 11(PTX ISA 7.0)입니다. 즉 EOL 논리가 허용하는 것보다 한 단계 보수적으로 잡았습니다. 결함을 없앨 만큼은 올리되, 필요 이상으로 자르지는 않은 선택으로 보입니다.

MCP는 NVIDIA 쪽 현황도 근거로 함께 적었습니다 — CUDA 13은 SM 7.5~~12.1을, CUDA 12.9는 SM 5.0~~12.1을 지원합니다. 흥미로운 대목입니다. Rust가 잡은 SM 7.0 커트라인은 최신 CUDA 13이 이미 잘라낸 선(7.5)보다도 오히려 관대합니다.

누가 깨지고, 무엇을 해야 하나

예고 글은 이렇게 안내합니다.

"If you do not specify -C target-cpu, the new default will be sm_70, and your build should continue to work (but will no longer be compatible with pre-Volta GPUs)."

"If you currently specify an older -C target-cpu (for example, sm_60), you will need to either: remove that flag and let it default to sm_70, or update it to sm_70 or a newer architecture."

정리하면 이렇습니다.

-C target-cpu 를 안 준다        -> 기본값이 sm_70 으로 바뀜. 빌드는 통과.
                                   단 결과물이 pre-Volta GPU에서 안 돎.
-C target-cpu=sm_60 을 준다     -> 플래그를 빼거나 sm_70 이상으로 올려야 함.
CUDA 10 이하 드라이버           -> 대상 아님.
Maxwell / Pascal GPU           -> 대상 아님. 옵트아웃 없음.

주목할 점: 옵트아웃이 없습니다. 예고 글에도 "옛 동작으로 되돌리는 플래그"는 없습니다. Pascal에 PTX를 뱉어야 한다면 방법은 1.96 이하 툴체인을 고정하는 것뿐이고, 그건 결함이 있는 채로 쓰겠다는 뜻이기도 합니다.

영향 범위에 대한 예고 글의 판단은 담담합니다.

"In this case, the most recent affected GPU architectures date back to 2017 and are no longer actively supported by NVIDIA."

"We therefore expect the overall impact of this change to be limited."

저자 본인의 추정이라는 점은 감안하되, 근거는 납득할 만합니다 — 영향받는 GPU 중 가장 최신 세대가 2017년 물건이고 NVIDIA 자신도 더는 적극 지원하지 않습니다.

그런데 이걸 실제로 쓰는 사람이 있나 — 2026년 Rust-on-GPU 지형

정직해질 대목입니다. Tier 2에 메인테이너 한 명, nightly 필요, no_std. 이 타깃을 날것으로 쓰는 사람은 많지 않습니다. 그러면 왜 이 변화가 의미가 있을까요.

2026년 들어 Rust로 GPU를 다루는 판이 갑자기 붐볐기 때문입니다. Rust CUDA 프로젝트가 정리한 생태계 지도를 보면 접근법이 이렇게 갈립니다.

cuda-oxide — rustc 코드젠 백엔드로 NVIDIA PTX/SASS를 노림. 설계 중심은 "CUDA를 Rust로 가져오기"(커널 작성, 디바이스 인트린식, SIMT 실행 모델).
rust-cuda — rustc_codegen_nvvm을 통해 rustc → NVVM IR → PTX. 설계 중심은 "Rust를 GPU로 가져오기" — 디바이스 위에서의 async/.await 같은 Rust 편의성.
Rust-GPU — SPIR-V로 가는 그래픽스 지향. Vulkan/Metal/DirectX. 벤더 간 이식성이 중심.
CubeCL — 내장 DSL + JIT 런타임. CUDA/ROCm/WGPU를 한 커널로. proc-macro 방식이라 rustc 백엔드가 아님.
std::offload — nightly 언어 기능. LLVM offload 런타임으로 CPU 루프를 가속기로 암묵적으로 넘김.
cudarc — 안전한 CUDA 드라이버 바인딩. 커널은 딴 데서 짜고 호스트 쪽만 Rust.
wgpu — WebGPU API의 Rust 구현. 스택의 층 자체가 다름.

이 중 가장 큰 뉴스는 cuda-oxide입니다. NVIDIA Labs가 직접 낸 Rust→CUDA 컴파일러이고, 저장소 설명 그대로 "an experimental Rust-to-CUDA compiler that lets you write (SIMT) GPU kernels in safe(ish), idiomatic Rust"입니다. DSL도 바인딩도 아니고 표준 Rust를 PTX로 바로 컴파일합니다. 파이프라인은 Rust → MIR → Pliron IR → LLVM IR → PTX이고, 라이선스는 Apache-2.0입니다.

GPU 회사가 자기 플랫폼용 Rust 컴파일러를 직접 낸다는 것 — 이게 2026년의 신호입니다. 그리고 이런 도구들이 실제로 굴러가려면 그 아래의 PTX 생성이 정확해야 합니다. 베이스라인 상향은 바로 그 바닥을 다지는 작업입니다.

바닥이 부실했다는 증거는 Rust CUDA 프로젝트 자신의 문서에 있습니다. 그동안 "유일하게 쓸 만한 선택지는 LLVM PTX 백엔드를 쓰는 것"이었는데 그게 "많은 흔한 Rust 연산에서 유효하지 않은 PTX를 생성"했다고, 이 프로젝트가 존재하는 이유를 그렇게 설명합니다. 다른 경로를 파야 했을 만큼 기본 경로가 못 미더웠다는 뜻입니다. 1.97의 정리는 그 기본 경로를 좁히는 대신 믿을 만하게 만드는 방향입니다.

정직한 트레이드오프 — 그리고 언제 쓰지 말아야 하나

이 변화 자체는 좋은 거래입니다. 아무도 하드웨어를 물려 검증하지 않는 오래된 아키텍처에 대해, 지킬 수 없는 아토믹 보장을 약속하고 조용히 틀린 코드를 뱉느니, 지원 범위를 좁히고 남은 하드웨어에서 제대로 맞는 편이 낫습니다. 호환성보다 정확성을 택한 것이고, 정확성이 실제로 깨져 있었으니 정당합니다.

그렇다고 지금 Rust로 GPU 커널을 짜야 한다는 뜻은 아닙니다. 정직하게 적으면 이렇습니다.

nvptx64 타깃은 Tier 2입니다 — 빌드만 보장되고 테스트 통과는 보장되지 않습니다. 문서의 빌드 예시부터 nightly입니다.
no_std이고, 타깃 고유의 제약도 있습니다. 예컨대 static 초기화식이 순환을 이루면 컴파일러가 거부합니다(static A: Foo = Foo(&A);는 에러).
NVIDIA가 낸 cuda-oxide조차 스스로를 이렇게 규정합니다 — "in an early stage (alpha) and under active development: you should expect bugs, incomplete features, and API breakage." 게다가 특정 nightly(nightly-2026-04-03)에 고정돼 있고, CUDA 12.x 이상과 Linux를 요구합니다.

그래서 대부분의 경우 답은 이렇습니다. GPU를 Rust에서 쓰고 싶을 뿐이라면, 커널은 CUDA C++로 짜고 호스트 쪽만 cudarc 같은 안전한 드라이버 바인딩으로 붙이십시오. 이건 지금 프로덕션에서 돌아가는 조합입니다. 커널까지 Rust로 짜는 건 아직 연구·실험·단일 소스 코드베이스에서 호스트와 디바이스가 타입을 공유해 얻는 이득이 클 때의 선택지입니다.

Maxwell이나 Pascal이 아직 현역이라면 — 판단은 둘 중 하나입니다. 툴체인을 1.96 이하로 고정하거나(결함을 안고 가는 것), Rust로 커널을 짜지 않거나. 사실 후자가 대부분의 경우 이미 답이었습니다.

한 가지 덧붙이면, cuda-oxide가 애초에 CUDA 12.x 이상을 요구한다는 점이 이 변화의 성격을 잘 보여줍니다. 생태계는 이미 CUDA 11보다 앞에 가 있었고, 컴파일러의 베이스라인이 뒤늦게 그 자리로 따라간 것에 가깝습니다.

마치며

Rust 1.97의 nvptx64 베이스라인 상향은 릴리스 노트 한 줄짜리 변화입니다. 실제 내용은 이렇습니다 — SM 2.0/PTX 3.2에서 SM 7.0/PTX 7.0으로, Maxwell과 Pascal을 걷어내고, 대신 남은 하드웨어에서 아토믹 순서와 디버그 심볼이 제대로 동작하게 만드는 것. 옵트아웃은 없고, 영향은 저자 판단으로 제한적입니다.

이 조용한 정리를 굳이 길게 읽을 가치가 있는 이유는 그 배경입니다. 몇 년간 아무도 안 보던 Tier 2 타깃에 결함이 쌓여 있었고, 2026년 들어 그 타깃 위로 진짜 도구들이 — NVIDIA 자신이 낸 컴파일러를 포함해 — 올라오기 시작하면서 바닥을 볼 이유가 생겼습니다. 지원 범위를 넓히는 게 아니라 좁혀서 정확하게 만드는 쪽을 택한 것은, 그 위에 뭔가를 올릴 생각이 있는 사람들의 결정처럼 보입니다.

다만 결론은 담담합니다. Rust-on-GPU는 "불가능"에서 "관리되기 시작함"으로 옮겨 왔을 뿐, "프로덕션 준비 완료"는 아닙니다. 알파라고 적힌 문서를 그대로 믿으십시오. 그리고 대부분의 사람에게 1.97에서 해야 할 일은 여전히 rustup update stable 하나뿐입니다.