Samsung SDS

생성형 AI 도입이 검증 단계를 넘어 실제 서비스로 확대되면서 기업의 AI 인프라 의사결정 기준도 달라지고 있습니다. 동일한 GPU를 사용하더라도 모델 규모, 학습과 추론의 비중, 목표 지연시간, 동시 요청 수와 데이터 이동 방식에 따라 실제 처리량과 비용은 크게 달라질 수 있습니다. 워크로드에 맞지 않는 인프라를 먼저 선택하면, 고성능 GPU를 확보하고도 통신 병목이나 데이터 공급 지연으로 실제 활용률이 낮아지거나 서비스 전환 단계에서 재구성 비용이 추가로 발생하는 경우가 많습니다.

그래서 AI 인프라를 결정하는 질문은 “어떤 GPU가 가장 강력한가”가 아니라 “우리 워크로드에 어떤 구성이 맞는가”여야 합니다. 본 글에서는 GPU 피크 성능만으로 인프라를 판단하기 어려운 이유를 살펴보고, 인프라 선택 전에 확인해야 할 질문과 세 가지 대표 구성 방식, 동일 조건에서의 비교 방법, 그리고 실제 도입을 위한 검증 및 실행 순서를 차례로 살펴봅니다.

왜 GPU 피크 성능만으로는 부족한가

AI 가속기는 벡터·행렬·텐서 연산처럼 딥러닝에서 반복되는 계산을 빠르게 처리하도록 설계된 하드웨어입니다. CPU는 범용 제어와 순차 처리에, GPU는 폭넓은 모델을 지원하는 대규모 병렬 연산에, NPU는 신경망 연산을 전용 구조로 최적화한 전력 효율에 강점을 갖습니다. 이 차이는 어떤 칩이 더 뛰어난가의 문제가 아니라, 어떤 워크로드 조건에서 유리한가의 문제입니다.

[그림1] AI 가속기 관계 (작성자 제작)

AI 가속기: 범용 처리에서 신경망 특화 연산까지

• CPU - 범용 처리 (다양한 작업, 제어 중심)
• GPU - 대규모 병렬 처리 (AI 학습, 병렬 연산 최적화)
• NPU - 신경망 연산 특화 (추론, 저전력•고효율 최적화)

CPU 에서 NPU 로 갈수록 범용성 • 유연성 → 효율성 • 전문성

실제 선택에 영향을 주는 것은 피크 성능 수치가 아니라 소프트웨어 호환성, 확장 방식, 전력당 처리량, 그리고 검증에 걸리는 시간입니다. GPU는 소프트웨어 생태계와 모델 호환성이 넓어 도입 속도가 빠르지만, 전력과 발열 부담이 크고, NPU는 특정 추론 워크로드에서 전력 대비 성능을 크게 높일 수 있지만 컴파일러와 런타임이 최신 LLM 구조를 지원하는지부터 확인해야 실제 배포로 이어질 수 있습니다. 제조사가 제시하는 벤치마크 수치는 대부분 특정 모델과 배치 크기, 정밀도 조건에서 측정된 값이어서, 그 조건이 자사 워크로드와 다르면 그대로 적용하기 어렵습니다.

GPU의 연산 성능이 아무리 뛰어나도, 사용자가 체감하는 실제 서비스 속도는 그 하나만으로 결정되지 않습니다. 메모리 용량과 대역폭, GPU 간 통신, 데이터 입출력, CPU 처리, 소프트웨어 스택까지 여러 구성 요소가 함께 맞물려 전체 성능을 만들어내기 때문입니다.

문제는 이 가운데 유독 느린 구간이 하나라도 있으면, 전체 시스템의 속도가 결국 그 구간에 맞춰진다는 점입니다. 사슬의 강도가 가장 약한 고리로 결정되듯이, GPU 연산 성능이 높아도 메모리 대역폭이 부족하거나 소프트웨어가 비효율적이면 그 병목 때문에 GPU의 실력을 온전히 발휘하지 못합니다.

그래서 높은 피크 연산 성능은 좋은 서비스를 위한 필요조건일 뿐, 목표한 서비스 수준(SLO)을 보장하는 충분조건은 되지 못합니다. 결국 메모리, 통신, I/O, CPU, 소프트웨어가 균형 있게 뒷받침되어야 실제로 빠르고 안정적인 서비스가 완성됩니다. 그래서 인프라 선택에 앞서 먼저 해야 할 일은 가속기 사양을 비교하는 것이 아니라, 자사 워크로드에 맞는 질문을 던지는 것입니다.

인프라 선택 전에 답해야 할 다섯 가지 질문

