한눈에 보기

Google Research가 2026년 4월 21일 ReasoningBank: Enabling agents to learn from experience를 공개했습니다. 핵심은 AI 에이전트가 작업 중 겪은 성공과 실패를 단순 로그로 쌓아두는 게 아니라, 다음 작업에 다시 쓸 수 있는 추론 전략으로 정리해 메모리에 저장한다는 점입니다.

쉽게 말하면 "이번에는 왜 맞았고, 왜 틀렸는지"를 에이전트가 실행 후에 정리하고, 다음 실행 때 그 전략을 꺼내 쓰는 구조입니다. 장기 실행 에이전트가 같은 실수를 반복하는 문제를 정면으로 다룹니다.

이번 발표 뭐가 나왔나

Google Research Blog에 따르면 ReasoningBank는 성공한 경험과 실패한 경험에서 일반화 가능한 reasoning strategy를 추출하는 agent memory framework입니다. 관련 논문은 ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory이고, Google은 ICLR paper로 소개했습니다.

배경은 현실적입니다. AI 에이전트가 단발성 데모를 넘어 지속적으로 작업을 처리하는 역할로 가면, 이전 상호작용에서 얻은 힌트를 버리거나 같은 전략적 실수를 반복하는 문제가 생깁니다.

기존 메모리 방식은 모든 행동 trajectory를 자세히 저장하거나, 성공한 workflow만 요약하는 쪽이 많았습니다. Google은 이런 방식이 더 높은 수준의 transferable reasoning pattern과 실패에서 나오는 counterfactual signal을 놓친다고 봤습니다.

ReasoningBank의 메모리 아이템은 Title, Description, Content로 구성됩니다. 단순 로그가 아니라 제목, 설명, 실제 추론 내용이 들어간 작은 전략 카드에 가깝습니다.

핵심 변화 3가지

1. 실패 경험을 메모리 재료로 쓴다

ReasoningBank에서 가장 중요한 부분은 실패를 적극적으로 다룬다는 점입니다. 실패한 실행에서 함정, 피해야 할 조건, 다음번에 먼저 확인해야 할 체크포인트를 뽑아 예방형 lesson으로 저장합니다.

Google은 예시로 Load More 버튼을 누르는 절차만 외우는 대신, 무한 스크롤 함정을 피하기 위해 현재 page identifier를 먼저 확인하는 전략을 배울 수 있다고 설명했습니다.

2. 실행 전에는 꺼내 쓰고, 실행 후에는 다시 쌓는다

ReasoningBank의 workflow는 닫힌 루프입니다.

작업 전에는 현재 문제와 관련 있는 memory를 검색해 context에 넣습니다. 작업 후에는 LLM-as-a-judge로 trajectory를 self-assess하고, 성공했다면 success insight를, 실패했다면 failure reflection을 추출합니다. 그다음 새 memory를 ReasoningBank에 append합니다.

이 구조는 모델 자체를 매번 재학습시키는 방식과 다릅니다. 테스트 타임에 외부 memory를 활용해 행동을 바꾸는 쪽에 가깝습니다.

3. MaTTS로 탐색 경로까지 메모리 품질 개선에 쓴다

논문과 블로그는 MaTTS, 즉 memory-aware test-time scaling도 소개합니다. 보통 test-time scaling은 추론 때 더 많은 계산을 써서 답을 잘 찾게 하는 방식인데, ReasoningBank에서는 그 과정에서 생긴 여러 탐색 경로를 메모리 품질 개선에 다시 씁니다.

parallel scaling은 같은 query에 대해 여러 trajectory를 만들고 성공/실패 경로를 비교해 더 단단한 전략을 뽑습니다. sequential scaling은 한 trajectory 안에서 점진적으로 추론을 다듬으며 생기는 중간 insight를 memory item으로 저장합니다.

본문 이미지

ReasoningBank 작동 구조 이미지

실제로 뭐가 달라지나

일반 사용자

지금의 AI 에이전트는 종종 "아까 틀린 걸 왜 또 하지?" 싶은 행동을 보입니다. ReasoningBank식 메모리가 잘 붙으면, 사용자는 같은 설명을 반복해서 하지 않아도 되는 쪽에 가까워집니다.

특히 웹 탐색, 예약, 문서 정리, 반복 업무 자동화처럼 절차와 예외가 많은 작업에서 체감이 클 수 있습니다.

개발자

개발자 입장에서는 에이전트 메모리를 단순 대화 기록 저장소로 볼지, 실행 전략 저장소로 볼지의 차이가 커집니다. ReasoningBank는 raw trajectory보다 압축된 reasoning memory를 강조합니다.

