Agent에 메모리를 붙이는 시스템이 점점 늘고 있고, 저마다 쓸수록 똑똑해진다고 말한다. 그런데 정면으로 답하는 경우가 드문 질문이 하나 있다: 컨텍스트 창도 커지고 있다는 것이다. 모델이 한 번에 읽을 수 있는 양이 늘어날수록, 미리 저장해 둔 메모리는 얼마나 가치가 있을까?

EvoMemBench는 바로 이 곡선에 숫자를 붙였다. 15가지 메모리 방법을 하나의 평가 프로토콜에 넣고 보고한 바는 이렇다: 컨텍스트 예산이 16K에서 128K로 커지면, 무메모리 기준선 대비 최고 메모리 이득은 +14.5점에서 +8.5점으로 축소되고, 128K 구간에서는 이미 기준선 아래로 떨어진 메모리 방법도 있다.

내가 관심 있는 것은 이 곡선이 백본을 바꿔도 성립하는가, 특히 가장 저렴한 등급으로 바꿔도 그런가이다. 이유는 실용적이다: 이런 규모의 실험(128K 구간은 긴 컨텍스트를 반복해서 재생해야 한다)은 플래그십 가격으로는 도저히 돌릴 수 없어서, 백본을 고를 때 먼저 가격에서 한 차례 걸러진다; 그리고 내가 주목하는 배포 환경에서 물량을 주로 돌리는 것도 저렴한 등급이다. 그래서 논문의 전체 설정을 복제하는 대신, 축소된 질문을 사전 등록했다: 게이트웨이에서 구할 수 있는 가장 저렴한 GPT 등급에서, 단일 실행 환경 안에서, 이득이 예산에 따라 축소되는 방향이 여전히 존재하는가?

결론부터 놓는다: 방향은 있다. 내가 돌린 최고 이득은 16K의 +18.0점에서 128K의 +6.0점으로 축소됐고, 두 메모리 방법 모두 같은 방향으로 좁혀졌다. 그러나 논문에서 가장 날카로운 장면 — 128K에서 메모리가 기준선 아래로 떨어지는 일 — 은 나타나지 않았다: 검색 메모리의 이득은 0이 됐을 뿐이고, 절차적 메모리는 여전히 기준선 위에 있었다. 종합 판정은 PARTIAL이며, 증거 경계는 글 끝에 있다.

먼저 증거 등급부터 구분하자

이 논문(arXiv:2605.18421, 홍콩과기대 광저우 등 기관)은 2026년 5월에 v1이 나왔고 10월 30일에 v3로 업데이트됐으며, 새 논문이 아니다. 이 논문이 한 일은 “Agent의 기억력이 실제로 도움이 되는가”라는 문제에 좌표계를 세운 것이다: 한 축은 메모리의 작용 범위(단일 작업 안 / 작업 간), 다른 축은 내용 유형(지식 / 실행)으로 네 개의 사분면을 이루고; 여섯 개 데이터셋이 Table 2 기준 총 2,954개의 평가 표본으로 네 사분면에 나뉘어 들어가며; 15가지 메모리 방법이 여섯 개 계열로 나뉘어 통합 프로토콜 아래에서 긴 컨텍스트 기준선과 비교된다. 항상 함께 붙여야 할 조건이 하나 있다: 논문의 모든 메모리 방법은 하나의 백본 DeepSeek-V3.2를 공유한다는 것, 즉 그 순위는 이 백본에서의 순위이며, 백본을 떼어 놓고 순위를 논하는 것은 의미가 없다.

논문의 여덟 가지 결론 중 이 글과 직접 관련된 것은 세 개 반이다. 긴 컨텍스트 기준선은 여전히 강해서 지식 유지와 수정에서 1위를 차지하고(Finding 1); 메모리의 병목은 검색이 아니라 수정에 있어서, 방법들은 정보를 저장하는 데는 능하지만 증거가 바뀌었을 때 낡은 지식을 고치는 데는 서투르며(Finding 2); 한 층 더 깊이 들어가면, 병목은 저장한 정보를 재사용 가능한 지식으로 만드는 것이지 더 많이 저장하는 것이 아니고(Finding 6); 절차적 메모리가 실행형 작업에 가장 잘 맞으며(Finding 4); 난이도 반전도 있다: 쉬운 문제에서는 메모리가 음의 이득이고, 어려운 문제에서는 메모리만이 점수를 낸다(Finding 5) — 이 반 개는 내가 측정하지 못했고, 이유는 글 끝에 설명한다.

