AI 용량 계획 (Capacity planning)이 다시 부상하고 있지만, 대부분의 기업 인프라 팀은 10년 넘게 이 작업을 수행하지 않았습니다. 이는 기술 격차의 문제가 아닙니다. 그것은 기억상실의 문제입니다. 이 분야가 방치되어 퇴화한 것이 아니라, 보이지 않는 곳에서 매우 능숙하게 작업을 수행하는 세 기업에 조용히 아웃소싱되었기 때문입니다.

AI capacity planning — cloud elasticity outsourcing capacity forecasting to hyperscalers, now returning to enterprises

지난 15년 동안 "용량 계획 (capacity planning)"은 특정한 것을 의미했습니다: 수요를 예측하고, 몇 달 전에 하드웨어를 주문하며, 리드 타임 (lead-time) 위험을 직접 감수하고, 소유한 고정 풀 (fixed pool)에 대해 활용도를 관리하는 것이었습니다. 클라우드의 탄력성 (elasticity)이 그 규율을 없앤 것은 아닙니다. 그것은 위치를 옮겼을 뿐입니다. AWS, Azure, GCP는 지역 수요를 예측하고, 몇 년 전에 서버 하드웨어를 사전 주문하며, 예측이 틀렸을 때의 자본 위험을 감수하는 바로 그 작업을 계속 수행해 왔으며, 그 결과물을 "스케일 업 (scale up)"이라고 적힌 버튼 하나로 여러분에게 판매했습니다. 그 버튼은 실재했습니다. 그 뒤의 계획은 여전히 진행되고 있었습니다. 단지 여러분이 직접 수행하는 것이 아니었기에, 그것이 하나의 전문적인 규율이라는 사실조차 인지하지 못하게 된 것입니다.

AI 인프라는 이러한 계약 관계를 깨뜨렸습니다. 이는 클라우드 제공업체들이 업무를 제대로 수행하지 못해서가 아니라, GPU 공급이 범용 컴퓨팅 (general-purpose compute)처럼 원활하게 이루어지지 않기 때문입니다. 탄력성 (Elasticity)은 무한한 용량이 아니었습니다. 그것은 다른 누군가의 용량 계획 (capacity plan)이었으며, 기업들은 이제 자신들이 스스로의 계획 역량을 얼마나 포기해 왔는지 깨닫고 있습니다.

용량 제약 (Capacity Constraints)은 결코 사라진 적이 없다

본능적으로 이를 용량 계획 (Capacity Planning)의 귀환이라고 설명하고 싶겠지만, 이는 실제로 일어난 일을 과소평가하는 것입니다. 용량 계획은 산업에서 사라진 적이 없습니다. 단지 _여러분의 조직_에서 사라졌을 뿐입니다. 제약 사항은 항상 존재해 왔습니다. 누군가는 다음 분기에 세상이 얼마나 많은 컴퓨팅 자원을 필요로 할지 예측해야 했고, 수요가 발생하기 몇 달 또는 몇 년 전에 그 예측에 따라 자본을 투입해야 했으며, 예측이 틀렸을 때의 리스크를 감수해야 했습니다. 이는 실제 실패 모드 (Failure modes)가 존재하는 엄연한 규율이며, 범용 클라우드 (General-purpose cloud) 시대에는 하이퍼스케일러 (Hyperscalers)들이 개별 기업이 따라갈 수 없는 규모와 재무 상태를 바탕으로 이를 수행해 왔습니다. 즉, 과거에는 여러분이 직접 내려야 했던 AI 인프라 아키텍처 (AI infrastructure architecture) 결정들이, 이제는 완성된 제품으로서 소비하는 결정으로 바뀐 것입니다.

