벡터 DB 없이 설계하는 Always On Memory Agent 영속 메모리

임베딩 파이프라인을 걷어낸 메모리 에이전트

2026년 3월 Google 제품 관리자 Shubham Saboo는 “Always On Memory Agent”를 MIT 라이선스로 공개했다. 이 프로젝트가 던진 질문은 명확했다. “벡터 데이터베이스 없이, 임베딩 없이, LLM이 읽고 생각하고 구조화된 메모리를 직접 작성한다”면 에이전트의 장기 기억을 어디까지 구현할 수 있는가.

Google의 Agent Development Kit(ADK)와 Gemini 3.1 Flash-Lite를 기반으로 만든 이 시스템은 구조화된 메모리를 SQLite에 보관한다. 기본값으로 30분마다 통합 작업을 실행해 저장된 내용을 다시 검토하고, 장기 세션에서 필요한 맥락의 일관성과 메모리 효율을 관리한다. 코드는 Google Cloud Platform의 공식 GitHub 저장소인 GoogleCloudPlatform/generative-ai에 공개됐다.

Always On Memory Agent가 연속적으로 수행하는 역할은 네 가지다. 파일과 API에서 텍스트·이미지·오디오·비디오·PDF를 수집하고, LLM이 내용을 분석해 구조화된 메모리로 바꾼다. 저장 이후에는 주기적으로 중복과 노이즈를 정리하며, 작업 에이전트가 정보를 요구하면 관련 메모리를 찾아 프롬프트 컨텍스트에 넣는다.

수집한 정보가 장기 기억이 되기까지

⤢✕

SQLite에는 수집한 원문을 그대로 쌓지 않는다. LLM이 원본을 분석한 뒤 의미 있는 단위로 정리한 엔트리를 저장한다. 각 엔트리에는 다음 정보가 들어간다.

content: 핵심 정보를 요약한 텍스트
source: 원본 정보의 출처
timestamp: 처음 수집한 시점
last_accessed: 망각 정책에 사용하는 최근 참조 시점
importance_score: LLM이 판단한 중요도인 0.0 ~ 1.0 범위의 값
category: 의미에 따라 부여한 분류 태그
related_ids: 관련 메모리 엔트리에 대한 참조

계속 들어오는 정보를 모두 보존하면 저장소는 끝없이 커진다. 이 문제를 다루기 위해 Always On Memory Agent는 두 가지 기준으로 망각 대상을 판단한다.

첫 번째는 중요도다. 중요도 점수가 임계값보다 낮고 최근 접근 빈도까지 낮은 메모리는 정기 통합 과정에서 삭제된다. 이때 중요도는 LLM이 해당 정보의 맥락적 가치를 평가해 정한다.

두 번째는 시간 기반 감쇠(Temporal Decay)다. 마지막 접근 이후 시간이 흐를수록 접근 가중치가 감소한다. 다만 중요도가 높은 메모리는 시간 감쇠의 영향을 상대적으로 적게 받는다.

벡터 검색 대신 LLM이 관련성을 판단한다

일반적인 RAG 기반 메모리 파이프라인은 다음 순서로 구성된다.

문서를 청크(Chunk)로 나눈다.
임베딩 API를 호출해 각 청크를 벡터로 변환한다.
Pinecone, pgvector, Weaviate 같은 벡터 DB에 저장한다.
질문도 임베딩한 뒤 ANN(Approximate Nearest Neighbor) 유사도 검색을 실행한다.
검색 결과를 LLM 프롬프트에 주입한다.

이 구조에서는 임베딩 API 비용과 벡터 DB 운영 복잡도를 함께 감당해야 한다. 시간의 흐름에 따라 의미가 바뀌어도 기존 임베딩이 이를 반영하지 못하는 의미 드리프트(Semantic Drift) 역시 고려해야 한다.

Always On Memory Agent는 이 검색 구간에서 임베딩을 사용하지 않는다. 요청이 들어오면 LLM이 SQLite에 저장된 요약 메타데이터, 즉 전체 메모리 인덱스를 검토하고 관련성이 높은 항목을 직접 고른다. 자연어 질문을 유연하게 해석할 수 있고 단순한 벡터 유사도로 잡기 어려운 추론적 관계도 찾을 수 있다.

대신 저장된 항목이 많아질수록 LLM이 검토해야 할 토큰도 늘어난다. 메모리 규모가 검색 비용으로 이어지는 스케일링 제약은 이 구조에서 피할 수 없는 조건이다.

통합과 충돌 처리가 세션의 맥락을 지킨다

장기 세션에서는 개별 메모리를 저장하는 것만큼 압축 방식이 중요하다. 통합 에이전트는 내용이 비슷한 엔트리를 하나로 병합해 저장 공간을 줄인다. 이 과정에서 일부 세부 정보가 사라질 수 있지만 핵심 의미는 보존된다.

세션 간 지속성은 SQLite 파일을 통해 확보한다. 에이전트 프로세스가 재시작돼도 이전 세션의 메모리는 파일에 남아 있으며, 새 세션은 이를 곧바로 참조할 수 있다.

