AI 팀의 65.9%가 GPU 용량 계획에 실패하는 이유
AI 엔지니어링 리드에게 요즘 가장 골치 아픈 게 뭐냐고 물으면, 의외로 모델 자체를 꼽는 경우는 거의 없습니다. 진짜 문제는 그 아래 인프라, 정확히는 "GPU 용량을 대체 얼마나 확보해둬야 하는가"입니다. 2026년 3월 Akamai가 AI 실무자 200명을 대상으로 진행한 설문에서 이 감각이 숫자로 확인됐습니다. AI 네이티브 팀의 65.9%가 GPU 용량 계획(capacity planning)을 스케일링 과정에서 가장 어려운 과제로 꼽았고, 이는 설문에 포함된 다른 모든 (레이턴시, 비용까지 포함한) 운영 이슈를 제친 1위였습니다. [1] 이건 소수가 겪는 특수한 고충이 아닙니다. 응답자의 75.5%가 엔지니어, 아키텍트, DevOps 실무자였고, 응답자의 76%가 기업의 예산과 방향을 정하는 의사결정권자였습니다. 즉, 실무자와 리더 모두가 공통으로 꼽은 문제라는 뜻입니다. 흥미롭게도, 같은 현상을 다른 곳에서도 확인할 수 있습니다. 2026년 VentureBeat의 기업 107곳 대상으로 진행한 설문에서도 응답 기업의 83%가 GPU 가동률이 50% 이하라고 답했고, AI 컴퓨트 비용을 제대로 추적하고 있다고 답한 곳은 44%에 그쳤습니다. [7] 결국 팀들이 마주친 문제는 GPU 부족이 아니라, 얼마나 필요한지 알아낼 신뢰할 만한 방법이 없다는 것입니다.
그렇다면 용량 계획은 왜 무너지는가
전통적인 인프라 용량 계획은 한 가지를 전제로 합니다. 사용자 수와 부하 사이에 예측 가능한 관계가 있다는 것. LLM 워크로드는 이 전제를 처음부터 깹니다. 일반적인 웹 서비스가 사용자 1만 명에서 100만 명으로 늘어날 때는 주로 데이터베이스와 API 레이어에 부하가 걸리고, 이건 어느 정도 사전에 모델링할 수 있습니다. 반면 AI 서비스가 스케일업될 때는 GPU 메모리, 토큰 처리량, 배치 효율, 콜드 스타트까지 동시에 영향을 받는데 이 요소들은 사용자 수와 나란히 움직이지 않습니다. 결국 토큰 수요 예측이 이렇게 어려운 이유는 수요가 완만하게 증가하는 게 아니라 스파이크성으로 튀기 때문입니다. 아래 표를 보면 다양한 워크로드에서 이런 패턴이 반복적으로 나타나는 걸 확인할 수 있습니다.
예약 기반의 정적인 용량 계획은 애초에 이렇게 움직이는 워크로드를 염두에 두고 설계된 방식이 아닙니다. 위 사례들을 특히 곱씹어볼 만한 이유는, 이 팀이 이미 노드를 추가로 프로비저닝한 상태였는데도 그게 해법이 아니었다는 점입니다. 잘못된 지점에 투입된 추가 용량은, 용량 부족과 똑같은 레이턴시 벽을 만듭니다.
너무 많아도, 너무 적어도 문제
수요를 과대 추정하면 사용하지 않는 GPU에도 계속 비용을 지불해야 합니다. 최악의 트래픽 급증에 대비해 용량을 넉넉히 확보한 팀들은 예상보다 수요가 늘지 않을 경우, 수개월 동안 유휴 하드웨어를 떠안게 됩니다. 실제로 한 포춘 500대 기업은 필요한 용량보다 300% 많은 자원을 확보했고, 그 초과분은 2년 동안 사용되지 않은 채 남았습니다. 반대로 수요를 과소 추정하면 큰 비용을 치를 수 있습니다. 부족한 자원을 급하게 확보하는 데 드는 비용이 처음부터 일정 수준의 여유 용량을 마련하는 비용보다 훨씬 커지기 때문입니다. 한 기업이 수요를 400% 과소 추정했고, 이를 뒤늦게 메우기 위한 긴급 조달에만 8억 달러를 쓴 대표적인 사례도 있습니다. [5] 두 사례는 실패의 방향만 반대일 뿐, 근본 원인은 같습니다. 끊임없이 변하는 워크로드를 하나의 고정된 숫자로 예측하고 대응하려 했다는 것입니다. 이게 바로 "GPU를 더 사면 해결된다"가 답이 되지 못하는 이유입니다. 실제로 상당한 인프라 투자를 마친 조직 중에서도 절반은 피크 트래픽이 발생할 때 목표 레이턴시를 충족하지 못하고 있습니다. [1] 결국 유휴 자원으로 인한 비용 낭비와 피크 시간대의 성능 저하는 서로 다른 문제가 아닙니다. 변화하는 수요와 고정된 인프라 사이의 구조적 불일치가 각각 비용과 성능의 형태로 드러난 결과입니다.
과대 추정의 실제 비용은 얼마나 될까
'유휴 GPU'라는 말은 비용으로 환산하기 전까지 다소 추상적으로 들릴 수 있습니다. 그러나 실제 수치는 생각보다 훨씬 심각합니다. Cast AI의 2026 State of Kubernetes Optimization Report는 AWS, Azure, GCP에서 운영되는 약 2만 3,000개 프로덕션 클러스터로부터 수집한 텔레메트리 데이터를 분석했습니다. 그 결과, 이들 클러스터의 평균 GPU 가동률은 단 5%에 불과했습니다. 단순 계산하면 기업들이 실제 사용량의 약 20배에 달하는 GPU 용량을 프로비저닝하고 있다는 의미입니다. [8] [9]
가동률은 클라우드 서비스에 따라 차이가 있었지만, 어느 환경에서도 낮았습니다. 관리형 쿠버네티스 서비스별 평균 GPU 가동률은 AKS가 2%, EKS가 5%, GKE가 6%에 그쳤습니다. [10] 특정 클라우드 벤더만의 문제가 아니라, GPU 자원을 할당하고 운영하는 방식 전반의 문제에 가깝다는 뜻입니다.
이러한 낭비를 비용으로 환산하면 이렇습니다. AWS p5 온디맨드 기준으로 사용하지 않는 H100 한 대를 계속 할당해두면 월 약 8,850달러의 비용이 발생합니다. [10] 예를 들어 엔지니어 20명 규모의 팀이 개발용 H100 한 대씩을 사용한 뒤 종료하지 않는다면, 별다른 경고도 없이 한 달에 약 17만 7,000달러가 낭비될 수 있습니다. 유휴 GPU의 비용 리스크가 위험한 이유는 눈에 잘 띄지 않기 때문입니다. 고장이 난 것도 아니고 오료를 일으키는 것도 아니다보니 워크로드가 없어도 자원이 할당된 상태라면 모르고 비용은 계속 청구됩니다. CPU와 비교하면 그 차이는 더욱 분명합니다. 유휴 CPU 코어의 비용은 일반적으로 시간당 센트 단위지만, 유휴 GPU에는 시간당 수 달러가 청구됩니다. [8] CPU 자원의 일부를 여유 있게 확보하는 것은 전체 비용에서 큰 영향을 주지 않을 수 있지만, GPU를 같은 방식으로 과대 프로비저닝하면 CFO가 물어볼 만한 항목이 될 수 밖에 없죠.
이 문제가 지속되는 구조적 이유 중 하나는 스팟 인스턴스 활용률이 지나치게 낮다는 점입니다. 2025년 대부분 기간 동안 스팟 인스턴스에서 실행된 GPU 워크로드는 전체의 2% 미만이었습니다. 중단을 감수할 수 있는 워크로드라면 스팟 가격으로 60~91%의 비용을 절감할 수 있었음에도 말입니다. [8] 물론 GPU 공급난으로 인해 스팟 GPU 자체를 확보하기 어려웠던 시기도 있었습니다. 그러나 예약된 상시 가동 용량을 가장 '안전한' 선택으로 여기는 운영 관행 역시 낮은 활용률을 고착화했습니다. 수요 변동과 관계없이 GPU를 미리 확보해두는 방식이 반복되면서 평균 가동률 5%라는 결과로 이어진 것입니다.
성숙한 팀들은 실제로 무엇을 바꾸고 있는가
그렇다면 해법은 수요를 더 정확하게 예측하는 데 있을까요? 성숙한 팀들은 질문 자체를 바꾸고 있습니다. 미래의 수요를 하나의 숫자로 맞히는 데 집중하기보다, 실제 수요가 예상과 달라지더라도 인프라가 유연하게 대응할 수 있는 구조를 만드는 것입니다. 즉, 핵심은 예측의 정확도를 높이는 것이 아니라 불확실성에 대응하는 능력을 높이는 데 있습니다. 이러한 팀들의 운영 방식에서는 다음과 같은 세 가지 공통 패턴이 나타납니다.
1. 예약된 용량이 아니라 탄력적인 용량
고정 예약은 특정 사용량 예측에 거는 베팅입니다. 그 예측이 틀리면(위의 설문 데이터를 보시면 아시겠지만, 대체로 틀립니다🥲) 대가는 유휴 비용이거나 장애입니다. 실시간 수요에 맞춰 GPU 할당이 자동으로 늘고 줄어드는 인프라는 애초에 '숫자를 정확히 맞혀야 한다'는 전제 자체를 없앱니다.
2. GPU 시간 단위가 아니라 토큰 단위의 비용 가시성
지난 글에서 살펴봤듯이, AI 비용 관리는 이제 필수적인 운영 업무가 되었습니다. 하지만 청구된 GPU 사용 시간만 확인해서는 어떤 모델과 요청, 기능이 비용을 발생시켰는지 파악하기 어렵습니다. 비용을 토큰 단위까지 연결해봐야 증가 원인을 구체적으로 추적할 수 있습니다. 이러한 가시성을 확보한 팀은 비용 스파이크가 발생한 시점에 원인을 찾아 대응할 수 있습니다. 3주 뒤 청구서를 받아보고 나서야 문제를 발견하는 방식과는 대응 속도부터 다릅니다.
3. 인프라를 중앙집중화하는 대신 분산시키기
지난 글에서 다뤘듯이, AI 인프라는 모든 연산을 하나의 대규모 데이터센터에 집중하는 구조에서 벗어나고 있습니다. 특히 추론 워크로드는 여러 지역에서 상시 발생하고 부하를 예측하기 어려우며, 데이터 위치와 지연시간에도 영향을 받습니다. 따라서 필요한 시점과 위치에 맞춰 사용할 수 있는 연산 자원을 선택하는 능력이 중요해지고 있습니다. 틀린 수요 예측은 확보한 GPU 수를 늘린다고 해서 해결되지 않습니다.
용량 계획을 실제로 통제하기 위한 실무 순서
앞서 살펴본 세 가지 패턴이 용량 계획의 방향을 보여준다면, 이제는 이를 실제 운영에 적용할 차례입니다. 다음은 이 문제를 효과적으로 관리하는 인프라 팀들에게서 공통적으로 나타나는 실행 순서입니다. 반드시 따라야 하는 체크리스트라기보다, 추가 예산과 인력을 투입하기 전에 점검해볼 수 있는 기본 절차에 가깝습니다.
용량을 산정하기 전에 워크로드부터 분류합니다. 학습, 파인튜닝, 추론은 컴퓨트, 메모리, 네트워킹 요구사항이 근본적으로 다릅니다. 이 세 가지를 하나의 기준으로 묶어 용량을 산정하면, 일부 워크로드에는 자원이 남고 다른 워크로드에는 부족한 상황이 발생할 수밖에 없습니다. 워크로드별 특성을 나누는 것이 모든 용량 계획의 출발점입니다. [11]
장기 예약에 앞서 실제 사용량의 기준선을 측정합니다. 충분한 프로덕션 데이터 없이 예약형 용량에 먼저 커밋하면, 초기의 불안정한 수요를 정상적인 사용량으로 오인할 수 있습니다. 특히 에이전트와 추론 서비스의 트래픽은 출시 초기 몇 주 동안 큰 폭으로 변동합니다. 따라서 최소 30일간 실제 트래픽을 관찰하며 지속적으로 발생하는 부하와 일시적인 스파이크를 구분한 뒤 예약 용량을 결정하는 것이 좋습니다. [12]
기본 수요와 순간적인 수요를 분리해 대응합니다. 프로덕션 환경에서는 모델을 항상 웜 상태로 유지하며 기본 트래픽을 처리하는 소규모 전용 용량과, 수요가 급증할 때만 확장되는 탄력적 용량을 함께 사용하는 방식이 효과적입니다. 두 수요를 하나의 고정 할당으로 처리하려 하면 평소에는 GPU가 놀고, 피크 시간에는 레이턴시가 높아집니다. 결국 유휴 비용과 성능 저하 중 하나를 감수하게 되는 구조입니다. [12]
인력을 투입하기 전에 비용 귀속 체계부터 갖춥니다. 어떤 팀과 모델, 기능이 GPU 비용을 발생시키는지 파악할 수 있어야 올바른 최적화가 가능합니다. 최근 한 엔터프라이즈 인프라 설문에서는 응답 팀의 74%가 현재 사용하는 스케줄링 및 자원 할당 도구에 만족하지 못한다고 답했습니다. 가시성을 확보하지 않은 채 용량 계획에 엔지니어를 더 투입하는 것은 불완전한 정보를 바탕으로 판단하는 사람의 수만 늘리는 것과 다르지 않습니다. [13]
워크로드 분류와 용량 결정은 정기적으로 다시 검토합니다. 워크로드의 성격과 트래픽 패턴은 계속 변합니다. 6개월 전에는 적절했던 용량이 지금도 적절하리라는 보장은 없습니다. 따라서 워크로드 분류와 기본 사용량을 적어도 분기마다 다시 확인하고, 그 결과를 스팟 인스턴스 비중과 오토스케일링 설정, 예약형 용량에 반영해야 합니다. [8]
이 다섯 단계에는 새로운 GPU나 관리 도구를 구매하는 일이 포함되어 있지 않습니다. 먼저 필요한 것은 용량을 한 번 정하고 끝내는 것이 아니라, 실제 사용량을 지속적으로 측정하고 그에 맞춰 결정을 수정하는 운영 방식입니다. 결국 용량 계획은 일회성 프로비저닝 작업이 아니라 반복적인 의사결정 과정이어야 합니다. 앞서 살펴본 65.9%라는 수치는 대부분의 팀이 아직 이 전환을 이루지 못했다는 사실을 보여줍니다.
결론
GPU 용량 계획이 AI 네이티브 팀의 가장 큰 스케일링 과제로 꼽히는 이유는 예측 역량이 부족해서가 아닙니다. 예측해야 하는 대상인 토큰 수요 자체가 전통적인 방식으로는 정확히 가늠하기 어려울 만큼 빠르고 불규칙하게 변하기 때문입니다. 따라서 해법은 더 정교한 스프레드시트나 더 많은 GPU를 확보하는 데 있지 않습니다. 필요한 것은 예측이 빗나가더라도 안정적으로 운영할 수 있는 인프라입니다. 실제 사용량에 따라 자동으로 확장되고 축소되는 용량, GPU 사용 시간이 아니라 토큰 단위까지 연결되는 비용 가시성, 그리고 수요가 갑자기 10배로 증가해도 긴급 대응 없이 흡수할 수 있는 아키텍처가 필요합니다.
Air Cloud는 분산된 GPU 자원을 하나의 인프라로 연결하고, 실제 워크로드에 맞춰 필요한 만큼 확장할 수 있도록 설계되었습니다. 고정된 GPU 용량을 미리 확보하는 대신, 변화하는 수요에 유연하게 대응할 수 있는 인프라가 필요하다면 Air Cloud에서 직접 워크로드를 실행하고 비용과 성능을 비교해보세요.
👉👉👉 Air Cloud 시작하기
.
.
.
