에이전트 영속 메모리, 벡터 검색 없이 설계하는 방법

벡터 검색의 필요부터 검토해야 하는 이유

OptMem은 벡터 DB와 임베딩 모델 없이 append-only 로그와 이진 트리 인덱스로 에이전트 영속 메모리를 구현한 설계다. 이 접근은 에이전트 메모리를 벡터 검색 스택의 조합으로 보지 않고, 어떤 질의를 어떤 운영 비용으로 회수할지의 문제로 다시 다룬다.

임베딩 모델 버전이 바뀌면 전체 색인을 다시 만들어야 한다. 유사도 임계값도 서비스와 데이터 성격에 따라 조정해야 하며, 벡터 DB는 가용성과 백업 계획을 별도로 요구하는 운영 대상이 된다. 회수 질의가 특정 엔티티나 시점을 가리키는 경우가 대부분이라면, 이 부채를 감당할 이유가 있는지 먼저 따져볼 필요가 있다.

이 구조의 핵심은 추가 전용 로그, 트리 인덱스 키, 회수 경로, 시간 필터, 중복 병합, 재구축, 용량 통제, 정확도 지표를 하나의 메모리 체계로 묶는 데 있다.

로그를 보존하고 키로 회수 경로를 제한한다

추가 전용 로그에서는 기록을 수정하지 않고 끝에 새 항목을 붙인다. 갱신은 새 기록으로 남기고 이전 기록은 보존한다. 쓰기가 순차적으로 이뤄지므로 성능을 예측하기 쉽고, 손상 발생 시 복구 지점도 분명해진다.

이진 트리 인덱스에서 중요한 것은 어떤 항목을 찾을지 결정하는 키다. 대화 주제, 대상 엔티티, 시간 구간이 후보가 될 수 있다. 키가 질의 패턴에 맞지 않으면 인덱스가 있어도 전체 순회가 발생한다. 이 구조에서는 키 설계가 회수 성능을 좌우한다.

회수 경로는 정확 키 조회, 접두 범위 조회, 시간 범위 조회로 명시한다. 지원하지 않는 질의 유형도 문서화해야 한다. 의미 유사 검색이 필요한 질의를 이 구조에 억지로 넣으면 회수 품질이 무너질 수 있다.

시간순 로그는 구간을 잘라 조회하기 쉽고, 최근 기록을 우선하는 회수에도 적합하다. 오래된 구간의 회수 가중치를 낮추면 낡은 판단이 최신 맥락을 밀어내는 일을 줄일 수 있다. 반복 기록은 같은 대상의 항목을 병합하거나 최신 항목만 회수하는 방식으로 다룬다. 이때 병합 기준은 키 수준에서 정해야 하며, 내용 비교로 병합하기 시작하면 유사도 판단이 다시 필요해진다.

⤢✕

재구축과 보존 정책도 메모리 설계에 포함된다

키 설계를 바꾸면 원본 로그를 다시 훑어 인덱스를 재구축한다. 로그가 남아 있으므로 재구축 자체는 항상 가능하다. 다만 키 설계 변경의 실제 비용은 재구축에 걸리는 시간이므로, 이를 측정해 두어야 한다.

추가 전용 구조에서는 저장 용량이 단조 증가한다. 구간 압축과 아카이브 정책이 필요한 이유다. 아카이브한 구간을 어떤 방식으로 회수할지도 미리 정해야 한다. 접근할 수 없는 아카이브는 삭제와 다르지 않다.

회수된 정보가 실제 작업에 도움이 됐는지는 작업 성공률과 함께 기록한다. 회수 실패 사례를 유형별로 모으면 키 설계를 조정해 해결할 수 있는 실패와 의미 검색이 필요한 실패를 구분할 근거가 생긴다.

질의 로그를 기준으로 도입 범위를 정한다

도입 판단은 실제 에이전트가 무엇을 어떤 방식으로 찾는지 수집하는 데서 시작한다. 대부분이 정확 키 조회라면 벡터 검색은 과잉일 수 있다. 반대로 의미 유사 검색이 반드시 필요한 질의의 비중은 숫자로 파악해야 하며, 이 비중이 전체 판단의 기준이 된다.

키 설계 초안은 엔티티 식별자와 시간 구간을 기본 축으로 두고, 주제 키를 보조로 둘 수 있다. 이후 실제 질의 로그에 대입해 전체 순회가 발생하는지 확인한다.

기존 벡터 메모리와 비교할 때는 같은 질의 세트로 회수 결과와 작업 성공률을 함께 비교한다. 운영 항목 수와 장애 대응 시간도 기록해야 한다. 이 차이가 어떤 방식을 채택할지 판단하는 실질적 근거다.

작업 유형별로 회수 실패를 몇 퍼센트까지 허용할지 정하고, 실패하면 사용자에게 다시 묻는 경로를 준비한다. 실패를 조용히 넘기면 잘못된 맥락으로 작업이 진행될 수 있다.

