AlloyDB 및 Memorystore for Valkey에서 장기 AI 에이전트 메모리를 구현하는 방법

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

엔터프라이즈 AI 에이전트가 복잡하고 며칠에 걸친 워크플로와 장기 작업을 실행하려면 영구 메모리가 필요합니다. 이 블로그에서는 단기 버퍼 메모리용 Memorystore for Valkey와 장기 영구 메모리용 AlloyDB AI를 사용하는 2계층 메모리 아키텍처가 중요한 데이터와 엔터프라이즈 가드레일을 유지하면서 토큰 지출을 최대 70%까지 줄이는 데 어떻게 도움이 되는지 살펴봅니다.

사용자의 휴가 예약을 돕도록 설계된 맞춤형 여행 에이전트를 빌드한다고 상상해 보세요. 사용자는 며칠에 걸쳐 에이전트와 여러 차례 상호작용하며 여행 일정 브레인스토밍부터 실제 구매 의도 관련 질문까지 다양한 질문을 합니다. 진정으로 원활한 사용자 경험을 제공하려면 이 에이전트는 이전 세션에서 설정된 항공편 선호도(예: '직항 항공편만'), 호텔 예산, 식단 제한 사항(예: '글루텐 프리 식사 옵션 필요')을 기억해야 합니다. 더 중요한 것은 대화가 관광지 추천과 일정 계획과 같은 세부 사항으로 깊이 들어가더라도 이러한 핵심 사실을 계속 유지해야 한다는 점입니다. 에이전트는 모든 후속 질문과 방문할 장소에 대한 흥미로운 세부정보로 인해 사용자의 기본적인 요구사항과 결정을 잊거나 덮어쓰지 않도록 해야 합니다. 

스테이트풀(Stateful) 워크플로는 본질적으로 LLM의 스테이트리스(Stateless) 특성과 충돌합니다.

AI 에이전트는 멀티턴 대화와 장기 실행 워크플로에 사용되지만, 대규모 언어 모델(LLM)은 세션 간에 상태를 유지하지 않습니다. 사용자가 며칠 후 다시 에이전트를 사용하면 모델은 빈 컨텍스트 윈도우로 시작합니다. 애플리케이션이 장기 에이전트 메모리를 사용하여 과거 컨텍스트를 재구성하도록 빌드되지 않은 경우, 사용자는 매번 목표와 컨텍스트를 다시 설명해야 하므로 실망스럽고 단편적인 경험을 하게 됩니다.

이제 백만 토큰 규모의 컨텍스트 윈도우가 표준이 되면서 이 문제에 대한 일반적인 해결 방법은 '컨텍스트 스터핑'입니다. 즉, 원시 채팅 기록부터 도구 실행 로그에 이르기까지 프롬프트에 들어갈 수 있는 모든 내용을 턴마다 덤프하는 것입니다. 실제로 이는 AI 모델 사용 초기에 흔히 볼 수 있는 패턴이었습니다. 하지만 이러한 임시방편은 규모가 커지면 금방 문제가 됩니다. 메시지마다 토큰 비용이 배로 늘어나고, 간단한 프롬프트인데도 응답 시간이 30초 이상으로 길어질 수 있으며, 모델이 산더미 같은 프롬프트 텍스트에 묻힌 중요한 요청 사항을 간과하게 되어 '중간에서 길을 잃는' 성능 저하를 겪기 시작합니다.

또 다른 일반적인 해결 방법은 롤링 요약을 사용하는 것입니다. LLM에 이전 메시지를 주기적으로 요약 단락으로 압축하도록 요청하는 것입니다. 이렇게 하면 프롬프트 크기가 줄어들지만, LLM 기반 요약은 본질적으로 정보 손실이 발생합니다. 몇 차례 압축을 거치면 미묘하지만 중요한 세부정보가 백그라운드 노이즈로 간주되어 필터링됩니다. 몇 차례 대화가 오가고 나면 에이전트는 앞서 설정한 정확한 제약 조건을 은연중에 위반합니다. 한마디로, 이전 대화나 멀티턴 작업의 메모리를 유지하면서도 사용자 경험을 저하시키거나 새로운 병목 현상을 일으키지 않는 더 확장 가능한 접근 방식이 필요합니다.

2계층 메모리 아키텍처 구현

가드레일과 제약 조건을 준수하는 신뢰할 수 있고 비용 효율적인 엔터프라이즈 에이전트를 빌드하려면 2계층 메모리 아키텍처를 사용하는 것이 좋습니다.

