AI 에이전트에게 어제 정한 내용을 다시 물었는데 모른다고 하면, 모델이 멍청해서가 아닐 수 있습니다. 대화 기록이 다음 실행에 다시 들어가는 구조가 없기 때문입니다.
에이전트의 기억은 긴 대화창 하나가 아니라, 저장하고 요약하고 다시 꺼내 쓰는 별도 구조에 가깝습니다.
에이전트와 챗봇의 차이는 기억에서 드러납니다
일반적인 챗봇은 현재 대화 안에서 질문과 답을 이어갑니다. 하지만 에이전트가 매일 반복해서 일을 하려면 어제의 목표, 사용자의 선호, 작업의 진행 상태를 다음 실행에서도 불러올 수 있어야 합니다.
이 연결이 없으면 같은 설명을 매번 처음부터 해야 합니다. 반대로 기억을 무작정 모두 넣으면 오래된 정보와 잘못된 판단까지 함께 따라와 답변이 흐려질 수 있습니다.
마이크로소프트가 공개한 기억 구조
마이크로소프트는 7월 24일 Microsoft Agent Framework와 Azure Cosmos DB를 연결한 네이티브 에이전트 메모리 구조를 소개했습니다. 핵심은 대화 기록을 그대로 쌓는 데서 끝나지 않는다는 점입니다.
원본 대화에서 오래 남길 사실과 사용자 프로필, 작업 요약을 분리하고, 다음 실행이 시작될 때 필요한 내용만 검색해 넣는 방식입니다. 이 기능은 현재 프리뷰 단계이며, 공식 글 기준으로 Python 사용이 먼저 지원됩니다.
기억을 붙이는 3단계
- 원본 기록 저장: 어떤 지시와 결과가 있었는지 나중에 확인할 수 있도록 남깁니다.
- 오래 남길 내용 요약: 말투 선호, 반복 작업, 확정된 결정처럼 다음 실행에도 필요한 정보만 골라냅니다.
- 실행 전에 검색: 새 작업이 시작될 때 관련된 기억만 찾아 현재 지시와 함께 전달합니다.
이 구조를 쉽게 비유하면 메모장을 통째로 읽는 것이 아니라, 필요한 페이지를 찾아 읽는 방식입니다.
기억을 넣는다고 무조건 정확해지지는 않습니다
기억에 잘못 저장된 정보가 있으면 에이전트는 다음 실행에서도 그 내용을 사실처럼 사용할 수 있습니다. 사용자가 한 번 잘못 말한 내용을 영구 규칙으로 저장하는 것도 위험합니다.
또 다른 문제는 범위입니다. 한 사용자의 정보가 다른 사용자의 작업에 섞이면 안 되고, 오래된 정보는 삭제하거나 만료시킬 수 있어야 합니다. 에이전트의 기억은 편리한 기능이면서 동시에 관리해야 할 데이터입니다.
실제로 만들 때 먼저 정할 것
- 무엇을 기억할지: 선호, 장기 목표, 작업 상태를 구분합니다.
- 누구의 기억인지: 사용자와 프로젝트 단위로 범위를 나눕니다.
- 언제 지울지: 오래된 정보의 만료 기준과 사용자의 삭제 요청을 정합니다.
- 어디까지 자동화할지: 기억을 새 규칙으로 확정하기 전 사람의 확인이 필요한지 결정합니다.
결론
에이전트를 계속 일하게 만드는 방법은 프롬프트를 계속 길게 쓰는 데만 있지 않습니다. 매번 필요한 기억을 안정적으로 저장하고, 골라서 불러오고, 틀린 기억을 지울 수 있는 구조가 먼저 필요합니다.
처음부터 거대한 기억 시스템을 만들 필요는 없습니다. 반복 작업 하나를 정하고, 사용자 선호 한두 가지를 저장한 뒤, 다음 실행에서 제대로 불러오는지 확인하는 것부터 시작하면 됩니다.
출처
공개된 공식 기술 소개를 바탕으로, 비개발자도 이해할 수 있도록 에이전트 메모리의 흐름과 주의점을 정리했습니다.