들어가며: 왜 지금 GPU 기반 SQL 엔진인가?
대규모 데이터 분석에서 Presto는 널리 쓰이는 분산 SQL 엔진입니다. 하지만 CPU 기반 아키텍처는 점점 더 커지는 데이터셋과 실시간 응답 요구 앞에서 한계를 드러내고 있어요. 특히 AI 에이전트가 데이터를 기반으로 의사결정을 내리는 시나리오에서는 밀리초 단위의 레이턴시가 서비스 품질을 좌우합니다.
NVIDIA는 이 문제를 해결하기 위해 cuDF 기반의 GPU 가속 Presto를 선보였습니다. 단순히 GPU를 단다는 개념이 아니라, 쿼리 파싱부터 실행, 결과 반환까지 전 과정을 GPU 친화적으로 재설계했어요. 이번 글에서는 NVIDIA가 공개한 DGX B200과 GB200 NVL72 환경에서의 벤치마크 결과를 바탕으로, GPU 가속 Presto가 어떤 성능을 내는지, 그리고 실제 운영 환경에서 주의할 점은 무엇인지 살펴보겠습니다.
이 글은 NVIDIA Developer Blog의 원문을 분석하고, 국내 데이터 플랫폼 엔지니어의 시각에서 실무 적용 포인트를 추가했습니다.
DGX B200 단일 노드: CPU 8~10대 클러스터를 압도하다
가장 인상적인 결과는 단일 DGX B200 노드에서 나왔습니다. 이 서버 한 대에 B200 GPU 8개가 NVLink 5.0으로 연결되어 있고, 각 GPU가 하나의 Presto 워커 역할을 합니다.
TPC-H Scale Factor 1K (약 1TB 데이터셋)
| 구성 | 실행 시간 | CPU 대비 속도 향상 |
|---|---|---|
| CPU 8노드 (Intel Xeon 6642Y) | 기준 (1x) | - |
| GPU 1개 (B200) | 0.4x | 2.5배 빠름 |
| GPU 8개 (B200) | 0.12x | 8.2배 빠름 |
TPC-H Scale Factor 3K (약 3TB 데이터셋)
| 구성 | 실행 시간 | CPU 대비 속도 향상 |
|---|---|---|
| CPU 10노드 (Intel Xeon 6642Y) | 기준 (1x) | - |
| GPU 3개 (B200) | 0.28x | 3.6배 빠름 |
| GPU 8개 (B200) | 0.13x | 7.8배 빠름 |
여기서 주목할 점:
- GPU 1개만 써도 8노드 CPU 클러스터보다 2.5배 빠릅니다. 전력 소비와 랙 공간을 고려하면 TCO 측면에서 압도적이에요.
- GPU 개수를 늘릴수록 선형에 가깝게 성능이 확장됩니다. NVLink 5.0의 1,800 GB/s 양방향 대역폭이 병목을 만들지 않기 때문입니다.
- 단, 이 벤치마크는 Hot Cache 상태(데이터가 이미 메모리에 적재된 상태)에서 측정되었습니다. 실제 운영 환경에서는 콜드 스타트 시 I/O 병목이 발생할 수 있으므로, 캐시 워밍 전략이 중요합니다.
💡 국내 SI/클라우드 환경 팁: 국내에서는 아직 GPU 클러스터를 Presto 전용으로 할당하기 어려운 경우가 많습니다. 이럴 때는 GPU 인스턴스를 스팟(Spot)으로 띄우고, 핫 데이터만 GPU Presto로 라우팅하는 하이브리드 아키텍처를 고려해보세요. 예를 들어, 일간 배치성 쿼리는 CPU Presto, 실시간 대시보드는 GPU Presto로 분기하면 비용 효율을 높일 수 있습니다.
GB200 NVL72 멀티노드: I/O 최적화로 64% 성능 향상
단일 노드의 성능이 인상적이지만, 진짜 관건은 멀티노드로 확장할 때입니다. NVIDIA GB200 NVL72는 18개 노드(총 72개의 B200 GPU)로 구성된 시스템으로, 모든 GPU가 NVLink로 연결됩니다.
벤치마크는 8개 노드(32개 GPU)를 사용해 TPC-H Scale Factor 10K(약 10TB)와 30K(약 30TB)를 실행했습니다. 특히 흥미로운 점은 I/O 설정 최적화 과정이 단계별로 공개된 것입니다.
I/O 최적화 단계별 성능 비교 (SF 10K)
| 최적화 단계 | 설명 | 누적 성능 향상 |
|---|---|---|
| Baseline | POSIX 읽기 + 기본 I/O 파라미터 | 0% (기준) |
| + GDS + 16MiB I/O | GPUDirect Storage 활성화, I/O 태스크 크기 4MiB→16MiB | ~30% |
| + 16 I/O 스레드 | I/O 스레드 4→16개로 증가 | ~47% (추가 17%) |
| + Rebatcing + Q11 Rewrite | 대용량 배치 전송, Q11 SELECT→INSERT 변환 | ~64% (추가 35%) |
Q11 Rewrite가 시사하는 점
Q11 쿼리는 SELECT 결과를 Coordinator로 전송하는 과정에서 GPU 활용률이 5% 미만으로 떨어지는 문제가 있었습니다. HttpExchange가 병목이었죠. 이를 INSERT INTO로 변경하여 GPU 기반 Parquet Writer로 결과를 직접 Storage에 저장하도록 바꾸자, 실행 시간이 50초에서 2초로 단축됐습니다.
이 사례가 주는 교훈:
- GPU 가속 환경에서는 데이터 이동(Data Movement)이 계산보다 더 큰 병목이 될 수 있습니다.
- Presto의 기본 HttpExchange는 GPU 간 통신에 최적화되어 있지 않습니다. UcxExchange를 활용한 고성능 통신 채널 구성이 필수입니다.
- 쿼리 패턴에 따라 결과 반환 방식을 SELECT vs INSERT로 선택할 수 있는 옵티마이저 레벨의 자동화가 앞으로의 과제입니다.
GPUDirect Storage의 역할
GB200 NVL72 + IBM Storage Scale 조합에서 **GPUDirect Storage(GDS)**는 성능의 핵심입니다. GDS를 사용하면 스토리지 → GPU 메모리로 데이터가 직접 전송되어, CPU 메모리를 거치는 바운스 버퍼(Bounce Buffer) 복사 비용과 NUMA 경계를 넘는 패널티를 제거합니다.
실제로 2노드 8GPU 환경에서 GDS Cold Read는 POSIX Cold Read보다 약 2배 빠른 성능을 보였습니다. 콜드 상태(캐시 미스)에서도 이 정도 차이라면, 운영 환경에서는 GDS 적용이 필수라고 볼 수 있습니다.
결론: GPU 가속 Presto, 도입 전 꼭 확인할 3가지
NVIDIA의 벤치마크 결과는 GPU 가속 Presto가 CPU 기반 클러스터를 대체할 수 있는 현실적인 대안임을 증명했습니다. 하지만 실제 도입을 고려한다면 다음 세 가지를 반드시 검토해야 합니다.
1. I/O 아키텍처 설계
- GDS를 지원하는 스토리지(IBM Storage Scale, Lustre 등)와 네트워크(InfiniBand/RoCE)가 갖춰져 있어야 합니다.
- 국내에서는 AWS EBS나 Azure Managed Disk 같은 클라우드 네이티브 스토리지와의 GDS 호환성을 먼저 확인하세요. 온프레미스가 아니라면 NVIDIA GPU Cloud(NGC)의 레퍼런스 아키텍처를 참고하는 것이 좋습니다.
2. 쿼리 패턴 분석
- 모든 쿼리가 GPU 가속의 이점을 받는 것은 아닙니다. 복잡한 조인, 윈도우 함수, 대규모 집계가 많이 포함된 워크로드에 가장 효과적입니다.
- 간단한 포인트 쿼리나 단일 행 조회는 오히려 GPU 컨텍스트 스위칭 오버헤드로 인해 성능이 떨어질 수 있습니다.
3. 운영 복잡도
- GPU Presto는 기존 Presto와 별도 클러스터로 운영해야 합니다. CPU Presto와 GPU Presto 간 데이터 라우팅과 메타데이터 동기화 전략이 필요합니다.
- IBM watsonx.data 플랫폼과의 통합이 진행 중이므로, 관리형 서비스를 우선 검토하는 것도 방법입니다.
다음 단계 학습 방향
- 구글 ADK for Kotlin/Android 드디어 공개 AI 에이전트를 앱 안에 직접 심는 방법 – AI 에이전트와 데이터 플랫폼의 연결을 고민한다면 참고하세요.
- AI 코딩 에이전트, 예측 가능한 결과를 만드는 핵심 강력한 피드백 루프 – GPU 가속 Presto가 AI 에이전트에 어떤 피드백 루프를 제공할 수 있는지 생각해보세요.
GPU 가속 Presto는 아직 기술 프리뷰 단계이지만, 데이터 분석의 패러다임을 바꿀 잠재력은 충분합니다. 특히 실시간성이 중요한 AI 에이전트 시대에는 더욱 그렇습니다. 국내에서도 NVIDIA의 레퍼런스 아키텍처를 기반으로 한 PoC가 조만간 시작될 것으로 예상되니, 관심 있으신 분들은 NVIDIA Developer Program에 등록하여 최신 정보를 받아보시길 추천합니다.