• 단기 세션 버퍼: 토큰 제한 슬라이딩 윈도우를 사용하여 활성 대화 턴을 메모리에 캐시하므로 여러 라운드에 걸쳐, 심지어 기기 간에도 컨텍스트 윈도우 크기를 안정적으로 유지하면서 최신 메시지를 최신 상태로 유지할 수 있습니다. 이 계층에서는 매 턴마다 1밀리초 미만의 높은 처리량 조회가 필요하므로 Memorystore for Valkey가 활성 세션 상태를 유지하는 데 적합합니다. 

• 장기 영구 메모리: 중요한 사실, 사용자 환경설정, 에피소드 사실을 세션 전반에 걸쳐 저장합니다. 이 계층에는 트랜잭션 무결성, 데이터 거버넌스, 관계형 데이터와 벡터 전반의 하이브리드 검색이 필요하며, 이러한 기능은 AlloyDB AI에서 네이티브로 제공됩니다.

장기 메모리와 활성 세션 버퍼를 모두 관계형 데이터베이스에 직접 저장할 수도 있지만, 인메모리 캐시가 있는 2계층 아키텍처가 더 나은 성능과 확장성을 제공할 수 있습니다. 활성 세션 버퍼는 매우 일시적이며 모든 대화 턴에서 1밀리초 미만의 고처리량 업데이트가 필요합니다. 인메모리 키-값 캐시에서 이러한 빠른 쓰기를 처리하면 관계형 데이터베이스에서 쓰기 증폭과 테이블 비대화를 방지할 수 있습니다. 그렇지 않으면 빈번한 행 삭제와 집중적인 비우기가 필요합니다. 이는 데이터베이스 앞에 캐싱 계층을 추가하여 핫 행에 대한 고빈도 조회를 오프로드하는 것과 유사합니다. 이러한 업무 분담을 통해 기본 데이터베이스는 가볍고 반응성이 뛰어난 상태를 유지하며, 트랜잭션 일관성, 복잡한 하이브리드 벡터 검색, 장기 분석 쿼리 실행 등 본래 설계된 목적에 리소스를 집중할 수 있습니다. 

Memorystore for Valkey의 단기 캐싱과 네이티브 AlloyDB AI 기능을 결합하면 데이터베이스 계층 내에서 직접 항목 추출, 메모리 압축, 교차 세션 메모리, 하이브리드 검색을 실행하여 활성 프롬프트를 간결하고 빠르며 비용 효율적으로 유지할 수 있습니다.

네 가지 메모리 유형 이해하기

장기 에이전트 상태를 효과적으로 구성하기 위해, 에이전트 메모리를 앞서 설명한 단기 및 장기 스토리지 계층 전반에서 네 가지 상호 보완적인 유형으로 더 세분화하면 다음과 같습니다.

단기 대화 컨텍스트를 정형화된 장기 규칙과 분리함으로써 에이전트는 원시 상호작용 로그로 토큰 윈도우를 채우지 않고도 필요에 따라 관련 컨텍스트를 검색할 수 있습니다.

계층형 메모리 아키텍처 청사진

아래 다이어그램은 애플리케이션 조정 레이어, Memorystore for Valkey 단기 버퍼, AlloyDB AI 장기 저장소를 연결하는 읽기 및 쓰기 경로를 보여줍니다.

이 시스템은 조정된 두 가지 실행 경로를 통해 작동합니다.

• 읽기 경로: 사용자가 질문하면 애플리케이션은 Memorystore for Valkey에서 활성 슬라이딩 윈도우를 가져오고, ai.generate를 사용하여 데이터베이스 내 쿼리 정규화를 실행하고, ai.hybrid_search를 사용하여 AlloyDB를 쿼리하여 범위가 지정된 항목 규칙과 관련 에피소드 사실을 검색합니다.

• 쓰기 경로: 응답을 생성한 후 해당 대화 턴은 즉시 Memorystore for Valkey에 캐시됩니다. 비동기 백그라운드 큐 작업자가 대화에서 정형 항목을 추출하여 AlloyDB에 직접 기록하면, 트랜잭션 기반 자동 임베딩이 데이터베이스에서 벡터 표현을 즉시 계산하고 저장합니다.

비즈니스 영향 및 ROI

멀티턴 개발 대화(도구 실행이 많은 45턴 이상)에 대한 벤치마크 테스트에서 단기 캐싱을 장기 지속성과 분리하면 단순한 컨텍스트 스터핑에 비해 측정 가능한 비용 및 성능 개선이 확인되었습니다.

