AWS 기술 블로그

Amazon EC2 Spot 인스턴스로 디지털 휴먼 렌더링하기

원문: Rendering Digital Humans with Amazon EC2 Spot Instances — Dario Macagnano, Jyothi Madanlal, 2026년 7월 10일 (AWS Physical AI Blog)

Amazon Web Services는 이 게시물에 기여해 주신 UneeQ 엔지니어링 팀에 감사드립니다

UneeQ는 실시간 고충실도(high-fidelity) 3D 렌더링을 통해 사실적인 표정을 표현하면서 자연스러운 대화를 나누는 AI 기반 디지털 휴먼(digital humans)을 만듭니다. Unreal Engine 같은 게임 엔진 위에 구축된 이런 연산 집약적 워크로드는 운영 자체가 본질적으로 복잡합니다. 그리고 그 복잡성은 규모가 커질수록 배가됩니다. 이 애플리케이션들은 특수한 하드웨어와 그래픽 요구사항을 수반하기 때문에, 가용성과 성능을 유지하면서 GPU 용량을 효율적으로 분배하는 일만으로도 상당한 인프라 과제가 됩니다. 여기에 사용자 세션, 매치메이킹, 스트리밍 서버를 동시에 조율해야 하는 컨테이너 런타임 환경까지 더해지면 복잡성은 한층 커집니다. 이렇게 제공되는 경험 하나하나가 GPU 인스턴스에서 집약적인 그래픽 처리를 요구하므로, 장애를 견디고(fault-tolerant) 스스로 복구되는(auto-healing) 인프라 관리가 근본적인 필수 요건이 됩니다.

Figure 1: Sophie, an AI-powered virtual being

그림 1: AI 기반 가상 존재(virtual being)인 Sophie

주요 과제로는 분산된 리소스 전반에 걸쳐 세션 할당을 관리하면서 비용을 최적화하고, 변동하는 사용자 부하에 맞춰 확장성을 유지하는 것을 들 수 있습니다. 전통적인 컨테이너 오케스트레이션만으로는 충분하지 않습니다. 특히 실시간 렌더링 콘텐츠를 여러 리전의 사용자에게 스트리밍하는 경우, 그래픽 집약적 애플리케이션 특유의 요구를 감당하려면 특화된 인프라가 필요합니다. GPU 인스턴스는 비용이 높은 만큼, 최상의 사용자 경험을 유지하면서 성능 요구와 리소스 활용도 사이에서 세심하게 균형을 잡는 비용 최적화가 특히 중요해집니다.

이 글에서는 UneeQ가 Amazon Elastic Kubernetes Service(Amazon EKS)와 Amazon EC2 스팟 인스턴스를 사용해 여러 리전에 걸쳐 GPU 리소스를 동적으로 관리하는 맞춤형 솔루션을 어떻게 구축했는지 살펴봅니다. UneeQ는 Unreal Engine의 픽셀 스트리밍 기술과, 자사의 Digital Human Operating System 및 특허받은 지능형 애니메이션 시스템 Synanim을 결합해 사용합니다. 디지털 휴먼은 웹 브라우저와 다양한 기기에 배포될 수 있으며, 금융 서비스, 뱅킹, 헬스케어, 교육 등 여러 산업에서 브랜드 앰배서더, 고객 경험, 임직원 교육 등의 용도로 활용됩니다.

UneeQ의 Digital Human Operating System은 최종 사용자와의 실시간 디지털 휴먼 상호작용에 일관된 가용성을 보장하면서 GPU 리소스를 효율적으로 관리해야 했습니다. 핵심 요구사항은 다음과 같습니다.

  • 비용 효율성: Amazon EC2 스팟 인스턴스를 전략적으로 활용해 디지털 휴먼당 비용을 낮추고, 목표로 하는 비용·성능 균형을 달성합니다.
  • 유연성: GPU 인스턴스 타입은 사양에 따라 동시에 구동할 수 있는 디지털 휴먼 수가 제각기 다릅니다. 세션당 실효 비용이 더 낮으면서 디지털 휴먼 4개를 구동하는 고성능 인스턴스는, 2개만 구동하는 저성능 인스턴스보다 본질적으로 더 가치가 높습니다. UneeQ의 Group Manager는 이 점을 우선순위로 반영해, 인스턴스 타입을 “서비스 실효 비용(effective cost to serve)” 기준으로 순위화해야 했습니다. 동시에, 스팟 가용성을 극대화하기 위해 가능한 한 넓은 범위의 GPU 인스턴스 타입을 지원하는 것도 그만큼 중요했습니다.
  • 확장성: 대화 수요에 따른 자동 확장.
  • 가동 시간(Uptime): 세션 유실이 허용되지 않는 고객 대면 배포를 위한 고가용성.

