AI 에이전트에게 얼마나 많은 메모리를 제공해야 할까? 8개 모델 연구 결과 (2026)

여기서 "메모리"는 대화 기록이 아니라 정제된 가이드라인을 의미합니다

이 단어는 여러 가지 다른 개념을 포괄하기 때문에 가장 먼저 짚고 넘어가야 할 부분입니다. 저자들은 다음과 같이 명확히 밝히고 있습니다. "여기서 '메모리'는 과거의 대화 기록을 다시 재생하는 것을 의미하지 않습니다. 이는 에이전트 자신의 이전 궤적(trajectories)에서 정제된 가이드라인 세트—성공한 전략, 피해야 할 실수, 예외 상황(edge cases)—를 의미합니다."

전체 루프는 다음과 같습니다. 에이전트가 작업을 시도하고 궤적을 생성하면, 시스템은 "성공한 실행과 실패한 실행 모두에서" 행동 가이드라인을 추출합니다. 이를 재사용 가능한 세트로 통합하고, 추론(inference) 시점에 에이전트는 전체 세트 또는 그중 선택된 일부를 제공받습니다. 결정적으로 "모델 가중치는 업데이트되지 않습니다." 변경되는 것은 모델 자체가 아니라 "에이전트가 사용할 수 있는 안내(guidance)"입니다.

따라서 이는 대화 기록에 관한 연구가 아니며, 긴 컨텍스트 창(context window)에 관한 연구도 아닙니다. 이는 왜 긴 컨텍스트가 메모리가 아닌가와 구분해서 생각해야 할 중요한 차이점입니다.

벤치마크와 두 가지 지표

평가는 AppWorld에서 진행되었습니다. "9개의 시뮬레이션된 앱(캘린더, 메시징, 결제 등)에 걸친 585개의 다단계 작업(168개의 test_normal + 417개의 test_challenge)"을 대상으로 했습니다.

두 가지 점수가 측정되었으며, 그 사이의 격차가 흥미로운 부분으로 드러났습니다.

TGC — Task Goal Completion (작업 목표 완료율). "에이전트가 개별 작업을 완전하고 정확하게 완료한 비율"입니다. 가장 직관적인 성공 여부 수치입니다.

SGC — Scenario Goal Completion (시나리오 목표 완료율). "더 엄격한 전부 아니면 전무(all-or-nothing) 방식의 지표"입니다. 각 시나리오는 동일한 작업의 여러 변형을 묶은 것이며, "SGC는 에이전트가 모든 변형 작업에서 성공해야만 해당 시나리오를 통과한 것으로 간주합니다. 이는 신뢰성을 측정합니다."

세 가지 구성

두 메모리 구성 모두 AppWorld의 훈련 분할(training split)에서만 "단 한 번 추출된" 동일한 가이드라인 세트에서 가져오며, 저자들은 "테스트 분할 데이터는 가이드라인 구축에 전혀 들어가지 않는다"고 명시했습니다. 차이점은 전달 방식에 있습니다.

Baseline (기본값) — "메모리 없음 — 출시된 상태 그대로의 에이전트."

Full guideline set (전체 가이드라인 세트) — "추출된 모든 가이드라인을 모든 ReAct 단계에 주입."

Curated retrieval (큐레이션된 검색) — "동일한 가이드라인 중 신뢰도가 높은 고정된 핵심 세트에 더해, 각 작업에 맞게 검색된 몇 가지 작업 관련 가이드라인을 추가(고정 영역 + 가변 영역)."

세 가지가 눈에 띕니다.

강력한 모델은 모든 것을 흡수했습니다. 개선 여지가 있는 모델들은 "드문 예외 상황에 대한 교훈을 포함하여" 전체 가이드라인 세트에서 가장 좋은 성능을 보였습니다. "이러한 모델들은 그 모든 것을 흡수하고 적용할 수 있는 능력을 갖추고 있기 때문"입니다.

약한 모델은 양에 압도당했습니다. "더 작거나 약한 모델은 방대한 가이드라인 세트에 묻혀버립니다." gpt-oss-120b의 경우, 전체 세트를 사용했을 때 curated retrieval에 비해 "성능 향상은 더 적으면서도 토큰 비용은 약 50% 더 많이 들었습니다."

