고성능 GPU 프로그래밍은 오랫동안 두 가지 가치 사이에서 타협을 강요받아 왔다. 하나는 실행 효율이고 다른 하나는 메모리 안전성이다. 수천 개의 스레드가 동시에 같은 메모리 공간을 넘나드는 대규모 병렬 환경에서 성능을 끌어내려면 개발자가 포인터와 메모리 전송을 직접 통제해야 했고, 그 과정에서 안전성은 뒷전으로 밀리기 일쑤였다. arXiv에 공개된 이 논문은 러스트(Rust) 컴파일러 자체에 GPU 오프로드 기능을 심어, 이 타협을 줄일 수 있음을 보여주려는 시도다.
왜 지금 러스트인가
러스트는 소유권(ownership) 모델을 통해 호스트 CPU에서 컴파일 시점에 메모리 안전성을 보장하는 언어로 자리 잡았다. 문제는 이 규율을 GPU로 그대로 가져오기가 쉽지 않았다는 점이다. 지금까지 GPU에서 러스트의 안전성을 살리려면 특정 벤더에 종속된 도메인 특화 언어(DSL)를 쓰거나, 아니면 안전성 검사를 우회하는 unsafe 원시 포인터로 빠져나가야 했다. 전자는 이식성을 잃고, 후자는 러스트를 쓰는 이유 자체를 무너뜨린다. 둘 다 만족스러운 답이 아니었던 셈이다.
논문이 제시하는 접근은 별도의 언어나 라이브러리를 얹는 대신 rustc(러스트 컴파일러)와 LLVM 백엔드에 GPU 컴파일 경로를 직접 내장하는 것이다. 저자들이 강조하는 핵심은 '제로 오버헤드'와 '멀티 벤더'다. 즉 안전성을 위해 성능을 깎지 않으면서, 엔비디아와 AMD 같은 서로 다른 하드웨어를 함께 겨냥한다는 것이다. 이를 위해 러스트의 타입 시스템과 소유권 정보, 그리고 엄격한 별칭 금지(strict aliasing, noalias) 보장을 활용해 호스트와 디바이스 사이의 데이터 전송을 관리하고 최적화한다. 여기서 noalias 정보는 특히 중요한데, 컴파일러가 '이 데이터 영역들은 서로 겹치지 않는다'고 확신할 수 있으면 그만큼 공격적인 최적화가 가능해지기 때문이다. 러스트의 소유권 규칙은 이런 보장을 언어 수준에서 자연스럽게 제공한다.
두 개의 세계를 잇는 문제
이 작업이 단순하지 않은 이유는 호스트(CPU)와 디바이스(GPU)가 서로 다른 타깃이기 때문이다. 논문은 벤더마다 다른 ABI(응용 이진 인터페이스) 하강(lowering) 과정에서 발생하는 불일치를 기술적 난점으로 지목한다. 같은 러스트 코드라도 CPU용으로 낮출 때와 GPU용으로 낮출 때 함수 호출 규약이나 메모리 배치가 어긋날 수 있다는 뜻이다. 저자들은 이를 다루기 위해 2패스(two-pass) 컴파일 파이프라인을 도입해, 개발자가 직접 지정한 메모리 이동과 컴파일러가 자동으로 생성한 메모리 이동을 모두 안전하게 처리하도록 했다. 데이터 전송이라는, GPU 프로그래밍에서 가장 실수가 잦고 성능에 민감한 지점을 컴파일러가 책임지도록 설계한 것이다.
성능 평가는 RAJAPerf 벤치마크로 이뤄졌다. 논문은 rustc 기반 방식이 GPU 커널에 대해 경쟁력 있는 LLVM IR을 생성했으며, 손으로 최적화한 네이티브 CUDA와 HIP C++ 기준선에 견줄 만한 커널 성능을 냈다고 밝힌다. 즉 안전성을 얻기 위해 성능을 크게 희생하지는 않았다는 것이 저자들의 주장이다. 다만 여기서 주의해서 읽어야 할 표현이 있다. '경쟁력 있는', '견줄 만한' 같은 서술은 특정 워크로드에서의 결과이지, 모든 상황에서 C++ 수작업 최적화를 넘어섰다는 뜻은 아니다.
한국의 실무자 관점에서 이 연구가 갖는 함의는 분명하다. 러스트가 시스템 프로그래밍과 인프라 영역으로 빠르게 확산되는 가운데, GPU 활용은 그동안 러스트 생태계의 약한 고리로 남아 있었다. 컴파일러에 오프로드가 내장되면, 별도의 벤더 SDK나 unsafe 코드에 의존하지 않고도 이식성 있는 GPU 코드를 작성할 길이 열린다. 특히 AI 추론, 시뮬레이션, 데이터 처리처럼 GPU를 쓰면서도 안정성이 중요한 분야에서 매력적인 선택지가 될 수 있다.
동시에 냉정하게 볼 지점도 있다. 이 결과는 아직 학술 논문 단계의 프레임워크이며, RAJAPerf라는 특정 벤치마크 위에서 측정된 것이다. LLVM의 오프로드 인프라나 rustc의 관련 기능이 프로덕션에서 안정적으로 쓰일 만큼 성숙했는지, 복잡한 실제 커널과 다양한 GPU 세대에서도 동일한 이식성과 성능이 유지되는지는 별개의 문제다. 논문은 접근의 타당성을 입증했을 뿐, 당장 실무에 투입 가능한 완성품을 제시한 것은 아니다. 그럼에도 '안전하거나 빠르거나' 중 하나를 고르라는 오래된 요구를 다시 검토하게 만든다는 점에서, 러스트로 GPU를 쓰려는 개발자라면 눈여겨볼 만한 방향 제시다.