CPU가 다시 스택의 중심으로 돌아왔습니다 — 하지만 아무도 이를 예산에 반영하지 않았습니다

CPU는 스택을 떠난 적이 없습니다. CPU는 조용히, 그리고 잘못되게 '지원 컴퓨팅 (support compute)'으로 재분류되었을 뿐입니다. GPU에 데이터를 공급하고, GPU를 중심으로 스케줄링을 수행하며, GPU가 "진짜" 작업을 수행하는 동안 방해되지 않도록 자리를 비켜주는 존재로 취급되었습니다. 이러한 분류는 AI 워크로드가 예측 가능한 형태를 가진 거대하고 단일한(monolithic) 학습 및 추론 작업이었던 기간 동안에만 유효했습니다. 하지만 에이전트 시스템 (agentic systems)에서는 더 이상 통하지 않습니다. 에이전트 아키텍처 (agentic architectures)에서 CPU는 무엇을, 어떤 순서로, 어떤 권한으로 실행할지, 그리고 두 에이전트가 동시에 동일한 리소스를 원할 때 어떤 일이 발생할지를 결정하는 주체로서 다시 스택의 중심으로 돌아왔습니다. 이것은 지원 역할이 아닙니다. 이것은 전체 시스템이 의존하는 조정 기질 (coordination substrate)이며, 거의 아무도 이를 위한 인프라 예산을 책정하지 않았습니다.

Xeon 공급 제약은 증상일 뿐, 본질이 아닙니다

현재 발생하고 있는 Xeon 공급 부족 현상 — 할당 지연, 이전 분기를 훨씬 상회하는 리드 타임(lead times), 하이퍼스케일러(hyperscalers)들이 자사 플릿(fleets)을 우선시한다는 보고 등 — 은 대부분의 보도에서 GPU와 관련된 이야기로 해석되고 있습니다. 즉, CPU는 가속 노드 (accelerated nodes)의 "호스트 (host)" 측이며, 호스트 측의 부족이 GPU 배포를 늦추고 있다는 식입니다. 이러한 프레임워크가 완전히 틀린 것은 아닙니다. 하지만 중요한 측면에서 불완전합니다.

Xeon 제약은 하나의 증상입니다. 이는 이미 존재하고 이미 커지고 있었던 의존성을 드러내고 있기 때문입니다. 다만 호스트 CPU를 아무 생각 없이 과다 할당(over-provision)해도 되는 범용 인프라(commodity infrastructure)로 취급하는 동안에는 그 의존성이 눈에 보이지 않았을 뿐입니다. 에이전트 중심의 워크로드(Agentic workloads)가 호스트 CPU의 역할을 변화시켰습니다. 이제 CPU는 단순히 가속기로 데이터를 전달하고 네트워크 I/O를 처리하는 역할에 그치지 않습니다. CPU는 18개월 전에는 유의미한 규모로 존재하지 않았던 시스템들을 위해 오케스트레이션 계층(orchestration layer) — 즉, 에이전트 루프(agent loop), 도구 호출 라우팅(tool-call routing), 정책 검사(policy checks), 메모리 및 컨텍스트 관리(memory and context management) — 을 실행하고 있습니다. 공급 충격(supply shock)이 이 의존성을 만들어낸 것이 아닙니다. 가뭄이 어떤 나무의 뿌리가 얕은지를 드러내듯, 공급 충격은 이미 존재하던 의존성을 드러냈을 뿐입니다.

에이전트 중심 시스템이 인프라 비율을 역전시키다

생성형 AI의 첫 번째 물결 — 대규모 학습(large training runs), 배치 추론(batch inference), 단일 모델 서빙(single-model serving) — 동안 인프라 비율은 명확했습니다. GPU가 거의 모든 작업을 수행하고, CPU는 거의 수행하지 않는 구조였습니다. 프로비저닝(Provisioning)도 그 비율을 따랐습니다. 가속기 플릿(accelerator fleet)의 규모를 먼저 결정하고 호스트 계층은 부차적인 것으로 취급했는데, 이는 모델 크기와 상관없이 호스트 계층의 작업량이 적고 대체로 고정되어 있었기 때문입니다.

