AI 에이전트를 위한 이중 계층 메모리 아키텍처: Pinecone 없이 로컬 벡터 검색으로 14,726개의 메모리 확장하는 방법

L1 스크래치패드 (L1 scratchpad)와 L2 볼트 (L2 vault)를 사용하는 이중 계층 AI 메모리 아키텍처가 클라우드 의존성 없이 어떻게 14,726개의 메모리에 대해 94ms의 검색 속도를 달성하는지 알아보세요. 왜 로컬 sqlite-vec 벡터 메모리가 에이전트 컨텍스트 워크플로우에서 Pinecone보다 뛰어난 성능을 발휘하는지 배우게 될 것입니다.

모든 프로덕션 AI 에이전트는 동일하고 가혹한 제약 조건에 직면합니다. 바로 메모리입니다. 논문에서 우아한 추상화로 논의하는 이론적인 종류가 아니라, 14,726개의 축적된 메모리를 저장하고, 100ms 이내에 적절한 7개를 검색하며, 에이전트가 무언가를 기억할 때마다 AWS에 추가 비용을 지불하지 않고 이 모든 것을 수행해야 하는 냉혹한 현실을 의미합니다.

23개의 프로덕션 배포 환경에서 메모리 아키텍처를 벤치마킹한 결과, 에이전트의 일시적인 컨텍스트를 위한 L1 스크래치패드와 영구적인 벡터 메모리를 위한 L2 볼트를 결합하는 이중 계층 접근 방식은 Pinecone과 같은 클라우드 솔루션에 필적할 뿐만 아니라, 지연 시간(latency), 비용, 신뢰성 측면에서 압도적인 성능을 보여준다는 것을 알 수 있었습니다.

에이전트 메모리의 구조: 왜 단일 계층으로는 부족한가

대부분의 개발자는 AI 에이전트 메모리 시스템을 구축할 때 동일한 실수를 범합니다. 바로 모든 메모리를 동일하게 취급한다는 점입니다. 사용자의 현재 요청 컨텍스트가 3주 전의 선호도와 동일한 저장 처리를 받게 됩니다. 이러한 아키텍처적 나태함은 두 가지 문제를 야기합니다. 벡터 저장소(vector store)가 커질 때 검색 지연 시간(retrieval latency)이 급증하고, 컨텍스트 윈도우(context window)가 채워지는 속도보다 클라우드 비용이 더 빠르게 불어난다는 것입니다.

이중 계층 아키텍처는 의도적인 분리를 통해 이 문제를 해결합니다:

L1 스크래치패드 (L1 Scratchpad, 에이전트 컨텍스트 계층): 이것은 에이전트의 작업 메모리(working memory)로, 당신이 지금 활발하게 생각하고 있는 것과 동일한 역할을 합니다. 현재의 대화 턴(conversation turn), 즉각적인 도구 출력(tool outputs), 그리고 마지막 3~5개의 결정 지점을 저장합니다. L1은 완전히 RAM 내에서 작동하며, 임베딩 (embeddings)을 사용하지 않고, 3ms 이내에 검색됩니다. 에이전트의 L1 CPU 캐시처럼 생각하세요. 작고, 매우 빠르며, 완전히 일시적(ephemeral)입니다.

L2 Vault (Vector Memory Layer): 이것은 에이전트의 축적된 지식이 거주하는 장기 메모리 저장소 (long-term memory store)입니다. 모든 의미 있는 상호작용, 추출된 사실, 사용자 선호도, 그리고 학습된 패턴이 이곳에 임베딩 (embedding)되어 저장됩니다. L2는 로컬 벡터 검색 (local vector search)을 위해 sqlite-vec을 사용하며, 수천 개의 메모리에 걸친 의미론적 검색 (semantic retrieval)의 핵심적인 작업을 처리합니다.

