💡 이번주 뉴스레터에는 이런 내용을 담았어요!

• 하나의 Agent 작업이 여러 번의 LLM 호출로 이루어지고, 이 호출들이 실제로 어떤 구조에서 처리되는지 살펴봅니다.
• 여러 Agent 프로그램이 동시에 실행될 때 생길 수 있는 프로그램 단위 Scheduling 문제와, 여러 Engine 사이에서 KV Cache를 어떻게 재사용할지 알아봅니다.
• 개별 LLM 호출이 아니라 Agent 프로그램 전체의 실행 이력과 Context를 함께 고려하는 Agentix의 핵심 아이디어를 소개합니다.

앞에서는 하나의 에이전트 프로그램을 살펴봤습니다. 이번에는 실제 서비스처럼, 서로 다른 목표를 가진 여러 에이전트 프로그램이 동시에 실행되는 상황을 생각해보겠습니다. 그림에서는 Program A, B, C, D가 각각 하나의 작업이고, A1 → A2 → A3 → A4처럼 하나의 프로그램 안에서 여러 LLM 호출이 이어집니다.

이때 서로 다른 프로그램에서 나온 LLM 호출들은 같은 GPU 자원을 두고 경쟁하게 됩니다. 기존 LLM Serving 시스템은 주로 개별 LLM 호출을 얼마나 효율적으로 처리할지에 초점을 맞춰왔지만, Agent 환경에서는 이것만으로 충분하지 않을 수 있습니다.

• FCFS (First-Come First-Served): 먼저 도착한 LLM 호출부터 순서대로 실행하는 단순한 선착순 스케줄링 방식입니다. 구현은 간단하지만, 앞에 긴 호출이 있으면 뒤의 짧은 호출도 함께 오래 기다릴 수 있습니다.
• MLFQ (Multi-Level Feedback Queue): 여러 개의 우선순위 큐를 두고, 오래 실행된 호출의 우선순위를 낮추는 스케줄링 방식입니다. 긴 호출이 GPU를 계속 점유하지 못하게 하고, 새로 들어온 호출이나 아직 적게 실행된 호출에 더 빠르게 실행 기회를 줍니다.

이 차이를 고려하지 않으면 A와 B가 후속 호출을 만들 때마다 다시 앞쪽으로 들어오면서, 짧은 Program D가 계속 뒤로 밀릴 수 있습니다. 그림의 MLFQ에서도 D1이 여러 번 실행을 양보하며 뒤로 밀리는 모습을 볼 수 있죠. 

사용자 입장에서는 비교적 간단한 Agent 작업을 맡겼는데도, 다른 긴 Agent 작업의 후속 호출이 계속 먼저 처리되면서 내 작업 전체가 예상보다 늦게 끝나는 상황이 생길 수 있습니다.

이를 해결하기 위해 Agentix가 제안하는 핵심은 LLM 호출 하나가 아니라, 그 호출이 속한 프로그램 전체를 기준으로 스케줄링하는 것입니다. A2가 새로 들어온 호출이더라도, Program A가 앞에서 이미 얼마나 실행됐는지까지 함께 보는 것이죠.

뒤에서 자세히 살펴볼 PLAS(Program-Level Attained Service)가 이런 방식입니다. 그림의 (d) PLAS에서는 이미 실행 기회를 많이 받은 A와 B의 후속 호출을 뒤로 미루고, 상대적으로 덜 실행된 C와 D를 먼저 처리함으로써, 짧은 프로그램이 긴 프로그램의 후속 호출에 계속 밀리는 현상을 줄일 수 있어요.

이제 Agentix가 실제로 어떤 구조로 동작하는지 살펴보겠습니다.

Agentix는 프로그램 단위의 정보를 바탕으로 크게 두 가지 결정을 내립니다. Scheduler는 여러 LLM 호출 중 무엇을 먼저 실행할지, Load Balancer는 선택된 호출을 어느 LLM Engine에서 실행할지 정하죠. 여기서는 먼저 Scheduler를 다루려고 해요.

Agentix는 개별 LLM 호출만 보는 대신, 그 호출이 속한 프로그램의 실행 이력까지 함께 고려합니다. 이를 위해 프로그램별 상태를 Global Process Table에 모아 관리해요. 각 프로그램이 지금까지 얼마나 실행되고 기다렸는지, 현재 어떤 Thread가 실행 중인지, 어느 Engine을 사용하고 있는지 같은 정보가 여기에 기록됩니다.

Scheduler는 이 정보를 바탕으로 어떤 프로그램의 LLM 호출에 먼저 실행 기회를 줄지 결정합니다.

