AI 에이전트 시대의 인프라 (2편): 소비자용 GPU 클라우드가 답이 되는 이유
- 2일 전
- 5분 분량
1편에서는 AI 에이전트가 왜 기존 서빙 시스템의 가정을 무너뜨리는 '프로그램형 워크로드'인지, 그리고 세계 최고 시스템 학회들이 이 문제를 어떻게 다루고 있는지 살펴봤습니다. CacheBlend 사례에서 확인했듯, 그 답의 상당 부분은 GPU 메모리 바깥의 자원, 즉 소비자용 PC가 가진 DRAM과 SSD를 어떻게 활용하느냐에 달려 있었습니다. 이제 비용 이야기로 돌아와, 그 흐름이 왜 "소비자용 GPU 클라우드"라는 그림으로 수렴하는지 이어가 보겠습니다.
4. 그 많은 호출, 전부 초거대 모델이어야 할까: SLM이라는 답
NVIDIA Research는 지난해 "Small Language Models are the Future of Agentic AI"라는 도발적인 제목의 논문을 내놓았습니다 [1]. 요지는 이렇습니다. 에이전트 루프에서 실제로 발생하는 일의 상당수는 검색 결과 요약, tool 호출용 JSON 생성, 문서에서 정형 필드 추출, 메일 초안 작성 같은 좁고 반복적인 작업이고, 이런 작업에는 10B 미만의 SLM(Small Language Model)으로 충분하다는 것입니다. 저자들은 8B급 SLM의 서빙 비용이 405B급 LLM 대비 10~30배 저렴하다고 추정합니다.
물론 이것은 아직 검증이 진행 중인 전망에 가깝고, 어려운 계획과 추론에는 여전히 큰 모델이 필요합니다. 그러나 방향 자체는 이미 시스템 연구들이 실증하고 있습니다. 1편에서 본 것처럼 AIMS [2]는 요청을 서브태스크로 분해한 뒤 SLM으로 충분한 작업만 골라 라우팅하는 것으로, 클라우드 전용 방식과 비슷한 정확도를 유지하면서 서브태스크의 절반가량(45.67%)을 로컬 SLM으로 넘겼고, TailorLLM [3]은 고빈도 작업을 로컬 SLM에 특화시켜 클라우드로 오가는 전송 부담을 줄였습니다. 어려운 계획은 큰 모델이 브레인으로 맡고, 나머지 다수의 호출은 작은 모델들이 처리하는 하이브리드 구조가 표준 설계로 굳어지고 있는 것입니다. 그리고 이 대목에서 하드웨어 쪽 사실 하나가 중요해집니다. 2026년의 SLM들은 소비자용 GPU에 들어갑니다.
모델 | 파라미터 | 가중치 크기 | 공개 |
Qwen3.5 Small (Alibaba) | 0.8B~9B | 약 1.6~18GB (BF16) | '26.03 |
Gemma 4 E2B / E4B (Google) | 유효 2.3B / 4.5B | 약 1.5GB / 3GB | '26.04 |
Granite 4.1 8B (IBM) | 8B | 약 16GB (BF16) | '26.04 |
Phi-4-reasoning-vision (Microsoft) | 15B | 약 30GB (BF16) | '26.03 |
Mistral Small 4 (Mistral AI) | 약 24B | 약 48GB (4bit 양자화 시 약 14GB) | '26.03 |
(각 사 공개 자료 기준, 2026년 7월 정리)
RTX급 소비자 GPU의 VRAM은 대체로 8~24GB이고 상위 제품은 그 이상입니다. 표의 모델 대부분이 그대로, 혹은 양자화를 거쳐 그 안에 들어갑니다. 즉 에이전트 호출의 다수를 차지하게 될 SLM 추론은 데이터센터의 최상위 GPU가 아니라, 이미 세상에 셀 수 없이 깔려 있는 사용자급 GPU로 처리할 수 있는 일이 되었습니다. NVIDIA 논문의 논지를 빌리면, 일상적인 트래픽까지 전부 중앙 데이터센터로 보내는 것은 자원의 오배분에 가깝습니다 [1].
여기까지를 겹치면 저희가 보는 전망이 나옵니다. 에이전트 시대가 본격화되면, 수백만 에이전트가 만들어 내는 일상 호출의 대부분은 그 수가 매우 많은 사용자급 GPU들로 구성된 분산 인프라 위의 SLM들이 받아내고, 정말 어려운 추론만 큰 모델로 올라가는 구조가 될 것입니다. 거꾸로 말하면, 이런 인프라가 잘 받쳐 줘야 AI 에이전트 시대를 비용 걱정 없이 본격적으로 맞이할 수 있습니다.
5. 마지막 조각: 신뢰성
다만 이 그림에는 정직하게 짚어야 할 조각이 하나 남습니다. 신뢰성입니다. 에이전트 하나가 단위 시간 동안 문제를 일으킬 확률을 p라고 하면, N개의 에이전트가 T 단위 시간 동안 모두 정상일 확률은 대략 (1 - p)의 N×T 제곱으로 떨어집니다. p가 아무리 작아도 에이전트 수 N이 수백만이 되고 실행 시간 T가 몇 주가 되면 이 값은 사실상 0입니다. 즉 대규모 long-running 에이전트 환경에서 장애는 예외가 아니라 상수입니다. 실제로 2025년 7월에는 코드 동결 중이던 서비스의 운영 데이터베이스를 코딩 에이전트가 삭제한 사고가 공개적으로 보고되기도 했습니다(Replit 사례). 에이전트가 결제, 배포, 계약처럼 실행 권한이 큰 일을 맡을수록 오류 하나의 비용도 커집니다.
그 실행 권한의 최전선이 어디까지 왔는지 보여주는 사례가 결제입니다. 최근 에이전트가 사람 개입 없이 웹 API 사용료를 스스로 지불하게 해 주는 x402라는 결제 프로토콜이 빠르게 퍼지고 있습니다. HTTP의 402 "Payment Required" 상태 코드를 확장한 것으로, 서버가 결제 조건을 제시하면 에이전트가 서명된 결제 증명을 붙여 다시 요청하고, facilitator라고 부르는 중개 인프라가 검증과 블록체인 정산을 대행하는 구조입니다. Coinbase, Cloudflare, AWS, Google 같은 주요 사업자가 이미 지원하고 있고, 누적 1억 5천만 건 이상의 온체인 거래와 4천만 달러 이상의 결제가 이 프로토콜 위에서 오갔습니다 [5]. 에이전트가 정보를 읽고 쓰는 것을 넘어, 이미 돈을 쓰는 주체가 되었다는 뜻입니다.
그런데 지난 7월 공개된 이 생태계의 첫 체계적 보안 분석 결과는 서늘합니다 [5]. EPFL과 저장대학교 연구진이 수행했고, 보안 분야 최고 학회 중 하나인 USENIX Security 2026에서 발표될 예정인 연구입니다. 전체 x402 거래의 99%를 처리하는 주요 facilitator 15곳을 블랙박스 테스트했더니 15곳 전부에서 보안 규칙 위반이 발견됐고, 49건의 위반이 이전까지 알려지지 않았던 취약점 31개로 이어졌습니다. 공격 경로도 구체적입니다. 결제 없이 자원을 얻어 내는 Free Shopping, 정산 과정을 비틀어 중개자가 보유한 자산을 빼내는 Asset Theft, 실패할 정산을 반복시켜 서비스를 마비시키는 Service Denial, 중개자가 대납하는 수수료를 태우게 만드는 Gas Abuse까지 네 가지가 실제 배포 환경에서 확인됐고, 제보를 받은 Coinbase 등 사업자들이 완화 조치를 적용했습니다. 저자들의 온체인 측정에 따르면, x402 정산 시도가 지금까지 태운 가스와 수수료는 누적 20만 달러를 넘습니다 [5]. 이 20만 달러 자체는 정상 거래의 정산 비용까지 포함한 생태계 전체의 지출이지만, 문제는 그중 실패해서 되돌려진(revert) 정산에 들어간 5,800달러입니다. 이 돈은 아무것도 정산하지 못한 채 중개자가 대납한 순수 손실이고, 공격자가 실패할 정산을 반복시키면 이 손실을 얼마든지 키울 수 있다는 것을 보여주는 증거입니다. 여기에 더해, 연구진은 2만 3천여 건의 거래에서 공격자가 중개자에게 계정 생성 비용(ATA rent)을 떠넘기는 패턴을 관찰했습니다. 즉 5,800달러는 피해의 총량이 아니라, 검증만 통과하고 정산은 실패하는 구조가 실제로 돈을 태우고 있다는 존재 증명으로 읽어야 합니다. 에이전트가 돈을 만지는 순간, 검증과 실행 사이의 시간차, 원자성의 부재, 감사 가능성 같은 분산 시스템의 고전적인 문제들이 그대로 보안 취약점이 된다는 것을 보여주는 사례입니다. 이 논문이 제안하는 완화 방향, 그러니까 검증을 정산에 단단히 묶고, 클라이언트가 준 입력을 적대적 입력으로 취급하고, 대납 비용에 기본 상한을 두라는 원칙은, 에이전트 시스템 연구들이 도달하고 있는 결론과 같은 곳을 가리킵니다.
그래서 최신 연구들은 에이전트를 분산 시스템으로 다루기 시작했습니다. Meta의 LogAct [4]는 하나의 에이전트 루프를 권한이 분리된 여러 프로세스(제안, 검증, 결정, 실행)로 분해하고 모든 결정을 공유 로그에 기록해서, 위험한 행동을 실행 전에 걸러 내고, 장애가 나면 로그를 재생해 복구하며, 사후에는 무엇을 왜 했는지 감사할 수 있게 만들었습니다. 하나의 에이전트 안에서 권한을 나누는 이런 접근 외에, 여러 에이전트가 서로의 출력을 교차 검증하고 일부가 틀리거나 악의적이어도(Byzantine) 전체 결정을 지키도록 강건하게 집계하는 다중 에이전트 신뢰성 연구도 활발하게 이어지고 있습니다. 분산 시스템의 오래된 문제들이 새로운 얼굴로 돌아오는 것을 지켜보는 요즘입니다.
소비자 GPU 클라우드에서 신뢰성은 선택이 아니라 전제입니다. 노드는 예고 없이 빠질 수 있고, 하드웨어는 이질적이며, 네트워크는 데이터센터만큼 안정적이지 않습니다. 효율과 신뢰성을 따로 최적화하는 것이 아니라 처음부터 같이 설계해야 하는 환경이고, 바로 그래서 연구자에게는 가장 흥미로운 환경이기도 합니다.
6. Air Cloud: 에이전트 시대를 위해 준비된 인프라
여기까지의 흐름을 겹쳐 보면, AIEEV가 만들고 있는 Air Cloud가 정확히 이 교차점 위에 서 있다는 것이 보입니다. 먼저 비용 구조입니다. 에이전트 시대의 비용은 호출량에 비례합니다. Air Cloud는 분산된 소비자용 GPU 자원을 하나의 클라우드로 연결해 호출 단가의 구조 자체를 바꿉니다. 사내 대시보드 편에서 소개했던, 문서 초안 한 번 생성에 약 1원 수준이라는 Air API의 비용은 이 구조에서 나옵니다.
두번째는 SLM에 맞는 그릇이라는 점입니다. 앞에서 본 것처럼 에이전트 호출의 다수는 SLM의 일이고, SLM은 소비자용 GPU 크기에 맞는 일입니다. Air API는 Qwen 계열을 비롯한 오픈소스 모델을 OpenAI 호환 API로 즉시 제공하고, Air Container는 자신의 모델과 서비스를 클릭 한 번으로 분산 환경에 배포할 수 있게 합니다.
셋째, 하이브리드 구조입니다. Air Agent(베타)는 로컬 우선 처리와 AirCloud 연결을 결합한 구조입니다. 고빈도 작업은 가까운 곳에서 처리하고 무거운 작업만 클라우드로 보내는 이 방향은, AIMS나 TailorLLM 같은 최신 연구가 실증한 바로 그 설계와 같은 곳을 보고 있습니다.
마지막으로 연구와 제품의 결합입니다. 저희는 vLLM과 LMCache를 포함한 최신 서빙 스택을 Air Cloud 환경에서 직접 검증하고 적용하는 R&D를 진행하고 있습니다. 1편과 2편에서 소개한 프로그램 단위 스케줄링, KV 캐시 재사용, 신뢰성 기법들이 소비자 GPU 분산 환경에서는 어떻게 달라져야 하는가. 이것이 저희 연구의 질문이고, 그 답을 논문과 제품 양쪽으로 만들어 가는 것이 목표입니다.
마치며
정리하면 이렇습니다. 에이전트는 모델 호출을 폭발시키고, 세계의 시스템 학계는 이미 그 폭발을 받아내기 위한 연구로 움직였으며, 그 답의 큰 부분은 작은 모델과 아주 많은 소비자용 GPU에 있습니다. 그리고 그 인프라에는 효율만큼이나 신뢰성이 필요합니다.
모델을 만드는 경쟁의 다음은 AI를 운영하는 경쟁입니다. 에이전트 시대가 본격화될수록 승부는 인프라에서 갈립니다. AIEEV는 그 시대를 위해 Air Cloud를 만들고 있습니다. 좋은 에이전트 아이디어가 인프라 비용 때문에 멈추지 않도록, 그리고 수백만 개의 에이전트가 믿고 돌아갈 수 있는 바닥이 되도록. 앞으로도 산업 현장에 있으면서 글로벌 최첨단 기술 연구 성과들을 보고 배우는 것들을 계속 공유하겠습니다.
.
.
.
참고 자료
[1] Small Language Models are the Future of Agentic AI (NVIDIA Research): https://arxiv.org/abs/2506.02153
[2] AIMS: Cost-Efficient LLM-Based Agent Deployment in Hybrid Cloud-Edge Environments (EuroSys 2026, arXiv 프리프린트 제목 HERA): https://arxiv.org/abs/2504.00434
[3] TailorLLM: Collaborative End-Cloud Inference of Large and Small Language Models Based on Low-Rank Adaptation (EuroSys 2026): https://dl.acm.org/doi/10.1145/3767295.3769346
[4] LogAct: Enabling Agentic Reliability via Shared Logs (Meta): https://arxiv.org/abs/2604.07988
[5] When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments (USENIX Security 2026 발표 예정, EPFL·Zhejiang University): https://arxiv.org/abs/2607.19545
