AI 에이전트 메모리는 실제로 성능을 향상시킬까 — 작업 순서가 답을 결정하는 이유 (2026)

이전 연구들이 놓친 두 가지 축

이 연구는 새로운 방식을 제안하기보다는 기존 방식을 재평가하는 구조입니다. 저자들은 기존의 두 가지 메모리 기반 방식, 즉 "온라인 작업 스트림으로부터 학습하고 텍스트 메모리 뱅크를 유지함으로써 시간이 지남에 따라 개선되는" 에이전트를 가져와 다음 두 가지 축으로 평가를 확장했습니다. 저자들은 이를 "(1) 분산을 정량화하기 위해 여러 번의 실행을 포함하는 것, (2) 작업 순서의 영향을 조사하기 위해 작업을 무작위로 섞는 것"이라고 설명합니다.

이 두 가지는 대부분의 실증적 머신러닝에서 표준적인 관행이지만, 기존 연구에서는 모두 빠져 있었습니다. 이것이 방법론적 기여의 전부이며, 결과를 바꾸기에 충분했습니다.

발견 1: 메모리가 추가되기 전부터 측정에 노이즈가 있었습니다

저자들의 첫 번째 관찰 결과는 다음과 같습니다. "에이전트 평가는 복잡한 환경과 다단계 작업에서 본질적으로 노이즈가 심하며, 그 위에 자가 개선 루프를 쌓으면 이 노이즈가 더욱 증폭될 수 있습니다."

이 문장은 두 부분으로 나뉘어 있으므로 두 번 읽어보시기 바랍니다. 다단계 작업에 대한 에이전트 벤치마크는 그 자체로 노이즈가 심합니다. 동일한 에이전트, 동일한 작업이라도 실행이 다르면 점수가 달라집니다. 여기에 자가 개선 루프가 더해지면 이 노이즈가 섞인 신호를 가져와 메모리 뱅크에 다시 피드백하고, 이것이 다음 실행에 영향을 미칩니다. 노이즈는 단순히 지속되는 것이 아니라 누적됩니다.

자체 평가를 수행하는 모든 이들에게 실질적인 시사점은 다음과 같습니다. 메모리를 켰을 때와 껐을 때를 단 한 번만 실행하여 비교하는 것은 거의 아무것도 말해주지 않습니다. 수치가 한 번 올라갔다고 해서 메모리 변경 사항을 배포한 적이 있다면, 이 논문은 왜 그것이 증거가 될 수 없는지 설명해 줍니다.

발견 2: 작업 순서가 결과에 큰 영향을 미치고 있었습니다

두 번째 관찰 결과는 매우 놀랍습니다. "에이전트의 개선은 작업 순서에 크게 의존합니다. 이전 연구들은 종종 암묵적인 커리큘럼을 부과하는 기본 순서를 채택하여, 이것이 성공을 위한 숨겨진 전제 조건으로 작용했습니다."

암묵적인 커리큘럼이란 기본 작업 순서가 우연히 쉬운 것에서 어려운 것으로 진행되었거나, 유용한 교훈을 주는 작업을 이를 필요로 하는 작업보다 먼저 배치했음을 의미합니다. 에이전트는 그 순서대로 학습하여 개선되었습니다. 하지만 순서를 섞으면 개선 효과가 줄어듭니다. 즉, 메모리 뱅크는 아무도 의도적으로 설계하거나 보고하지 않은 '가르침의 순서' 덕을 보고 있었던 것입니다.

이것은 새로운 옷을 입은 익숙한 실패 모드입니다. 사기도 아니고 태만도 아닙니다. 이 분야가 아직 초기 단계이기 때문에 아무도 통제할 생각을 하지 못한 통제되지 않은 변수일 뿐입니다.

그들이 테스트하고 부분적으로만 확인한 가설

저자들은 부정적인 결과에서 멈추지 않았습니다. 그들은 메모리 뱅크를 직접 검사하고 다음과 같은 가설을 세웠습니다. "작업 및 환경의 미흡한 명세(underspecification)가 이러한 취약성의 원인이다." 즉, 작업과 환경이 에이전트에게 무엇이 올바른 결과인지 충분히 명확하게 알려주지 않았기 때문에 에이전트가 모호하거나 잘못된 교훈을 기록한다는 것입니다.

그 후 그들은 "상세한 루브릭(평가 기준) 및 환경 피드백과 같이 더 나은 명세를 가능하게 하는 정보를 메모리 구축 프로세스에 통합"함으로써 이를 테스트했습니다.