엄격한 지표가 대표 지표보다 더 크게 움직였습니다. DeepSeek은 TGC가 +9.5 증가한 반면 SGC는 +16.1 증가했습니다. "좋은 가이드라인은 에이전트가 평균적인 케이스뿐만 아니라 시나리오의 모든 변형을 해결하는 데 특히 도움이 되기 때문"입니다. 한계에 도달한 모델들조차 신뢰성 면에서 계속해서 향상되었습니다. GPT-5.5와 Opus는 각각 SGC가 +7.2%p, +7.1%p 증가했습니다. 저자들의 이 표현은 기억해 둘 만합니다. "모델에 해결해야 할 실패 모드(failure mode)가 남아 있는 한, 메모리는 계속해서 효과를 발휘합니다."

그리고 한 모델은 아무런 변화도 보이지 않았습니다. GLM-5는 이러한 작업에서 메모리가 있을 때와 없을 때 동일한 점수를 기록했습니다. 이것이 무엇을 의미하는지에 대해 저자들은 매우 신중한 태도를 취하고 있으며, 이는 아래에서 다룹니다.

매 단계마다 가이드라인을 주입하는 것에 대한 즉각적인 반론은 비용이며, 이는 타당한 지적입니다. 그들의 측정 결과는 다음과 같습니다.

따라서 더 약한 모델의 경우, 선택적 적용이 두 축 모두에서 동시에 승리했습니다. "토큰은 단 5%만 증가하면서 TGC는 +16.1%p 향상"되었습니다. 저자들의 표현대로 "여기서 더 나은 성능을 얻기 위해 더 많은 추론 비용이 필요한 것은 아닙니다."

비용을 예산에 반영하려는 사람들에게는 두 가지 보조적인 발견이 중요합니다. 첫째, 오버헤드는 더 많은 작업을 수행해서가 아니라 입력 토큰이 늘어났기 때문입니다. "DeepSeek은 메모리가 있을 때나 없을 때나 거의 동일한 횟수의 ReAct 단계(평균 약 18~19단계)를 실행하므로, 추가된 비용은 더 긴 궤적이 아니라 입력 토큰의 팽창 때문입니다." 둘째, 이를 해결할 수 있는 표준적인 수단이 있습니다. "프로덕션에서 실제 효율성을 높이는 수단은 프롬프트 캐싱(prompt caching)입니다. 가이드라인 세트의 정적인 부분은 단계 전반에 걸쳐 동일하므로 캐싱할 수 있어 실질적인 비용을 크게 절감할 수 있습니다." 저자들은 이를 고려한 설계를 권장합니다. "공유되는 가이드라인 세트 접두사(prefix)를 안정적으로 유지하여 캐싱이 가능하도록 만드는 것"입니다.

이 마지막 점은 설계에 직접적인 시사점을 줍니다. 매 호출마다 출력을 재정렬하는 메모리 레이어는 캐싱을 무력화합니다. 안정적인 핵심(core)과 작은 가변적인 꼬리(tail)를 가진 구성이 실행 비용이 더 저렴하며, 이는 더 약한 모델에서 정확도 면에서도 승리한 구성이기도 합니다.

저자들은 자신들의 한계에 대해 매우 엄격한 태도를 유지하고 있으며, 이를 올바르게 인용하는 것이 결과를 정직하게 읽는 방법입니다.

"포화 상태(Saturated)"는 관찰된 현상을 설명할 뿐, 원인을 설명하는 것은 아닙니다. GLM-5의 변화 없는 결과에 대해 저자들은 다음과 같이 말합니다. "우리는 이를 포화 패턴이라고 부릅니다. 이 라벨은 우리가 관찰한 현상을 설명할 뿐, 증명된 원인이 아닙니다. 모델이 이미 이러한 작업에서 한계에 가까웠을 수도 있고, 가이드라인이 남아 있는 실패 요인을 해결하지 못했을 수도 있으며, 혹은 안내를 효과적으로 적용하지 못했을 수도 있습니다." 이는 모델의 품질에 대한 결론이 아닙니다. 단 하나의 벤치마크, 하나의 가이드라인 세트, 하나의 구성일 뿐입니다.

