50%.

NVIDIA Vera CPU가 풀로드 상태에서 코어당 성능을 기존 대비 50% 더 빠르게 끌어올린 수치다. 단순히 클럭 속도를 높인 것이 아니라, 에이전틱 AI가 정답을 찾기 위해 파이썬 코드를 생성하고 도구를 호출하는 '추론의 틈'을 메우기 위해 설계된 최적화의 결과다. 이는 마치 고속도로의 제한 속도를 높이는 대신, 병목 현상이 심한 톨게이트를 수십 개로 늘려 전체 흐름을 뚫어버린 것과 같다.

그런데 지금 개발자 커뮤니티가 진짜 뜨겁게 반응하는 지점은 따로 있다. 그동안 AI 인프라의 주인공은 언제나 GPU였다. 하지만 에이전틱 AI 시대로 접어들면서 상황이 바뀌었다. 모델이 스스로 생각하고, 도구를 쓰고, 코드를 실행하는 '오케스트레이션' 단계에서 CPU 병목이 심각하게 발생한다는 사실을 실무자들이 체감하기 시작했기 때문이다. "결국 GPU가 아무리 빨라도 CPU가 데이터를 밀어주지 못하면 깡통이다"라는 말이 나올 정도로 CPU의 역할이 다시 중요해진 시점이다.

NVIDIA는 이 지점을 정확히 파고들었다. Vera는 단순한 보조 프로세서가 아니라, 에이전트의 샌드박싱과 롱 컨텍스트 상태 관리를 위해 태어난 '에이전트 전용 CPU'를 표방한다. 특히 OCI(Oracle Cloud Infrastructure, 오라클 클라우드 인프라스트럭처)가 2026년부터 수십만 대 규모로 이를 도입한다는 소식에, 하이퍼스케일 인프라를 다루는 엔지니어들 사이에서는 "이제는 CPU까지 NVIDIA가 설계한 풀스택 생태계에 종속되는 것인가"라는 논쟁과 "드디어 에이전트 상용화의 병목이 풀린다"는 기대감이 동시에 교차하고 있다.

NVIDIA Vera CPU, 88개 올림푸스 코어와 1.2TB/s 대역폭 탑재

개발팀이 공개한 수치는 여기서 갈린다. 엔비디아가 공개한 베라(Vera) CPU는 88개의 커스텀 올림푸스(Olympus) 코어를 탑재하고 1.2TB/s의 메모리 대역폭을 확보했다. 단순한 스펙 업그레이드가 아니다. 에이전틱 AI(Agentic AI, 스스로 목표를 설정하고 도구를 사용하는 인공지능)가 정답을 내기 위해 파이썬 코드를 직접 생성하고 실행해야 하는 오케스트레이션 과정에서 발생하는 병목 현상을 해결하려는 설계다. 커뮤니티에서는 그동안 GPU에만 쏠렸던 관심이 다시 CPU의 연산 효율로 옮겨가는 분위기가 역력하다. 특히 툴 콜링(Tool-calling, 외부 도구 호출)이나 샌드박싱(Sandboxing, 격리된 환경에서의 코드 실행) 같은 작업이 급증하면서 CPU 수요가 폭발적으로 늘어나는 상황을 정확히 짚어냈다.

실제 풀 로드(Full load, 최대 부하) 상태에서의 코어당 성능은 이전보다 50% 더 빨라졌다. 이는 대규모 추론 워크로드에서 지속적인 성능을 유지해야 하는 에이전틱 AI의 요구사항을 정조준한 결과다. 기존 인프라 대비 에너지 효율을 2배로 높이면서 데이터 이동과 제어 능력을 극대화했다. 개발자들 사이에서는 GPU가 연산을 처리하는 동안 CPU가 얼마나 빠르게 데이터를 밀어 넣어줄 수 있느냐가 관건이라는 논쟁이 이어졌는데 베라가 그 답안지를 제시한 셈이다. 특히 2세대 NVLink-C2C(Chip-to-Chip, 칩 간 고속 연결 기술)를 통해 루빈(Rubin) GPU와 연결되어 통합 메모리 아키텍처를 공유하며 가속 컴퓨팅 자원의 활용도를 극한으로 끌어올렸다.

