당신의 벡터 메모리 데이터베이스는 모든 것을 기억합니다. 그것이 바로 문제입니다.

거의 모든 벡터 데이터베이스(Vector Database)와 AI 메모리 구현에는 운영 환경에서 노드가 성장하는 것을 지켜보기 전까지는 합리적으로 들리는 설계 가정이 내포되어 있습니다. 그것은 바로 더 많이 기억하는 것이 항상 더 좋다는 것입니다.

우리의 AUDN 코드를 테스트하고 개선한 결과, 그것은 정확히 맞지 않았습니다.

99일 동안 실제 개발 세션에 대해 VEKTOR Slipstream을 실행한 결과, 데이터베이스는 4개의 네임스페이스(Namespace)에 걸쳐 1,413개의 저장된 메모리를 보유했습니다. 중요도 점수(Importance score) 분포를 살펴보면, 해당 메모리의 83%가 시스템이 노이즈 플로어(Noise floor)로 간주하는 1.0 중 0.25 미만에 머물러 있었습니다. 나머지 17%인 1,413개 중 단 60개의 메모리만이 0.75를 초과하며 모든 회상(Recall) 결과의 대부분을 차지했습니다.

이것이 바로 큐레이션 레이어(Curation layer)가 만들어내야 하는 결과물입니다.

점수가 낮은 1,154개의 메모리는 정확합니다. 그것들은 삭제되지 않습니다. 직접적인 쿼리(Query)를 통해 검색할 수 있습니다. 다만, 에이전트가 컨텍스트(Context)가 필요할 때마다 60개의 고신호(High-signal) 항목과 경쟁할 만큼 중요하지 않을 뿐입니다.

AUDN은 수백 번의 쓰기(Write) 작업에 걸쳐 이들에게 점수를 점진적으로 삭감했습니다. 왜냐하면 유사하거나, 더 구체적이거나, 혹은 더 빈번하게 강화된 메모리들이 동일한 영역을 더 잘 커버했기 때문입니다. 시스템은 계층 구조를 생성했습니다. 큐레이션이 없다면, 1,413개의 모든 메모리가 모든 회상 슬롯을 위해 동등하게 경쟁할 것이며, 에이전트는 실제로 중요한 것들과 함께 중복되고 가치가 낮은 컨텍스트를 지속적으로 노출하게 될 것입니다.

그것이 바로 큐레이션 레이어가 없는 표준 벡터 메모리의 모습입니다. 에이전트가 3개월이나 지난 답변을 자신 있게 내놓기 시작할 때까지 아무도 눈치채지 못하는, 느리고 보이지 않는 성능 저하입니다.

Vektor의 모든 메모리 노드는 0과 1 사이의 중요도 점수를 가집니다.

메모리가 처음 저장될 때, 해당 콘텐츠의 추정된 중요도 (significance)를 기반으로 점수가 부여됩니다. 이 점수는 고정되어 있지 않습니다. 의미론적으로 관련이 있지만 직접적으로 모순되지는 않는 새로운 메모리가 도착할 때마다, 기존 메모리에 대한 호환성 판정 (compatible verdict)은 작은 중복 페널티 (redundancy penalty)를 받게 됩니다.

이 페널티는 의도적으로 완만하게 설계되었습니다. 들어오는 콘텐츠가 얼마나 유사한지에 따른 계수를 기반으로 하며, 일반적으로 발생할 때마다 점수를 10~15% 정도 감소시킵니다. 하지만 수백 번의 세션에 걸쳐 이 효과는 복리로 누적됩니다. 수십 개의 대화에 걸쳐 유사한 기록을 통해 강화되는 프로젝트 도구 (project tooling)에 관한 메모리는, 활성 회상 (active recall)에서 더 이상 경쟁하지 못하는 노이즈 플로어 임계값 (noise floor threshold) 아래로 떨어질 때까지 점수가 꾸준히 낮아지게 됩니다.

노이즈 플로어 (noise floor)는 손상되었거나 잘못된 메모리를 담는 쓰레기통이 아닙니다. 시스템이 해당 메모리가 나타내는 정보의 가장 중요한 버전이 아니라고 판단했을 때 메모리가 이동하는 곳입니다.