참고: 위의 측정항목은 여러 세션, 프로젝트, 컨텍스트 전환에 걸쳐 개발자와 상호작용하는 실제 엔터프라이즈 AI 페어 프로그래밍 어시스턴트를 모방하여 시뮬레이션된 개발자 워크로드의 내부 벤치마크 결과를 반영합니다. 실제 절감액과 지연 시간은 프롬프트 구조, 쿼리 빈도, 데이터 볼륨에 따라 달라집니다.

이러한 결과는 계층형 메모리가 에이전트 단위 경제성을 어떻게 변화시키는지 보여줍니다. 턴이 추가될 때마다 비용 곡선이 상승하는 대신, 프롬프트 크기가 제한되어 지속적인 LLM API 비용을 줄이면서도 빠른 응답 시간을 유지할 수 있습니다.

AlloyDB AI의 핵심 기술적 이점

AlloyDB AI는 핵심 AI 기능을 데이터베이스 엔진에 직접 임베딩하여 영구 에이전트 메모리를 구현하는 데 드는 운영 오버헤드를 줄입니다.

• 트랜잭션 데이터베이스 내 자동 임베딩(ai.initialize_embeddings): AlloyDB는 Agent Platform(이전 명칭: Vertex AI)과의 네이티브 통합을 사용하여 텍스트 열에 대한 벡터 임베딩을 자동으로 생성하며, 초당 최대 3,000개의 임베딩을 생성합니다. incremental_refresh_mode => 'transactional'을 사용하면 AlloyDB는 동일한 트랜잭션 내에서 소스 데이터가 변경될 때 임베딩을 최신 상태로 유지하므로 커스텀 임베딩 파이프라인, 외부 스케줄러 또는 복잡한 재시도 로직이 필요하지 않습니다.

• 데이터베이스 내 생성형 AI 함수(ai.generate): AlloyDB를 사용하면 SQL 쿼리에서 직접 Gemini와 같은 파운데이션 모델을 실행할 수 있습니다. 이를 통해 애플리케이션에서 별도의 왕복 없이 데이터베이스 내 쿼리 분해(복합적인 사용자 질문을 단일 측면의 하위 쿼리로 분해하고 '마지막 세션'과 같은 상대적인 시간 구문을 명시적인 식별자로 해결)를 수행할 수 있습니다.

• Reciprocal Rank Fusion(ai.hybrid_search)이 기본 제공되는 네이티브 하이브리드 검색: AlloyDB는 엔진 내에서 직접 상호 순위 융합(RRF)을 실행하는 기본 제공 SQL 함수를 제공합니다. 이 기능은 단일 데이터베이스 호출에서 벡터 코사인 유사성(HNSW 또는 ScaNN 색인에 대한 <=>)과 PostgreSQL 전체 텍스트 검색(BM25, RUM 또는 GIN 사용)을 결합하여 시맨틱 매칭과 정확한 키워드 검색을 혼합하는 동시에 메타데이터 필터 푸시다운(filter_condition)을 지원하여 성능을 개선하고 결정론적 범위 격리를 제공합니다.

• IAM 사용자 인증 정보를 사용한 직접적인 Agent Platform 통합: AlloyDB는 Google Cloud IAM 서비스 계정 역할과 데이터베이스 인증을 사용하여 Google Cloud의 비공개 네트워크를 통해 Agent Platform 파운데이션 모델에 직접 연결하므로 애플리케이션 코드에 API 키를 저장하거나, 주기적으로 순환하거나, 전달할 필요가 없습니다.

• 통합 운영, 벡터, 거버넌스 엔진: AlloyDB는 관계형 비즈니스 데이터, 벡터 임베딩, 전체 텍스트 색인, 엔터프라이즈 권한을 단일 ACID 호환 PostgreSQL 데이터베이스에 통합하여 별도의 운영 및 벡터 데이터베이스 전반에서 데이터 드리프트와 통합 복잡성을 방지합니다.

주요 구현 패턴

다음은 2계층 메모리 아키텍처를 구성하는 데 사용되는 핵심 데이터베이스 패턴입니다. 전체 러너블 Python 및 SQL 스크립트는 함께 제공되는 AlloyDB 에이전트 메모리 Codelab을 참고하세요.

1. 스키마 및 자동 임베딩 설정

AlloyDB에서 필요한 확장 프로그램을 설치하고 정형 메타데이터, 전체 텍스트 검색을 위해 생성된 tsvector 열, 벡터 임베딩 열을 사용하여 agent_entities 테이블을 정의합니다.

