구글, 벡터DB 없이 지속 학습하는 ‘항상온 메모리 에이전트’ 공개

구글 ‘항상온 메모리 에이전트’ 공개의 의미

구글의 시니어 AI PM 슈브함 사부가 에이전트 설계의 난제인 지속 메모리를 오픈소스 엔지니어링 과제로 풀었다. 그는 ‘항상온 메모리 에이전트(Always On Memory Agent)’를 구글 클라우드 플랫폼 깃허브에 MIT 라이선스로 공개했으며, 구글의 Agent Development Kit(ADK, 2025년 봄 공개)와 2026년 3월 3일 발표된 저비용 모델 Gemini 3.1 Flash‑Lite로 구축됐다. 이 레퍼런스 구현은 정보를 상시 수집·백그라운드 통합·사후 조회하되 전통적 벡터 데이터베이스에 의존하지 않는 방식을 제시하며, 고객지원·리서치 어시스턴트·사내 코파일럿·워크플로 자동화에 맞는 장기 실행형 자율성을 보여준다. 동시에 세션 경계를 벗어나는 순간 거버넌스 논점이 선명해진다.

레포가 보여주는 것과 보여주지 않는 것

전문 서브에이전트 기반의 내부 구조

레포는 수집·통합·질의를 담당하는 전문 컴포넌트로 구성된 멀티에이전트적 내부 아키텍처를 시사한다. 다만 다수의 독립 에이전트가 메모리를 공유하는 범용 프레임워크라는 주장은 명확히 하지 않는다. ADK 자체는 멀티에이전트를 지원하지만, 이번 레포는 지속 스토리지를 갖춘 메모리 레이어, 즉 항상온 메모리 에이전트에 가깝다. 그럼에도 많은 팀이 씨름 중인 핵심 인프라 문제를 실용적으로 짚는다.

아키텍처: 벡터DB 없는 단순한 메모리 계층

연속 실행과 주기적 메모리 통합

레포에 따르면 에이전트는 상시 실행되며 파일·API 입력을 수집하고, 구조화된 메모리를 SQLite에 저장한다. 기본 30분 주기로 메모리 통합을 스케줄링하며, 로컬 HTTP API와 Streamlit 대시보드를 제공한다. 텍스트·이미지·오디오·비디오·PDF 입력을 지원한다.

“No embeddings” 선택의 파장

레포는 “벡터 데이터베이스도 임베딩도 없다. LLM이 읽고 사고하여 구조화 메모리를 작성한다”는 도발적 설계를 내세운다. 전통적 검색 스택의 임베딩 파이프라인·벡터 저장·인덱싱·동기화 복잡도를 덜 수 있어, 특히 소·중형 메모리 범위의 프로토타입에서 인프라 확산을 줄인다. 대신 성능 초점은 벡터 검색 오버헤드에서 모델 지연, 메모리 압축 로직, 장기적 행동 안정성으로 이동한다.

Flash‑Lite가 뒷받침한 경제성

가격·성능 지표

Gemini 3.1 Flash‑Lite는 대량 워크로드용으로 설계되어 입력 100만 토큰당 $0.25, 출력 100만 토큰당 $1.50에 책정됐다. 첫 토큰 지연은 Gemini 2.5 Flash 대비 2.5배 빠르고, 출력 속도는 45% 향상되었다고 한다. 공개 지표로는 Arena.ai Elo 1432, GPQA Diamond 86.9%, MMMU Pro 76.8%를 기록하며 번역·모더레이션·UI 생성·시뮬레이션 같은 고빈도 작업에 적합하다는 포지셔닝이다.

항상온 서비스와의 궁합

주기적으로 재읽기·통합·제공을 반복하는 24/7 서비스에는 예측 가능한 지연과 낮은 추론 비용이 필수다. 이 점에서 Flash‑Lite는 항상온 메모리 에이전트를 경제적으로 성립시키는 축이 된다.

ADK가 확장하는 에이전트 런타임

모델·배포 중립성과 개발자 경험

ADK는 모델·배포 중립을 표방하며 워크플로 에이전트, 멀티에이전트, 도구 호출, 평가를 지원하고 Cloud Run, Vertex AI Agent Engine 등 다양한 배포 타깃을 제공한다. 메모리 에이전트 예시는 장기 실행 서비스 형태지만, ADK는 서버리스와 롱러닝 모두를 포괄한다. 이 프레이밍에서 메모리는 부가 기능이 아니라 런타임 레이어의 일부가 된다.

엔터프라이즈 관점: 거버넌스가 성패를 좌우

공개 반응과 운용상의 질문

일부 X 사용자들은 ADK와 상시 메모리 통합을 연속 자율성의 도약으로 보면서도, 결정적 경계 없이 백그라운드에서 “꿈꾸듯” 메모리가 교차 오염되면 컴플라이언스 악몽이 된다고 경고했다. 또 다른 반응은 토큰 비용보다 드리프트와 루프가 항상온 에이전트의 진짜 비용이라고 지적했다. 누가 메모리를 쓰는가, 무엇이 병합되는가, 보존·삭제 정책은 무엇인가, 학습 이력을 어떻게 감사하는가 같은 운영 과제가 핵심이다.

“No embeddings”에 대한 기술적 반론

일각에서는 임베딩이 없어도 결국 청크화·인덱싱·구조화 메모리 조회가 필요하며, 작은 컨텍스트에서는 잘 작동해도 대규모로 가면 한계가 드러날 수 있다고 본다. 벡터DB를 뺐다고 검색 설계가 사라지는 것은 아니며, 복잡성의 위치가 바뀔 뿐이다. 따라서 가벼운 스택은 저비용·유한 메모리 시나리오의 항상온 메모리 에이전트에 유리하지만, 대규모 배포에는 더 엄격한 검색 통제, 명시적 인덱싱, 수명주기 도구가 요구된다.

아직 제시되지 않은 부분

비교 벤치마크와 통제 장치

제공 자료에는 프로덕션 에이전트 루프에서의 Flash‑Lite 대 Anthropic Claude Haiku 직접 비교가 없다. 또한 결정적 정책 경계, 보존 보장, 분리 규칙, 공식 감사 워크플로 같은 엔터프라이즈급 통제도 구체화되어 있지 않다. 내부적으로 전문 에이전트를 활용하는 듯하지만, 다수 독립 에이전트 간의 영속 공유 메모리를 입증하는 수준은 아니다. 현재 레포는 완성형 플랫폼이라기보다 설득력 있는 엔지니어링 템플릿이다.

왜 지금 중요한가

장기 맥락과 신뢰 가능한 메모리

엔터프라이즈 AI는 단발성 보조를 넘어 선호 기억, 프로젝트 맥락 유지, 장기 지향 운영을 요구한다. 오픈소스 항상온 메모리 에이전트는 그 다음 계층을 시작할 현실적 기반을 제공하고, Flash‑Lite가 경제성을 보완한다. 결론적으로, 평가는 능력 못지않게 거버넌스에 달려 있다. 핵심 질문은 에이전트가 기억할 수 있느냐가 아니라, 항상온 메모리 에이전트가 경계가 분명하고, 점검 가능하며, 프로덕션에서 신뢰할 만큼 안전하게 기억하느냐다.