AI 에이전트가 길게 일할수록 성능을 흔드는 것은 단순한 “기억 부족”이 아니다. 사용자는 같은 배경을 반복 설명해야 하고, 에이전트는 검색 결과·코드·오류 로그 같은 도구 출력으로 컨텍스트를 빠르게 소모한다. 결국 중요한 정보가 묻히고, 매 작업마다 불필요한 토큰 비용이 쌓인다.
TencentDB Agent Memory는 이 문제를 겨냥한 로컬 우선 메모리 시스템이다. Tencent가 MIT 라이선스로 공개했으며, 기본적으로 로컬 SQLite와 sqlite-vec에서 실행된다.1 핵심은 더 많이 저장하는 것이 아니라, 에이전트가 다시 꺼내 쓸 수 있는 형태로 기억을 구조화하는 데 있다.
장기 기억: 대화를 그대로 쌓지 않는다
TencentDB Agent Memory의 장기 기억은 L0 Conversation, L1 Atom, L2 Scenario, L3 Persona의 4단계 구조로 구성된다.1
L0 Conversation: 원본 대화
L1 Atom: 사실, 선호처럼 작은 단위의 기억
L2 Scenario: 특정 작업이나 상황 단위의 장면
L3 Persona: 장기적으로 누적되는 사용자 프로필
이 구조의 의미는 분명하다. 에이전트가 매번 전체 대화 기록을 벡터 검색으로 뒤지는 대신, 먼저 사용자 프로필과 장면 수준의 요약을 참고하고 필요할 때만 원문으로 내려간다. 장기 기억을 단순 저장소가 아니라, 대화 조각을 사용자 프로필과 작업 맥락으로 증류하는 파이프라인으로 보는 접근이다.
실무적으로 중요한 차이는 “무엇을 저장했는가”보다 “다음 작업에서 무엇을 먼저 참고하게 할 것인가”다. TencentDB Agent Memory의 4단계 구조는 이 우선순위를 메모리 설계 안에 포함한다.
단기 기억: 컨텍스트를 작업 상태판으로 바꾼다
장기 기억만으로는 긴 작업의 토큰 폭증을 막기 어렵다. 실제 에이전트 작업에서 컨텍스트를 크게 차지하는 것은 사용자의 선호보다 도구 로그, 검색 결과, 코드 조각, 오류 메시지인 경우가 많다.
TencentDB Agent Memory는 이런 단기 기억의 도구 로그를 Mermaid 기호로 압축해 컨텍스트에 주입한다.1 Mermaid는 텍스트로 다이어그램을 표현하는 문법이다. 에이전트는 압축된 작업 지도를 통해 전체 흐름을 파악하고, 세부 내용이 필요할 때 node_id로 원본 로그를 다시 찾는다.
이 방식은 컨텍스트 창을 “모든 기록을 담는 창고”가 아니라 “현재 작업의 상태판”으로 쓰게 만든다. 에이전트에게 항상 필요한 것은 전체 원문이 아니라, 지금 어디까지 왔고 어떤 세부 정보에 접근할 수 있는지에 대한 구조화된 단서이기 때문이다.
평가 지표: 토큰 절감과 성공률을 함께 봐야 한다
메모리 시스템은 토큰을 줄이는 것만으로 충분하지 않다. 압축 때문에 필요한 정보가 사라지면 성공률이 떨어질 수 있기 때문이다. 따라서 TencentDB Agent Memory를 볼 때도 토큰 사용량과 작업 성공률을 함께 봐야 한다.
Tencent가 공개한 OpenClaw 연동 평가에서는 다음과 같은 결과가 제시됐다.1
| 평가 | 토큰 사용량 변화 | 성공률 변화 |
|---|---|---|
| WideSearch | 221.31M → 85.64M | 33% → 50% |
| SWE-bench | 3474.1M → 2375.4M | 58.4% → 64.2% |
| AA-LCR | 112.0M → 77.3M | 44.0% → 47.5% |
특히 SWE-bench 평가는 실제 장기 에이전트의 컨텍스트 누적 압력을 모사하기 위해 세션당 50개 연속 작업으로 수행됐다.1 이는 TencentDB Agent Memory가 겨냥하는 문제가 단발성 질의응답이 아니라, 여러 단계에 걸쳐 상태와 로그가 누적되는 장기 작업이라는 점을 보여준다.
다만 이 수치는 Tencent가 공개한 평가 결과다. 실무 도입을 판단하려면 자신의 워크플로에서 같은 기준으로 재검증해야 한다. 예를 들어 코딩 에이전트라면 장시간 디버깅 세션에서, 리서치 에이전트라면 반복 검색과 문서 요약이 누적되는 작업에서 토큰 사용량과 결과 품질을 함께 측정하는 식이다.
도입 관점: 어디에 먼저 써볼 만한가
TencentDB Agent Memory는 OpenClaw 플러그인과 Hermes Docker 이미지로 제공된다.1 로컬 SQLite와 sqlite-vec 기반으로 시작할 수 있다는 점도 실험 장벽을 낮춘다.
우선 적용해볼 만한 영역은 로그와 중간 산출물이 많이 쌓이는 에이전트다.
긴 코딩·디버깅 작업
반복 검색이 필요한 리서치 작업
문서 분석과 요약이 이어지는 업무
사용자 선호와 프로젝트 맥락을 장기간 유지해야 하는 개인화 에이전트
반대로 단발성 질의응답처럼 누적 맥락이 적은 작업에서는 효과가 제한적일 수 있다. 이 시스템의 가치는 “오래 일하는 에이전트가 무엇을 기억하고, 무엇을 압축하고, 무엇을 다시 찾아야 하는가”를 관리할 때 커진다.
결론
TencentDB Agent Memory가 던지는 메시지는 간단하다. 에이전트 메모리는 “많이 기억하기”가 아니라 “구조화해 필요할 때 꺼내기”다.
장기 기억은 대화를 사용자 프로필과 장면으로 증류하고, 단기 기억은 도구 로그를 Mermaid 기반 작업 지도로 압축한다. 이 조합은 컨텍스트 창을 무작정 늘리는 대신, 에이전트가 현재 작업에 필요한 단서를 더 효율적으로 다루게 한다.
따라서 TencentDB Agent Memory를 평가할 때의 핵심 질문은 하나다. 내 에이전트가 반복해서 잃어버리는 맥락과 낭비하는 로그를, 다시 사용할 수 있는 구조로 바꿀 수 있는가. 긴 코딩, 리서치, 문서 분석처럼 컨텍스트가 계속 누적되는 작업이라면 충분히 실험해볼 만하다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.