NVIDIA, 클라우드 없이 노트북에서 에이전트 구축 아키텍처 시연

GTC 2026 기조연설이 중반부에 접어들었을 때, Jensen Huang은 노트북 한 대를 꺼냈습니다.

슬라이드를 실행하기 위해서도, 데이터 센터 어딘가에 있는 API 엔드포인트(API endpoint)를 호출하기 위해서도 아니었습니다. 그는 AI 에이전트 (AI Agent) 인터페이스를 열고, 특정 스타일, 면적, 방향, 기능적 구역 설정 등 자연어(natural-language)로 된 건축 설계 브리프를 입력한 뒤 실행했습니다.

다음 몇 분 동안, 에이전트는 요구 사항을 자율적으로 분석하고, 설계 제안서를 생성하며, 코드를 작성하고, 스스로 디버깅(debug)하여 완성된 결과물을 전달했습니다. 어느 시점에서도 인간의 개입은 없었습니다. 무슨 일이 일어나고 있는지 설명하기 위한 극적인 멈춤도 없었습니다. 그저 노트북이 작업을 수행했을 뿐입니다.

그 노트북은 NVIDIA의 새로운 N1X 칩으로 구동되는 RTX Spark였습니다. Blackwell GPU + Grace CPU + 128GB 통합 메모리(unified memory)를 탑아하여, 데스크톱 PC 폼 팩터(form factor)에 페타플롭(Petaflop)급 연산 능력을 담아냈습니다. Huang은 이를 "40년 만에 이루어진 PC의 첫 번째 재정의"라고 불렀습니다.

대담한 주장입니다. 하지만 이 데모를 진정으로 흥미롭게 만든 것은 칩 사양만이 아니었습니다. 그것은 온디바이스 AI 에이전트 (on-device AI Agents)를 위한 풀 스택 (full stack)이 마침내 사용 가능한 임계값에 도달했다는 함의였습니다. 실리콘(silicon)부터 오케스트레이션 (orchestration)에 이르기까지 기술 스택의 모든 계층이 로컬 하드웨어에서 실제 결과물을 생성하기 위해 함께 작동할 수 있을 정도로 독립적으로 성숙했습니다.

아키텍처를 깊이 파고들기 전에, 오픈 소스 (open-source) 커뮤니티가 이미 작동하는 구현체들을 출시하고 있다는 점을 주목할 가치가 있습니다. Mano-P는 에지 디바이스 (edge devices)를 위해 특별히 설계된 Apache 2.0 라이선스의 GUI 에이전트 (GUI Agent) 모델입니다. 이 모델은 Apple Silicon Mac에서 복잡한 GUI 자동화 작업을 완전히 온디바이스 (on-device)로 실행하며, 클라우드 호출이나 기기를 벗어나는 데이터 전송이 전혀 없습니다. 저는 이 포스트 전반에 걸쳐 현재 온디바이스 AI가 실제로 어느 단계에 와 있는지에 대한 기준점(ground truth)으로서 이 모델의 벤치마크 데이터를 참조할 것입니다.

해당 데모 뒤에 숨겨진 4계층 스택

GTC 데모는 설계 단계부터 정교하게 다듬어집니다. 이와 같은 결과물을 실제로 출시하기 위해 무엇이 필요한지 이해하기 위해, 스택을 4개의 계층으로 분해하여 각 계층의 현재 성숙도를 살펴보겠습니다.

계층 1: 실리콘 (Silicon)

온디바이스 AI (On-device AI)는 전통적인 컴퓨팅 워크로드와 근본적으로 다른 하드웨어 요구 사항을 가집니다. 중요한 것은 피크 FLOPS(부동 소수점 연산 능력)나 코어 수가 아니라, 메모리 대역폭 (memory bandwidth), 통합 메모리 용량 (unified memory capacity), 그리고 저정밀도 연산 처리량 (low-precision compute throughput)입니다.

전통적인 PC 아키텍처는 CPU, GPU, 그리고 시스템 메모리를 분리합니다. 데이터는 트랜스포머 추론 (transformer inference)의 액세스 패턴을 위해 설계되지 않은 버스 (bus)를 통해 앞뒤로 계속 이동합니다. FP16 정밀도의 40억 파라미터 모델은 가중치 (weights)를 위해서만 약 8GB가 필요하며, 여기에 활성화 메모리 (activation memory), KV 캐시 (KV cache), 그리고 오버헤드 (overhead)가 추가됩니다. GPU가 PCIe를 통해 끊임없이 데이터를 스왑 (swap)해야 할 때, 지연 시간 (latency)은 이론적인 처리량의 이점을 모두 상쇄해 버립니다.

