[논문 리뷰] Proactive Memory Agent — 에이전트가 잊기 전에 기억이 개입해야 한다

Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents

Yifan Wu, Lizhu Zhang, Yuhang Zhou, Mingyi Wang, Bo Peng, Serena Li, Xiangjun Fan, Zhuokai Zhao (2026)- arXiv preprint

한 줄 요약

장기 작업 에이전트에서 메모리는 “어디에 저장할 것인가”보다 언제 행동 루프에 끼어들 것인가가 더 중요해진다.

Meta AI의 이 논문은 그 문제를 behavioral state decay라고 부른다. 에이전트가 초반에 본 요구사항, 실패한 시도, 환경 제약, 아직 끝나지 않은 하위 목표를 나중에 더 이상 행동에 반영하지 못하는 현상이다. 정보가 컨텍스트 안에 남아 있어도, 다음 행동을 실제로 제약하지 못하면 기억은 없는 것과 비슷하다.

LinkedIn에서 공유된 요약글도 이 지점을 잘 짚었다. 이 논문의 핵심은 “메모리를 더 많이 저장하자”가 아니라, 필요한 순간에만 기억을 다시 활성화하는 별도 memory agent를 붙이자는 주장이다.

1. 문제: 긴 컨텍스트가 있어도 에이전트는 잊는다

장기 작업 에이전트의 실패는 단순히 “토큰이 부족해서 과거가 잘렸다”로만 설명되지 않는다.

실제로는 이런 일이 자주 생긴다.

초반: 사용자가 "이 파일은 건드리지 말라"고 말함
중반: 에이전트가 다른 버그를 고치다가 그 파일을 수정함
 
초반: 특정 명령이 이미 실패했고 원인도 확인함
후반: 비슷한 명령을 다시 실행하며 같은 실패를 반복함
 
초반: 인증 상태나 사용자의 등급을 도구로 확인함
후반: 사용자의 주장만 믿고 정책을 잘못 적용함

논문은 이런 현상을 behavioral state decay라고 정의한다.

여기서 중요한 포인트는 “정보가 저장되어 있는가”와 “정보가 다음 행동을 제어하는가”가 다르다는 점이다. 긴 컨텍스트 모델을 써도, 과거 정보가 현재 의사결정에서 덜 salient해지면 에이전트는 같은 실수를 반복한다.

그래서 이 논문은 메모리를 storage/retrieval 문제가 아니라 control loop에 대한 intervention 문제로 재정의한다.

2. 핵심 아이디어: action agent 옆에 memory agent를 붙인다

구조는 단순하다.

Action Agent
  - 원래 하던 대로 환경을 관찰하고 도구를 쓰고 다음 행동을 결정한다
  - 모델, 프롬프트, 도구 scaffold는 바꾸지 않는다
 
Memory Agent
  - 별도 프로세스로 action agent 옆에서 실행된다
  - 최근 trajectory와 기존 memory bank를 읽는다
  - 구조화된 memory bank를 업데이트한다
  - 다음 action call 전에 기억을 주입할지, 침묵할지 결정한다

메모리 에이전트가 하는 일은 두 단계다.

Phase 1. Memory bank 관리

논문은 memory bank를 세 종류로 나눈다.

구성요소	역할	예시
status	memory agent만 보는 진행 상태와 리스크	아직 해결 안 된 하위 목표, 열린 이슈
knowledge memory	작업 중 안정적으로 참인 사실	파일 경로, 환경 제약, 사용자/도구로 검증된 사실
procedural memory	시도와 결과	실패한 명령, 효과 있었던 수정, 버그 원인, 진단 결과

중요한 건 이 memory bank가 자유로운 요약문 하나가 아니라는 점이다. memory agent는 memory_save_knowledge, memory_save_procedural, memory_delete, memory_update_status 같은 제한된 operation으로 bank를 관리한다. 그래서 “요약이 점점 뭉개지는 문제”를 줄이고, 요구사항·환경 사실·실패 이력·진단을 분리해서 유지할 수 있다.

Phase 2. 개입 여부 결정

그 다음 memory agent는 두 가지 중 하나를 고른다.

<context_for_action>
  지금 다음 행동 전에 반드시 다시 활성화해야 하는 기억
