에이전트 메모리의 규모 확장: 네임스페이스 디자인 패턴

AWS의 AgentCore Memory는 멀티에이전트 시스템에서 발생하는 메모리 관리 문제를 해결하기 위한 매니지드 서비스로, 핵심은 **네임스페이스(namespace) 계층 설계**에 있습니다. 네임스페이스는 `/{tenant}/{user}/{agent}/{session}` 같은 슬래시 기반 경로 구조로 메모리를 논리적으로 격리하며, 변수 치환(`{actorId}`, `{sessionId}`, `{strategyId}`)을 통해 런타임에 동적으로 메모리 범위를 결정합니다. 단기 메모리(short-term)는 세션 내 대화 컨텍스트를, 장기 메모리(long-term)는 사용자 선호도·사실(fact)·요약본을 저장하며, 각각에 대해 시맨틱 검색(semantic), 사용자 선호도(user preference), 요약(summary) 같은 추출 전략(extraction strategy)을 매핑할 수 있습니다. IAM 정책에서는 리소스 ARN의 네임스페이스 부분에 와일드카드와 `${aws:PrincipalTag/...}` 같은 조건 키를 결합해, 같은 메모리 저장소를 공유하면서도 테넌트·사용자별로 접근을 격리할 수 있습니다.

실무적으로 이 패턴은 **멀티테넌트 SaaS형 에이전트**를 만들 때 가장 큰 임팩트를 가집니다. 기존에는 각 테넌트마다 별도의 벡터 DB 인덱스를 만들거나 애플리케이션 레이어에서 필터링을 강제해야 했는데, 이는 권한 분리 실패 시 곧바로 정보 유출(cross-tenant leakage)로 이어졌습니다. AgentCore Memory의 네임스페이스 + IAM 조합을 사용하면 권한 경계가 인프라 계층에서 강제되므로, 애플리케이션 버그가 있어도 IAM이 차단해주는 **다층 방어(defense in depth)** 가 가능합니다. 또한 협업형 에이전트(예: 영업 에이전트와 지원 에이전트가 동일 고객 컨텍스트 공유) 시나리오에서 `/shared/{customerId}` 같은 공용 네임스페이스를 정의해 선택적 공유가 가능해, RAG 파이프라인을 직접 구축하던 비용을 크게 줄여줍니다.

한국 개발자가 도입할 때 주의할 점은 세 가지입니다. 첫째, **네임스페이스 설계는 사후 변경이 매우 비싸므로** 초기에 테넌트·역할·기능 축을 신중히 정해야 하며, 일반적으로 `/{org}/{user}/{agent}/{memoryType}` 구조에서 출발해 필요 시 `/shared`, `/global` 같은 가지를 추가하는 패턴이 안전합니다. 둘째, IAM 정책에서 와일드카드(`*`)를 부주의하게 쓰면 동일 부모 네임스페이스의 모든 자식이 노출되므로, `Condition` 블록의 `StringLike`와 `PrincipalTag`를 적극 활용해 테스트 환경에서 권한 경계를 반드시 검증해야 합니다. 셋째, 추출 전략별로 LLM 호출 비용과 지연시간이 다르기 때문에 채팅 로그처럼 양이 많은 데이터에 무분별하게 semantic 전략을 적용하지 말고, 요약(summary) 위주로 운용하다가 필요한 영역에만 시맨틱 추출을 켜는 점진적 도입이 비용 측면에서 유리합니다. AgentCore가 아직 서울 리전 정식 지원 여부와 데이터 잔존 정책(retention)도 도입 전 반드시 확인해야 할 항목입니다.