이로 인해 엔터프라이즈 아키텍트 (Enterprise architects)들이 얻은 것은 제약 사항의 부재가 아니었습니다. 그것은 제약 사항에 대한 _가시성 (Visibility)_의 부재였습니다. 그리고 가시성은 거버넌스 (Governance)와 결코 같은 것이 아니었습니다. 비용을 보는 것과 비용을 통제하는 것은 다릅니다. 용량 측면에서의 이러한 격차가 바로 지금 다시 떠오르고 있는 현상입니다. 지역적 용량 제한 (Regional capacity limits)은 내내 존재해 왔지만, 클라우드 제공업체들이 대부분의 경우 일반적인 수요 증가가 운영에 영향을 줄 정도로 부딪히지 않을 만큼 충분한 여유분 (Headroom)을 확보해 두었을 뿐입니다. 예측, 조달 리드 타임 (Procurement lead time), 데이터 센터 구축 일정, 지역 할당 계산 등 이 모든 과정은 스택의 한 단계 위에서 계속 진행되고 있었으며, 결과물을 API 호출과 월간 인보이스로 소비하는 사람들에게는 보이지 않았을 뿐입니다.

더 나아가기 전에 숙고해 볼 가치가 있는 재정의는 다음과 같습니다. 탄력성 (Elasticity)은 무한한 용량이 아니었습니다. 그것은 누군가 다른 사람의 용량 계획이었습니다.

왜 GPU는 클라우드의 나머지 자원들과 다르게 작동하는가

범용 컴퓨팅(General-purpose compute) — CPU, 표준 메모리(standard memory), 블록 스토리지(block storage) — 는 제조 물량이 충분하고 벤더 간 대체 가능성(substitutability)이 높기 때문에, 하이퍼스케일러(hyperscalers)가 고객에게 제약 사항이 드러나지 않도록 수요 변동성을 흡수할 수 있습니다. 하지만 AI 워크로드에 실제로 필요한 가속기(accelerator), 즉 GPU 용량에는 그러한 여유(slack)가 없습니다. 이는 AI 인프라 성숙도의 기초가 되는 가속기 경제학 및 리드 타임의 현실(accelerator economics and lead-time reality)과 동일한 문제입니다. 하이퍼엔드 가속기 주문의 리드 타임(lead times)은 확정부터 인도까지 수개월, 때로는 1년 이상이 소요됩니다. 할당(Allocation)은 종종 대량으로 사전에 협상되며, 스팟 가용성(spot availability)보다는 다년 단위의 용량 약정(capacity commitments)과 연계되는 경우가 많습니다. 이 중 그 어느 것도 "클릭 한 번으로 확장(click to scale)"하는 방식과는 맞지 않습니다.

실질적인 결과는 에러 메시지가 아닌 대기열(queues)의 형태로 나타납니다. 새로운 추론(inference) 워크로드를 위해 GPU 용량이 필요한 팀은 "클라우드"에 대기 명단이 있다는 사실을 알게 됩니다. 특정 인스턴스 제품군(instance family)에 대해, 특정 리전(region)에서, 때로는 인도 기간이 분 단위가 아닌 분기 단위로 측정되기도 합니다. 한때 예측 가능한 스테이트(steady-state) 워크로드를 위한 틈새 FinOps 도구였던 예약 용량(Reserved-capacity) 계약은, 이제 진지한 AI 인프라 팀이 제공자가 우연히 자원을 보유하고 있을 때가 아니라 프로젝트가 필요할 때 컴퓨팅 자원을 확보할 수 있도록 보장하는 주요 수단이 되고 있습니다. 온디맨드 유틸리티(on-demand utility)가 아닌 비용 아키텍처의 항목(cost-architecture line item)으로서 용량을 바라보는 이러한 변화는, 이 사이트가 추론 계층에서 이미 명명한 바 있는 것과 동일한 근본적인 메커니즘입니다. 즉, 비용 문제와 용량 문제는 서로 다른 라벨을 붙인 동일한 예측 실패(forecasting failure)입니다.