역량 등급이 단순히 매개변수(parameter) 수를 의미하지는 않습니다. "모델을 특정 패턴으로 분류하는 것은 단순히 매개변수 수만이 아닙니다. 벤치마크의 개선 여지, 컨텍스트 창 크기, 아키텍처, 가이드라인의 품질, 작업 분포 등이 모두 모델이 도달하는 위치를 결정하는 것으로 보이며, 이러한 요인들을 분리하는 것은 현재 진행 중인 연구 과제입니다." 745B의 GLM-5와 671B의 DeepSeek이 서로 다른 패턴에 속했다는 점에 주목하십시오.

컨텍스트 창 크기에 대한 설명은 가설입니다. 저자들은 더 큰 컨텍스트 창이 전체 세트를 더 잘 흡수할 수 있다고 생각하지만, "이 요인을 격리한 통제된 실험은 아직 수행하지 않았다"고 직접적으로 밝히고 있습니다.

단 하나의 벤치마크입니다. "이 결과는 엄격한 다단계 벤치마크인 AppWorld에서 검증되었지만, 단 하나의 벤치마크일 뿐입니다." 더 광범위한 벤치마크와 실제 배포는 현재 진행 중인 작업으로 언급되어 있습니다.

검색 자체도 불완전함을 인정하고 있습니다. "현재 우리의 검색은 코사인 유사도(cosine similarity)로 가이드라인의 순위를 매기는데, 이는 특정 작업에 어떤 가이드라인이 도움이 될지 완벽하게 예측하지 못한다는 것을 보여주었습니다." 다음 단계로 학습된 선택기(learned selector)가 언급되었습니다. 즉, 다소 투박한 선택 방식에도 불구하고 curated-retrieval 수치를 달성했다는 의미입니다.

매우 약한 모델은 대상에서 제외됩니다. "최소한의 역량 기준선 미만에서는 자체 정제(self-distillation)가 유의미한 신호를 만들어내지 못합니다."

종합해 보면, 연구 결과의 방향성은 잘 뒷받침되고 있지만, 구체적인 수치는 이 벤치마크와 이 방법에 국한된 것입니다. 이 비율을 여러분의 시스템이 달성할 수 있는 수치로 그대로 인용하지 마십시오.

저장만을 문제의 전부로 취급하는 것. 대부분의 메모리 설정은 더 많이 캡처하는 데 최적화되어 있습니다. 이 연구는 캡처는 쉬운 절반에 불과하며, 작업당 무엇이 주입되는지가 정확도와 비용 모두를 결정한다고 말합니다.

컨텍스트 비용이 저렴해졌다고 해서 모든 것을 주입하는 것. 저렴한 것이 무료는 아닙니다. 여기서는 비용이 +51%에서 +78%까지 증가했으며, 더 약한 모델의 경우 더 많은 컨텍스트가 오히려 결과를 악화시켰습니다.

더 큰 모델은 도움이 덜 필요할 것이라고 가정하는 것. 한계에 도달한 모델들도 신뢰성 지표에서는 여전히 의미 있는 향상을 보였습니다. 대표 정확도 지표는 이를 가렸지만, 엄격한 지표는 이를 드러냈습니다.

평균적인 성공 사례로만 메모리를 평가하는 것. TGC는 전반적으로 메모리의 이점을 과소평가했습니다. 에이전트가 "대체로 올바르다"면, 메모리가 해결해 주는 것은 에이전트가 실패하는 변형 케이스일 수 있으며, 이것이 바로 SGC가 측정하는 것입니다.

한 모델에서 효과가 없었다고 해서 메모리가 작동하지 않는다고 결론 내리는 것. 저자들은 자신들의 데이터로부터 그러한 결론을 도출하는 것을 명시적으로 거부합니다.

이 연구를 실무에 적용할 때의 교훈은 "더 적게 저장하라"가 아닙니다. 메모리 레이어가 선택할 수 있어야 하고, 안정적인 핵심(core)을 유지해야 하며, 정리(pruning)가 가능해야 한다는 것입니다. 복용량은 설정할 때 한 번 결정하는 것이 아니라, 모델과 작업별로 내리는 결정이기 때문입니다.