이상은 전부 저자 보고이다. 내 복제가 건드린 것은 그중 하나뿐이다: Finding 3의 이득—예산 곡선, 그것도 한 사분면의 한 환경에서만.

내 복제 설계: 가장 저렴한 백본으로, 곡선 하나만 측정한다

이 실험은 사전 등록했고, 설정은 실행 전에 전부 확정했으니 아래와 같다. 부분집합은 네 사분면 중 InEp-Exec(한 에피소드 안에서의 실행 작업)을 택하고, 그중 Gorilla File System 환경 하나만 돌렸다 — 다회전 도구 호출 작업 묶음으로, 작업 성공 여부는 공식 runner 내장 검사기가 판정하므로 추가 심판이 필요 없다. 세 가지 조건: A0 무메모리 기준선; A1은 BM25 검색 메모리; A2는 절차적 메모리 ACE. 컨텍스트 예산은 두 구간, 16K와 128K. 셀당 50개씩 총 300개 episode, 공식 프로토콜 파라미터(함수 호출 모드, 긴 컨텍스트 노이즈, 메모리 범위)는 공식 스크립트 그대로다.

백본은 제3자 OpenAI 호환 게이트웨이가 gpt-6-luna로 표기한 엔드포인트를 쓰고, 전 과정에서 바꾸지 않았다. 여기서 먼저 밝혀야 할 신원 경계가 하나 있다: 표기는 게이트웨이가 붙인 것이며, 실제로 서빙되는 모델은 내 쪽에서는 독립적으로 확인할 수 없다. 따라서 아래의 자체 수치는 모두 “이 표기 엔드포인트”에 대해서만 성립하고, 논문의 DeepSeek 기준과는 다른 변형 기준으로, 같은 표가 아니다.

논문 설정과의 차이와 버전 세부 사항은 실행 전에 실험 계획에 적어 두었고, 먼저 세 가지를 밝힌다:

• 표본 수: v3와 저장소가 일치하며, 환경당 50개. 이 논문 v1의 Table 2에는 환경당 200개로 적혀 있었으나 v3에서 50개로 바뀌었고, 공식 저장소가 실제로 배포한 것도 50개이며, 내가 돌린 것이 바로 그 50개다. 이는 동시에 환경당 50개가 논문 자체의 평가 규모라는 뜻이기도 해서, 뒤에 나오는 ±14점의 통계 구간은 논문의 단일 환경 수치도 똑같이 짊어지고 있다.
• 절차적 메모리의 구현이 바뀌었다. 원래 계획은 ReasoningBank였으나, 저장소에 함께 배포된 그 구현은 다른 공급업체의 임베딩 키에 강하게 의존하는데 내게는 게이트웨이 접속 하나뿐이라, 같은 절차적 계열이면서 논문의 또 다른 헤드라인 방법인 ACE로 교체했다. 같은 방법이 아니므로, 판정할 때는 계열 방향으로만 봐야 하고 방법끼리 일대일로 대응시켜 봐서는 안 된다.
• 메모리 조건의 전송 계층 한 겹이 바뀌었다. 저자들이 메모리 방법용으로 준비한 호출 채널은 다른 클라우드 업체의 배치 인터페이스인데, 그 OpenAI 호환 백엔드는 메모리 유형을 거부했다; 나는 로컬 작업 사본에서 전송 계층만 교체했고, 프로토콜·프롬프트·메모리 로직·절단·채점은 전부 고정 커밋의 공식 코드를 썼다. 덤으로, 상류에 원래 있던 비대칭 하나를 밝혀 둔다: 저자들의 OpenAI 백엔드는 A0 조건의 호출에 temperature 1을 붙이지만, 메모리 조건이 타는 경로에는 이 파라미터를 전달하지 않는다 — 나는 이를 그대로 두었고, 맞추려고 코드를 고치지 않았으므로, 세 조건 사이에는 메모리 외에도 이 생성 파라미터 차이 한 겹이 더 끼어 있다.