NVIDIA의 해답은 N1X입니다. 이는 Blackwell GPU와 Grace CPU를 결합하고 128GB의 통합 메모리 (unified memory)를 갖춘 이기종 아키텍처 (heterogeneous architecture)입니다. 대규모 모델은 샤딩 (sharding) 없이 전체를 로드할 수 있습니다. GPU, CPU, 메모리는 단일 주소 공간 (address space)을 공유하여, 개별 GPU (discrete GPU) 구성에서 발생하는 데이터 이동 오버헤드를 제거합니다.

Apple은 다른 경로를 택합니다. 효율성 우선 설계 철학을 가진 통합 메모리 아키텍처 (unified memory architecture)입니다. 32GB/64GB 구성의 M4/M5 시리즈 칩은 의미 있는 규모의 모델을 실행할 수 있습니다. Apple의 접근 방식은 가공되지 않은 TFLOPS를 전력 효율성과 와트당 메모리 대역폭 (memory bandwidth per watt)과 맞바꾸는 것이며, 이는 근본적으로 메모리 대역폭에 제한을 받는 (memory-bound) 추론 워크로드에서 놀라울 정도로 좋은 거래임이 드러났습니다.

두 접근 방식은 한 지점에서 수렴합니다. 통합 메모리는 온디바이스 AI를 위한 필수 조건 (table stakes)이라는 점입니다. 전통적인 CPU + 개별 GPU + 분리된 메모리 아키텍처는 대규모 모델 추론의 대역폭 요구 사항을 감당할 수 없습니다. 이는 단순한 사양 업그레이드가 아닌, 진정한 아키텍처의 전환입니다.

현재 상태: NVIDIA와 Apple 모두 4B–7B 파라미터 모델이 원활하게 실행될 수 있는 수준까지 엣지 실리콘 (edge silicon)을 발전시켰습니다. 더 높은 메모리 구성에서는 더 큰 모델도 실행 가능합니다. 이 계층은 더 이상 병목 현상 (bottleneck)이 아닙니다.

계층 2: 추론 프레임워크 (Inference Frameworks)

하드웨어 성능은 이를 활용할 효율적인 추론 프레임워크 (inference frameworks) 없이는 아무런 의미가 없습니다. 이론적으로 메모리에 들어갈 수 있는 모델이라 할지라도, 실질적인 처리량 (throughput)을 달성하기 위해서는 어텐션 연산 (attention computation), KV 캐시 관리 (KV cache management), 그리고 양자화된 행렬 곱셈 (quantized matrix multiplication)을 위한 세심하게 최적화된 커널 (kernels)이 필요합니다. 이 계층은 지난 1년 동안 급격한 발전을 이루었습니다.

Apple의 MLX 프레임워크는 이제 가중치 양자화 (weight quantization, W8A16, W4A16)에 대한 네이티브 지원과 깊은 Apple Silicon 최적화를 갖춘 성숙한 단계에 도달했습니다. 이 프레임워크는 메모리 매핑 (memory mapping), 지연 평가 (lazy evaluation), 그리고 통합 메모리 액세스 패턴 (unified memory access patterns)을 즉시 처리할 수 있습니다. 커뮤니티는 Apple 하드웨어에서 가능한 한계를 계속해서 넓혀가고 있습니다.

예를 들어, 오픈 소스인 Cider SDK는 MLX 상단에 W8A8/W4A8 활성화 양자화 (activation quantization)를 추가합니다. 기술적인 차이점은 다음과 같습니다. 기본 MLX는 가중치 (weights)만 양자화하고 활성화 값 (activations)은 FP16/FP32로 유지합니다. 이는 행렬 곱셈 중에 한 피연산자 (operand)는 저정밀도이지만 다른 하나는 여전히 전체 너비(full-width)를 유지하므로, 속도 향상이 제한됨을 의미합니다. Cider는 활성화 값 또한 INT8로 압축하여 연산 커널 (compute kernels)이 완전히 저정밀도 산술 (low-precision arithmetic)로 작동할 수 있게 합니다. 그 결과, M5 Pro에서 MLX W4A16 베이스라인 대비 1.4x–2.2x의 프리필 (prefill) 가속을 달성했습니다. INT8 TensorOps는 M5+ 칩에 특화되어 구축되었으며, 이 SDK는 모델 불가지론적 (model-agnostic)입니다. 즉, Mano-P뿐만 아니라 MLX와 호환되는 모든 모델에서 작동합니다.

NVIDIA 측면에서는 TensorRT-LLM과 관련 추론 도구들이 RTX Spark를 위한 Blackwell 전용 최적화를 제공합니다. NVIDIA는 자사 실리콘을 위한 추론 커널 최적화 분야에서 수년간의 경험을 보유하고 있으며, Blackwell 아키텍처는 트랜스포머 워크로드 (transformer workloads)를 더욱 가속화하는 새로운 저정밀도 데이터 타입을 도입했습니다.