워크로드에 맞는 인프라를 고르려면 먼저 다음 다섯 가지 질문에 답해야 합니다. 이 답에 따라 필요한 GPU 수량과 메모리, 클러스터 여부, 가속기 종류가 달라집니다.

이 다섯 가지 질문에 대한 답은 워크로드마다, 같은 기업 안에서도 프로젝트 단계마다 달라집니다. 그래서 하나의 인프라 구성을 표준으로 정해두기보다, 답에 따라 다른 구성을 선택하거나 조합할 수 있는 유연성이 더 중요합니다.

세 가지 구성 방식

다섯 가지 질문에 대한 답은 대체적으로 세 가지 구성방식으로 수렴합니다. 이 세 가지는 순서대로 거쳐야 하는 단계가 아니라, 워크로드 조건에 따라 선택하거나 동시에 조합할 수 있는 패턴입니다.

① 단일 노드·변동 수요: GPU VM

개발 초기 단계에서는 모델과 데이터가 자주 바뀌고, 그때그때 필요한 GPU 수량도 일정하지 않은 경우가 많습니다. 이런 상황에서는 워크로드 종류에 따라 확인해야 할 기준이 달라집니다. 학습 워크로드라면 모델 가중치와 그래디언트, 옵티마이저 상태, 활성값까지, 즉 학습에 필요한 모든 데이터가 하나의 노드 메모리 안에 다 들어가는지를 먼저 확인해야 하고, 추론 워크로드라면 모델 자체와 목표로 하는 동시 요청 수를 처리할 만큼의 KV 캐시가 하나의 노드에 수용되는지를 확인해야 합니다.

여기에 자원 수요의 변동성이 크다면 고려할 점이 하나 더 있습니다. 매번 물리 서버를 새로 구성하는 방식은 이런 상황에서 비효율적이기 때문에, 물리 GPU를 가상 서버에 직접 할당해 필요할 때 즉시 생성하고 다 쓰면 바로 회수할 수 있는 GPU VM이 훨씬 유리합니다. 특히 개발/검증, 미세조정, 중소규모 학습, 배치 추론처럼 자원 사용량이 유동적인 작업에서는 GPU VM이 자원 운영 부담을 크게 줄여줍니다.

[그림 2] GPU Pass-through 기반 GPU VM 구조 (작성자 제작)

GPU VM 구조: 가상 서버와 물리 GPU의 직접 연결

• GPU VM - Guest OS1 → Hypervisor / GPU Pass-through → GPU
• GPU VM - Guest OS2 → Hypervisor / GPU Pass-through → GPU
• GPU VM - Guest OS3 → Hypervisor / GPU Pass-through → GPU
• GPU VM - Guest OS4 → Hypervisor / GPU Pass-through → GPU

다만 온라인 추론에 쓸 때는 GPU 수량 확보만으로는 부족합니다. 모델 로딩 시간, 첫 토큰 응답시간, 동시 처리량, 오토스케일링 동작까지 실제 트래픽 조건에서 함께 검증해야 목표 SLO를 만족시킬 수 있습니다. GPU가 VM에 직접 할당되더라도 CPU 코어 수, 메모리 용량, 스토리지 I/O 성능, 네트워크 경로가 함께 성능에 영향을 주기 때문에, 대형 모델 서빙에서는 GPU 연산 자체보다 모델 로딩과 토큰화, KV Cache 관리가 병목이 되는 경우가 더 많습니다.

이런 검증과 관리 부담을 줄여주는 것이 SCP GPUaaS의 GPU Server(GPU VM)입니다. 웹 콘솔 기반으로 GPU VM 생성부터 드라이버·프레임워크 버전 관리, 네트워크 격리까지 별도 구축 없이 처리할 수 있습니다.

② 다중 노드·분산 처리: MNGC (Multi-Node GPU Cluster)

"GPU를 두 배로 늘리면 학습 시간도 절반이 될까?" 실제로는 그렇지 않은 경우가 많습니다. 모델과 데이터가 커지면 여러 GPU 서버를 연결해 쓰게 되는데, 이때 학습 시간을 좌우하는 것은 GPU 개수가 아니라 GPU 간 통신 속도와 데이터 공급 성능입니다. 여러 GPU가 계산 결과를 동기화하는 All-Reduce, All-to-All 같은 통신이 느리면 GPU는 계산을 마치고도 다른 GPU를 기다리게 되고, 스토리지가 체크포인트와 학습 데이터를 충분히 빠르게 공급하지 못하면 마찬가지로 연산 성능을 다 쓰지 못합니다.

