Designing lifecycle policies for AgentCore memory

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore의 장기 실행 에이전트는 기억 유형에 맞춘 TTL 만료, 관련성 점수화, LLM 통합으로 오래된 맥락의 누적을 관리할 수 있다.

📌 핵심 요약

• 장기간 누적된 기억은 응답 품질 저하와 규정 준수 위험을 유발하며, 원문은 AgentCore memory, AWS Step Functions, Amazon Bedrock을 활용한 야간 수명주기 워크플로를 제시한다.
• 기억은 대화 이력을 담는 일화 기억, 사실과 선호를 담는 의미 기억, 작업 절차를 담는 절차 기억으로 나뉘며, 일화 기억부터 우선 만료하고 절차 기억은 가장 신중하게 삭제하도록 권고한다.
• TTL 만료는 점수화와 통합보다 먼저 실행되며 일화 기억의 기본값은 90일이다. AgentCore memory에는 내장 자동 삭제 TTL이 없어 생성 시각 필터로 만료 대상을 조회한 뒤 삭제한다.
• 관련성 점수는 생성 최신성, 마지막 접근 최신성, 접근 빈도를 결합하며 기본 설정은 pruneDays 45일과 임계값 0.3이다. AWS CloudTrail의 GetMemoryRecord 이벤트와 Amazon S3의 접근 이력으로 실제 이용 정보를 보완한다.
• LLM 통합은 낮은 점수의 관련 기억을 하나의 의미 기억으로 압축하고 저장한 뒤 원본을 삭제한다. Amazon Bedrock 호출이 실패하면 원본을 유지하고, 삭제 실패는 수동 검토를 위해 기록한다.

🧩 주요 포인트

1. 기억 유형별 가치와 유효기간의 차이 → 일화·의미·절차 기억에 보존 및 삭제 기준을 다르게 적용할 필요.
2. TTL과 관련성 점수의 상호 보완 → 보존 기한을 넘긴 기억을 먼저 제거하고, 남은 기억은 최신성과 실제 이용 신호로 평가.
3. LLM 통합 후 원본 삭제와 호출 실패 시 원본 유지 → 중복 정보를 줄이면서 통합 실패에 따른 원본 손실을 방지.

🧠 상세 정리

1. 장기 운영에서 드러나는 기억 누적 문제

에이전트가 대화마다 기억을 생성하면 수주 또는 수개월 뒤에는 이미 해결되었거나 효력을 잃은 정보가 계속 응답에 영향을 줄 수 있다. 원문은 고객 지원 에이전트가 4개월 전에 끝난 청구 분쟁을 진행 중인 문제로 취급한 사례와, 다른 에이전트가 교체된 운영 지침에 근거해 오래된 배포 조언을 반복한 사례를 제시한다. 이를 해결하기 위한 기억 수명주기 관리는 기억을 지속적으로 점수화하고 통합하며 삭제하는 방식이다. 제안된 구성은 AgentCore memory, AWS Step Functions, Amazon Bedrock을 이용해 야간에 실행되며 AWS CDK 스택과 관련 코드도 안내한다. 주요 대상은 상호작용 데이터가 많이 쌓이는 고객 지원·영업·IT 헬프데스크 에이전트이며, 이용량이 적은 개인 비서는 TTL 만료와 GDPR 준수부터 시작할 수 있다고 설명한다.

2. 세 가지 기억 유형과 보존 우선순위

일화 기억은 과거 대화에서 발생한 일을 기록하며, 타임스탬프와 개별 세션에 연결되고 생성량이 많다는 특징을 가진다. AgentCore memory의 Summary와 Episodic 전략이 이러한 정보를 저장하며, 단기적인 대화 연속성에는 유용하지만 시간이 지날수록 개별 기록의 관련성이 낮아져 우선 만료 대상으로 제시된다. 의미 기억은 특정 대화에서 분리해 추출한 사실과 선호로, 여러 일화적 관찰을 하나의 권위 있는 사실로 합치는 통합에 적합하며 더 오래 보존하도록 권고한다. 절차 기억은 학습된 작업 흐름과 도구 사용 패턴으로, 일부 용도에서는 가장 가치가 높아 보존 기간이 가장 길고 삭제 기준도 가장 엄격해야 한다. AgentCore memory는 절차 지식을 일화 기억에 연결된 성찰로 저장하며, 실제 업무 절차가 바뀔 때 해당 지식의 유효성을 확인해야 한다.

