이 글의 순서 모델이 스스로 기억하는 것은 아니다
AI 에이전트에게 어제 정한 조건을 다시 물었는데 엉뚱한 답이 돌아왔다. 반대로 잠깐 말한 취향을 오래된 규칙처럼 적용하기도 했다.
둘 다 흔히 “메모리 문제”라고 부른다. 하지만 하나는 필요한 정보를 못 찾은 문제고, 다른 하나는 낡은 정보를 너무 믿은 문제다. 저장 공간만 늘려서는 함께 해결되지 않는다.
그래서 저장 공간보다 메모리의 수명을 따라가 보기로 했다. 어디에 남기고, 어떻게 다시 쓰며, 언제 잊어야 하는지를 나누면 두 실패의 원인이 보인다.

메모리는 정보를 쌓아두는 상자가 아니다. 남길 내용을 고르고, 최신 상태로 고치고, 필요한 순간에만 다시 넣고, 오래된 내용은 빼는 흐름이다.
모델이 스스로 기억하는 것은 아니다
AI 에이전트의 메모리는 대개 모델 바깥에 있다. 대화 기록, 사용자 설정, 작업 결과를 파일이나 데이터베이스에 저장해 두었다가 다음 요청에 필요한 부분을 다시 넣는다.
짧게 줄이면 다음 흐름이다.
대화와 작업 결과
→ 남길 정보 고르기
→ 바깥 저장소에 기록하기
→ 다음 작업에서 관련 정보 찾기
→ 모델이 볼 컨텍스트에 넣기
모델은 마지막 단계에서 들어온 내용을 보고 답하거나 행동한다. 저장소에 정보가 있어도 찾지 못하면 쓰지 못한다. 반대로 관련 있어 보인다는 이유만으로 잘못된 기록을 넣으면 그 기록이 다음 판단을 흐린다.
OpenAI의 장기 메모리 예제는 세션 중 후보 메모리를 모은 뒤, 세션이 끝날 때 중복과 충돌을 정리해 장기 메모리로 합친다. 저장 뒤에도 중복 제거, 충돌 해결, 망각이 이어진다.
대화 기록과 장기 메모리는 다르다
한 대화 안에서 앞말을 이어가는 정보는 짧게 쓰는 작업 상태다. 여러 대화가 끝난 뒤에도 남겨둘 정보는 장기 메모리다.
예를 들어 여행 예약을 돕는 에이전트가 있다고 해보자.
- “이번 여행 예산은 100만 원”은 지금 예약에서만 쓸 가능성이 크다.
- “채식 식사를 선호한다”는 다음 여행에서도 도움이 된다.
- “지난번 결제 단계에서 카드 인증에 실패했다”는 같은 실패를 피할 경험 기록으로 남는다.
- “결제 전에는 반드시 사용자 확인을 받는다”는 취향이 아니라 지켜야 할 작업 규칙이다.
이 네 정보를 모두 같은 방식으로 저장하면 문제가 생긴다. 일회성 예산이 다음 여행에 남고, 실패 기록이 사용자 취향처럼 불려 오며, 작업 규칙이 오래된 대화 한 줄과 같은 무게를 갖게 된다.
LangChain의 메모리 설명은 한 대화 안의 짧은 메모리와 대화를 넘어 남는 장기 메모리를 나눈다. 장기 메모리 안에서도 사실, 경험, 절차를 구분한다. 이름보다 중요한 것은 정보마다 수명과 쓰임이 다르다는 점이다.
무엇을 기억할지 고르는 일이 더 어렵다
처음에는 대화를 많이 저장하면 더 잘 기억할 것처럼 보인다. 실제로는 잡담, 임시 상태, 이미 바뀐 정보까지 함께 쌓인다.
예를 들어 사용자가 한 번 “오늘은 창가 좌석이 좋아”라고 말했다. 이 문장을 곧바로 영구 취향으로 저장하면 다음 예약에서도 창가 좌석을 고르게 된다. 사용자의 평소 취향은 통로 좌석이었을 수도 있다.
그래서 메모리를 쓸 때는 적어도 다음 질문이 필요하다.
- 이 정보는 이번 작업에서만 유효한가?
- 다음 작업에서도 기본값으로 써도 되는가?
- 사용자가 직접 말한 사실인가, 에이전트가 추정한 내용인가?
- 새 정보가 이전 기록을 바꾸거나 무효로 만들었는가?
- 언제 다시 확인하거나 지워야 하는가?
AWS의 AgentCore Memory 문서는 짧은 대화에서 장기 기록을 뽑는 규칙을 메모리 전략으로 설명한다. 이 구분은 특정 제품을 쓰지 않아도 유용하다. 저장 버튼보다 먼저 “무엇을 어떤 조건에서 남길지”를 정해야 한다.
관련 있는 기억이 항상 맞는 기억은 아니다
많은 메모리 시스템은 질문과 뜻이 비슷한 기록을 찾는다. 이를 의미 기반 검색이라고 한다. “로그인 오류”를 물으면 과거의 로그인 관련 기록을 불러오는 식이다.
문제는 비슷한 기록 안에 성공과 실패가 함께 있을 때다.
비밀번호 초기화로 해결했다.
비밀번호 초기화를 시도했지만 권한 오류로 실패했다.
두 문장은 주제가 매우 비슷하다. 하지만 다음 행동을 고를 때 의미는 반대다. 검색 결과에 성공 여부와 확인한 날짜가 없다면 에이전트는 이미 실패한 방법을 다시 선택하기 쉽다.
LongMemEval 연구는 장기 메모리를 단순한 정보 찾기로만 평가하지 않는다. 여러 대화에 걸친 추론, 시간 순서, 지식 갱신, 답할 근거가 없을 때 멈추는 능력을 함께 본다. 오래 저장하는 것과 올바르게 기억하는 것은 다른 문제다.
잊는 기능도 메모리의 일부다
좋은 메모리는 모든 기록을 영원히 보존하지 않는다.
주소, 일정, 프로젝트 상태, 도구 버전은 바뀐다. 사용자 취향도 상황에 따라 달라진다. 낡은 정보가 계속 들어오면 에이전트는 잊어서가 아니라 잘못 기억해서 실패한다.
메모리를 관리할 때는 다음 동작이 함께 있어야 한다.
- 추가: 새로 확인한 사실이나 경험을 기록한다.
- 갱신: 같은 대상의 최신 정보로 바꾼다.
- 통합: 뜻이 같은 기록을 하나로 합친다.
- 충돌 처리: 현재 요청과 과거 기록이 다르면 우선순위를 정한다.
- 망각: 기한이 지났거나 근거가 약한 기록을 빼낸다.
현재 사용자의 말이 오래된 메모리보다 우선해야 한다. 명확한 작업 규칙은 대화에서 우연히 나온 문장과 같은 저장소에 두지 않는 편이 안전하다. 민감한 개인정보는 “나중에 도움이 될지도 모른다”는 이유만으로 저장해서는 안 된다.
처음에는 세 칸이면 충분하다
메모리 시스템을 처음부터 거대한 벡터 데이터베이스로 만들 필요는 없다. 작은 에이전트라면 세 칸으로 시작해도 된다.
현재 작업
- 이번 요청의 목표와 아직 끝나지 않은 일
오래 남길 사실
- 사용자가 명확히 확인한 취향과 제약
경험 기록
- 무엇을 시도했고, 성공하거나 실패한 이유
각 기록에는 확인한 날짜와 출처를 붙인다. 다음 작업에 넣을 때는 전부 복사하지 않고, 지금 질문과 관련 있는 작은 부분만 고른다. 정보가 충돌하면 현재 사용자의 말, 확인된 최신 사실, 오래된 기록 순으로 판단한다.
이 구조로도 무엇을 저장해야 할지 분명하지 않다면 장기 메모리를 아직 넣지 않는 편이 낫다. 메모리가 과거 정보를 다시 행동으로 연결할수록 잘못된 기록의 비용도 커진다.
기억의 양보다 생애주기를 본다
AI 에이전트 메모리는 모델에 기억력을 추가하는 마법 상자가 아니다. 바깥에 정보를 저장하고, 필요한 때 찾아서, 다시 모델이 볼 수 있게 넣는 시스템이다.
처음에는 “얼마나 많이 기억하나”가 중요해 보였다. 공식 문서와 장기 메모리 평가 연구를 함께 보면 더 중요한 질문은 달라진다.
무엇을 남겼고,
왜 지금 불러왔으며,
언제 고치거나 잊을 것인가?
이 세 질문에 답해야 기억이 다음 행동을 돕는다. 답하지 못하면 메모리는 지식이 아니라 오래된 문맥을 자동으로 되살리는 장치가 되기 쉽다.
한 대화 안의 세션과 컨텍스트 창이 먼저 궁금하다면 LLM 세션을 기억처럼 믿으면 작업이 흔들린다를 함께 읽어도 좋다.
확인한 공식·원 자료
아래 자료는 2026년 8월 24일에 확인했다.
- OpenAI, Context Engineering for Personalization
- LangChain, Memory overview
- LangChain, Long-term memory
- Amazon Web Services, Add memory to your AgentCore agent
- Amazon Web Services, Long-term memory and RAG
- Microsoft AutoGen, Memory and RAG
- Sumers 외, Cognitive Architectures for Language Agents
- Packer 외, MemGPT: Towards LLMs as Operating Systems
- Park 외, Generative Agents: Interactive Simulacra of Human Behavior
- Wu 외, LongMemEval
- Maharana 외, Evaluating Very Long-Term Conversational Memory of LLM Agents
반응
댓글은 제출 즉시 공개되며, 작성 때 정한 비밀번호로 삭제할 수 있습니다.
댓글을 불러오는 중입니다.