결과: 축소는 재현됐고, 기준선 하회는 나타나지 않았다

여섯 셀의 성공률은 아래와 같다(셀당 n=50, 공식 성공 판정):

조건	16K	128K	이득(같은 구간의 A0 대비)
A0 무메모리	38%(19/50)	44%(22/50)	—
A1 BM25 검색	42%(21/50)	44%(22/50)	+4.0 → 0.0
A2 ACE 절차형	56%(28/50)	50%(25/50)	+18.0 → +6.0

두 메모리 모두 이득이 예산이 커질 때 축소됐고, 최고 이득은 +18.0에서 +6.0으로 줄었다. 논문이 DeepSeek 기준, 네 개 환경에서 보고한 값은 +14.5 → +8.5이다(중간이 단조롭지는 않다: 64K 구간에서 +7.8까지 내려갔다가 128K 구간에서 +8.5로 다시 올랐다). 규모는 같은 자리수이고 방향은 일치한다 — 그러나 이 두 묶음의 숫자는 같은 표의 셀이 아니므로 나란히 놓고 크기를 비교할 수는 없다.

128K 구간의 세부 사항은 따로 짚을 만하다. 논문은 이 구간에서 이미 기준선 아래로 떨어진 방법이 있다고 했지만, 내 결과에서는 없었다. BM25의 이득은 정확히 0으로 증발했고(44% 대 44%), “하락”의 문턱에 멈춰 서서 넘지 않았다; ACE는 여전히 기준선보다 6점 위에 있었다. 이 결과는 논문의 조항을 확인도 반박도 하지 않는다: 나는 15가지 방법 중 2가지, 4개 환경 중 1개만 측정했고, 게다가 고른 것이 스펙트럼의 양끝이다 — 가장 단순한 검색 메모리와, 논문의 실행 사분면에서 가장 강한 부류인 절차적 메모리; 논문이 128K에서 기준선 아래로 떨어졌다고 지목한 MemAgent와 MemoBrain은 둘 다 포함되지 않았으므로, “떨어지지 않았다”의 일부는 선택 자체가 결정한 것이다. 말할 수 있는 것은, 이 부분집합과 이 백본에서는 “128K에서 메모리가 음의 자산이 되는” 일은 일어나지 않았고, 일어난 것은 “저렴한 메모리가 먼저 무력해지는” 일뿐이라는 것이다 — 검색 메모리의 이득이 예산에 가장 민감하고, 절차적 메모리의 이득이 더 오래 버틴다. ACE의 12점 축소를 뜯어 보면: 절반은 기준선 자체가 강해진 데서 왔고(A0가 문제 3개를 더 맞혔다), 나머지 절반은 ACE의 하락에서 왔다(3개를 덜 맞혔다) — 두 변화 모두 문제 3개 수준의 크기라, 합치면 그림이 되지만 떼어 놓으면 이야기가 되지 않는다. 이 셀은 논문의 Finding 4와도 같은 방향이다: 세 조건 중 유일한 절차적 방법인 ACE가 두 구간 모두 가장 강했다.

통계적으로는 찬물을 끼얹어야 한다: 셀당 표본이 50개뿐이라 한 셀의 95% 구간은 대략 ±14점이고, 4점 차이는 문제 두 개에 불과하다. 다행히 여섯 셀은 같은 50개 문제를 돌렸으므로 쌍을 지어 승패 뒤집힘을 볼 수 있다: 16K 구간에서 ACE는 기준선보다 9개를 더 맞히고 0개를 덜 맞혔다; 하지만 축소 폭 자체를 쌍대 bootstrap에 넣으면, ACE의 그 12점에 대한 95% 구간 하한은 정확히 0 위에 걸리고, BM25의 축소는 0과 구분할 수 없다. 따라서 이 글의 방향 판정은 서술적인 것으로 둔다: 그림은 논문과 같은 방향이고, ACE라는 한 조건에는 쌍대 증거가 받쳐 주지만; 어느 한 셀만 놓고 승패를 다투는 것은 노이즈 속에서 결론을 찾는 일이다.

