CUDA는 NVIDIA가 GPU를 단순한 그래픽 처리 장치에서 범용 병렬 컴퓨팅 플랫폼으로 전환시키기 위해 설계한 핵심 기술이다. 오늘날 AI, HPC, 클라우드 데이터센터의 기반이 되는 이 플랫폼은 단순한 SDK를 넘어, GPU 아키텍처의 진화를 흡수하고 확장하는 실행 환경으로 자리잡았다. CUDA의 각 버전은 독립적으로 존재하는 것이 아니라, 특정 GPU 세대와 강하게 결합되어 발전해왔으며, 이 둘의 관계를 함께 이해하는 것이 전체 흐름을 파악하는 핵심이다.
아래 표는 CUDA의 주요 버전과 해당 시기의 GPU 아키텍처, 그리고 기술적 특징을 한눈에 정리한 것이다.
CUDA 버전별 아키텍처 및 하드웨어 매핑
| CUDA | 버전출시 | 시기지원 | 아키텍처 대표 | GPU 핵심 기술 변환 |
| 1.x | 2007 | Tesla | Tesla C870 | GPU 범용 컴퓨팅 시작 |
| 2.x | 2008 | Tesla | GTX 280 | 메모리 모델 개선 |
| 3.x | 2010 | Fermi | GTX 480 | L1/L2 Cache, ECC |
| 4.x | 2011 | Fermi | Tesla M2090 | 멀티 GPU 지원 |
| 5.x | 2012 | Kepler | K20 | Dynamic Parallelism |
| 6.x | 2014 | Kepler | K40 | Unified Memory |
| 7.x | 2015 | Maxwell | GTX 980 | 전력 효율 개선 |
| 8.x | 2016 | Pascal | P100 | FP16 지원 |
| 9.x | 2017 | Volta | V100 | Tensor Core |
| 10.x | 2018 | Turing | T4 | AI 추론 최적화 |
| 11.x | 2020 | Ampere | A100 | TF32, MIG |
| 12.x | 2022 | Hopper / Ada Lovelace | H100 / RTX 4090 | HMM, NVLink |
| 13.x | 2025~ | Hopper / Blackwell | H100 / B100 | Tile 기반 실행, FP8 |
NVIDIA GPU 아키텍처 & Compute Capability 테이블
| 아키텍처명 | Compute Capability (SM) | 주요 하드웨어 / 제품군 | 특징 |
| Blackwell | sm_110 / sm_100 | Jetson Thor, B200, B100 | FP4 지원, 5세대 Tensor 코어 |
| Blackwell (Consumer) | sm_120 | GeForce RTX 50 시리즈 | 컨슈머향 최적화 (Thor와 호환성 격차 존재) |
| Hopper | sm_90 / sm_90a | H100, H200 | Transformer Engine 도입 |
| Ada Lovelace | sm_89 | RTX 40 시리즈, L40 | 4세대 Tensor 코어, DLSS 3 |
| Ampere | sm_87 / sm_86 / sm_80 | Jetson Orin, RTX 30, A100 | TF32, Sparsity 가속 |
| Turing | sm_75 | RTX 20 시리즈, T4 | RT 코어 최초 도입 |
| Volta | sm_72 / sm_70 | Jetson Xavier, V100 | Tensor 코어 최초 도입 |
| Pascal | sm_62 / sm_61 / sm_60 | Jetson TX2, GTX 10 시리즈 | FP16 연산 성능 강화 |
| Maxwell | sm_53 / sm_52 / sm_50 | Jetson Nano, GTX 900 시리즈 |
CUDA의 초기 버전인 1.x와 2.x는 Tesla 아키텍처 위에서 동작하며 GPU를 연산 자원으로 활용하는 첫 시도를 가능하게 했다. 이 시기의 CUDA는 기능적으로 제한적이었지만, 병렬 컴퓨팅이라는 새로운 방향성을 제시했다는 점에서 의미가 크다.
이후 Fermi 기반의 CUDA 3.x와 4.x에서는 캐시 구조와 ECC 메모리가 도입되며 HPC 환경에서 요구되는 신뢰성과 성능이 확보되었다. 멀티 GPU 지원 역시 이 시기에 본격적으로 도입되면서, CUDA는 단일 장치가 아닌 클러스터 환경에서 활용되기 시작했다.
Kepler 기반의 CUDA 5.x와 6.x는 GPU의 자율성을 크게 높였다. Dynamic Parallelism을 통해 GPU가 스스로 커널을 생성할 수 있게 되었고, Unified Memory는 CPU와 GPU 간 메모리 관리의 복잡성을 크게 줄였다. 이는 GPU를 독립적인 실행 주체로 발전시키는 중요한 계기였다.
Maxwell 기반 CUDA 7.x는 전력 효율을 중심으로 설계되었으며, 이후 클라우드 환경에서 GPU를 운영하는 데 필요한 기반을 마련했다. 이 시기는 성능 향상보다는 운영 효율성이 중요한 설계 요소로 등장한 전환점이었다.
CUDA 8과 함께 등장한 Pascal 아키텍처는 AI 컴퓨팅의 시작을 알렸다. FP16 연산 지원을 통해 딥러닝 학습이 본격적으로 가속되었고, GPU는 점차 AI 인프라의 핵심 요소로 자리잡기 시작했다.
Volta와 Turing 기반의 CUDA 9.x와 10.x에서는 Tensor Core가 도입되며 AI 연산이 구조적으로 최적화되었다. 특히 Volta는 학습, Turing은 추론에 특화되며 AI 워크로드가 분화되기 시작했다.
CUDA 11은 Ampere 아키텍처를 기반으로 클라우드 환경에 최적화된 기능들을 제공했다. 비동기 실행 모델과 CUDA Graphs는 실행 효율을 극대화했으며, MIG(Multi-Instance GPU)를 통해 하나의 GPU를 여러 워크로드가 공유할 수 있게 되었다. 이는 클라우드 사업자에게 GPU를 서비스화할 수 있는 기반을 제공했다.
CUDA 12는 Hopper 및 Ada Lovelace 아키텍처를 지원하며 데이터센터 수준의 통합을 강화했다. Heterogeneous Memory Management를 통해 CPU와 GPU 간 메모리 경계가 더욱 자연스럽게 통합되었고, 고속 인터커넥트 기술을 통해 다수의 GPU가 하나의 시스템처럼 동작할 수 있는 기반이 마련되었다.
CUDA 13.x는 Hopper의 고도화와 함께 Blackwell 아키텍처를 포괄하며, GPU 컴퓨팅의 패러다임을 다시 한 번 변화시키고 있다. 기존의 thread 중심 실행 모델에서 벗어나 데이터 블록 단위의 처리 방식이 강화되고 있으며, 컴파일러가 자동으로 최적화를 수행하는 구조로 전환되고 있다. FP8과 같은 AI 특화 연산이 기본적으로 지원되면서, 대규모 언어모델과 같은 최신 AI 워크로드에 최적화된 실행 환경이 제공된다.
이러한 흐름을 종합하면 CUDA의 발전은 단순한 기능 확장이 아니라, 컴퓨팅 패러다임 자체의 전환 과정이라고 볼 수 있다. 초기에는 GPU를 활용하는 기술에 불과했지만, 현재는 GPU를 중심으로 시스템을 설계하고 운영하는 수준에 이르렀다. 특히 CUDA 13 이후의 방향성은 GPU 클러스터 전체를 하나의 논리적 컴퓨팅 시스템으로 추상화하는 데 있으며, 이는 AI 데이터센터 설계 방식에 직접적인 영향을 미치고 있다.
결국 CUDA는 GPU를 사용하는 방법을 제공하는 기술을 넘어, GPU 기반 컴퓨팅 환경을 정의하는 표준으로 진화하고 있으며, 그 중심에는 항상 GPU 아키텍처와의 긴밀한 결합이 존재한다.
CUDA의 실행 구조는 아래와 같이 계층적으로 구성된다.
이 구조에서 애플리케이션은 직접 GPU를 제어하지 않는다. 대신 CUDA Runtime을 호출하고, Runtime은 다시 Driver API를 통해 GPU와 통신한다. 이 계층 구조는 CUDA의 핵심 설계이며, Linux 환경에서의 설치 구조도 이를 그대로 반영한다.
CUDA 구성 요소와 역할
먼저 CUDA를 구성하는 주요 요소를 정리하면 다음과 같다.
| 구성 요소 | 주요 역할 | 포함 위치 | 비고 |
| Driver | GPU 제어, 커널 실행 | OS 영역 (/usr/lib) | OS 커널과 연결 |
| Runtime (libcudart) | 개발 편의 API | CUDA Toolkit | Driver 위에서 동작 |
| Toolkit | 컴파일러 및 개발 도구 | /usr/local/cuda | nvcc 포함 |
| Libraries | AI/HPC 연산 | /usr/local/cuda/lib64 | cuBLAS, cuDNN, NCCL |
| Application | 사용자 프로그램 | 사용자 영역 | PyTorch 등 |
이 표에서 가장 중요한 포인트는 Driver와 Toolkit이 서로 다른 영역에 설치된다는 점이다.
Runtime과 Driver의 관계
CUDA를 이해하는 핵심은 Runtime과 Driver의 차이를 정확히 구분하는 것이다.
| 항목 | Runtime (libcudart.so) | Driver (libcuda.so) |
| 위치 | CUDA Toolkit | OS 시스템 |
| 역할 | 편의 API 제공 | GPU 직접 제어 |
| 의존성 | Driver 필요 | 독립 |
| 사용자 접근 | 일반 개발자 | 시스템 레벨 |
애플리케이션의 실제 실행 흐름은 다음과 같다.
이 구조에서 Runtime은 개발 편의성을 제공하고, Driver는 실제 하드웨어 실행을 담당한다.