TencentDB Agent Memory: AI 에이전트의 기억을 계층화한다는 것

한 줄 요약

TencentDB Agent Memory는 AI 에이전트에게 로컬 장기 기억과 단기 작업 기억을 제공하는 오픈소스 메모리 시스템이다. 내가 보기엔 이 프로젝트의 핵심은 “기억을 더 많이 저장하자”가 아니라 기억을 평평한 벡터 더미로 만들지 말고, 추상 수준과 근거 경로가 있는 구조로 관리하자는 점이다.

PyTorch Korea에 소개된 글은 이 프로젝트를 “계층형 로컬 기억 시스템”으로 정리한다. GitHub README도 같은 방향을 강조한다. TencentDB Agent Memory는 symbolic short-term memory와 layered long-term memory를 결합하고, 기본적으로 SQLite와 sqlite-vec 기반 로컬 저장을 사용한다.

왜 에이전트에게 기억이 필요한가

AI 에이전트를 실제 업무에 붙여 보면, 모델의 답변 품질보다 먼저 체감되는 문제가 있다. 매번 같은 설명을 반복해야 한다는 점이다.

예를 들면 이런 것들이다.

• 이 프로젝트의 배경과 현재 상태
• 자주 쓰는 명령어와 테스트 방식
• 팀의 출력 형식과 보고 스타일
• 사용자가 선호하는 답변 톤
• 이전 작업에서 이미 실패했던 접근
• 장기 세션 중 쌓인 로그, 검색 결과, 중간 판단

처음에는 컨텍스트를 길게 넣으면 해결될 것처럼 보인다. 하지만 컨텍스트에 모든 것을 계속 넣는 방식은 금방 한계가 온다. 토큰 비용이 커지고, 중요하지 않은 로그가 모델의 주의를 빼앗고, 과거 정보와 현재 정보가 뒤섞인다.

그래서 에이전트 메모리의 목표는 단순히 “많이 저장하기”가 아니다. 좋은 메모리는 오히려 매번 컨텍스트에 넣어야 하는 정보를 줄여야 한다. 지금 필요한 기억만 적절한 추상 수준에서 꺼내고, 세부 근거가 필요할 때만 원문으로 내려갈 수 있어야 한다.

TencentDB Agent Memory가 흥미로운 이유가 여기에 있다. 이 프로젝트는 메모리를 하나의 벡터 저장소로 보지 않고, 장기 기억과 단기 기억을 서로 다른 구조로 다룬다.

평면 벡터 저장소의 한계

많은 메모리 시스템은 대화나 문서를 chunk로 자른 뒤 embedding해서 vector store에 넣는다. 다음 작업에서는 유사도 검색으로 관련 chunk를 가져온다. 이 방식은 빠르게 만들 수 있고, RAG 스타일 시스템에서는 여전히 유용하다.

문제는 에이전트의 기억이 단순 문서 검색과 다르다는 점이다.

에이전트가 기억해야 하는 정보에는 층위가 있다.

일시적 작업 로그
  < 프로젝트별 규칙과 결정
  < 반복되는 업무 시나리오
  < 사용자의 장기 선호와 협업 스타일

“방금 npm run build가 실패했다”는 정보와 “사용자는 장황한 개념 설명보다 실무적 판단을 선호한다”는 정보는 모두 기억이지만 성격이 완전히 다르다. 전자는 단기 작업 상태에 가깝고, 후자는 장기 페르소나에 가깝다.

이 둘을 같은 벡터 공간에 평평하게 저장하면, 검색은 될 수 있지만 운영이 어려워진다.

• 이 정보가 얼마나 안정적인 사실인지 알기 어렵다.
• 어떤 프로젝트나 시나리오에만 적용되는지 구분하기 어렵다.
• 잘못된 기억이 왜 불러와졌는지 디버깅하기 어렵다.
• 요약 과정에서 근거가 사라지면 나중에 검증하기 어렵다.

TencentDB Agent Memory의 README는 이 문제를 “flat vector piles”의 한계로 설명한다. 단순히 더 많은 chunk를 저장하는 것이 아니라, 기억의 형성과 회상 자체가 계층적이어야 한다는 주장이다.

장기 기억: L0에서 L3까지의 의미 피라미드

TencentDB Agent Memory의 장기 기억은 L0부터 L3까지 이어지는 semantic pyramid로 구성된다.

