Executive Summary

이 보고서가 딛고 선 숫자는 넷이다. 앞의 셋은 병목이 가속기 바깥으로 옮겨 갔다는 쪽을 가리키고, 마지막 하나는 그 이동을 "CPU가 모자란다"로 읽으면 안 된다는 쪽을 가리킨다. 넷이 서로 어긋나 보이는 자리가 이 글이 다루는 지점이다.

이 이야기는 한 건의 보도에서 시작했다. 2026년 8월 7일 디 인포메이션은 AWS 경영진이 5월 사내 회의에서 엔지니어들에게 "가능한 모든 수단으로 용량을 아껴라"고 지시했다고 보도했다. 팀별로 연내 감축 기한이 걸렸고, 더 이상 필요 없는 유휴 EC2 인스턴스를 해체해 그 용량을 고객에게 돌리라는 요구가 뒤따랐다는 것이다. 대상은 AI 칩 서버와 CPU 탑재 서버 양쪽이었다고 한다. 한 엔지니어는 몇 시간이면 나오던 CPU 서버 용량이 이제 며칠씩 걸린다고 말했다.

기사가 매력적인 만큼 소스 구조를 먼저 드러내는 편이 정직하다. 이 보도는 페이월 뒤의 단독이고, 핵심 근거는 익명 엔지니어의 전언이다. 이후 나온 Tom's Hardware를 비롯한 후속 기사는 전부 같은 원 보도의 재인용이라, "세 매체가 보도했다"는 식으로 소스 수를 부풀리면 안 된다. 로이터·블룸버그급의 독립 확인 보도는 이 보고서를 쓴 2026년 8월 11일까지 확인되지 않았다. 디 인포메이션 자신도 단서를 달았다. 부족은 대체로 스팟 인스턴스 쪽 문제이며, 한 컨설턴트는 계약된 용량에는 부족이 없었다고 말했다는 것이다.

AWS는 반박했다. 컴퓨팅 자원을 관리하는 방식에 바뀐 것이 없고, 사내 팀과 고객 양쪽 수요의 "압도적 다수"를 계속 충족하고 있다는 것이다. 대변인은 EC2를 포함한 서비스 수요가 "믿기 어려울 만큼 강하고 계속 커지는 중"이라고 했고, 유휴 인스턴스 회수와 라이트사이징은 오래전부터 해온 관행이므로 이런 효율화 조치를 새로운 용량 제약의 증거로 읽는 것은 "잘못"이라고 덧붙였다.

1.1익명 전언을 앵커로 쓰지 않는 이유

보도가 사실인지 아닌지를 판정하는 데 이 글의 지면을 쓸 생각은 없다. 그럴 필요가 없기 때문이다. AWS에 CPU 용량 제약이 존재한다는 사실은 익명 전언에 기대지 않고도 성립한다. 앤디 재시 CEO가 2025년 주주서한(2026년 4월 9일 공개)에 직접 써 놓았다.

Graviton은 AWS가 직접 설계한 CPU다. 고객 두 곳이 1년치 CPU 용량을 통째로 사겠다고 했고 클라우드 사업자가 그것을 거절해야 했다는 서술은, 익명 엔지니어의 대기시간 체감보다 훨씬 단단하다. 회사의 CEO가 주주에게 문서로 남긴 진술이기 때문이다. 그래서 이 글은 여기서부터 앵커를 갈아탄다. 아래에서 인용하는 대기시간 이야기는 정성적 전언이므로 표나 지표에 올리지 않고, 논지의 하중은 재시의 문장과 다음 섹션의 인텔 실적 발표가 나눠 진다.

AWS 쪽 이야기가 전언과 서한 사이에 걸쳐 있다면, 인텔 쪽은 훨씬 단순하다. 실명의 임원이 실적 발표 자리에서 숫자를 말했고 그 발언이 트랜스크립트로 남아 있다. 2026년 4월 23일 1분기 실적 콜에서 립부 탄 CEO는 CPU 대 GPU 비율을 이렇게 정리했다.

읽는 방향을 먼저 못 박아 두자. 이 표기는 CPU 대수 대 GPU 대수 순서다. GPU 8대에 CPU 1대가 붙던 구성이 GPU 4대에 1대로, 다시 거의 1대 1로 옮겨 갔다는 뜻이므로, 이 이동은 CPU가 늘어난 이야기다. 순서를 뒤집어 "4대 1에서 1대 1로 갔다"고 읽으면 CPU가 줄어든 것처럼 보인다. 정반대다.

같은 콜에서 데이비드 진스너 CFO는 이 비율을 워크로드별로 갈라 놓았다. 학습은 CPU 1대에 GPU 7~8대, 추론은 3~4대 수준인데, 에이전틱과 멀티 에이전트로 가면 "방향이 조금 뒤집힐 수도 있다"는 것이다. 이 글에 가장 중요한 문장이다. 비율 이동의 원인으로 실명의 CFO가 에이전트를 지목했기 때문이다. 그 뒤 3개월치 발언도 같은 방향을 가리킨다. 7월 23일 2분기 콜에서 진스너는 비율이 "거의 대등하며 대수 기준으로는 CPU 쪽으로 더 기울 수도 있다"고 말했고, 구체적 숫자 제시는 거부하면서 근거로 고객 지출 인풋과 장기공급계약의 가시성을 들었다.

발언 네 건을 시점 순으로 한자리에 놓으면 이동의 방향이 눈에 들어온다. 볼 것은 오른쪽 열 하나다. 왼쪽 숫자가 CPU 대수, 오른쪽이 GPU 대수이며, 왼쪽 몫이 커질수록 같은 수의 가속기를 돌리는 데 더 많은 CPU가 붙는다는 뜻이다. 학습에서 추론으로, 다시 에이전트로 넘어가면서 그 몫이 여덟 배 가까이 늘었다.

인텔 임원 발언에 나타난 CPU 대 GPU 대수 비율의 이동. 세 번째 줄은 앞뒤 줄과 표기 방향이 반대이므로 숫자만 비교하면 안 된다.

페블러스 원본 도식 — 인텔 임원 발언 기준 CPU(오렌지) 1대에 붙는 GPU(회색) 대수의 변화. 같은 CPU 1대가 감당하던 GPU 수가 학습→추론→에이전틱으로 갈수록 8대에서 1대로 줄었다. 뒤집어 보면 GPU 1대당 필요한 CPU가 그만큼 늘었다는 뜻이다.

표의 세 번째 줄에는 주의가 필요하다. 탄은 2026년 5월 JPMorgan 글로벌 TMC 콘퍼런스에서 "일부 고객은 이제 나에게 4대 1이라고 말한다. CPU 4대에 GPU 1대"라고 발언했다. 앞 줄들의 "1대 4"와 여기의 "4대 1"은 표기 방향이 정반대이며, 이것은 일부 고객 사례에 대한 전언이다. 나란히 놓고 숫자만 보면 독자는 반드시 혼동한다. 탄은 프런티어 모델 기업과 스타트업이 강화학습, 여러 에이전트의 오케스트레이션, 워크로드 최적화에서 CPU가 더 유용하다고 말하더라고 그 발언을 귀속했다.

2.1인텔 CEO가 직접 지목한 이유는 데이터였다

비율 숫자보다 이 글에 중요한 것은 탄이 밝힌 이유다. 왜 추론으로 넘어가면 CPU가 중요해지느냐는 대목에서 그는 세 가지를 들었다.

세 항목 중 마지막이 이 보고서가 딛는 자리다. CPU 수요가 늘어나는 이유로 CPU를 파는 회사의 CEO가 데이터를 다루는 일을 직접 지목했다. 같은 콜에서 그는 CPU를 "AI 스택 전체의 오케스트레이션 계층이자 핵심 컨트롤 플레인"으로 재정의하기도 했다. 4절에서 이 문장으로 다시 돌아온다.

2.2말하는 쪽이 파는 쪽이다

여기서 판단을 미루지 않고 벤더 인센티브를 바로 계산에 넣는 편이 낫다. CPU 르네상스를 가장 크게 말하는 주체가 정확히 CPU를 파는 회사들이기 때문이다. 인텔은 2026년 3월 "AI 인프라에서 높아지는 CPU 대 GPU 비율"이라는 자사 백서를 냈고, 3월 이후 서버 CPU 가격을 10~20% 올렸으며 하반기 8~10% 추가 인상이 예상된다는 보도가 나왔다. 일부 Xeon SKU는 1,000달러 넘게 비싸졌다. AMD는 2030년 서버 CPU 시장을 2,200억 달러로 전망하며 자사 성장 논거로 삼는다. 희소성 서사는 그 자체로 가격 인상을 정당화한다.

흥미로운 것은 인텔 스스로 다른 설명도 내놓았다는 점이다. 인텔 VP 타샤 추앙은 TrendForce와의 인터뷰에서 가격 조정이 주로 공급망 전반의 제조 비용 변화를 반영한 것이라고 말했다. 수요가 폭증해서가 아니라 원가가 올라서라는 프레이밍이다. 같은 회사 안에서 수요발 서사와 비용발 서사가 공존하는 셈이니, 가격 인상을 곧바로 "CPU가 부족하다"의 증거로 환산하는 것은 성급하다. 이 글이 인텔 발언에서 가져오는 것은 비율의 방향과 그 이유로 데이터가 지목됐다는 사실이지, 그들의 결론이 아니다.

여기까지는 기업의 말이다. 실제로 시간이 어디서 흐르는지는 재 봐야 안다. 다행히 재 본 사람들이 있다. 조지아공대와 인텔 연구진(Ritik Raj 외)이 에이전트 워크로드 다섯 종을 CPU 관점에서 프로파일링한 arXiv:2511.00739이 지금으로선 이 질문에 가장 직접적으로 답하는 논문이다. 저자 다섯 중 둘이 인텔 소속이라는 점은 읽는 내내 감안할 필요가 있다.

먼저 인용 조건을 정리해 둔다. 이 논문은 2025년 11월 초판 이후 세 번 개정됐고, 초판 초록의 "총지연의 최대 90.6%"라는 문장은 현행 v3(2026년 4월 16일)에서 최대 88%로 바뀌었으며 v3 초록에는 이 퍼센트 자체가 빠졌다. 아래 수치는 모두 v3 본문 기준이다. 그리고 88%는 다섯 워크로드의 평균이 아니라 도구가 지배하는 워크로드에서의 상한이다. 이 조건을 떼고 인용하면 곧바로 틀린 문장이 된다.

논문은 두 시스템에서 같은 워크로드를 돌렸다. Sys 1은 고성능 CPU(인텔 6세대 Xeon Granite Rapids)에 상대적으로 낮은 성능의 GPU(RTX Pro 6000 Blackwell)를 붙였고, Sys 2는 고성능 CPU(NVIDIA Grace)에 고성능 GPU(H200)를 붙였다. 표에서 볼 것은 두 가지다. 각 워크로드에서 시간을 가장 오래 붙잡은 구간이 무엇이었는지, 그리고 그 구간이 두 시스템에서 각각 몇 퍼센트를 차지했는지다. 워크로드별 결과는 이렇다.

Raj 외(arXiv:2511.00739 v3)의 워크로드별 지연 분해. 맨 아랫줄은 이 글의 논지에 대한 반례다. Toolformer에서 88%를 차지한 것은 도구가 아니라 LLM 추론이다.

표의 마지막 줄을 지우고 싶은 유혹이 있지만, 지우면 이 글이 거짓이 된다. 같은 논문 안에 에이전트가 CPU 바운드가 아닌 사례가 함께 있다. Toolformer의 88%는 도구 처리가 아니라 모델 연산이다. 따라서 정확한 문장은 "에이전트는 CPU 바운드다"가 아니라 "도구가 지배하는 워크로드에서는 실행 시간의 대부분이 CPU 측에서 흐른다"이다. 어떤 워크로드가 어느 쪽인지는 재 봐야 안다는 것이 실은 이 표의 가장 실용적인 함의다.

3.1GPU를 좋은 걸로 바꾸자 병목이 더 잘 보였다

표에서 Sys 1과 Sys 2 열을 나란히 보면 이 글에서 가장 흥미로운 대목이 나온다. GPU를 더 좋은 것으로 바꿨더니 도구 구간의 비중이 줄어든 게 아니라 커졌다. RAG는 83%에서 89%로, SWE-Agent는 38%에서 65%로 올라갔다. 당연한 결과이면서 동시에 중요한 결과다. 전체 실행 시간에서 GPU가 차지하던 몫이 줄어들자, 그대로 남아 있던 CPU 구간의 비중이 상대적으로 도드라진 것이다.

이 관찰은 "GPU 공급이 풀리면 해결될 문제 아니냐"는 반론에 직접 답한다. 가속기가 흔해지고 빨라질수록 이 현상은 완화되지 않고 심해진다. 한 논문이 두 시스템 비교만으로 그 방향을 보여준 셈이다.

3.2서빙 계층에서도 같은 일이 벌어진다

위 논문이 에이전트 층위의 이야기라면, 한 층 아래 추론 서빙 인프라에서도 같은 현상이 잡힌다. Chung 외(arXiv:2603.22774)는 멀티 GPU LLM 추론에서 CPU가 유발하는 지연을 세 가지 기제로 정리했다. 첫째는 토크나이제이션이다. Llama 3.1 8B를 H200 4장으로 서빙하며 CPU 16코어를 준 조건에서, 긴 시퀀스 요청의 경우 텍스트를 토큰으로 쪼개는 이 한 단계가 총지연의 최대 절반을 먹었다. 둘째는 집합통신 동기화다. CPU가 과다구독되면 NCCL 배리어에서 한 랭크가 1밀리초 늦는 것만으로 GPU 8장이 통째로 대기 상태로 들어간다. 셋째는 공유메모리 경합으로, vLLM V1의 브로드캐스트 큐에서 dequeue 지연이 12밀리초에서 228밀리초로 19배 악화된 사례를 보고했다.

이 논문의 실용적 결론은 배정 문제다. CPU를 충분히 준 경우 GPU를 한 장도 추가하지 않고 첫 토큰 지연이 1.36~5.40배 개선됐다. 그리고 실제 클러스터는 대체로 반대로 배정돼 있다. 저자들이 분석한 465만 건의 잡 스케줄러 레코드에서 교육용 클러스터의 GPU당 CPU 코어 수 중앙값은 1~2개였고, 연구용 클러스터에서도 GPU당 8코어 미만인 잡이 약 60%였다.