배포 규모는 상상을 초월한다. 오라클 클라우드 인프라스트럭처(OCI, Oracle Cloud Infrastructure)는 2026년부터 수십만 대 규모의 베라 CPU를 도입할 계획이다. 하이퍼스케일(Hyperscale, 초거대 규모의 데이터 센터) 수준에서 베라를 가장 먼저 도입하는 클라우드 제공사가 된다는 점은 기업용 에이전틱 AI 인프라의 기준점이 바뀔 것임을 암시한다. 이는 단순히 서버 대수를 늘리는 증설 작업이 아니라 프로덕션 등급의 에이전틱 AI 인프라를 구축하여 다른 클라우드 제공사가 따라올 수 없는 규모의 경제를 실현하려는 전략이다.

이 하드웨어의 주 타겟은 AI 랩과 클라우드 제공사 그리고 대규모 에이전틱 AI를 운영하는 기업들이다. RL(Reinforcement Learning, 강화 학습) 워크로드나 롱 컨텍스트 상태 관리(Long-context state management), 데이터 분석처럼 메모리 집약적이고 복잡한 제어가 필요한 환경에서 베라의 가치가 드러난다. 개발 현장에서는 이제 모델의 파라미터 수보다 이를 뒷받침할 오케스트레이션 하드웨어의 효율성이 실제 서비스 응답 속도와 품질을 결정짓는 핵심 변수가 되었다는 반응이 지배적이다.

NVLink-C2C와 통합 메모리로 구현한 Rubin GPU와의 초밀착 결합

Vera Rubin NVL72의 설계 구조에서 가장 먼저 눈에 띄는 점은 호스트 프로세서인 Vera CPU가 Rubin GPU와 맺고 있는 물리적 관계다. 기존의 범용 서버 구조가 PCIe 버스를 통해 데이터를 주고받으며 발생하는 지연 시간에 허덕였다면 이번에는 2세대 NVIDIA NVLink-C2C(Chip-to-Chip, 칩 간 고속 연결 기술)를 도입해 두 프로세서를 사실상 하나의 유닛처럼 묶어냈다. 커뮤니티에서는 이를 두고 단순한 연결 방식의 변경이 아니라 데이터가 흐르는 통로 자체를 완전히 새로 뚫은 격이라는 반응이 나온다. 특히 호스트 CPU가 GPU의 연산 속도를 따라가지 못해 발생하는 병목 현상은 대규모 모델을 돌리는 개발자들에게 고질적인 스트레스였는데 이 초밀착 결합이 그 해결책으로 제시되며 지금 매우 뜨거운 관심을 받고 있다.

핵심은 Vera와 Rubin이 공유하는 통합 메모리 아키텍처(Unified Memory Architecture, CPU와 GPU가 동일한 메모리 공간을 공유하는 구조)에 있다. 이전까지는 CPU 메모리에 있는 데이터를 GPU 메모리로 복사해 옮기는 과정에서 막대한 시간과 자원이 낭비되었으나 이제는 두 장치가 메모리 주소를 공유하며 직접 데이터를 읽고 쓴다. 개발자들 사이에서는 데이터 복사 오버헤드가 사라지면서 가속 컴퓨팅 자원의 활용률이 극대화될 것이라는 기대감이 높다. 메모리 복사라는 불필요한 중간 단계가 생략되니 데이터 이동 경로가 획기적으로 짧아지고 연산 장치가 유휴 상태 없이 계속해서 일할 수 있는 환경이 조성되는 셈이다. 이는 특히 컨텍스트 윈도우가 큰 모델을 다룰 때 메모리 관리의 효율성을 극적으로 높여주는 요소가 된다.

