Amazon Bedrock AgentCore Memory 가이드: 전략·namespace와 검색

InYourLeague 리서치 · 2026-08-29

Answer in brief

Amazon Bedrock AgentCore Memory는 세션 범위의 단기 컨텍스트와 전략 기반의 장기 레코드를 namespace로 구성합니다. 검색에는 의미 검색과 구조화된 metadata 필터를 함께 적용할 수 있으며, 실패한 수집은 공식 redrive 절차를 따라야 합니다. 공식 소스는 이 제품에서 선택할 수 있는 모델 ID를 공개하지 않습니다.

Key facts at a glance

Failure modes and verification

FAQ

단기 메모리와 장기 메모리는 어떻게 다릅니까?

단기 메모리는 하나의 세션에서 turn-by-turn 컨텍스트를 유지합니다. 장기 메모리는 여러 세션에서 사용할 선호, 중요한 사실, 요약을 추출해 저장하며, 자세한 개념은 Amazon Bedrock AgentCore Memory 개요에서 확인할 수 있습니다.

Actor와 세션은 어떻게 격리해야 합니까?

세션은 단기 대화 경계로 사용하고, namespace는 사용자나 tenant 같은 주요 엔터티의 지속적인 경계로 사용합니다. Metadata 공식 가이드는 namespace가 주요 엔터티별로 메모리를 격리한다고 설명합니다.

의미 검색은 memory strategy입니까?

제공된 공식 근거는 built-in, built-in with overrides, custom strategy 구성을 설명합니다. 의미 검색은 RetrieveMemoryRecords가 수행하므로, 문서 근거상 strategy 이름이 아니라 검색 동작으로 구분하는 것이 정확합니다. 관련 항목은 장기 메모리 공식 가이드를 참조하십시오.

구조화된 metadata는 언제 필터에 사용할 수 있습니까?

Metadata key를 metadataFilters에서 사용하려면 먼저 indexed key로 선언해야 합니다. 구조화된 metadata 가이드에 따르면 indexed key를 나중에 추가해도 기존 레코드는 자동으로 backfill되지 않습니다.

실패한 수집은 어떻게 redrive하며 어떤 모델 ID를 선택해야 합니까?

공식 장기 메모리 가이드의 “Redrive failed ingestions” 절차를 사용해야 하며, 제공된 발췌문은 구체적인 명령이나 retry limit을 명시하지 않습니다. 공식 소스는 이 제품에서 선택 가능한 모델 ID를 공개하지 않습니다.

Sources and freshness

• Official source
• Official source
• Official source
• Last verified: 2026-08-29

Extended guide

Amazon Bedrock AgentCore Memory를 사용할 때는 두 경계를 명확히 분리해야 합니다. 현재 대화의 즉시 필요한 맥락은 하나의 세션 안에 두고, 여러 세션에서 유지할 지식은 관련 actor 또는 주요 엔터티에 대응하는 namespace에 저장하십시오. 장기 정보가 자동으로 추출될 것이라고 기대하기 전에 memory strategy를 구성하고, 저장된 레코드는 의미 검색과 필요한 metadata 필터를 조합해 검색하는 방식이 핵심입니다.

운영 모델

구현 순서

1. Memory를 생성하고 구성합니다. Memory 리소스를 만든 뒤 하나 이상의 strategy를 추가해야 장기 메모리가 활성화됩니다. 장기 메모리 공식 가이드는 built-in, built-in with overrides, custom strategy 구성을 다룹니다. 각 strategy는 대화에서 추출하여 지속적으로 저장할 정보의 종류를 결정하므로, 보존 목적을 먼저 정한 뒤 선택하는 것이 적절합니다.

2. 격리 경계를 정의합니다. 단기 대화에는 세션 경계를 사용하고, 지속되는 actor 또는 엔터티 데이터에는 namespace를 사용합니다. 같은 actor의 여러 세션에서 유지할 선호나 사실은 장기 메모리 대상이지만, 한 세션의 일시적인 문맥은 단기 메모리 대상입니다. 제공된 공식 발췌문은 actor 또는 session identifier의 구체적인 필드 이름을 명시하지 않으므로, 이 가이드에서 문서화되지 않은 식별자를 임의로 추론해서는 안 됩니다.

3. 구조화된 metadata를 선언합니다. CreateMemory 또는 UpdateMemory로 indexed key를 추가합니다. metadataFilters에는 indexed key만 사용할 수 있습니다. 지원되는 indexed 값 유형은 STRING, STRINGLIST, NUMBER입니다. 하나의 memory에는 최대 10개의 indexed key를 선언할 수 있습니다. 추가한 indexed key는 제거할 수 없으며, 새 key를 추가해도 기존 레코드가 자동으로 backfill되지는 않습니다. 따라서 향후 필터링할 business dimension을 생성 단계에서 검토해야 합니다.

4. Metadata 추출을 구성합니다. Strategy의 memoryRecordSchema.metadataSchema는 memory record를 만들 때 LLM이 대화 내용에서 추출할 metadata를 정의할 수 있습니다. Schema에 포함됐지만 indexed key가 아닌 값은 레코드에 표시될 수 있으나 필터 표현식에는 사용할 수 없습니다. Validation은 high, High, HIGH처럼 의미는 같지만 표기가 다른 값으로 인해 필터 일치가 깨지는 문제를 줄이는 데 사용합니다. Department, compliance level, agent identity처럼 애플리케이션이 이미 알고 있는 분류 값에는 STRICTLY_CONSISTENT를 사용하면 제공된 값이 LLM 추론 없이 그대로 복사됩니다.

5. 콘텐츠를 수집하고 검색합니다. CreateEvent 또는 IngestData로 콘텐츠를 제출하거나, BatchCreateMemoryRecords로 레코드를 직접 생성할 수 있습니다. RetrieveMemoryRecords는 선택적인 metadata 사전 필터와 함께 의미 검색을 수행합니다. ListMemoryRecords는 metadata만을 기준으로 필터링할 때 사용합니다. 한 query에는 최대 5개의 필터가 AND 논리로 적용됩니다. Namespace로 주요 엔터티를 먼저 격리한 뒤, priority, department, channel, time range 같은 세부 business dimension을 metadata로 좁히는 구조입니다.

6. 수집 실패를 처리합니다. 공식 장기 메모리 가이드에는 “Redrive failed ingestions”라는 별도 절차가 있습니다. 실패한 수집은 해당 절차에 따라 redrive해야 합니다. 제공된 발췌문에는 retry command, retry limit, 상태 전이 같은 운영 세부 정보가 없으므로, 지원되지 않은 명령이나 제한을 만들어내지 않아야 합니다.

배포 전 체크리스트

• 단기 컨텍스트가 하나의 세션 범위로 제한되어 있습니다.
• 장기 레코드가 actor 또는 주요 엔터티에 맞춘 namespace를 사용합니다.
• 검색 필터에 사용할 모든 metadata key가 indexed key로 선언되어 있습니다.
• 통제된 값에는 validation 또는 적절한 STRICTLY_CONSISTENT 설정이 적용되어 있습니다.
• 의미 검색과 metadata 필터 검색을 각각 검증했습니다.
• 실패한 수집의 redrive 절차가 운영 문서에 포함되어 있습니다.

검증 범위

제공된 공식 문서를 2026-08-29 기준으로 검증했습니다. 공식 소스는 이 제품에서 선택 가능한 모델 ID를 공개하지 않습니다. Retained reference data의 정확한 표현은 다음과 같습니다. “The official source does not publish a selectable model ID for this product.”

모델 제공 범위 안내: 공식 출처는 선택 가능한 모델 ID를 지정하지 않습니다.