RAG를 대체하는 상시 메모리 에이전트, Gemini 3.1 Flash-Lite로 다시 쓰는 LLM 기억 구조

Google Cloud가 generative-ai 저장소에 Always-On Memory Agent 참조 구현을 신규 추가하며, RAG의 검색 패러다임을 연속 통합 패러다임으로 대체하는 실험적 아키텍처를 공개했다. 기반 모델로는 Gemini 3.1 Flash-Lite가 채택되었고, 메모리 처리는 24시간 상시 동작하는 멀티 에이전트 파이프라인으로 재구성되었다. 이 사례는 생성형 AI 서비스의 기억 비용을 어디까지 줄일 수 있는지에 대한 새로운 기준선을 제시한다는 점에서 주목할 만하다.

RAG에서 Always-On Memory로의 전환 배경

기존 RAG 파이프라인의 한계와 임베딩 의존도

전통적인 RAG는 문서를 청크로 분할하고 임베딩 모델로 벡터화한 뒤, 유사도 검색으로 컨텍스트를 주입하는 구조를 따른다. 이 방식은 검색 정확도가 임베딩 품질에 직결되며, 벡터 데이터베이스 운영 비용과 인덱스 갱신 부담이 서비스 전체의 총소유비용을 끌어올리는 요인으로 지적되어 왔다. 또한 검색 시점과 입력 시점 사이의 정보 불일치 문제, 이른바 stale context 문제가 장기 대화형 워크로드에서 사용자 경험을 저하시킨다는 지적이 꾸준히 제기돼 왔다.

메모리를 일회성 검색이 아닌 연속 프로세스로 재정의한 의미

Always-On Memory Agent는 메모리를 호출 시점에만 조회하는 자원이 아니라, 에이전트가 쉬지 않고 통합하고 다듬는 대상으로 정의한다. 즉, 새로운 사실이 들어오는 즉시 구조화 메모리에 반영하고, 유사 항목끼리 병합하며, 더 이상 유효하지 않은 정보는 축약 또는 폐기하는 처리가 24/7 백그라운드에서 일어난다. 이러한 접근은 검색 정확도라는 단일 지표보다 기억의 일관성과 최신성을 더 중요하게 취급하는 방향으로의 전환을 의미한다.

Always-On Memory Agent 아키텍처 분석

Ingest·Consolidate·Query 3단 에이전트의 역할 분담

공개된 참조 구현은 단일 거대 컨텍스트 창에 의존하지 않고, 책임을 세 개의 하위 에이전트로 분리한다. Ingest 에이전트는 외부 입력과 시스템 이벤트를 받아 정제된 사실 단위로 변환하고, Consolidate 에이전트는 SQLite에 저장된 메모리를 주기적으로 통합·요약·중복 제거하며, Query 에이전트는 사용자 요청에 가장 적합한 기억 조각을 조합해 응답에 주입한다. 이 3단 구조는 파이프라인의 각 단계가 독립적으로 스케일링·교체될 수 있다는 점에서 운영 유연성을 높이는 것으로 분석된다.

Google ADK와 Gemini 3.1 Flash-Lite 조합의 설계 의도

오케스트레이션은 Google ADK(Agent Development Kit)가 담당하고, 각 하위 에이전트의 추론은 Gemini 3.1 Flash-Lite가 수행한다. Flash-Lite 등급 모델을 채택한 것은 통합 작업의 대다수가 고정된 스키마 기반의 경량 처리에 해당하기 때문으로 해석되며, 이는 비용 최적화를 1차 목표로 둔 설계로도의 추론보다 안정적인 분류·요약·판단에 해당하기 때문으로 해석된다. 상위 모델로 올려야 하는 호출이 의도적으로 통합·조회 단계에서 분리됨으로써, 토큰 단가와 지연 시간 모두에서 여지가 생기는 구조다.

SQLite 기반 구조화 메모리와 벡터 데이터베이스 배제 전략

이 아키텍처의 가장 큰 특징 가운데 하나는 벡터 데이터베이스와 임베딩 파이프라인을 의도적으로 배제하고 SQLite 같은 임베디드 관계형 저장소를 사용한다는 점이다. 메모리는 자유 텍스트 덤프가 아니라 키-값 메타데이터와 함께 스키마에 저장되며, 유사도 검색 대신 LLM 자체의 판단으로 의미적으로 동등한 항목을 병합한다. 그 결과 인프라 복잡도는 낮아지지만, 통합 품질이 모델 능력에 직접 의존하게 되어 모델 선택의 중요도가 그 어느 때보다 커진 것으로 보인다.