3.3한 번 도는 루프를 시간 축으로 펴 보면

세 번째 실측은 운영체제 관점에서 나왔다. UC 산타크루즈 연구진의 AgentCgroup(arXiv:2602.09345 v3)은 Claude Code 하네스로 SWE-rebench 144개 태스크를 돌리며 시간을 분해했다. 태스크 하나에 5~11분이 걸렸고, 그중 LLM 추론이 40~45%, 도구 실행이 활성 시간의 20~35%, 초기화가 31~48%였다. 초기화와 도구 실행을 묶은 운영체제 수준 오버헤드는 사용자가 체감하는 완료 시간의 55~60%를 차지했다. 아래는 이 루프를 시간 축으로 편 그림이다.

그림에서 오렌지로 채워진 구간이 CPU에서 도는 데이터 작업이다. 도구를 부르고, 검색하고, 파일을 읽고, 돌아온 응답을 파싱해 다음 프롬프트에 싣고, 마지막에 결과를 요약하는 일이 전부 여기 들어간다. 모델이 실제로 도는 구간은 회색 두 칸, 즉 계획과 재계획뿐이다. 막대 길이는 특정 워크로드의 실측 비율이 아니라 구간의 순서와 상대적 무게를 나타낸 개념도다.

분해 수치 자체는 환경에 크게 좌우된다는 점도 함께 적어 둔다. AgentCgroup이 초기화를 31~48%로 잡은 반면, 도구 실행과 LLM 생성을 병렬화한 PASTE(arXiv:2603.18897)는 자체 트레이스에서 초기화가 도구 지연의 20% 미만이라고 보고했다. 하네스와 트레이스가 다르면 분해도 다르다. 어떤 단일 수치도 보편 상수처럼 쓸 수 없다는 뜻이다.

여기서 질문은 하나로 좁혀진다. 그 CPU 구간에서는 정확히 무슨 일이 벌어지고 있는가. 앞 절에서 시간을 붙잡고 있던 구간들을 원래 하는 일의 이름으로 다시 적어 보면 답이 나온다.

3절 실측에서 시간을 지배한 구간을 데이터 작업의 이름으로 다시 적은 것. 어느 것도 모델 연산이 아니다.

오른쪽 열에 모델 연산은 하나도 없다. 전부 데이터를 옮기고, 고르고, 다듬고, 모양을 바꾸는 일이다. 에이전트 인프라 비용이라 불리는 것의 상당 부분이 실은 데이터 파이프라인 비용이라는 말은 여기서 수사가 아니라 항목의 나열이 된다. 2절에서 인텔 CEO가 CPU 수요의 이유로 "여러 에이전트를 데이터로 관리하는 일"을 지목했던 문장과, 이 표는 같은 것을 다른 각도에서 말하고 있다. 한쪽은 칩을 파는 사람의 관찰이고 다른 쪽은 프로파일러의 출력인데, 가리키는 구간이 겹친다.

4.1돈은 GPU로 가고 시간은 CPU로 간다

여기서 모순처럼 보이는 자료 두 개를 나란히 놓아야 한다. MCP 기반 에이전틱 워크플로의 비용을 분해한 한 연구(arXiv:2601.14735)는 애플리케이션 두 건에서 LLM이 전체 비용의 61~94%를 차지하고 에이전트 실행은 13% 남짓, MCP 함수 실행은 3% 수준이라고 보고했다. 도구가 시간의 88%를 먹는다는 3절의 수치와 정면으로 부딪히는 것처럼 보인다.

부딪히지 않는다. 두 수치는 서로 다른 것을 재고 있다. 하나는 돈이고 다른 하나는 시간이다. 토큰 요금은 GPU 위에서 돌아가는 추론 서버로 흘러가고, 오케스트레이션과 도구 실행은 훨씬 싼 CPU 위에서 오래 돈다. 청구서만 보면 이것은 GPU 문제로 보이고, 시계를 보면 데이터 문제로 보인다. 같은 시스템을 두 개의 다른 계기판으로 읽은 결과다.

페블러스 원본 도식 — 비용 비중은 arXiv:2601.14735(애플리케이션 2건)의 LLM 비용 비중, 시간 비중은 arXiv:2511.00739의 도구 지배 워크로드 상한이다. 두 수치는 서로 다른 연구·워크로드를 잰 것이라 한 실행을 정확히 반으로 쪼갠 값은 아니며, 같은 시스템을 다른 계기판으로 읽었을 때 어느 쪽이 도드라지는지의 방향만 보여주는 개념도다.

4.2그런데 CPU 사용률은 10%다

지금까지의 서술은 "그러니 CPU가 모자란다"로 이어지기 쉽다. 그런데 같은 AgentCgroup 실측이 그 결론을 정면으로 막는다. 에이전트의 평균 CPU 사용률은 Claude Haiku 4.5 백엔드에서 13.2%, GLM 백엔드에서 7.6%였다. 저자들의 결론은 더 분명하다. 다중 테넌시 밀도를 제약하는 것은 CPU가 아니라 메모리이며, 프레임워크가 기본으로 쓰는 185MB 위에 도구 호출이 얹히면서 최대 사용량이 평균의 15.4배까지 튄다는 것이다.

