AI 산업은 지난 몇 년 동안 하나의 지배적인 인프라 문제를 논의하며 시간을 보냈습니다:

컴퓨팅(Compute)이 충분하지 않다.

기업들은 GPU를 확보하기 위해 경쟁하고 있습니다. 클라우드 제공업체들은 용량을 확장하고 있습니다. 정부는 새로운 데이터 센터(Data centres)에 자금을 지원하고 있습니다. 스타트업들은 크레딧, 예약, 그리고 최신 가속기(Accelerators)에 대한 접근권을 얻기 위해 경쟁하고 있습니다.

하지만 이러한 부족에 대한 서사는 또 다른 문제를 숨기고 있습니다.

우리가 이미 보유하고 있는 컴퓨팅의 상당 부분이 효과적으로 사용되지 않고 있습니다.

Gartner는 2026년에 전 세계 AI 지출이 전년 대비 47% 성장한 2.59조 달러에 달할 것이라고 예측합니다. Goldman Sachs의 기본 모델은 이와 별개로 2026년 동안 연간 AI 자본 지출(Capital expenditure)이 약 7,650억 달러에 이를 것으로 추정합니다.

이는 역사적인 규모의 인프라 구축입니다.

하지만 더 많은 GPU를 구매한다고 해서 자동으로 더 유용한 AI 작업이 생성되는 것은 아닙니다.

컴퓨팅은 올바른 워크로드(Workload)가 올바른 하드웨어에 도달하고, 성공적으로 시작되며, 건강한 상태를 유지하고, 기대되는 출력을 생성하며, 이를 합리적인 비용으로 수행할 때에만 가치를 창출합니다.

그 실행 체인(Execution chain)은 여전히 놀라울 정도로 취약합니다.

5% 활용도 통계는 주의와 맥락이 필요합니다

CAST AI의 2026년 Kubernetes 최적화 현황 보고서(State of Kubernetes Optimization Report)는 AWS, Microsoft Azure, Google Cloud에서 실행되는 수만 개의 비최적화된 프로덕션 Kubernetes 클러스터를 대상으로 GPU 활용도를 측정했습니다.

분석된 클러스터 전체의 평균 GPU 활용도는 단 **5%**였습니다.

CAST AI는 해당 활용도 수준에서 조직들이 특정 시점에 워크로드가 소비하는 양보다 약 20배 더 많은 GPU 용량을 보유하고 있다고 언급했습니다.

이는 놀라운 결과이지만, 신중하게 해석되어야 합니다.

이것이 전 세계에서 구매되는 모든 GPU의 95%가 영구적으로 낭비되고 있다는 것을 의미하지는 않습니다. 이 측정값은 비최적화된 Kubernetes 환경이라는 특정 집단을 대상으로 합니다. 사용되지 않는 일부 용량은 트래픽 급증, 신뢰성 요구 사항 또는 스케줄링 제약 조건을 위한 의도적인 여유분(Headroom)일 수도 있습니다.

그럼에도 불구하고, 이 결과는 중요한 사실을 드러냅니다:

프로비저닝된 컴퓨팅(Provisioned compute)과 생산적인 컴퓨팅(Productive compute)은 동일한 것이 아닙니다.

조직은 기술적으로 상당한 GPU 용량을 보유하고 있으면서도, 워크로드(Workload)를 효율적으로 실행하는 데 여전히 어려움을 겪을 수 있습니다.

문제는 단순히 하드웨어 가용성(Availability)의 문제가 아닙니다. 그것은 해당 하드웨어를 둘러싼 소프트웨어 및 운영 메커니즘의 문제입니다.

컴퓨팅 낭비는 여러 계층에서 발생합니다

사람들이 “유휴 GPU(Idle GPU)”라는 말을 들으면, 종종 아무것도 하지 않고 있는 서버를 상상하곤 합니다.

실제로 AI 컴퓨팅의 비효율성은 더 복잡합니다. 낭비는 워크로드 생명주기(Workload lifecycle)의 여러 단계에서 나타납니다.

1. 프로비저닝 낭비 (Provisioning waste)

팀들은 종종 애플리케이션이 소비하는 것보다 더 많은 용량을 예약합니다.

이는 인프라가 워크로드의 관찰된 동작(Observed behaviour)보다는 요청된 리소스, 예상되는 피크(Peak), 또는 광범위한 하드웨어 카테고리를 기준으로 프로비저닝되기 때문에 발생합니다.