이러한 구조적 변화는 곧바로 에너지 효율의 수치로 증명된다. Vera CPU는 빠른 코어 성능과 최적화된 인터커넥트를 통해 GPU에 데이터를 공급하는 피딩 작업을 수행하며 기존 인프라 대비 2배의 에너지 효율을 달성했다. 단순히 전력을 덜 쓰는 것이 아니라 동일한 전력으로 더 많은 데이터를 더 빠르게 밀어 넣어 GPU가 굶지 않게 만드는 능력이 탁월해진 것이다. 하드웨어 최적화에 민감한 엔지니어들은 전성비(전력 대비 성능 비율)의 비약적인 상승이 곧 데이터센터의 운영 비용 절감과 직결된다는 점에 주목하며 치열한 논쟁을 벌이고 있다. 결국 Vera는 단순한 보조 프로세서를 넘어 Rubin GPU의 연산 잠재력을 끝까지 끌어올려 데이터 병목을 완전히 제거하는 핵심 엔진 역할을 수행한다.

범용 CPU에서 '에이전트 전용'으로, 오케스트레이션 처리 방식의 변화

기존 인프라에서 에이전트가 정답을 도출하는 과정은 생각보다 투박했다. 모델이 질문을 받았을 때 즉각적인 답변을 내놓는 것이 아니라, 내부적으로 파이썬 코드를 생성해 실행하고 그 결과를 다시 해석하는 단계를 거쳐야 했기 때문이다. 개발자 커뮤니티에서는 이 과정에서 발생하는 샌드박싱(Sandbox, 외부 영향 없이 코드를 실행하는 격리 환경) 부하와 오케스트레이션(Orchestration, 여러 작업을 조율하고 배치하는 과정) 지연이 고질적인 병목으로 지적되어 왔다. 범용 CPU는 다양한 작업을 처리하도록 설계되었기에, 에이전트가 실시간으로 코드를 짜고 실행하며 상태를 관리해야 하는 고부하 추론 워크로드에서는 효율이 급격히 떨어지는 모습을 보였다. 특히 복잡한 데이터 분석이나 다단계 추론이 필요한 에이전틱 AI의 경우, CPU가 GPU의 속도를 따라가지 못해 전체 시스템이 대기 상태에 빠지는 현상이 빈번했다.

베라(Vera)는 바로 이 지점을 정조준해 설계된 에이전트 전용 CPU다. 단순히 연산 속도를 높이는 것이 아니라 오케스트레이션, 툴 콜링(Tool-calling, 모델이 외부 도구를 호출하는 기능), 강화학습(RL, Reinforcement Learning) 워크로드, 데이터 분석과 같은 에이전트 특화 작업들을 전담 처리한다. 특히 모델이 정답을 찾기 위해 파이썬 코드를 생성해야 하는 워크로드에 최적화되어 있어, 기존 CPU가 헐떡이던 코드 생성 및 실행 단계의 처리량을 획기적으로 끌어올렸다. 에이전트 샌드박싱과 롱 컨텍스트 상태 관리(Long-context state management, 긴 문맥의 상태를 유지하고 관리하는 기술)를 CPU 레벨에서 전담함으로써 GPU가 오직 추론에만 집중할 수 있는 환경을 구축했다. 이는 모델이 스스로 생각하고 도구를 사용하는 에이전틱 AI의 핵심 루프를 하드웨어 수준에서 가속하는 결과로 이어진다.

현장의 반응은 범용 CPU의 한계를 넘었다는 점에 집중된다. 기존에는 CPU가 단순한 보조 역할에 그쳤다면, 베라는 고처리량 추론 워크로드(High-throughput reasoning workloads)를 위해 설계된 전용 엔진에 가깝다. 이는 루빈(Rubin) GPU, 블루필드 4(BlueField 4) DPU(Data Processing Unit, 데이터 처리 장치) 등과 함께 설계된 엔비디아의 공동 설계 전략의 핵심이다. 베라가 오케스트레이션과 데이터 이동을 효율적으로 처리해 GPU에 밀어 넣어줌으로써, 전체 시스템의 에너지 효율을 기존 인프라 대비 2배 가까이 높였다는 분석이 나온다. 범용 CPU가 모든 일을 적당히 처리하던 시대에서, 에이전트의 사고 과정을 전담하는 전용 프로세서의 시대로 처리 방식의 패러다임이 완전히 바뀌고 있다. 이제 개발자들은 CPU의 성능 부족으로 인해 에이전트의 추론 단계를 제한하거나 타협할 필요가 없는 환경을 맞이하게 된 셈이다.

