AMD 카드 쓰는데 CUDA가 필요할 때
AI나 머신러닝 쪽을 조금이라도 건드려 본 분이라면 한 번쯤 이런 경험이 있을 거예요. 튜토리얼 따라 PyTorch 설치하고 예제 돌리려는데 “CUDA 디바이스를 찾을 수 없습니다”라는 에러가 뜨는 거죠. 내 컴퓨터엔 분명 멀쩡한 AMD 라데온 그래픽카드가 있는데 말이에요.
이게 왜 그러냐면, CUDA는 엔비디아가 만든 GPU 프로그래밍 플랫폼이거든요. 쉽게 말해 “그래픽카드한테 그림 그리는 것 말고 다른 계산도 시키는 방법”인데, 이게 엔비디아 카드에서만 돌아가요. 그런데 지난 10년 넘게 AI 생태계가 거의 CUDA 위에서 만들어졌기 때문에, 라이브러리나 예제 코드 대부분이 CUDA를 전제로 하고 있어요. AMD 카드 쓰는 사람은 늘 2등 시민 같은 기분이었죠.
이번에 GitHub에 올라온 “CUDA for AMD on Windows”라는 프로젝트는 이름 그대로, 윈도우 환경에서 AMD 그래픽카드로 CUDA용 소프트웨어를 돌릴 수 있게 하는 걸 목표로 해요. 리눅스도 아니고 윈도우라는 점이 포인트인데요, 왜 그게 중요한지는 조금 뒤에 설명드릴게요.
다른 회사 카드에서 CUDA가 어떻게 돌아가나요
이게 뭐냐면, 기본 아이디어는 “번역”이에요. CUDA 프로그램이 “GPU야, 메모리 할당해줘”, “이 커널(GPU에서 돌아가는 작은 함수) 실행해줘”라고 요청하면, 중간에 끼어든 호환 레이어가 그 요청을 받아서 AMD 쪽 언어인 HIP이나 ROCm 명령으로 바꿔서 전달하는 거죠. 영어로 말하는 손님과 한국어만 하는 직원 사이에 통역사가 서 있는 것과 비슷해요.
AMD도 자체적으로 ROCm이라는 플랫폼과 HIP이라는 프로그래밍 모델을 갖고 있어요. HIP은 사실 CUDA와 API 모양이 거의 똑같이 설계돼 있어서, cudaMalloc이 hipMalloc으로, cudaMemcpy가 hipMemcpy로 대응되는 식이거든요. 그래서 소스 코드가 있으면 hipify라는 도구로 변환할 수 있어요. 문제는 우리가 쓰는 프로그램 대부분이 소스 코드가 아니라 이미 컴파일된 바이너리 형태라는 거예요. 그래서 소스 변환이 아니라, 실행 시점에 CUDA 런타임 라이브러리(cudart, cublas 같은 DLL)를 가로채서 AMD 쪽으로 넘겨주는 방식이 필요한 거고, 이런 프로젝트들이 하는 일이 바로 그거예요.
기술적으로 까다로운 부분은 두 가지예요. 첫째, CUDA 커널은 PTX라는 중간 언어로 컴파일되는데, 이걸 AMD GPU가 알아듣는 형태로 다시 컴파일해야 해요. 둘째, cuBLAS나 cuDNN 같은 엔비디아 전용 고성능 라이브러리는 내부 구현이 공개돼 있지 않아서, AMD의 rocBLAS나 MIOpen 같은 대응 라이브러리로 하나하나 매핑해줘야 하거든요. 여기서 성능 차이가 갈리고, 지원 안 되는 함수가 나오면 프로그램이 중간에 죽기도 해요.
왜 하필 윈도우가 문제였나
리눅스에서는 ROCm이 꽤 오래전부터 지원됐고, PyTorch도 ROCm 빌드를 공식 제공해 왔어요. 그런데 윈도우는 사정이 달랐어요. AMD의 HIP SDK가 윈도우용으로 나온 건 비교적 최근이고, 지원하는 카드 종류도 제한적이었거든요. 게다가 PyTorch 같은 프레임워크의 윈도우 ROCm 지원은 리눅스보다 한참 뒤처져 있었어요.
그런데 정작 취미로 AI 돌려보는 사람, 게임용으로 AMD 카드를 산 사람 대부분은 윈도우를 쓰죠. Stable Diffusion으로 그림 생성하거나 로컬에서 LLM 돌려보고 싶은 사람들이 “리눅스 듀얼부팅 하세요”라는 답변을 듣고 포기하는 경우가 많았어요. 그래서 윈도우에서 CUDA 호환을 제공한다는 건 실질적으로 꽤 많은 사람에게 의미 있는 일이에요.
이 분야의 선배들: ZLUDA와 SCALE
사실 이런 시도는 처음이 아니에요. 가장 유명한 게 ZLUDA라는 프로젝트예요. 원래는 인텔 GPU에서 CUDA를 돌리려고 시작됐다가, AMD가 조용히 개발을 후원했고, 2024년 초에 AMD가 손을 떼면서 공개됐어요. 그때 “수정 없이 CUDA 바이너리를 AMD에서 돌린다”는 걸 실제로 보여줘서 큰 인상을 남겼죠. 이후 법적인 문제로 코드가 한 번 내려갔다가, 새로운 후원을 받아 다시 개발이 이어지고 있어요.
또 하나는 Spectral Compute라는 회사의 SCALE이에요. 이건 런타임에 가로채는 방식이 아니라, CUDA 소스 코드를 AMD용으로 직접 컴파일해주는 컴파일러 툴체인이에요. 소스가 있을 땐 이쪽이 더 깔끔하지만, 바이너리만 있으면 못 써요.
그리고 엔비디아의 입장이 있어요. 엔비디아는 CUDA 이용약관에 “번역 레이어를 통해 다른 하드웨어에서 실행하는 것을 금지한다”는 취지의 조항을 넣었어요. 법적으로 어디까지 유효한지는 논쟁이 있지만, 이런 프로젝트가 늘 회색지대에 있는 이유이기도 해요. 이번 프로젝트도 ZLUDA 계열의 접근을 윈도우 환경에 맞게 정리하고 설치 과정을 쉽게 만드는 데 초점을 둔 것으로 보이는데, 쓰실 땐 이 법적 배경도 알고 계시는 게 좋아요.
한국 개발자에게 주는 시사점
당장 실무 프로덕션에서 쓰기엔 아직 조심스러워요. 호환 레이어는 본질적으로 “안 되는 함수가 있으면 거기서 멈춘다”는 한계가 있고, 성능도 네이티브 CUDA보다 떨어지는 게 보통이거든요. 하지만 몇 가지 상황에선 정말 유용해요.
첫째, 집에 AMD 카드가 있는데 AI 공부를 시작하고 싶은 분이요. 클라우드 GPU 빌리기 전에 로컬에서 코드 돌려보고 감 잡는 용도로는 충분히 쓸 만해요. 둘째, 회사에서 AMD GPU 도입을 검토 중이라면, 기존 CUDA 코드베이스가 얼마나 옮겨지는지 미리 테스트해보는 도구로 활용할 수 있어요. 셋째, 시스템 프로그래밍에 관심 있는 분이라면 이런 프로젝트 코드 자체가 훌륭한 교재예요. DLL 후킹, API 호환 레이어 설계, GPU 컴파일러 파이프라인 같은 걸 실제 코드로 볼 수 있거든요.
마무리
한 줄로 정리하면, “엔비디아 독점이라는 벽에 윈도우 사용자도 사다리를 놓기 시작했다”는 거예요. 아직 벽을 넘은 건 아니지만, AMD 카드로 AI 돌려보는 문턱이 조금씩 낮아지고 있어요.
여러분은 어떠세요? GPU 살 때 “그래도 CUDA 때문에 엔비디아”라고 생각하시나요, 아니면 이런 호환 레이어가 성숙하면 AMD로 넘어갈 생각이 있으신가요? 실제로 ZLUDA 같은 걸 써보신 분들 경험도 궁금해요.
🔗 출처: Hacker News