</context_for_action>
 
또는
 
<no_intervention/>

이 침묵 액션이 중요하다. 항상 기억을 넣으면 토큰과 지연이 늘고, action agent가 이미 알고 있는 내용을 반복해서 오히려 방해할 수 있다. 반대로 너무 적게 넣으면 같은 실패를 반복한다.

즉 이 논문에서 메모리는 “검색 결과를 붙여주는 레이어”가 아니라, 언제 말하고 언제 조용히 있을지를 배우는 정책이다.

3. 실험 결과: pass@1이 실제로 오른다

논문은 두 가지 장기 작업 벤치마크에서 평가한다.

벤치마크	무엇을 보나	behavioral state decay 예시
Terminal-Bench 2.0	터미널에서 파일 확인, 명령 실행, 코드 수정, 디버깅	실패한 명령 반복, 환경 제약 망각, 버그 진단 유실
τ²-Bench	실제 서비스 도메인 기반 대화형 tool-use	정책 조항 망각, 사용자 상태 혼동, 도구 결과보다 사용자 주장 우선

메인 결과는 꽤 직관적이다.

벤치마크	action model	baseline	+ memory	개선
Terminal-Bench 2.0	Claude Sonnet 4.5	37.6%	45.9%	+8.3pp
Terminal-Bench 2.0	Claude Opus 4.6	43.5%	45.9%	+2.4pp
τ²-Bench task-weighted avg.	Claude Sonnet 4.5	55.0%	61.8%	+6.8pp
τ²-Bench task-weighted avg.	Claude Opus 4.6	66.2%	68.7%	+2.5pp

두 가지가 눈에 띈다.

첫째, 약한 action agent에서 개선폭이 크다. Sonnet 4.5 기준 Terminal-Bench에서 +8.3pp, τ²-Bench에서 +6.8pp다.

둘째, 강한 action agent에서도 효과가 사라지지 않는다. Opus 4.6에도 +2.4pp, +2.5pp가 남는다. 이건 memory agent가 단순히 “약한 모델의 추론 능력을 보완하는 조언자”가 아니라, 강한 모델도 겪는 장기 상태 유지 문제를 다룬다는 뜻에 가깝다.

4. ablation: 수동 검색보다 선택적 개입이 중요하다

이 논문에서 가장 중요한 표는 ablation이다. τ²-Bench에서 여러 변형을 비교한다.

방식	memory bank	intervention	macro avg.	micro avg.
Sonnet 4.5 baseline	없음	없음	57.5	55.0
Full memory agent	있음	선택적 reminder / silence	64.3	61.2
Full-bank context	있음	전체 bank를 매번 노출	61.5	58.6
Always inject	있음	매번 reminder 강제	63.5	61.5
Injection-only	없음	trajectory 기반 조언	61.0	60.8
Mem0	ADD memory	vector+BM25 top-10 retrieval	62.1	60.8

여기서 내가 보기엔 세 가지 결론이 나온다.

4.1 전체 memory bank를 노출하는 것만으로는 부족하다

Full-bank context도 baseline보다 낫지만, full memory agent보다 낮다. 즉 “과거 상태를 어딘가에 저장하고 매번 보여주면 되겠지”가 아니다. 현재 행동을 바꿀 만큼 중요한 기억만 골라야 한다.

4.2 항상 주입하는 것도 정답은 아니다

Always inject는 micro average에서는 근소하게 높지만, domain-balanced macro average에서는 full memory agent가 더 좋다. 특히 airline처럼 정책 적용이 중요한 영역에서는 불필요한 reminder보다 정확한 타이밍의 개입이 중요하다.

이건 제품 관점에서 꽤 현실적인 신호다. memory injection은 공짜가 아니다. 토큰, latency, 주의 분산, 과잉 검증 비용이 있다.

4.3 일반 long-term memory와 task execution memory는 다르다

Mem0 비교가 흥미롭다. Mem0는 production memory retrieval 레이어로 유용하지만, 이 논문이 겨냥하는 문제와는 약간 다르다. Mem0는 “관련 memory를 찾아서 제공”하는 데 가깝고, Proactive Memory Agent는 “이 memory가 지금 action loop에 개입해야 하는가”를 결정한다.