이 숫자를 숨기면 글이 거짓이 된다. 그리고 숨기지 않으면 논지가 오히려 정확해진다. 코어를 다 태우면서 88%가 흐르는 게 아니다. 거의 놀고 있는 코어 위에서 시간만 쌓인다. 검색 결과를 기다리고, 파일이 열리기를 기다리고, 응답이 다 와야 파싱을 시작하는 직렬 구간이 줄줄이 이어진 결과다. 그러니 병목의 성격은 연산량이 아니라 대기와 직렬화이며, 처방도 달라진다. 코어를 더 사도 대기는 줄지 않는다. 줄어드는 것은 경로를 고쳤을 때다.

4.3여기서 멈춰야 하는 지점

논지를 한 걸음 더 밀면 이렇게 된다. 데이터가 지저분할수록 파싱이 실패하고, 스키마가 어긋나 재시도가 늘고, 그만큼 CPU 시간이 더 든다. 그럴듯하고, 아마 맞을 것이다. 그런데 이 보고서는 그것을 측정된 사실로 제시하지 않는다. "더러운 데이터"와 "늘어난 CPU 초"를 한 실험 안에서 이은 연구를 찾지 못했기 때문이다.

찾은 것은 사슬의 조각들이다. 멀티턴 대화에서 도구 호출 스키마 오류율이 6.4~9.8%로 관측된 벤치마크가 있고, 에이전트 루프가 제로샷 대비 API 호출을 504건 대 308건으로 늘리며 비용을 52% 올렸고 그 주원인이 196회의 재시도였다는 사례 연구가 있다. 스키마 복잡도가 높아질수록 필수 파라미터 누락이 급증한다는 관측도 있다. 조각들은 같은 방향을 가리키지만, 이어 붙인 것은 이 보고서이지 실험이 아니다. 인과가 아니라 정황으로 읽어 주기 바란다.

대신 조각 하나는 실무적으로 확실하다. 필수 필드 누락이나 타입 불일치로 400이나 422를 받은 호출은, 같은 파라미터로 다시 보내도 또 400이다. 그런 재시도는 부분적으로라도 회수되는 비용이 아니라 순수한 낭비다. 재시도 지표를 한 덩어리로 집계하는 조직에서는 이 낭비가 일시적 오류나 속도 제한 재시도에 섞여 보이지 않게 된다.

수요가 정말로 CPU 쪽으로 옮겨 갔다면 값이 오르거나 구하기 어려워졌을 것이다. 확인해 보면 절반만 맞는다. 제조 단계에서는 압박이 뚜렷하고, 클라우드 요금표에서는 거의 보이지 않는다.

5.1제조 단계 — 압박이 뚜렷하다

시장조사기관 TrendForce는 2026년 4월 15일 자료에서 그해 전체 서버 출하량 성장률 전망을 20%에서 13%로 내렸다. 이유는 수요 감소가 아니라 부품이었다. PCB와 CPU의 리드타임이 약 1년으로 늘었고, 전원관리 반도체(PMIC)는 21~26주에서 35~40주로, 서버 관리 컨트롤러(BMC)는 11~16주에서 21~26주로 벌어졌다. 반면 같은 기관은 8월 5일 자료에서 AI 서버 출하량 성장률 전망을 28%에서 31% 가까이로 올렸다. 상위 9개 클라우드 사업자의 2026년 설비투자 합계는 전년 대비 약 90% 늘어날 것으로 봤다.

두 숫자를 붙여 읽어야 그림이 맞다. 전체 서버 시장은 부품이 없어서 전망이 내려갔고, AI 서버는 수요가 세서 전망이 올라갔다. 부품이 AI 서버 쪽으로 우선 배정되면서 일반 서버가 뒤로 밀린 것이다. 이 압박은 AWS 사내에서 무슨 일이 있었느냐와 무관하게 공급망 전체에 걸려 있고, 그래서 개별 기업의 해명으로 지워지지 않는다.

5.2클라우드 요금표 — 아직 보이지 않는다

그런데 클라우드 소비자가 실제로 결제하는 화면에는 이 압박이 도착하지 않았다. AWS의 범용 인스턴스(M7i·C7i·R7i) 온디맨드 가격에서 2026년 중 인상 근거를 찾지 못했고, m5·c5·r5 같은 구세대는 오히려 3~7% 내렸다. Graviton4 계열(r8g·c8g·m8g)은 이전 세대 대비 10~15% 저렴하다. 반대로 GPU 쪽은 명확하다. EC2 GPU Capacity Block 가격은 1월에 15%, 7월에 다시 20% 올랐다.

