에이전트 메모리가 실제로 저장하는 것, 그리고 채팅 기록이 메모리가 아닌 이유
요약
AI 에이전트의 효율적인 운영을 위해 대화 기록과 메모리의 차이를 정의하고, 작업 메모리와 장기 메모리의 구조적 역할을 설명합니다. 에이전트가 불필요한 노이즈를 줄이고 검증된 지식만을 축적하여 성능을 유지하는 전략을 다룹니다.
핵심 포인트
- 대화 기록은 로그일 뿐이며, 진정한 메모리는 구조화된 지식의 기록임
- 작업 메모리는 휘발성 컨텍스트를, 장기 메모리는 검증된 지식을 관리함
- 효과적인 메모리 관리를 위해 불필요한 추론 과정은 버리고 핵심 결과만 저장해야 함
- 멀티 에이전트 시스템에서는 공유 메모리 버스나 네임스페이스를 통한 협업이 필요함
자율적으로 작동하는 AI 에이전트들은 컨텍스트 윈도우 (context window) 문제처럼 보이지만 실제로는 그렇지 않은 벽에 부딪힙니다. 프로세스가 몇 시간 동안 실행되다가 중단된 후 다시 돌아왔을 때, 이미 완료한 작업을 반복하거나 한 시간 전에 내린 결정과 모순되는 경로를 택하곤 합니다. 컨텍스트 윈도우를 더 크게 만든다고 해서 해결되지 않는데, 그 이유는 저장되고 있는 대상이 애초에 올바른 것이 아니었기 때문입니다.
대화 기록 (Conversation history)은 무엇이 말해졌는지에 대한 로그입니다. 에이전트 메모리 (Agent memory)는 무엇을 배웠는지, 무엇을 시도했는지, 무엇이 작동했는지, 무엇이 실패했는지, 각 작업의 현재 상태는 무엇인지, 그리고 관련된 엔티티 (entities)들이 서로 어떻게 관계를 맺고 있는지에 대한 구조화된 기록입니다. 이것들은 수명 주기가 다른 서로 다른 데이터 구조이며, 하나를 다른 하나로 취급하는 것이 대부분의 에이전트 구축이 잘못되는 지점입니다.
작업 메모리 (Working Memory) vs 장기 메모리 (Long Term Memory)
작업 메모리 (Working memory)는 단일 작업 실행을 위한 활성 컨텍스트 (active context)입니다. 즉, 현재의 목표, 계획, 중간 결과, 에이전트가 진행 중인 단계, 그리고 아직 검증되지 않은 새로 발견된 정보 등을 포함합니다. 이는 빠르고, 규모가 작으며, 휘발성 (volatile)입니다. 실제로 이는 컨텍스트 윈도우 (context window)와 하나의 에이전트 루프 동안 유지하는 스크래치패드 (scratchpad) 또는 상태 변수 (state variables)에 매핑됩니다.
장기 메모리 (Long term memory)는 모든 세션에 걸쳐 축적된 검증된 지식의 영구 저장소입니다. 여기에는 환경에 대한 사실 (어떤 서비스가 어떤 데이터베이스에 의존하는지, 각 컴포넌트의 소유자가 누구인지), 학습된 절차 (지난번에 커넥션 풀 (connection pool) 문제를 실제로 진단했던 단계의 순서), 그리고 에피소드 기록 (특정 사건, 그 원인, 그 해결책)이 담깁니다. 검색 (retrieval)이 하나의 단계이므로 접근 속도는 더 느리지만, 재시작 후에도 유지되며 계속 성장합니다.
흥미로운 점은 이들 사이의 승격 (promotion) 과정입니다. 단순한 (naive) 접근 방식은 대화 전체를 장기 저장소 (long term storage)에 쏟아붓는데, 이는 가치가 낮은 중간 단계들로 저장소를 채워 시스템이 가동되는 시간이 길어질수록 검색 (retrieval) 품질을 조용히 저하시킵니다. 효과적인 접근 방식은 선택적입니다. 작업이 완료되면 결과, 핵심 결정 사항, 그리고 놀라운 점들을 저장한 다음, 그 결과에 도달하기까지의 단계별 추론 (step by step reasoning)은 폐기합니다. 이는 수면 중에 일어나는 기억 공고화 (memory consolidation)와 대략적으로 유사하며, 패턴은 유지하고 노이즈는 버리는 방식입니다.
여러 에이전트가 하나의 저장소를 공유하는 방법
멀티 에이전트 시스템 (Multi agent systems)은 단일 에이전트는 결코 직면하지 않는 메모리 문제를 야기합니다. 공유 저장소가 없다면, 동일한 사건을 조사하는 두 에이전트는 독립적으로 동일한 사실을 재발견하게 될 것이며, 상대방이 배제한 정보로부터 어떤 이득도 얻지 못할 것입니다. 알아둘 만한 몇 가지 패턴이 있습니다.
공유 메모리 버스 (shared memory bus)는 모든 에이전트에게 하나의 저장소에 대한 읽기 및 쓰기 권한을 부여합니다. 단순하며, 에이전트들이 상호 보완적인 역할을 수행하고 쓰기 충돌 (conflicting writes)의 위험이 낮을 때 효과적입니다. 약점은 오염 (pollution)입니다. 한 에이전트가 장황하고 신뢰도가 낮은 노트를 작성하면 모든 사용자의 검색 품질을 저하시킵니다.
범위가 지정된 네임스페이스 (Scoped namespaces)는 각 에이전트에게 자신만의 쓰기 공간을 부여하되, 다른 에이전트의 공간에 대한 읽기 권한을 제공합니다. 에이전트 A는 연구 (research) 영역에 쓰고, 에이전트 B는 실행 (execution) 영역에 쓰며, 둘 다 양쪽 모두를 읽을 수 있습니다. 이는 공유를 유지하면서 쓰기 충돌을 방지하며, 조정자 (coordinator)가 검증된 발견 사항을 공유 네임스페이스로 승격시킬 수 있습니다.
블랙보드 패턴 (blackboard pattern)은 관찰 사항을 공통 공간에 게시하며, 제어 컴포넌트 (control component)는 보드에 올라온 내용을 바탕으로 다음에 어떤 에이전트를 실행할지 결정합니다. 이벤트 기반 업데이트 (Event driven updates)는 여기서 더 나아갑니다. 새로운 메모리가 이벤트를 발생시키면, 해당 전문 분야와 관련된 에이전트를 깨웁니다. 이는 조정 오버헤드 (coordination overhead)를 줄여주지만, 에이전트 A의 발견이 에이전트 B를 트리거하고, 에이전트 B의 발견이 다시 에이전트 A를 트리거하는 상황을 방지하기 위해 서킷 브레이커 (circuit breakers)가 필요하다는 대가가 따릅니다.
패턴이 무엇이든 충돌은 불가피하며, '마지막 쓰기 승리 (last write wins)' 방식은 잘못된 기본 설정입니다. 두 에이전트가 서로 모순되는 설명을 기록할 때는 출처(source attribution)와 신뢰도 점수 (confidence scores)를 포함하여 둘 다 유지하십시오. 나중에 교차 검증 (corroboration)을 통해 하나는 점수를 높이고 다른 하나는 낮추면, 검색 순위 (retrieval ranking)가 아무것도 조용히 삭제되지 않은 상태에서 문제를 해결합니다.
대화 기록(Transcripts) 대신 사실(Facts)을 체크포인팅하기
충분히 오래 실행되는 에이전트는 반드시 중단됩니다. 체크포인팅 (Checkpointing)은 이에 대한 표준적인 해답입니다. 각 중요한 단계마다 현재의 목표, 계획, 완료된 단계, 그리고 지금까지의 결과를 기록하십시오. 모든 도구 호출 (tool call) 후에 체크포인트를 생성하면 모든 작업에 지연 시간 (latency)이 발생하지만 세밀한 복구 (fine grained recovery)가 가능합니다. 작업 경계 (task boundaries)에서 체크포인트를 생성하면 오버헤드 (overhead)는 훨씬 낮아지지만 복구 단위는 더 거칠어지며, 이는 대부분의 시스템에 적합한 트레이드오프 (trade-off)입니다.
중요한 세부 사항은 체크포인트에 무엇을 담느냐 하는 것입니다. LLM 에이전트는 결정론적 상태 (deterministic state)를 갖지 않으므로, 저장된 대화 기록을 재생 (replaying)하는 것은 이미 실행되었던 것과는 다른 연속성을 만들어낼 수 있습니다. 대신 사실적인 상태 (factual state)를 저장한 다음, 재개 시 해당 사실들로부터 새로운 컨텍스트 (context)를 다시 구축하십시오. 재시작된 에이전트는 자신을 엉뚱한 곳으로 이끌 수 있는 대화 기록 (transcript)이 아니라, 알려진 사실로부터 결정을 내리게 됩니다.
이벤트 소싱 (Event sourcing)은 대안이 될 수 있습니다. 모든 행동과 관찰을 불변의 이벤트 (immutable event)로 로그를 남기고, 이를 재생하여 상태를 재구성하는 방식입니다. 이를 통해 완전한 감사 추적 (audit trail)과 과거의 어느 시점이든 조사할 수 있는 능력을 얻을 수 있지만, 로그가 쌓임에 따라 재생 시간이 늘어난다는 비용이 따릅니다. 따라서 오래 실행되는 에이전트는 주기적인 스냅샷 압축 (snapshot compaction)이 필요합니다. 이 방식은 컴플라이언스 (compliance)를 위한 감사 추적이 필요하거나, 사후에 중대한 결정을 검토해야 할 때 그 복잡성을 정당화할 수 있습니다.
요약 (The Takeaway)
만약 에이전트가 무언가를 잊어버린다면, 던져야 할 질문은 컨텍스트 윈도우 (Context Window)의 크기가 아닙니다. 그것은 대화 기록 (Transcript) 이외의 무언가가 기록되고 있는지에 대한 질문입니다. 실시간 작업을 위한 작업 메모리 (Working memory), 작업 이후에도 살아남은 정보를 위한 장기 메모리 (Long term memory), 이들 사이의 선택적 승격 (Selective promotion), 채팅이 아닌 사실을 보유하는 체크포인트 (Checkpoints), 그리고 하나 이상의 에이전트가 관여할 때 신뢰도 점수 (Confidence scores)를 포함하는 네임스페이스 (Namespaces)가 필요합니다.
패턴에 대한 전체적인 분석, 실패 모드 (Failure modes) 이면의 벤치마크, 그리고 구현 가이드: https://www.adaptiverecall.com/ai-agent-memory/
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기