배경 및 맥락
에이전트 시스템이 web navigation, software engineering, document workflow 같은 장기 과제를 맡기 시작하면서 병목은 단발성 reasoning보다 반복 학습 부재로 이동하고 있다. 기존 agent는 같은 유형의 실수를 여러 세션에서 반복하고, exploration 과정에서 얻은 교훈을 구조화해 다음 작업에 재사용하지 못하는 경우가 많았다. 이 한계 때문에 실제 운영 환경에서는 모델 자체보다 memory 설계가 성능 차이를 크게 만들기 시작했다.
Google Research의 ReasoningBank는 이 문제를 해결하려는 접근이다. 핵심은 실행 궤적 전체를 저장하는 대신, 성공과 실패에서 공통적으로 재사용 가능한 reasoning pattern을 뽑아 structured memory로 축적하는 것이다.
핵심 내용
공식 소개에 따르면 ReasoningBank는 각 메모리 항목을 title, description, content 형태의 구조화된 reasoning asset으로 저장한다. 에이전트는 작업 전에 관련 memory를 불러와 컨텍스트에 넣고, 실행 후에는 LLM-as-a-judge를 활용해 trajectory를 평가해 success insight와 failure reflection을 새 메모리로 추가한다. 중요한 차별점은 실패 경험을 적극적으로 학습 자원으로 쓴다는 점이다.
Google은 이를 memory-aware test-time scaling(MaTTS)과 결합했다. Parallel scaling에서는 여러 trajectory를 비교해 더 강한 전략을 추출하고, sequential scaling에서는 단일 trajectory 내부의 점진적 개선 과정을 메모리로 환원한다. Gemini-2.5-Flash 기반 평가에서 ReasoningBank는 WebArena에서 memory-free baseline 대비 성공률 8.3%p 향상, SWE-Bench-Verified에서 4.6%p 향상, 그리고 SWE-Bench-Verified에서 task당 거의 3 step 절감 효과를 보였다. MaTTS를 더하면 WebArena에서 추가 3%p 개선과 0.4 step 절감이 이어졌다.
경쟁 구도 / 비교
기존 memory 접근은 trajectory memory처럼 모든 행동을 보관하거나, 성공 사례만 요약하는 workflow memory에 가까웠다. ReasoningBank는 두 방식 모두가 tactical foresight를 잃거나 failure signal을 버린다고 본다. 이 관점은 최근 agent engineering이 컨텍스트 길이 확장보다 memory quality와 retrieval structure를 더 중시하는 흐름과 맞닿아 있다.
또한 test-time scaling을 단순 다중 샘플링이 아니라 운영 중 경험 축적 장치로 해석한 점이 중요하다. 이는 agent product의 차별화가 base model뿐 아니라 runtime memory loop와 evaluation loop에서 발생할 수 있음을 시사한다.
의미
산업적으로는 persistent agent의 경쟁력이 이제 reasoning token을 얼마나 더 쓰느냐보다, 그 토큰 사용 결과를 다음 작업의 자산으로 얼마나 잘 보존하느냐로 이동하고 있다. 향후 enterprise agent 플랫폼은 vector retrieval보다 strategy memory와 failure replay를 핵심 기능으로 내세울 가능성이 크다.
실무적으로는 agent 운영팀이 memory schema, retrieval 정책, 실패 반성 기록, self-judge 품질 검증을 제품 일부로 다뤄야 한다. 좋은 agent는 더 길게 생각하는 agent가 아니라, 생각한 결과를 구조화해 다음 실행을 바꾸는 agent가 될 가능성이 높다.