방향만 추려 놓으면 갈림이 분명해진다. 2026년 중 요금이 오른 항목은 GPU 용량 하나이고, CPU가 들어가는 범용 인스턴스는 제자리이거나 오히려 내렸다. 수요 이동이 소비자 가격에 도달했다면 반대 그림이 나왔어야 한다.

2026년 AWS 인스턴스 가격 변화 방향(온디맨드 기준). 압박은 GPU 쪽에만 요금으로 나타났다.

그래서 이 보고서는 "지금 클라우드에서 CPU가 비싸졌다"고 쓰지 않는다. 그렇게 쓰면 사실과 어긋난다. 정확한 문장은 제조 단계의 압박이 아직 클라우드 요금표로 전이되지 않았다이다. 리드타임 신호로 보아 시차를 두고 나타날 수는 있지만, 2026년 8월 현재 그 전이는 확인되지 않는다.

다만 클라우드가 다 같지는 않다. Azure는 예외에 가깝다. 블룸버그 보도에 따르면 버지니아 북부와 텍사스 등 핵심 리전의 신규 구독 제한이 2026년 상반기까지 이어질 것으로 전망됐고, 그 사유는 물리적 공간과 서버 부족이며 GPU 전용이 아니라 CPU 기반 전통 워크로드에도 영향을 준다고 명시됐다. 모건스탠리는 2026년 하반기부터 완화될 것으로 본다. GCP와 OCI에서는 이만한 신호를 찾지 못했다. 네 사업자 중 둘은 확인되고 둘은 확인되지 않는다는 비대칭을 그대로 적어 둔다. 모든 클라우드에서 CPU가 부족하다고 일반화해도 틀리고, AWS만의 특수 사정으로 축소해도 틀린다.

5.3이 글이 틀릴 수 있는 여섯 자리

방어적으로 덧붙이는 대신 독립된 목록으로 세워 둔다. 아래 여섯 가지는 이 글의 논지를 약화시키거나 조건을 다는 근거이며, 이것들을 다 읽고도 남는 만큼이 이 보고서의 실제 주장이다.

• 가장 가시적인 병목은 여전히 GPU다. 엔비디아의 최근 분기 데이터센터 매출은 512억 달러였고, 젠슨 황은 클라우드 GPU가 매진 상태라고 말했다. CPU 이야기는 그 위에 얹히는 이야기이지 그것을 대체하는 이야기가 아니다.
• 진짜 제약은 연산이 아니라 연결성이라는 반론. Futurum은 에이전틱 추론을 실제로 묶어 두는 것이 CPU 연산이 아니라 전문가 혼합 모델의 스케일업 네트워킹 데이터 이동이라고 본다. Marvell CEO는 AI 스케일링을 근본적으로 연결성 문제로 규정했다. 다만 이 반론은 이 글에 부분적으로 유리하다. 데이터 이동이 병목이라는 말 역시 결국 데이터 경로의 문제이기 때문이다.
• 병목은 전력이라는 반론. 가트너는 2027년까지 AI 데이터센터의 40%가 전력 가용성 때문에 운영 제약을 받을 것으로 본다. 이 축은 앞선 글에서 따로 다뤘다.
• 말하는 쪽이 파는 쪽이다. 2절에서 다룬 벤더 인센티브는 여기서도 유효하다. 이 글이 근거로 삼은 핵심 논문의 저자 다섯 중 둘도 인텔 소속이다.
• 병목은 스케줄링으로 상당 부분 회수된다. 같은 논문이 제안한 기법들은 P50 지연을 1.7배, 특정 요청 유형의 총지연을 2.37~2.49배 개선했다. 구조적이라는 것과 불가피하다는 것은 다르다.
• 같은 데이터를 양쪽이 인용한다. SambaNova 데모에서 에이전틱 태스크 45초 중 GPU가 쓴 시간은 2초였다. CPU 진영은 이것을 병목 이동의 증거로 인용하고, GPU 진영은 그 2초가 토큰의 대부분을 만들었다는 점을 인용한다. 해석이 얼마나 갈리는지 보여주는 사례로 남겨 둔다.

여기까지 읽고 나면 남는 질문은 하나다. 우리 조직은 어떤가. 대부분의 조직은 답을 모른다. 비용 대시보드가 토큰만 보여주기 때문이다. 아래 여섯 가지는 앞 절들에서 나온 수치만 가지고 자기 환경에서 확인할 수 있는 항목이다. 새 숫자는 없다.

6.1시간 축부터 쪼갠다

에이전트 1회 실행을 LLM 대기, 도구 실행, 직렬화·파싱, 검색·전처리, 초기화의 다섯 구간으로 나눠 잰다. 3절의 세 논문이 전부 이 분해에서 출발했고, 분해하지 않으면 어느 구간이 자기 환경의 지배 구간인지 알 수 없다. Toolformer처럼 모델 추론이 지배하는 워크로드라면 이 글의 처방은 해당되지 않는다. 그 판정을 남에게 맡길 이유가 없다.