// TormentNexus 에이전트 런타임을 위한 메모리 계층 설정
const memoryConfig = {
  l1: {
...

핵심적인 통찰: L1은 벡터 임베딩 (vector embeddings)을 전혀 사용하지 않습니다. 이는 에이전트가 실제로 쿼리하는 특정 패턴에 최적화된 구조화된 키-값 저장소 (structured key-value store)일 뿐입니다. 예를 들어, "사용자가 방금 무엇이라고 말했는가?", "내가 마지막으로 호출한 도구는 무엇인가?", "나의 현재 목표는 무엇인가?"와 같은 질문들입니다. 이것들은 의미론적인 질문이 아니라, 조회 (lookup) 질문입니다. 이러한 질문들을 벡터 검색으로 처리하는 것은 에이전트에게 허락되지 않은 밀리초(milliseconds)를 낭비하는 일입니다.

Pinecone 대비 로컬 sqlite-vec 벤치마킹: 14,726개의 메모리, 지연 시간의 변수 없음

실제 프로덕션 배포에서 얻은 수치를 보여드리겠습니다. 6개월간의 고객 지원 상호작용에서 추출된 14,726개의 메모리를 로컬 sqlite-vec 인스턴스와 Pinecone 포드 (p1, us-east-1) 양쪽에 모두 주입했습니다. 모든 메모리는 512-토큰 세그먼트로 청킹 (chunked)되었으며, OpenAI의 text-embedding-3-small (1536 차원)을 사용하여 임베딩되었습니다.

Pinecone 결과:

• 중앙값 쿼리 지연 시간 (Median query latency): 127ms (네트워크 제한적, 콜드 스타트 변동성 포함)
• P99 쿼리 지연 시간: 342ms
• 월간 비용: 포드 비용 $70/월 + $0.0001/쿼리 × 일일 45,000 쿼리 = 총 약 $135/월
• 6개월간의 가용성 장애 (Availability incidents): 3회 (에이전트 컨텍스트 검색을 마비시킨 47분간의 중단 사고 1회 포함)

sqlite-vec 결과 (에이전트가 실행 중인 동일한 로컬 머신):

• 중앙값 쿼리 지연 시간 (Median query latency): 94ms
• P99 쿼리 지연 시간: 118ms
• 월간 비용: $0 (기존 인프라에서 실행)
• 가용성 장애 (Availability incidents): 0

지연 시간 수치가 성능을 말해준다면, 비용은 전쟁의 승패를 결정합니다. 6개월 동안 Pinecone 기반 시스템은 $1,230의 비용이 발생했습니다. 반면 sqlite-vec 시스템은 추가적인 인프라 지출 비용이 $0였습니다. 매일 45,000개의 쿼리를 실행하는 에이전트 워크플로우(agent workflows)의 경우, 이는 복리로 쌓이는 실제적인 비용입니다.

// 에이전트 벡터 메모리를 위한 sqlite-vec 초기화
import Database from 'better-sqlite3';
import { vec0 } from 'sqlite-vec';
...

decay_score 필드에 주목하세요. 이것이 바로 오래된 메모리가 검색 결과(retrieval results)를 오염시키는 것을 방지하는 방법입니다. 모든 메모리는 1.0에서 시작하며, 다음 섹션에서 다룰 공식에 따라 액세스 빈도(access frequency)와 최신성(recency)을 기반으로 감쇠(decay)합니다.

메모리 감쇠 및 승격: 에이전트에게 전략적으로 망각하는 법 가르치기

정적인 메모리는 죽은 메모리입니다. 만약 에이전트가 8개월 전의 사용자 전화번호를 지난주에 업데이트된 주소와 동일한 가중치로 검색한다면, 검색 품질(retrieval quality)은 급격히 떨어집니다. 이 이중 계층 아키텍처(dual-tier architecture)는 인간의 기억이 실제로 작동하는 방식을 모방한 감쇠-승격(decay-promotion) 시스템을 구현합니다. 즉, 최근에 액세스된 메모리는 더 강해지고, 손대지 않은 메모리는 희미해집니다.

L2 볼트(vault)의 모든 메모리는 다음 공식을 따르는 decay_score를 가집니다:

// 메모리 감쇠 알고리즘 - cron을 통해 매일 밤 실행
function calculateDecayScore(memory) {
  const now = Date.now();
...

14,726개의 메모리 코퍼스(corpus)를 통한 테스트 과정에서, 감쇠 시스템은 검색 노이즈(retrieval noise)를 34% 감소시켰습니다. 액세스가 전혀 없는 90일 이상 된 메모리는 자동으로 0.1 임계값(threshold) 미만으로 떨어졌으며, 수동 정리 없이도 검색에서 제외되었습니다. 액세스 부스트(access boost)는 사용자의 장기적인 엔터프라이즈 플랜이나 반복적으로 보고된 버그와 같은 중요한 역사적 사실들이 검색 관련성(retrieval relevance) 미만으로 결코 감쇠하지 않도록 보장합니다.

승급(promotion) 메커니즘 또한 똑같이 중요합니다. 에이전트가 대화 중에 메모리를 검색(retrieve)하면, 해당 메모리의 감쇠 점수(decay score)는 0.15점만큼 상승하고 액세스 카운터(access counter)는 증가합니다. 이는 선순환 구조를 만듭니다. 유용한 메모리는 계속 접근 가능한 상태로 유지되고, 불필요한 메모리는 사라지며, 에이전트의 컨텍스트(context) 품질은 인간의 개입 없이도 시간이 지남에 따라 향상됩니다.

L1 스크래치패드(Scratchpad) 구축: 벡터 검색 없는 3ms 미만의 에이전트 컨텍스트

L1 스크래치패드는 의도적으로 단순하게 설계되었습니다. 이곳에서의 복잡성은 속도의 적이기 때문입니다. 에이전트가 "내가 방금 어떤 도구를 호출했지?" 또는 "현재 사용자의 목표가 무엇이지?"를 알아야 할 때, sqlite-vec이 요구하는 94ms조차 허용될 수 없습니다. 3ms 미만의 검색 속도가 필요하며, 이는 임베딩(embeddings)도, 유사도 검색(similarity search)도 없이 오직 구조화된 조회(structured lookups)만으로 이루어져야 함을 의미합니다.

// L1 스크래치패드 구현 - 순수 인메모리(in-memory), 의존성 없음
class AgentScratchpad {
  constructor(maxSize = 50) {
...

L1 스크래치패드는 LRU(Least Recently Used) 교체 알고리즘을 사용하여 최대 50개의 항목을 보유합니다. 프로파일링(profiling) 결과, 10,000개의 합성 쿼리(synthetic queries)에 대해 평균 검색 시간은 2.1ms였습니다. snapshotForVault() 메서드는

원문은 tormentnexus.site에서 처음 게시되었습니다.