L3 Persona
  사용자 선호, 협업 스타일, 안정적인 프로필
 
L2 Scenario
  프로젝트, 주제, 워크플로우 단위의 장면
 
L1 Atom
  사실, 선호, 제약, 상태 같은 원자 정보
 
L0 Conversation
  원본 대화와 이벤트 스트림

이 구조의 장점은 정보가 위로 갈수록 압축되지만, 아래의 근거를 잃지 않는다는 점이다.

L0는 원본 대화와 이벤트를 보존한다. L1은 그 안에서 사실, 선호, 제약, 상태 같은 원자 정보를 뽑는다. L2는 원자 정보를 프로젝트나 시나리오 단위로 묶는다. L3는 반복적으로 관찰되는 사용자 선호와 협업 스타일을 페르소나로 정리한다.

여기서 중요한 것은 “요약해서 원문을 버리는 것”이 아니다. 상위 계층은 구조를 제공하고, 하위 계층은 근거를 제공한다. 에이전트가 L3 Persona를 참고해 답변하더라도, 필요하면 L2 Scenario, L1 Atom, L0 Conversation으로 내려가 근거를 확인할 수 있어야 한다.

나는 이 부분이 에이전트 메모리에서 꽤 중요하다고 본다. 메모리는 오래될수록 도움이 되기도 하지만, 동시에 부채가 되기도 한다. 예전에는 맞았지만 지금은 틀린 프로젝트 규칙, 한 번의 예외를 일반화한 사용자 선호, 실패한 작업에서 생긴 과도한 회피 패턴이 장기 기억에 남을 수 있다.

그렇기 때문에 장기 기억은 반드시 inspectable해야 한다. 사람이 열어 보고, 고치고, 삭제할 수 있어야 한다. TencentDB Agent Memory가 상위 계층을 Markdown처럼 사람이 읽을 수 있는 형태로 남기는 것도 이 맥락에서 의미가 있다.

단기 기억: 긴 로그를 심볼 그래프로 압축하기

장기 기억과 별개로, 에이전트는 긴 작업 중에도 기억이 필요하다. 특히 코딩 에이전트나 리서치 에이전트는 한 세션 안에서도 많은 중간 산출물을 만든다.

• 검색 결과
• 터미널 로그
• 테스트 실패 메시지
• 코드 diff
• 오류 추적 과정
• 이미 시도한 해결책

이런 정보는 중요하지만, 그대로 컨텍스트에 계속 들고 다니기에는 너무 길다. TencentDB Agent Memory는 이 문제를 symbolic short-term memory로 푼다.

핵심 아이디어는 전체 로그를 컨텍스트에 넣지 않는 것이다. 원본 로그는 외부 파일로 offload하고, 컨텍스트에는 Mermaid 기반의 가벼운 symbol graph를 남긴다. 각 node에는 node_id가 있고, 에이전트는 필요한 경우 해당 node를 통해 원문 로그로 내려간다.

대략 이런 구조다.

