클라우드 개요
클라우드는 서비스 이름을 외우는 것보다 공통 구조를 이해하는 것이 먼저입니다. 공통 구조를 이해하면 벤더가 달라도 운영 원칙을 유지할 수 있습니다.학습 목표
- 계정/리전/네트워크/권한/비용의 관계를 설명할 수 있습니다.
- 3대 클라우드(AWS/Azure/GCP) 서비스 대응 관계를 이해합니다.
- AI/ML 워크로드 관점에서 클라우드 선택 기준을 세울 수 있습니다.
- 초기 설계 실수(권한, 네트워크, 비용)를 예방할 수 있습니다.
왜 중요한가
AI/ML 프로젝트의 성패는 모델 성능만으로 결정되지 않습니다. GPU 확보, 데이터 전송 비용, 보안 통제, 모니터링 등 인프라 운영 역량이 서비스 안정성을 좌우합니다. 클라우드 기본 구조를 이해하면, 어떤 벤더를 사용하든 같은 원칙으로 운영할 수 있습니다.공통 구조 5계층
| 계층 | 역할 | AWS | Azure | GCP |
|---|---|---|---|---|
| 계정/프로젝트 | 과금, 권한, 감사 기준점 | Account | Subscription | Project |
| 네트워크 | 격리, 라우팅, 보안 | VPC | VNet | VPC |
| 컴퓨팅 | VM, 컨테이너, 서버리스 | EC2, EKS, Lambda | VM, AKS, Functions | CE, GKE, Cloud Run |
| 데이터 | 객체/블록/파일 저장소 | S3, EBS, EFS | Blob, Disk, Files | GCS, PD, Filestore |
| 운영 | 모니터링, 알림, 비용 | CloudWatch | Azure Monitor | Cloud Monitoring |
클라우드 서비스 대응 비교
| 기능 | AWS | Azure | GCP |
|---|---|---|---|
| ML 플랫폼 | SageMaker | Azure ML | Vertex AI |
| LLM API | Bedrock | Azure OpenAI | Vertex AI (Gemini) |
| 컨테이너 오케스트레이션 | EKS | AKS | GKE |
| 서버리스 컨테이너 | Fargate | Container Instances | Cloud Run |
| 객체 저장소 | S3 | Blob Storage | Cloud Storage |
| 비밀정보 관리 | Secrets Manager | Key Vault | Secret Manager |
| IAM | IAM | Microsoft Entra ID | IAM |
| 데이터 분석 | Athena, Redshift | Synapse Analytics | BigQuery |
| 비용 관리 | Cost Explorer, Budgets | Cost Management | Billing Reports |
AI/ML 관점 GPU 가용성 비교
| GPU | AWS | Azure | GCP |
|---|---|---|---|
| A10G | g5 시리즈 | NV A10 v5 | a2 시리즈 |
| A100 40GB | p4d | NC A100 v4 | a2-highgpu |
| A100 80GB | p4de | ND A100 v4 | a2-ultragpu |
| H100 | p5 | ND H100 v5 | a3 시리즈 |
| TPU | - | - | v4, v5e, v5p |
| Spot/선점형 | Spot Instance | Spot VM | Preemptible/Spot VM |
GPU 가용성은 리전에 따라 크게 다릅니다. 특히 H100은 모든 클라우드에서 수요가 높아 사전 쿼터 신청이 필수입니다.
TPU는 GCP에서만 사용 가능하며, JAX/TensorFlow 워크로드에 최적화됩니다.
AI/ML 관점 우선순위
클라우드를 선택할 때 다음 4가지를 비교하세요.- GPU 가용성: 원하는 리전에서 원하는 GPU를 확보 가능한가?
- 데이터 이동 비용: 스토리지/서비스 간 egress 비용은 어떤가?
- 보안 통제: IAM, KMS, Secret Manager 운영이 쉬운가?
- 관측성: 지연시간/비용/오류를 통합 모니터링 가능한가?
멀티클라우드 전략
언제 멀티클라우드를 고려하는가
| 상황 | 접근 방식 |
|---|---|
| 특정 GPU가 한 벤더에서만 가용 | 학습은 GCP(TPU), 서빙은 AWS(Inf2) |
| 고객 요구로 특정 클라우드 필수 | 핵심 서빙은 고객 클라우드, 내부 도구는 주력 클라우드 |
| 벤더 종속(lock-in) 회피 | 컨테이너(K8s) 기반으로 이식성 확보 |
| 장애 대응(DR) | 주력 + 백업 클라우드 구성 |
멀티클라우드 운영 시 핵심
- 인증 통합: 각 클라우드의 IAM을 연결하거나, 중앙 IdP(Okta, Entra ID)를 사용합니다.
- 네트워크 연결: 클라우드 간 전용선(Interconnect) 또는 VPN을 구성합니다.
- 비용 통합: 클라우드별 비용을 하나의 대시보드에서 추적합니다.
- 컨테이너 표준화: K8s 기반으로 워크로드를 표준화하면 이식성이 높아집니다.
시작 순서(권장)
초보자가 많이 놓치는 것: 비용 경보
초보자가 많이 놓치는 것: 비용 경보
PoC 단계라서 비용 관리를 미루면, 리소스 미종료로 비용이 빠르게 누적됩니다.
시작일에 예산/경보를 같이 설정하세요. 특히 GPU 인스턴스는 시간당 비용이 높습니다.
벤더 비교를 단순화하는 방법
벤더 비교를 단순화하는 방법
서비스 이름이 아니라 4가지만 비교하세요.
- GPU 가용성 2) 네트워크/보안 운영 난이도 3) 관측성 통합 4) 총비용(TCO) 기능 차이보다 운영 경험과 팀 역량이 선택에 더 큰 영향을 줍니다.
온프렘/클라우드 혼합 운영 시 핵심
온프렘/클라우드 혼합 운영 시 핵심
데이터 위치, 인증 방식, 네트워크 연결(전용선/VPN), 로그 수집 경계를 먼저 고정해야 운영이 안정됩니다.
특히 데이터 이동 비용(egress)을 사전에 계산하세요.
클라우드 선택 의사결정 기준
클라우드 선택 의사결정 기준
기존 팀 역량(AWS 경험이 많으면 AWS), 고객 요구사항(특정 벤더 필수),
기술 요구사항(TPU 필요 시 GCP), 비용 구조를 종합적으로 고려하세요.
“최고의 클라우드”는 없고, 상황에 맞는 클라우드가 있습니다.
체크리스트
- 계정/프로젝트 분리 구조가 정의됐나요?
- 네트워크 경계(퍼블릭/프라이빗)가 설계됐나요?
- 비용 태깅과 예산 알림이 설정됐나요?
- GPU 가용성과 쿼터를 확인했나요?
- 모니터링 대시보드가 구성됐나요?