RAG 없이 기억하는 Google Cloud의 Always-On Memory Agent

AI 에이전트의 다음 과제는 단지 더 잘 답하는 것이 아니다. 과거의 상호작용에서 필요한 정보를 남기고, 이후 행동에 활용할 수 있어야 한다. Google Cloud의 Always-On Memory Agent는 이 문제를 벡터 검색이 아닌 LLM의 지속적인 메모리 정리와 구조화로 풀어낸 참조 구현이다.

벡터 검색 대신 구조화된 상태를 유지한다

Always-On Memory Agent는 Google ADK와 Gemini 3.1 Flash-Lite를 기반으로 한다. 오케스트레이터가 작업을 Ingest, Consolidate, Query 하위 에이전트로 라우팅하고, 이들은 SQLite에 저장된 구조화 메모리를 지속적으로 읽고 연결하고 갱신한다.¹

• Ingest는 새 정보를 받아 메모리로 기록한다.

• Consolidate는 새 정보와 기존 기록의 관계를 정리하고 통합한다.

• Query는 축적된 메모리를 바탕으로 질문에 답한다.

가장 눈에 띄는 특징은 임베딩과 벡터 데이터베이스를 사용하지 않는다는 점이다. 새 정보에서 주제와 개체를 추출하고 기존 기억과 연결한 뒤, 질문이 들어오면 LLM이 구조화된 기록과 통합 결과를 읽어 답을 만든다.

그렇다고 검색 문제가 사라지는 것은 아니다. 벡터 인덱스를 구축하고 유사도를 조정하는 대신, 무엇을 기록하고 합치며 수정하거나 버릴지를 LLM이 판단한다. 복잡성을 제거했다기보다 검색 계층에서 메모리 관리 계층으로 옮긴 설계에 가깝다.

Flash-Lite는 지속적인 메모리 작업을 뒷받침한다

상시 메모리 통합에는 많은 요청을 짧은 지연 시간과 낮은 비용으로 처리할 수 있는 모델이 필요하다. Gemini 3.1 Flash-Lite는 대규모·비용 민감형 LLM 트래픽을 겨냥하며, 1,048,576토큰의 컨텍스트 창과 기본값 기준 최대 65,535토큰의 출력을 제공한다.²

구조화 출력과 함수 호출을 지원하는 점도 중요하다. 에이전트가 정해진 형식의 메모리 레코드를 만들고, SQLite 읽기·쓰기 같은 도구 작업을 수행하는 데 활용할 수 있기 때문이다. 또한 최소·낮음·중간·높음의 네 가지 사고 수준을 제공하므로 작업 성격에 따라 추론 강도를 조절할 수 있다.²

다만 Flash-Lite 자체는 RAG Engine과 명시적·암시적 컨텍스트 캐싱도 지원한다.² 따라서 이 구현을 ‘RAG의 대체’로 일반화해서는 안 된다. 목적에 따라 다음처럼 구분하는 편이 실용적이다.

• 문서 원문이나 근거 구간을 정확히 찾아야 한다면 RAG

• 사용자 선호, 관계, 업무 맥락처럼 시간이 지나며 수정·통합되는 상태라면 지속형 메모리

• 두 요구가 모두 있다면 검색과 구조화된 상태를 함께 사용하는 방식

핵심 과제는 기억이 아니라 통제다

Always-on 에이전트는 과거 상호작용에서 축적된 영속 상태가 이후 행동에 영향을 주는 시스템이다. 이 상태에는 검색 가능한 기억뿐 아니라 작업 원장, 권한, 자격 증명, 약속, 출처, 감사 기록도 포함될 수 있다.³

따라서 운영 환경에서는 ‘무엇을 기억할 것인가’만큼 다음 여섯 가지를 명확히 해야 한다.³

1. 권한: 누가 읽고 수정할 수 있는가

2. 범위: 사용자·세션·조직 중 어디까지 공유되는가

3. 변경 가능성: 어떤 상태를 갱신하거나 고정할 수 있는가

4. 출처: 각 기억이 어디에서 왔는지 추적할 수 있는가

5. 복구 가능성: 잘못된 변경을 삭제하거나 롤백할 수 있는가

6. 실행 가능성: 저장된 상태가 실제 행동에 어떤 영향을 주는가

메모리의 전체 수명주기도 함께 설계해야 한다. 기록과 검색만으로는 부족하며, 검증·구성·실행·갱신·삭제·감사·롤백까지 관리할 수 있어야 한다.³ 특히 잘못 통합된 정보가 이후 판단에 반복적으로 영향을 줄 수 있으므로 출처와 변경 이력, 복구 절차가 필수적이다.

실무에서 가져갈 설계 원칙

Always-On Memory Agent에서 배울 핵심은 벡터 DB를 제거하는 방법이 아니다. 에이전트의 기억을 단순한 대화 기록이나 부가 기능이 아니라, 지속적으로 갱신되고 실제 행동에 영향을 주는 상태 저장 시스템으로 다뤄야 한다는 점이다.

도입 전에는 세 가지를 먼저 결정해야 한다.

• 저장할 상태와 버릴 정보를 구분한다.

• 검색이 필요한 지식과 지속적으로 통합할 상태를 분리한다.

• 기록부터 삭제·감사·롤백까지 전체 수명주기를 설계한다.

이 기준이 갖춰져야 Always-on 메모리가 편리한 기능을 넘어, 검증 가능하고 통제 가능한 에이전트 기반이 될 수 있다.

¹Always On Memory Agent: what Google's Memory Agent actually does

²Gemini 3.1 Flash-Lite

³Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents