AI 에이전트 장기 기억을 벡터 DB 하나에 몰아넣으면 안 되는 이유: SQL·벡터 검색·Memory Bank 분리 설계

멀티모달 신호에서 정형 사실(SQL 큐브)과 의미론적 이해(벡터 성좌)를 분리해 저장하고 원본 오디오·비디오 파형은 외부에 두는 구조를 표현한 생성형 개념 이미지다. 실제 Google Cloud 콘솔 화면이 아니다.

Google Cloud가 공개한 AI Agent Memory Architecture 기술 영상과 Agent Platform Memory Bank 공식 문서는 텍스트를 넘어 음성과 카메라 화면까지 실시간으로 주고받는 멀티모달 에이전트가 세션이 끝난 뒤 ‘무엇을, 어디에, 언제’ 기억해야 하는지를 다룬다. 발표자 Annie는 에이전트의 기억을 단순히 하나의 벡터 데이터베이스에 몰아넣는 흔한 실수를 지적하며, 사실(Facts), 이해(Understanding), 원본 지각(Raw Perception)의 세 갈래로 저장소와 쓰기 타이밍을 분리하는 아키텍처를 제시했다.

결론부터 말하면, 정확한 조회가 필요한 사실(예: 구매 내역, 목요일 저녁 약속)은 관계형 데이터베이스(Cloud SQL 등)에 즉시 동기로 기록하고, 여러 대화에서 누적된 성향과 맥락(예: 격식 있는 자리에서 어두운 색상을 선호함)은 실시간 응답 경로(hot path) 바깥에서 비동기로 추출해 벡터 스토어(Memory Bank, AlloyDB 등)에 저장해야 하며, 원본 오디오·비디오 스트림은 에이전트 기억 저장소에 넣지 말아야 한다. 다만 이 글은 Google Cloud 공식 영상과 문서를 바탕으로 메모리 계층 설계 원칙을 정리한 것이며, 실제 프로덕션 트래픽에서 DB 쿼리 지연이나 메모리 추출 비용을 직접 측정한 결과는 아니다.

왜 모든 기억을 벡터 스토어 하나에 넣으면 위험한가

세션이 유지되는 동안 에이전트가 5분 전 대화를 기억하는 것은 컨텍스트 윈도우라는 단기 기억(RAM) 덕분이다. 하지만 세션이 종료된 뒤 다음 세션으로 넘어가려면 영구 저장소가 필요하다. 이때 많은 개발팀이 ‘에이전트 장기 기억 = 시맨틱 메모리’라고 생각해 일정, 주문 내역, 개인 취향까지 전부 임베딩하여 벡터 스토어 한 곳에 저장한다.

발표(04:30~05:25)에서는 이 설계가 실패하는 이유를 ‘유사도(similarity) 검색과 정확성(exactness)의 충돌’로 설명한다. 벡터 스토어는 질문이 모호할 때 의미가 비슷한 조각을 찾아오는 데 최적화되어 있다. 사용자가 “내가 지난번에 무슨 재킷을 샀지?”라거나 “목요일 저녁 일정이 뭐야?”라고 물었을 때, 에이전트가 비슷한 기억을 추측해서 답하면 곧바로 환각(hallucination)이 된다.

따라서 에이전트가 다루는 정보는 성격에 따라 다음 세 가지 계층으로 엄격히 분리해야 한다.

구분 계층	정의 및 데이터 예시	적합한 저장소	쓰기(Write) 시점 및 경로
사실 (Structured Facts)	ID·날짜·상태가 명확해 생성·수정·삭제(CRUD)와 정확한 일치가 필요한 데이터 (예: 위시리스트 아이템, 캘린더 일정, 주문 내역)	관계형 SQL 데이터베이스 (`Cloud SQL`, `PostgreSQL`, `MySQL` 등)	대화 중 도구 호출(tool call) 즉시 동기식(Synchronous) 기록
이해 (Semantic Understanding)	단일 행으로 정의되지 않고 여러 대화를 거치며 드러나는 사용자의 패턴과 의미 (예: “화려한 것보다 심플한 스타일 선호”, “더위를 많이 탐”)	벡터 스토어 및 관리형 메모리 (Agent Platform Memory Bank, `AlloyDB`, `pgvector`)	실시간 음성·대화 지연을 막기 위해 턴 종료 후 또는 세션 종료 후 비동기(Asynchronous, Off-the-hot-path) 추출·통합
원본 지각 (Raw Perception)	카메라 프레임, 오디오 파형(waveform), 실시간 미디어 스트림 원본	에이전트 메모리 외부 (감사·디버깅·학습용 별도 오브젝트 스토리지)	원본 미디어 자체는 기억에 넣지 않고, 그 안에서 추출한 의미(“검은 모자를 다시 착용함” 등)만 메모리로 전환

세션 시작과 종료의 두 트랙: 동기 팩트 기록과 비동기 의미 추출

이 아키텍처가 실제 대화 루프에서 어떻게 돌아가는지는 세션 시작(Cold Open)과 세션 진행·종료(Save & Extract)의 두 시점으로 나누어 보면 명확하다(Memory Bank API Quickstart).

세션 시작 시점의 병렬 로드(Read at Start): 사용자가 대화를 시작할 때 에이전트는 백지상태에서 출발하지 않는다. 먼저 SQL 데이터베이스에서 확정된 사실(다가오는 목요일 저녁 약속, 위시리스트에 담긴 부츠)을 조회하고, 동시에 벡터 스토어(ADK PreloadMemoryTool 또는 RetrieveMemories API)에서 해당 상황과 의미론적으로 연관된 성향(편안한 핏 선호, 선호 색상)을 검색해 프롬프트 컨텍스트로 결합한다.

대화 중 팩트의 즉시 반영(Fast Synchronous Track): 사용자가 “그 블레이저를 위시리스트에 추가해 줘”라고 말하면 에이전트는 즉시 SQL 쓰기 도구를 호출해 행(row)을 추가한다. 사용자는 자신의 명령이 그 자리에서 정확히 반영되기를 기대하기 때문이다.

대화 중·종료 후 이해의 비동기 추출(Slow Asynchronous Track): 반면 사용자가 지나가는 말로 “오늘은 노란색이 괜찮아 보이네”라고 했다고 해서 곧바로 장기 프로필을 ‘노란색 선호’로 덮어쓰면 기억이 오염(noisy memory)된다. LLM이 대화 전체 맥락을 읽고 반복되는 신호인지 판단해 기존 기억과 통합(consolidation)하는 과정은 일반 DB 쓰기보다 훨씬 무겁다. 특히 실시간 음성(Live Voice) 에이전트에서는 이 추출 과정이 오디오 스트림을 블로킹하면 안 되므로, 반드시 실시간 응답 경로 바깥(off the live path)에서 비동기로 실행해야 한다.

에이전트 장기 기억 시스템을 구축할 때 확인할 점

자체 서비스에 장기 기억 계층을 도입하거나 Agent Platform Memory Bank와 자체 벡터 DB(pgvector 등)를 비교할 때는 다음 기준을 먼저 점검하는 편이 좋다.

질문의 성격에 따른 라우팅 경계 정의: “내가 무엇을 샀는가 / 언제 예약했는가”처럼 정답이 하나인 질문은 절대 벡터 유사도 검색에 의존하지 말고 SQL 조건절(WHERE)로 처리하도록 도구를 분리해야 한다.

직접 구축(Plain Vector Store)과 관리형(Memory Bank)의 공수 비교: pgvector나 AlloyDB로 직접 벡터 스토어를 구성하면 저장 자체는 간단하지만, 대화록에서 기억할 가치가 있는 문장을 선별하고 기존 기억과의 모순을 해결(consolidation)하는 LLM 파이프라인을 직접 짜야 한다. 관리형 Memory Bank를 쓰면 GenerateMemories 호출만으로 추출·중복 제거·충돌 해결이 백그라운드에서 자동 처리된다. 단, CreateMemory API로 직접 넣은 단편 기억은 자동 통합 과정을 거치지 않으므로 중복 적재에 주의해야 한다(Memory Bank API 문서).

실시간 멀티모달 에이전트의 추출 시점과 핫패스 분리: 사용자가 대화를 중간에 끊고 나가더라도 맥락을 잃지 않으려면 세션 종료 시점뿐 아니라 일정 턴 간격으로 중간 추출(mid-session extraction)을 걸어두는 것이 유리하다. 이때도 추출 작업은 반드시 비동기 워커나 콜백으로 분리해 사용자 체감 지연 시간(TTFT 및 오디오 지연)에 영향을 주지 않는지 확인해야 한다.

결국 사용자를 제대로 기억하는 에이전트는 모든 대화 로그와 미디어 파일을 무작정 쌓아두는 시스템이 아니라, ‘정확히 조회할 사실’과 ‘맥락으로 떠올릴 이해’를 각기 다른 저장소와 속도로 다루는 시스템이다.