그 결과는 초록에서 가장 정직한 문장으로 나타납니다. "이러한 추가 정보가 이전 실험에서의 성능 저하를 부분적으로 메워주기는 하지만, 여전히 상당한 격차가 존재하며, 이는 규명되지 않은 다른 요인들이 이러한 취약성에 기여하고 있음을 시사합니다."

'부분적으로', '상당한 격차가 존재함', '규명되지 않은 다른 요인들'. 이는 연구팀이 자신들의 해결책을 과대포장하지 않으려는 태도를 보여주며, 이 논문을 신뢰할 수 있는 이유이기도 합니다.

이 경계를 명확히 하는 것이 헤드라인보다 더 중요합니다.

이 연구는 전체 카테고리가 아니라 두 가지 방식을 연구했습니다. 이번 재평가는 두 가지 메모리 기반 자가 개선 방식만을 대상으로 합니다. 이는 종합적인 조사(survey)가 아니며, 에이전트 메모리에 대한 모든 접근 방식이 취약하다고 주장하지 않습니다.

이 연구는 사람이 개입하지 않고 스스로 메모리를 작성하는 에이전트에 관한 것입니다. 구체적인 연구 대상은 인간의 개입(human in the loop) 없이 온라인 작업 스트림으로부터 텍스트 메모리 뱅크를 유지하는 에이전트입니다. 이는 사람이 프로젝트의 제약 조건을 적어두거나 팀이 파일에 컨벤션을 유지하는 것과는 다릅니다. 기록된 컨텍스트가 더 이상 유용하지 않다는 말은 어디에도 없습니다.

이는 신뢰성에 대한 비판이지, 반박이 아닙니다. 발견된 사실은 보고된 성능 향상이 순서에 의존적이고 노이즈가 심하다는 것이지, 메모리가 아무런 효과가 없다는 것이 아닙니다. 혜택이 작업 순서에 의존하는 방식이라도 특정 순서 하에서는 여전히 혜택이 존재합니다.

특정 제품을 언급하지 않습니다. 이것은 벤치마크상의 연구 방법론입니다. 이를 특정 벤더의 메모리 기능에 대한 판결로 해석하는 것은 논문이 의도하지 않은 과도한 해석이며, 다른 누구도 그렇게 해석해서는 안 됩니다.

또한 이와 반대되는 결과를 가리키는 연구들도 존재합니다. 불과 나흘 전에 발표된 연구에서는 자체 정제된 가이드라인을 주입함으로써 얻는 실질적인 이득을 측정했으며, 그 크기는 모델에 따라 달랐습니다. 이는 AI 에이전트에게 얼마나 많은 메모리를 주어야 할까에서 다룬 바 있습니다. 두 가지 모두 사실일 수 있습니다. 성능 향상은 존재하지만, 보고된 향상 폭은 기존 문헌이 암시하는 것보다 덜 안정적이라는 점입니다. 이 둘을 조화시키는 방법은 더 나은 평가이며, 이것이 바로 이 논문이 요구하는 바입니다. 즉, "여러 번의 실행에 걸친 결과를 보고하고 까다로운 조건에서 스트레스 테스트를 수행하는 것"입니다.

"에이전트 메모리는 작동하지 않는다." 논문은 그렇게 말하지 않으며, 저자들은 그런 말을 하지 않기 위해 각별히 신경 쓰고 있습니다. 두 가지 방식, 하나의 평가 프로토콜, 순서 의존적인 성능 향상이 핵심입니다.

"그러니 메모리는 건너뛰고 더 큰 컨텍스트 창을 사용해야 한다." 이는 이 논문의 영향을 받지 않는, 그 자체의 답을 가진 다른 질문입니다. 이 내용은 왜 긴 컨텍스트가 메모리가 될 수 없는가에서 다루었습니다.

"해결책은 루브릭이다." 루브릭과 환경 피드백이 도움이 되긴 했지만 격차를 완전히 메우지는 못했습니다. 이를 해결책으로 취급하는 것은 여전히 상당한 격차가 존재한다는 문장을 무시하는 것입니다.

"벤치마크는 쓸모없다." 정반대입니다. 이 논문은 여러 번 실행하고 순서를 섞는 등 올바르게 실행할 때 벤치마크가 얼마나 유용한지 보여주는 증거입니다.

