현장에서 에이전트 PoC를 보면 첫 주에는 반응이 좋다. 대화가 자연스럽고, 문서도 찾아오고, 몇 단계 업무도 처리한다. 문제는 둘째 주부터 나온다. 어제 합의한 업무 기준을 잊고, 다른 사용자의 맥락을 잘못 가져오고, 오래된 정책을 현재 기준처럼 말한다. 이때 팀은 모델을 바꾸려 한다. 그러나 원인은 대개 모델이 아니라 메모리 구조다.
에이전트 메모리는 “기억력”이 아니다. 운영 중인 판단 재료를 어떤 저장소에 두고, 언제 불러오고, 누구에게 공유하고, 언제 폐기할지 정하는 아키텍처다.
메모리는 하나가 아니라 세 층이다
단기·장기·공유 메모리를 한 저장소에 넣으면 곧바로 오염된다. 회의 중 임시 메모가 장기 규칙처럼 남고, 개인 취향이 팀 표준처럼 퍼진다. 반대로 장기 지식이 단기 컨텍스트에 과도하게 들어오면 현재 작업의 초점이 흐려진다.
| 구분 | 목적 | 저장 대상 | 실패 패턴 |
|---|---|---|---|
| 단기 메모리 | 현재 세션 유지 | 최근 대화, 진행 중 계획, 임시 변수 | 컨텍스트 과밀, 중간 지시 망각 |
| 장기 메모리 | 세션 간 누적 | 사용자 선호, 반복 결정, 검증된 업무 규칙 | 오래된 정보 재사용, 출처 불명 |
| 공유 메모리 | 여러 에이전트·팀 간 정합성 | 공통 정책, 업무 온톨로지, 승인된 산출물 | 권한 누락, 부서별 기준 충돌 |
OpenAI Agents SDK는 세션 메모리를 대화 이력 관리로 설명하고, 별도의 agent memory는 이전 실행에서 얻은 교훈과 선호를 재사용하는 구조로 분리한다. Cloudflare의 Agent Memory도 메시지 이력에서 사실·이벤트·지시·작업을 추출하고 중복을 줄여 검색 가능한 메모리로 저장하는 방식을 제시한다. 방향은 같다. “긴 프롬프트”가 아니라 “층화된 기억”이 필요하다.
메모리 설계의 핵심은 더 많이 저장하는 것이 아니라, 무엇을 승격하지 않을지 정하는 것이다.
공유 메모리는 지식창고가 아니라 권한 모델이다
기업 현장에서 가장 위험한 메모리는 공유 메모리다. 공유 메모리는 협업을 가능하게 하지만, 동시에 잘못된 전파를 만든다. 구매팀의 협상 메모가 영업 에이전트에 노출되거나, 특정 고객 대응 원칙이 전체 고객 정책처럼 쓰이면 사고가 난다.
그래서 공유 메모리는 저장소 설계보다 권한 설계가 먼저다.
- 개인 메모리: 사용자별 선호와 작업 습관
- 역할 메모리: 직무별 절차와 검토 기준
- 팀 메모리: 팀 단위 의사결정과 운영 규칙
- 전사 메모리: 승인된 정책, 표준 용어, 공식 지식
각 층은 쓰기 권한과 읽기 권한이 달라야 한다. 에이전트가 장기 메모리에 쓸 수 있어도 공유 메모리에 직접 쓰게 해서는 안 된다. 공유 메모리는 승인, 버전, 출처, 만료일을 가진 운영 자산이다.
메모리는 저장보다 승격과 폐기가 어렵다
많은 팀이 vector DB를 붙이면 장기 메모리가 생긴다고 생각한다. 아니다. vector DB는 검색 수단이다. 메모리 운영은 별도 문제다.
운영 메모리에는 최소 네 가지 규칙이 필요하다.
- 승격 규칙: 단기 대화 중 무엇을 장기 메모리로 올릴지 정한다.
- 출처 규칙: 사용자의 말, 시스템 로그, 공식 문서, 도구 결과를 구분한다.
- 충돌 규칙: 새 정보와 기존 정보가 다를 때 무엇을 우선할지 정한다.
- 폐기 규칙: 만료된 선호, 바뀐 정책, 실패한 추론을 제거한다.
Redis의 2026년 장기 메모리 아키텍처 글은 원문 텍스트에서 검색 가능한 지식으로 가는 파이프라인과 recall·latency·cost·forgetting의 트레이드오프를 강조한다. MongoDB와 LangGraph의 장기 메모리 통합도 세션 안 기억과 세션을 넘는 기억을 구분한다. 연구 쪽에서도 2026년 Agentic Memory 논문은 단기·장기 메모리 관리를 에이전트 정책 안에 통합하는 방향을 다룬다. 현장 결론은 단순하다. 저장소보다 운영 규칙이 성능을 결정한다.
참고와 다음 행동
- OpenAI Agents SDK Sessions: https://openai.github.io/openai-agents-js/guides/sessions/
- OpenAI Agents SDK Agent Memory: https://openai.github.io/openai-agents-js/guides/sandbox-agents/memory/
- Cloudflare Agent Memory, 2026: https://blog.cloudflare.com/introducing-agent-memory/
- Redis Long-Term Memory Architectures for AI Agents, 2026: https://redis.io/blog/long-term-memory-architectures-ai-agents/
- MongoDB LangGraph Long-Term Memory, 2025: https://www.mongodb.com/company/blog/product-release-announcements/powering-long-term-memory-for-agents-langgraph
- Agentic Memory 논문, 2026: https://arxiv.org/abs/2601.01885
에이전트 메모리는 기능 목록으로 구매할 수 없다. 업무별로 단기·장기·공유 메모리의 경계를 정하고, 쓰기 권한과 폐기 규칙을 설계해야 한다. AX Ops에서는 이 구조를 에이전트 UX, 평가, 운영 로그, 승인 체계와 함께 묶어 설계한다. 메모리부터 바로잡아야 에이전트가 파일럿을 넘어 운영 자산이 된다. 다음 설계 원칙은 AX Ops 방법론 →에서 이어진다.