추론(Inference) 서비스는 많은 양의 GPU 메모리를 필요로 하지만 지속적인 컴퓨팅은 상대적으로 적게 사용할 수 있습니다. 배치(Batch) 워크로드는 집중적인 GPU 처리와 CPU 바운드(CPU-bound) 데이터 준비 사이를 교차하며 수행될 수 있습니다. 학습(Training) 작업은 여러 개의 가속기(Accelerator)를 요청하지만 이를 불균일하게 사용할 수 있습니다.

하드웨어는 할당되었지만, 그 구성 요소들이 반드시 포화(Saturated) 상태인 것은 아닙니다.

2. 워크로드 구성 낭비 (Workload-configuration waste)

작업이 GPU에 도달한 후에도 해당 GPU를 제대로 활용하지 못할 수 있습니다.

2024년 Microsoft Research의 연구에 따르면, 평균 GPU 사용률이 50% 이하인 400개의 산업용 딥러닝(Deep-learning) 작업을 조사했습니다. 연구진은 706개의 별도 저사용률(Low-utilization) 문제를 식별했습니다.

해당 문제 중 약 46%는 데이터 작업과 관련이 있었고, 약 45%는 딥러닝 모델과 관련이 있었습니다. 연구진은 저사용률이 불충분한 GPU 연산이나 시스템의 다른 곳에서 수행되는 작업으로 인한 중단(Interruption)으로 인해 흔히 발생한다는 것을 발견했습니다.

결정적으로, 그들은 식별된 문제의 약 85%가 비교적 적은 수의 코드 또는 스크립트 수정만으로도 해결될 수 있다고 결론지었습니다.

이는 낮은 활용도(low utilization)가 항상 피할 수 없는 하드웨어적 한계 때문만은 아니라는 것을 의미합니다.

다음과 같은 원인으로 발생할 수 있습니다:

• 비효율적인 데이터 로딩 (data loading);
• 부적절한 배치 크기 (batch sizes);
• CPU 병목 현상 (CPU bottlenecks);
• 과도한 동기화 (excessive synchronization);
• 선택된 하드웨어에 맞지 않는 모델 설정 (model configurations);
• 느린 스토리지 또는 네트워크 전송;
• 가속기(accelerator) 전체를 할당할 필요가 없는 워크로드.

GPU가 활성화되어 있을지라도, 여전히 효율적으로 사용되지 않고 있을 수 있습니다.

3. 실패로 인한 낭비 (Failure waste)

컴퓨팅 낭비의 가장 명백한 형태는 워크로드가 실행되어 리소스를 소비한 후, 결국 실패하는 경우입니다.

Microsoft 연구진은 이전에 내부 운영 플랫폼에서 발생한 **4,960건의 실패한 딥러닝 작업 (deep-learning jobs)**을 연구했습니다. 그들은 실패의 48%가 핵심 프로그램 로직이 아닌 플랫폼과의 상호작용에서 발생했다는 것을 발견했습니다.

많은 사례가 로컬 개발 환경과 작업이 최종적으로 실행되는 환경 사이의 차이와 관련이 있었습니다.

이러한 구분은 매우 중요합니다.

개발자가 올바른 모델 코드를 가지고 있더라도 다음과 같은 이유로 컴퓨팅 자원을 낭비할 수 있습니다:

• 호환되지 않는 런타임 (runtime);
• 누락된 패키지 (package);
• 잘못된 컨테이너 엔트리포인트 (container entrypoint);
• 잘못된 스토리지 권한;
• 불충분한 GPU 메모리;
• 지원되지 않는 가속기 아키텍처 (accelerator architecture);
• 잘못된 환경 변수 (environment variable);
• 제공업체별 설정 불일치 (provider-specific configuration mismatch).

이러한 문제들이 프로비저닝 (provisioning)이 시작된 후에야 감지되면, 조직은 실행 전에 충분히 잡아낼 수 있었을 오류를 발견하기 위해 비용을 지불하게 됩니다.

4. 운영상의 낭비 (Operational waste)

클라우드 청구서에 직접적으로 나타나지는 않지만, 또 다른 범주의 낭비가 존재합니다.

그것은 바로 엔지니어링 시간(engineering time)에서 나타납니다.

AI 팀은 제공업체의 콘솔을 오가며 GPU 유형을 비교하고, 할당량(quotas)을 확인하고, 로그를 찾고, 아티팩트(artifacts)를 다운로드하고, 실패한 작업을 재시작하며, 실패의 원인이 코드 때문인지 인프라 때문인지 파악하는 데 일상적으로 수많은 시간을 소비합니다.

실패한 컴퓨팅 작업으로 인해 20달러의 비용이 발생할 때, 고액 연봉을 받는 엔지니어의 시간 또한 수 시간 동안 소모될 수 있습니다.

이러한 운영상의 부담은 팀이 여러 제공업체(provider)를 사용할 때 더욱 심각해집니다. 각 플랫폼은 고유의 용어, API, 용량 동작(capacity behaviour), 인증 모델(authentication model), 로그, 스토리지 컨벤션(storage conventions), 그리고 실패 상태(failure states)를 가지고 있습니다.

그 결과, 스크립트, 대시보드, 그리고 조직 내 지식(institutional knowledge)에 의해 간신_히 유지되는 파편화된 실행 프로세스가 만들어집니다.

GPU를 더 추가하는 것이 이 문제를 해결하지 못하는 이유

용량 압박에 대한 자연스러운 반응은 공급을 늘리는 것입니다.

더 많은 GPU가 확실히 필요합니다. AI 수요는 빠르게 성장하고 있으며, 많은 조직이 실제로 용량 제약(capacity constraints)에 직면해 있습니다.

하지만 추가적인 공급만으로는 부적절한 워크로드 배치(workload placement), 실행 실패, 비효율적인 설정(configurations), 파편화된 관측성(observability), 또는 유휴 예약(idle reservations) 문제를 해결할 수 없습니다.

더 나은 실행 인프라(execution infrastructure) 없이는, 용량을 늘리는 것이 단지 잘못 할당될 수 있는 인프라의 양을 늘리는 결과만 초래할 수 있습니다.

따라서 업계는 다른 질문을 던져야 합니다.

단순히 다음과 같은 질문이 아니라:

어디에서 더 많은 컴퓨팅 자원을 찾을 수 있는가?

다음과 같은 질문도 함께 던져야 합니다:

어떻게 하면 모든 워크로드가 적절한 컴퓨팅 자원을 할당받고, 이를 유용한 출력물로 성공적으로 전환하도록 보장할 수 있는가?

이것은 오케스트레이션(orchestration) 및 실행(execution)의 문제입니다.

AI 인프라에서 누락된 추상화(abstraction)

애플리케이션 개발자들은 일반적으로 모든 GPU, 클라우드 제공업체, 스케줄러(scheduler), 컨테이너 런타임(container runtime), 그리고 지역별 용량 시장(regional capacity market)의 전문가가 되고 싶어 하지 않습니다.

그들은 워크로드를 기술하고 예측 가능한 결과를 얻기를 원합니다.

더 강력한 실행 계층(execution layer)은 다음과 같은 능력을 갖추어야 합니다:

1. 제출 전 워크로드(workload) 이해
   비싼 인프라가 프로비저닝(provisioned)되기 전에 리소스 요구 사항, 컨테이너 설정(container configuration), 런타임 제한(runtime limits), 스토리지 필요량 및 예상 출력물을 검사해야 합니다.

2. 워크로드를 적절한 컴퓨팅(compute)에 매칭
   모든 AI 워크로드가 가장 빠르거나 가장 비싼 GPU를 필요로 하는 것은 아닙니다. 올바른 결정은 메모리, 아키텍처 호환성, 지연 시간(latency), 지속 시간, 가용성 및 비용에 따라 달라집니다.

3. 개별 제공업체로부터 실행(execution)을 분리
   개발자는 용량(capacity)이 한 제공업체에서 다른 제공업체로 이동할 때마다 운영 워크플로(operational workflow)를 다시 구축할 필요가 없어야 합니다.

4. 실패 상태를 이해 가능하게 만들기
   로그, 상태 변경, 재시도(retries), 취소 및 아티팩트(artifacts)는 일관된 인터페이스를 통해 노출되어야 합니다.

5. 실행 이력 보존
   작업(job)은 무엇이 요청되었는지, 어디에서 실행되었는지, 어떤 리소스가 사용되었는지, 왜 실패하거나 성공했는지, 그리고 무엇을 생성했는지를 보여주는 내구성이 있는 기록을 가져야 합니다.