"에이전트가 스스로 메모리를 관리하게 두면 알아서 해결될 것이다." 이것이 바로 이 논문이 가장 직접적으로 무너뜨리는 믿음입니다. 사람이 개입하지 않는 자가 개선 루프는 평가 노이즈를 메모리 뱅크로 증폭시킵니다.

"우리 내부 A/B 테스트에서 상승 효과가 있었으니 괜찮다." 만약 그 A/B 테스트가 고정된 작업 순서로 단 한 번만 실행된 것이라면, 이 논문은 왜 그것이 아직 증거가 될 수 없는지 구체적으로 설명하고 있습니다.

논문은 두 가지 권장 사항으로 끝을 맺으며, 이것이 바로 실행 가능한 부분입니다. 첫 번째는 평가입니다. 여러 번의 실행 결과를 보고하고 까다로운 조건에서 스트레스 테스트를 수행하는 것입니다. 두 번째는 이를 바탕으로 무언가를 구축하려는 사람들에게 더 흥미로운 내용입니다. "미흡한 명세에 대한 우리의 발견은 효과적인 인간의 감독을 가능하게 하여 에이전트가 예측 불가능한 방식으로 실패하는 것을 방지하는 시스템과 인터페이스를 요구합니다."

인간의 감독, 인터페이스, 메모리 구축에 기록되는 명세. 종합해 보면, 권장 사항은 "에이전트에게 메모리를 덜 주라"는 것이 아니라, 에이전트가 감독 없이 기록하는 블랙박스로 메모리를 방치하지 말라는 것입니다.

실제 환경에서 작동하는 설정을 위해 다음 세 가지가 필요합니다.

분산과 섞인 순서로 평가하세요. 최소 3번 실행하고 작업 순서를 변경해 보세요. 순서를 섞었을 때 성능 향상이 사라진다면, 기존의 작업 순서가 일종의 커리큘럼 역할을 했다는 사실을 알게 된 것입니다.

축적하기 전에 명세하세요. 논문에서 제시한 부분적인 해결책은 메모리 구축에 더 나은 작업 및 환경 명세를 제공하는 것이었습니다. 실제로 이는 "올바르게 완료됨"이 어떤 모습인지 기록해 두는 것을 의미하며, 그래야 에이전트가 정제한 교훈이 올바른 기준을 가질 수 있습니다.

사람이 읽고 편집할 수 있도록 메모리를 유지하세요. 무엇이 기록되었는지 볼 수 없다면, 향후 50번의 실행에 영향을 미칠 모호하거나 잘못된 항목을 잡아낼 수 없습니다.

이 마지막 포인트가 바로 MemoryLake가 구축된 핵심 철학입니다. 즉, 무작위로 늘어나기만 하는 불투명한 저장소가 아니라, 사용자가 읽고 수정하고 삭제할 수 있는 개별 항목으로서의 메모리입니다. 설정은 3단계로 이루어집니다.

1단계: API 키 생성

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

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

논문에서 에이전트에게 부족하다고 지적한 명세를 각 항목당 하나의 주장만 담긴 짧은 항목으로 작성합니다:

반복되는 작업에서 "올바름"이 의미하는 바. 줄글로 작성된 루브릭입니다. 이는 논문에서 도움이 된다고 밝혀낸 유일한 카테고리입니다.

환경이 알려주지 않는 제약 조건. 속도 제한(rate limits), 순서 요구 사항, 최근 행이 없는 스테이징 데이터베이스 등 에이전트가 스스로 유추할 수 없는 환경 피드백입니다.

이유와 함께 이미 배제된 접근 방식. 작업 순서가 섞인 상태에서 에이전트는 의존할 커리큘럼이 없습니다. 기록된 거부 사유가 우연한 순서를 대체합니다.

두 번 이상 수정한 사항. 사람이 두 번 말해야 했다면, 감독 없는 루프는 결코 이를 스스로 도출해내지 못했을 것입니다.

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

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

세 가지 솔직한 한계가 있으며, 첫 번째가 이 글의 핵심입니다. MemoryLake는 이 연구의 일부가 아니었으며, 연구에서 설명하는 취약성을 해결하지 않습니다. 큐레이션된 메모리 레이어가 자가 개선 에이전트를 신뢰할 수 있게 만든다는 주장은 어디에도 없습니다. 저자들은 다른 요인들이 여전히 규명되지 않았다고 말하며, 이는 모든 저장소에 적용됩니다. 검사 가능한 레이어가 제공하는 것은 저자들이 요구하는 인간의 감독 기능과, 회귀 테스트에서 문제를 발견하는 대신 잘못된 항목을 즉시 수정할 수 있는 능력입니다. 이는 오직 귀하 또는 귀하의 에이전트가 기록한 내용만 보관합니다. 또한 이는 평가 하네스(evaluation harness)가 아니므로, 여러 번 실행하는 규율은 직접 구현해야 합니다.

