AI 팩토리, 왜 CPU 설계가 다시 중요해졌나
GPU가 모델을 돌리는 동안, CPU는 오케스트레이션·툴 실행·샌드박스 컴퓨팅을 담당합니다. 문제는 여기예요. 기존 서버 워크로드는 런타임 프로파일이 안정적이라 코어 수를 예측해서 스펙을 정할 수 있었지만, 에이전트 워크로드는 예측 불가능하고 편차가 극심합니다.
실제로 163,594개의 에이전트 세션 텔레메트리를 분석해보면, **97% 이상의 세션이 서로 다른 실행 궤적(trajectory)**을 보였습니다. 이 정도 편차면 "툴 호출 패턴이 이런 경우엔 A CPU, 저런 경우엔 B CPU" 식으로 플릿을 쪼개는 건 사실상 무의미해요.
이 글에서는 에이전트 세션의 실제 형태(길이와 너비)를 뜯어보고, 왜 균형 잡힌 단일 CPU 설계점이 플릿 경제성 측면에서 유리한지 살펴봅니다. 근거자료는 NVIDIA Developer Blog의 원문 분석을 참고했어요.
에이전트 궤적의 두 축: 길이(Length)와 너비(Width)
에이전트 세션의 형태는 두 가지 축으로 정의됩니다.
- 길이(Length): 에이전트가 한 턴을 끝낼 때까지 필요한 추론 단계·툴 호출·재시도·서브태스크의 수
- 너비(Width): 각 단계에서 동시에 뻗어나가는 작업량(병렬 툴 호출, 검색, 샌드박스, 서브에이전트)
여기서 중요한 포인트가 있어요. 세션의 너비가 아무리 넓어도, 실제 wall-clock 시간의 대부분은 순차 체인(sequential chain)에서 소비됩니다. 왜냐하면 병렬 버스트는 일시적이고, 의존성 체인은 세션 내내 지속되거든요.
# 개념 예시: 에이전트 세션의 시간 분해
# (실제 텔레메트리 구조를 단순화한 의사 코드)
class AgentSession:
def run_turn(self):
# 순차 경로: 세션 완료 시간을 결정하는 지배적 경로
plan = self.llm_reason() # latency-bound
while not self.done:
tool = self.pick_tool(plan) # 순차
# 병렬 팬아웃: 일시적 버스트, 서브에이전트/툴 동시 호출
results = self.fan_out([
self.call_tool(tool),
self.retrieve_context(),
self.spawn_subagent(),
])
# 팬아웃 결과가 모두 돌아올 때까지 메인 에이전트는 대기
plan = self.llm_reason(results)
핵심은 팬아웃 도중에도 per-thread latency가 여전히 중요하다는 점입니다. 병렬 작업이 끝나야 메인 에이전트가 다음 단계로 진행할 수 있으니까요. 결국 CPU 플릿은 전체 궤적을 최적화해야 합니다.
- 팬아웃 버스트를 흡수할 동시성(concurrency)
- 순차 경로를 빠르게 밀어줄 강한 단일 스레드 성능
이 두 가지가 동시에 필요해요. 그래서 에이전트 CPU 플릿의 최적화 목표는 '코어 개수'가 아니라 **'완료된 사용자 세션 수(completed sessions)'**가 되어야 합니다.
고코어 CPU의 함정: 메모리 TCO와 동기화 오버헤드
높은 코어 수는 스펙 시트상 매력적으로 보입니다. 하지만 실제로는 트레이드오프가 발생해요.
1) 코어 밀도를 위해 단일 스레드 성능을 희생
코어 수 목표를 맞추려다 보면, 에이전트의 critical path에서 필요한 per-thread 성능을 깎게 됩니다. 그 결과 순차·지연 민감(latency-sensitive) 작업이 저성능 코어에 배정되거나, 대규모 이기종 클러스터에서 동기화 오버헤드가 폭증합니다.
2) 터보 부스트와 메모리 낭비
CPU는 순간적으로 일부 코어를 "꺼서" 단일 스레드 성능을 부스트할 수 있습니다. 그런데 이 방식은 코어당 8GB 메모리를 놀리는 결과를 낳고, 메모리 TCO 페널티로 직결됩니다. 즉, 순간 성능을 위해 상시 자원을 낭비하는 셈이죠.
3) 순차 경로 무시의 대가
에이전트 워크로드는 대부분의 wall-clock을 순차 체인에서 소비합니다. 이 경로를 무시하고 코어 수만 늘리면, 팬아웃 버스트는 잘 처리해도 세션 완료 시간은 개선되지 않습니다.
⚠️ 국내 SI·클라우드 환경에서 특히 주의할 부분: 코어 수 중심의 인스턴스 스펙 비교는 에이전트 워크로드에서 오해를 부르기 쉽습니다. 세션 완료율(throughput of completed turns)과 p95 latency를 함께 봐야 실제 비용 효율이 드러나요.
균형 잡힌 CPU 설계는 특정 단계가 아니라 전체 궤적을 최적화합니다. 강한 per-thread 응답성 + 의미 있는 동시성 + 충분한 메모리 대역폭 + 효율적 전력 사용, 이 네 가지가 함께 가야 코어·DRAM·GPU HBM을 낭비 없이 쓸 수 있습니다.
실무 적용 조언 및 다음 단계
정리하면 이렇습니다.
- 플릿 스펙 결정 기준을 '코어 수'에서 '완료 세션 수'로 바꾸세요. 에이전트 워크로드에서 코어 수는 결과 지표가 아닙니다.
- 순차 경로의 p95 latency를 반드시 측정하세요. 이 경로가 세션 완료 시간을 지배합니다.
- 팬아웃 버스트를 흡수할 동시성과 per-thread 성능을 동시에 확보하세요. 둘 중 하나만 강한 설계는 특정 구간에서 병목이 됩니다.
- 메모리 대역폭과 TCO를 워크로드 프로파일과 함께 검증하세요. 터보 부스트로 얻는 순간 성능이 메모리 낭비로 상쇄될 수 있습니다.
이 접근의 한계
- 본 분석은 특정 벤더(NVIDIA Vera CPU)의 아키텍처와 내부 측정 결과에 기반합니다. 경쟁사 결과는 추정치가 포함되어 있어 워크로드에 따라 순위가 뒤집힐 수 있습니다.
- SPEC CPU 2026 결과는 합성 벤치마크이며, 실제 에이전트 세션의 다양성(97% 고유 궤적)을 완전히 반영하지는 못합니다.
- "단일 설계점으로 충분하다"는 주장은 워크로드가 실제로 균질하다는 전제에 의존합니다. 이질적 워크로드가 섞이는 환경에서는 재검증이 필요합니다.
다음 단계 학습 방향
- 에이전트 오케스트레이션 레이어(예: 서브에이전트 스케줄링, 툴 호출 큐잉)의 병목 분석
- 샌드박싱 격리 수준과 CPU 오버헤드의 트레이드오프
- 실제 프로덕션 텔레메트리 수집 파이프라인 설계(세션 궤적 로깅)