경량 LLM과 상시 통합의 비용·품질 트레이드오프

연속 처리로 인한 토큰 사용량 증가 가능성과 제어 포인트

24/7 통합은 곧 시간당 일정한 토큰 소비를 수반하므로, 트래픽이 적은 시간대에도 비용이 누적되는 구조적 특성이 있다. MarkTechPost 기사에 따르면 참조 구현은 통합 빈도·요약 길이·보존 기간을 설정 값으로 노출해 운영자가 직접 튜닝할 수 있도록 설계된 것으로 보인다. 핵심 제어 포인트는 Consolidate 에이전트의 트리거 조건과 보존 TTL이며, 이 두 값을 도메인별 이벤트 밀도에 맞춰 조정하는 것이 비용 최적화의 1차 레버로 부상한다.

Flash-Lite 등급 모델의 응답 지연과 처리량 이점

Flash-Lite는 같은 시리즈의 상위 모델 대비 처리량이 크고 응답 지연이 짧은 경량 등급으로 알려져 있어, 통합·조회처럼 다량·저지연이 요구되는 작업에 적합하다. Query 단계에서 컨텍스트 주입이 끝난 뒤 최종 응답 생성에 상위 모델을 호출하는 2단 구조라면, 체감 품질은 유지하면서 비용 곡선만 눌러 누울 수 있는 가능성이 있다. 다만 이 효과는 도메인 난이도와 통합 품질에 따라 편차가 클 수 있어, 실제 도입 시 동일 시나리오의 A/B 측정 없이는 일반화하기 어렵다는 견해가 유력하다.

현장 적용 시나리오와 도입 체크리스트

장기 컨텍스트 고객지원과 개인 비서 워크로드 적합성

세션이 길어질수록 컨텍스트 창 한계가 드러나는 워크로드, 예컨대 장기 고객지원 이력 기반 상담이나 개인 비서형 서비스는 이 아키텍처의 대표 적용처로 꼽힌다. 사용자별·이슈별 누적 기억이 자동으로 구조화되어 검색 시점의 추가 인덱스 작업 없이도 일관된 답변을 기대할 수 있기 때문이다. 반면, 카탈로그처럼 정적 참조가 잦은 워크로드에서는 전통적 RAG나 함수 호출 기반 검색이 여전히 더 경제적일 수 있다.

보안·프라이버시·데이터 보존 정책 고려사항

상시 통합은 기억에 포함된 개인정보가 더 오래, 더 다양한 경로로 노출될 위험을 동반한다. 참조 구현이 SQLite 같은 파일 기반 저장소를 채택했다는 점은 배포 환경의 통제 가능성이 높다는 장점이기도 하지만, 반대로 운영자가 보존 기간·마스킹·삭제 정책을 명시적으로 구현해야 함을 의미하기도 한다. 의료·금융처럼 규제 강도가 높은 도메인에서는 통합 단계에서 PII 자동 비식별화 처리를 함께 파이프라인에 넣는 설계가 사실상 필수로 여겨진다.

참조 구현을 통해 읽는 Google의 생성형 AI 생태계 전략

Always-On Memory Agent는 단독 제품이라기보다, Gemini 3.1 Flash-Lite와 Google ADK를 결합해 기억 문제를 새로 풀어 보이는 레퍼런스 아키텍처에 가깝다. 동일한 패턴을 Firebase·Vertex AI 같은 관리형 서비스에 이식하면, 고객이 직접 멀티 에이전트 통합을 구현하지 않아도 되는 상시 메모리 기능이 등장할 여지가 충분하다. 결과적으로 이 공개는 RAG의 종착을 선언한다기보다, 더 가볍고 운영 친화적인 기억 계층이 생성형 AI 스택의 한 축으로 자리 잡기 시작했음을 시사하는 신호탄으로 읽히는 것이 합리적 해석이다.

Always-On Memory Agent, Google Cloud, Gemini 3.1 Flash-Lite, Google ADK, RAG 대체, continuous LLM consolidation, 멀티 에이전트 오케스트레이션, SQLite 메모리, 임베딩 없는 검색, 생성형 AI 아키텍처, 경량 LLM, AI 비용 최적화

참고: MarkTechPost, GeekNews