단일 실행 비교는 더 이상 결과로 인정되지 않습니다. 가장 적은 비용으로 가장 큰 효과를 볼 수 있는 변화입니다. 최소 3번 실행하고 순서를 섞으세요.

"AI 에이전트가 학습했다"는 주장은 직접 확인해야 하는 대상이 됩니다. 메모리를 열고 항목들을 읽어보며 에이전트가 정제한 교훈이 실제로 올바른지 확인하세요.

루브릭 작성이 엔지니어링 작업이 됩니다. 미흡한 명세가 원인 중 하나로 지목되었습니다. 올바른 결과가 무엇인지 명세하는 것은 더 이상 단순한 문서화 작업이 아닙니다.

순서 독립성이 디자인 목표가 됩니다. 에이전트가 특정 작업 순서에서만 개선된다면, 그것은 메모리 시스템이 아니라 커리큘럼을 가진 것입니다.

축적하는 것보다 가지치기(pruning)가 더 중요해집니다. 노이즈 속에서 기록된 잘못된 항목은 올바른 항목들과 함께 주입됩니다. 이는 왜 RAG가 메모리가 아닌가의 이면에 있는 일반적인 문제입니다.

최소 세 번 실행하세요. 실행 간의 분산은 원래 연구에서 누락되었던 두 가지 축 중 하나였습니다.

의도적으로 작업 순서를 섞으세요. 성능 향상이 순서에 의존한다면, 배포하기 전에 이를 파악해야 합니다.

가장 좋은 수치가 아니라 분포(spread)를 보고하세요. 논문의 요구 사항을 한 줄로 요약한 것입니다.

메모리를 작성하기 전에 루브릭을 작성하세요. 메모리 구축에 더 나은 명세를 제공하는 것이 측정 가능한 도움이 되었던 개입이었습니다.

에이전트가 기록한 내용을 읽어보세요. 수동 검사는 저자들이 처음에 미흡한 명세 가설을 찾아낸 방법이었습니다.

항목에 날짜를 기록하고 오래된 항목은 삭제하세요. 노이즈가 있는 상황에서는 오래되고 잘못된 항목이 비어 있는 저장소보다 더 나쁩니다.

두 가지 방식만으로 카테고리 전체의 결과를 단정 짓지 마세요. "메모리는 작동한다"도 아니고, "메모리는 작동하지 않는다"도 아닙니다.

설계 단계부터 인간의 개입(human in the loop)을 유지하세요. 논문의 마지막 권장 사항은 효과적인 인간의 감독을 가능하게 하는 시스템과 인터페이스입니다. 이에 대한 구체적인 형태는 AI 메모리란 무엇이고 무엇이 아닌가에서 논의되었습니다.

AI 에이전트 메모리는 성능을 향상시킬까요? 이 논문의 증거에 따르면, 때로는 그렇지만 보고된 것보다는 적으며, 두 가지 저명한 방식에서 측정된 차이의 상당 부분은 아무도 통제하지 않은 작업 순서로 거슬러 올라갑니다. 저자들은 이것이 의미하는 바에 대해 신중한 태도를 취합니다. 에이전트 평가는 자가 개선 루프를 추가하기 전부터 노이즈가 심하고, 루프는 그 노이즈를 증폭시키며, 더 나은 명세가 도움이 되긴 하지만 여전히 상당한 격차가 존재하고, 다른 요인들은 여전히 규명되지 않은 채로 남아 있습니다.

이것이 실무자들에게 변화를 주는 부분은 아키텍처라기보다는 주로 규율(discipline)에 가깝습니다. 비교 테스트를 한 번 이상 실행하세요. 순서를 섞으세요. 에이전트가 스스로 유추하기를 바라기보다 올바른 결과가 어떤 모습인지 기록해 두세요. 그리고 사람이 실제로 읽을 수 있는 곳에 메모리를 보관하세요. 논문 자체의 결론도 더 똑똑한 무인 루프가 아니라 인간의 감독을 요구하고 있기 때문입니다. 검사하고 수정할 수 있는 메모리는 스스로 개선되는 메모리보다 약한 주장처럼 보일 수 있지만, 이번 증거에 따르면 그것이 바로 유효한 주장입니다.