현장에서 에이전트 PoC가 길어지면 비슷한 장면이 반복된다. 처음에는 “이전 대화를 기억하게 하자”로 시작한다. 곧 벡터 DB, 세션 저장, 요약, 사용자 프로필이 한꺼번에 붙는다. 문제는 저장 기술이 아니다. 에이전트가 무엇을 기억해도 되는지 합의하지 않은 채 기억 기능을 켠 것이다.
최근 주요 플랫폼도 memory를 단순 대화 기록이 아니라 제품 계층으로 다룬다. Google Cloud는 2025년 7월 Vertex AI Agent Engine Memory Bank 공개 프리뷰를 발표하며 세션 밖 장기 기억, 선호·사실 추출, 기존 기억과의 통합·모순 해소를 강조했다. Anthropic은 2025년 9월 Claude의 업무용 memory를 발표하며 사용자·팀 프로젝트 맥락과 선호를 기억하되, 선택적 사용과 Incognito chat을 같이 제시했다. (cloud.google.com)
메모리는 하나가 아니며, 섞이면 망가진다
에이전트 메모리는 “오래 저장되는 것”이 아니다. 서로 다른 목적의 상태를 분리해 다루는 운영 장치다.
| 메모리 종류 | 기억하는 것 | 쓰기 기준 |
|---|---|---|
| 세션 메모리 | 지금 대화의 문맥, 미완료 과업 | 대화가 끝나면 압축 또는 폐기 |
| 의미 메모리 | 사용자·조직·업무의 안정적 사실 | 출처와 유효기간이 있을 때만 저장 |
| 에피소드 메모리 | 어떤 상황에서 무엇을 했고 결과가 어땠는지 | 재현 가능한 사건과 결과가 있을 때 저장 |
| 절차 메모리 | 다음에 반복할 작업 방식, 금지 패턴 | 검토된 성공·실패가 절차 변경으로 이어질 때 저장 |
LangGraph 문서는 인간 기억을 facts, experiences, rules에 대응시키며 semantic, episodic, procedural memory로 설명한다. OpenAI Agents SDK의 sandbox memory도 대화용 Session memory와 별개로 memory artifact를 다루며, 읽기와 생성 권한을 분리하는 설정을 제공한다. (docs.langchain.com)
기억할 것은 유용한 정보가 아니라 다시 쓸 정보다
많은 팀이 “나중에 유용할 수 있다”는 이유로 너무 많이 쓴다. 이 문장은 메모리 오염의 시작이다. 에이전트가 다시 읽지 않을 정보는 기억이 아니라 로그다.
메모리는 기록 보관소가 아니다. 다음 행동을 바꾸는 정보만 메모리다.
우리가 쓰기 후보로 보는 정보는 네 가지다.
- 사용자가 반복해서 밝힌 선호와 제약
- 업무 시스템에서 확인된 안정적 사실
- 이전 실행에서 발생한 실패 원인과 회피 조건
- 승인된 업무 절차와 금지된 행동
반대로 감정적 표현, 추측, 임시 요청, 한 번뿐인 상황 설명은 기본적으로 쓰지 않는다. 필요하면 로그에 남기고, 메모리 승격은 따로 심사한다.
쓰기 정책은 세 단계로 막아야 한다
좋은 메모리 설계는 retrieval보다 write path가 먼저다. 2026년 agent memory 연구도 장기 과업에서 memory system의 construction, retrieval, generation 비용과 trade-off를 별도로 보아야 한다고 정리한다. 또 다른 2026년 survey는 write-path filtering, contradiction handling, latency budgets, privacy governance를 실제 엔지니어링 이슈로 짚는다. (arxiv.org)
쓰기 정책은 단순해야 운영된다.
| 단계 | 질문 | 산출물 |
|---|---|---|
| 후보 생성 | 이 정보가 다음 행동을 바꾸는가 | memory candidate |
| 검증 | 출처, 소유자, 유효기간이 있는가 | approved memory |
| 반영 | 기존 기억과 충돌하는가 | update, supersede, reject |
특히 의미 메모리는 last-write-wins로 끝내면 안 된다. “고객은 A를 선호한다”와 “고객은 B를 선호한다”가 충돌하면 최신 발화만 믿을지, 업무 시스템 값을 믿을지, 사람에게 확인할지 정책이 필요하다. Google Memory Bank도 새 정보가 생기면 기존 기억과 통합하고 모순을 해결한다고 설명한다. 이 기능을 쓰더라도 최종 정책은 조직이 정해야 한다. (cloud.google.com)
저장소 선택 전에 삭제 기준을 정한다
메모리는 많이 쌓일수록 똑똑해지지 않는다. 오래된 선호, 폐기된 정책, 실패한 임시 우회가 살아 있으면 에이전트는 과거의 조직을 현재처럼 다룬다.
그래서 첫 설계 문서에는 저장소보다 먼저 세 가지가 들어가야 한다.
- 어떤 정보는 절대 저장하지 않는가
- 어떤 정보는 자동 승격하지 않는가
- 어떤 정보는 만료·검토·폐기되는가
OpenAI의 conversation state 문서는 Responses API와 Conversations API로 상태를 지속할 수 있다고 설명한다. Microsoft Foundry Agent Service도 persistent threads, runs, messages로 대화 상태를 관리한다고 설명한다. 상태를 지속하는 기능은 이미 플랫폼에 있다. 차이는 그 상태가 운영 자산이 되는지, 오염된 잔재가 되는지다. (platform.openai.com)
참고
- Google Cloud, “Vertex AI Memory Bank in public preview”, 2025: https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-memory-bank-in-public-preview
- Anthropic, “Bringing memory to teams at work”, 2025: https://claude.com/blog/memory
- OpenAI Agents SDK, “Agent memory”: https://openai.github.io/openai-agents-js/guides/sandbox-agents/memory/
- LangGraph Docs, “Memory overview”: https://docs.langchain.com/oss/javascript/langgraph/memory
- arXiv, “Memory for Autonomous LLM Agents”, 2026: https://arxiv.org/abs/2603.07670
- arXiv, “Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads”, 2026: https://arxiv.org/abs/2606.06448
에이전트 메모리 1단계는 “어디에 저장할까”가 아니다. “무엇을 기억하지 않을까”를 정하는 것이다. 그 기준이 있어야 semantic, episodic, procedural memory가 운영 시스템 안에서 서로 다른 역할을 한다. AX LABS는 이 기준을 에이전트 설계와 운영 거버넌스에 함께 묶어 설계한다. 다음 단계는 읽기 정책, 즉 어떤 기억을 언제 context로 올릴지다. 설계 기준부터 잡아야 한다면 AX Ops 방법론 →