메모리가 내야 할 임대료: 비용 해부

논문은 점수를 보고했고, 각 방법의 총 token도 보고했다 — 다만 그것은 작업 실행과 메모리 모듈을 합친 총량이다(부록의 효율 표 참조). 메모리 모듈 자체의 호출을 따로 떼어 내지는 않았다. 이번에는 용도별로 나눠서, 논문에 없는 수치 한 묶음을 얻었다.

300개 episode는 총 약 1,517만 개의 입력 token과 54만 개의 출력 token을 소모했다. ACE는 자신의 100개 episode에서, 메모리 모듈 — 매 회전 뒤의 성찰과 경험 큐레이션 호출 — 이 266만 token을 먹었다: ACE 자신의 입력만 놓고 보면 메모리 모듈이 약 36.5%를 차지하고; 전체 300개 episode의 총입력에 펼치면 17.6%이다. 그 출력 token은 무메모리 조건의 약 7.4배인데, 성찰과 큐레이션이 모두 생성형 호출이기 때문이고; 출력 단가는 입력의 6배라, 금액으로 따지면 이 7.4배가 입력 쪽 비중보다 청구서를 더 아프게 한다. 다시 말해, ACE가 입력 token 100개를 쓸 때마다 약 36.5개는 작업 자체를 진전시키는 데가 아니라 메모리를 유지하는 데 쓰였다. BM25는 메모리 유지 호출을 만들지 않는다: 인덱싱과 검색은 모두 로컬에서 이뤄지고 모델을 호출하지 않는다; 다만 검색해 온 텍스트는 여전히 컨텍스트에 들어가야 하므로, 그 몫의 입력 token은 자기 작업 청구서에 기록된다 — BM25가 아끼는 것은 유지 호출이지 컨텍스트가 아니다.

규모감은 논문 자체의 효율 표와 대조해 볼 수 있다: DeepSeek 기준, 128K 구간에서 ACE의 총 token은 무메모리 기준선의 약 1.8배이고, 늘어난 부분은 ACE 총량의 약 43.5%를 차지한다 — 여기서 떼어 낸 36.5%와 같은 규모이다(기준은 다르다: 논문은 총 token 대 기준선의 비율이고, 내 것은 ACE 입력 내부의 용도 분해이다).

이 수치들은 “메모리가 가치가 있는가”를 따지는 계산법을 바꾼다. +18점의 이득은 공짜가 아니다: ACE 한 조건의 임대료만 해도 자체 입력의 3분의 1을 넘고, 게다가 출력량은 일곱 배가 넘는다; 그리고 이 임대료는 예산 구간과 무관하게 존재한다 — 128K 구간에서 이득이 +6점으로 축소됐을 때도 ACE의 메모리 모듈은 거의 같은 양의 token을 먹었다(16K 구간 134만, 128K 구간 132만). 메모리 방법을 평가할 때는 메모리 자체의 호출을 방법 비용에 넣어야 하며, 인프라 안에 숨겨서 한꺼번에 넘겨서는 안 된다. Luna 등급의 공개 가격(입력 0.20달러, 출력 1.20달러, 모두 100만 token당)으로 환산하면, 이번 300개 작업의 총가격은 약 3.7달러이다(게이트웨이 계정의 실제 과금은 그쪽 기준이며 내게는 보이지 않는다) — 싼 것은 백본이고, 비싼 것은 구조다.

측정하지 않은 부분

• Finding 5(난이도 반전)는 측정하지 않았다. 사전 등록에는 보조 프로브를 남겨 두어, 저자가 제공한 난이도 등급으로 CrossEp-Know 사분면에서 “쉬운 문제에서는 메모리가 음수, 어려운 문제에서는 양수”를 측정하려 했다. 프로브는 파일럿 단계까지 갔을 때 게이트웨이 계정의 한도가 소진돼서 내가 중단했고, 판독 가능한 데이터는 얻지 못했다. 따라서 이 글은 Finding 5에 대해 어떤 결론도 내리지 않으며, 위에 등장할 때는 저자 보고로만 다룬다.
• 논문의 긴 컨텍스트 대조(Gemini-3-Flash, GPT-5-mini 등 독점 모델)는 내가 다시 돌릴 수 없어서, 그 점수는 저자 보고로 인용한다.
• 나머지 세 사분면, 다른 열세 가지 방법, 논문의 DeepSeek-V3.2 원래 기준은 모두 이 글의 증거 범위 밖에 있다.

