AI 에이전트 메모리라는 말을 들으면 많은 분이 먼저 vector DB부터 떠올립니다. 하지만 실제 에이전트를 만들다 보면 문제는 훨씬 더 넓습니다. 어떤 정보는 지금 대화 안에만 잠깐 들어 있어야 하고, 어떤 정보는 나중에 다시 찾아오면 되고, 어떤 정보는 모델이 아니라 시스템이 따로 들고 있어야 합니다.
이 셋을 한 단어로 다 memory라고 부르면 설계가 금방 꼬입니다. 이 글에서는 AI 에이전트 메모리를 context window 안의 working memory, retrieval memory, tool state로 나눠 보고, 왜 메모리가 모델 옵션이 아니라 시스템 설계 문제에 가까운지 설명하겠습니다.
에이전트의 메모리는 모델 옵션 하나로 해결되는 기능이 아니라, 무엇을 어디에 두고 언제 다시 가져올지 정하는 시스템 문제입니다.
왜 이 말이 헷갈릴까
예를 들어 블로그 초안을 쓰는 에이전트를 만든다고 해보겠습니다. 사용자가 “어제 잡아 둔 주제로 draft 이어서 써줘”라고 말했을 때, 에이전트가 기억해야 하는 것은 방금 직전 대화만이 아닙니다. 어제 조사한 문서, 현재 draft의 post_id, 이미 만든 썸네일 여부, 지금 단계가 조사인지 초안인지 같은 상태도 함께 필요합니다.
- 방금 직전 대화에서 무엇을 말했는가
- 어제 조사한 문서와 메모는 어디에 있는가
- 현재 작업 중인 draft의 post_id는 무엇인가
- 이미 썸네일을 만들었는가
- 지금 단계가 조사인지, 초안 작성인지, 검토인지
채팅 기록만 길게 붙이면 context가 금방 불어나고, vector DB에 다 넣으면 현재 실행 상태를 잃어버리고, 앱 state만 믿으면 필요한 설명 문맥을 모델이 못 봅니다. 그래서 먼저 메모리를 세 종류로 나눠 봐야 합니다.
먼저 세 가지로 나누자
working memory는 지금 눈앞에 있는 정보다
working memory는 모델이 이번 응답을 만들 때 직접 보고 있는 정보입니다. 시스템 프롬프트, 최근 대화, 방금 읽어 온 문서 조각, 직전 tool 결과가 여기에 들어갑니다. 이 글에서는 이것을 context window 안의 메모리라고 부르겠습니다.
retrieval memory는 필요할 때 다시 가져오는 정보다
retrieval memory는 항상 모델 앞에 펼쳐져 있지 않습니다. 대신 검색이나 유사도 조회를 통해 필요한 순간에만 일부를 꺼내 오고, 그다음 context window 안으로 넣습니다. vector DB는 보통 이 층에서 많이 쓰입니다.
tool state는 시스템이 따로 들고 있는 실행 상태다
tool state는 모델의 기억이라기보다 애플리케이션의 상태에 가깝습니다. 현재 draft의 post_id, 생성한 이미지 경로, 승인 여부, 재시도 횟수, 마지막 에러처럼 정확하게 저장하고 다시 불러와야 하는 값이 여기에 들어갑니다.
context window는 working memory에 가깝다
Anthropic 문서는 context window를 모델이 응답을 생성할 때 참조할 수 있는 전체 텍스트로 설명합니다. 이 개념은 사람의 작업 기억과 비슷하게 이해하면 편합니다. 즉 모델은 지금 이 창 안에 들어온 것만 직접 보고 판단합니다.
그래서 “전에 봤으니 기억하겠지”라고 생각하면 자주 어긋납니다. 지금 turn에서 context에 다시 들어오지 않으면 모델은 그 정보를 안정적으로 활용하지 못할 수 있습니다.
- 오래된 문장이 새 판단을 방해할 수 있습니다.
- 중요한 정보가 긴 대화 중간에 묻힐 수 있습니다.
- 불필요한 로그가 토큰 비용과 지연을 키울 수 있습니다.
- context가 길어진다고 자동으로 더 정확해지지 않습니다.
Anthropic 문서도 context가 길어질수록 accuracy와 recall이 저하될 수 있고, 이를 context rot라고 설명합니다. 그래서 working memory의 핵심은 단순히 많이 넣는 것이 아니라, 지금 필요한 것만 잘 고르는 데 있습니다.
vector DB는 만능 기억이 아니다
vector DB가 자주 memory라고 불리는 이유는 분명합니다. 문서 조각을 저장해 두고 나중에 관련 내용을 다시 꺼내 오는 데 매우 유용하기 때문입니다. RAG 논문도 언어 모델의 parametric memory만으로는 최신성 업데이트와 정확한 지식 접근에 한계가 있고, 이를 보완하기 위해 dense vector index 같은 non-parametric memory를 결합하는 구조를 설명합니다.
Pinecone 문서도 semantic search를 dense vector index에서 의미적으로 가까운 records를 찾는 방식으로 설명합니다. 여기서 중요한 단어는 “찾는다”입니다.
- 과거 문서에서 관련 조각 찾기
- 사용자 선호 메모 중 비슷한 항목 찾기
- 긴 회의록에서 관련 대목 가져오기
- 지식베이스에서 후보 문서 추리기
반대로 vector DB는 지금 2번째 단계까지 끝냈는지 추적하거나, 마지막 tool call이 성공했는지 저장하거나, 동일 작업의 재실행을 막는 식의 정확한 실행 상태 보존에는 적합하지 않습니다. vector DB는 기억 그 자체라기보다, 필요할 때 관련 정보를 다시 꺼내 오는 retrieval 계층에 더 가깝습니다.
tool state는 왜 따로 봐야 할까
실무에서 제일 자주 놓치는 부분이 바로 tool state입니다. 에이전트는 문답만 하지 않습니다. 파일을 읽고, 명령을 실행하고, 초안을 만들고, ID를 기억하고, 중간 결과를 다음 단계에 넘깁니다. 이때 정말 중요한 정보 상당수는 모델이 아니라 시스템 바깥에 있어야 합니다.
- draft slug
- 생성된 draft의 post_id
- 썸네일 파일 경로
- 이전 draft가 이미 있는지 여부
- 지금 create를 해야 하는지 update를 해야 하는지
이 정보는 의미가 비슷한 문서를 찾는 문제가 아닙니다. 정확하게 저장하고 정확하게 다시 불러와야 하는 문제입니다. LangGraph 문서가 short-term memory를 단순 대화 기록만이 아니라 thread-scoped state로 설명하는 이유도 여기에 있습니다. 대화뿐 아니라 uploaded files, retrieved documents, generated artifacts 같은 stateful data가 함께 관리되어야 하기 때문입니다.
한 장면으로 보면 더 쉽다
사용자가 이렇게 말한다고 해보겠습니다. “어제 조사하던 AI 메모리 글 이어서 써줘. 초안은 draft만 갱신하고 publish는 하지 마.” 이 요청을 처리할 때 세 메모리는 서로 다른 일을 합니다.
context window에 들어가는 것
- 현재 사용자 요청
- 작업 규칙
- 최근 대화 몇 턴
- 방금 읽은 brief와 fact pack 핵심
- 기존 draft 일부
retrieval memory에서 가져오는 것
- 지난 조사 메모 중 관련 내용
- 공식 문서에서 저장해 둔 근거 조각
- 이전에 정리한 사용자 선호 메모
tool state로 따로 들고 있는 것
- 이 글의 slug
- 기존 draft의 post_id
- preview_url, edit_url
- 이미 업로드한 썸네일 정보
- validate를 통과했는지 여부
이 장면을 보면 왜 vector DB 하나로는 부족한지 바로 드러납니다. 문서 검색은 잘해도 post_id를 잊어버리면 update 대신 새 draft를 또 만들 수 있기 때문입니다.
vector DB만 붙이면 메모리가 해결된다고 느끼는 이유
초기 데모에서는 PDF를 넣었더니 관련 내용을 다시 찾아주고, 사용자 취향을 저장해 뒀다가 다음 대화에서 꺼내 쓰고, 긴 문서를 chunk로 쪼개 두었더니 답변 품질이 올라가는 장면이 먼저 보입니다. 여기까지는 분명 유용합니다.
하지만 실제 운영으로 가면 곧 다른 문제가 나옵니다. 어떤 메모리를 언제 업데이트할지, 오래된 메모리를 언제 잊을지, 잘못 저장된 메모리를 어떻게 수정할지, 검색 결과 여러 개 중 무엇을 context에 넣을지, tool 결과와 문서 메모가 충돌하면 무엇을 우선할지까지 함께 정해야 합니다.
즉 retrieval은 memory 문제의 한 조각일 뿐입니다. 검색이 잘된다고 상태 관리가 자동으로 해결되지는 않습니다.
결국 AI 에이전트 메모리는 시스템 문제다
에이전트의 메모리를 어렵게 만드는 이유는 모델이 덜 똑똑해서만이 아닙니다. 실제로는 어떤 정보가 현재 turn에 꼭 필요한지, 어떤 정보는 나중에 검색하면 되는지, 어떤 정보는 반드시 정확한 state로 보존해야 하는지, 어떤 정보는 잊어야 하는지, 어떤 정보는 사용자 승인 전까지 쓰면 안 되는지를 동시에 풀어야 합니다.
이것은 모델 파라미터 하나의 문제가 아니라 프롬프트 구성, retrieval 정책, state 저장 방식, 권한 설계, 실패 복구 흐름이 함께 얽힌 문제입니다. 그래서 memory 품질은 종종 모델 스펙보다 오케스트레이션 품질에서 더 크게 갈립니다.
실무에서는 어떻게 나누면 좋을까
context에 둘 것
- 지금 답변에 꼭 필요한 최근 대화
- 현재 단계의 핵심 규칙
- 방금 검색한 문서 조각
- 바로 직전 tool 결과
retrieval store에 둘 것
- 긴 문서
- 과거 대화 요약
- 사용자 선호 메모
- 자주 다시 참고하는 지식 조각
app state로 둘 것
- task_id, post_id, file path
- 승인 여부
- 현재 단계와 재시도 횟수
- 이미 실행한 tool 결과의 canonical record
특히 정확한 값이 필요한 상태는 vector DB보다 명시적인 DB나 체크포인트 스토어에 두는 편이 안전합니다.
메모리 설계 체크리스트
- 이 정보는 지금 context에 꼭 있어야 하나
- 아니면 검색해서 다시 가져오면 되나
- 검색이 아니라 정확한 키로 조회해야 하는 상태인가
- 이 메모리는 언제 갱신되나
- 오래되면 언제 버리나
- 잘못 저장됐을 때 누가 수정하나
- 승인 전에는 어떤 상태를 절대 자동 실행하면 안 되나
이 질문에 답하지 못하면 memory 기능을 붙여도 에이전트는 자주 같은 실수를 반복합니다. 반대로 이 경계를 잘 나누면, 메모리는 훨씬 단순해집니다. “모델이 다 기억하게 하자”가 아니라 “무엇을 어디에 둘지 분류하자”로 접근하게 되기 때문입니다.
정리
AI 에이전트 메모리는 하나가 아닙니다. context window 안의 working memory, 필요할 때 다시 찾는 retrieval memory, 시스템이 따로 들고 있는 tool state를 구분해야 합니다. 이 셋을 나누면 왜 context window가 길어도 문제가 남는지, 왜 vector DB를 붙여도 실행이 불안정할 수 있는지, 왜 memory가 결국 시스템 설계 문제인지가 보입니다.
관련 글로는 MCP란 무엇인가, ReAct 논문 쉽게 이해하기, AI 에이전트 tool use 실패: 상태 관리가 더 어렵다, AI 에이전트 planning이 왜 필요한가를 함께 보면 흐름이 더 잘 잡힙니다.
주요 참고 자료는 Anthropic context windows guide, LangChain memory overview, RAG 논문, Pinecone semantic search guide, OpenAI text generation guide입니다.