6. 확정 전 추정
   팀은 워크로드를 실행하기 전에 예상 비용과 적절한 용량이 존재하는지 여부를 알아야 합니다.

이것이 모든 실패를 제거하거나 완벽한 활용을 보장하지는 않습니다.

하지만, 이는 중요한 결정들이 비용이 많이 들기 전, 즉 실행 라이프사이클(execution lifecycle)의 더 이른 단계에서 이루어지도록 합니다.

인프라 접근에서 실행 지능(execution intelligence)으로

AI 인프라의 첫 번째 세대는 접근(access)에 집중했습니다.

개발자가 GPU를 확보할 수 있는가?

다음 세대는 실행 지능(execution intelligence)에 집중해야 합니다.

어떤 GPU를 사용해야 하는가? 워크로드가 해당 GPU와 호환되는가? 더 저렴하고 적절한 옵션이 있는가? 용량이 실제로 사용 가능한가? 작업이 실패로부터 복구될 수 있는가? 출력물을 검증할 수 있는가? 개발자가 워크플로를 재설계하도록 강요하지 않고도 실행을 제공업체 간에 이동할 수 있는가?

이러한 질문들이 필수적인 인프라 질문이 되고 있습니다.

Jungle Grid에서 이것이 바로 우리가 해결하고자 하는 문제입니다.

우리는 AI 워크로드(Workloads)가 제출되고, 스크리닝(Screening)되며, 사용 가능한 컴퓨팅 자원으로 라우팅(Routing)되고, 모니터링(Monitoring) 및 재시도(Retry)되며, 일관된 로그(Logs) 및 아티팩트(Artifacts)와 함께 반환될 수 있는 실행 계층(Execution layer)을 구축하고 있습니다.

목표는 단순히 더 많은 GPU를 노출하는 것이 아닙니다.

이종 컴퓨팅(Heterogeneous compute)이 신뢰할 수 있는 실행 인프라(Execution infrastructure)처럼 작동하도록 만드는 것입니다.

이 차이점은 매우 중요한데, AI의 미래는 단일 제공업체, 단일 GPU 유형, 또는 단일 배포 모델(Deployment model) 위에 구축되지 않을 것이기 때문입니다.

워크로드는 하이퍼스케일러(Hyperscalers), 특화된 GPU 클라우드, 지역 제공업체, 프라이빗 클러스터(Private clusters), 그리고 분산 인프라(Distributed infrastructure)를 가로질러 점점 더 많이 이동할 것입니다.

승리하는 추상화(Abstraction)는 제공업체의 대시보드가 아닐 것입니다.

그것은 워크로드가 이 모든 곳을 어떻게 이동할지를 결정하는 실행 계층(Execution layer)이 될 것입니다.

진정한 기회

AI 컴퓨팅에 관한 대화는 희소성(Scarcity)에 의해 지배되어 왔습니다.

희소성은 실재하지만, 이는 문제의 한 단면에 불과합니다.

다른 한 면은 값비싼 용량(Capacity)이 빈번하게 유휴(Idle) 상태이거나, 제대로 매칭되지 않거나, 잘못 구성되거나, 운영 측면에서 파편화되어 있거나, 혹은 유효한 결과를 전혀 생성하지 못하는 작업에 의해 소비되고 있다는 점입니다.

이 문제를 해결하는 조직은 두 가지 방식으로 가치를 창출할 것입니다:

컴퓨팅에 대한 접근성을 확대할 것이며, 기존의 컴퓨팅을 실질적으로 훨씬 더 생산적으로 만들 것입니다.

AI에 수조 달러를 지출할 준비를 하고 있는 산업에서, 실행 효율성(Execution efficiency)의 미미한 개선조차도 엄청난 결과를 초래할 수 있습니다.

다음 인프라의 돌파구는 단순히 더 빠른 GPU가 아닐 수도 있습니다.

그것은 우리가 이미 보유하고 있는 GPU를 낭비하는 것을 멈추게 보장하는 시스템일 것입니다.

출처

• Gartner, 2026년 전 세계 AI 지출 47% 성장 전망
• CAST AI: 2026년 Kubernetes 최적화 현황 보고서
• Microsoft Research: 딥러닝 작업의 낮은 GPU 활용도에 관한 실증적 연구
• Microsoft Research: 딥러닝 작업의 프로그램 실패에 관한 실증적 연구