이런 병목은 서버 내부와 서버 사이, 두 구간에서 각각 다른 방식으로 해결됩니다. GPU 서버 내부에서는 NVLink와 NVSwitch가 GPU 간 고속 통신 통로 역할을 하고, 여러 서버를 넘어서는 구간에서는 InfiniBand 네트워크와 GPUDirect RDMA(GPU 메모리끼리 CPU를 거치지 않고 직접 데이터를 주고받는 기술)가 그 역할을 대신합니다.^[1][2][3] 이 두 구간 모두 충분한 대역폭과 낮은 지연시간을 확보해야, GPU 수를 늘린 만큼 실제 처리량도 안정적으로 늘어나는 확장성을 얻을 수 있습니다.

[그림 3] B300 기준 NVLink·NVSwitch, InfiniBand와 병렬 스토리지로 구성한 MNGC 개념 (작성자 제작)

Multi-Node GPU Cluster 구조: 노드 내부와 노드 간 통신을 통합 설계

사용자 ↔ 인터넷 ↔ Bare Metal Server [NVSwitch - 1.8TB/s(B300)] ↔ InfiniBand Switch (GPU Direct RDMA 구간) ↔ Bare Metal Server [NVSwitch - 1.8TB/s(B300)] 고성능 SSD [Block Storage - File Storage - File Storage - Object Storage] 병렬 파일시스템 [Parallel File Storage - Parallel File Storage]

그래서 클러스터 규모를 정할 때는 GPU를 늘렸을 때 실제 처리량이 그만큼 늘어나는지를 보는 스케일링 효율, 체크포인트 저장이 전체 학습 시간을 얼마나 지연시키는지, 노드 장애 시 재개하는 데 걸리는 시간, 그리고 자원을 기다리는 대기시간까지 함께 확인해야 합니다. 또한 노드 하나의 장애가 전체 학습 작업에 영향을 줄 수 있으므로 상태 모니터링과 장애 복구 정책도 함께 갖춰야 합니다.

이러한 구성을 기업이 직접 설계하고 호환성을 검증하려면 상당한 시간과 전문성이 필요합니다. SCP MNGC는 GPU 서버, InfiniBand 네트워크, 고성능 스토리지를 사전에 검증된 구성으로 제공해 이 구축 부담을 줄이고, 고객이 모델 병렬화와 데이터 처리 최적화에 집중할 수 있게 합니다.

③ 반복 추론·전력 효율: NPU

추론이 개발 단계를 넘어 하루 종일 반복 실행되는 서비스로 자리 잡으면, 성능을 평가하는 기준 자체가 달라집니다. 이 단계에서 비용을 좌우하는 것은 최대 연산 성능이 아니라, 사용자 한 명당 체감하는 지연시간, 동시에 처리할 수 있는 요청 수, 전력 대비 처리량, 그리고 장비 밀도가 비용을 좌우하기 때문입니다.

NPU는 신경망 연산에 특화된 구조로 지원되는 모델과 연산에서는 작은 배치에서도 낮은 지연시간과 높은 전력당 처리량을 낼 수 있지만, 새로운 모델 구조나 연산 패턴이 등장했을 때는, 소프트웨어 관점에서 유연하게 대응할 수 있는 GPU만큼 빠르게 따라가기는 어렵습니다. 그래서 NPU 도입은 GPU를 대체하려는 결정이라기보다, 반복적이고 규모가 큰 추론 구간에 한해 이기종 가속기를 추가하는 결정에 가깝습니다.

SCP GPUaaS는 FuriosaAI RNGD^[4] 기반 NPU 서버를 VM 형태로 제공합니다. 이를 통해 NPU 전용 하드웨어를 별도로 구축 및 운영하는 부담 없이도, 자사 워크로드에 NPU가 실제로 맞는지를 먼저 시험해보고 도입할 수 있습니다.

동일 조건에서 비교해야 진짜 차이가 보인다

가속기의 성능을 비교할 때는 하드웨어 사양만 보는 것보다 어떤 조건에서 측정했는지가 중요합니다. AI 모델 버전과 데이터, 입력·출력 길이, 동시 요청 수, 정확도와 품질 기준, 측정 시간과 오류 처리 방식을 동일하게 맞춰야 실제 성능 차이를 확인할 수 있습니다. 가능하다면 연산 정밀도와 배치 크기도 같은 조건으로 맞춰 하드웨어와 소프트웨어 환경의 차이를 비교하는 것이 좋습니다.

측정 항목은 학습과 추론에 따라 달라집니다. 학습에서는 전체 학습 시간, GPU를 늘렸을 때의 성능 향상 정도, 토큰·샘플 처리량, 체크포인트 저장에 걸리는 시간, 장애 후 재시작 시간을 확인해야 합니다. 추론에서는 첫 토큰이 나오기까지의 시간, 토큰 생성 간 지연시간, 초당 처리 가능한 토큰 및 요청 수, 동시 사용자 수, 백만 토큰당 비용과 장시간 운영 안정성을 살펴봐야 합니다. 또한 GPU와 NPU를 비교할 때는 여기에 모델과 연산자 지원 범위, 컴파일 및 변환에 필요한 시간, 출력 품질 변화, 장애 분석 난이도 까지 함께 봐야 합니다.