Amazon EC2 스팟 인스턴스는 사용되지 않는 EC2 컴퓨팅 용량을 온디맨드 대비 대폭 할인된 가격(경우에 따라 최대 90% 절감)으로 제공합니다. 인스턴스 비용이 운영비의 대부분을 차지하는 실시간 3D 렌더링 같은 GPU 집약적 워크로드에서 스팟 인스턴스는 전략적 필수 요소입니다.

하지만 이 절감 효과를 실현하는 데는 실질적인 복잡성이 따릅니다.

스팟 용량은 본질적으로 동적입니다. 가용성은 인스턴스 타입, 가용 영역(AZ), 리전에 따라 달라지며, 때로는 몇 분 단위로 변동합니다. 스팟 활용도를 극대화하려면 워크로드를 가능한 한 많은 호환 GPU 인스턴스 타입에 분산해야 합니다. UneeQ의 경우, 리전에 따라 최대 11가지 GPU 인스턴스 타입을 지원한다는 의미입니다.

UneeQ의 각 디지털 휴먼은 저마다 그래픽 충실도(graphic fidelity) 요구사항을 가지며, 이는 곧바로 머신 인스턴스의 리소스 요구사항으로 이어집니다. 각 디지털 휴먼은 Amazon EKS의 지정된 파드(pod)에서 실행되며, 하나의 노드가 수용할 수 있는 파드 수는 인스턴스 타입, 기반 GPU의 성능, 그리고 품질 설정·렌더링 해상도 같은 요인에 따라 달라집니다:

  • g5.4xlarge: 해상도에 따라 노드당 디지털 휴먼 2~5개
  • g6.4xlarge: 노드당 1~4개
  • g5.2xlarge: 노드당 1~2개

이 가변성은 비용에 엄청나게 중요합니다. UneeQ가 디지털 휴먼 80개를 구동해야 하는데 각 인스턴스 타입의 서로 다른 용량을 고려하지 않는다면, 과다 프로비저닝(비용 낭비) 또는 과소 프로비저닝(사용자 경험 저하) 중 하나가 발생합니다.

이제 계산을 살펴봅시다. 혼합 스팟 플릿으로 디지털 휴먼 80개를 구동한다면 조합은 다음과 같을 수 있습니다.

  • g5.4xlarge 12대 스팟 인스턴스 → 디지털 휴먼 48개 (12대 × 4개)
  • g6.4xlarge 9대 스팟 인스턴스 → 27개 (9대 × 3개)
  • g5.2xlarge 3대 스팟 인스턴스 → 6개 (3대 × 2개)

즉 24개 노드로 구성된 혼합 플릿에서 81개의 디지털 휴먼을 구동하는, 최적의 구성입니다. 하지만 이를 여러 인스턴스 타입과 여러 리전, 그리고 끊임없이 변하는 스팟 가용성에 걸쳐 수동으로 계산하는 것은 운영 관점에서 지속 가능하지 않습니다.

AWS는 여러 기본 스팟 할당 전략을 제공하며, 많은 워크로드에는 이것으로 충분합니다. lowest-price 전략은 현재 가격이 가장 낮은 스팟 풀에서 인스턴스를 할당합니다. capacity-optimized 전략은 가용 용량이 가장 많은 풀에서 선택함으로써 중단 위험을 줄입니다. price-capacity-optimized 전략은 이 둘의 균형을 꾀하며, diversified 분배는 복원력(resilience)을 위해 여러 풀에 인스턴스를 분산합니다.에 인스턴스를 분산합니다.

특정 크기 내에서는 어떤 인스턴스 타입이든 기능적으로 동등한 단순 컨테이너 워크로드라면, 이 전략들이 잘 동작합니다. 구현하는 쪽에서는 인스턴스 타입 유연성을 정의하고 원하는 할당 전략을 설정한 뒤, 나머지는 AWS에 맡기면 됩니다.

