빠른데 느려요 — 이제 '요청'이 아니라 '세션'을 봐야 해요 - LLM Scheduling for Agent Serving
안녕하세요, 아크릴 테크블로그의 음유시인 갈리엄(Galliam)입니다. 여름방학이 한창인 요즘, 많은 학생들이 무더위보다 뜨거운 학구열로 공부하고 있을 것 같은데요(이따금씩 누워서 릴스 시청으로 머리도 식히길ㅎ), 어린 갈리엄의 초등학생 시절이 떠오릅니다. 갈리엄은 하루 10문제씩 수학 문제를 풀면 TV시청 30분권을 받았는데요, 룰루랄라 풀면서 무얼 볼 지 고민하던 어느 날, 덧셈/뺄셈만 알던 제게 곱셈/나눗셈의 세계가 들어와 죽을 맛이었던 기억이 또렷합니다. 분명 문제 수는 똑같이 10문제인데, 처리하고 생각해야 할 수식이 늘다 보니 미칠 지경이었거든요. 이런 저의 어린 시절 아픔을 공유하는 친구의 이야기가 요즘 AI 업계에서 들리는데요, 바로 스케줄러입니다.
과거 챗봇 서빙시절 스케줄러의 임무는 참 단순했습니다. 요청이 오면 배치에 넣고, 토큰을 뽑고, 돌려주면 끝인, ‘요청 1 = 일 1’인 시대였거든요. 그런데 에이전트의 시대를 맞이한 스케줄러는 정말 고생이죠. 사용자의 질문 하나에 도구 호출 10번, 재시도 3번, 요약 2번, 게다가 외부 API도 잠시 기다려야 하구요. 사용자 입장에선 똑같은 ‘일 1’인데, 스케줄러는 ‘요청 30’을 처리해야 하는 이 눈물나는 상황, 오늘은 그런 스케줄러에 대한 재미난 이야기를 가져와봤습니다.
이상하다… 분명 빨라졌는데?
에이전트의 등장으로 대시보드의 요청당 지연, 그러니까 호출 하나가 오가는 시간은 오히려 줄었어요. 배칭도 잘 돌고, 토큰 처리량도 나쁘지 않아요. 그런데 정작 에이전트의 사용자는 여전히 '느리다'고 말해요. 아니 분명 빨라졌는데, 왜 그럴까요? 정답은 우리가 측정하는 수치와 사용자가 겪는 시간 단위의 간극에 있어요.
일반적으로 서버는 요청당 지연을 측정하는데, 사용자는 일이 끝날 때까지의 시간을 겪어요. 즉, 그동안의 측정 방식은 디테일을 챙기느라 큰 그림을 놓친 셈이죠. 이걸 학계에선 그 '일' 하나가 끝나는 시간, 작업 완료 시간(JCT/Job-Completion-Time)이라고 부르는데요. Astraea 연구팀은 이 간극을 이렇게 정리해요.[1] 기존 시스템은 구간별 최적화에 맞춰져 있어서, 요청 생애 전체의 완료 시간을 최소화하는 데 실패한다고요. 가까이 들여보면 각 구간은 다 잘 돌아가는데, 한 발치 떨어져서 보면 전체는 느린, 전형적인 지역 최적화(Local Optimization)의 함정인거죠.
[이미지 1] 요청 30개가 다 빨라져도, 일 1개가 끝나는 시간은 그대로일 수 있습니다.
KV 캐시, 또 너야?
에이전트가 느린 데에는 사실 KV 캐시의 보관이 한몫해요. 에이전트 세션이 외부 API를 기다리는 동안 해당 세션의 KV 캐시는 보통 GPU 메모리에 그대로 쌓이거든요. 안 그래도 바빠 죽겠는데 메모리마저 발목을 잡고 있으니, 뛰어난 에이전트를 데려와도 GPU 메모리 부하로 제 능력을 발휘하기 어려운 거죠.
그래서 최근 연구들은 팔을 걷고 이 지점을 건드리기 시작했어요. Astraea는 I/O 대기 중인 ‘세션’의 KV 캐시를 메모리 압력에 따라 내렸다 올렸다 하는 적응형 매니저를 붙여서 평균 JCT를 최대 25.5% 줄이는 데 성공했다고 보고했어요.[1] 한편 Autellix는 아예 스케줄러에 프로그램 개념을 넣어서 앞선 ‘호출 이력’을 보고 다음 호출을 선점·우선처리하는 기능을 추가한 결과, 동일한 지연 조건에서 vLLM 대비 4~15배의 처리량을 기록했다고도 했죠.[2]
물론 두 결과 모두 연구팀이 자체적으로 실행한 실험을 통해 보고한 값이라는 한계점은 있어요. 워크로드와 하드웨어가 다르면 실험 결과가 그대로 재현되지도 않고요. 하지만 이들이 제시하는 메세지는 확실해요. 개별 호출을 빠르게 하는 경쟁은 끝났고, 이제 '무엇을 일의 단위로 볼 것인가'의 경쟁이 시작됐다는 거죠.
[이미지 2] 기다리는 동안에도 자리를 잡고 있는 KV 캐시가 진짜 병목입니다.
이제는 큰 그림, 그러니까 '세션'을 볼 차례
이 메세지를 가장 잘 보여주는 게 바로 'SMetric: Rethink LLM Scheduling for Serving Agents with Balanced Session-centric Scheduling' 논문이에요.[3] 번역하면 '에이전트를 서빙하려면 스케줄링을 다시 생각하라, 세션 중심으로'인데요, 제목만으로도 업계의 관심이 어디로 옮겨가는지를 알 수 있죠.
요즘 스케줄링 연구가 붙잡은 단위는 이렇게 정리할 수 있어요. 크게 세 층이에요. 요청(request), 프로그램(program), 세션(session)순으로요. 챗봇 시대에는 첫 번째만 잘 수행하면 충분했어요. 하지만 에이전트 시대에는 세 번째이자 요즘 가장 핫한 ‘세션’까지 단위의 수행능력도 고려해야 클러스터 전체 처리량(TPS)을 끌어올릴 수 있어요. 앞서 본 Astraea와 Autellix가 사용자 체감 지연(JCT)을 줄이는 쪽이었다면, SMetric은 같은 세션이라는 단위를 처리량 쪽에서 붙잡은 셈이죠.
그런데 왜 하필 세션일까요? SMetric 연구진이 재보니, 에이전트 워크로드에서는 앞서 만들어둔 KV 캐시가 다시 쓰이는 비율이 80%를 넘었어요. 사람이 직접 치는 챗봇(54~62%)보다 훨씬 높죠.[3] 사람은 답을 읽으며 뜸을 들이지만, 에이전트는 완성된 답을 받자마자 곧바로 다음 호출을 던지거든요. 그러니까 에이전트의 세션은 '요청이 여러 번 모인 것'이 아니라, 이미 쌓아둔 캐시를 함께 쓰는 하나의 덩어리에 가까운 셈이에요.
이들의 주장에 반박하는 목소리도 있어요. 세션 단위로 보려면 스케줄러가 상태(state)를 들고 있어야 하는데, 그럴 경우 스케줄러 자체가 무거워지는 동시에 에러 발생 시 복구가 까다로워져 배보다 배꼽이 커질 수 있다는 지적인데요, 현재의 무상태(stateless) 설계가 주는 단순함을 포기하는 대가인거죠. 그렇다면 우리는 선택의 기로에 놓이는 것일까요?
물론 이 기로에 대해 SMetric이 내놓은 답도 있어요. 라우터가 세션 상태를 들고 있는 대신, 사용자 입력만 보고 '이게 세션의 첫 턴인지, 이어지는 턴인지'를 가려내는 방식이에요. 첫 턴은 한가한 쪽으로 흩뿌려 부하를 고르게 하고, 이어지는 턴은 캐시가 남아 있는 쪽으로 돌려보내는 거죠.[3] 무상태의 단순함은 지키면서 세션은 챙기는, 나름의 절충안인 셈이에요.
[이미지 3] 스케줄링의 단위가 요청에서 프로그램으로, 다시 세션으로 옮겨가고 있습니다.
우리는 이미 답을 알고 있다
“과거를 기억하지 못하는 자들은 과거를 반복하기 마련이다”
철학자 조지 산타야나(George Santayana)의 명언인데요,[4] 지금 스케줄러 이슈와 찰떡인 것 같아 가져와봤습니다. 생각해 보면 이런 메모리 문제를 우리는 오래전 OS에서 겪었어요. 초기 OS는 명령어 단위로 CPU를 나눴지만, 결국 프로세스와 스레드라는 단위를 만들었어요. 상태를 가진 실행 단위를 정의하고, 그걸 스케줄링하고, 대기중이면 스와핑해서 내리는 체계를 세워 병목을 해소한 거죠.
이런 과거 OS의 사례를 에이전트 서빙 이슈에 비교해보면 이렇게 볼 수 있어요. 세션이 곧 프로세스고, KV 캐시가 곧 그 프로세스의 메모리 페이지예요. I/O 대기 중 캐시를 내리는 건 스와핑이고요. 어때요, 둘이 정말 닮지 않았나요?
다만 이 비유가 정확히 겹치는 건 KV 캐시를 언제 내리고 언제 올릴지를 다루는 층, 그러니까 Astraea가 손대는 자리예요. SMetric이 붙잡은 라우팅은 그보다 한 층 위고요. 캐시를 내릴지 말지가 아니라 이 세션을 어느 노드로 보낼지를 정하니까, OS로 치면 스와핑이 아니라 어느 코어에 붙일지 고르는 쪽에 가깝죠. 두 층은 세션을 하나의 단위로 본다는 목적은 같지만 방법이 달라요. 그래서 서로 대체하는 게 아니라 같이 쌓아 올릴 수 있고요.
에이전트 스케줄링 이슈는 특정 엔진의 기능으로 풀 문제가 아닐지도 몰라요. vLLM도 SGLang도 각자 최적점이 있고 다 훌륭해요. 하지만 세션의 생애주기를 알고, KV 캐시를 언제 내리고 어느 노드로 라우팅할지 결정하는 계층은 엔진 위에 따로 있어야 해요. 엔진에 종속되지 않고, 워크로드별 최적 설정을 자동으로 고르는, ‘스케줄링’에 특화된 계층이요. 어쩌면 우리는, 이미 답을 알고 있을지도 몰라요(갈르륵).
맺음
돌이켜보면 에이전트가 비싸진 건 토큰을 많이 써서만은 아닌 것 같습니다. 아직도 ‘요청’이라는 낡은 단위로 자원을 나누고 있어서겠죠. 무엇을 하나의 일로 볼 것인가가 스케줄링을 정하고, 스케줄링이 활용률을 정하고, 활용률이 결국 단가를 정하니까요. 그러니 에이전트 시대의 원가 절감은 더 빠른 커널이 아니라 ‘단위’의 문제일지도 모릅니다.
저 갈리엄은 이번 논문의 발표가 AI 속 새로운 발견의 가능성에 굉장한 힘을 실어줬다고 생각해요. 스케줄링 단위에 대한 새로운 정의와 재고의 필요성, 그리고 기존 스케줄러 설계 구조에 대한 뜨거운 논의 등, 기존의 패러다임을 뒤집을지도 모르는 영역들을 따끔하게 꼬집은 것 같거든요. 에이전트 스케줄링의 패러다임이 바뀔지도 모른다니, 이 기념비적인 사건을 혹여 놓치지 않도록, 스케줄 정리 좀 해놔야겠습니다. 이상, 아크릴 테크블로그의 음유시인, 갈리엄이었습니다.
“에이전트 시대의 병목은 토큰이 아니라 단위예요.
요청을 아무리 빨리 처리해도,
세션이 자리를 잡고 있으면 클러스터는 놀아요.”
참고 자료 (References)
[1] arXiv — Astraea: A State-Aware Scheduling Engine for LLM-Powered Agents (2025.12.16) https://arxiv.org/abs/2512.14142
[2] arXiv — Autellix: An Efficient Serving Engine for LLM Agents as General Programs (2025.02.19) https://arxiv.org/abs/2502.13965
[3] arXiv — SMetric: Rethink LLM Scheduling for Serving Agents with Balanced Session-centric Scheduling (2026.07.09) https://arxiv.org/abs/2607.08565
[4] George Santayana — The Life of Reason: The Phases of Human Progress, Vol. 1 (1905) https://www.gutenberg.org/ebooks/15000