현재 상태: 추론 프레임워크 (Inference frameworks)는 "실행된다"의 단계를 넘어 "빠르게 실행된다"의 단계로 진화했습니다. 양자화 (Quantization) 기술의 발전은 온디바이스 모델 추론 (on-device model inference)을 실질적인 사용 가능 수준에 가깝게 끌어올렸습니다. "기술적으로 가능한 것"과 "매끄러운 사용자 경험" 사이의 간극이 크게 좁혀졌습니다.

레이어 3: 모델 (Models)

모델 자체가 실제 작업을 처리할 수 없다면 빠른 프레임워크는 의미가 없습니다. 엣지 모델 (edge models)이 직면한 근본적인 갈등은 다음과 같습니다. 파라미터 수 (parameter counts)는 메모리와 연산 능력에 의해 제한되지만, 작업의 복잡도는 로컬에서 실행한다고 해서 줄어들지 않습니다. 사용자는 모델이 40억 개(4B)의 파라미터를 가졌는지 4,000억 개(400B)의 파라미터를 가졌는지에는 관심이 없습니다. 그들은 모델이 자신의 작업을 정확하게 완료할 수 있는지에 관심을 가집니다.

이 지점에서 최근의 벤치마크 (benchmarks)는 놀랍고도 흥미로운 이야기를 들려줍니다.

Mano-P의 72B 모델은 OSWorld에서 58.2%를 기록하며 특화 모델 중 1위를 차지했습니다 (2위인 opencua-72b는 45.0%를 기록했습니다). 중요한 주의 사항은, 72B 모델은 벤치마크 검증용이며 실제 엣지 배포 모델은 4B 변체 (variant)라는 점입니다. 하지만 72B의 결과는 훈련 방법론 (training methodology)과 아키텍처 (architecture)가 GUI 환경을 깊은 수준에서 진정으로 이해하는 모델을 생성한다는 것을 입증하며, 이러한 지식은 증류 (distillation)를 통해 더 작은 변체들로 전이됩니다.

WebRetriever Protocol I에서 Mano-P는 41.7 NavEval을 달성하여 Gemini 2.5 Pro (40.9)와 Claude 4.5 (31.3)를 능가했습니다. 이 부분을 잠시 주목해 보십시오. 엣지 배포를 위해 설계된 오픈 소스 (open-source) 모델이 웹 내비게이션 벤치마크에서 가장 유능한 두 가지 클라우드 호스팅 (cloud-hosted) 모델보다 뛰어난 성능을 보이고 있습니다. 이는 집중적인 최적화 (optimization)를 거친 엣지 규모의 모델이 특정 작업에서 훨씬 더 큰 클라우드 모델과 대등하거나 이를 능가할 수 있음을 보여줍니다.

핵심 통찰은 전문화(specialization)에 있습니다. 범용 프런티어 모델(General-purpose frontier models)은 창의적 글쓰기부터 코드 생성, 시각적 이해에 이르기까지 모든 영역에 역량을 분산시킵니다. 반면, 목적에 맞게 구축된 GUI 에이전트(GUI Agent) 모델은 스크린샷 이해, UI 요소 식별, 행동 계획(action planning), 오류 탐지와 같이 자신에게 필요한 특정 기능에 파라미터(parameters)를 집중할 수 있습니다. 이러한 집중 덕분에 4B 모델은 체급을 훨씬 뛰어넘는 성능을 발휘할 수 있습니다.

현재 상태: 전문화된 엣지(edge) 모델은 이미 GUI 자동화, 웹 네비게이션 및 이와 유사한 수직적(vertical) 작업에 실용적으로 사용되고 있습니다. 범용 역량은 여전히 프런티어 클라우드 모델에 뒤처져 있지만, 타겟팅된 유스케이스(use cases)의 경우 그 격차가 좁혀졌습니다.

레이어 4: 에이전트 오케스트레이션 및 도구 사용 (Agent Orchestration and Tool Use)

지시 사항을 이해하고 인터페이스를 조작할 수 있는 모델은 필수적이지만 그것만으로는 충분하지 않습니다. 요구 사항 수집부터 결과물 출력에 이르기까지 GTC 데모와 같은 엔드 투 엔드(end-to-end) 워크플로우를 완료하려면 작업 분해(task decomposition), 도구 호출(tool invocation), 오류 복구(error recovery) 및 상태 관리(state management)를 위한 오케스트레이션 레이어(orchestration layer)가 필요합니다.