OCI의 하이퍼스케일 도입과 엔터프라이즈 AI 인프라의 변화

OCI(Oracle Cloud Infrastructure, 오라클 클라우드 인프라스트럭처)가 2026년부터 수십만 개의 NVIDIA Vera CPU를 도입하며 하이퍼스케일 전개를 시작한다. 단순한 하드웨어 추가가 아니라 에이전틱 AI(Agentic AI, 스스로 목표를 설정하고 도구를 사용하는 AI)를 위한 전용 인프라를 클라우드 규모로 구축하는 첫 사례라는 점이 개발자들 사이에서 뜨거운 감자다. 그동안 많은 기업이 에이전트 서비스를 개발했지만 실제 운영 환경인 프로덕션 단계로 넘어가면 성능 저하와 불안정성이라는 벽에 부딪혔다. 이번 OCI의 행보는 실험실 수준의 데모가 아니라 실제 수많은 사용자가 동시에 접속해도 버틸 수 있는 프로덕션 등급의 에이전틱 AI 인프라가 가능해졌음을 의미한다. 현장에서는 이제 모델의 지능보다 그 지능을 뒷받침할 인프라의 체력이 서비스의 실제 가치를 결정한다는 목소리가 높다.

커뮤니티에서는 이제 논의의 중심이 모델의 파라미터 수에서 인프라의 처리량과 지속 가능성으로 빠르게 옮겨가고 있다. 에이전틱 AI는 단순히 질문에 답을 내놓는 것이 아니라 내부적으로 파이썬 코드를 생성하고 실행하며 정답에 도달할 때까지 추론 과정을 반복해야 하므로 지속적인 고성능 연산 능력이 필수적이다. OCI가 하이퍼스케일 도입 첫 주자로 나선 것은 이러한 고처리량 추론 워크로드에 최적화된 Vera의 아키텍처를 통해 엔터프라이즈 급의 안정성을 확보하겠다는 전략이다. 개발자들은 이제 개별 모델의 최적화를 넘어 클라우드 제공사가 제공하는 인프라의 밀도와 전력 효율이 서비스의 성패를 가르는 핵심 변수가 되었다고 분석한다. 특히 대규모 에이전트 군단을 운영해야 하는 기업 입장에서 인프라의 풋프린트 감소는 곧 운영 비용의 획기적인 절감으로 이어진다.

더욱이 이번 도입은 NVIDIA의 익스트림 코디자인(Extreme Co-design, 하드웨어와 소프트웨어를 동시에 최적화하는 설계 방식) 전략의 결정체라는 점에서 업계의 시선이 쏠린다. Vera CPU는 단독으로 작동하는 것이 아니라 Rubin GPU, BlueField 4 DPU(Data Processing Unit, 데이터 처리 장치), Spectrum-X, 그리고 MGX 랙 아키텍처와 하나로 결합되어 작동한다. 이는 CPU가 단순한 보조 프로세서가 아니라 GPU와의 통합 메모리 아키텍처를 통해 데이터 이동 병목을 제거하고 전체 시스템의 효율을 극대화하는 구조다. 인프라 엔지니어들 사이에서는 이러한 수직 계열화된 하드웨어 스택이 에이전트의 샌드박싱이나 긴 컨텍스트의 상태 관리 같은 무거운 작업을 처리하는 유일한 해법이 될 것이라는 의견이 지배적이다. 범용 CPU의 시대가 가고 에이전틱 AI라는 특정 목적을 위해 설계된 전용 하드웨어 스택의 시대가 본격적으로 열렸다는 평가가 나오는 이유다.

