AgentSysBench: LLM 서빙 시스템을 위한 에이전틱 워크로드 특성 분석

요약

AgentSysBench(arXiv:2608.15127, 2026년 8월)는 HKUST·알리바바·바이트댄스 공동 연구팀이 발표한 벤치마크로, LLM 추론과 에이전틱(agentic) 워크로드가 서빙 시스템 관점에서 얼마나 다른지 정량적으로 규명한다. 코드 작성·웹 탐색·OS 조작 등 10가지 실제 에이전트 애플리케이션을 측정한 결과, 기존 LLM 서빙 연구가 전제해 온 패턴—짧은 컨텍스트, 단발성 요청, GPU 병목—이 에이전틱 환경에서는 성립하지 않음을 보였다.

배경: LLM 서빙이 가정해 온 세계

vLLM, TensorRT-LLM 같은 현세대 LLM 서빙 시스템은 단일 요청-응답 패턴을 최적화 기준으로 설계됐다. 사용자가 프롬프트를 보내면 모델이 응답을 생성하고 세션이 끝난다. PagedAttention, continuous batching, prefix caching 같은 핵심 기법은 모두 이 전제 위에 서 있다.

에이전트 시스템은 구조가 다르다. 하나의 작업(task)이 수십 번의 LLM 호출, 툴 실행, 환경 피드백, 재계획으로 이어진다. Claude Code나 OpenHands 같은 코딩 에이전트는 파일 읽기·셸 실행·테스트 결과를 매 스텝마다 컨텍스트에 축적한다. 이 패턴이 서빙 시스템에 어떤 함의를 갖는지를 데이터로 규명한 연구가 AgentSysBench다.

연구 설계: 합성 벤치마크와 실측 데이터

AgentSysBench는 두 축으로 구성된다.

합성 벤치마크: 코드 생성·디버깅, 웹 탐색, OS 조작, 파일 관리, 데이터 분석 등 10가지 에이전트 태스크를 대표하는 애플리케이션 슈트. 각 앱은 실제 사용 패턴을 모사하도록 설계됐다.

TraceLab 실측 데이터: Claude Code·Codex 실사용 세션 약 4,300개에서 추출한 350만 회 LLM 스텝, 430만 회 툴 호출 로그. 실제 사용자 세션의 토큰 분포와 툴 호출 패턴을 그대로 반영한다.

TraceLab 주요 수치:

prefix 토큰 중앙값이 11만 9천이라는 수치는 기존 LLM 서빙 연구가 주로 다루는 수백~수천 토큰 범위와 질적으로 다른 스케일이다.

6가지 에이전틱 워크로드 특성

AgentSysBench가 식별한 핵심 특성 6가지를 구체적 수치와 함께 정리한다.

특성 1: 비-LLM 구성 요소가 지연을 지배한다

10개 애플리케이션 중 5개에서 전체 작업 완료 시간의 50% 이상이 LLM 추론이 아닌 툴 실행·환경 피드백에 소비됐다. 코드 실행 결과를 기다리거나 웹 페이지가 로드되는 동안 GPU는 유휴 상태다. LLM 추론 지연만 줄이면 에이전트 성능이 개선된다는 직관이 절반의 경우에는 틀렸다.

특성 2: 샌드박스 메모리 요구량이 크다

코드 실행·OS 조작 에이전트에서 샌드박스 피크 메모리가 최대 28 GB에 달했다. 하나의 에이전트 세션이 GPU 메모리에 근접하는 CPU/RAM 자원을 별도로 요구한다는 의미다. GPU 서버와 CPU 서버 간 자원 할당 비율이 에이전틱 환경에서는 완전히 재검토되어야 한다.

특성 3: GPU·메모리·CPU 친화성이 애플리케이션마다 다르다

10가지 앱을 측정하면 GPU-집중형, 메모리-집중형, CPU-집중형이 고르게 분포한다. 단일 자원 유형 최적화로는 이 이질성을 수용하기 어렵다. 서빙 클러스터가 애플리케이션 특성에 따라 동적으로 자원 구성을 조정할 수 있어야 한다.

특성 4: 세션이 길고 지속적인 컨텍스트 체인을 형성한다

하나의 에이전트 세션은 수십~수백 회의 LLM 호출로 이어진다. 각 호출이 이전 호출의 결과를 컨텍스트에 쌓기 때문에 prefix 길이가 세션 내내 단조 증가한다. TraceLab 데이터의 중앙값 11만 9천 토큰은 이 누적 효과의 결과다. KV 캐시를 세션 단위로 유지·확장하는 메커니즘이 없으면 매 스텝마다 전체 prefix prefill을 반복해야 한다.

특성 5: 세션 간 분산이 극도로 크다