verbose tool logs
  -> refs/*.md로 원문 저장
  -> jsonl 형태의 step summary 추출
  -> Mermaid canvas로 현재 작업 상태 압축
  -> 필요할 때 node_id로 원문 재조회

이 접근은 단순하지만 실용적이다. 장기 작업에서 토큰을 많이 잡아먹는 것은 최종 결론보다 중간 로그인 경우가 많다. 모든 로그를 계속 컨텍스트에 넣으면 모델은 쉽게 산만해진다. 반대로 로그를 모두 버리면 나중에 검증할 수 없다.

TencentDB Agent Memory는 이 둘 사이에서 절충한다. 컨텍스트에는 고밀도 심볼만 남기고, 원문은 외부에 보존한다. 그래서 토큰은 줄이되 traceability는 유지한다.

로컬 우선 메모리라는 점

TencentDB Agent Memory는 기본적으로 로컬 우선 구조를 지향한다. README 기준으로 SQLite와 sqlite-vec를 사용하고, 외부 API 의존성 없이 동작하는 것을 강조한다. OpenClaw 플러그인 형태로 설치할 수 있고, Hermes Gateway와 연결하는 방식도 제공한다.

메모리 시스템에서 로컬 우선은 단순한 취향 문제가 아니다. 에이전트 메모리에는 민감한 데이터가 쌓인다.

• 사용자의 업무 습관
• 프로젝트 내부 맥락
• 도구 사용 규칙
• 실패 이력과 디버깅 로그
• 장기적으로 축적된 선호와 제약

이런 정보를 외부 서비스에 맡기는 것은 팀이나 개인 환경에 따라 부담이 클 수 있다. 로컬 저장은 사용자가 직접 파일과 DB를 확인하고, 백업하고, 삭제할 수 있다는 장점이 있다.

물론 로컬 우선이 모든 문제를 해결하는 것은 아니다. 팀 단위로 쓰려면 권한, 동기화, 백업, 여러 에이전트 간 메모리 격리 문제를 따로 설계해야 한다. 하지만 개인 에이전트나 로컬 개발 에이전트에는 꽤 자연스러운 출발점이다.

벤치마크 수치는 어떻게 볼까

TencentDB Agent Memory README는 OpenClaw 통합 결과로 몇 가지 수치를 제시한다.

• WideSearch에서 토큰 사용량 최대 61.38% 감소
• WideSearch pass rate 상대 기준 51.52% 개선
• SWE-bench, AA-LCR에서도 토큰 감소와 성공률 개선
• PersonaMem 정확도 48%에서 76%로 상승

이 수치들은 인상적이지만, 그대로 일반화하기보다는 방향성을 보는 게 좋다. 에이전트 메모리의 효과는 작업 유형, 세션 길이, 회상 정책, 모델, 도구 구성에 크게 좌우된다.

다만 중요한 신호는 있다. 메모리 시스템이 잘 설계되면 토큰을 더 쓰는 것이 아니라 덜 쓰게 만든다는 점이다. 장기 세션에서 모든 히스토리를 다시 읽는 대신, 현재 필요한 구조만 컨텍스트에 올리고 세부 근거는 필요할 때 내려가는 방식이 가능해진다.

이것은 앞으로 에이전트 런타임에서 꽤 중요한 최적화 축이 될 가능성이 높다. 컨텍스트 윈도우가 커져도 모든 것을 계속 넣는 방식은 비싸고 불안정하다. 더 큰 컨텍스트보다 더 좋은 메모리 구조가 필요한 순간이 온다.

설치 관점에서 보면

OpenClaw 환경에서는 npm 패키지 형태로 플러그인을 설치하고 gateway를 재시작하는 방식으로 시작할 수 있다.

openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
openclaw gateway restart

설정은 기본적으로 로컬 SQLite와 sqlite-vec 백엔드를 사용한다. README에는 Hermes Gateway를 Docker로 띄우는 구성도 함께 안내되어 있다. Gateway는 기본적으로 8420 포트에서 동작하며, 필요하면 API key와 CORS origin 설정을 통해 외부 노출 시 보안 옵션을 켤 수 있다.

여기서 내가 눈여겨본 부분은 설치 명령보다 configuration philosophy다. 에이전트 메모리는 자칫하면 설정 항목이 너무 많아져서 운영하기 어려워진다. TencentDB Agent Memory는 기본값으로 시작하고, recall strategy, recall max results, memory extraction interval, persona generation interval 같은 항목을 필요에 따라 조정하는 쪽에 가깝다.

즉, 처음부터 완벽한 메모리 정책을 설계하라고 요구하기보다, 로컬에서 관찰 가능한 형태로 켜고 점진적으로 조정하는 방식이다.

실무 적용 시 내가 볼 체크포인트

이런 메모리 시스템을 실제 에이전트에 붙인다면, 나는 기능 목록보다 다음 체크포인트를 먼저 볼 것 같다.

1. 어떤 정보가 장기 기억으로 승격되는가

메모리 시스템에서 가장 위험한 지점은 저장이 아니라 승격이다. 한 번 나온 말을 장기 선호로 저장하면 오염이 생긴다. 반대로 반복적으로 확인된 프로젝트 규칙을 저장하지 않으면 매번 다시 설명해야 한다.

그래서 L1 Atom에서 L2 Scenario, L3 Persona로 올라가는 기준이 중요하다. 반복성, 안정성, 적용 범위, 최근성 같은 기준이 있어야 한다.

2. 잘못된 기억을 수정할 수 있는가

에이전트가 잘못된 기억을 불러왔을 때, 사용자는 “그거 아니야”라고 말할 수 있어야 한다. 더 나아가 어떤 기억 항목이 문제였는지 확인하고 수정할 수 있어야 한다.

Markdown 기반의 persona, scenario, canvas는 이 점에서 장점이 있다. black-box vector store만 있는 시스템보다 운영자가 개입하기 쉽다.

3. 회상 결과가 컨텍스트를 오염시키지 않는가

메모리가 많아질수록 recall은 더 조심해야 한다. 관련성이 낮은 과거 정보가 현재 작업에 끼어들면, 에이전트는 오히려 더 나쁜 결정을 할 수 있다.

좋은 메모리 시스템은 “많이 회상하는 것”보다 “필요한 것만 회상하는 것”에 가까워야 한다. TencentDB Agent Memory가 계층형 구조와 hybrid search를 함께 쓰는 이유도 여기에 있다.

4. 원문 근거로 내려갈 수 있는가

에이전트가 어떤 사용자 선호를 적용했다면, 그 선호가 어디서 나왔는지 확인할 수 있어야 한다. 작업 로그를 요약했다면, 그 요약이 어떤 원문 로그에서 나왔는지 되짚을 수 있어야 한다.

이 traceability가 없으면 메모리는 편리한 기능이 아니라 디버깅하기 어려운 암묵 상태가 된다.

에이전트 메모리의 방향성

TencentDB Agent Memory가 보여주는 방향은 꽤 명확하다. 에이전트 메모리는 RAG의 부속 기능이 아니라 런타임의 핵심 구성요소가 되고 있다.

앞으로의 에이전트는 단순히 긴 컨텍스트를 가진 모델이 아니라, 다음과 같은 구조를 가진 시스템에 가까워질 가능성이 높다.

사용자 요청
  -> 현재 작업 상태 확인
  -> 단기 심볼 메모리에서 진행 상황 회상
  -> 장기 계층 메모리에서 관련 persona/scenario 검색
  -> 필요한 경우 atom/conversation 근거 확인
  -> tool 실행
  -> 새 경험을 다시 memory pipeline에 반영

이 흐름에서 중요한 것은 모델이 모든 것을 직접 기억하지 않는다는 점이다. 모델은 메모리를 읽고 쓰는 주체지만, 메모리의 구조와 수명 주기는 런타임이 관리해야 한다.

나는 이 방향이 맞다고 본다. 에이전트를 오래 쓰려면 “똑똑한 모델”만으로는 부족하다. 무엇을 기억하고, 무엇을 잊고, 무엇을 근거로 남길지 관리하는 별도의 시스템이 필요하다.

TencentDB Agent Memory는 그 방향을 꽤 실용적으로 보여준다. 특히 다음 조합이 좋다.

• 로컬 우선 저장
• L0에서 L3까지의 계층형 장기 기억
• Mermaid 기반 심볼릭 단기 기억
• node_id 기반 원문 추적
• 사람이 읽을 수 있는 상위 메모리 산출물

이 구조는 에이전트가 “더 많이 기억하는” 시스템이라기보다, 사람이 검토할 수 있는 방식으로 “더 잘 기억하는” 시스템에 가깝다.

마무리

에이전트 메모리를 단순히 “대화 기록 저장”으로 보면 벡터DB 하나로 충분해 보인다. 하지만 실제 업무 에이전트는 대화 기록보다 더 복잡한 것을 기억해야 한다. 사용자의 선호, 프로젝트 맥락, 작업 로그, 실패 이력, 도구 사용 규칙, 반복되는 시나리오가 모두 섞인다.

그래서 메모리에는 구조가 필요하다. 어떤 기억은 잠깐만 유지하고, 어떤 기억은 프로젝트 단위로 묶고, 어떤 기억은 사용자 페르소나로 승격해야 한다. 그리고 모든 추상화는 근거로 내려갈 수 있어야 한다.

TencentDB Agent Memory는 이 문제를 “계층화와 심볼화”라는 관점으로 푼다. 이 접근은 앞으로 에이전트 런타임을 설계할 때 꽤 자주 등장할 패턴처럼 보인다.

좋은 에이전트는 모든 것을 기억하는 에이전트가 아니다. 필요한 것을 적절한 층위에서 기억하고, 틀렸을 때 고칠 수 있으며, 판단의 근거를 되짚을 수 있는 에이전트다.

참고 링크

• PyTorch Korea 소개 글: TencentDB Agent Memory: AI 에이전트를 위한 계층형 로컬 기억 시스템
• GitHub: TencentCloud/TencentDB-Agent-Memory
• npm: @tencentdb-agent-memory/memory-tencentdb
• README: TencentDB Agent Memory README