여러 작업이 병렬로 진행될 때, 전체 프로그램이 끝나는 시점을 결정하는 가장 긴 실행 경로입니다. 이 경로가 늦어지면 다른 Branch가 먼저 끝나더라도 프로그램 전체 완료 시간은 줄어들지 않습니다.

Agentix는 이런 다중 스레드 프로그램을 위해 ATLAS(Adaptive Thread-Level Attained Service)를 사용합니다. 모든 호출의 실행 시간을 단순히 더하는 대신, 현재까지 관측된 Critical Path를 기준으로 프로그램이 얼마나 실행됐는지 계산하는 방식입니다.

오른쪽 그림을 보면 왜 이런 기준이 필요한지 더 잘 드러납니다. 같은 프로그램이라도 스케줄링 순서에 따라 전체 완료 시간이 달라질 수 있어요. Best-Case에서는 Critical Path인 2 → 4 → 4 → 1이 끊기지 않고 이어지고, 다른 Branch가 그와 병렬로 처리되면서 프로그램이 11에 끝납니다. 반면 Worst-Case에서는 Critical Path에 속하지 않는 호출들이 먼저 실행되면서 4 → 4 경로가 뒤로 밀리고, 전체 완료 시간도 14까지 늘어납니다.

정리하면, PLAS는 순차적으로 이어지는 프로그램의 누적 실행 시간을, ATLAS는 병렬 구조에서 현재까지 관측된 Critical Path의 실행 시간을 기준으로 우선순위를 정하는 스케줄링 방식입니다.

앞에서 본 Scheduler가 여러 LLM 호출 중 무엇을 먼저 실행할지 정한다면, Load Balancer는 그렇게 선택된 호출을 어느 LLM Engine에서 실행할지 정합니다.

여러 Engine을 함께 사용할 때는 단순히 가장 한가한 곳으로 보내는 것만으로는 최적이라고 할 수 없습니다. 같은 프로그램의 후속 호출은 이전 대화와 Tool 실행 결과를 이어받기 때문에, 이전에 계산한 KV Cache가 남아 있는 Engine에서 이어서 처리하면 반복 계산을 줄일 수 있기 때문이죠.

이렇게 필요한 데이터가 이미 있는 곳에서 작업을 이어서 실행하는 특성을 데이터 지역성(Data Locality)이라고 합니다. 예를 들어 Program A의 A1을 처리한 Engine에 관련 KV Cache가 남아 있다면, A2나 A3도 같은 Engine에서 처리할 때 이전 계산 결과를 활용할 수 있습니다. 반대로 다른 Engine으로 보내면 같은 Prefix를 다시 계산해야 할 수 있죠.

하지만 모든 후속 호출을 항상 같은 Engine으로 보내면 그곳에 작업이 몰릴 수 있습니다. 그래서 Agentix는 기존 계산을 재사용할지, 더 한가한 Engine으로 보내 작업을 나눌지를 함께 봅니다.

프로그램 초반에는 아직 해당 프로그램만의 Context가 많이 쌓이지 않았기 때문에, 기존 Engine을 고집해서 얻는 이점이 크지 않습니다. 이런 호출은 부하가 낮은 Engine으로 보내는 편이 낫습니다. 반대로 프로그램이 진행될수록 이전 대화와 Tool 결과가 누적되고, 프로그램 고유의 Context도 길어집니다. 이때는 같은 Engine에 남아 있는 KV Cache를 재사용할 수 있는 이점이 커지기 때문에, 이처럼 Context가 길어진 프로그램은 해당 프로그램의 KV Cache가 남아 있는 Engine에서 이어서 처리합니다.

즉 Agentix는 Context가 아직 적을 때는 작업을 여러 Engine에 나누는 쪽을, 많이 누적됐을 때는 기존 KV Cache를 재사용하는 쪽을 더 중요하게 보는 방식입니다.

개인적으로 이 논문에서 가장 흥미로웠던 부분은 새로운 스케줄링 알고리즘 자체보다, Serving 시스템이 무엇을 하나의 ‘작업 단위’로 바라봐야 하는지를 다시 생각하게 했다는 점이었습니다. 이렇게 설계한 근거는 사용자의 만족도 측면에서 Chatbot에서는 개별 요청의 지연 시간이 중요했다면, Agent를 사용하는 입장에서는 여러 번의 LLM 호출과 Tool 사용이 모두 끝나 내가 맡긴 작업 전체가 언제 완료되는지가 더 중요하기 때문이죠.

앞으로는 하나의 Agent가 혼자 작업하는 형태를 넘어, 여러 Agent와 사람이 함께 여러 목표를 수행하는 구조도 점점 늘어날 것 같습니다. 그럴수록 Serving은 단순히 GPU를 효율적으로 쓰는 기술이 아니라, Agent 시스템 전체의 성능과 규모를 결정하는 필수적인 기반에 가까워질 것 같습니다.