그런 다음 ai.initialize_embeddings를 사용하여 임베딩을 생성합니다. transactional 모드를 사용하면 소스 데이터가 변경될 때 임베딩이 최신 상태로 유지됩니다.

마지막으로 HNSW 벡터 색인과 RUM 전체 텍스트 검색 색인을 만들어 하이브리드 검색이 빠르고 효율적으로 수행되도록 합니다.

2. 네이티브 하이브리드 검색으로 장기 메모리 쿼리

읽기 경로에서 ai.hybrid_search를 사용하여 관련 장기 항목을 검색합니다. 이 네이티브 SQL 함수는 AlloyDB에서 직접 Reciprocal Rank Fusion(RRF)을 실행하여 단일 데이터베이스 쿼리에서 벡터 유사성 검색과 전체 텍스트 키워드 검색 결과를 원활하게 재정렬하고 결합합니다.

3. AI 함수를 사용한 데이터베이스 내 메모리 압축

커스텀 가지치기 스크립트를 작성하지 않고도 장기 스토리지 증가를 관리하기 위해 AlloyDB에서 직접 자동화된 추출 및 압축 쿼리를 실행하여 저장하면 이점이 있는 중요한 부분을 식별할 수 있습니다. 이 패턴은 ai.generate와 함께 SQL 공통 테이블 표현식(CTE)을 사용하여 오래된 에피소드 항목을 고밀도 요약으로 통합합니다.

예를 들어 자녀와 함께 이용할 항공편을 변경하는 복잡한 과정에 대한 긴 상호작용을 '직항 항공편을 선호합니다'라는 요약으로 정리할 수 있습니다.

4. 2계층 메모리 아키텍처를 ADK 에이전트에 연결

핵심 2계층 메모리 아키텍처가 구성되면 이제 함께 제공되는 Codelab에 표시된 대로 기본 ADK 메모리 프로바이더를 확장하여 이 2계층 메모리 아키텍처를 사용할 수 있습니다(예: ADKTieredMemoryProvider). 장기 메모리를 ADK 에이전트에 연결하려면 다음과 같이 도구(예: longterm_memory_tool)로 제공하면 됩니다.

엔터프라이즈 거버넌스 및 멀티 테넌트 보안

엔터프라이즈 프로덕션 환경에서 에이전트 메모리를 실행하려면 엄격한 보안 경계와 액세스 제어가 필요합니다. 먼저 범위 및 멀티 테넌트 격리를 유지해야 합니다. agent_entities에서 user_id, project_id, scope 열을 색인화하고 PostgreSQL 행 수준 보안(RLS)을 적용하면 동일한 데이터베이스 클러스터 내에서 부서, 팀, 개별 사용자 간에 메모리 저장소를 격리할 수 있습니다. 파라미터화된 보안 뷰(PSV)는 또 다른 결정론적 애플리케이션 수준 보안 레이어를 제공하여 악의적인 프롬프트와 지나치게 광범위한 SQL 쿼리로부터 보호합니다.

또한 위의 구현 패턴에서 볼 수 있듯이 자동화된 메모리 수명 주기 관리를 제공해야 합니다. 예약된 SQL 압축 쿼리와 시간 기반 파티션 가지치기를 결합하면 시간이 지나도 예측 가능한 데이터베이스 사용 공간과 쿼리 지연 시간을 유지하는 데 도움이 됩니다. 이 접근 방식에 대한 자세한 내용은 함께 제공되는 Codelab을 참고하세요.

요약 및 다음 단계

활성 컨텍스트 윈도우를 영구 스토리지에서 분리하는 것은 프로덕션에 즉시 사용 가능한 AI 에이전트를 빌드하는 실용적인 접근 방식입니다. 1밀리초 미만의 세션 캐싱을 위한 Memorystore for Valkey와 트랜잭션 장기 스토리지를 위한 AlloyDB AI를 함께 사용하면 장기 작업과 멀티턴 에이전트 경험 전반에서 엄격한 비즈니스 규칙을 유지하면서도 토큰 비용을 대폭 절감하고 더 빠른 응답 시간을 달성할 수 있습니다.

시작하려면 다음 안내를 따르세요.

• AlloyDB 에이전트 메모리 Codelab에서 제공하는 전체 실무형 튜토리얼을 단계별로 진행하여 실제 작동하는 2계층 메모리 아키텍처를 배포해 보세요.

• AlloyDB AI 문서에서 데이터베이스 측 머신러닝 기능에 대해 자세히 알아보세요.

• 자동 벡터 임베딩 생성 및 하이브리드 벡터 검색 실행에 대한 가이드를 살펴보세요.