같은 주제에 서로 모순되는 정보가 저장됐을 때는 LLM 기반 충돌 해결 절차가 개입한다. 기본 판단에서는 타임스탬프가 최신인 정보를 우선하고, 출처 신뢰도와 중요도 점수를 함께 검토해 최종 메모리를 결정한다.

LLM 메모리와 벡터 DB의 선택 기준

비교 항목	LLM 메모리(Always On Agent)	벡터 DB(RAG 기반)
구현 복잡도	낮음(SQLite + LLM)	높음(임베딩 파이프라인 + 벡터 DB)
검색 방식	LLM 추론 기반	수치 유사도(코사인, 유클리드)
검색 정확도	추론적 관련성에 강점	의미적 유사성에 강점
지연시간	LLM 추론 시간 필요	밀리초 수준 ANN 검색
비용 구조	LLM API 토큰 비용	임베딩 API + 벡터 DB 운영 비용
스케일링	소~중규모에 적합	대규모 문서 저장소에 강점
메모리 업데이트	LLM의 유연한 재해석	임베딩 재계산 필요
의미 드리프트	LLM의 맥락 이해로 자동 해결	임베딩 갱신 필요
운영 관리	SQLite 파일 관리	벡터 DB 클러스터 관리
장기 에이전트 적합성	지속성 기본 내장	별도 영속성 레이어 필요

LLM 메모리는 개인 AI 에이전트처럼 수천 개 항목 이하의 소규모 저장소에서 유리하다. LLM 기반 검색이 벡터 검색보다 맥락적으로 더 정확한 결과를 반환하며, 로컬 SQLite 파일을 사용하면 데이터가 외부 서비스로 전송되지 않아 프라이버시 측면에서도 이점이 있다.

코딩 어시스턴트나 개인 지식 관리 에이전트처럼 과거 행동과 선호를 계속 기억해야 하는 경우에도 추론 기반 검색이 잘 맞는다. 별도의 벡터 DB 설정 없이 SQLite로 시작할 수 있어 빠른 프로토타이핑에도 적합하다.

반면 수백만 건 이상의 문서를 밀리초 안에 찾아야 하는 엔터프라이즈 RAG라면 벡터 DB의 ANN 검색이 현실적인 선택이다. BM25 키워드 검색과 시맨틱 검색을 결합하는 하이브리드 RAG 파이프라인에도 벡터 DB가 필요하다. 금융이나 의료처럼 감사 추적과 정확한 출처 추적이 규정으로 요구되는 환경 역시 벡터 DB 기반 시스템이 더 적합하다.

Obsidian 노트에 연결한 검색 흐름

Always On Memory Agent가 공개된 뒤 커뮤니티에서는 이를 다른 도구와 결합하려는 사례가 나왔다. 그중 하나가 Obsidian 개인 지식 관리 도구와의 통합이다. 개발자들은 벡터 DB 기반 RAG에서 Always On Memory Agent 패턴으로 바꾼 뒤 노트 검색의 맥락 정확도가 높아지고 운영 복잡도가 크게 줄었다고 보고했다.

⤢✕

이 흐름에서 SQLite는 영속 저장소를 맡고, 메모리 에이전트는 검색 결과의 관련성을 다시 평가한다. 작업 에이전트는 선별된 메모리를 컨텍스트로 받아 사용자의 요청을 처리한다. 같은 저장소를 다음 세션에서도 이용할 수 있으므로 대화나 작업이 끊겨도 이전 맥락을 이어갈 수 있다.

영속 메모리를 다루는 오픈소스 생태계

Always On Memory Agent와 함께 살펴볼 수 있는 프로젝트로는 Mem0, MemOS, memweave가 있다.

Mem0는 다중 사용자·다중 세션 LLM 애플리케이션을 위한 범용 메모리 레이어다. mem0ai/mem0 저장소에서 관리되며, Mem0와 OpenClaw, Ollama를 결합해 로컬 AI 에이전트에 영속 메모리를 추가하는 패턴도 주목받고 있다.

MemOS는 MemTensor가 개발한 자가 진화 메모리 OS다. 하이브리드 검색과 작업 간 스킬 재사용을 지원하며 35.24%의 토큰 절감 효과를 보고하고 있다.

memweave는 마크다운과 SQLite만으로 에이전트 메모리를 구성하는 제로 인프라 접근법이다. 벡터 DB 없이 메모리를 구현하는 방식이 Towards Data Science에 소개됐다.

Always On Memory Agent가 보여주는 핵심은 벡터 DB를 모든 에이전트 메모리의 전제로 둘 필요가 없다는 점이다. SQLite의 영속성과 LLM의 맥락 해석을 결합하면 장기 세션의 기억을 비교적 단순한 구조로 관리할 수 있다. 대규모 저장소와 밀리초 검색이 필요하면 벡터 DB가 여전히 유효하므로, 두 방식은 서로를 대체하는 단일 해답이라기보다 저장 규모와 검색 조건에 따라 고르는 설계 도구에 가깝다.