한국 AI 실무자가 주목해야 할 'CPU-GPU 통합 최적화'의 실전 의미

현장 개발자들이 가장 먼저 체감하는 병목은 모델의 파라미터 수가 아니라 에이전트가 도구를 호출하며 파이썬 코드를 생성하고 실행하는 찰나의 지연 시간이다. 지금까지는 모델 튜닝으로 응답 품질을 높이는 데 집중했다면 이제는 그 모델이 구동되는 하드웨어의 효율성으로 논의의 중심이 빠르게 옮겨가고 있다. 에이전틱 AI(Agentic AI, 스스로 목표를 설정하고 도구를 사용해 과업을 수행하는 AI)가 확산되면서 대규모 스케일에서 끊김 없이 유지되는 지속적인 성능(sustained performance)이 상용화의 핵심 변수로 떠올랐다. 커뮤니티에서는 단순히 GPU를 많이 투입하는 방식으로는 추론 비용과 응답 속도라는 두 마리 토끼를 잡을 수 없다는 회의론과 함께 인프라 레벨의 최적화가 필요하다는 목소리가 뜨겁다. 특히 실시간으로 수많은 에이전트가 동시에 작동해야 하는 엔터프라이즈 환경에서는 찰나의 병목이 전체 서비스 경험을 망가뜨린다는 분석이 지배적이다.

이번에 공개된 베라(Vera) CPU는 오케스트레이션(Orchestration, 여러 작업을 조율하고 배치하는 과정)과 툴 콜링(Tool-calling, 외부 도구 호출), 그리고 에이전트 샌드박싱(Agent Sandboxing, 격리된 환경에서 코드를 안전하게 실행하는 기술) 같은 작업을 전담한다. 여기에 강화 학습(RL) 워크로드와 데이터 분석, 롱 컨텍스트 상태 관리(Long-context state management)까지 처리하며 GPU의 부담을 덜어준다. 특히 루빈(Rubin) GPU와 통합 메모리 아키텍처를 공유하며 데이터 이동 경로를 극단적으로 줄인 점이 실무자들 사이에서 주목받는 지점이다. 이는 블루필드 4(BlueField 4) DPU(Data Processing Unit, 데이터 처리 전용 장치), 스펙트럼-X(Spectrum-X) 네트워크, MGX 랙 아키텍처로 이어지는 하드웨어-소프트웨어 공동 설계(co-design) 전략의 결과물이다. 개발자들은 이제 모델 하나를 잘 만드는 것을 넘어 어떤 CPU와 GPU 조합이 자신의 워크로드에 최적인지를 직접 검증하고 커스터마이징해야 하는 새로운 단계에 진입했다.

한국의 AI 실무 환경에서도 단순한 벤치마크 수치보다 실제 서비스 워크로드에 맞춘 시스템 검증의 중요성이 비약적으로 커질 수밖에 없다. 에이전트가 복잡한 추론 과정을 거치며 상태를 유지하고 외부 API와 통신할 때 CPU의 효율성이 떨어지면 결국 고가의 GPU가 연산을 기다리며 놀게 되는 자원 낭비가 발생하기 때문이다. 하드웨어와 소프트웨어를 동시에 설계하는 공동 설계 방식은 응답 속도를 높이는 동시에 클라우드 운영 비용을 결정짓는 결정적인 요소가 된다. 에이전트 서비스의 상용화 단계에서는 모델의 지능만큼이나 이를 뒷받침하는 인프라의 밀도와 전력 효율이 기업의 실질적인 경쟁력이 되는 시대가 왔다. 실무자들은 이제 모델 가중치 최적화라는 좁은 틀을 벗어나 시스템 전체의 데이터 흐름과 하드웨어 자원 배분을 최적화하는 관점으로 접근해야 한다.