구현 관점에서는 retrieval, trajectory 평가, memory extraction, memory append가 하나의 loop로 묶입니다. 이 loop를 잘못 설계하면 나쁜 memory도 계속 쌓입니다. 그래서 실제 제품에서는 memory 품질 관리가 핵심입니다.

창업자

AI 에이전트 제품을 만드는 팀이라면 "우리 에이전트가 고객사 환경에서 시간이 지날수록 나아지는가?"라는 질문을 피하기 어렵습니다.

ReasoningBank의 방향은 product memory를 개인화 기록이나 환경 설정에만 두지 않고, 실패 회피 전략과 업무별 decision rationale까지 확장하는 쪽입니다. 다만 그대로 제품에 넣으려면 오래된 규칙의 폐기, 서로 충돌하는 memory 정리, 잘못된 self-judgement로 생긴 나쁜 memory 제거가 필요합니다.

좋은 점

첫째, 실패를 학습 재료로 명시적으로 다룹니다. 실제 업무 자동화에서 실패는 비싼 데이터입니다. 실패 로그를 디버깅용으로만 남기는 게 아니라, 다음 행동을 바꾸는 전략으로 바꾸려는 방향이 좋습니다.

둘째, 구조가 이해하기 쉽습니다. retrieve before action, self-assess after interaction, extract insight, append memory라는 흐름은 복잡한 학습 파이프라인 없이도 에이전트 시스템 설계에 참고하기 좋습니다.

셋째, 평가 수치가 구체적입니다. Google은 Gemini-2.5-Flash 기반 WebArena와 SWE-Bench-Verified 평가에서 ReasoningBank without scaling이 memory-free baseline보다 WebArena 성공률을 8.3%, SWE-Bench-Verified 성공률을 4.6% 높였다고 설명했습니다. SWE-Bench-Verified에서는 task당 거의 3 execution steps도 줄었습니다.

MaTTS를 추가하면 WebArena에서 ReasoningBank 대비 성공률이 3% 더 올라가고, step도 0.4 줄었다고 합니다.

아쉬운 점

아직은 연구 프레임워크에 가깝습니다. 메모리를 계속 append하는 단순 전략은 실험에는 깔끔하지만, 실제 서비스에서는 중복 memory, 오래된 memory, 서로 충돌하는 memory를 어떻게 다룰지가 남습니다.

LLM-as-a-judge를 쓰는 self-assessment도 운영 환경에서는 조심스럽게 봐야 합니다. Google은 ReasoningBank가 judgment noise에 꽤 robust하다고 설명하지만, 특정 도메인에서는 잘못된 반성이 오히려 나쁜 습관으로 굳을 수 있습니다.

그리고 이 방식은 모델이 가중치 수준에서 새로 학습한다기보다, 외부 memory를 통해 다음 실행의 context와 전략을 바꾸는 구조입니다. "스스로 진화한다"는 표현은 제품 설명에서 과장하지 않는 편이 낫습니다.

내 생각

ReasoningBank가 흥미로운 이유는 에이전트를 사람처럼 포장해서가 아닙니다. 지금 에이전트가 못하는 부분, 즉 경험을 구조화해서 다음 행동에 반영하는 기본기를 공학적으로 다루기 때문입니다.

앞으로 에이전트 경쟁은 모델 성능만이 아니라 어떤 기억을 남기고, 어떤 기억을 버리며, 언제 꺼내 쓰는가로 옮겨갈 가능성이 큽니다. RAG가 지식 검색의 기본 부품이 됐다면, ReasoningBank류의 memory는 장기 실행 에이전트의 운영 부품이 될 수 있습니다.

요약 카드 이미지

ReasoningBank 요약 카드

결론

ReasoningBank는 AI 에이전트가 성공 경험뿐 아니라 실패 경험에서도 일반화 가능한 추론 전략을 뽑아 쓰게 만드는 프레임워크입니다. 장기 실행 에이전트가 매번 새로 시작하는 듯 행동하고, 같은 실수를 반복하는 문제를 줄이려는 시도입니다.

아직 실제 서비스에 넣으려면 memory 정리, 품질 평가, 충돌 해결 같은 숙제가 남아 있습니다. 그래도 에이전트 메모리를 "대화 기록 저장"이 아니라 "실행 전략의 축적"으로 바라보게 만든다는 점에서 의미 있는 발표입니다.

한 줄 평

Google ReasoningBank는 AI 에이전트에게 로그북이 아니라, 실패 노트까지 포함한 전략 수첩을 쥐여주는 접근입니다.

참고 출처