EvoArena - Tracking Memory Evolution for Robust LLM Agents in Dynamic Environments

J. Xu, Q. Li, J. Wu, Y. Lan, S. S. Li, H. Zhou, B. Jiang, L. Wang, J. Wang, A. T. Luu, C. Xiong, H. W. Park, B. Hooi, and Z. Hu, "EvoArena: Tracking Memory Evolution for Robust LLM Agents in Dynamic Environments," arXiv:2606.13681, 2026.

저자

Jundong Xu와 Qingchuan Li가 공동 1저자다. 두 사람은 모두 싱가포르국립대학교(NUS) 소속으로, 각각 LLM 추론과 에이전트 메모리 쪽 연구를 해왔다. 시니어 라인에는 NUS의 Bryan Hooi와 Zhiyuan Hu가 있고, 밖으로는 Caiming Xiong(전 Salesforce AI Research SVP, 현 Recursive Superintelligence 공동창업자)과 MIT의 Hae Won Park이 자문 역할로 함께했다. Caiming Xiong의 참여는 논문 각주에 "Work Partially Done at Salesforce AI Research"라고 명시되어 있다.

사실상 이 논문은 NUS 그룹이 주도하되, 싱가포르경영대, 워싱턴대, UPenn, UCL, NTU, MIT까지 여러 기관의 공동 작업으로 완성된 벤치마크 논문이다. 참여 기관이 많은 만큼 세 종류의 벤치마크(터미널, 소프트웨어, 개인화 대화)를 동시에 설계하고 검증하는 데 분업이 가능했다.

배경

대부분의 LLM 에이전트 벤치마크는 정적 스냅샷을 가정한다. WebArena, SWE-bench, GAIA 모두 한번 만들어진 환경이 평가 내내 변하지 않는다. 그런데 실제 배포 환경은 그렇지 않다. API 인터페이스가 바뀌고, 코드베이스에 새 마일스톤이 추가되고, 사용자의 취향이 조금씩 달라진다. 에이전트가 "지금 버전"을 정확히 파악하고, 이전 버전에서 유효했던 절차 중 어떤 것이 아직 통하는지, 어떤 것이 더 이상 맞지 않는지를 구별할 수 있어야 진정한 신뢰성을 얻는다.

기존 벤치마크는 이 "버전 인식 능력"을 전혀 측정하지 않는다는 점이 이 논문이 출발한 자리다.

EvoArena: 세 종류의 진화

EvoArena는 세 도메인의 "진화하는 버전 체인"으로 구성된다.

Terminal-Bench-Evo는 터미널 워크플로우가 버전마다 달라지는 환경이다. 원본 Terminal-Bench의 89개 태스크를 각각 최대 5개 버전의 체인으로 확장했다. 버전마다 같은 목표("hello.html을 push하고 포트 8080에서 서빙")를 유지하되, 배포 방식, 경로, 권한 정책, 브랜치 규칙이 순차적으로 바뀐다. 최종 데이터셋은 441개 태스크 인스턴스(초기 버전 포함), 평균 체인 길이 4.96.

SWE-Chain-Evo는 실제 GitHub 레포지토리에서 연속 커밋 기간을 뽑아 밀스톤 체인을 구성했다. 12개 레포지토리, 50개 체인, 493개 체인-스텝 인스턴스(고유 밀스톤 145개). 평균 체인 길이 9.86. 나중 밀스톤은 앞선 밀스톤에서 작성된 코드를 참조하므로, "이전에 통과시킨 테스트를 깨뜨리지 않으면서 새 요구사항을 구현"하는 능력을 직접 측정한다.

PersonaMem-Evo는 대화 속에서 사용자 취향이 점점 변해가는 시나리오다. 10개 페르소나 각각에 대해 평균 597턴짜리 긴 대화 이력을 생성하고(중앙값 174.7K 토큰), 그 안에서 특정 취향이 어떻게 진화했는지를 묻는 4지선다 문제 505개를 구성했다. 문제 유형은 단일 패턴 전이, 다중 패턴 합성, 충돌 해소, 시간적 궤적 예측의 네 가지다.

세 도메인 공통으로 스텝 정확도(개별 버전/문제 단위)와 체인 정확도(체인 전체를 모두 맞혀야 정답) 두 가지 지표를 쓴다. 체인 정확도는 한 고리라도 틀리면 0이기 때문에 훨씬 가혹하다.

EvoMem: 메모리를 패치 이력으로

기존 에이전트 메모리 시스템의 공통 약점은 **상태 붕괴(state collapse)**다. 새 정보가 들어오면 이전 메모리를 덮어써버린다. 이전 버전에서 유효했던 절차가 새 버전 정보에 의해 지워지고, "왜 그 절차가 거기서 맞았는가"라는 맥락도 함께 사라진다.

EvoMem은 이를 패치 이력(patch history) 개념으로 해결한다. 기본 메모리 업데이터는 건드리지 않고, 메모리가 의미 있게 바뀌는 시점마다 패치 하나를 append-only 로그에 추가한다. 패치 하나에는 다음 필드가 들어간다:

\[p_t = \langle \tau_t, C_t^-, C_t^+, r_t, z_t, e_t \rangle\]

\(\tau_t\)는 타임스탬프, \(C_t^-\)와 \(C_t^+\)는 업데이트 전후의 메모리 내용, \(r_t\)는 업데이트 이유, \(z_t\)는 변경 요약, \(e_t\)는 업데이트를 촉발한 맥락(태스크 피드백, 환경 스냅샷 등)이다.