이 메모리들은 여전히 저장되어 있으며 직접적인 쿼리 (direct query)를 통해 검색할 수도 있습니다. 다만, 분포의 상단으로 떠오른 60개의 고신호 (high-signal) 항목들과 함께 회상을 지배하는 것을 멈출 뿐입니다. 이것이 의도된 동작입니다. 즉, 가장 중요한 것이 먼저 표면으로 드러나고, 나머지 모든 것은 매 검색마다 노이즈를 유발하지 않으면서도 사용 가능한 상태로 남아있는 자연스러운 계층 구조 (natural hierarchy)를 만드는 것입니다.

아무도 이야기하지 않는 메커니즘

벡터 데이터베이스 (Vector databases)는 한 가지를 놀라울 정도로 잘합니다. 바로 정보를 저장하고, 다른 정보와 의미론적으로 유사한 정보를 찾아내는 것입니다. 이는 진정으로 유용하지만, 현재 사용 가능한 최선의 방법은 아닙니다.

사용자가 1월에 에이전트 (agent)에게 "저는 금융업에서 일합니다"라고 말하고, 4월에 "지난달에 은행을 그만두었습니다"라고 말하면, 벡터 저장소 (vector store)는 두 사실을 모두 충실히 기록합니다.

임베딩 (embeddings)은 동일한 주제에 관한 것이기 때문에 벡터 공간 (vector space) 내에서 서로 가깝게 위치합니다. 5월에 전문적인 맥락 (professional context)을 쿼리하면, 두 정보가 모두 반환됩니다. 에이전트 (agent)는 어떤 것이 최신인지 알려주는 메타데이터 (metadata) 없이 두 개의 상충하는 진실을 받게 되며, 모호한 맥락이 주어졌을 때 언어 모델 (language models)이 하는 방식대로 행동합니다. 즉, 현실을 반영할 수도 있고 그렇지 않을 수도 있는, 그럴듯하게 들리는 답변을 합성 (synthesises)해 버립니다.

이것은 검색 (retrieval)의 문제가 아닙니다. 더 나은 필터 (filters)를 추가하거나 더 스마트한 재순위화 (reranking)를 적용한다고 해서 호출 (recall) 시점에 이를 해결할 수는 없습니다. 왜냐냐하면 쿼리를 하는 시점에는 이미 모순이 그래프 (graph) 안에 존재하며 주의 (attention)를 끌기 위해 경쟁하고 있기 때문입니다. 이를 해결할 수 있는 유일한 곳은 상충하는 사실이 커밋 (committed)되기 전인 쓰기 계층 (write layer)뿐입니다.

이것이 바로 AUDN 게이트 (gate)의 아키텍처 (architecture)를 이끈 통찰입니다. 아래는 실제 운영 환경에서 작동하는 모습으로, 의미론적 (semantic), 인과적 (causal), 시간적 (temporal), 그리고 엔티티 (entity) 노드 (nodes)가 형성되는 과정입니다.

(운영 그래프, 시간적 노드만 표시)

쓰기 계층 큐레이션 게이트 (Write-Layer Curation Gate)가 실제로 하는 일

AUDN는 어떤 정보가 데이터베이스 (database)에 닿기 전, 모든 개별 메모리 쓰기 (memory write) 단계에서 동기식 (synchronously)으로 실행됩니다. 들어오는 모든 정보는 코사인 유사도 (cosine similarity)를 사용하여 가장 최근의 활성 메모리 200개와 비교됩니다. 이는 2밀리초 미만으로 완료되는 순수 SQLite 작업입니다. 유사한 것이 없다면, 해당 메모리는 새로운 추가 사항으로 즉시 커밋 (committed)됩니다. 만약 코사인 점수 (cosine score) 0.72 이상의 유사한 항목이 존재한다면, 게이트는 해당 쌍을 분류 (classification)를 위해 LLM으로 보냅니다.

이 테스트 실행에 사용된 LLM은 Groq llama3–8b-8192입니다. 이 모델은 빠르고, 관대한 무료 티어 (free tier) 제한을 가지고 있으며, 이 작업에 필요한 종류의 이진 분류 (binary classification)에 정확합니다.