그래서 이 논문의 메시지는 Mem0류 메모리를 부정하는 게 아니다. 오히려 다음 구분을 명확히 한다.

Persistent memory
  - 사용자 선호, 장기 개인화, 세션 간 사실 유지
  - 주 질문: 무엇을 저장하고 어떻게 검색할 것인가?
 
Execution-state memory
  - 현재 장기 작업 안의 요구사항, 실패 이력, 진단, 열린 목표 유지
  - 주 질문: 어떤 기억이 지금 다음 행동을 제약해야 하는가?

5. 기억이 도움이 되는 순간들

논문은 qualitative analysis에서 memory intervention이 잘 먹히는 패턴을 정리한다.

메커니즘	memory content	예시
requirement / policy reactivation	작업 요구사항, 도메인 정책	항공 보상 규칙, retail 수정 규칙
environment grounding	런타임 사실, 경로, 도구 제한	Git server setup, 파일 쓰기 실패
failure-loop avoidance	이전 시도와 실패 이유	같은 diagnostic retry 방지
diagnostic carryover	버그 원인, 부정적 신호	regex edge case, SQLite gcov 설정
progress / entity tracking	현재 사용자, 주문, 라인, 브랜치, subgoal	telecom line lookup, 인증 상태

이 표는 실제 agent harness를 만들 때 거의 체크리스트처럼 쓸 수 있다.

내가 특히 중요하게 보는 건 failure-loop avoidance와 diagnostic carryover다. 코드 수정 에이전트가 “이 접근은 실패했다”를 잊는 순간, 비용은 선형이 아니라 반복 루프 형태로 터진다. 같은 테스트를 다시 깨고, 같은 패치를 살짝 바꿔 다시 시도하고, 이미 배제한 가설을 새 가설처럼 다룬다.

이때 필요한 건 벡터 검색으로 과거 로그를 찾는 능력만이 아니다. “지금 이 행동 직전에 그 실패 이력을 다시 보여줘야 한다”는 timing 판단이다.

6. open-weight memory policy도 가능할까?

논문은 추가로 Qwen3.5-27B를 memory agent로 학습시키는 초기 실험도 한다. action agent는 Qwen3.5-122B-A10B로 고정하고, memory agent만 학습한다.

설정	SETA avg. reward	solved	변화
action only, no memory	0.709	56	—
+ Qwen3.5-27B base memory	0.693	54	-0.016
+ SFT memory	0.720	58	+0.011
+ GRPO memory	0.734	58	+0.025

그리고 held-out Terminal-Bench 2.0에서는 action-only 37.6%에서 trained memory agent 41.1%로 오른다.

여기서 중요한 건 base memory agent가 오히려 성능을 떨어뜨린다는 점이다. memory agent를 붙인다고 자동으로 좋아지는 게 아니다. 잘못된 개입은 방해가 된다. SFT는 memory operation을 가르치고, GRPO는 “언제 개입해야 하는가”의 calibration을 개선한다.

즉 memory policy는 학습 가능한 문제지만, 핵심은 저장보다 개입 calibration이다.

7. 실무적으로 어떻게 써먹을 수 있나

이 논문을 agent system 설계로 옮기면, 나는 다음 구조가 꽤 현실적이라고 본다.

Agent run loop
  1. action agent가 관찰/계획/도구 호출을 수행한다
  2. memory agent가 최근 N step을 읽는다
  3. memory bank를 업데이트한다
     - requirements
     - environment facts
     - failed attempts
     - successful fixes
     - active subgoals
  4. 다음 action 직전에 intervention 여부를 결정한다
  5. 필요한 경우에만 짧은 reminder를 transient context로 넣는다

여기서 memory bank는 “예쁜 요약문”보다 operation log에 가까워야 한다.

[requirement] public API response schema must remain backward-compatible
[environment] tests run with Python 3.14 and node 22
[failed_attempt] changing parser regex broke Korean title extraction
[diagnosis] failure is caused by MDX interpreting numeric JSX props
[open_subgoal] verify deployed URL after GitHub Actions completes

그리고 reminder는 길면 안 된다.

Before editing the MDX, remember: numeric-looking Paper props must be strings.
The previous build failed when year was passed as {2026}.