추론 시에는 최신 메모리(\(M_T\))에서 먼저 검색하고, 쿼리가 시간적 변화나 덮어쓰인 상태에 의존한다고 판단되면 패치 이력에서 관련 패치를 추가로 가져온다:

\[c(q) = \text{Concat}(R_\text{mem}(q, M_T),\; R_\text{patch}(q, P_{1:T}))\]

EvoMem은 메모리 형식에 무관하다. 논문에서는 네 가지 에이전트에 각기 다른 방식으로 이식했다: 터미널 에이전트 Terminus2, 코딩 에이전트 OpenHands, 대화 메모리 에이전트 A-Mem, 스킬 메모리 에이전트 Memento-Skill.

결과

핵심 발견 세 가지를 짚는다.

첫째, 현재 에이전트는 진화 환경에서 고전한다. GPT-5.5도 Terminal-Bench-Evo 체인 정확도 31.8%에 그친다. 스텝을 개별적으로 푸는 것과 "버전 체인 전체를 연속으로 맞히는 것"의 격차가 크다는 사실이 진화 환경의 어려움을 보여준다.

둘째, EvoMem은 체인 레벨에서 더 크게 이긴다. 스텝 정확도 향상보다 체인 정확도 향상이 일관되게 더 크다. Terminal-Bench-Evo에서 스텝 +2.4% 대 체인 +6.1%, SWE-Chain-Evo에서 스텝 +0.5% 대 체인 +2.9%가 그 예다. 연속된 태스크를 일관성 있게 처리하는 능력이 패치 이력에서 나온다는 의미다.

셋째, EvoMem은 기존 벤치마크에서도 잘 통한다. GAIA에서 평균 +6.5%, LoCoMo에서 +3.3%. 진화 환경 전용 트릭이 아니라, 메모리 업데이트 이력을 추적하는 게 일반적으로 유익하다는 증거다.

모델별로 보면 GPT-5.5가 Terminal-Bench-Evo에서 최고 스텝 정확도(62.8%)를 내지만 토큰 소비가 505M으로 압도적으로 높다. Gemini-3.1-Pro(53.8%)와 GLM-5.1(51.8%)은 토큰 사용이 평균 아래(80M 내외)다. 토큰 예산이 성능을 보장하지 않는다는 점이 Terminal-Bench-Evo에서 뚜렷하게 드러난다.

메커니즘 분석

어떨 때 EvoMem이 실제로 도움이 되는가? 논문은 세 도메인에서 각각 메커니즘을 분석한다.

Terminal-Bench-Evo에서 핵심 변수는 패치 uptake, 즉 에이전트가 검색된 패치의 내용을 이후 추론이나 명령에 실제로 반영하는지다. 패치를 가져왔지만 활용하지 않은 경우 개선폭이 +2.6%인 반면, 패치를 실제로 명령어에 녹여 쓴 경우 개선폭이 +8.3%로 뛴다. EvoMem은 단순히 컨텍스트를 늘리는 게 아니라, 에이전트가 "무엇이 바뀌었는가"를 정확히 포착하고 이를 행동에 옮길 때 빛난다.

SWE-Chain-Evo에서는 회귀(regression) 감소가 핵심이다. EvoMem 추가 후 Pass-to-Pass 테스트 실패율이 평균 9.09%에서 6.32%로 떨어진다. 나중 밀스톤 작업 중 이전 밀스톤에서 확립한 행동을 깨뜨리는 빈도가 줄어든다.

PersonaMem-Evo에서는 시간적 궤적 질문과 다중 패턴 합성 질문에서 EvoMem 효과가 두드러진다(각 +5.2%). 이 둘은 오래 전에 언급된 선호도 상태를 복원해야 하는 문제 유형이다. 반면 갈등 해소, 단일 패턴 전이에서는 개선이 미미하거나 소폭 하락하는데, 이쪽은 증거 확보보다 "어떤 선호도가 우선인가"를 판단하는 능력이 요구되기 때문으로 해석한다.

회고

저자들이 직접 밝힌 한계다. EvoArena는 터미널 워크플로우, 소프트웨어 레포지토리, 장기 선호도라는 세 영역에 집중한다. 로보틱스, 과학 워크플로우, 다중 에이전트 협업처럼 물리적·도메인적으로 다른 진화 환경은 아직 다루지 못한다. EvoMem 자체도 패치 검색이 잘못 작동할 때 -- 예컨대 GPT-5.5로 PersonaMem-Evo 시간적 궤적 문제를 풀 때 -- 구형 상태를 불필요하게 끌어올려 혼선을 주기도 한다.

장기 메모리 이력이 누적될수록 개인 정보 관리와 접근 제어 문제도 중요해진다. 논문이 이 지점을 Broader Impact 섹션에서 명시적으로 언급하는 건 성실한 태도다.

정리

• EvoArena는 LLM 에이전트를 "버전이 바뀌는 환경"에서 평가하는 최초의 다중 도메인 벤치마크다. 터미널, 소프트웨어, 대화 세 도메인 모두에서 체인 정확도 개념을 도입했다.
• EvoMem은 메모리 업데이트를 패치 이력으로 남겨 에이전트가 "무엇이 왜 바뀌었는가"를 추론할 수 있게 한다. 기존 메모리 시스템에 비침습적으로 얹힌다.
• 현재 최강 모델(GPT-5.5)도 EvoArena 체인 정확도는 30% 안팎에 머문다. 배포 환경의 비정상성은 아직 충분히 해결되지 않은 열린 문제다.