API 비용과 속도 제한 (rate limits)을 관리 가능한 수준으로 유지하기 위해, 쌍(pairs)은 배치(batch)로 처리됩니다. 즉, 한 번의 호출로 최대 10개의 후보 쌍을 분류합니다. 어떤 이유로든 LLM을 사용할 수 없는 경우, AUDN은 유사도가 0.95 이상이면 아무 작업도 수행하지 않고(no-operation), 그 외의 모든 것은 호환 가능한 것으로 간주하는 휴리스틱 (heuristic) 방식으로 전환됩니다. 쓰기 작업은 절대 차단되지 않습니다. 이 폴백 (fallback) 방식은 정확도를 희생하여 가용성을 확보하며, 이는 올바른 트레이드오프 (tradeoff)입니다.

분류는 이진 (binary) 방식이 아닙니다. 다섯 가지 가능한 판결이 있으며, 각 판결은 서로 다른 동작을 생성합니다.

(엔티티 노드 조언: Supersession chain explicit edges — AUDN UPDATE)

호환 가능 (Compatible)은 두 사실이 서로 다른 관점에서 동시에 참임을 의미합니다. 들어오는 메모리는 저장되지만, 기존 메모리는 중요도 점수에서 약간의 중복 페널티 (redundancy penalty)를 받습니다. 시간이 지남에 따라 이는 자연스럽게 더 구체적이고, 더 자주 액세스되며, 더 최근의 메모리들을 우선순위 스택 (priority stack)의 상단으로 끌어올립니다.

모순됨 (Contradictory)은 들어오는 사실이 기존 사실과 직접적으로 충돌함을 의미합니다. 새로운 사실이 승리하지만, 한 가지 중요한 조건인 신뢰 행렬 (trust matrix)을 따릅니다. 만약 들어오는 메모리의 신뢰 점수가 기존 메모리 신뢰 점수의 80% 미만이라면, 판결은 대신 '호환 가능'으로 강등됩니다. 의미적 유사성 (semantic similarity)에 관계없이, 모호한 대화 파편은 검증된 세션 사실을 덮어쓸 수 없습니다. 진정한 모순이 확인되면, 기존 메모리는 즉시 삭제되는 대신 30일의 기간 동안 지수 감쇠 함수 (exponential decay function)를 사용하여 억제됩니다.

포함함 (Subsumes)은 들어오는 사실이 더 일반적이며 논리적으로 기존 사실을 포함하고 있음을 의미합니다. 기존 메모리는 콜드 스토리지 (cold storage)로 이동되어 아카이브되지만, 더 이상 활성 회상 (active recall)에서 경쟁하지 않습니다.

Subsumed(포섭됨)는 기존 사실이 더 일반적이며 새로 들어오는 정보가 아무것도 추가하지 않음을 의미합니다. 새로운 메모리는 완전히 버려지며, 대신 기존 메모리가 약간의 중요도 상승(importance boost)을 받습니다.

No-Op(무작위 작업 없음)은 새로 들어오는 사실이 이미 높은 신뢰도로 알려져 있음을 의미합니다. 코사인 유사도(cosine similarity)가 0.95 이상일 경우, 쓰기 작업은 건너뛰어지고 기존 메모리의 액세스 횟수(access count)가 증가합니다. 이것이 시스템이 동일한 것을 계속 저장하려는 자연스러운 경향을 처리하는 방식입니다. 즉, 사실의 두 번째 인스턴스는 중복을 생성하는 대신 첫 번째 인스턴스를 강화합니다.

83%의 발견

실제 라이브 개발 데이터베이스의 데이터를 살펴보면, 추상적인 설명으로는 볼 수 없었던 이 문제의 형태가 명확히 드러납니다.

99일 동안 축적된 1,413개의 활성 메모리 중 1,154개는 0.10에서 0.25 사이의 중요도 점수(importance score)를 가지고 있습니다. 이들은 Compatible(호환 가능) 경로를 여러 번 거치며, 관련은 있지만 모순되지 않는 메모리가 근처에 기록될 때마다 매번 작은 중복 페널티(redundancy penalties)를 누적해 온 메모리들입니다. 이들 중 어느 것도 틀리거나 모순되지 않습니다.

이들은 단지 반복적으로 강화되고, 빈번하게 액세스되었으며, 한 번도 페널티를 받지 않은 중요도 분포 상위 60개의 메모리보다 중요도가 낮을 뿐입니다.