이것은 이 블로그의 이전 Beacon 크로스툴 메모리 실측과 정확히 이어진다. 그때의 결론은: 메모리는 “저장소 자체에서는 도출할 수 없는 지식”에 대해서만 증분을 제공하고, 자동 캡처와 증류 계층은 취약하다는 것이었다. 두 번의 증거 형태는 다르다 — 그때는 단일 시스템을 깊이 팠고, 이번 것은 횡단 평가 프로토콜 아래에서의 부분집합 복제이다 — 그러나 같은 한 가지를 가리킨다: 메모리 이득은 기본으로 존재하는 것이 아니며, 조건들의 함수이다. 이번에 더해진 조건은 예산이다: 컨텍스트가 저렴하고 클수록, 미리 저장해 둔 메모리의 가치는 떨어진다; 먼저 무력해지는 것은 검색만 하는 부류이다.

결론

Agent용 메모리 방안을 고르고 있다면, 이 복제가 뒷받침할 수 있는 사용법은 세 가지뿐이다. 첫째, 이득을 말하기 전에 예산부터 밝혀라: 어떤 메모리 방법이든 내세우는 향상은, 어느 정도 크기의 컨텍스트 예산에서 측정했는지를 물어야 한다. 예산을 한 구간 키우면 이득이 절반 넘게 증발할 수 있다. 둘째, 메모리 모듈 자체의 token을 비용표에 적어라: 생성형 메모리(성찰, 큐레이션, 요약)의 임대료는 자체 입력의 3분의 1을 넘을 수 있고(이번 사례 36.5%), 이득이 축소된다고 함께 줄지 않는다. 셋째, 이런 도구 호출 작업에서는 절차적 메모리(이 사례의 ACE)가 두 구간 모두 더 강하지만, 그 호출 비용을 지불해야 한다; 순수 검색 메모리는 예산이 충분할 때 이득이 가장 먼저 0이 되므로, 예산이 정말로 제한된 환경에만 적합하다. 이 환경을 벗어나면 서둘러 옮겨 붙이지 마라: 논문의 Finding 7은 웹 검색, 체화(embodied) 등 다른 실행 영역에서는 가장 잘 맞는 메모리 형태가 서로 다르다고 보여 준다.

이 벤치마크 자체에 대한 내 판정은 이렇다: Finding 3의 축소 패턴은 엔드포인트를 바꾸고 부분집합으로 줄여도 방향이 여전히 맞아떨어지고, 이것이 이 벤치마크의 가장 유용한 부분이다; 다만 엔드포인트의 신원을 독립적으로 확인할 수 없으므로, 이것은 엔드포인트를 바꾼 탐색적 복제일 뿐 백본을 바꾼 증명은 되지 않는다. 128K에서 기준선 아래로 떨어진다는 더 날카로운 주장은 내 부분집합에서는 나타나지 않았고, 더 많은 방법에 대해서도 성립하는지를 판정하려면 누군가 원래 기준으로 나머지 열세 가지 방법을 끝까지 돌려야 한다. 그것은 이 글의 결론이 아니라, 이 글이 남기는 숙제다.

---

증거 경계: 논문의 수치는 모두 arXiv:2605.18421 v3 저자 보고이다; 자체 수치는 위의 부분집합, 세 조건 두 예산 구간과 게이트웨이 표기 엔드포인트에 대해서만 성립하며, 단일 실행이다. 전체 실행 기록(여섯 셀의 원시 카운트, token 분해, 편차 등록과 통계적 한계 포함), 문제별 데이터와 쌍대 분석 스크립트는 이 글과 함께 공개됐다(글 앞부분의 publicRepository 참조). 파일별 SHA256SUMS로 검증할 수 있다.