이러한 제약은 가속기(accelerators) 자체에만 국한되지 않습니다. 메모리 공급업체들은 생산 용량(production capacity)을 AI 인프라 수요 쪽으로 적극적으로 재배치하고 있습니다. 이는 가설이 아니라 이번 주 시장 활동에서 나타난 실시간 신호입니다. GPU는 눈에 보이는 병목 현상(bottleneck)일 뿐입니다. 이는 근본적인 제약이 모두가 가장 먼저 언급하는 칩에만 있는 것이 아니라, 그 칩에 공급되는 전체 하드웨어 공급망(hardware supply chain) 전반에 걸쳐 흐르고 있음을 보여줍니다.

GPU accelerator lead times versus cloud elasticity — order-to-delivery timeline compared to instant scaling

구매된 용량(purchased capacity)과 사용 가능한 용량(usable capacity)은 같은 숫자가 아니며, 그 사이의 격차를 측정하는 것이 바로 Framework #90인 Capacity Illusion Index입니다. 즉, 스케줄링 오버헤드(scheduling overhead), 파편화(fragmentation), 유휴 시간(idle time)을 고려한 후 실제로 유용한 작업을 수행하는 구매된 GPU 용량의 비율을 측정합니다. 예약을 확보하고, 리드 타임(lead time)을 견뎌내며, 할당 비용을 지불한 조직이라 할지라도 자신이 생각하는 만큼의 용량을 확보하지 못했다는 사실을 깨달을 수 있습니다. 송장에 적힌 숫자와 워크로드(workloads)를 실행하는 숫자가 서로 다르기 때문입니다.

아무도 재건하지 않은 계획 역량

이 부분은 GPU 희소성(scarcity)에 관한 대부분의 보도에서 생략되는 지점입니다. 대기열(queues)과 리드 타임은 설명하기 쉽지만, 조직의 기억 상실(organizational memory loss)은 그렇지 않기 때문입니다. 실제 격차는 하드웨어 부족이 아닙니다. 그것은 인프라 설계자(infrastructure architects) 세대 전체가 현재의 상황에서 요구되는 예측 규율(forecasting discipline)을 구축하거나 유지할 필요가 없었다는 점입니다. 클라우드 시대는 그들에게 그런 것을 요구하지 않았기 때문입니다.

중간 행이 중요한 부분입니다. 탄력적 클라우드(elastic-cloud) 팀들이 용량 계획(capacity planning)을 제대로 하지 못했다는 뜻이 아닙니다. 그들은 아예 하지 않았으며, 지난 15년 동안 그것은 올바른 운영적 선택이었습니다. 해당 전문성은 실제로 존재했지만, 단지 서비스 제공자(provider) 측에 있었을 뿐입니다. 내부적으로 그와 유사한 그림자 버전을 구축하는 것은 보상 없는 중복된 노력이 되었을 것입니다. 그것이 바로 이 전문성이 깨끗하고 조용하게 퇴화한 정확한 이유입니다. 아무도 단계를 건너뛴 것이 아닙니다. 건너뛸 단계 자체가 없었습니다.

AI 인프라는 이 단계를 다시 도입하며, 이를 조달(procurement) 문제가 아닌 계획(planning) 문제로서 다시 도입합니다. 예약(Reservations)은 그 자체로 불확실한 프로젝트 일정에 맞춰 예측되어야 합니다. 할당 창(Allocation windows)은 클라우드 이전 시대의 팀들이 하드웨어 리드 타임(lead times)을 고려했던 방식대로, 즉 과소평가했을 때 실질적인 비용이 발생하는 실제 제약 조건으로서 추론되어야 합니다. 실행 예산(Execution budgets)은 하류(downstream)에 적용되는 동일한 전문성입니다 — 일단 워크로드에 용량이 할당되면, 특정 요청이 그 용량의 얼마만큼을 소비하도록 허용할 것인가의 문제는 대부분의 팀이 명시적으로 결정해 본 적이 없는 배급(rationing) 결정입니다. 큐 경합(Queue contention)은 사후에 발견되는 것이 아니라 모델링되어야 합니다.