이렇게 동일한 조건에서 비교하면 단순히 “GPU가 더 빠르다”거나 “NPU가 더 저렴하다”는 일반적인 평가를 넘어, 자사 워크로드에서 어떤 구성이 목표 품질과 SLO를 가장 합리적인 비용으로 만족하는지 구체적으로 판단할 수 있습니다.

SCP 서비스로 보는 적용 예시

SCP GPUaaS 서비스는 GPU Server와 NPU, MNGC 등 다양한 AI 가속기 인프라를 워크로드 특성에 맞게 선택할 수 있도록 제공합니다.^[4][5][6] 핵심은 각 서비스가 따로 존재하는 것이 아니라 같은 콘솔과 네트워크·스토리지 체계 위에서 연결되어 있다는 점입니다. 이를 통해 사용자는 GPU Server에서 검증한 워크로드를 바탕으로 기존 데이터 경로와 인프라 구성을 최대한 활용하면서, 필요에 따라 MNGC나 NPU로 확장할 수 있습니다.

SCP GPUaaS 인프라 서비스는 향후 NVIDIA Rubin 기반 차세대 시스템을 비롯해 AMD GPU와 국산 NPU까지 가속기 포트폴리오를 지속 확대하고, 인프라 가상화와 분할 기술을 적용해 자원 활용의 유연성과 선택의 폭을 높이는 방향으로 발전할 예정입니다.

도입 체크리스트

실제 도입을 검토하고 있다면 다음 순서로 접근하시길 권장합니다.
1. 실제 모델 벤치마크: 목표 서비스에 사용할 모델을 GPU Server, MNGC, NPU Server 등 후보 인프라에서 동일 조건으로 테스트해 성능과 비용을 비교합니다.
2. 데이터 경로 확인: 학습 데이터와 모델 아티팩트의 저장 위치, 접근 권한, 외부 반출 통제 방안을 서비스 설계 단계에서 확정합니다.
3. 운영 조건 검증: 네트워크·권한 분리, 표준 이미지, 사용량 계측, 장애 모니터링과 기술지원 체계가 충족되는지 확인합니다.
4. 단계적 확장: 검증 결과를 바탕으로 소규모 파일럿부터 시작해 실제 서비스 규모에 맞게 인프라를 단계적으로 확대합니다.

GPU 견적보다 워크로드 정합성이 먼저다

GPU의 최고 사양을 확보하는 것과 우리 워크로드에 맞는 AI 인프라를 확보하는 것은 다른 문제입니다. 동일한 가속기라도 모델 구조와 메모리 요구량, 데이터 경로, 통신 방식, 트래픽 패턴과 운영 조건에 따라 실제 성능과 비용은 크게 달라질 수 있습니다. 따라서 인프라 검토는 장비명과 수량을 정하는 일보다, 워크로드와 성공 기준을 수치로 정의하는 일에서 시작해야 합니다.

때문에 특정 GPU에 대한 견적보다, 실제 모델과 트래픽을 기준으로 한 워크로드 프로파일과 벤치마크 기준을 먼저 수립해야 할 것입니다. 이후 동일한 품질과 SLO를 충족하는 조건에서 학습 완료시간, 요청 지연시간, 장애 복구, 운영 복잡성과 총비용을 함께 측정해야 합니다.

좋은 AI 인프라 의사결정을 위해서는 가장 빠른 장비를 선택하는 것보다 가장 합리적인 비용과 전환 위험으로 목표 품질과 SLO를 반복해서 달성할 수 있는 구조를 만드는 것이 중요합니다. 특정 GPU 세대나 수량을 먼저 확정하기보다, 실제 워크로드를 기준으로 2~3개의 후보 구성에 동일한 파일럿 종료 기준을 적용하는 것부터 시작해야 합니다. 그 결과가 향후 확장과 투자 판단을 뒷받침하는 가장 신뢰할 수 있는 근거가 될 것입니다.

References

• NVIDIA, “NVIDIA H100 Tensor Core GPU.”
• NVIDIA, “NVIDIA DGX B300.”
• NVIDIA, “NVIDIA HGX Platform.”
• FuriosaAI, “FuriosaAI and Samsung SDS Launch Korea’s First Domestic NPUaaS,” July 20, 2026.
• 삼성SDS, “삼성 클라우드 플랫폼 GPUaaS.”
• 삼성SDS, “Samsung SDS Unveils B300 GPU Service,” March 26, 2026.

FAQ