6.2사용률이 아니라 대기시간을 본다

CPU 사용률 10%는 "여유 있음"으로 읽히지만 "기다리는 중"일 수도 있다. 4절의 7.6~13.2%가 정확히 그 상황이었다. 사용률 그래프가 평평하다는 이유로 CPU 쪽을 조사 대상에서 빼면, 시간이 가장 많이 쌓이는 구간을 통째로 놓친다. 봐야 할 것은 I/O 대기, 큐 지연, 직렬 구간의 길이다.

6.3GPU당 CPU 코어 배정을 확인한다

3절에서 본 대로 실제 클러스터의 GPU당 CPU 코어는 1~2개인 경우가 흔하고, 이것은 과소 배정이다. 충분히 배정했을 때 첫 토큰 지연이 1.36~5.40배 개선된 결과가 있으니, GPU를 더 사기 전에 확인할 항목으로는 값이 싸다. 자기 클러스터의 잡 스펙에서 이 비율을 뽑아 보는 데는 하루가 걸리지 않는다.

6.4토크나이제이션과 검색 구간을 따로 잰다

긴 시퀀스를 다루는 서비스라면 토크나이제이션이 총지연의 절반까지 갈 수 있다. 검색 구간도 마찬가지다. 두 구간은 대개 애플리케이션 지표에서 "모델 호출" 한 덩어리에 묻혀 있어서, 따로 떼어 재기 전까지는 존재를 드러내지 않는다.

6.5재시도를 종류별로 나눈다

4.3절의 구분이 지표가 되는 자리다. 일시적 오류나 속도 제한으로 인한 재시도는 다시 보내면 성공할 여지가 있지만, 스키마 불일치로 400·422를 받은 재시도는 다시 보내도 실패한다. 두 종류를 한 줄로 집계하면 재시도율이 정상 범위로 보이는 동안 순수한 낭비가 그 안에 숨는다. 도구 호출 스키마 오류율은 벤치마크에서 멀티턴 기준 6.4~9.8% 수준으로 관측된다. 자기 환경의 값이 그보다 높다면 그 자체가 우선순위다.

6.6예산 항목을 세 줄로 나눈다

마지막이 이 글의 요청이다. 에이전트 예산을 토큰비, 가속기 시간, 데이터 경로 시간의 세 줄로 나눠 계상하라. 앞의 두 줄은 대부분의 조직이 이미 본다. 세 번째 줄은 대개 어느 대시보드에도 없고, 그래서 그 값이 크든 작든 논의의 대상이 되지 않는다. 세어 보면 최소한 크기를 알게 되고, 크기를 알면 그것이 우선순위인지 아닌지를 판단할 수 있다. 이 보고서가 독자에게 부탁하는 것은 거기까지다.

페블러스의 제품군은 전부 모델 바깥에 서 있다. DataClinic은 데이터셋의 상태를 진단하고, AI-Ready Data는 학습에 들어가기 전 단계를 다루며, DataGreenhouse와 PebbloSim은 데이터를 만들고 검증하는 층이다. 그래서 이 주제를 오래 들여다봤다. 인텔과 AWS 양쪽에서 관측되는 신호는 AI 시스템의 자원 무게중심이 정확히 그 층으로 옮겨 가고 있다는 것이기 때문이다.

7.1데이터 품질이 성능이 아니라 시간으로 나타난다

데이터 품질 문제는 보통 모델 성능 저하로 나타난다고 이야기된다. 정확도가 떨어지고, 환각이 늘고, 벤치마크 점수가 내려간다는 식이다. 에이전트 아키텍처에서는 그 이전에 시간으로 나타날 가능성이 크다. 파싱이 실패하고, 스키마가 어긋나 재시도가 붙고, 전처리를 다시 돌리는 동안 시계가 흐른다. 4.3절에서 적었듯 이 연결을 한 실험 안에서 측정한 연구는 아직 없다. 그래서 이것은 페블러스의 주장이지 이 보고서가 증명한 사실이 아니며, 증명은 각자의 환경에서 6절의 계측으로 하는 편이 낫다.

7.2견적서에 빠져 있는 줄

에이전트 도입을 검토하는 조직은 대개 토큰 비용과 가속기 비용을 계산한다. 이 보고서가 지목하는 것은 그 견적서에 없는 세 번째 줄이다. 클라우드 용량 계획, 데이터 파이프라인 재설계, 도구 호출 실패율 관리는 셋 다 데이터의 상태에 직접 연동되는데, 셋 다 대개 항목으로 서 있지 않다. 항목이 없으면 개선의 효과도 측정되지 않고, 측정되지 않으면 투자 대상이 되지 못한다.

7.3이 글이 회계가 아니라 시계를 다루는 이유