사용량 예측 (Utilization forecasting)은 "우리가 얼마나 사용하고 있는가"라는 질문보다 더 어려운 질문에 답해야 합니다. 즉, "우리가 예약한 것 중 실제로 필요할 때 사용할 수 있는 양은 얼마인가"라는 질문에 답해야 하며, 이는 이전 섹션에서 다룬 용량 환상 지수 (Capacity Illusion Index) 질문과 정확히 일치하지만, 이제는 사후적(retrospectively)이 아닌 사전적(prospectively)으로 적용되는 것입니다.

일부 조직은 예측 문제를 해결하기 위해 예측 자체를 제거하는 방식으로 대응하고 있습니다. 즉, 외부 제약을 받는 공유 풀(shared, externally-constrained pool)과 계속 협상하는 대신, GPU 용량을 다시 온프레미스(on-premises)로 가져오는 것입니다. 이것은 이 글에서 설명하는 계획 문제에 대한 거부가 아닙니다. 오히려 그 문제에 대한 가장 직접적인 답변입니다. 하드웨어를 직접 소유한다면, 여러분은 자신의 조달 리드 타임 (procurement lead time)에 맞춰 자신의 수요를 다시 예측해야 하기 때문입니다. 이는 이 글 전체가 주장하는 바와 같이, 결코 사라진 적이 없으며 단지 위치만 옮겨졌을 뿐인 규율입니다.

진단 (Diagnostic): "만약 내일 여러분의 주요 AI 워크로드 (workload)가 두 배로 늘어난다면, 여러분의 조직은 필요한 용량이 실제로 언제 사용 가능해질지 — 단순히 예산이 언제 승인될지가 아니라 — 추정할 수 있습니까?"

이 질문은 이 글의 전체 논지를 자기 테스트 형식으로 압축한 것입니다. 클라우드 시대의 사고방식은 확장 이벤트 (scaling event)로 이에 답합니다. 즉, 예산이 통과되면 인스턴스 (instances)가 나타난다는 것입니다. 반면 AI 시대의 사고방식은 예측으로 답해야 합니다. 리드 타임 (lead time), 할당 창 (allocation window), 큐 위치 (queue position), 그리고 구매한 용량이 아닌 실제로 사용 가능한 용량에 대한 실질적인 추정치가 필요합니다. 오늘 이 질문을 받은 대부분의 조직은 첫 번째 프레임워크로 답할 것입니다. 왜냐하면 그것이 현재 재직 중인 구성원들이 경험해 본 유일한 방식이기 때문입니다.

📊 이 논증의 8슬라이드 캐러셀 버전 다운로드

아키텍트의 판결 (Architect's Verdict)

클라우드 탄력성 (Cloud elasticity)이 용량 제약 (capacity constraints)을 제거한 것은 아니었습니다. 클라우드는 그 제약 사항을 세 개의 기업에 외주 주었을 뿐이며, 이 기업들이 고객이 위험의 존재 자체를 잊어버릴 정도로 위험을 흡수하는 데 충분히 능숙해졌을 뿐입니다. AI 인프라가 새로운 문제를 도입한 것이 아닙니다. AI 인프라는 기업들에게 과거에 스스로 책임졌던 문제를 다시 돌려주었으며, 대부분의 기업은 이제 그 문제를 감당할 근력을 더 이상 갖추고 있지 않습니다.

진정한 실패는 GPU 부족이 아닙니다. 그것은 "이것을 위한 예산이 얼마인가"라는 질문에는 오후 안에 답할 수 있으면서도, "이 용량이 실제로 언제 사용 가능해지는가"라는 질문에는 전혀 답하지 못하는 조직의 문제입니다. 왜냐하면 전자의 질문은 지난 15년 동안 매 분기마다 던져져 왔지만, 후자의 질문은 클라우드가 그 일을 타인의 업무로 만들어버린 이후로는 진지하게 제기된 적이 없기 때문입니다.

탄력성 (Elasticity)은 무한한 용량이 아니었습니다. 그것은 누군가 다른 사람의 용량 계획 (capacity plan)이었습니다. 그 사실을 알아차리지 못한 것에 대한 청구서가 이제 도착했습니다.

_원문 게시처: rack2cloud.com