AI 에이전트 시대의 인프라 (1편): 에이전트는 프로그램이다
안녕하세요. AIEEV 개발팀에서 AI 인프라 연구개발을 담당하고 있는 조용래입니다. 분산 시스템 성능 확장성 및 신뢰성을 주제로 컴퓨터 공학과 박사 학위를 받았으며, 지금은 Air Cloud 위에서 LLM 서빙의 효율과 신뢰성, 그리고 AI 에이전트 기술 연구개발에 관심을 두고 일하고 있습니다.
AI 에이전트처럼 한 번의 요청에 모델을 수십, 수백 번씩 호출하는 서비스가 늘어날수록, 추론 비용 청구서는 예상보다 훨씬 빠르게 불어납니다. 회사에서 에이전트 기능을 붙여 보신 분이라면 한 번쯤 겪어보셨을 겁니다. AIEEV가 줄곧 붙들고 있는 문제의식도 바로 여기서 출발합니다. 이 글은 그 문제를 연구자의 시선으로 끝까지 파고든 기록입니다. 2부로 나눠, 1편에서는 AI 에이전트가 서빙 인프라에 던지는 도전이 무엇인지 세계 최고 시스템 학회들의 최신 연구로 짚어보고, 2편에서는 그 흐름이 왜 "아주 많은 소비자용 GPU 위에서 돌아가는 작은 모델들"이라는 그림으로 수렴하는지 풀어보겠습니다.
챗봇 시대에는 사용자 요청 하나가 모델 호출 하나였습니다. 에이전트 시대에는 요청 하나가 계획, 도구 호출, 결과 해석, 재계획으로 이어지는 하나의 프로그램이 되고, 그 안에서 모델이 수십에서 수백 번 호출됩니다. 실제 측정을 보면 탐색형 에이전트는 프로그램 하나당 평균 159.7회의 LLM 호출을 만들어 냅니다. 일반 챗봇 대화(평균 6.66회)의 약 24배입니다 [1]. 여기에 동시에 돌아가는 에이전트 수가 수십만, 수백만으로 늘어난다고 생각해보세요. 추론 인프라가 감당해야 할 호출량은 지금과는 차원이 다른 규모가 됩니다. agentic AI 시장이 2024년 약 52억 달러에서 2034년 약 2,000억 달러로 성장하리라는 전망이 나오는 배경이기도 합니다 [2].
이 변화의 성격은 컴퓨터의 역사에 이미 등장한 적이 있습니다. CPU가 개별 명령어를 하나씩 실행하던 시대에서, 명령어 묶음과 그 상태를 프로세스라는 단위로 묶어 관리하는 운영체제의 시대로 넘어왔듯이, LLM 서빙도 지금 단일 모델 호출에서 AI 에이전트 프로그램으로 관리 단위를 옮기는 중입니다(그림 1). 그렇다면 질문은 하나로 모입니다. 그 폭증하는 호출을 누가, 어디서, 어떤 모델로, 얼마에 처리할 것인가.
1. 에이전트는 "호출"이 아니라 "프로그램"입니다
에이전트의 내부를 뜯어 보면 구조는 명확합니다. 요청이 들어오면 ① 서브태스크로 분해하고 계획을 세운 뒤, ② 서브태스크를 골라 웹 검색, 코드 실행, 파일시스템, 외부 API 같은 도구를 호출해 실행하고, ③ 그 결과를 다시 모델이 해석해서, ④ 상태를 갱신하고 다음 서브태스크로 넘어갑니다. 남은 서브태스크가 없을 때까지 이 루프가 반복됩니다.
서빙 시스템의 눈으로 보면, 이 구조는 챗봇 서빙이 깔고 있던 가정을 거의 전부 무너뜨립니다. 최근 논문들이 공통적으로 지적하는 특성은 여섯 가지입니다.
의존성 있는 호출 묶음: 요청이 프로그램 단위로 들어옵니다. 앞 호출의 결과가 다음 호출의 입력이 됩니다.
잦은 tool 호출: tool의 응답을 기다리는 동안 GPU는 놀고, 그 사이 KV 캐시(모델이 프롬프트를 읽으며 만들어 둔 중간 계산 결과)는 자리만 차지합니다.
GPU 밖 자원까지 점유: 컨테이너, 파일, 포트, 브라우저 세션이 프로그램과 함께 살아 움직입니다.
상태 누적: KV 캐시와 장기 기억이 턴마다 쌓여 GB에서 TB 단위까지 커집니다.
긴 실행 시간: 몇 초짜리 응답이 아니라 몇 시간, 며칠, 몇 주짜리 작업이 등장하고, 오래 돌수록 장애에 더 많이 노출됩니다.
단가 문제: 이 모든 호출을 최상위 초거대 모델로 처리하면 비용이 감당되지 않습니다.
시스템 연구는 언제나 워크로드 특성화에서 시작합니다. 워크로드가 바뀌면 스케줄러, 메모리 관리자, 장애 모델이 전부 다시 설계됩니다. 지금 에이전트 워크로드를 두고 벌어지는 일이 정확히 그것입니다.
2. 세계 탑 시스템 학회의 최전선
본론에 들어가기 전에 한 가지를 짚고 싶습니다. AI 클라우드 인프라를 만드는 회사가 왜 시스템 분야 탑 학회의 연구 성과를 계속 들여다봐야 하는가 하는 점입니다.
답은 지금 업계 표준이 된 소프트웨어의 계보에 있습니다. 오늘날 사실상 표준 추론 엔진이 된 vLLM은, UC Berkeley 연구진이 시스템 분야 최고 학회인 SOSP 2023에서 발표한 PagedAttention 논문에서 출발한 프로젝트입니다 [3]. 운영체제의 가상 메모리와 페이징 개념을 KV 캐시 관리에 가져온 이 논문 하나가, 몇 년 만에 전 세계 GPU 위에서 돌아가는 기반 소프트웨어가 되었습니다. 뒤에서 소개할 LMCache와 CacheBlend도 정확히 같은 경로를 밟는 중입니다. 이 분야에서 탑 학회는 완성된 기술의 전시장이 아니라, 2~3년 뒤 프로덕션 스택의 설계도가 가장 먼저 공개되는 곳입니다.
그래서 저희는 인프라를 운영하는 회사일수록 기초 기술 연구개발에 발을 담가야 한다고 믿습니다. 남이 만든 엔진을 잘 가져다 쓰는 데 머무르면, 기술의 최전선이 움직일 때마다 뒤에서 따라가는 수밖에 없습니다. 최전선이 어디로 움직이는지 먼저 읽고, 필요한 곳에서는 그 최전선을 직접 넓히는 것. 저희가 학회 프로그램을 정기적으로 리뷰하는 이유입니다.
그 눈으로 보면, OSDI, SOSP, NSDI, EuroSys, MLSys 같은 시스템 분야 최고 학회들의 최근 프로그램에서 "에이전트 서빙"이 이미 하나의 독립된 연구 주제로 자리 잡았다는 것이 뚜렷하게 보입니다. 앞서 정리한 여섯 가지 특성 하나하나에 대응하는 연구가 나오고 있습니다. 대표적인 결과만 추리면 다음과 같습니다.
문제 | 시스템 (발표 지면) | 핵심 아이디어 | 보고된 효과 |
스케줄링 단위 | Autellix (NSDI '26) [1] | 호출이 아니라 프로그램 단위로 스케줄링, 프로그램이 뒤섞이며 KV 캐시가 밀려나는 것을 방지 | 기존 서빙 엔진 대비 처리량 최대 15배 |
tool 대기 | Continuum [4] | tool 응답을 기다리는 동안 KV를 TTL과 함께 고정(pin)해 재계산 제거 | 평균 작업 완료 시간 8배 이상 개선 |
GPU 밖 자원 | ThunderAgent (ICML '26) [5] | 프로그램이 컨테이너·포트·파일을 OS 프로세스처럼 소유, 종료 시 한꺼번에 회수 | 처리량 1.5~3.6배, 디스크 사용 4.2배 절감 |
호출 단가 | AIMS (EuroSys '26) [6] | 요청을 서브태스크로 분해한 뒤 SLM으로 충분한지 분류기로 판단해 라우팅 | 정확도 유지하며 서브태스크 45.67%를 로컬 SLM에 오프로드 |
디바이스 활용 | TailorLLM (EuroSys '26) [7] | 고빈도 작업은 사용자 디바이스의 SLM에 LoRA로 특화시켜 로컬에서 종결 | 전송 오버헤드를 줄이며 로컬 처리 확대 |
신뢰성 | LogAct (Meta) [8] | 에이전트를 권한이 분리된 여러 프로세스로 분해하고 공유 로그에 기록 | 장애 후 재작업 없는 복구, 감사 추적 확보 |
각 수치는 해당 논문이 자체 실험 환경에서 보고한 값입니다. 개별 숫자보다 중요한 것은 공통된 방향, 즉 최적화 단위의 이동입니다. vLLM이나 SGLang 같은 기존 서빙 엔진은 호출 하나를 최적화 단위로 봅니다. 그런데 에이전트에서는 호출 사이에 의존성이 있고 상태가 이어지기 때문에, 호출 단위로 스케줄링하면 서로 다른 프로그램이 GPU 위에서 뒤섞이며 KV 캐시(직전 계산 결과를 저장해 두고 재사용하는 캐시)가 밀려나고 같은 계산을 반복하게 됩니다. Autellix가 스케줄링 단위를 프로그램으로 바꾸는 것만으로 처리량을 최대 15배 끌어올린 이유가 여기에 있습니다.
분산 시스템을 연구해 온 입장에서는 익숙한 장면이기도 합니다. 글 첫머리의 그림 1에서 예고한 진화, 그러니까 에이전트가 서빙 시스템의 프로세스가 되어 가는 변화는 먼 전망이 아니라, 위의 논문들이 보여주듯 이미 진행 중인 현실입니다. 이 밖에도 에이전트의 기억을 무엇으로 남기고(의미) 어디에 둘지(물리)를 다루는 메모리 계층 연구(Mem0 [9], LMCache [10], Mooncake 등)도 활발합니다. 이 축은 바로 다음 장에서 다시 만나게 됩니다.
3. 사례로 보는 최전선: CacheBlend, 검색된 지식을 계산된 상태째 재사용하기
이 분야가 얼마나 뜨거운지 보여주는 사례 하나를 조금 깊게 소개하겠습니다. 시스템 분야 최고 학회 중 하나인 EuroSys의 2025년 Best Paper Award를 받은 CacheBlend입니다(미국 시카고대학교 중심 연구진) [11].
배경부터 짚겠습니다. LLM이 프롬프트를 읽는 단계(prefill)에서 모델은 토큰마다 Key와 Value라는 중간 계산 결과를 만들어 둡니다. 이것이 KV 캐시입니다. 같은 텍스트가 다시 들어오면 이 계산을 재사용해서 첫 토큰이 나오기까지의 시간(TTFT)을 크게 줄일 수 있습니다. 다만 기존 방식(prefix caching)에는 조건이 있습니다. 프롬프트의 맨 앞에서부터 완전히 같은 구간만 재사용할 수 있다는 것입니다.
문제는 에이전트와 RAG의 프롬프트가 그렇게 생기지 않았다는 데 있습니다. 에이전트는 기억과 지식을 Vector DB에 저장해 두고, 매 호출마다 관련된 지식 청크 여러 개를 검색해 프롬프트에 끼워 넣습니다. 같은 청크 A, B, C라도 요청마다 조합과 순서가 달라지니, 프리픽스가 일치하는 것은 기껏해야 첫 번째 청크뿐입니다. 애써 만들어 둔 KV 캐시의 대부분이 버려집니다.
그렇다고 각 청크의 KV 캐시를 그냥 이어 붙이면 품질이 무너집니다. 각 청크의 KV는 그 청크를 단독으로 읽었을 때의 계산 결과라서, 앞에 놓인 다른 텍스트를 참고하는 계산(cross-attention)이 통째로 빠져 있기 때문입니다.
CacheBlend의 답은 절충입니다. 청크들의 KV 캐시를 프리픽스 여부와 무관하게 일단 재사용하되, cross-attention의 영향이 큰 소수의 토큰만 골라 선택적으로 다시 계산합니다. 그리고 이 재계산을, KV 캐시를 저장장치에서 GPU로 불러오는 시간과 겹치도록 파이프라인으로 설계했습니다. 재계산 비용이 로딩 시간 뒤에 숨기 때문에, KV 캐시를 크고 느린(대신 싼) 저장장치에 두고도 지연이 늘지 않습니다. 그 결과 전체를 다시 계산하는 방식(full prefill) 대비 TTFT는 2.2~3.3배 빨라지고 처리량은 2.8~5배 늘어나면서도 생성 품질은 유지됩니다(논문 초록 기준) [11].
이 논문을 굳이 길게 소개한 이유는 세 가지입니다.
1. 학계의 무게중심
시스템 분야 최고 학회가 최우수 논문상을 에이전트와 RAG를 위한 서빙 연구에 주었다는 사실 자체가, 이 문제가 지금 시스템 연구의 중심에 있다는 가장 명확한 신호입니다.
2. 산업으로 이식되는 속도
CacheBlend는 같은 연구진이 주도하는 오픈소스 KV 캐시 계층인 LMCache [10]에 non-prefix KV reuse 기능으로 들어갔고 [12], LMCache는 vLLM과 결합해 멀티턴 질의응답과 문서 분석 워크로드에서 최대 15배의 처리량 향상을 보고하고 있습니다 [13]. 그리고 바로 지난 7월 22일 공개된 LMCache v0.5.2 릴리스에서는 CacheBlend가 vLLM의 하이브리드 KV 캐시 관리자(HMA) 아래에서도 동작하도록 확장되었고, sliding window attention 모델을 위한 dual RoPE 지원과, 여러 노드에 흩어진 캐시에서 토큰을 찾아내는 글로벌 P2P 토큰 매칭까지 더해졌습니다 [14]. 최고 학회의 수상 논문이 1년여 만에 사실상 표준 서빙 스택의 기본 기능이 되어 가는 속도입니다.
3. 소비자용 PC 환경과의 궁합
CacheBlend가 데이터센터 서빙을 겨냥해 나온 것은 사실이지만, 핵심 설계를 다시 보면 재계산을 소수의 토큰으로 줄이고 그 재계산 시간을 느린 저장장치에서 KV를 불러오는 시간 뒤에 숨기는 것, 즉 GPU 메모리 바깥의 DRAM과 SSD를 KV 캐시의 정식 저장 계층으로 승격시키는 것입니다 [11]. 그런데 이 설계가 가장 절실한 곳이 바로 소비자용 PC입니다. 소비자 GPU의 VRAM은 8~24GB 수준이라 GPU만으로는 에이전트가 쌓는 지식과 KV를 다 담기 어렵지만, 같은 PC 안에는 수십 GB의 DRAM과 TB급 SSD가 대체로 놀고 있습니다. 에이전트가 자주 쓰는 지식 청크의 KV를 DRAM과 SSD에 쌓아 두고, 필요할 때 불러와 소수 토큰만 다시 계산하면, 작은 VRAM으로도 긴 컨텍스트의 에이전트 호출을 감당할 수 있게 됩니다. 여기에 유휴 CPU 연산까지 추론에 끌어 쓰는 연구 흐름(PowerInfer 등 [15])을 겹치면 방향은 더 분명해집니다. 소비자 GPU 클라우드란 GPU 한 장이 아니라 PC 한 대 전체, 그러니까 GPU와 DRAM, SSD, CPU를 합친 하나의 서빙 노드를 뜻하고, PC 안의 유휴 자원을 끌어 쓸수록 그 노드는 강해집니다. 이 관점에서 CacheBlend 계열 기법은 데이터센터보다 소비자 환경에서 오히려 더 절실한 기술이 됩니다. 물론 소비자 하드웨어는 저장장치 대역폭과 GPU 연산 속도의 비율이 데이터센터와 다르기 때문에, 로딩과 재계산의 균형점이 실제로 어디에 오는지는 실측으로 검증해야 할 지점이고, 저희가 Air Cloud 환경에서 들여다보고 있는 주제이기도 합니다.
연구자의 시선에서 관전 포인트를 하나 덧붙이면, CacheBlend가 여는 방향은 지식이 텍스트가 아니라 계산이 끝난 상태(KV)로 유통되는 세계입니다. 에이전트의 기억 계층(Vector DB)과 서빙 엔진의 캐시 계층이 하나의 메모리 계층 구조로 합쳐지기 시작한 것입니다. 그리고 캐시가 여러 노드에 흩어져 있는 분산 GPU 클라우드에서는, 어떤 노드에 어떤 KV가 있는지 찾고 옮기고 섞는 문제가 한층 더 흥미로운 연구 주제가 됩니다. 글로벌 P2P 토큰 매칭 같은 기능이 등장한 것은 커뮤니티가 이미 그 방향을 보고 있다는 뜻이기도 합니다. 저희가 Air Cloud를 만들며 매일 마주하는 질문도 정확히 여기에 있습니다. 수만 대의 소비자용 GPU가 노드로 흩어진 환경에서, 어느 노드에 어떤 KV가 있는지를 찾고 필요한 곳으로 옮기는 일입니다.
➡️ 다음 편에서 계속됩니다.
에이전트는 더 이상 호출이 아니라 프로그램이고, 세계 최고 시스템 학회들은 이미 이 변화에 맞춰 서빙 시스템을 다시 설계하고 있습니다. 다음 편에서는 이 문제의 실질적인 답, 즉 SLM과 소비자용 GPU가 왜 만나는지, 그리고 이 인프라가 갖춰야 할 신뢰성 조건까지 다룹니다.
참고 자료
[1] Autellix: An Efficient Serving Engine for LLM Agents as General Programs (NSDI 2026): https://arxiv.org/abs/2502.13965
[2] Small Language Models are the Future of Agentic AI (NVIDIA Research): https://arxiv.org/abs/2506.02153
[3] Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023, vLLM의 출발점): https://arxiv.org/abs/2309.06180
[4] Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live: https://arxiv.org/abs/2511.02230
[5] ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System (ICML 2026 Spotlight): https://arxiv.org/abs/2602.13692
[6] AIMS: Cost-Efficient LLM-Based Agent Deployment in Hybrid Cloud-Edge Environments (EuroSys 2026, arXiv 프리프린트 제목 HERA): https://arxiv.org/abs/2504.00434
[7] 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
[8] LogAct: Enabling Agentic Reliability via Shared Logs (Meta): https://arxiv.org/abs/2604.07988
[9] Mem0: https://arxiv.org/abs/2504.19413
[10] LMCache (오픈소스 KV 캐시 계층): https://github.com/LMCache/LMCache
[11] CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion (EuroSys 2025, Best Paper Award): https://arxiv.org/abs/2405.16444 · https://dl.acm.org/doi/10.1145/3689031.3696098
[12] LMCache 블로그의 CacheBlend 소개: https://blog.lmcache.ai/en/2025/03/31/cacheblend-best-paper-acm-eurosys25-enabling-100-kv-cache-hit-rate-in-rag/
[13] LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference (MLSys 2026 초청 강연): https://mlsys.org/virtual/2026/invited-talk/3646
[14] LMCache v0.5.2 릴리스 노트 (2026.07): https://github.com/LMCache/LMCache/releases/tag/v0.5.2
[15] PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU (SOSP 2024): https://arxiv.org/abs/2312.12456