에이전트 중심 시스템은 그 비율을 깨뜨리며, 아무도 예상하지 못한 방향으로 깨뜨립니다. 에이전트 루프는 단 한 번의 추론 호출이 아닙니다. 그것은 도구 호출(tool calls), 검색 호출(retrieval calls), 상태 업데이트(state updates), 정책 평가(policy evaluations), 그리고 라우팅 결정(routing decisions)이 뒤섞인 일련의 추론 호출 시퀀스입니다. 여기서 이러한 단계들이 뒤섞이는 '횟수'는 모델 크기가 아니라 작업의 복잡성에 따라 확장됩니다. 이러한 모든 단계는 아키텍처의 CPU 측에서 실행됩니다. 에이전트 중심 시스템이 더 긴 호흡의 다단계(multi-step), 다중 에이전트(multi-agent) 작업을 수행함에 따라, CPU 바운드(CPU-bound) 조정 작업의 양은 증가하며, 이는 해당 작업이 조정하는 GPU 바운드(GPU-bound) 실행 작업보다 더 빠르게 증가합니다. "CPU는 부차적인 것이다"라는 프로비저닝을 정당화했던 비율은 단순히 이동하는 것이 아니라, 역전됩니다.

첫 번째 AI 물결은 GPU 중심이었다

왜 GPU 중심의 프레임워크가 그토록 오랫동안 타당했는지 정확히 짚고 넘어갈 가치가 있습니다. 그 대조를 이해해야만 이러한 역전 현상을 명확히 파악할 수 있기 때문입니다.

학습(Training) 작업은 구조적으로 GPU에 종속(GPU-bound)되어 있습니다. 하드웨어의 존재 목적 자체가 가속기(Accelerator)를 통해 가능한 한 많은 행렬 연산(Matrix math)을 밀어붙이는 것이며, 호스트 측(Host-side)의 작업은 거의 전적으로 GPU에 데이터를 계속 공급하기 위해 존재합니다. 지난 2년간의 프로비저닝(Provisioning) 논의들 — 10만 개의 GPU 클러스터를 위한 800G 급 패브릭 물리(Fabric physics), 프라이빗 LLM 학습을 위한 GPU 클러스터 아키텍처, Kubernetes 내부의 GPU 스케줄링(Scheduling) — 은 모두 가속기를 희소 자원이자 설계 시 고려해야 할 병목 지점(Bottleneck)으로 보았으며, 이는 올바른 접근이었습니다.

이러한 프레임워크는 초기 추론(Inference) 배포 단계까지 이어졌으며, 이는 GPU 활용률(Utilization) 자체가 눈에 보이는 문제가 된 이유 중 하나이기도 합니다. 가속기가 예산과 설계 노력의 핵심 대상일 때, 유휴 GPU 사이클(Idle GPU cycles)은 모두가 주시하는 실패 모드(Failure mode)가 됩니다. 그 시대에 구축된 도구들은 정확히 다음과 같은 질문에 답하기 위해 만들어졌습니다: 가속기가 제약 사항(Constraint)인가, 그리고 그것이 효율적으로 사용되고 있는가? 이 도구들은 원래 설계된 워크로드(Workload)에 대해서는 여전히 유효합니다. 문제는 에이전트형 워크로드(Agentic workloads)는 더 이상 예전의 워크로드와 완전히 같지 않다는 점이며, GPU 측면만 감시하는 도구는 아키텍처의 반대편에서 형성되고 있는 제약 사항을 포착하지 못할 것이라는 점입니다.

CPU가 거버넌스 계층(Governance Layer)이 되다

역전 현상을 명확히 말씀드리자면, 에이전트형 AI 인프라에서 CPU의 역할은 더 이상 GPU를 지원하는 것이 아닙니다. CPU의 역할은 시스템을 거버넌스(Govern, 관리/통제)하는 것입니다. 즉, GPU(및 시스템의 다른 모든 자원)가 무엇을 할 수 있는지, 어떤 순서로, 어떤 제약 조건 하에서 수행할지, 그리고 왜 그렇게 하는지에 대한 기록을 남기며 결정하는 역할을 합니다.

"거버넌스 계층(Governance layer)"이라는 말이 구체적인 실체와 연결되지 않는다면 단순한 브랜딩 용어처럼 들릴 수 있습니다. 따라서 실제 소모되는 사이클(Cycles) 관점에서 이것이 무엇을 의미하는지 설명하겠습니다.