메모리를 핵심(core)과 꼬리(tail)로 나누십시오. 항상 주입되는 작고 신뢰도 높은 세트와, 작업별로 검색되는 작업 관련 항목을 조합하십시오. 이는 더 약한 모델에서 정확도와 비용 모두를 잡은 구성이며, 캐싱이 가능하게 유지되는 구성입니다.

프롬프트 캐싱이 작동하도록 핵심 영역을 안정적으로 유지하십시오. 항상 켜져 있는 부분이 단계 전반에 걸쳐 바이트 단위로 동일하다면 비용 할인 혜택을 받을 수 있습니다. 이를 무심코 재정렬하면 캐싱 혜택이 사라집니다.

여러분의 모델에서 두 가지 복용량을 모두 테스트해 보십시오. 여러분의 작업에서 전체 세트와 핵심+검색 구성을 비교 측정해 보십시오. 이 연구의 결론은 모델마다 답이 다르다는 것입니다.

엄격한 지표를 측정하십시오. 단순히 완료된 작업 수만 세지 말고, 동일한 작업의 모든 변형이 얼마나 자주 통과하는지 측정하십시오. 성능 향상이 두드러진 곳이 바로 여기입니다.

가이드라인 품질이 중요한 요인으로 언급되었으므로 정리(prune)하십시오. 잘못되거나 오래된 항목은 무해한 것이 아닙니다. 좋은 항목들과 함께 주입되어 악영향을 미칩니다.

이를 위해서는 하나의 어시스턴트 내부에 메모리가 쌓이게 두는 대신, 검사하고 편집할 수 있는 곳에 메모리를 두어야 합니다. 그것이 바로 MemoryLake입니다. 에이전트가 MCP나 API를 통해 읽어오는 메모리 레이어로, 불투명하게 커지는 덩어리가 아니라 개별적이고 편집 가능한 항목으로 구성되어 있어 복용량 조절을 가능하게 만듭니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 도구 전반에 걸쳐 하나의 자격 증명만 사용하면 됩니다.

2단계: 첫 번째 메모리 업로드

연구의 가이드라인 세트와 유사한 형태로 항목을 작성하십시오. 가능하면 행동 중심의 단일 주장 형태로 작성합니다(성공한 것, 피해야 할 것, 이전 시도를 실패하게 만든 예외 상황 등). 포함할 만한 범주는 다음과 같습니다.

두 번 이상 수정한 사항. 정의상 이는 가장 신뢰도가 높은 핵심 항목입니다.

실패 모드 및 이를 피하는 방법. 연구의 성과는 주로 이전에 실패했던 변형 케이스를 해결하는 데서 나왔습니다.

임의적인 것처럼 보이는 제약 조건. 속도 제한, 순서 요구 사항, 문서와 다르게 작동하는 API 등.

이미 배제된 사항. 어떤 결과물에도 포함되지 않는 범주이자, 새로운 에이전트가 매번 다시 제안하는 사항.

3단계: AI 및 에이전트 연결

사용하는 도구들을 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw 등 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽을 수 있습니다.

세 가지 솔직한 한계가 있습니다. MemoryLake는 이 연구에 참여하지 않았으며, 위의 백분율 수치 중 어느 것도 MemoryLake에 대한 주장이 아닙니다. 결과는 저자들의 자체 벤치마크와 방법에 따른 것입니다. MemoryLake는 사용자나 에이전트가 작성한 내용을 보관하므로 품질은 입력에 달려 있습니다. 또한 모델의 역량 자체를 바꾸지는 않습니다. 에이전트의 남은 실패 요인이 안내를 통해 해결될 수 있는 종류가 아니라면, 더 나은 메모리도 이를 해결할 수 없습니다.

"더 많은 컨텍스트"가 더 이상 기본 해결책이 되지 않습니다. 더 약한 모델의 경우, 더 많은 컨텍스트가 오히려 결과를 악화시켰습니다. 선택이 핵심 수단입니다.