이 정도면 action agent의 행동을 바꾸기에 충분하다. 반대로 전체 memory bank를 매번 넣으면 컨텍스트가 지저분해지고, “중요한 기억”의 신호가 다시 묻힌다.

8. 한계와 조심할 점

좋은 논문이지만, 바로 제품에 넣을 때는 몇 가지를 조심해야 한다.

8.1 frontier memory agent 비용

메인 실험은 Claude Opus 4.6을 memory agent로 쓴다. action agent 옆에 강한 memory agent를 매 step 또는 자주 호출하면 비용과 지연이 커진다. 논문도 open-weight memory policy 실험을 넣은 이유가 여기에 있다.

실무에서는 모든 step에서 돌리기보다 다음 조건을 섞는 게 나을 수 있다.

테스트 실패 직후
같은 파일/명령을 반복해서 만질 때
state-changing tool call 직전
요구사항 위반 가능성이 높은 edit 직전
task가 일정 step 이상 길어졌을 때

8.2 잘못된 reminder는 독이다

memory agent가 추측을 너무 확신 있게 말하면 action agent를 잘못된 방향으로 밀 수 있다. 논문도 남은 실패가 주로 calibration error라고 설명한다. speculative inference와 verified fact를 memory bank에서 분리해야 한다.

8.3 action agent와 memory agent의 책임 경계

memory agent가 “전략가”가 되어버리면 구조가 흐려진다. 이 논문의 memory agent는 broad advice가 아니라 memory-grounded reminder에 제한된다. 이 제한이 중요하다. 그렇지 않으면 multi-agent supervisor 하나 더 붙인 것과 다르지 않아진다.

9. 제 해석: 메모리는 DB가 아니라 주의 제어 장치다

이 논문을 읽고 가장 강하게 남는 문장은 “memory as intervention”이다.

지금까지 에이전트 메모리를 이야기할 때는 보통 저장소 관점이 강했다.

무엇을 저장할까?
어떤 embedding을 쓸까?
얼마나 오래 보관할까?
어떻게 검색할까?

하지만 장기 작업 에이전트에서는 질문이 하나 더 붙는다.

이 기억이 지금 다음 행동을 바꿔야 하는가?

이 질문이 없으면 memory는 그냥 더 긴 노트다. action loop에 들어오는 순간과 문장을 제어할 수 있어야 진짜 행동 상태가 된다.

개인적으로는 이 방향이 agent harness 설계에서 꽤 중요해질 것 같다. 특히 코딩 에이전트, 브라우저 에이전트, 업무 자동화 에이전트처럼 “여러 번 보고, 실행하고, 실패하고, 다시 고치는” 시스템에서는 long-term memory보다 먼저 run-local execution memory가 필요하다.

장기 기억은 사용자와 제품의 연속성을 만든다. 하지만 실행 기억은 한 작업 안에서 에이전트가 같은 실수를 반복하지 않게 만든다. 이 둘은 같은 memory라는 단어를 쓰지만, 설계 목표가 다르다.

정리

Proactive Memory Agent 논문은 에이전트 메모리 논의를 한 단계 구체화한다.

문제는 behavioral state decay: 중요한 실행 상태가 다음 행동에 영향을 주지 못하는 현상이다.
해결은 별도 memory agent: action agent는 그대로 두고, memory agent가 구조화된 memory bank를 관리한다.
핵심은 선택적 개입: 모든 기억을 노출하지 않고, 필요할 때만 짧은 reminder를 주입한다.
결과는 유의미하다: Terminal-Bench 2.0에서 Sonnet 4.5 기준 +8.3pp, τ²-Bench에서 +6.8pp 개선된다.
실무적 메시지는 분명하다: 메모리는 저장소가 아니라 주의와 행동을 다시 연결하는 제어 장치로 봐야 한다.

다음에 agent memory를 설계한다면 “무엇을 기억할까?”에서 멈추면 안 된다. 더 중요한 질문은 이것이다.

이 기억은 언제, 어떤 형태로, 다음 행동을 바꾸기 위해 다시 등장해야 하는가?

참고 자료

LinkedIn discussion: Fixing Behavioral State Decay in Agents with Memory Grounding
Paper: Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents
PDF: arXiv:2607.08716
Code: yifannnwu/proactive-memory-agent