그러나 UneeQ의 워크로드는 이 모든 전략이 전제하는 근본 가정을 깨뜨립니다. 바로 “다양화된 풀 안의 모든 인스턴스가 동일한 수의 워크로드 단위를 동등하게 처리할 수 있다”는 가정입니다.

기본 스팟 할당 전략은 모든 노드를 서로 교체 가능한 것으로 취급합니다. 단가나 가용성을 최적화할 뿐, 워크로드 밀도(각 노드가 지탱할 수 있는 세션 수)라는 개념이 없습니다. g5.4xlarge는 디지털 휴먼 4개를 구동하지만, g5.2xlarge는 2개만 구동합니다. 이 2:1의 밀도 격차는 세션당 실효 비용과 쿠버네티스 전체 레플리카 수에 직접적인 영향을 줍니다. 워크로드 밀도를 절반으로 떨어뜨리는 저렴한 인스턴스는 결코 저렴한 것이 아닙니다. 오히려 스케줄링 오버헤드를 두 배로 늘리고, 겉보기의 비용 우위를 갉아먹습니다.

또한 기본 전략은 인스턴스 프로비저닝 계층에서 동작하기 때문에, 그 위에 있는 쿠버네티스 스케줄링 계층을 인지하지 못합니다. 그 결과 Auto Scaling 그룹 크기를 쿠버네티스 레플리카 수와 맞춰 조율하지 못하며, 리전 간 스팟 가격 변동을 반영해 비용과 용량을 동시에 고려하는 지능적인 배치 결정을 내리지도 못합니다.

기본 전략이 판단할 수 있는 범위와 UneeQ의 워크로드가 요구하는 것 사이의 이 간극이야말로, Group Manager를 만들게 된 동기입니다. Group Manager는 AWS 기본 전략이 애초에 제공하도록 설계되지 않은 “워크로드 인지형 지능(workload-aware intelligence)”을 스팟 할당에 부여하는 맞춤형 오케스트레이션 계층입니다.

Figure 2 — UneeQ Digital Human auto scaling architecture

그림 2 — UneeQ 디지털 휴먼 자동 확장 아키텍처

UneeQ는 Group Manager를 AWS Lambda 함수로 구축했습니다. 이 함수는 리전·인스턴스 타입 전반의 GPU 용량을 지속적으로 평가한 뒤, 원하는 수의 가용 디지털 휴먼을 유지하면서 스팟 활용도를 극대화하도록 인프라를 자동으로 조정합니다.

동작 방식은 다음과 같습니다.

2분마다 Amazon EventBridge 스케줄러가 Group Manager를 트리거합니다. 지원되는 인스턴스 타입·리전 전반의 현재 스팟 가용성과 가격을 평가한 뒤:

  1. 우선순위 가중 인스턴스 선택 알고리즘에 기반해 Auto Scaling 그룹(ASG) 크기를 조정합니다.
  2. KEDA(Kubernetes Event-driven Autoscaling) / HPA(Horizontal Pod Autoscaler)를 통해 쿠버네티스 배포 레플리카 수를 가용 노드 용량에 맞춰 업데이트합니다.
  3. Amazon EC2 스팟 인스턴스를 공격적으로 우선하며, 동등한 스팟 용량이 확보되는 즉시 온디맨드 인스턴스를 종료합니다.
  4. 구성된 우선순위에 따라 워크로드를 여러 리전에 분산해 가용성과 비용 효율을 동시에 극대화합니다.

Group Manager는 Amazon Simple Storage Service(Amazon S3)에 저장된 JSON 구성 파일을 사용하며, 이 파일은 인스턴스 타입 우선순위, 최대 가격, 노드당 파드 비율, 스케일링 임계값, 리전별 파라미터를 정의합니다.

JSON 구성 예시:

{     "node_groups": {         "gpu_cluster": {             "deployment_name": "digital-humans",             "namespace": "uneeq",\             "instance_types": {\                 "g5.4xlarge": {                     "pods_per_node": 4,                     "priority": 1,                     "max_price": "2.0"                 },                 "g6.4xlarge": {                     "pods_per_node": 3,                     "priority": 2,                     "max_price": "1.8"                 },                 "g5.2xlarge": {                     "pods_per_node": 2,                     "priority": 3,                     "max_price": "1.5"                 }             }         }     },     "scaling_parameters": {         "evaluation_interval": 120,         "min_nodes": 1,         "max_nodes": 20,         "scale_up_threshold": 0.8,         "scale_down_threshold": 0.4,         "cooldown_period": 300     },     "regions": {         "us-east-1": {             "enabled": true,             "priority": 1,             "max_instances": 50,             "availability_zones": ["us-east-1a", "us-east-1b", "us-east-1c"]         },         "us-west-2": {             "enabled": true,             "priority": 2,             "max_instances": 30,             "availability_zones": ["us-west-2a", "us-west-2b"]         }     },     "kubernetes_deployment": {         "min_replicas": 1,         "max_replicas": 100,         "target_cpu_utilization": 70,         "target_memory_utilization": 80     } }

샘플 Group Manager JSON 구성

Figure 3: Group Manager Data Flow

그림 3: Group Manager 데이터 흐름

Group Manager의 진정한 정교함은 인스턴스 선택에 접근하는 방식에 있습니다.

디지털 휴먼당 비용 관점에서 모든 GPU 인스턴스가 동등하지는 않습니다. 세션당 실효 비용이 더 낮으면서 디지털 휴먼 4개를 구동할 수 있는 더 강력한 인스턴스는, 2개를 구동하는 작은 인스턴스보다 항상 선호됩니다. Group Manager는 이 비즈니스 로직을 인스턴스 타입을 “서비스 실효 비용” 기준으로 순위화하는 우선순위 가중 시스템으로 인코딩합니다.

하지만 우선순위만으로는 충분하지 않습니다. 스팟 가용성이 변수입니다. Group Manager는 어떤 인스턴스 타입에 스팟 용량이 있는지 지속적으로 모니터링하고, 목표 수의 디지털 휴먼을 최저 비용으로 제공하는 조합으로 할당을 동적으로 전환합니다. 선호하는 인스턴스 타입을 스팟으로 사용할 수 없으면, 불필요하게 값비싼 온디맨드로 되돌아가는 대신 다음 우선순위 계층으로 순차적으로 내려갑니다.

온디맨드 인스턴스는 안전망 역할을 합니다. 스팟 용량이 진짜로 부족할 때만 프로비저닝되며, 스팟 용량이 회복되는 즉시 종료됩니다. 이 공격적인 “스팟 우선(Spot-first)” 태세가 규모에서 의미 있는 비용 절감을 이끌어냅니다.

스팟 용량은 인스턴스 타입뿐 아니라 리전과 가용 영역(AZ)에 따라서도 달라집니다. us-east-1에서는 제약이 있는 스팟 풀이 us-west-2에서는 풍부할 수 있습니다. UneeQ의 Group Manager는 여러 리전에서 동시에 운영하는 방식으로 이러한 현실을 활용하며, 이때 지연(latency) 요구사항과 일반적인 용량 가용성을 모두 반영한 리전 단위 우선순위 가중치를 적용합니다.

Amazon Route 53 지연 기반 라우팅과 Application Load Balancer(ALB)가 여기서 중요한 보조 역할을 합니다. Group Manager가 여러 리전에 걸쳐 용량을 프로비저닝하면, Route 53은 사용자를 지연이 가장 낮은 엔드포인트로 안내함으로써 리전 간 트래픽 라우팅을 처리합니다. 그리고 각 리전 내에서는 ALB가 정상 인스턴스 전반의 부하 분산을 관리하고, 고급 상태 확인(health check)을 제공하며, SSL/TLS 종료를 처리합니다. 이로써 인프라 계층에서 일어나는 비용 최적화가 최종 사용자에게는 전혀 드러나지 않게 됩니다.

그 결과, 스팟 용량이 가장 저렴하고 가장 넉넉한 곳으로 별도의 수동 개입 없이 자동으로 이동하는, 전 세계에 분산된 렌더링 플릿이 완성됩니다.

Group Manager를 배포한 이후, UneeQ는 중요한 모든 차원에서 측정 가능한 개선을 달성했습니다.

서비스 비용 절감 — 디지털 휴먼당 30~55% 비용 절감.

효과적인 리소스 활용 — UneeQ는 가장 비용 효율적인 스팟 풀을 활용함으로써, 덜 최적화된 인스턴스 타입에서 30% 절감에 안주하지 않고 디지털 휴먼당 비용을 최대 55%까지 절감할 가능성을 극대화합니다. 우선순위 가중 선택 알고리즘은 워크로드가 항상 가용한 인스턴스 중 밀도가 가장 높고 비용이 가장 낮은 쪽으로 쏠리도록 보장합니다.

