AI 에이전트를 구축하는 대부분의 팀은 메모리와 추론 비용(inference cost)을 다음 모델 출시가 결국 해결해 줄 문제로 취급하고 있습니다. 그들은 더 큰 컨텍스트 윈도우(context window), 더 똑똑한 검색기(retriever), 더 저렴한 토큰 요율 등이 에이전트 메모리 문제를 해결하기 위한 시스템의 필요성을 면제해 줄 것이라고 믿습니다.

이러한 태도는 편리하지만 잘못되었습니다. 에이전트가 무엇을 기억할지, 언제 잊을지, 그리고 추론하는 데 비용이 얼마나 들지는 아키텍처 결정(architectural decisions) 사항입니다. 이러한 결정은 어떤 모델이 관여하기 훨씬 전에 내려지며, 모델이 아무리 개선되더라도 그 밑바탕에 깔린 잘못된 아키텍처를 고칠 수는 없습니다.

메모리는 버퍼(buffer)가 아니라 라이프사이클(lifecycle)입니다

오늘날 대부분의 에이전트 시스템은 컨텍스트(context)를 하나의 공유된 덩어리(blob)로 취급합니다. 모든 것이 들어가고, 의미 있는 것은 나오지 않으며, 공간이 부족해지는 것에 대한 "해결책"은 더 큰 윈도우를 사용하는 것입니다. 그것은 메모리 시스템이 아니라 그냥 쌓아둔 더미(pile)일 뿐입니다.

라이프사이클 접근 방식은 이를 각각 고유한 설계가 필요한 단계로 나눕니다:

• 인제스션 (Ingestion): 처음에 무엇이 메모리에 기록되는지, 그리고 어떤 입도(granularity)로 기록되는지
• 스코핑 (Scoping): 무엇이 이 에이전트, 이 사용자, 이 작업에 관련이 있는지, 반대로 무엇이 단지 근처에서 발생한 노이즈인지
• 감쇠 (Decay): 시간이 지남에 따라 관련성을 잃어 의도적으로 잊어야 하는 것은 무엇인지, 버퍼가 가득 찼을 때 우연히 잘려 나가는 것이 아니라
• 검색 (Retrieval): 주어진 턴(turn)을 위해 무엇이 컨텍스트로 다시 불러와지는지, 그리고 그 이유는 무엇인지

이것들을 차별화되지 않은 하나의 덩어리로 취급하면, 모두가 불평하는 바로 그 실패 모드(failure modes)를 겪게 됩니다. 즉, 중요한 것을 "잊어버리고" 중요하지 않은 것을 "기억하는" 에이전트가 되는 것입니다.

비용이 실제로 발생하는 지점

에이전트 시스템에서 토큰 소비의 대부분은 추론 그 자체 때문이 아니라, 더 이상 자리를 유지할 가치가 없는 컨텍스트를 계속 전달하는 데서 발생합니다. 모든 오래된 사실, 모든 해결된 하위 작업(sub-task), 모든 후속 호출마다 다시 전송되는 사소한 잡담의 턴들이 쌓이게 됩니다. 그리고 공유 버퍼 아키텍처(shared-buffer architecture)에서는 해당 컨텍스트가 여전히 비용을 지불할 가치가 있는지 묻게 만드는 장치가 없기 때문에, 이러한 비용은 조용히 쌓여만 갑니다.

이를 제대로 수행하려면 비용을 사후에 최적화하는 항목이 아니라, 수명 주기 속성 (lifecycle property) 중 하나로 취급해야 합니다.

우리는 방법론과 5가지 프리미티브 (primitives)가 더 나은 접근 방식이라고 주장합니다

저는 이 내용을 23페이지 분량의 논문인 "Agentic Context Management"에 공식적으로 정리했습니다. 이 논문에는 전체 평가 하네스 (evaluation harness)와 기초 연구 데이터가 포함되어 있어, 이 주장은 단순히 개념적인 것에 그치지 않고 직접 검증할 수 있는 내용입니다.

이는 저희가 Synap에서 진행해 온 메모리 작업의 핵심 사고방식과 동일하며, 이제는 데이터를 바탕으로 정리되었습니다.

논문: arxiv.org/abs/2607.21503

수명 주기 프레임워크 (lifecycle framing)가 어디에서 한계에 부딪힌다고 생각하시는지 진심으로 궁금합니다. 특히 범위 설정 (scoping)이 훨씬 더 까다로워지는 멀티 에이전트 시스템 (multi-agent systems)을 운영하시는 분들의 의견을 듣고 싶습니다.