3. TTL 만료의 실행 순서와 구현 제약

첫 번째 정책은 설정된 TTL보다 오래된 기억을 자동으로 삭제하며, 일화 기억의 기본 보존 기간은 90일이다. TTL은 해당 기억이 여전히 유용한지 판단하지 않지만 기억의 무제한 누적을 제한하고 규정 준수를 지원하는 역할을 한다. 운영 환경에서는 Summary 기억에 30~60일, 의미 기억에 6~12개월을 적용하고 절차 기억에는 TTL을 두지 않는 방안을 검토하도록 권고하지만, 제공 구현은 단일 memoryTtlDays 매개변수에서 출발한다. AgentCore memory에는 내장 자동 삭제 TTL이 없으므로 ListMemoryRecords에서 시스템 생성 시각 필드인 x-amz-agentcore-memory-createdAt과 BEFORE 필터를 사용해 기한이 지난 기록만 조회한다. 만료 처리를 점수화와 통합보다 먼저 수행해 이미 삭제되어야 할 기억에 계산 자원을 쓰는 일을 줄인다.

4. 관련성 점수의 구성과 감쇠 방식

두 번째 정책은 기억의 생성 시점, 마지막 접근 시점, 누적 접근 횟수를 결합해 관련성 점수를 계산한다. 생성 이후 경과 시간과 마지막 접근 이후 경과 시간에는 각각 지수 감쇠를 적용하고, 접근 빈도에는 기준 횟수 대비 비율을 사용하되 최대값을 1로 제한한다. 기본 가중치는 생성 최신성 0.4, 마지막 접근 최신성 0.35, 접근 빈도 0.25이며, 세 가중치의 합이 1일 때 점수는 0~1 범위에 놓인다. 이 구조에서는 오래전에 생성된 기억이라도 최근에 사용되었고 반복적으로 조회되었다면 높은 점수를 유지할 수 있다. 점수가 설정된 임계값 아래로 내려가면 정책 설정에 따라 통합 또는 삭제 대상으로 표시되므로, 생성 시각만으로 일괄 판단하는 TTL과 다른 평가 신호를 제공한다.

5. pruneDays와 접근 빈도 매개변수

원문은 운영자가 원시 감쇠 상수를 직접 다루는 대신, 접근하지 않은 기억의 점수가 관련성 임계값 아래로 떨어지는 대략적인 기간인 pruneDays를 설정하도록 한다. 감쇠율은 임계값의 자연로그에 음수를 취한 값을 pruneDays로 나누어 계산하며, 기본값인 45일과 임계값 0.3을 적용하면 약 0.02676이 된다. 변환 함수는 pruneDays가 양수이고 임계값이 0과 1 사이인지 검증하며, 이 기간은 접근 빈도 등을 포함한 모든 기억의 정확한 삭제 시점을 뜻하지 않는다. 접근 빈도 항의 기준인 MAX_ACCESS_BASELINE은 기본 50회이고, 횟수가 이 기준에 도달하면 해당 항의 비율은 더 커지지 않는다. 운영자는 반복 조회가 중요한 업무에서 빈도 가중치를 높이거나 최신 정보가 중요한 업무에서 생성 최신성 가중치를 높이는 방식으로 평가 기준을 조정할 수 있다.

6. 업무별 관련성 유지 기간의 출발점

관련성이 유지되는 기간은 에이전트가 다루는 업무에 따라 달라지므로 원문은 다섯 가지 유형에 서로 다른 pruneDays 시작값을 제시한다. 실시간 지원 봇은 문의가 수시간 또는 수일 안에 해결된다는 이유로 7일, 영업·온보딩 에이전트는 거래가 수주 단위로 마무리되고 오래된 잠재 고객 정보가 맥락을 흐릴 수 있다는 이유로 21일을 권고한다. 일반 비서는 혼합된 작업에 대한 균형을 고려해 45일, IT 헬프데스크·운영 에이전트는 장애 패턴의 계절적 반복을 고려해 90일을 제시한다. 법률·규정 준수 자문 에이전트에는 선례의 관련성이 수개월 지속된다는 이유로 180일을 제안한다. 이 수치는 고정된 보존 의무나 일괄 삭제 기한이 아니라 관련성 감쇠 설정의 권장 출발점이며, 원문은 모든 임계값을 에이전트의 필요에 맞게 조정할 수 있다고 명시한다.