페블러스는 6월에 이미 에이전트 청구서를 회계의 문제로 다룬 글을 썼다. 이 글은 같은 이야기의 반복이 아니라 다른 계기판의 이야기다. 그쪽이 돈의 흐름을 따라갔다면 이쪽은 시간의 흐름을 따라간다. 병목이 GPU에 있던 시절에는 데이터 준비가 비용 항목에조차 잡히지 않았다. 무게중심이 주변부로 옮겨 가면 그 층은 초 단위로, 그다음에는 숫자로 나타난다.

2026년의 AI 인프라 논의는 여전히 얼마나 큰 가속기를 몇 장 확보하느냐를 중심으로 돈다. 그 질문이 중요하지 않아서가 아니라, 그 질문만으로는 에이전트가 실제로 무엇을 기다리는지 알 수 없다. 다음 분기 계획서를 쓰기 전에 한 번쯤 시계를 들여다볼 만하다. 기다리는 대상이 모델이 아니라면, 더 좋은 모델을 사는 일은 그 기다림을 줄이지 못한다.

학술 (arXiv / 논문)

• 1.Raj, R., Kundu, S., Vohra, I., Wang, H., Krishna, T., "Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective," 2025~2026 (v1 2025-11-01, v3 2026-04-16). Georgia Tech / Intel. arXiv:2511.00739 — 본문의 88%·워크로드별 분해·두 시스템 비교의 출처
• 2.Chung, E., Jia, Y., Jezghani, A., Kim, H., "Characterizing CPU-Induced Slowdowns in Multi-GPU LLM Inference," 2026-03-24. arXiv:2603.22774 — TTFT 1.36~5.40배, 토크나이제이션 50%, 코어 배정 실태
• 3.Zheng, Y., Fan, J., Fu, Q., Yang, Y., Zhang, W., Quinn, A., "AgentCgroup: Understanding and Controlling OS Resources of AI Agents," v3 2026-07-23. UC Santa Cruz. arXiv:2602.09345 — 시간 분해와 CPU 사용률 7.6~13.2%
• 4."Parallelizing Tool Execution and LLM Generation for Low-Latency Agent Serving" (PASTE), 2026-03. arXiv:2603.18897 — 초기화 비중에 대한 상충 관측
• 5."Schema First Tool APIs for LLM Agents," 2026. arXiv:2603.13404 — 도구 호출 실패의 유형 분류
• 6.MCP 기반 에이전틱 워크플로의 비용 분해 (FaaS 환경, 애플리케이션 2건), 2026. arXiv:2601.14735 — LLM 비용 61~94%

기업 1차 (실적 콜 · 주주서한 · IR)

• 7.Intel, 2026년 1분기 실적 콜 트랜스크립트, 2026-04-23 — 립부 탄·데이비드 진스너 발언. fool.com (트랜스크립트 서비스 경유)
• 8.Intel, 2026년 2분기 실적 콜, 2026-07-23 — "almost in parity" 발언. intc.com
• 9.Amazon, "CEO Andy Jassy's 2025 Letter to Shareholders," 2026-04-09 — Graviton 용량 요청과 거절, 3.9GW, 설비투자 선행. aboutamazon.com
• 10.AMD, 2026년 2분기 실적 보도자료, 2026-08-04 — 서버 CPU 성장률과 2030년 시장 전망. ir.amd.com
• 11.J.P. Morgan 54th Annual Global TMC Conference, 인텔 파이어사이드 챗, 2026-05-19 — "four CPU to one GPU" 발언(방향 역전 사례)

조사기관 · 통계

• 12.TrendForce, 서버 출하 전망 하향 및 부품 리드타임 보도자료, 2026-04-15. trendforce.com
• 13.TrendForce, AI 서버 출하 전망 상향 보도자료, 2026-08-05. trendforce.com
• 14.Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," 보도자료, 2025-02-26 (표본 N=248, 2024 Q3). gartner.com

보도 (2차 — 원출처 소급 후 인용)

• 15.The Information, AWS 사내 용량 절감 지시 관련 단독 보도, 2026-08-07 (페이월). theinformation.com
• 16.Tom's Hardware, AWS 보도 재인용 및 AWS 성명 게재. tomshardware.com
• 17.Tom's Hardware, 인텔 서버·소비자 CPU 가격 인상 확인 보도, 2026-04. tomshardware.com
• 18.AI타임스, AWS 사내 CPU 사용 단속 보도. aitimes.com

페블러스 인접 (교차 링크)

• 19.페블러스, "가격이 내릴수록 청구서가 커진다" (2026-06-13) — 토큰 청구서의 축. blog/ai-agent-token-cost-retry-loop
• 20.페블러스, "전력의 벽에 가로막힌 미국 AI 데이터센터 붐" (2026-08-01). report/ai-datacenter-power-wall-2026
• 21.페블러스, 메타의 컴퓨트 쇼크 (2026-07-03). report/meta-compute-semiconductor-shock
• 22.페블러스, 엔비디아 가상 세포 챌린지 — GPU는 충분했고 부족한 것은 데이터였다 (2026-05-12). report/nvidia-virtual-cell-challenge-2026-05