AI 시대, 기술 선택의 본질은 기계적 성능이 아닌 생태계와 개발자 경험에 있다.
오늘날 딥러닝 및 대규모 언어 모델(LLM)은 NVIDIA (엔비디아)의 CUDA (Compute Unified Device Architecture) 생태계에 깊이 의존하고 있습니다. 그러나 이 종속성은 컴파일 타임(compile time)이 아니라 런타임(runtime) 환경의 독점적 구조에서 발생하며, 이는 기술적 병목으로 작용합니다. 본 글은 이러한 CUDA의 런타임 종속성을 구조적으로 분석하고, 이를 완화하거나 대체하려는 기술로서 ONNX (Open Neural Network Exchange) 형식과 ROCm (Radeon Open Compute) 실행 환경의 가능성과 한계를 탐구합니다. 분석 결과, 기술의 성공은 단순히 FLOPs/$ (Floating-point Operations Per Second per dollar) 경쟁을 넘어 개발자 경험(developer experience)을 주축으로 한 기술 생태계(ecosystem)의 성숙도가 핵심 조건임을 보여줍니다.
인공지능(AI)과 고성능 병렬 연산 분야에서 GPU (Graphics Processing Unit)는 사실상 필수적인 기반 인프라가 되었습니다. 특히 NVIDIA (엔비디아)의 CUDA (Compute Unified Device Architecture)는 PyTorch (파이토치), TensorFlow (텐서플로우) 등 주류 딥러닝 프레임워크와의 긴밀한 연동을 통해 표준적 지위를 확보했습니다. 그러나 이 강력한 표준은 동시에 심각한 종속성(dependency) 문제를 야기합니다. 개발자들은 “코드는 돌아가야 하지만, CUDA가 없으면 아무것도 실행되지 않는다”는 현실에 직면합니다. 본 글은 CUDA가 어떻게 런타임 수준에서 기술적 병목을 형성하는지 살펴보고, ONNX 형식과 ROCm 실행 환경이 이 구조적 종속성을 해소할 수 있는 가능성과 그 현실적 한계를 평가합니다. 이를 통해 AI 시대의 기술 선택이 단순한 성능 수치가 아닌 생태계와 개발자 생산성에 달려 있음을 논의하고자 합니다.
CUDA 런타임에 대한 종속성: 기술 병목의 구조
소프트웨어 실행 흐름의 기본은 '작성(Write) → 컴파일(Compile) → 링크(Link) → 실행(Run)'으로 요약됩니다. 여기서 컴파일 타임(compile time)은 우리가 작성한 코드가 컴퓨터가 이해할 수 있는 기계어로 번역되는 시점을 의미합니다. 즉, 프로그래머가 프로그램을 만들기 위해 소스 코드를 작성하고 이를 컴퓨터가 실행할 수 있는 형태로 변환하는 단계입니다. 반면, 런타임(run time)은 그렇게 만들어진 프로그램이 실제로 컴퓨터 위에서 실행되는 시점을 말합니다.
전통적인 컴파일형 언어인 C++ (C 플러스플러스)의 경우, 이 과정을 통해 생성된 실행 파일은 운영체제(OS)만 준비되면 별도의 추가 의존성 없이 실행될 수 있었습니다. 그러나 CUDA는 이 전통 구조에 독점적 런타임 계층을 얹습니다.
nvcc (NVIDIA CUDA Compiler)를 사용하여 .cu 파일을 컴파일하고 C++ 코드와 결합한 후 실행 파일을 만들 수는 있지만, 진정한 병목은 실행(runtime) 시점에 나타납니다. CUDA 프로그램은 다음과 같은 **런타임 자원(runtime resources)**에 의존합니다:
- NVIDIA 드라이버(Driver): GPU 하드웨어와 OS 간의 통신을 담당합니다.
- CUDA Runtime API (Application Programming Interface):
libcudart.so와 같은 라이브러리가 GPU 커널 실행 및 메모리 관리를 담당합니다. - 고성능 연산 라이브러리:
cuBLAS(CUDA Basic Linear Algebra Subprograms),cuDNN(CUDA Deep Neural Network Library),NCCL(NVIDIA Collective Communications Library) 등 딥러닝 연산에 최적화된 라이브러리들입니다. - GPU 디바이스(Device) 접근 권한 및 커널 로딩: 실제 GPU 하드웨어에 접근하고, GPU에서 실행될 커널 코드를 로딩하는 과정입니다.
이들 자원은 모두 NVIDIA가 독점적으로 제공하며, 특정 버전 호환성을 요구합니다. 하드웨어와 드라이버가 충돌하거나 누락되면 아무리 코드가 잘 컴파일되어도 실행 자체가 불가능합니다. 따라서 CUDA 종속성의 핵심은 컴파일이 아니라 실행(runtime) 단계에서의 폐쇄적 구조에 있습니다.
ONNX 형식: 플랫폼 독립 실행의 가능성과 제약
CUDA 런타임 종속성을 완화하려는 대표적인 시도 중 하나가 ONNX (Open Neural Network Exchange) 형식입니다. Microsoft (마이크로소프트)와 Meta (메타)가 주도한 ONNX 형식은 다양한 프레임워크에서 학습된 모델을 .onnx 파일로 저장하여 플랫폼 독립적으로 실행할 수 있게 합니다. .onnx 모델은 ONNX Runtime을 통해 CUDA뿐만 아니라 ROCm, DirectML (다이렉트ML), OpenVINO (오픈비노), CPU-only (CPU 전용), WebAssembly (웹어셈블리) 등 다양한 백엔드에서 추론할 수 있습니다. 이는 런타임 독점 구조를 우회하는 대표적인 전략입니다.
ONNX는 PyTorch (파이토치)나 TensorFlow (텐서플로우) 등 특정 프레임워크에 묶이지 않고 동일 모델을 재사용할 수 있다는 점에서 ‘AI 시대의 실행 가능한 중립 바이너리’라고 할 만합니다. 그러나 현실에서는 다음과 같은 제약이 존재합니다:
- 연산자 변환 손실(Conversion Loss): 일부 PyTorch 연산자는 ONNX로 완전 변환되지 않거나, 정확한 매핑이 어려울 수 있습니다.
- 성능 최적화의 한계: ONNX Runtime은 TensorRT (텐서RT)와 같이 하드웨어 전용 최적화 라이브러리에 비해 추론 성능이 떨어질 수 있습니다.
- 대규모 LLM (Large Language Model) 지원의 불완전성: Transformer (트랜스포머) 기반의 대형 모델은 ONNX로의 변환 및 최적화가 복잡하며, 성능상의 제약이 따를 수 있습니다.
이로 인해 "추론 플랫폼 독립성"이라는 이상은 유지되지만, 실제 실무에서는 추가적인 최적화 비용과 시스템 이해도가 요구됩니다. 많은 개발자가 "결국 PyTorch + CUDA로 가자"를 선택하는 이유가 바로 여기에 있습니다.
ROCm 실행 환경: CUDA 독점에 맞서는 오픈소스 GPGPU의 가능성
ONNX가 모델 포맷 차원의 독립성을 추구한다면, ROCm (Radeon Open Compute)은 실행 환경 자체를 대체하려 합니다. AMD (Advanced Data Machines)는 ROCm을 통해 CUDA와 유사한 GPGPU (General Purpose GPU) 프로그래밍 환경을 제공합니다. 핵심은 HIP (Heterogeneous-Compute Interface for Portability)이라는 커널 언어로, 이는 CUDA C/C++ (C 플러스플러스)과 문법이 거의 동일하여 hipify 도구를 사용하면 CUDA 코드를 HIP 코드로 자동 변환할 수도 있습니다.
ROCm은 PyTorch, TensorFlow, ONNX Runtime과 연동되며, libhiprtc, rocBLAS, MIOpen 같은 라이브러리로 CUDA의 libcudart.so, cuBLAS, cuDNN을 대체합니다. 이는 공급망 다양화와 비용 절감, 오픈소스 기반의 투명성을 동시에 추구하는 구조입니다.
그러나 ROCm은 다음과 같은 현실적 한계가 뚜렷합니다:
- 운영체제 제약(OS Restriction): ROCm은 Linux (리눅스) 중심으로 설계되어 Windows (윈도우즈) 지원이 제한적입니다.
- GPU 모델 호환성(GPU Compatibility): 일부 고급 Radeon GPU (라데온 GPU)만이 ROCm을 공식 지원하여, 모든 AMD GPU에서 ROCm을 사용할 수 있는 것은 아닙니다.
- 생태계 미성숙(Immature Ecosystem): 개발 문서, 예제, 커뮤니티, 디버깅 툴 등 전반적인 개발 생태계가 CUDA 수준에 미치지 못합니다.
결국, ROCm은 기술적으로는 대안이지만, 실질적으로는 더 높은 학습 비용과 불확실성을 동반하는 선택지로 인식됩니다. FLOPs/$만으로는 충분하지 않다는 점이 분명합니다.
CUDA의 독점적인 지위는 단순히 뛰어난 성능 때문만이 아닙니다. 수많은 개발자, 문서, 예제 코드, 디버깅 도구, 그리고 PyTorch나 TensorFlow와 같은 핵심 프레임워크와의 긴밀한 연동이 만든 강력한 생태계(ecosystem) 덕분입니다. 반면 ONNX와 ROCm은 구조적으로는 매우 타당한 대안이지만, FLOPs/$ 이상의 가치인 ‘개발자 경험(developer experience)’과 ‘프로그래머의 시간/$’을 획기적으로 낮추지 못하면 대중화되기 어렵습니다. 궁극적으로 중요한 것은 '코드 → 컴파일 → 링크 → 실행'이라는 단순한 소프트웨어 실행 구조의 본질을 꿰뚫어 보고, 런타임 종속성과 병목이 어디서 발생하는지를 이해하는 능력입니다. 이후 상황에 맞게 ONNX와 ROCm 같은 대안을 선택할 수 있는 실력이 중요합니다. 이는 특정 벤더에 종속되지 않고, 기술 변화에 유연하게 대응할 수 있는 진정한 기술적 자유(freedom)로 이어집니다.