AI 에이전트 메모리 구조 정리: 리콜·리테인과 Mem0·Honcho 엔진 비교 실험

핵심 메시지

• 대화창 안에서만 유지되는 기억은 에피소딕(컨텍스트 창) 메모리여서, 새 대화를 열면 사용자에 대해 아무것도 모르는 상태로 돌아간다.
• 메모리 시스템의 기본 동작은 두 가지다. 턴이 시작되기 전 관련 있는 사실을 불러와 컨텍스트에 넣는 리콜, 턴이 끝난 뒤 대화 기록에서 사실을 뽑아 저장하는 리테인이다.
• 저장한 사실은 벡터로 바꿔 검색하기 때문에 키워드가 아니라 개념 단위로 찾을 수 있고, 이 방식이 LLM에 훨씬 잘 맞는다.
• Hindsight, Mem0, Honcho 같은 상용 엔진과 SQLite 기반 자체 구현을 같은 인터페이스로 묶으면 어떤 사실을 어떻게 저장하는지 나란히 비교할 수 있다.
• 같은 방식은 클로드 코드나 코덱스 같은 코딩 에이전트에도 적용된다. 호출 전에 리콜하고 종료 후에 리테인하면 된다.

쉽게 이해하기

발표자는 간단한 시연으로 문제를 보여 준다. 메모리를 끈 상태에서 '초밥을 좋아한다'고 말하면 같은 대화 안에서는 저녁 메뉴로 초밥을 추천한다. 하지만 새로고침해 새 대화를 열고 같은 질문을 하면 아무것도 기억하지 못한 채 일반적인 답만 내놓는다. 대화 한 편 안에서만 유지되는 이 기억이 에피소딕 메모리다.

메모리를 켜면 달라진다. '초밥을 좋아한다'는 문장에서 사실 하나가 추출돼 저장되고, 새 대화에서 저녁 메뉴를 물었을 때 그 사실이 다시 불려 나와 답변에 반영된다. 여기서 필요한 동작이 리콜과 리테인이다. 리콜은 사용자의 입력을 받아 관련 있는 사실을 찾아 시스템 컨텍스트에 주입하는 단계이고, 리테인은 턴이 끝난 뒤 대화 전체를 LLM으로 훑어 사실을 추출하고 데이터베이스에 넣는 단계다. 일부 엔진은 대화 도중 모델이 스스로 기억하거나 꺼내 쓰도록 도구를 제공한다.

영상은 메모리를 여러 층위로 구분한다. 학습 과정에서 얻은 모델 메모리, 하나의 응답 안에서만 쓰이는 워킹 메모리, 대화창 단위의 에피소딕 메모리, 그리고 지금 다루는 장기 사용자·애플리케이션 메모리다. 마지막 층은 선호와 관찰, 요약처럼 오래 남겨 둘 사실을 뜻한다.

구현에는 LLM과 임베딩 모델이 함께 필요하다. 대화에서 사실을 뽑아내는 데는 LLM이, 그 사실을 벡터로 바꾸는 데는 임베딩 모델이 쓰이며, 벡터와 사실은 원하는 저장소에 넣는다. 발표자가 직접 만든 로컬 버전은 SQLite에 저장하고 임베딩은 오픈AI, 사실 추출은 앤트로픽 모델을 사용했다. 검색은 벡터 기반이라 단어가 일치하지 않아도 개념이 비슷하면 찾아온다.

실제 코드에서는 메모리가 미들웨어 형태로 붙는다. 엔진과 함께 스코프(사용자와 세션)를 넘겨 주면 백엔드가 누구의 어떤 대화에 속한 사실인지 구분해 보관하고, 역할을 리콜과 리테인 모두로 둘지 리테인만 둘지 고를 수 있다. 리테인만 켜면 이번 대화는 남기지 않되 기존에 알던 내용은 활용하는 시크릿 모드처럼 동작한다.

주요 인사이트

• 'AI가 나를 기억한다'는 경험은 모델의 능력이 아니라 대화 앞뒤에 붙은 저장·검색 파이프라인의 결과다. 기억은 학습이 아니라 배관 문제에 가깝다.
• 리콜과 리테인을 분리하면 프라이버시 설계가 쉬워진다. 리테인만 끄는 것만으로 '이번 대화는 기록하지 말되 나를 알고는 있어라'는 요구를 구현할 수 있다.
• 메모리를 벡터 검색으로 다루면 사용자가 이전과 다른 표현을 써도 관련 사실이 걸린다. 키워드 검색으로는 잡히지 않는 맥락이 여기서 살아난다.
• 여러 엔진을 하나의 인터페이스 뒤에 두고 같은 입력을 동시에 흘려 보내면, 각 시스템이 무엇을 '기억할 만한 사실'로 판단하는지 차이가 드러난다. 벤치마크의 대상이 성능이 아니라 판단 기준이라는 점이 흥미롭다.
• 코딩 에이전트에도 같은 구조를 씌울 수 있다. 에이전트를 호출하기 전 사용자 프롬프트로 리콜하고, 종료 후 대화 기록으로 리테인하면 별도 통합 없이 기억을 붙일 수 있다.

자주 묻는 질문

관련 AI 소식