태스크 오케스트레이션 (Task orchestration) 및 에이전트 시퀀싱 (Agent sequencing). 모든 에이전트 시스템은 어떤 에이전트나 하위 태스크(sub-task)를 다음에 실행할지, 어떤 순서로 실행할지, 그리고 현재 태스크의 상태를 고려했을 때 특정 단계가 진행되는 것이 허용되는지 여부를 결정해야 합니다. 그 결정 로직 — 즉 에이전트 루프(agent loop)의 제어 흐름(control flow) — 은 모든 단계에서, 모든 에이전트에 대해, 지속적으로 CPU 위에서 실행됩니다.

메모리 및 컨텍스트 중재 (Memory and context arbitration). 에이전트들은 단일 모델 추론(inference) 호출이 그러하듯 단일하고 단순한 컨텍스트 창(context window)을 공유하지 않습니다. 여러 에이전트와 여러 단계가 공유 메모리, 벡터 스토어(vector stores), 그리고 컨텍스트 상태(context state)를 읽고 쓰며, 어떤 쓰기 작업이 승리할지, 어떤 단계에 무엇을 검색(retrieve)할지, 그리고 언제 컨텍스트를 가지치기(prune)하거나 요약(summarize)할지를 중재하는 무언가가 반드시 필요합니다. 이러한 중재는 CPU 바운드(CPU-bound) 조정 작업이며, 이는 모델 크기가 아니라 에이전트의 수와 태스크의 깊이에 따라 확장됩니다.

에이전트 간 동기화 및 충돌 해결 (Cross-agent synchronization and conflict resolution). 두 에이전트(또는 동일한 에이전트 태스크의 두 단계)가 동일한 리소스 — 도구(tool), 상태(state)의 일부, 공유 메모리에 대한 쓰기 잠금(write lock) — 를 원할 때, 단순히 먼저 도착한 요청에 따르는 것이 아니라 정책에 따라 해당 충돌을 해결하는 무언가가 있어야 합니다. 이것이 가장 문자 그대로의 의미에서의 런타임 제어 평면(runtime control plane)이며, rack2cloud의 거버넌스(governance) 작업이 수개월 동안 매핑해 온 아키텍처 영역입니다.

이것이 구조적 역전입니다. 연산 밀도(Compute Density) — 작업이 얼마나 많은 인프라에서 실행되는가 — 가 과거에는 이야기의 전부였습니다. 왜냐하면 작업이 충분히 단순하여 이를 조정하는 비용이 거의 들지 않았기 때문입니다. 조정 밀도(Coordination Density) — 작업을 거버넌스(govern) 하는 데 얼마나 많은 인프라가 필요한가 — 는 항상 0이 아니었지만, 무시할 수 있을 정도로 작았습니다. 에이전트 시스템은 조정 작업을 무(無)에서 만들어내는 것이 아닙니다. 그들은 조정 작업을 지배적인 비용으로 만듭니다.

업계가 잘못된 리소스를 측정하고 있습니다

만약 조정 (Coordination)이 이제 에이전트 시스템 (Agentic systems)에서 지배적인 비용이라면, 용량 계획 (Capacity planning), 비용 할당 (Cost allocation), 그리고 SLA 설계 (SLA design)를 규정하는 지표들도 이를 반영해야 합니다. 하지만 그렇지 않습니다. 오늘날 프로덕션 AI 관측성 (Observability)의 거의 모든 지표는 컴퓨팅 밀도 (Compute Density) 지표 — 즉, GPU 측 실행에 대한 측정값 — 이며, 현재 제약 사항 (Constraint)을 유발하고 있는 CPU 측의 조정 작업 (Coordination work)을 측정하는 지표는 거의 없습니다.

추적됨 (컴퓨팅 밀도)	추적되지 않음 (조정 밀도)
GPU 사용률 %	작업당 오케스트레이션 호출 (Orchestration calls)
...

오른쪽 열의 항목 중 표준 GPU 클러스터 대시보드에 나타나는 것은 아무것도 없습니다. 일반적인 클라우드 비용 할당 보고서에도 나타나지 않는데, 이는 해당 작업이 그 자체로 하나의 워크로드 (Workload)로서 프로비저닝된 것이 아니라, "인프라 오버헤드 (Infrastructure overhead)"로 프로비저닝된 호스트 노드 (Host nodes) 상의 CPU 시간이기 때문입니다. 계측 (Instrument)하지 않는 제약 사항은 관리할 수 없으며, 현재 거의 아무도 이 부분을 계측하고 있지 않습니다.