이것이 의도된 결과입니다. 평면적인 벡터 저장소(flat vector store)는 모든 사실을 영원히 동일하게 중요한 것으로 취급하며, 이는 그래프가 커질수록 신호(signal)와 노이즈(noise)가 대등한 조건에서 경쟁하기 때문에 검색 품질이 저하됨을 의미합니다. 큐레이션된 그래프(curated graph)는 가장 의미 있고, 가장 강화되었으며, 가장 최신인 사실들이 상단으로 올라가고 나머지 모든 것은 사용 가능한 상태로 유지되되 회상(recall)을 지배하지 않게 되는 자연스러운 계층 구조를 생성합니다.

해당 데이터베이스 내의 60개 고신호(high-signal) 메모리는 세션 핸드오버(session handover) 노트, 확인된 아키텍처 결정 사항, 그리고 수십 개의 세션에 걸쳐 기록되고 재기록되며 액세스된 주요 프로젝트 사실들입니다. 이들은 떠오릅니다(float). 나머지는 가라앉습니다(sink). 데이터베이스가 커질수록 검색은 더 느려지고 노이즈가 심해지는 대신, 더 빠르고 정확해집니다. 이는 큐레이션되지 않은 벡터 저장소에서 발생하는 현상과는 정반대입니다.

실제 적용 사례에서의 신뢰 매트릭스 (The Trust Matrix in Practice)

해당 데이터베이스 내 메모리의 17%는 0.7 미만의 신뢰 점수 (trust score)를 가지고 있습니다. 이들은 주로 세션 인제스션 (session ingestion) 과정에서 자동으로 저장된, 추출된 대화 파편이나 추론된 사실들입니다. 나머지 70%는 0.9 이상의 신뢰 점수를 보유하고 있으며, 이는 직접 저장되고 확인된 정보를 나타냅니다.

신뢰 가드 (trust guard)가 존재하는 이유는 모든 쓰기 (writes) 작업이 동일한 출처에서 오지 않기 때문입니다. 대화 중에 가볍게 말하는 사용자는 확정된 결정을 명시적으로 기록하는 에이전트와는 다른 품질의 정보를 생성합니다.

신뢰도가 낮은 파편이 기존의 높은 신뢰도를 가진 메모리와 높은 의미론적 유사성 (semantic similarity)을 가지고 도착할 때, 모순 (Contradictory) 판정은 무시됩니다. 시스템은 설령 두 정보가 동일한 내용을 다루고 있더라도, 추측이 확실성을 덮어쓰는 것을 허용하지 않습니다.

이는 가드가 없을 때 발생하기 쉬운 실패 모드(failure mode)를 방지합니다. 즉, 에이전트가 확신이 없거나 불확실한 사용자의 발언 스트림을 처리할 때, 모든 “내 생각에는 아마도”나 “아마도 ~같은 것”이라는 표현이 유사성 임계값 (similarity threshold)을 넘어서면서 견고한 정보를 점진적으로 침식하고 덮어쓰는 현상을 막아줍니다.

아무것도 조용히 사라지지 않습니다

모든 AUDN 결정은 실제 작업이 실행되기 전에 감사 로그 (audit log)에 기록됩니다. 스키마 (schema)에는 수행된 작업, 영향을 받은 메모리, 결정 당시 콘텐츠의 500자 스냅샷 (snapshot), LLM이 분류 근거로 제시한 이유, 호출을 트리거한 코사인 유사도 (cosine similarity) 점수, 그리고 타임스탬프 (timestamp)가 저장됩니다. 이는 전체 결정 이력을 쿼리 (query)할 수 있음을 의미합니다:

const decisions = await memory.auditLog({ action: 'CONTRADICTORY', since: '30d' });  
// 지난 30일 동안 해결된 각 모순 (contradiction) 사례를 반환합니다. 
// 무엇이 억제되었는지, 무엇이 그것을 대체했는지, 그리고 그 이유를 포함합니다.

reason 필드는 특히 주의 깊게 살펴볼 가치가 있습니다. Groq가 한 쌍의 데이터를 모순적 (Contradictory)이라고 분류할 때, 판결과 함께 짧은 자연어 설명을 반환합니다. 해당 설명은 있는 그대로 (verbatim) 저장됩니다. 이를 사용자에게 노출하거나, 예상치 못한 에이전트 (agent) 동작을 디버깅하는 데 사용하거나, 이를 기반으로 설명 가능성 (explainability) 기능을 구축할 수 있습니다. 이는 자칫 불투명할 수 있는 큐레이션 (curation) 메커니즘을 관찰 가능하고 신뢰할 수 있는 것으로 바꿔줍니다.