향상된 복원력 — UneeQ는 이미 디지털 휴먼 플랫폼에 대해 99.95%의 가동 시간을 유지하고 있습니다. 스팟 인스턴스로의 전환은 이 가용성을 훼손하는 것이 아니라 그대로 유지하도록 설계되었습니다. 시스템은 대체 인스턴스 타입으로 자동 폴백하고, 가용 영역(AZ)과 리전 전반에 용량을 선제적으로 분산함으로써, 순수 온디맨드 방식과 비교해도 가동 시간이 전혀 저하되지 않도록 보장합니다.

운영 오버헤드 감소 — 한때 끊임없는 수동 계산과 구성이 필요했던 작업이 이제는 2분마다 자율적으로 실행되며, Amazon CloudWatch가 시스템의 의사결정에 대한 가시성을 제공합니다. 이를 통해 월 약 15 엔지니어 시간(engineer-hours)이 확보되어, 팀은 용량 관리 대신 제품 혁신에 집중할 수 있게 되었습니다.

이 글에서는 UneeQ Digital Humans가 Amazon EKS와 Amazon EC2 스팟 인스턴스를 사용해 여러 리전에 걸쳐 GPU 리소스를 동적으로 관리하기 위해, 맞춤형 오케스트레이션 계층인 Group Manager를 어떻게 구축했는지 살펴봤습니다. UneeQ는 워크로드 인지형 인스턴스 선택과 공격적인 “스팟 우선” 프로비저닝을 결합함으로써, 고객 대면 배포의 고가용성을 유지하면서도 디지털 휴먼당 비용을 30~55% 절감했습니다.

스팟 인스턴스로 얻을 수 있는 컴퓨팅 절감은 상당하지만, 이를 확보하려면 단순한 구성에서 한 걸음 더 나아가야 합니다. UneeQ의 접근 방식은 변동하는 가용성, 혼합 인스턴스 플릿, 다중 리전 배포를 헤쳐 나가는 로직을 어떻게 구축하는지 보여줍니다. Amazon EKS, AWS Lambda, Amazon EventBridge, Amazon EC2 Auto Scaling, Amazon CloudWatch, Amazon EC2 스팟 인스턴스 위에 구축된 솔루션에 투자함으로써, UneeQ는 GPU 비용 관리를 운영 부담에서 경쟁 우위로 전환했습니다.

게임 스트리밍, 공간 컴퓨팅(spatial computing), 실시간 렌더링, AI 추론 등 이와 유사하게 집약적인 워크로드를 운영하는 팀에게, UneeQ의 접근 방식은 설득력 있는 청사진을 제시합니다. 인스턴스 우선순위를 서비스 실효 비용(effective cost-to-serve) 기준으로 정의하고, 가능한 한 넓은 범위의 호환 인스턴스 타입을 지원하며, 리전 전반에 걸쳐 공급을 수요에 맞추는 고된 작업은 자동화에 맡기는 것입니다.

UneeQ 디지털 휴먼의 높은 충실도(fidelity)는 변함없이 유지되며, 이렇게 확보한 상당한 비용 효율 덕분에 UneeQ는 고객에게 서비스 비용을 낮게 유지하는 동시에, 기반 인프라 비용을 늘리지 않고도 지속적인 품질 개선에 재투자할 수 있습니다.

스팟 최적화 GPU 워크로드를 시작하려면:

Joonhyung Kim

Joonhyung Kim

김준형 Sr. Solutions Architect는 AWS Korea의 Physical AI 및 Spatial Computing 전문가입니다. 디지털 트윈, 3D, AR/VR/XR 비즈니스를 추진하는 고객들이 AWS에서 빠르고 비용 효율적으로 개발·운영할 수 있도록 지원하고 있습니다. AWS Spatial Data Management on AWS(SDMA), NVIDIA Omniverse, Isaac Sim, Isaac Lab 등을 AWS와 결합한 Physical AI 파이프라인 구축에 주력하고 있으며, 생성형 AI, 머신러닝, 데이터, 클라우드 아키텍처 분야에서도 풍부한 경험을 바탕으로 고객들의 디지털 혁신을 돕고 있습니다.