콘텐츠로 이동

멀티클라우드 AI

문서 기준: 2026년 8월 | 이 문서는 변동이 빠른 영역으로 분기별 리뷰 대상입니다.

각 클라우드 벤더는 AI/ML 영역에서 서로 다른 강점을 가지고 있습니다. 단일 벤더에 종속되지 않고 워크로드 특성에 맞는 최적의 서비스를 조합하면 비용, 성능, 모델 다양성 측면에서 이점을 얻을 수 있습니다.

  • AWS — Amazon Bedrock/SageMaker AI. 최대 규모 모델 카탈로그 + 자체 AI 칩(Trainium/Inferentia)
  • Azure — Microsoft Foundry. OpenAI GPT 시리즈 주력 + Microsoft 생태계 통합
  • Google Cloud — Gemini Enterprise Agent Platform. 자체 Gemini 멀티모달 + TPU 인프라
  • OCI — OCI Enterprise AI. Dedicated AI Cluster(RDMA 전용 GPU) + 이그레스 10TB 무료

AI 학습 및 추론에 필수적인 GPU 인스턴스를 주요 CSP별로 비교합니다.

현재 클라우드에서 제공되는 주요 NVIDIA 데이터센터 GPU의 스펙 비교입니다.

항목 H100 (Hopper) H200 (Hopper) B200 (Blackwell) GB200 (Blackwell)
메모리 80GB HBM3 141GB HBM3e 192GB HBM3e 384GB (2×192GB)
대역폭 3.35 TB/s 4.8 TB/s 8.0 TB/s 16 TB/s (Superchip)
NVLink 900 GB/s 900 GB/s 1.8 TB/s NVL72 도메인
TDP 700W 700W 1000W 1200W (Superchip)
적합 워크로드 학습/추론 범용 대규모 추론, 긴 컨텍스트 차세대 학습 조 단위 파라미터 프론티어 모델
메모리 (H100 대비) ~1.8× ~2.4× ~4.8× (2×B200 합산)

선택 가이드:

  • H100/H200 — 리전 가용성이 상대적으로 넓음. 중규모 학습, Fine-tuning, 일반 추론에 적합. H200은 H100과 동일 아키텍처 계열이며 메모리·대역폭이 커 긴 컨텍스트 추론에 유리
  • B200 — 2026년 주력 세대 후보. H100 대비 메모리·대역폭이 크고, 네이티브 FP4 등으로 양자화 추론 효율이 높은 편. 실제 처리량은 워크로드별로 측정
  • GB200 NVL72 — Grace CPU + B200 GPU를 Superchip으로 결합. 다수 GPU를 단일 NVLink 도메인으로 묶어 초대형 모델 학습에 사용. 가용 리전·약정 확보가 제한적일 수 있음
항목 AWS Azure Google Cloud OCI
B200 (Blackwell) P6-B200 (8×B200 180GB) ND GB200-v6 A4 (8×B200) BM.GPU.B200.8 (8×B200)
GB200 (NVLink) P6e-GB200 UltraServer (최대 72 GPU) ND GB200-v6 (NVLink 도메인) A4X (GB200 NVL72)
H100 인스턴스 p5.48xlarge (8×H100 80GB) ND H100 v5 (8×H100 80GB) a3-highgpu-8g (8×H100 80GB) BM.GPU.H100.8 (8×H100 80GB)
A100 인스턴스 p4d.24xlarge (8×A100 40/80GB) ND A100 v4 (8×A100 80GB) a2-highgpu-8g (8×A100 80GB) BM.GPU.A100-v2.8 (8×A100 80GB)
RTX PRO / 추론 특화 G7 (NVIDIA RTX PRO 4500 Blackwell)
자체 AI 칩 Trainium2 (Trn2), Inferentia2 (Inf2) Maia 100 TPU v8 (8세대)
예약 옵션 Reserved Instances, Savings Plans Reserved VM Instances CUD (Committed Use Discount) Capacity Reservation
스팟/선점형 Spot Instances Spot VMs Spot VMs (Preemptible) Preemptible Instances

RAG(Retrieval-Augmented Generation) 파이프라인은 Vector DB, Embedding 모델, LLM, 오케스트레이션의 조합으로 구성됩니다. 각 벤더별 주요 서비스:

  • AWS — OpenSearch Serverless + Titan Embeddings + Bedrock Knowledge Bases
  • Azure — AI Search + Microsoft Foundry + Azure AI Studio
  • Google Cloud — Vertex AI Vector Search + Gemini Embedding + RAG Engine
  • OCI — OCI Search/Oracle 23ai + Cohere Embed + Enterprise AI Agents
패턴 설명 적합한 경우
단일 CSP AI 플랫폼 한 클라우드의 모델, 데이터, 배포 도구를 모두 사용 운영 단순성이 가장 중요할 때
모델 분산 모델은 여러 CSP의 API를 쓰고, 애플리케이션은 한 곳에서 운영 모델 품질과 비용을 비교하며 선택해야 할 때
데이터 근접형 데이터가 있는 클라우드에서 임베딩·검색·추론을 수행 데이터 이동 비용이나 규제가 중요할 때
중앙 RAG 플랫폼 하나의 공통 RAG 계층에서 여러 CSP 모델을 호출 조직 전체에 공통 AI 플랫폼을 제공할 때
  • 데이터 이동 비용 — 대량 문서, 임베딩, 로그를 클라우드 간 이동하면 이그레스 비용이 커질 수 있습니다.
  • 데이터 주권 — 개인정보, 금융 데이터, 의료 데이터는 저장 위치와 처리 위치를 명확히 해야 합니다.
  • 모델 의존성 — 특정 모델의 API 형식, 토큰 제한, 함수 호출 방식에 종속되지 않도록 추상화 계층을 둡니다.
  • 관찰가능성 — 프롬프트, 응답, 토큰 사용량, 지연 시간, 비용을 함께 모니터링합니다.
  • 보안 — 프롬프트 인젝션, 민감정보 유출, 과도한 에이전트 권한을 통제해야 합니다.
  • 모든 벤더의 AI 서비스를 동시에 도입 — 멀티클라우드 AI는 필요한 조합만 선택하는 것인데, 모든 벤더를 병행하여 운영 복잡도와 비용이 폭증
  • 데이터 이동 비용을 사전에 산정하지 않음 — 임베딩, 문서, 로그를 클라우드 간 이동하면 이그레스 비용이 예상보다 크게 발생
  • 모델 API 형식에 직접 종속 — 추상화 계층 없이 특정 벤더의 함수 호출 방식에 코드를 맞추어 모델 교체가 어려워짐
  • 멀티클라우드 AI 도입 사유(모델 품질, 비용, 규제)를 명확히 정의했는가
  • 데이터 이동 비용(이그레스)을 사전에 산정하고 데이터 근접형 아키텍처를 검토했는가
  • 모델 호출에 추상화 계층(LangChain 등)을 두어 벤더 교체가 가능한 구조인가