용량 모델이 따라잡지 못한 이유

용량 계획 (Capacity planning) 모델은 모델이 구축될 당시의 지배적인 비용 동인 (Cost driver)으로부터 그 구조를 물려받습니다. 그리고 AI 인프라의 전체 첫 번째 파동 동안 지배적인 비용 동인은 가속기 (Accelerator)였습니다. 이러한 가정은 에이전트 워크로드 (Agentic workloads)가 이를 무너뜨리기 시작할 때까지는 명확히 드러나지 않는 방식으로 시스템의 근간을 지탱하고 있습니다.

기존 용량 모델 (Compute-Centric)	새로운 용량 모델 (Coordination-Aware)
가속기 플릿(accelerator fleet) 규모를 먼저 결정; 호스트 노드는 고정된 비율을 따름	조정 계층(coordination layer)을 독립적으로 산정 — 모델 크기가 아닌 작업 복잡성에 따라 확장됨
...
이 지점은 비용 가시성(cost-visibility) 문제가 경제학과 직접적으로 연결되는 지점이기도 합니다. 가장 큰 비용적 충격을 받는 조직은 전체적으로 얼마를 쓰고 있는지가 아니라, 아키텍처의 어느 계층에서 비용이 실제로 쌓이고 있는지에 대한 가시성이 가장 낮은 조직들입니다. 조정 밀도(Coordination Density)가 AI 인프라 지출에서 가장 큰 미계상 항목(unaccounted-for line item)이 되려는 이유는 바로 그 때문입니다. 즉, 이는 실제 하드웨어에서 발생하는 실제 비용임에도 불구하고, 아직 그 어떤 용량 모델에도 이를 위한 항목이 마련되어 있지 않기 때문입니다.

다음 제약 사항은 이전의 것과는 다를 것입니다

지금까지 AI 인프라의 모든 용량 제약은 하드웨어 부족의 형태를 띠었습니다. GPU, 그 다음은 HBM, 네트워크 패브릭(network fabric), 그리고 이제는 호스트 CPU 순이었습니다. 이러한 패턴은 업계 전체가 첫 번째이자 때로는 유일한 용량 질문으로 "어떤 부품이 부족한가?"를 묻도록 길들여 놓았습니다.

다음 제약 사항은 그런 모습이 아닐 것입니다. 왜냐하면 그것은 하드웨어 부족이 전혀 아니기 때문입니다. 그것은 아키텍처의 문제입니다. CPU는 더 많이 살 수 있습니다. 하지만 에이전트 시스템(agentic systems)이 더 많은 에이전트, 더 긴 작업 범위(task horizons), 그리고 더 많은 에이전트 간 의존성(cross-agent dependencies)을 떠맡게 됨에 따라 비선형적으로 확장될 필요가 없는 조정 아키텍처(coordination architecture)는 살 수 없습니다. 제약 사항은 그 아래에 깔린 실리콘의 공급량이 아니라, 조정 문제의 "형태(shape)"에 있습니다. 그리고 형태에 의한 제약은 조달(procurement)을 통해 해결되지 않습니다.

프레임워크 #132 — 조정 밀도 (Coordination Density)

위에서 언급한 모든 시스템이 수렴하고 있는 지점은 하나의 근본적인 관계이며, 여기에 이름을 붙이는 것이 나머지 논의를 다룰 수 있게(tractable) 만드는 핵심입니다.

**조정 밀도 (Coordination Density)**는 단위 AI 실행(AI execution)을 생성하는 데 필요한 오케스트레이션 (orchestration), 거버넌스 (governance), 검색 (retrieval), 정책 평가 (policy evaluation), 그리고 제어 평면 (control-plane) 작업의 양을 의미합니다. 컴퓨팅 밀도 (Compute Density)가 얼마나 많은 인프라가 작업을 실행하는지를 측정한다면, 조정 밀도 (Coordination Density)는 그 작업을 관리(govern)하기 위해 얼마나 많은 인프라가 필요한지를 측정합니다. 그리고 에이전트 시스템 (agentic systems)에서는 후자가 전자보다 더 빠르게 성장합니다.