이는 아마도 제대로 구현하기 가장 어려운 레이어일 것입니다. 모델은 행동을 환각(hallucinate)하거나, UI 요소를 잘못 식별하거나, 루프(loops)에 빠질 수 있습니다. 견고한 오케스트레이션 레이어는 이러한 모든 실패 모드(failure modes)를 유연하게 처리해야 합니다. 즉, 하위 작업이 실패했음을 감지하고, 알려진 정상 상태로 롤백(rollback)하며, 대안적인 접근 방식을 시도하고, 언제 포기하고 인간의 입력을 요청해야 하는지를 알아야 합니다.

이 레이어는 2026년에 상당히 성숙했습니다. 오픈 소스 생태계는 단순한 ReAct 루프부터 롤백 기능을 갖춘 정교한 다단계 플래너(multi-step planners)에 이르기까지 점점 더 다양한 에이전트 프레임워크(Agent frameworks)를 제공하고 있습니다. MCP (Model Context Protocol) 및 이와 유사한 도구 호출(tool-calling) 표준 또한 모델이 외부 도구와 상호 작용할 수 있도록 일관된 인터페이스를 제공함으로써 기여해 왔습니다.

Mano-P 생태계의 일부인 Mano-AFK는 에지 네이티브 (edge-native) 에이전트 오케스트레이션 (Agent orchestration)의 구체적인 사례 중 하나입니다. 이 시스템은 자연어 요구 사항을 입력받아 제품 요구 사양서 (PRD)를 자동 생성하고, 아키텍처를 설계하며, 코드를 작성하고, 로컬에 배포한 뒤, 엔드 투 엔드 (E2E) 테스트를 실행하고, 실패를 자동 수정하여 최종 결과를 전달합니다. 전체 파이프라인은 Mano-P를 로컬 비전 모델 (local vision model)로 사용하여 브라우저 기반의 GUI 자동화 테스트를 구동합니다. 모든 단계는 온디바이스 (on-device)에서 실행됩니다. 이 워크플로우는 NVIDIA 대신 Apple 하드웨어에서 실행된다는 점을 제외하면, Huang이 GTC에서 시연했던 내용과 매우 유사합니다.

현재 상태: 오케스트레이션은 실험적 단계에서 엔지니어링 등급 (engineering-grade)으로 전환되고 있으나, 신뢰성 및 오류 복구 (error recovery)는 여전히 개선이 필요한 영역으로 남아 있습니다.

실제 수치: 실제로 얼마나 빠르게 작동하는가?

아키텍처에 대한 논의도 유용하지만, 실제 사용자 경험은 어떠할까요? 실제 측정값을 살펴보겠습니다.

64GB RAM을 탑재한 M5 Pro Mac에서 Mano-P 4B 모델을 측정한 실제 결과입니다:

• W8A16 양자화 (quantization): 프리필 (prefill) 2.839초, 디코드 (decode) 80.1 tok/s
• W8A8 양자화 (Cider): 프리필 (prefill) 2.519초, 디코드 (decode) 79.5 tok/s
• 프리필 가속 (Prefill acceleration): 약 12.7%

실무에서 80 tok/s의 디코드 속도는 무엇을 의미할까요? GUI 에이전트 (GUI Agent) 워크플로우의 경우, 각 단계는 스크린샷을 캡처하고, 이를 비전 인코더 (vision encoder)를 통해 처리하며, 인터페이스 레이아웃과 상태를 이해한 뒤, 동작 명령을 출력하는 과정을 포함합니다. 초당 80 토큰의 속도라면

~2.5초의 프리필 (prefill) 시간은 입력값(스크린샷 포함)을 처리하는 데 필요한 시간입니다. 몇 초마다 동작을 수행하는 대화형 에이전트 (Agent)에게 이 정도 속도는 유연한 워크플로우를 유지하기에 충분히 빠릅니다. Cider의 활성화 양자화 (activation quantization)를 통한 12.7%의 프리필 가속은 이 루프를 더욱 단축시킵니다.

그리고 이것은 완전히 로컬 실행 (local execution)입니다. 모든 스크린샷과 작업 데이터는 기기 내에 머뭅니다. 네트워크 지연 (network latency)이 없습니다. 민감한 데이터를 제3자 서버로 업로드하는 것에 대한 개인정보 보호 우려도 없습니다. API 호출 제한 (rate limits)도 없으며, 토큰당 과금 (per-token billing)도 발생하지 않습니다. 데이터가 사내 구역을 벗어날 수 없는 기업용 배포 환경이나, 사용자가 단순히 자신의 화면 콘텐츠가 클라우드로 전송되는 것을 원치 않는 개인용 사례의 경우, 이는 클라우드 기반 솔루션이 근본적으로 따라올 수 없는 이점입니다.