신뢰성이 주시해야 할 지표가 됩니다. 한계에 도달한 모델을 포함하여 모든 등급에서 엄격한 모든 변형 측정치가 대표 정확도보다 더 크게 움직였습니다.

비용이 메모리 도입을 반대하는 논거가 되지 못합니다. 한 모델에서는 토큰 +5%로 +16.1%p의 성과를 냈고, 나머지는 안정적인 핵심 영역에 프롬프트 캐싱을 적용하면 됩니다.

모델 교체는 재조정(re-calibration) 작업이 됩니다. 크기만으로 역량 등급을 예측할 수 없으므로, 모델을 변경하면 적절한 복용량도 함께 변경될 수 있습니다.

정리(Pruning)가 성능 향상 활동이 됩니다. 가이드라인 품질은 모델이 어떤 패턴에 속할지 결정하는 요인 중 하나로 언급되었습니다. 따라서 오래된 항목을 삭제하는 것은 단순한 정리가 아니라 실제 성능 개선 작업입니다. 토큰 측면의 이야기는 메모리 레이어로 토큰 사용량 줄이기에서 다룹니다.

신뢰도 높은 작은 핵심 영역부터 시작하십시오. 추가하는 것이 도움이 된다는 것을 증명할 수 있을 때만 크기를 키우십시오.

그 외의 모든 것은 작업별로 검색하십시오. 개선 여지가 없는 모델의 경우, 몇 개의 관련 항목이 전체 세트보다 더 나은 결과를 냅니다.

항상 켜져 있는 접두사를 바이트 단위로 안정되게 유지하십시오. 캐싱 가능 여부가 비용 감당 여부를 결정합니다.

여러분의 작업에서 A/B 테스트를 실행하십시오. 여러분의 워크로드에서 전체 세트와 큐레이션된 세트를 비교해 보십시오. 연구의 핵심 발견은 바로 답이 보편적이지 않다는 것입니다.

평균이 아닌 전부 아니면 전무(all-or-nothing) 방식으로 점수를 매기십시오. 안내가 빛을 발하는 곳은 바로 신뢰성입니다.

날짜를 기록하고 삭제하십시오. 오래된 항목도 함께 주입됩니다.

변화가 없는 결과를 메모리가 쓸모없다는 증거로 해석하지 마십시오. 저자들은 성과가 없었던 단 하나의 사례에 대해 세 가지 가능한 설명을 제시했으며, 어느 하나로 단정 짓지 않았습니다.

메모리를 모델 외부에 두십시오. 이 연구에서는 가중치가 업데이트되지 않았습니다. 이것이 바로 이 접근 방식이 "도입 비용이 저렴하고 테스트한 8개 모델 전반에 걸쳐 이식성이 뛰어난" 이유였습니다. 이식성은 메모리를 외부에 유지함으로써 얻을 수 있는 특성입니다. 이에 대한 일반적인 내용은 지속성 메모리가 의미하는 것에서 다룹니다.

기억해야 할 가치 있는 발견은 저자들이 섹션 제목으로 정한 것입니다. "메모리는 단순히 축적되는 것이 아니라 조절되어야 한다." 개선 여지가 있는 강력한 모델은 자체 정제된 전체 가이드라인 세트를 사용했습니다. 반면 더 약한 모델은 압축된 핵심 영역과 작업별 검색을 결합했을 때 더 나은 성능을 보였으며, 토큰을 +51% 대신 단 +5%만 사용하고도 이를 달성했습니다. 한 모델은 측정 가능한 변화를 보이지 않았으며, 저자들은 단 하나의 벤치마크를 근거로 그 이유를 설명하는 것을 의도적으로 거부했습니다.

여러분의 에이전트 관점에서는 세 가지 습관으로 이어집니다. 안정적인 항상 켜져 있는 핵심 영역과 검색된 꼬리 영역을 분리하고, 평균적인 성공보다는 신뢰성을 측정하며, 정리를 성능 관리의 일부로 취급하는 것입니다. 그리고 메모리 자체를 검사하고 편집할 수 있는 곳에 두십시오. "얼마나 많이"는 모델을 바꿀 때마다 돌려야 하는 다이얼이지, 한 번 켜고 끝내는 스위치가 아니기 때문입니다.