7. CloudTrail과 S3를 통한 실제 접근 이력 수집

AgentCore memory API의 MemoryRecordSummary에는 lastAccessedAt 필드가 없으므로, 제공된 구성은 AWS CloudTrail을 이용해 실제 접근 데이터를 확보한다. CDK 스택은 고급 이벤트 선택기로 GetMemoryRecord 데이터 이벤트를 수집하는 추적을 설정하고, 기억 식별자와 타임스탬프가 포함된 로그를 Amazon S3 버킷으로 전달한다. Memory Scorer는 실행을 시작할 때 최근 25시간의 CloudTrail 로그 파일을 조회하고 압축을 풀어 기록별 마지막 접근 시각과 접근 횟수를 집계한다. 또한 실행 사이에 누적 이력을 유지하기 위해 접근 이력을 Amazon S3에 저장하고, 새로 수집한 횟수를 과거 횟수와 병합한다. 따라서 접근 빈도 항은 하루 동안의 이용량만 반영하는 값이 아니라 누적 이용 신호가 되며, 점수화에 필요한 접근 정보의 공백을 별도 수집과 저장으로 보완한다.

8. LLM 통합과 실패 시 원본 보존

세 번째 정책은 낮은 점수를 받은 기억을 삭제하기 전에 Amazon Bedrock을 이용해 관련 기록들을 하나의 간결한 의미 기억으로 합치는 기회를 제공한다. 원문은 배포 선호에 관한 다섯 개의 일화 기억을 하나의 권위 있는 사실로 압축하는 예를 들며, 프롬프트는 핵심 사실과 사용자 선호 및 실행 가능한 지식을 보존하고 중복과 오래된 정보를 제거하도록 지시한다. 모델에는 통합된 요약, 0~1 범위의 통합 품질 신뢰도, 보존한 핵심 사실 목록을 담은 JSON을 출력하도록 요청한다. 시스템은 통합 결과를 AgentCore memory에 저장한 다음 원본을 삭제하며, Amazon Bedrock 호출이 실패하면 원본을 변경하지 않고 유지한다. 삭제 실패는 수동 검토를 위해 기록하지만, 제공된 본문은 이 설명 직후 중단되어 신뢰도에 따른 후속 처리나 이후 구현 세부 사항은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• TTL은 보존 기한을 강제하고 관련성 점수는 이용 가치를 평가하므로, 자주 쓰이는 기억도 TTL을 넘기면 먼저 삭제되는 정책 구조다.
• 실제 접근 정보를 활용하려면 기억 저장소 외에 CloudTrail 수집과 S3 이력 보존이 필요하며, 누적 접근 이력의 유지가 빈도 점수의 근거가 된다.
• 통합은 낮은 점수의 기록에서도 핵심 지식을 보존할 기회를 제공하지만, 제공된 본문만으로는 모델이 출력하는 신뢰도가 처리 결정에 어떻게 사용되는지 알 수 없다.

✅ 액션 아이템

• 일화 기억·의미 기억·절차 기억의 가치와 유효기간을 기준으로 보존 및 삭제 기준 검토.
• TTL 90일, pruneDays 45일, 임계값 0.3을 출발점으로 업무에 맞는 설정 검토.
• LLM 통합 결과 저장 후 원본 삭제, Amazon Bedrock 호출 실패 시 원본 유지, 삭제 실패 기록 동작 확인.

❓ 열린 질문

• 일화 기억·의미 기억·절차 기억의 보존 및 삭제 기준을 해당 업무에서 어떻게 구분할 것인가?
• TTL 90일, pruneDays 45일, 임계값 0.3은 해당 에이전트의 정보 유효기간과 이용 패턴에 적합한가?
• LLM 통합 결과가 원본의 핵심 정보를 보존했는지 어떤 기준으로 판단할 것인가?