원문은 echonerve.com에서 처음 게시되었습니다.

Canonical URL: https://echonerve.com/why-ai-agents-need-memory/

만약 여러분이 Claude, GPT, 또는 Gemini를 기반으로 에이전트를 구축하고 있으며, 세션 전반에 걸쳐 상태(state)를 유지하기 위해 큰 컨텍스트 윈도우 (Context Window)에 의존하고 있다면, 해당 패턴을 프로덕션(production) 환경으로 확장하기 전에 반드시 알아야 할 벤치마크가 있습니다.

컨텍스트 부패 (The context rot) 문제

Chroma의 2025년 7월 연구는 18개의 프런티어 모델(frontier models) — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등을 포함 — 을 대상으로 바늘 찾기(needle-retrieval), 방해 요소(distractor), 건초더미 구조(haystack-structure), 그리고 대화형 QA 테스트를 수행했습니다. 입력 길이가 길어짐에 따라 모델이 하드 컨텍스트 제한(hard context limit)에 도달하기도 전부터, 심지어 아주 단순한 작업에서도 성능이 저하되었습니다. 오류가 발생하는 것이 아니라, 출력 품질이 꾸준히 나빠지는 방식입니다. 이는 아무런 경고 없이 발생하기 때문에 프로덕션 환경에서 포착하기 가장 어려운 실패 모드(failure mode)입니다.

더 이상한 결과는 다음과 같습니다: 18개 모델 모두에서, 논리적으로 일관된 문서보다 섞여 있는(shuffled) 문서에서 성능이 더 좋게 나타났습니다. 만약 여러분이 구조화된 로그, 순서가 있는 대화 기록, 또는 잘 정리된 지식 베이스를 거대한 컨텍스트 윈도우에 밀어 넣으며 그것이 데이터베이스처럼 작동하기를 기대하고 있다면, 이 연구 결과는 구조화가 오히려 여러분에게 불리하게 작용할 수 있음을 시사합니다.

작업 메모리 (Working memory) vs 외부 메모리 (External memory) vs 절차적 메모리 (Procedural memory)

Agent Stack 프레임워크(EchoNerve의 AI 시스템 모델: Models -> Tools -> Memory -> Agents -> Workflows -> Applications)는 메모리를 세 가지 별개의 구성 요소로 취급합니다:

작업 메모리 (Working memory):    컨텍스트 윈도우 (Context Window) 그 자체
                    -> 수명: 하나의 세션
                    -> 실패 모드: 채워짐에 따른 컨텍스트 부패 (context rot)
...

대부분의 에이전트 구현은 첫 번째 요소만을 구축하며, 벤치마크 데이터에 따르면 이 요소가 부하 상황에서 가장 심하게 저하됩니다.

검색(Retrieval)이 밀어넣기(Stuffing)보다 낫다 - 수치로 확인하기

LoCoMo (1,540개 질문: single-hop, multi-hop, open-domain, temporal)와 LongMemEval (500개 질문)은 정확히 이 점을 테스트하기 위해 특별히 제작된 벤치마크 (benchmarks)입니다. Mem0가 발표한 2026년 결과에 따르면, 동일한 벤치마크에서 전체 컨텍스트를 밀어넣는 (full-context-stuffing) 베이스라인이 약 500,000개의 토큰 (tokens)을 필요로 하는 반면, Mem0는 검색 (retrieval)당 평균 7,000개 미만의 토큰을 사용하면서 LoCoMo에서 91.6%를 기록했습니다. p95 지연 시간 (latency)의 경우, 밀어넣기 방식이 17.12초인 것에 비해 검색 방식은 1.44초로, 91%의 감소를 보여주었습니다. 이는 벤더 (vendor)가 보고한 수치이므로 (적절히 감안하여 해석해야 하지만), Chroma의 독립적이고 적대적인 (adversarial) 조사 결과와 동일한 방향을 가리키고 있습니다. 즉, 작고 관련성 높은 검색 결과가 정확도, 지연 시간, 토큰 비용 측면 모두에서 거대한 밀어넣기 방식의 윈도우 (windows)보다 우수하다는 것입니다.

실제로 무엇을 구축해야 하는가

2026년 중반 기준, 세 가지 현실적인 기질 (substrate) 옵션이 있습니다:

1. 호스팅된 메모리 서비스 (Hosted memory services) (예: Mem0) - 통합이 가장 빠르고 인프라를 소유하지 않고도 검색 품질을 확보할 수 있지만, 스택 (stack)의 핵심 레이어가 제3자 API 뒤에 위치하게 됩니다.
2. 오픈 소스 상태 유지 프레임워크 (Open-source stateful frameworks) (예: Letta, 이전의 MemGPT) - 에이전트 자체가 지속적이고 상태를 유지하는 (stateful) 객체입니다. 더 많은 제어가 가능하지만, 운영해야 할 인프라가 더 많습니다.
3. 일반 파일 (Plain files) - 버전 관리되는 저장소에 markdown/JSON 형태로 저장하며, 작업별로 선택적으로 로드합니다. 규모가 커질 때 가장 정교함이 떨어지지만, 모든 메모리 항목이 사람이 읽을 수 있고, git에서 차이점 (diff)을 비교할 수 있으며, 파일을 열어 감사 (auditable)할 수 있습니다.

잘못된 답은 기본값(default)을 사용하는 것입니다. 즉, 아무런 기질도 없이 매번 모든 것을 컨텍스트 윈도우 (context window)에 쑤셔 넣는 방식입니다. 이는 Chroma의 연구가 설명하는 바로 그 구성이며, 현재 프로덕션 (production) 환경에서 실행되는 대부분의 에이전트가 여전히 채택하고 있는 방식입니다.

이것이 출력 품질 그 이상으로 중요한 이유

이를 의도적으로 구축해야 하는 두 번째 이유는 감사 가능성 (auditability) 때문입니다. Anthropic의 Managed Agents (2026년 4월)는 감사 추적 (audit trails) 기능이 포함된 지속적이고 버전 관리되는 메모리 저장소를 출시했습니다. 즉, 메모리를 내보내고, 차이점을 비교하고, 검사할 수 있는 파일 형태로 제공합니다. 자율 에이전트가 급증함에 따라 (Gartner는 2028년까지 Fortune 500대 기업당 15만 개 이상의 에이전트가 존재할 것으로 예측합니다), 실제로 검사할 수 있는 메모리 레이어는 에이전트가 무엇을 왜 했는지에 대한 블랙박스 (flight recorder)와 가장 유사한 역할을 하게 될 것입니다.

출처 및 전체 프레임워크를 포함한 전체 글: https://echonerve.com/why-ai-agents-need-memory/