구글이 ReasoningBank를 소개한 핵심 메시지는 단순합니다. 에이전트가 매번 처음부터 추론하지 말고, 과거 경험에서 재사용 가능한 추론 전략을 꺼내 쓰게 하자는 것입니다.1 왜 지금 중요하냐면, 많은 팀이 이미 RAG, 대화 기록, 실행 로그를 붙였는데도 에이전트가 같은 유형의 문제에서 계속 비슷한 실수를 반복하고 있기 때문입니다.
이 지점에서 ReasoningBank는 "기억을 더 붙이자"는 얘기보다, "무엇을 저장해야 실제로 더 똑똑해지느냐"는 설계 문제로 읽는 편이 맞습니다. 문서를 더 잘 찾는 것과, 일을 푸는 방식을 축적하는 것은 다른 문제입니다.
RAG도 로그도 있는데, 왜 에이전트는 같은 실수를 반복할까
현업에서 흔한 실패는 이렇습니다. 에이전트는 관련 문서를 잘 가져옵니다. 이전 실행 로그도 남아 있습니다. 프롬프트도 여러 번 다듬었습니다. 그런데 비슷한 장애 분석, 비슷한 SQL 수정, 비슷한 고객 응대 케이스에서 성능이 들쭉날쭉합니다.
이유는 세 층이 서로 다르기 때문입니다.
문서는 "무엇이 사실인가"를 담습니다. 로그는 "무슨 일이 있었나"를 남깁니다. 하지만 둘 다 "이 유형의 문제를 풀 때 어떤 사고 절차가 재사용 가능한가"를 깔끔하게 보존하지는 못합니다. ReasoningBank가 노리는 건 바로 이 빈칸입니다.1
이 관점은 최근 메모리 논의와도 맞닿아 있습니다. 메모리는 단순히 더 긴 컨텍스트가 아니라, 무엇을 저장하고 어떻게 꺼낼지 정하는 시스템 설계 문제라는 지적이 반복해서 나옵니다.23 Databricks도 비슷한 문제의식에서, 원시 상호작용 로그(episodic memory)와 거기서 뽑아낸 일반화된 규칙(semantic memory)을 구분해 다뤄야 한다고 설명합니다.3
실무적으로는 먼저 진단이 필요합니다.
문제가 지식 부족인지, 절차 부족인지, 아니면 성공했던 접근을 다시 쓰지 못하는 기억 부족인지. ReasoningBank는 세 번째에 가장 잘 맞습니다.
벡터 검색, ReasoningBank, 파인튜닝 중 어디에 '생각하는 법'을 둘까
이 비교가 중요합니다. 세 방식은 대체재가 아니라 저장 계층이 다릅니다.
벡터 검색은 가장 빠르게 업데이트할 수 있고, 왜 이런 답이 나왔는지도 비교적 추적하기 쉽습니다. 대신 주로 사실, 사례, 문서 조각을 가져오는 데 강합니다. "어떤 정보를 봐야 하는가"에는 좋지만, "어떤 순서로 판단해야 하는가"는 약합니다.
ReasoningBank는 그 중간층입니다. 경험에서 전략을 추출해 저장하고, 새 문제에서 비슷한 전략을 불러옵니다.1 파인튜닝보다 수정이 빠르고, 문서 검색보다 행동 변화가 직접적일 수 있습니다. 무엇보다 규칙이나 전략을 사람이 읽고 검토할 여지가 남습니다. 그 대신 검색이 잘못되면 엉뚱한 전략을 자신 있게 적용할 위험도 같이 생깁니다.
파인튜닝은 행동을 모델 안에 녹여 넣습니다. 특정 형식, 도메인, 응답 스타일을 안정화할 때 강력합니다. 하지만 업데이트 속도가 느리고, 왜 그런 판단을 했는지 해석하기 어렵고, 잘못 학습되면 되돌리기 비용이 큽니다.
여기서 흥미로운 반론도 있습니다. 최근 제안된 reasoning graph는 ReasoningBank 같은 전략 저장보다 더 좁고 구체적인 방식, 즉 "비슷한 질문"이 아니라 "같은 증거 조각을 예전에 어떻게 평가했는가"를 다시 보는 구조를 제안합니다.4 이 연구는 고재사용 환경에서 오류를 47% 줄이고, 복잡한 4-hop QA에서 정확도를 11%포인트 높였다고 보고합니다.4 다만 이건 증거 재사용이 많은 QA 성격의 환경에서 특히 유리한 결과로 읽어야 합니다. 모든 에이전트 업무에 그대로 일반화하긴 이릅니다.
요컨대 선택 기준은 이렇습니다.
사실을 더 잘 가져오고 싶으면 RAG.
반복되는 문제 풀이 패턴을 축적하고 싶으면 ReasoningBank류.
행동 자체를 모델 특성으로 굳히고 싶으면 파인튜닝입니다.
전략 라이브러리는 쉽게 '대규모 헛소리 공장'이 된다
ReasoningBank류 접근은 매력적이지만, 위험도 분명합니다.
첫째, 과잉 일반화입니다. 한 번 통했던 전략이 조건이 다른 문제에도 무분별하게 붙을 수 있습니다. 둘째, 검색 오류입니다. 질문이 비슷해 보여도 실제 제약 조건이 다르면 전략 매칭이 오히려 독이 됩니다. 셋째, 오래된 지혜 문제입니다. 전략은 문서보다 더 빨리 낡을 수 있습니다. 운영 규칙, API, 조직 정책이 바뀌면 "좋았던 사고법"이 바로 위험한 습관이 됩니다.
그래서 메모리 시스템 일반론에서 말하는 관리 원칙이 그대로 중요해집니다. 저장 단위의 정제, 스코프 분리, 갱신 규칙, 만료 정책, 감사 추적입니다.235 ReasoningBank를 붙인다면 최소한 네 가지는 필요합니다.
전략마다 근거 링크를 남길 것.
적용 가능한 태스크 범위를 좁게 정의할 것.
만료일이나 재검증 조건을 둘 것.
고비용 작업에는 사람 검토 트리거를 걸 것.
이 장치가 없으면 "경험에서 학습"이 아니라 "경험에서 편견을 자동 복제"하는 시스템이 되기 쉽습니다.
이번 분기에 ReasoningBank를 만들지 판단하는 간단한 기준
모든 팀이 당장 만들 필요는 없습니다.
지금 검토할 만한 팀은 이렇습니다. 비슷한 작업군이 반복되고, 한 번의 실패 비용이 크고, 왜 그런 결정을 했는지 감사 가능성이 중요하고, 이미 성공/실패 사례가 어느 정도 쌓여 있는 팀입니다. 예를 들면 데이터 분석 에이전트, 내부 운영 자동화, 반복성 높은 고객 지원, 코드 수정 워크플로 같은 영역입니다.
반대로 아직 하지 말아야 할 팀도 분명합니다. 작업 유형이 너무 들쭉날쭉하거나, 실패 원인이 전략 부족보다 기본 검색 품질 부족인 경우입니다. 이때는 ReasoningBank보다 먼저 검색 품질, 툴 호출 안정성, 평가 체계를 손보는 편이 낫습니다.
결국 질문은 이것입니다.
당신의 에이전트가 부족한 것은 더 많은 정보인가, 더 나은 습관인가.
후자라면 ReasoningBank는 꽤 설득력 있는 계층입니다. 다만 그것을 "메모리 추가"로 보면 과대평가하기 쉽고, "전략 저장소 설계"로 보면 비로소 제대로 판단할 수 있습니다. 지금 신경 써야 하는 사람은 에이전트가 반복 업무를 많이 맡고 있는데도 성능이 누적되지 않는 팀입니다. 그 팀에게 중요한 판단 기준은 새 메모리를 붙일 수 있느냐가 아니라, 어떤 형태의 경험을 저장해야 실제로 더 신뢰할 수 있게 되느냐입니다.
참고
1ReasoningBank: Enabling agents to learn from experience
27 Steps to Mastering Memory in Agentic AI Systems
4Reasoning Graphs: Self-Improving, Deterministic RAG through Evidence-Centric Feedback
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.