에이전트가 실제로 필요로 하는 메모리 용량은 어느 정도인가?
요약
본 글은 에이전트에게 제공해야 할 '메모리 용량(dose)'을 모델 성능과 작업 특성에 맞춰 조절하는 것이 중요함을 강조합니다. 강력한 모델은 전체 가이드라인 세트를, 약한 모델은 검색 기반의 간결한 핵심 정보를 받는 것이 가장 효과적입니다.
핵심 포인트
- 에이전트 메모리는 켜고 끌 수 있는 기능이 아닌 '용량(dose)' 조절이 필수다.
- 강력한 모델은 전체 가이드라인 세트를, 약한 모델은 검색 기반의 간결한 정보가 최적이다.
- 선별된 검색(Curated retrieval) 방식이 정확도와 비용 면에서 가장 효율적일 수 있다.
ALTK-Evolve를 ACE와 함께 사용해 본 결과, 에이전트의 자체 증류된 가이드라인을 어떻게 전달하느냐(작업별 몇 개를 검색하여 제공할지 vs. 전체 세트를 주입할지)가 정확도와 비용 모두에 영향을 미친다는 것을 보여주었습니다. 이 글은 그보다 앞선 질문, 즉 '얼마나' 제공해야 하는지에 대한 질문으로 돌아갑니다. 에이전트에게 에이전틱 메모리(agentic memory)를 갖추게 하는 것은 간단해 보입니다: 과거 작업에서 배운 교훈을 증류하여 컨텍스트에 다시 넣으면 되고, 경험이 많을수록 성능이 좋아져야 합니다. 하지만 항상 그런 것은 아닙니다. 평가 규모를 30B 밀집 모델부터 최첨단 독점 시스템까지 여덟 가지 모델로 확장했을 때, 한 가지 발견이 눈에 띄었습니다: 에이전틱 메모리는 켜고 끌 수 있는 기능(feature)이 아닙니다. 모델에 맞춰 용량을 조절해야 하는 '용량(dose)'입니다.요약 (TL;DR)
ALTK-Evolve는 에이전트가 자체 과거 궤적으로부터 학습하게 합니다: 재사용 가능한 가이드라인을 증류하여 추론 시점에 주입하며, 이때 모델의 가중치 업데이트나 인간의 어노테이션(annotation)은 필요 없습니다. 최적의 용량은 모델 등급에 따라 다릅니다: 여유 공간이 있는 강력한 모델은 전체 가이드라인 세트를 원하고, 약한 모델은 간결한 핵심과 작업별 검색을 통해 가장 좋은 성능을 보이며, 포화된 모델은 측정 가능한 이득을 보여주지 못합니다. 선별된 검색(Curated retrieval)은 가장 정확하면서도 가장 저렴한 옵션일 수 있습니다: gpt-oss-120b는 토큰 증가율이 단지 +5%에 불과했음에도 작업 완료율에서 +16.1pp의 향상을 얻었으며, 프롬프트 캐싱(prompt caching)은 전체 가이드라인 세트조차도 프로덕션 환경에서 저렴하게 유지할 수 있게 합니다.
모든 모델이 동일한 양의 메모리로부터 이득을 보는 것은 아닙니다. 역량 스펙트럼에 걸친 여덟 가지 모델 전반에 걸쳐, 우리는 세 가지 반복되는 패턴을 발견했습니다:
**여유 공간이 있는 강력한 모델(Strong models with headroom)**은 전체 가이드라인 세트—희귀한 엣지 케이스 교훈을 포함하여 모든 가이드라인—를 원합니다. 이들은 모든 것을 흡수하고 적용할 수 있는 능력을 가지고 있습니다. DeepSeek-V3.2 (671B MoE)는 전체 자체 채굴된(self-mined) 가이드라인 세트를 제공받았을 때 작업 완료율이 +9.5 퍼센트 포인트 상승했습니다.**작거나 약한 모델은 큰 가이드라인 세트에 압도됩니다.**이런 경우, 간결하고 신뢰도가 높은 핵심 내용에 더해 작업 관련 가이드라인 몇 개를 각 작업별로 검색하여 제공하는 것이 가장 효과적입니다. gpt-oss-120b (117B MoE)는 이러한 선택적 접근 방식을 통해 +16.1pp의 이득을 얻었지만, 전체 가이드라인 세트를 사용했을 때는 이득이 적었고 토큰 비용은 약 50% 더 많이 들었습니다.**이미 포화된 모델(Already-saturated models)은 측정 가능한 이득을 보이지 않았습니다.**우리는 이를 '포화 패턴(saturated pattern)'이라고 부릅니다. 이 용어는 우리가 관찰한 것을 설명하는 것이지, 입증된 원인을 나타내는 것은 아닙니다. 해당 모델이 이미 이 작업에서 최대치에 근접했거나, 가이드라인이 남아있는 실패 지점을 다루지 못했거나, 혹은 안내를 효과적으로 적용하지 못했을 수 있습니다. GLM-5 (745B MoE)가 저희 테스트에서 여기에 속했습니다.
모델을 한 패턴에 위치시키는지 다른 패턴에 위치시키는지는 단순히 파라미터 개수만은 아닙니다. 벤치마크 여유 공간, 컨텍스트 창 크기, 아키텍처, 가이드라인 품질 및 작업 분포 등 모든 것이 모델이 어느 지점에 머무를지를 결정하는 것으로 보이며, 이 요소들을 분리하는 것은 현재 진행 중인 연구입니다. 실질적인 시사점은 어떤 경우든 동일합니다: 적절한 양의 메모리는 모델에 따라 다르며, 우리는 이를 조정할 수 있습니다.
여기서 '메모리(Memory)'는 과거 트랜스크립트를 재현한다는 의미가 아닙니다. 이는 에이전트 자체의 이전 궤적에서 추출된 가이드라인 세트(guideline set)—성공했던 전략, 피해야 할 실수, 그리고 엣지 케이스—를 의미합니다. 과정은 간단합니다:
- 에이전트가 작업을 시도하고 궤적을 생성합니다.
- ALTK-Evolve는 성공적인 실행과 실패한 실행 모두에서 행동 가이드라인을 추출합니다.
- 이 가이드라인들을 재사용 가능한 세트로 통합합니다.
- 추론(inference) 시간에 에이전트는 전체 가이드라인 세트 또는 작업 관련 선택된 가이드라인을 받게 됩니다.
모델 가중치(model weights)는 업데이트되지 않습니다. 학습 루프는 근본적인 모델 자체를 변경하는 것이 아니라, 에이전트가 이용할 수 있는 가이드라인을 변경합니다. 이것이 바로 이 방법론을 채택하기 쉽고, 우리가 테스트한 8가지 모델 전반에 걸쳐 포터블(portable)하다는 이유입니다.
저희는 AppWorld에서 평가를 진행했습니다. 여기에는 9개의 시뮬레이션 앱(캘린더, 메시징, 결제 등)에 걸친 585개의 다단계 작업이 포함되어 있습니다 (168개 test_normal + 417개 test_challenge). 작업은 두 가지 방식으로 점수화됩니다. 에이전트가 각 작업을 완전히 완료했는지 여부(TGC — Task Goal Completion)와 시나리오의 모든 변형이 통과했는지 여부(SGC — Scenario Goal Completion, 더 엄격한, 전원 아니면 무(all-or-nothing) 기준)입니다. 전체 정의는 부록에 있습니다.
어떤 메모리 연구에서 가장 혼란스러운 부분은 실제로 컨텍스트 창(context window) 안에 무엇이 들어가는지이기 때문에, 저희는 구성(configuration)을 미리 정의했습니다.
두 메모리 구성 모두 동일한 가이드라인 세트를 사용하며, 이 세트는 AppWorld의 **훈련 분할(training split)**에서 한 번만 채굴됩니다 (위 루프를 통해). 두 구성 간에 달라지는 것은 오직 그 하나의 세트를 어떻게 전달하는지뿐입니다. 즉, 전체 가이드라인 세트는 매 단계마다 모든 것을 주입하는 반면, **큐레이션된 검색(curated retrieval)**은 선택된 하위 집합을 제공합니다. 가이드라인이 생성된 방식이 달라지는 것이 아니며, 테스트 분할 데이터가 구축 과정에 들어가는 일도 없습니다.
| 구성 | 에이전트의 컨텍스트에 포함되는 내용 |
|---|---|
| Baseline | 메모리 없음 — 출고 상태의 에이전트. |
| ... | |
| 모델이 채굴하는 가이드라인의 수는 모델 자체의 역량에 따라 달라지므로, 저희는 원시적인 개수(raw counts)로 보고하기보다는 전략별로 구성( |
그림에서는 가독성을 위해 TGC를 플롯하고, 표에서는 더 엄격한 SGC 지표를 추가했는데, 여기서의 성능 향상(gains)이 훨씬 큰 경우가 많습니다:
| Model | Pattern | Baseline TGC / SGC | Best-memory TGC / SGC | Best config | Δ TGC | Δ SGC |
|---|---|---|---|---|---|---|
| gpt-oss-120b (117B MoE) | Weak / selective | 39.9 / 21.4 | 56.0 / 37.5 | curated retrieval | +16.1 | +16.1 |
| ... | ||||||
| Reading the SGC column, the stricter metric usually moves more than TGC — DeepSeek의 SGC는 +16.1pp 상승한 반면 TGC는 +9.5pp 상승에 그쳤습니다 — 이는 좋은 가이드라인이 단순히 평균적인 경우뿐만 아니라 시나리오의 모든 변형(every variant)을 에이전트가 명확히 처리하는 데 특히 도움이 되기 때문입니다. 그리고 이러한 효과는 최고 범위에서도 사라지지 않습니다: GPT-5.5와 Opus 모두 TGC 측면에서 거의 최대치에 근접했음에도 불구하고, 각각 +7.2 및 +7.1pp의 SGC를 얻었습니다. 모델이 여전히 목표로 삼을 수 있는 실패 모드(failure mode)가 남아있는 한 메모리는 계속해서 가치를 제공합니다. |
실질적인 고려 사항: 전체 가이드라인 세트를 주입하면, 해당 가이드라인이 매 턴마다 재전송되기 때문에 모든 ReAct 단계의 입력 토큰량이 증가합니다. 저희가 관찰한 내용은 다음과 같습니다:
| Model | Config | Tokens/task (baseline) | Tokens/task (+ memory) | Overhead |
|---|---|---|---|---|
| DeepSeek-V3.2 | full guideline set | 148K | 263K | +78% |
| ... | ||||
| 표 1. 에이전트 단계 전반에 걸쳐 누적된, 메모리가 없는 기준선 대비 작업당 평균 토큰 사용량. |
두 가지 핵심 시사점:
Curated retrieval은 비용을 기준선 근처로 유지합니다. 정확도 측면에서 선택(selection)이 우위를 점하는 약한 모델의 경우, 비용에서도 우위를 점합니다. 이는 두 마리 토끼를 모두 잡는 것입니다 (gpt-oss-120b의 경우 +16.1pp TGC 상승에 불과히 +5%의 토큰 증가). 여기서 성능 향상이 더 많은 추론(inference) 비용을 요구하지 않습니다.
메모리가 추론 루프를 폭증시키지 않습니다. DeepSeek은 메모리를 사용하든 안 하든 ReAct 단계 수가 거의 비슷합니다 (평균 약 18~19회). 따라서 추가되는 비용은 트래젝토리 길이 증가가 아니라 입력 토큰량의 증가입니다.
실제 효율성을 높이는 핵심 요소는 **프롬프트 캐싱(prompt caching)**입니다. 가이드라인 세트의 정적 부분은 단계마다 동일하므로 캐시할 수 있으며, 이를 통해 실질적인 비용을 크게 절감할 수 있습니다. 공유되는 가이드라인 세트 접두사(prefix)를 안정적으로 유지하여 캐싱이 가능하도록 하는 '캐시 인식 프롬프트 설계(Cache-aware prompt design)'는 엔지니어링할 가치가 있습니다. 또한, **컨텍스트 창 크기(context-window size)**가 역할을 할 것이라고 가정합니다. 더 큰 컨텍스트 창을 가진 모델은 전체 가이드라인 세트를 더 효과적으로 흡수할 수 있는 반면, 작은 컨텍스트를 가진 모델은 주입된 내용(injected content)을 간결하게 유지하는 검색(retrieval) 방식으로부터 더 많은 이점을 얻습니다. 저희는 아직 이 요인을 분리하여 통제된 실험을 진행하지 못했습니다.
교훈은 에이전트에게 배운 모든 것을 주는 것이 아닙니다. 실제로 사용할 수 있는 양의 경험을 제공하는 것입니다.
**약한 모델(weak models)**의 경우, 이는 간결한 핵심 내용과 몇 가지 작업별 교훈을 의미하며—이는 편리하게도 가장 저렴한 옵션이기도 합니다. **여유 공간이 있는 강력한 모델(strong models with headroom)**의 경우, 프롬프트 캐싱을 통해 운영 단계에서 비용 효율적으로 유지되는 전체 가이드라인 세트를 보존하는 것을 의미합니다. **포화된 모델(saturated models)**의 경우, 남아있는 실패 모드(failure modes)가 더 잘 이해될 때까지 추가 컨텍스트를 사용하지 않는다는 것을 의미합니다.
이러한 이점들은 자동적이고, 누출이 없으며, 인간의 주석 작업이 필요하지 않지만—모델에 맞는 용량일 때만 실현됩니다.
이는 끝이 아니라 시작점입니다:
학습된 선택기(A learned selector). 현재 우리의 검색(retrieval)은 코사인 유사도(cosine similarity)에 따라 가이드라인을 순위화하는데, 이는 주어진 작업에 어떤 가이드라인이 도움이 될지 완벽하게 예측하지 못한다는 것을 보여주었습니다. 결과 신호(outcome signal)로 훈련된 선택기(selector)가 자연스러운 다음 단계입니다.매우 취약한 모델을 위한 메모리(Memory for very weak models). 최소 역량 기준선(minimum capability baseline) 이하에서는 자기 증류(self-distillation)가 신호를 얻지 못합니다. 매우 취약한 모델을 위한 교사 증류(Teacher-distilled memory)는 우리가 탐구하고 있는 별개의 문제입니다.AppWorld를 넘어서(Beyond AppWorld). 이 결과들은 엄격한 다단계 벤치마크인 AppWorld에서 검증되었지만, 단일 벤치마크에 불과합니다. 더 광범위한 에이전트 벤치마크와 실제 배포가 진행 중입니다.컨텍스트 창 분리(Isolating context window). 위에서 언급했듯이, 우리는 컨텍스트 창 크기(context-window size)를 순수한 역량(raw capability)과 분리하는 통제된 실험을 원합니다. ALTK-Evolve 라이브러리를 사용해 보거나—여기서 사용된 추출(extraction), 통합(consolidation), 검색(retrieval) 파이프라인을 포함하고 있습니다—전체 방법론과 제거 연구(ablations)를 위해 전체 기술 보고서를 읽어보세요.
AppWorld 작업은 두 가지 지표로 평가되며, 둘 다 백분율(percentage)로 보고됩니다(높을수록 좋음):
TGC — 작업 목표 완료(Task Goal Completion). 에이전트가 완전히 그리고 정확하게 완료하는 개별 작업의 비율입니다. 이것이 핵심적인 '일을 마쳤는가' 수치입니다.
SGC — 시나리오 목표 완료(Scenario Goal Completion). 더 엄격한, 전원 또는 무(all-or-nothing) 방식의 지표입니다. 각 *시나리오(scenario)*는 동일한 작업의 여러 변형(다른 데이터, 구문, 또는 엣지 조건이 있는 동일한 요청)을 묶습니다. SGC는 에이전트가 모든 변형에서 성공할 때만 시나리오를 통과로 간주합니다. 이는 **신뢰성(reliability)**을 측정합니다—대부분의 경우 작업을 해결하지만 한 변형에서 실패하는 에이전트는 TGC에서는 점수를 얻지만 SGC에서는 점수를 얻지 못합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Hugging Face Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기