짧게 끝나는 세션과 수백 스텝을 소모하는 세션이 동일 클러스터에 혼재한다. 이 높은 분산은 배치 스케줄링을 어렵게 한다. 균일한 요청 패턴을 전제한 continuous batching 효율이 에이전틱 환경에서는 크게 떨어진다.

특성 6: 툴 호출 패턴이 버스트 형태다

툴을 실행하는 동안 LLM 요청이 멈추고, 결과가 오면 한꺼번에 많은 토큰이 컨텍스트에 추가되며 다음 추론이 시작된다. 이 온-오프 패턴이 반복되면서 GPU 사용률 곡선이 들쭉날쭉해진다. 균일한 부하를 전제한 서빙 시스템이 예측하기 어려운 스파이크를 경험한다.

기존 서빙 시스템에 대한 함의

AgentSysBench의 실험 결과는 현재 LLM 서빙 인프라의 세 가지 설계 가정에 직접 도전한다.

KV 캐시 수명 관리: vLLM의 prefix caching은 동일 prefix를 재사용하는 패턴을 가정한다. 에이전트 세션에서는 prefix가 매 스텝마다 고유하게 증가하기 때문에 캐시 히트율이 급격히 떨어진다. 세션 단위 장기 캐시 유지 전략이 필요하다.

배치 스케줄링: continuous batching은 비슷한 길이의 요청들이 섞여 들어올 때 효율적이다. 에이전틱 워크로드의 극단적 세션 길이 분산은 긴 세션이 GPU를 독점하거나 짧은 세션이 starvation을 겪는 현상을 유발한다.

GPU 중심 자원 할당: 28 GB 샌드박스 피크는 A100(80 GB HBM) 한 장에 근접하는 메모리를 CPU/DRAM 쪽에 요구한다. GPU:CPU 비율을 고정한 서버 설계로는 에이전틱 워크로드를 수용하기 어렵다.

TraceLab이 보여주는 실사용 패턴

AgentSysBench가 합성 벤치마크에 그치지 않는 이유는 TraceLab에 있다. 4,300개의 실사용 Claude Code·Codex 세션은 "실제 개발자가 실제로 어떻게 코딩 에이전트를 쓰는가"를 담는다.

중앙값 prefix 길이 119,000 토큰은 상위 티어 LLM의 컨텍스트 윈도우(128K~200K)를 한 세션이 대부분 소모한다는 뜻이다. 스텝 당 875 토큰 증가는 세션이 100 스텝 진행하면 prefix가 87,500 토큰 불어난다는 의미다. 반면 스텝 당 출력은 214 토큰으로 짧다—에이전트가 길게 추론(chain-of-thought)하는 것이 아니라, 짧게 행동(툴 호출)하고 긴 결과를 관찰하는 패턴이다.

서빙 시스템 연구에 대한 제언

논문은 다음 연구 방향을 제시한다.

• 세션-aware KV 캐시: 단일 세션의 KV 상태를 여러 GPU에 걸쳐 유지하는 분산 캐시 아키텍처
• 혼합 자원 스케줄러: GPU·CPU·메모리 할당을 애플리케이션 특성에 따라 동적으로 조정하는 스케줄러
• 비-LLM 구성 요소 최적화: 툴 실행 환경(컨테이너, 샌드박스)의 콜드 스타트 지연 및 메모리 사용 최적화
• 예측적 prefill: 다음 스텝에서 어떤 컨텍스트가 필요할지 미리 예측해 KV 캐시를 준비하는 기법

요점 정리

• AgentSysBench는 에이전틱 워크로드와 단발성 LLM 추론이 서빙 관점에서 질적으로 다름을 데이터로 증명한 대규모 연구다.
• 10개 앱 중 5개에서 비-LLM 구성 요소가 지연의 절반 이상을 차지하며, 샌드박스 메모리 피크는 28 GB에 달한다.
• TraceLab의 4,300개 실사용 세션은 중앙값 prefix 119K 토큰, 스텝 당 875 토큰 증가라는 구체적 수치를 제공한다.
• KV 캐시 수명, 배치 스케줄링, 자원 할당 비율—세 가지 기존 설계 가정이 모두 재검토 대상이다.
• 에이전트 인프라를 구축하거나 LLM 서빙 시스템을 평가하는 팀이라면 AgentSysBench 벤치마크를 기준선으로 삼을 수 있다.

References

• AgentSysBench 논문 (arXiv:2608.15127): https://arxiv.org/abs/2608.15127
• TraceLab 데이터셋 (arXiv:2606.30560): https://arxiv.org/abs/2606.30560
• vLLM 프로젝트: https://github.com/vllm-project/vllm
• PagedAttention 논문 (SOSP 2023): https://arxiv.org/abs/2309.06180
• OpenHands 에이전트 프레임워크: https://github.com/All-Hands-AI/OpenHands