GPU에서 Rust std를 쓴다고? VectorWare의 야심찬 시도와 현실적인 분석

솔직히 말해서, 처음 이 소식을 들었을 때 제 반응은 “굳이?”였습니다. GPU 프로그래밍의 핵심은 극한의 병렬 처리와 성능 최적화인데, 무거운 런타임이 연상되는 표준 라이브러리(Standard Library)를 얹는다니요. 하지만 VectorWare가 공개한 Rust’s Standard Library on the GPU 아티클을 뜯어보고, Hacker News의 반응들을 살펴보니 생각이 좀 바뀌었습니다. 이건 단순히 편의성을 넘어서 Heterogeneous Computing 의 패러다임을 바꾸려는 시도입니다.

오늘은 VectorWare가 발표한 기술의 핵심을 엔지니어 관점에서 깊게 파헤쳐 보고, 이것이 우리에게 어떤 의미가 있는지 가감 없이 이야기해보려 합니다.

왜 지금까지 GPU는 no_std였나?

Rust를 조금이라도 해보신 분들은 아시겠지만, Rust 라이브러리 계층은 크게 세 단계입니다.

  1. Core: 힙(Heap)도 없고 OS도 없는 가장 기초적인 단계.
  2. Alloc: 힙 할당이 추가된 단계.
  3. Std: OS 기능(파일, 네트워킹, 스레드 등)이 포함된 완전체.

지금까지 rust-cuda나 rust-gpu 같은 프로젝트들은 전부 #![no_std] 환경이었습니다. 당연하죠. GPU에는 운영체제(OS)가 없으니까요. 파일 시스템도 없고, 소켓도 없습니다. 그래서 우리는 GPU 커널을 짤 때마다 기존의 풍부한 Rust 생태계(Crates.io)를 거의 포기하고, 맨땅에 헤딩하듯 코드를 짜야 했습니다.

그런데 VectorWare가 이 제약을 깨버렸습니다.

핵심 기술: Hostcall (사실상 GPU를 위한 Syscall)

이들이 std를 구현한 방식이 꽤 흥미롭습니다. GPU 안에 OS를 심은 게 아니라, Hostcall 이라는 메커니즘을 만들었습니다. 쉽게 말해 GPU가 처리할 수 없는 작업(파일 쓰기, 네트워크 요청 등)을 CPU(Host)에게 “대신 해줘”라고 요청하는 RPC(Remote Procedure Call) 구조입니다.

아래 코드를 보시죠. 이게 GPU 위에서 돌아가는 코드입니다.

use std::io::Write;
use std::time::{SystemTime, UNIX_EPOCH};

#[unsafe(no_mangle)]
pub extern "gpu-kernel" fn kernel_main() {
    println!("Hello from VectorWare and the GPU!");
    
    // 파일 시스템 접근 (GPU -> Host 요청)
    let msg = format!("GPU에서 파일 생성 중... 🦀");
    std::fs::File::create("rust_from_gpu.txt")
        .unwrap()
        .write_all(msg.as_bytes())
        .unwrap();
}

println! 매크로와 File::create가 GPU 커널 안에서 자연스럽게 쓰입니다. 내부적으로는 다음과 같이 동작합니다.

  • libc Facade: Rust의 std는 보통 libc를 통해 OS와 통신합니다. VectorWare는 이 libc 호출을 가로채서 Hostcall로 변환합니다.
  • 비동기 처리: GPU가 멈추지 않게 CUDA Stream 등을 활용해 비동기적으로 Host와 통신합니다.
  • Device/Host Split: 모든 걸 Host에 넘기는 건 아닙니다. 예를 들어 std::time::Instant 같은 건 GPU 내부 타이머 레지스터를 써서 로컬에서 처리합니다. 똑똑하죠.

엔지니어로서의 비판적 시각: 성능과 트레이드오프

기술적으로 멋진 건 인정하지만, 현업 엔지니어로서 우려되는 지점들이 분명히 있습니다.

1. Latency라는 괴물

PCIe 버스를 타고 CPU까지 갔다가 다시 돌아오는 비용은 결코 저렴하지 않습니다. Hacker News의 한 유저(anon)가 지적했듯, “제목이 좀 오해의 소지가 있다. std 코드가 GPU에서 실행된다기보단, 원격 함수 호출에 가깝다”는 말은 반은 맞고 반은 틀립니다.

로직 자체는 GPU에서 돌지만, I/O가 발생하는 순간 엄청난 Latency 가 발생할 겁니다. 만약 루프 안에서 println!을 남발하거나 파일을 쓴다면? GPU의 병렬 처리 이점을 다 깎아먹고 병목 현상의 지옥을 맛보게 될 겁니다.

2. 추상화의 함정

std가 된다는 건 수많은 Rust 라이브러리를 그대로 가져다 쓸 수 있다는 뜻입니다. 하지만 그 라이브러리들이 GPU의 메모리 모델이나 스레드 구조를 고려해서 짜였을까요? 절대 아닙니다. 무심코 가져다 쓴 라이브러리가 내부적으로 락(Lock)을 걸거나 무거운 힙 할당을 한다면, 디버깅하기 힘든 성능 저하를 겪을 수 있습니다.

그럼에도 불구하고 왜 혁신적인가?

이러한 우려에도 불구하고, 저는 이 시도가 Game Changer 가 될 잠재력이 있다고 봅니다.

  • 디버깅과 로깅: GPU 커널 디버깅은 악몽입니다. 그냥 println!을 찍을 수 있다는 것만으로도 생산성이 10배는 올라갑니다.
  • 초기화 및 설정: 성능이 중요하지 않은 초기화 단계나 에러 처리 로직에서 std를 쓸 수 있다면 코드가 훨씬 깔끔해집니다.
  • 하드웨어의 융합: Apple의 M 시리즈나 AMD APU처럼 CPU와 GPU의 메모리가 통합되는 추세입니다. 이런 Unified Memory 아키텍처에서는 Hostcall의 비용이 획기적으로 줄어들 수 있습니다. VectorWare는 미래를 보고 베팅한 겁니다.

Hacker News의 반응들

커뮤니티의 반응도 흥미롭습니다. “이제 GPU에서 둠(DOOM) 돌릴 수 있냐?”는 농담부터, 기술적인 깊이를 묻는 질문까지 다양합니다.

  • 긍정론: “Rust std가 CPU에서 Syscall을 쓰듯, GPU에서 Hostcall을 쓰는 건 자연스러운 추상화다.”
  • 회의론: “결국 I/O는 CPU가 하는 건데, ‘GPU에서 실행된다’는 표현은 과장 아니냐?” (저는 이 의견에 일부 동의하지만, 추상화 관점에서는 허용 범위라고 봅니다.)

결론: 아직은 실험실 단계, 하지만 방향은 맞다

VectorWare의 이번 발표는 당장 프로덕션 레벨의 고성능 연산에 std::fs를 쓰라는 이야기가 아닙니다. Rust의 강력한 추상화를 이기종 컴퓨팅(Heterogeneous Computing)으로 확장 했다는 데 의의가 있습니다.

개인적으로는 이 기술이 오픈소스로 풀리고 업스트림(Upstream) 되어, 우리가 Cargo.toml에 의존성 한 줄 추가하는 것만으로 GPU 코드를 짤 수 있는 날이 오기를 기대합니다. 그때가 되면 CUDA C++는 정말 역사의 뒤안길로 사라질지도 모르니까요.

한 줄 요약: GPU 프로그래밍의 진입 장벽을 낮추는 엄청난 마일스톤이지만, Hostcall의 비용을 이해하지 못하고 쓰면 발등 찍히기 딱 좋다.