벡터 저장소의 기존 항목을 로그 형식으로 옮길 때는 각 항목에 키를 부여한다. 이관 과정에서 회수 품질이 낮아질 수 있는 구간을 예상해 사용자에게 알려야 한다. 용량은 일간 증가량과 예상 도달 시점으로 감시하고, 임계에 닿기 전에 아카이브 시점과 방법을 정한다. 키 설계 변경과 아카이브 정책 조정은 승인 대상으로 두며, 회수 실패 유형 분포는 정기 보고 항목으로 편성한다.

로그·트리 방식과 벡터 DB 방식의 차이

구분	로그·트리 기반 메모리	벡터 DB 기반 메모리
운영 복잡도	낮음	높음
의미 검색 능력	없음	있음
회수 정확성	키 일치 시 완전	근사
버전 부채	없음	임베딩 모델 의존
인덱스 재구축 비용	낮음	높음
질의 표현력	제한적	넓음

로그·트리 기반 방식은 임베딩 모델과 벡터 저장소를 운영하지 않으므로 배포와 백업이 단순하다. 키가 일치하면 결과가 결정적이고, 원본 로그를 남겨 두면 인덱스도 다시 만들 수 있다. 반면 표현이 다르지만 같은 의미인 질문은 찾지 못한다. 질의 유형은 키 설계에 묶이며, 새 회수 요구가 생기면 재구축이 필요하다.

벡터 DB 기반 방식은 표현이 달라도 의미가 가까우면 관련 기억을 찾을 수 있다. 키를 미리 설계하지 않아도 되고, 새로운 회수 패턴에도 자연스럽게 대응한다. 대신 임베딩 모델 버전이 바뀌면 전체 색인을 다시 만들어야 하며, 유사도 임계값은 서비스마다 조정해야 한다. 벡터 저장소 역시 별도 가용성 관리 대상이 된다.

정확 키 회수는 결과 해석에 모호함이 없다. 찾으면 맞는 항목이고, 찾지 못하면 없다는 사실이 분명하다. 같은 질의는 항상 같은 결과를 낸다. 그러나 키가 조금만 달라져도 존재하는 항목을 놓칠 수 있고, 사용자의 자연스러운 표현을 키로 변환하는 단계가 필요하다.

유사도 근사 회수는 표현 차이를 흡수하고 관련되지만 정확히 일치하지 않는 항목까지 가져올 수 있다. 그만큼 관련 없는 항목이 임계값 안으로 들어오는 오회수도 구조적으로 존재하며, 그 비율은 데이터 분포에 따라 달라진다. 색인 갱신에 따라 같은 질의의 결과도 바뀔 수 있다. 오회수가 잘못된 맥락 주입과 작업 실패로 이어지는 영역이라면 낮은 재현율보다 오회수 억제가 우선한다.

임베딩 의존을 제거하면 모델 교체나 폐기에 영향을 받지 않고, 임베딩 호출 비용과 지연도 사라진다. 데이터가 외부 모델을 거치지 않으므로 반출 제약이 있는 환경에도 적용할 수 있다. 대신 의미 확장 검색이 불가능해지고, 표현 변화는 프롬프트나 질의 변환 단계가 떠안게 된다. 회수 실패를 분류해 키 설계로 해결할 수 있는 비중을 확인해야 어느 쪽의 부채를 감당할지 결정할 수 있다.

정보관리 관점에서 보는 선택 기준

추가 전용 로그와 트리 인덱스의 조합은 로그 구조화 저장의 전형적인 설계다. 인덱스 키와 재구축 절차는 질의 패턴에 맞춘 인덱스 설계의 핵심 논점이기도 하다.

정확 일치 검색과 근사 검색의 선택은 정밀도와 재현율 사이의 절충으로 볼 수 있다. 시간 가중치는 최신성을 순위 요소로 포함하는 랭킹 설계에 해당한다.

운영 구성 요소가 줄어들면 장애 지점도 줄어든다. 용량 증가 감시와 아카이브 정책은 이러한 구조를 장기적으로 유지하기 위한 저장 자원 관리 절차다.

질의 유형으로 갈리는 메모리 설계의 흐름

에이전트 메모리에서 벡터 검색을 기본값으로 두지 않고, 질의 유형에 따라 방식을 고르는 접근이 확산되는 방향이다. 임베딩 모델 교체 비용이 부각되면서 색인 재구축을 전제한 운영 계획도 요구 사항으로 자리 잡는 흐름이다.

로그 기반 메모리와 벡터 검색을 질의 유형별로 나눠 사용하는 혼합 구성도 실무 표준으로 정착하는 방향이다. 메모리 평가는 회수 정확도를 작업 성공률과 연결해 측정하는 지표 체계로 옮겨갈 수 있다.

회수 질의의 대부분이 특정 대상이나 시점을 가리킨다면, 벡터 검색이 감당해야 할 운영 부채는 정당화되기 어렵다. 반대로 의미 유사 검색이 실제 작업의 핵심이라면 로그와 키만으로 이를 대체할 수 없다. 원본 로그 보존, 회수 경로 명시, 시간 가중치, 실패 유형 수집은 최소 구성이고, 그 출발점은 실제 질의 로그다.