멀티턴 에이전트 상태 추적: 캐시 생존 정책과 체크포인트 설계 전략
홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →
컨텍스트 엔지니어링 논의는 지금까지 대체로 프롬프트에 무엇을 넣고 뺄 것인가라는 애플리케이션 레이어의 문제에 집중해 왔다. 그러나 2026년 하반기 들어 학계와 서빙 인프라 업계는 더 아래 계층, 즉 에이전트가 도구를 호출하느라 멈춰 있는 공백 동안 GPU에 올라간 KV 캐시를 어떻게 다룰 것인가라는 문제를 별도의 연구 분야로 떼어내고 있다. 이 글은 선택적 주입이나 벡터 DB 캐싱 같은 상류 설계가 아니라, 멀티턴 에이전트의 실행 상태 자체를 서빙 레이어에서 추적·보존·우선순위화·체크포인트하는 메커니즘을 다룬다.
프롬프트 레이어 최적화가 놓치는 지점
프리픽스 캐싱이나 선택적 컨텍스트 주입은 "모델에게 무엇을 보여줄 것인가"를 결정하는 애플리케이션 레이어의 설계다. 이 레이어의 최적화는 토큰 수를 줄이고 캐시 적중률을 높이는 데는 효과적이지만, 암묵적으로 전제하는 것이 하나 있다. 바로 요청이 LLM 추론에서 추론으로 매끄럽게 이어진다는 가정이다. 실제 에이전트 워크로드는 이 가정과 다르게 동작한다. 한 턴의 추론이 끝나면 에이전트는 코드를 실행하거나, 외부 API를 호출하거나, 사용자 승인을 기다리는 공백 구간에 들어간다. 이 공백은 수백 밀리초에서 수십 초, 길게는 사람이 개입할 때까지 이어지는 수 시간까지 벌어질 수 있다.
문제는 이 공백 동안 해당 요청의 KV 캐시가 GPU 메모리에 그대로 남아 있다는 점이다. 기존 추론 엔진은 새 요청이 대기열에 들어오면 끝난 요청의 KV 캐시부터 즉시 비우도록 설계되어 있는데, 이 정책은 에이전트 워크로드에서 그대로 깨진다. 도구 호출 공백에 있는 요청은 "끝난 요청"이 아니라 "잠시 멈춘 요청"이기 때문이다. 캐시를 비우면 다음 턴이 돌아올 때 전체 프리필을 다시 계산해야 하고, 캐시를 그대로 두면 그 공백 시간만큼 GPU 메모리가 다른 요청에 쓰이지 못한 채 잠긴다. 프롬프트 레이어에서 아무리 정교하게 선택적 주입과 프리픽스 캐싱을 설계해도, 서빙 레이어가 이 공백을 다루는 정책을 갖추지 못하면 멀티턴 에이전트는 턴마다 지연과 비용이 누적되는 구조를 벗어나지 못한다.
왜 지금 서빙 레이어의 상태 문제가 부상했는가
에이전트가 한 번의 작업을 완수하는 데 거치는 LLM 호출 횟수가 많아지고, 각 호출 사이에 도구 실행이 끼어드는 비중이 커지면서 이 공백 구간의 누적 효과가 전체 작업 완료 시간에서 차지하는 비중도 함께 커졌다. 여러 에이전트가 동시에 서빙 인프라를 공유하는 멀티테넌트 환경에서는, 한 에이전트의 도구 호출 공백이 다른 에이전트의 요청을 블로킹하는 head-of-line 블로킹 현상까지 겹친다. 이 문제는 프롬프트를 아무리 잘 설계해도 해결되지 않고, 요청 스케줄링과 메모리 관리를 다루는 서빙 레이어에서만 해결할 수 있다는 인식이 2026년 들어 다수의 연구로 이어졌다.
아키텍처: 도구 호출 공백 동안의 KV 캐시 생존 정책
최근 연구들은 공통적으로 "도구 호출 공백을 어떻게 취급할 것인가"라는 하나의 질문에 서로 다른 답을 제시한다.
flowchart TD
A["LLM 추론 턴 완료"] --> B{"다음 동작이 도구 호출인가?"}
B -->|"아니오, 세션 종료"| C["즉시 KV 캐시 반환"]
B -->|"예, 도구 호출 공백 진입"| D{"예상 공백 길이 추정"}
D -->|"짧음"| E["preserve: 캐시 유지"]
D -->|"중간"| F["TTL 설정 후 대기"]
D -->|"김"| G["swap: 호스트 메모리로 이동"]
F --> H{"TTL 만료 전 턴 재개?"}
H -->|"예"| I["캐시 재사용, 프리필 생략"]
H -->|"아니오"| J["discard: 캐시 폐기"]
E --> K["우선순위 스코어 재계산"]
G --> K
I --> L["다음 추론 턴 실행"]
J --> M["다음 턴 전체 프리필 재수행"]
K --> N{"GPU 메모리 압박 발생?"}
N -->|"예"| O["생존 점수 최저 항목부터 축출"]
N -->|"아니오"| L
O --> L
TTL 기반 스케줄링 — Continuum
Continuum은 도구 호출 공백이 발생하는 순간 해당 요청의 KV 캐시에 유효기간(TTL)을 부여하는 방식을 제안한다. TTL은 예상되는 도구 실행 시간과 지금까지의 턴 횟수를 함께 반영해 산정되며, 이 기간 안에 턴이 재개되면 캐시를 그대로 재사용해 프리필을 생략하고, 기간을 넘기면 캐시를 비워 다른 요청에 메모리를 양보한다. 이 접근의 핵심은 "비울 것인가 유지할 것인가"를 이분법으로 결정하지 않고, 시간이라는 연속 변수로 판단을 유예한다는 점이다. 단순히 즉시 축출하거나 무기한 유지하는 기존 정책 대비 평균 작업 완료 시간을 개선한다는 결과가 보고된다.
preserve·swap·discard 결정 — InferCept
InferCept는 도구 호출 공백에서 선택지를 preserve(그대로 유지), swap(호스트 메모리로 옮겨 재적재 가능하게 보존), discard(완전히 폐기) 세 가지로 구분한다. 결정 기준은 기본적으로 캐시를 다시 계산하는 재적재 비용(reload cost)인데, 이는 공백이 짧을 것으로 예상되면 유지 비용이 재계산 비용보다 싸다는 식의 단순 비교다. 다만 이 방식은 공백 시간 동안 다른 요청이 대기열에서 얼마나 오래 기다리게 되는지, 즉 턴이 누적될수록 커지는 대기 지연을 모델에 반영하지 못하고 도구 실행 시간이 가변적일 때 견고하지 않다는 한계가 후속 연구에서 지적된다.
프로그램 수준 스케줄링 — Autellix
Autellix는 개별 LLM 호출 단위가 아니라 에이전트 프로그램 전체의 실행 이력을 보고 스케줄링 우선순위를 매긴다. 한 프로그램이 지금까지 얼마나 많은 턴을 거쳤는지, 완료까지 남은 예상 작업량이 얼마인지를 반영해 head-of-line 블로킹을 줄이는 것이 목표다. 다만 이 방식은 프로그램 수준의 실행 이력에 집중한 나머지 도구 호출 자체의 패턴(어떤 도구가 얼마나 걸리는지, 어떤 도구 호출 뒤에 캐시 재사용률이 높은지)은 충분히 반영하지 못한다는 점이 한계로 지적된다.
생존 기반 우선순위 스코어링 — UNISON
UNISON은 세션 단위의 공유 이벤트 로그를 두고, 각 KV 캐시 항목이 다음에 다시 참조될 때까지의 예상 거리(next-reference distance)를 추정해 생존 점수를 매긴다. GPU 메모리가 압박을 받을 때 축출 대상을 고르는 기준은 "가장 오래 쓰이지 않은 것"이 아니라 "다음 참조까지 가장 멀리 남은 것"이다. 이 점수는 여러 지표(최근성, 턴 간격, 도구 호출 패턴)를 종합한 다중 지표 평가로 산출되며, 단일 지표로 축출 순서를 정하는 기존 LRU류 정책보다 캐시 적중률을 높인다는 것이 핵심 주장이다.
의도 인지 캐시 프루닝 — IntentKV
IntentKV는 캐시 프루닝을 다중 질의 보존(multi-query retention) 문제로 재정의한다. 세션 전체의 의도를 요약한 QueryMemory를 유지하면서, 각 턴의 이력이 이 세션 수준 의도와 얼마나 관련 있는지를 점수화해 보존 여부를 결정한다. 이 접근은 턴 하나하나를 독립적으로 평가하는 대신, 세션이 진행되며 누적되는 의도 신호를 지속적으로 갱신해 반영한다는 점에서 앞선 방식들과 구분된다.
체크포인트·포크·복원·병합 — 실행 상태의 정합성
KV 캐시 생존 정책이 GPU 메모리라는 휘발성 자원을 다루는 문제라면, 체크포인트는 에이전트의 실행 상태 전체를 내구성 있는 저장소에 남겨 장애·중단·재시작에도 작업을 이어가게 하는 문제다. 상태 체크포인팅은 각 단계를 실행하기 전에 진행 상황을 내구성 저장소에 기록해, 여덟 번째 단계에서 장애가 나도 처음이 아니라 일곱 번째 단계부터 재개할 수 있게 한다. 이 설계는 작업 제출과 작업 완료를 분리해, 타임아웃·크래시·사람의 승인 대기·재시작을 모두 견디는 구조를 만든다.
다만 체크포인트, 포크(실행을 복제해 분기), 복원(이전 지점으로 되돌림), 병합(분기된 실행을 하나로 합침)을 자유롭게 조합하기 시작하면 정합성 문제가 발생한다. 최근 연구는 "에이전트가 언제 안전하게 체크포인트·포크·복원·병합을 수행할 수 있는가"를 형식적으로 검증하는 방법을 제시하는데, 이는 실행 중 도구가 외부 세계에 부작용(파일 쓰기, 이메일 발송, 결제 등)을 일으킨 지점을 되돌리면 상태 불일치가 발생하기 때문이다. 즉 상태 저장 자체는 기술적으로 어렵지 않지만, 되돌릴 수 있는 지점과 되돌릴 수 없는 지점을 구분하는 것이 실행 상태 관리의 실질적인 난제다.
또 다른 연구는 중단 후 재개 시 처음부터 다시 시작하는 대신, 이미 완료된 부분 작업을 그대로 승계해 잔여 작업만 완수하는 잔여 완결(residual completion) 방식을 제안한다. 이는 에이전트 핸드오프 상황, 즉 한 에이전트가 처리하던 작업을 다른 에이전트나 다른 세션이 이어받을 때 특히 중요하다. 이벤트 이력을 재생해 과거 LLM 호출을 다시 실행하지 않고 저장된 결과만으로 상태를 재구성하는 이벤트 리플레이 방식도 같은 목표, 즉 재시작 비용을 없애는 방향을 공유한다.
우선순위 정책 설계 — 무엇을 먼저 내보낼 것인가
위의 사례들을 종합하면 우선순위 정책은 공통적으로 다음 네 가지 축을 조합해 설계된다.
- 재계산 비용 축: 캐시를 비웠을 때 다시 채우는 데 드는 비용. InferCept가 기본으로 삼는 축이지만 단독으로 쓰면 대기 지연을 놓친다.
- 시간 축: 공백이 얼마나 지속될 것으로 예상되는가. Continuum의 TTL이 이 축을 명시적으로 다룬다.
- 참조 거리 축: 다음에 이 정보가 다시 필요해지는 시점까지 얼마나 남았는가. UNISON의 생존 점수가 이 축을 추정치로 환산한다.
- 의도 관련성 축: 세션 전체의 목표와 이 정보가 얼마나 관련 있는가. IntentKV가 이 축을 세션 수준 의도로 누적 반영한다.
실무에서 하나의 축만으로 우선순위를 정하면 특정 상황에서 체계적으로 틀린 결정을 내린다. 재계산 비용만 보면 공백이 길어질수록 손해가 커지는 상황을 못 잡고, 시간 축만 보면 세션 목표와 무관한 정보까지 TTL 안에 있다는 이유로 유지하게 된다. 따라서 성숙한 설계는 네 축을 가중합하되, 가중치 자체를 워크로드 특성(도구 호출 빈도, 세션 평균 길이, GPU 메모리 압박 수준)에 따라 동적으로 조정하는 방향으로 수렴하고 있다.
비교 분석: 프롬프트 레이어 캐싱 vs 서빙 레이어 캐싱
| 구분 |
프롬프트 레이어 캐싱 |
서빙 레이어 캐싱 |
| 제어 대상 |
프롬프트 텍스트 구조, 정적·동적 구간 배치 |
GPU 메모리에 올라간 KV 캐시 실체 |
| 의사결정 주체 |
애플리케이션 개발자, 프롬프트 조립기 |
추론 서빙 스케줄러 |
| 전형적 기법 |
프리픽스 캐싱, 시맨틱 캐시, 선택적 주입 |
TTL 스케줄링, preserve/swap/discard, 생존 점수 축출 |
| 실패 시 영향 |
캐시 미스, 토큰 비용 증가 |
턴 재개 지연, head-of-line 블로킹, GPU 메모리 고갈 |
| 관측 지표 |
캐시 적중률, 토큰당 비용 |
턴 재개 지연, 작업 완료 시간, 메모리 점유율 |
두 레이어는 경쟁 관계가 아니라 보완 관계다. 프롬프트 레이어 최적화가 애초에 모델에게 더 적고 더 관련성 높은 토큰을 보내도록 설계한다면, 서빙 레이어 최적화는 그 토큰들이 이미 계산된 결과를 턴 사이 공백에도 잃지 않도록 보존한다. 프롬프트 레이어만 잘 설계하고 서빙 레이어의 공백 처리 정책이 없으면, 매 턴 같은 프리필을 반복 계산하는 비효율이 그대로 남는다. 반대로 서빙 레이어만 정교하게 설계하고 프롬프트 레이어의 선택성이 없으면, 애초에 캐시에 올릴 필요가 없었던 정보까지 보존 대상이 되어 메모리 압박만 키운다.
정보관리기술사 관점: 도입 전략과 거버넌스
정보시스템 아키텍처 관점에서 이 문제는 전통적인 분산 트랜잭션 관리와 캐시 일관성 설계의 재현이다. TTL과 preserve/swap/discard 결정은 분산 캐시의 무효화 정책과 동일한 설계 공간에 있고, 체크포인트·포크·복원·병합의 정합성 문제는 분산 트랜잭션의 커밋·롤백·보상 트랜잭션 설계와 본질적으로 같은 질문을 던진다 — 어디까지 되돌릴 수 있고, 어디서부터는 외부에 이미 영향을 미쳐 되돌릴 수 없는가.
도입을 검토하는 조직이라면 먼저 현재 에이전트 워크로드에서 도구 호출 공백이 전체 작업 완료 시간에서 차지하는 비중을 계측하는 것부터 시작해야 한다. 이 비중이 낮다면 서빙 레이어 최적화보다 프롬프트 레이어 선택성 개선이 투자 대비 효과가 크고, 비중이 높고 멀티테넌트 환경에서 head-of-line 블로킹까지 관측된다면 서빙 인프라 수준의 캐시 생존 정책 도입을 검토할 근거가 된다. 또한 체크포인트·복원 기능을 도입할 때는 반드시 각 도구 호출이 외부 세계에 부작용을 일으키는지 여부를 사전에 분류해, 복원 가능한 지점과 복원 불가능한 지점을 구분하는 정책을 문서화해야 한다. 이 분류가 없으면 장애 복구 과정에서 이미 실행된 결제나 발송을 중복 실행하는 사고로 이어질 수 있다.
마무리
컨텍스트 엔지니어링의 다음 단계는 프롬프트에 무엇을 넣을지를 넘어, 멀티턴 에이전트가 도구 호출 공백 동안 잃어버리는 계산 결과를 서빙 레이어에서 어떻게 보존하고 우선순위화할 것인가로 이동하고 있다. TTL 스케줄링, preserve/swap/discard 결정, 생존 기반 우선순위 스코어링, 의도 인지 프루닝은 모두 "비울 것인가 유지할 것인가"라는 이분법을 연속적인 판단으로 바꾸려는 시도이며, 체크포인트·포크·복원·병합의 정합성 문제는 이 판단을 실행 상태 전체로 확장했을 때 드러나는 또 다른 난제다. 정보관리기술사는 이를 분산 캐시 일관성과 분산 트랜잭션 관리라는 익숙한 틀로 재해석해, 계측 우선순위와 거버넌스 체계를 먼저 세우는 것이 바람직하다.
Keywords
KV Cache, 캐시 생존 정책, Multi-turn Agent, 멀티턴 에이전트, State Checkpointing, 체크포인트, Priority Scoring, 우선순위 스코어링, TTL Scheduling, 서빙 레이어
Sources
