Agentic Context Management(ACM)는 에이전트의 메모리 문제를 단순 저장·검색 문제가 아니라 컨텍스트 수명주기 문제로 보는 접근이다. 논문은 프로덕션 에이전트 실패가 추론 능력 부족보다 대화 이력, 긴 프롬프트, 대형 도구 출력, 방대한 툴 정의를 제대로 관리하지 못하는 데서 자주 발생한다고 주장한다.
문제 정의
에이전트는 턴이 늘어날수록 더 많은 토큰을 매번 다시 읽는다. 단순 누적 방식은 대화 길이에 대해 비용이 사실상 이차적으로 증가하고, 단순 요약은 비용은 줄이지만 중요한 사실을 잃을 수 있다. ACM은 “무엇을 저장할까”보다 넓은 질문을 다룬다.
| 질문 | ACM 관점 |
|---|---|
| 무엇을 기억할까 | 중요한 사실, 결정, 근거, 조직 맥락을 구조화한다 |
| 어디에 둘까 | 데이터 유형별로 대화, 벡터 DB, 그래프, 파일, 이벤트 로그를 나눈다 |
| 누구 범위인가 | 개인, 팀, 조직, 프로젝트 같은 scope hierarchy를 관리한다 |
| 지금 필요한가 | 현재 작업과 관련 있는 기억만 검색한다 |
| 언제 압축·삭제할까 | provenance를 유지하면서 검증된 compaction과 consolidation을 수행한다 |
다섯 가지 primitive
논문은 ACM을 다섯 primitive로 나눈다.
| primitive | 설명 |
|---|---|
| Architecting | 컨텍스트 저장소, 계층, 정책, 비용 모델을 설계 |
| Ingesting | 대화·문서·도구 결과에서 기억할 정보를 추출·구조화 |
| Scoping | 개인·팀·조직·프로젝트 범위별 접근과 우선순위 결정 |
| Anticipating | 다음 턴이나 다음 작업에 필요할 정보를 미리 준비 |
| Compacting & consolidation | 컨텍스트 예산 안에서 정확도를 보존하며 압축·병합·삭제 |
기존 메모리와의 차이
agentic-memory는 주로 저장·검색 계층을 다룬다. ACM은 그 위에 운영 정책을 더한다. 예를 들어 같은 기억이라도 현재 태스크에는 필요 없고, 같은 팀의 다른 에이전트에는 필요하며, 오래된 버전이라면 provenance와 함께 낮은 우선순위로 내려야 한다. 이런 결정은 단순 벡터 검색만으로 해결하기 어렵다.
이 관점은 context-engineering과도 맞닿아 있다. 컨텍스트 창은 무한 저장소가 아니라 매 턴 비용과 정확도에 영향을 주는 실행 자원이다.
논문 결과
논문은 Maximem Synap이라는 reference implementation을 제시하고, 명시된 설정에서 LongMemEval 92%, LoCoMo 93.2%를 보고한다. 다만 이 수치는 제품·벤치마크 구성에 의존하므로, ACM의 핵심 기여는 특정 점수보다 컨텍스트를 lifecycle architecture로 분해한 개념 체계에 있다.
관련 문서
- agentic-memory — AI 에이전트 장기 메모리 아키텍처
- context-engineering — AI 에이전트 컨텍스트 창을 유한 자원으로 설계하는 방법론
- supermemory — AI 메모리·컨텍스트 엔진
- context-mode — 코딩 에이전트 컨텍스트 절약 MCP 서버