작업 부하 유형별로 AI 인프라를 먼저 선택해야 합니다. 왜냐하면 학습(training), 추론(inference), 그리고 AI 에이전트(AI agents)는 서로 다른 것을 필요로 하기 때문입니다. 학습에는 제한된 시간 동안 크고 밀접하게 연결된 GPU 클러스터가 필요하고, 추론에는 자동 스케일링과 높은 가용성을 갖춘 사용자 근처의 GPU가 필요하며, 에이전트에게는 격리된 샌드박스(sandboxes), 도구 및 데이터에 대한 안전한 접근 권한, 그리고 감사 기록(audit trails)이 필요합니다. 대부분 성장하는 기업들은 학습보다는 추론과 에이전트에 가장 많은 노력을 기울이며, 따라서 가장 중요한 결정은 모델이 어디에서 서비스되는지, 용량이 어떻게 확보되는지, 그리고 에이전트의 행동이 어떻게 격리되고 기록되는지에 관한 것입니다.
공개 고지: Control Plane에서 이 가이드를 게시합니다. 다른 제공업체들은 자체 페이지에서 설명되며, 2026년 10월에 인라인으로 연결 및 확인되었습니다.
요약 (TL;DR)
- **학습(Training)**은 빠른 상호 연결(fast interconnects)을 갖춘 많은 GPU가 필요한 제한된 시간의 작업입니다. 하이퍼스케일러(hyperscaler)나 GPU 클라우드에서 임대하거나, 활용률이 안정적이라면 전용 하드웨어를 구매할 수 있습니다.
- **추론(Inference)**은 24/7 서비스입니다. 자동 스케일링, 준비 상태 확인(readiness checks), 다중 리전 배치, 그리고 요청당 비용 보기(cost-per-request view)가 필요합니다.
- **에이전트(Agents)**는 생성된 코드를 실행하고 도구를 호출합니다. 이들은 샌드박스, 최소 권한 접근(least-privilege access), 내부 데이터에 대한 사설 연결성, 속도 제한(rate limits), 그리고 감사 로그를 필요로 합니다.
- 하이퍼스케일러, GPU 클라우드, 자체 하드웨어는 배타적이지 않습니다. 많은 팀들이 두세 가지를 사용하며, 이는 이식성(portability)을 요구사항으로 만듭니다.
- 하나의 GPU 제공업체에 종속되는 것을 피하기 위해, 서비스 계층을 여러 제공업체에 걸쳐 실행하여 한 곳에서의 용량 부족이나 중단이 트래픽을 멈추게 하지 않도록 합니다.
- Control Plane은 모든 클라우드, neocloud 또는 자체 GPU 서버에서 하나의 글로벌 가상 클라우드(Global Virtual Cloud) 내에서 추론 서비스와 에이전트를 능동-능동(active-active)으로 실행합니다. 99.999%의 가용성 SLA는 최소 두 개의 리플리카를 최소 두 위치에서 실행되는 워크로드에 적용됩니다.
AI 준비가 된 인프라란 실제로 무엇을 의미하는가
AI-ready 인프라는 모델과 에이전트를 프로덕션 환경에서 훈련(train), 서비스(serve), 운영(operate)할 수 있도록 컴퓨팅(compute), 네트워크(network), 스토리지(storage), 오케스트레이션(orchestration), 옵저버빌리티(observability), 보안(security) 기능을 갖춘 세트입니다. 이 인프라 덕분에 새로운 워크로드마다 스택을 재구축할 필요가 없습니다.
- 컴퓨팅 (GPU 및 가속기). GPU 메모리는 어떤 모델이 하나의 장치에 들어갈 수 있는지를 결정하며, GPU의 개수와 그들 간의 상호 연결(interconnect)은 얼마나 큰 모델을 여러 장치에 분할하여 처리할 수 있는지를 결정합니다. NVIDIA는 L4를 24 GB, 72W 저전력 PCIe 카드로, 그리고 H100 SXM을 80 GB로 제시합니다. 이는 가벼운 서비스에는 작은 카드(small cards)를, 더 큰 모델과 훈련에는 더 큰 파트를 사용한다는 의미입니다.
- 네트워킹. 여러 GPU에 걸쳐 훈련하는 것은 GPU와 노드 간의 빠른 링크에 의존하기 때문에, Lambda와 Nebius는 인피니밴드(InfiniBand)로 연결된 클러스터를 설명합니다. 추론(Inference)은 다른 종류의 네트워킹을 필요로 합니다: 정상적인 위치로의 글로벌 라우팅, 내부 데이터로의 사설 경로(private paths), 그리고 서비스 간 암호화된 트래픽이 필요합니다.
- 스토리지 및 데이터 접근. 모델 가중치(Model weights)는 크기가 큰 파일이며 새로운 복제본(replica)에 빠르게 로드되어야 합니다. 또한 에이전트와 검색 파이프라인은 비즈니스 데이터에 대한 통제된 접근(governed access)이 필요합니다.
- 오케스트레이션 및 스케일링. 누군가가 워크로드를 GPU에 배치하고, 복제본을 확장하며, 복제본이 준비될 때까지 트래픽을 유지하고, 새로운 모델 버전을 안전하게 배포해야 합니다. 쿠버네티스(Kubernetes)가 일반적인 기반이며, 많은 팀들이 자신들이 클러스터를 직접 운영하지 않기 위해 그 위에 추가 계층(layer)을 원합니다.
- 옵저버빌리티. GPU 워크로드는 CPU 서비스와는 다른 방식으로 실패합니다. 예를 들어 메모리 고갈(memory exhaustion), 큐 축적(queue buildup), 느린 모델 로드 등이 있습니다. 따라서 요청 경로 전체와 GPU에 걸쳐 메트릭, 로그, 트레이스뿐만 아니라 모델당 및 요청당 비용까지 파악해야 합니다.
- 보안 및 격리. 모델은 민감한 데이터에 접근하며, 에이전트는 아무도 검토하지 않은 코드를 실행할 수 있습니다. 따라서 테넌트 격리(tenant isolation), 비밀 관리(secrets management), 단기 자격 증명(short-lived credentials), 서비스 간 상호 TLS(mutual TLS), 그리고 감사 추적(audit trail)이 필요합니다.
학습(Training) vs 추론(Inference) vs 에이전트(Agents)
| 차원 | 학습 (Training) | 추론 (Inference) | AI 에이전트 (AI agents) |
|---|
| 작업 부하가 하는 일 | 데이터로부터 모델을 구축하거나 미세 조정함 | 훈련된 모델을 사용자 및 애플리케이션에 제공함 | 작업을 완료하기 위해 계획하고, 도구를 호출하며, 코드를 실행함 |
| ... | | | |
| Google Cloud의 AI Hypercomputer 가이드는 유사한 분할을 제시하며, 사전 학습(pre-training), 미세 조정(fine-tuning), 추론 또는 서비스 제공(serving), 그리고 소형 또는 중형 모델을 별개의 사례로 취급합니다: 사전 학습 및 미세 조정을 위한 예약 용량과 추론을 위한 예약, 온디맨드 또는 Spot 용량을 구분합니다. | | | |
어디서 실행할 것인가: 하이퍼스케일러(hyperscaler), GPU 클라우드, 또는 자체 하드웨어
AI를 기존 클라우드 서비스와 함께 사용하고 싶다면 하이퍼스케일러를, GPU 접근성과 클러스터 성능이 가장 중요하다면 GPU 클라우드를, 그리고 활용률이 안정적이고 통제권을 원한다면 자체 또는 코로케이션(colocated) 하드웨어를 사용합니다. 아래 순서는 순위가 아닙니다.
하이퍼스케일러: AWS, Google Cloud, Azure
강점. 나머지 클라우드 서비스와 함께하는 GPU: ID, 네트워킹, 스토리지, 데이터베이스 및 관리형 서비스를 포함합니다. AWS는 Amazon SageMaker AI, Amazon EKS, 그리고 EC2 UltraClusters에서 GPU 인스턴스를 예약하기 위한 EC2 Capacity Blocks를 사용하여 학습 및 추론을 위한 AI 인프라를 설명하며, 학습 및 HPC용 P5 인스턴스를 나열합니다. Google Cloud는 A4부터 B200 및 GB300 시스템에 이르는 NVIDIA GPU 머신 유형을 나열하며, A4, A4X, A4X Max 시리즈를 포함하고, 그 AI Hypercomputer는 Google Kubernetes Engine 및 Slurm과 통합됩니다. Azure는 HPC 솔루션 내에서 GPU 가상 머신을 제공하며, 스토리지, Azure Batch, 그리고 Foundry Tools를 함께 제공합니다.
트레이드오프(Trade-offs). GPU 접근은 할당량(quotas), 예약(reservations), 지역별 가용성에 의해 통제되며, 각 제공업체의 AI 서비스는 자체 API와 ID 모델을 가지고 있어, 상위 계층이 포터블하지 않다면 서빙 스택을 하이퍼스케일러 간에 이동하는 것은 많은 작업이 필요합니다.
최적의 선택(Best fit). 데이터, ID, 규정 준수 통제가 이미 하나의 하이퍼스케일러 내에 존재하는 팀.
GPU 클라우드 및 네오클라우드: CoreWeave, Lambda, Nebius
강점(Strengths). CoreWeave는 GPU 컴퓨팅, 베어메탈 서버, 관리형 Kubernetes, 모델 학습 및 서빙을 갖춘 AI 클라우드를 설명합니다. Lambda는 NVIDIA GPU 기반의 셀프서비스 GPU 인스턴스, 1-Click 클러스터, 단일 테넌트 슈퍼클러스터를 나열하며 SOC 2 Type II 인증 상태임을 명시합니다. Nebius는 InfiniBand를 사용하고 내장된 MLOps 도구와 서버리스 및 관리형 추론을 제공하는 비가상화 GPU를 설명합니다.
트레이드오프(Trade-offs). 네오클라우드는 하이퍼스케일러의 전체 카탈로그가 아닌 GPU와 그 주변 서비스를 다루므로, 이를 사용자의 ID, 네트워킹 및 데이터에 연결해야 합니다. 두 번째 스택을 실행하지 않고 네오클라우드를 추가하는 방법을 참조하세요.
최적의 선택(Best fit). GPU 용량, 클러스터 성능 또는 최신 GPU 세대가 필요하며, 그 위에 서빙 계층이 필요한 팀.
자체 보유 또는 코로케이션 하드웨어: Dell, HPE, Supermicro
장점. GPU 구성, 데이터 위치 및 안정적 활용률에서의 장기 단위 비용을 통제할 수 있습니다. Dell은 NVIDIA HGX B300이 포함된 구성을 포함하여 AI 트레이닝, 대규모 추론(inference), HPC를 위한 PowerEdge XE 시리즈 서버를 나열합니다. HPE는 NVIDIA B200 및 B300 옵션으로 AI 트레이닝, 튜닝(tuning), 추론을 위한 ProLiant Compute XD685 및 Compute XD690 서버를 나열합니다. Supermicro는 공랭식 및 액랭식 HGX B300 및 B200 시스템, GB300 NVL72 랙, 그리고 랙 레벨 통합을 나열합니다.
트레이드오프. 조달 리드 타임(Procurement lead time), 전력 및 냉각, 하드웨어 수명 주기, 운영팀이 필요하며, 활용률에 따라 비용 효율성이 결정됩니다.
최적의 적합성. 데이터 상주지 또는 주권 요구 사항, 안정적인 고활용률, 또는 맞춤형 GPU 구성을 가진 팀입니다.
핵심 인프라 대 AI 전용 인프라
| 계층 | 제공업체 페이지 예시 | 제공하는 것 |
|---|
| 핵심 인프라 (Core infrastructure) | AWS EC2, Google Compute Engine, Azure Virtual Machines | GPU가 연결되는 범용 컴퓨팅, 네트워킹 및 스토리지 |
| ... | | |
프로덕션에서의 추론: 대부분의 팀이 과소평가하는 부분
트레이닝 실행은 끝나지만, 추론(inference) 실행은 사용자, 지연 시간 목표(latency targets), 그리고 가동 시간 기대치와 함께 서비스로 지속됩니다. 또한 AI 기능을 추가하는 회사들의 GPU 지출 대부분이 종종 이 추론 계층에서 발생합니다. 추론 계층 가이드는 GPU 크기 결정 및 서비스 메트릭을 포함하여 전체 스택을 다룹니다. 가장 중요한 결정 사항들은 다음과 같습니다:
- CPU가 아닌 요청률(request rate), 지연 시간(latency) 또는 큐 깊이(queue depth)에 따라 자동 확장(Autoscale)합니다. 큐 깊이나 복제본당 처리 중인 요청 수(in-flight requests per replica)가 일반적으로 지연 시간보다 더 빠르게 반응합니다.
- 어떤 모델을 따뜻하게 유지할지 결정합니다. 사용자에게 노출되는 모델은 따뜻하게 유지하고, 느린 첫 번째 요청이 허용되는 내부 또는 트래픽이 적은 모델은 축소(scale down)합니다.
- 준비 상태(readiness)를 기준으로 트래픽을 제어합니다. 시작된 복제본이라도 아직 모델을 로드하지 않았을 수 있기 때문입니다.
- 여러 리전 또는 제공업체에서 운영합니다. 모든 리전이나 제공업체는 장애가 발생하거나 용량이 부족할 수 있으므로, 동일한 서비스를 여러 위치에 배포하고 각 요청을 정상적인 곳으로 라우팅해야 합니다. [multi-cloud failover solutions]를 참조하세요.
- 여러 제공업체에 걸쳐 GPU 용량을 확보합니다. 가격과 가용성이 변하기 때문에, 서비스 계층이 특정 제공업체에 의존하지 않도록 여러 곳에서 GPU 용량을 확보하는 것이 중요합니다. [how to combine GPU capacity across providers]를 참조하세요.
- 요청당 비용을 추적합니다: (지연 시간 목표 달성을 위한) 시간당 GPU 복제본 비용을 시간당 처리된 요청 수로 나눕니다.
프로덕션 환경의 에이전트(Agents)
에이전트는 액션을 취하기 때문에 추론 서비스와 다릅니다. 즉, 생성된 코드를 실행하고, API를 호출하며, 내부 데이터를 읽습니다. 가장 중요한 네 가지 제어 사항은 다음과 같습니다:
- 신뢰할 수 없거나 생성된 코드용 격리 샌드박스(Isolated sandboxes): 호스트, 다른 테넌트 또는 사용자의 네트워크로 기본적으로 접근할 수 없어야 합니다. MicroVM 기반의 격리가 일반적인 접근 방식이며, 상태가 작업 간에 지속되지 않도록 샌드박스는 일시적(ephemeral)이어야 합니다.
- 저장된 키 대신 단기 자격 증명(Short-lived credentials): 장기간 유지되는 클라우드 키는 코드, 로그 및 이미지를 통해 유출될 수 있기 때문입니다. [workload identity federation]을 참조하세요.
- 내부 데이터에 대한 최소 권한 접근(Least-privilege access): VPC 및 온프레미스 시스템으로의 사설 네트워킹을 통해 내부 데이터에 접근해야 합니다.
- 요청 제한(Rate limits) 및 감사 추적(audit trails): 루프나 프롬프트 주입(prompt injection)이 비용을 증가시키거나 손상을 입히는 것을 방지하고, 모든 행동이 기록되어야 합니다.
24/7 모델 서빙을 위한 관측 가능성 및 운영
요청 경로와 GPU를 계측하고, 사용자에게 보이는 증상부터 경고하며, 롤아웃(rollout)을 되돌릴 수 있도록 만드세요:
- 메트릭스 (Metrics): 지연 시간 백분위수(첫 토큰까지의 시간 포함), 처리량(throughput), GPU 활용률 및 메모리, 대기열 깊이(queue depth), 유형별 오류율, 요청당 비용.
- 로그 및 트레이스 (Logs and traces): 요청 ID, 모델 버전, 입력 및 출력 크기, 결과와 함께 게이트웨이, 검색(retrieval), 모델, 도구 전반에 걸친 트레이스. 데이터 정책이 허용하는 경우가 아니라면 프롬프트와 출력을 로그에 포함하지 마세요.
- 경고 (Alerting): 오류율, 목표 대비 지연 시간, 대기열 깊이에 대해 알림을 설정하고; 비용 및 활용도 신호를 티켓 대기열로 라우팅하세요.
- 롤아웃 (Rollouts): 모든 모델 버전을 배포(deploy)로 취급하고, 점진적으로 출시하며, 준비 상태에 따라 트래픽을 제한하고, 이전 버전이 빠른 롤백을 위해 준비되도록 하세요.
- 온콜 (On-call): 지연 시간 및 가용성에 대한 SLO(Service Level Objectives)를 설정하고, GPU 메모리 부족, 용량 부족, 느린 모델 로드, 제공업체 중단에 대한 운영 매뉴얼(runbooks)을 작성하며, 장애 조치를 리허설하세요.
AI 인프라 선택 결정 체크리스트