TencentDB Agent Memory 2.0 팀 메모리 구조와 벤치마크 조건

8/07/2026 ·impact


에이전트를 두세 개 이상 굴리기 시작하면 같은 설명을 매번 다시 하게 됩니다. 텐센트가 MIT 라이선스로 공개한 TencentDB Agent Memory는 대화와 문서와 코드를 재사용 가능한 자산으로 쌓아 두고 여러 에이전트가 나눠 쓰게 만드는 도구입니다. v2.0.0에서 개인 단위였던 메모리가 팀 단위로 넓어졌고, 저장소 README는 이 기능을 "Team Memory Beta is evolving quickly"라고 소개합니다. 베타라는 단서가 문서 맨 위에 붙어 있다는 뜻입니다. 이 글은 TencentDB Agent Memory 저장소에서 직접 확인한 내용만 정리하고, 인용이 잦은 토큰 절감 수치가 어떤 조건에서 측정된 것인지 짚습니다.

메모리 자산 네 가지로 나눈 저장 대상

이 도구는 저장 대상을 네 가지로 나눕니다. Chat Memory는 선호와 사실, 결정, 상호작용 이력을 보관합니다. 에이전트를 만들면 각자 메모리를 하나씩 갖고 시작합니다. Skill은 잘 돌아간 작업에서 뽑아낸 재사용 절차입니다. 버전과 리소스 파일, 트리거 경계, 실행 단계, 검증 규칙이 함께 붙습니다. Wiki는 문서를 링크 그래프가 딸린 구조화된 페이지로 바꿉니다. CodeGraph는 저장소의 심볼과 파일, 호출 관계, 영향 경로를 색인해서 에이전트가 코드를 고치기 전에 영향 범위를 먼저 보게 합니다.

네 가지는 모두 Memory Asset이라는 하나의 이름으로 등록됩니다. 소유자와 버전, 상태, 공개 범위, 사용 횟수, 에이전트 바인딩을 Memory Hub 패널 한곳에서 관리합니다. 자산을 열었을 때 내용만 보이는 구조가 아닙니다. 어디서 왔고 어느 버전이며 누구에게 배정됐고 최근에 쓰인 적이 있는지가 함께 붙습니다.

콜드 스타트도 같은 틀로 처리합니다. 기존 저장소를 넣으면 CodeGraph가 색인하고, 문서를 넣으면 Wiki가 페이지를 만들고, 지난 대화 세션을 넣으면 Skill과 Chat Memory가 추출됩니다. 운영 쪽 기록이 특히 Skill 후보로 잘 맞습니다. 예를 들어 EKS에서 Vault 파드와 PVC를 지운 뒤 Raft 클러스터를 복구한 절차처럼 한 번 검증해 둔 복구 순서, 쿠버네티스 인증서 만료를 확인하고 kubeadm certs renew로 갱신하는 점검처럼 주기가 정해진 작업이 그렇습니다.

공개 범위는 기본이 비공개입니다

새로 만들어진 Chat Memory와 Skill은 기본이 private입니다. 공유는 명시적으로 해야 하는 행동이고 기본값이 아닙니다. README의 표는 공개 범위를 네 가지로 적습니다.

  • private: 소유자만 열람, 팀 관리자도 제외
  • team: 팀 구성원 열람, 소유자와 관리자가 관리
  • restricted: User / Role / Agent ACL로 범위 지정
  • agent: 같은 팀 안에서 특정 에이전트에 지정 배정

역할은 두 층입니다. 전역 System Admin이 사용자와 팀을 만들고, 팀 안에서는 Admin과 Member가 자산 협업과 접근 제어를 맡습니다. 자산마다 Owner가 따로 추적되고 소유자는 자기 자산의 관리 권한을 자동으로 갖습니다.

실제 운용은 장비 배정에 가깝습니다. 릴리스 Skill은 릴리스 담당 에이전트에게, 아키텍처 Wiki는 개발 에이전트 전체에게, CodeGraph는 코드를 쓰는 쪽과 리뷰하는 쪽에 붙이는 식입니다. 에이전트마다 받는 자산이 다르니 문맥에 들어가는 양도 달라집니다. 다만 README는 자산 바인딩이 아직 수동이고 자동 라우팅은 다듬는 중이라고 적어 뒀습니다. 팀이 커질수록 이 수동 배정 비용을 누가 감당할지 먼저 계산해 보는 편이 좋습니다.

L0에서 L3으로 올라가는 계층과 컨텍스트 오프로딩

장기 기억은 네 계층으로 정제됩니다. 대화는 일단 L0로 저장되고 비동기 파이프라인이 위 계층을 만듭니다.

| 계층 | 저장하는 것 | 쓰임 | | --- | --- | --- | | L0 Conversation | 문맥이 다 붙은 원본 대화 | 표현과 시각, 출처 확인 | | L1 Atom | 대화에서 뽑은 사실과 선호, 제약, 이벤트 | 실행에 쓸 정보의 정확한 회수 | | L2 Scenario | 프로젝트나 상황 단위로 묶은 지식 블록 | 작업 문맥 복원 | | L3 Core / Persona | 장기 프로필과 안정적인 패턴 | 사용자와 팀의 맥락에 빠르게 진입 |

검색도 같은 순서를 탑니다. 평소에는 L2와 L3이 문맥을 빠르게 깔아 주고, 구체적인 사실이 필요할 때 BM25와 벡터 검색을 RRF로 합쳐 L1과 L0으로 내려갑니다. 결과는 건수와 문자 예산, 타임아웃으로 잘라 냅니다. 메모리가 컨텍스트 창을 잡아먹지 않게 막는 장치입니다.

단기 기억 쪽은 접근이 다릅니다. 길게 늘어지는 도구 로그를 파일로 내보내고 문맥에는 압축된 Mermaid 작업 캔버스만 남깁니다. 요약만 남기면 근거를 잃기 쉬운데, node_id를 따라가면 refs 아래 원문 마크다운을 다시 꺼낼 수 있습니다. 뒤에 나오는 토큰 수치가 이 방식과 직접 연결됩니다.

Wiki와 CodeGraph는 바탕이 된 작업을 저장소가 밝혀 두었습니다.

LLM Wiki문서를 LLM이 점진적으로 키우는 지식 산출물로 보는 카파시의 메모 CodeGraphCodeGraph 자산 모듈이 코드를 가져다 쓴 사전 색인 코드 그래프 구현

토큰 61.38% 감소는 어떤 조건의 수치인가

이 숫자가 가장 많이 인용되는데 전제가 붙어 있습니다. 저장소 main 브랜치 README는 "When integrated with OpenClaw"라고 먼저 적고 표를 보여 줍니다. 표의 비교 열 이름 자체가 OpenClaw Success와 With Plugin입니다. OpenClaw 단독과 OpenClaw에 이 플러그인을 얹은 경우를 비교한 값이라는 뜻입니다.

| 벤치마크 | 통과율 | 토큰 | | --- | --- | --- | | WideSearch | 33% → 50% (+51.52%) | 2억 2,131만 → 8,564만 (−61.38%) | | SWE-bench | 58.4% → 64.2% (+9.93%) | 34억 7,410만 → 23억 7,540만 (−33.09%) | | AA-LCR | 44.0% → 47.5% (+7.95%) | 1억 1,200만 → 7,730만 (−30.98%) | | PersonaMem | 48% → 76% (+59%) | 해당 없음 |

61.38%는 WideSearch 한 벤치마크의 토큰 감소폭이고, 51.52%는 같은 벤치마크의 통과율 상대 개선폭입니다. 두 수치가 다른 환경에서도 재현된다는 표기는 없습니다. 같은 표에서 SWE-bench의 토큰 감소는 33.09%, AA-LCR은 30.98%로 폭이 꽤 다릅니다. PersonaMem의 48%에서 76%는 긴 상호작용 뒤 사용자 정보를 제대로 이해하고 적용하는지 보는 개인화 정확도이고, 토큰 항목은 아예 비어 있습니다. 절감률과 정확도를 한 문장에 섞으면 안 되는 이유입니다.

측정 방식에도 단서가 붙습니다. README는 이 결과가 한 턴짜리 측정이 아니라 연속된 롱호라이즌 세션에서 나왔고, SWE-bench는 세션당 50개 과제를 연달아 돌려 문맥이 쌓이는 압력을 재현했다고 적습니다. 문맥이 길게 누적되는 작업일수록 효과가 크게 잡히는 셋업입니다. 짧은 단발 요청 위주라면 같은 폭을 기대하기 어렵습니다.

한 가지 더 봐야 할 게 있습니다. 이 네 줄짜리 표는 main 브랜치 README에 있습니다. 저장소 기본 브랜치인 feat/server_team의 팀 메모리 README에서 Benchmark 섹션은 PersonaMem 한 줄뿐입니다. 팀 단위로 자산을 공유했을 때의 토큰이나 통과율 수치는 저장소에 없습니다. 팀 메모리 도입 효과를 저 표로 설명하는 자료를 만난다면 근거가 한 단계 건너뛴 것입니다.

설치와 도입 전에 확인할 것

CHANGELOG는 v2.0.0을 2026년 8월 3일자로 기록합니다. 배포는 세 서비스를 한 번에 띄우는 형태입니다. 저장소를 받아 deploy/global-images로 이동하고, .env.example을 복사한 뒤 LLM 파라미터를 메모리 쪽과 프록시 쪽 두 벌 채우고 start-all.sh를 실행합니다. README에 적힌 clone 주소는 Tencent 조직 경로인데 TencentCloud 저장소로 리다이렉트됩니다. Node.js는 22.16 이상이 필요합니다.

git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env
./start-all.sh

포트는 설치 문서에 정리돼 있습니다. 패널이 8125, 메모리 코어가 8420, 프록시가 8096입니다. 프록시는 Anthropic과 OpenAI 프로토콜을 모두 받고, Claude Code는 ANTHROPIC_BASE_URL을 프록시 주소로 돌려 붙입니다. 매 턴 해당 에이전트의 L2와 L3 메모리, 매칭된 Skill, Wiki와 CodeGraph를 시스템 프롬프트에 끼워 상위 LLM으로 넘기는 구조입니다. 앞단에 리버스 프록시를 두는 구성이라면 Nginx 액티브 헬스체크 모듈을 패치해 설치한 방식처럼 서비스별 상태를 따로 확인할 장치를 같이 두는 편이 낫습니다.

README의 Notes에 적힌 제약도 그대로 옮길 만합니다. Wiki와 CodeGraph는 비동기로 만들어지므로 ready 상태가 될 때까지 시간이 걸립니다. CodeGraph는 공개 HTTPS 저장소를 우선 지원하고 프라이빗 저장소와 SSH 자격 증명은 아직 다듬는 중입니다. 사내 저장소를 붙이려는 경우 여기서 먼저 막힐 수 있습니다. 연동 대상으로는 OpenClaw, Hermes, Claude Code, CodeBuddy, SDK가 적혀 있습니다.

판단 기준은 결국 문맥 누적량입니다. 에이전트 하나로 짧은 작업을 처리한다면 얻을 게 적습니다. 여러 사람이 여러 에이전트를 붙들고 같은 코드베이스를 오래 만지는 상황, 그러니까 React Router의 중첩 라우팅 구조를 손볼 때 어떤 화면이 함께 깨지는지 매번 다시 파악해야 하는 상황이라면 CodeGraph와 Wiki 쪽에서 값이 먼저 나옵니다. 베타 표기가 붙어 있으니 운영 데이터를 옮기기 전에 격리된 환경에서 자산 추출 품질부터 재 보는 순서를 권합니다.

저장소에서 README 확인하기설치 문서 보기

정리

  • 대화와 문서, 코드를 Chat Memory와 Skill, Wiki, CodeGraph 네 자산으로 등록하고 소유자와 버전, 공개 범위를 패널에서 관리하는 구조
  • 공개 범위 기본값은 private, 여기서 team과 restricted, agent로 넓히는 방식이라 공유가 명시적 행동
  • 토큰 61.38% 감소와 통과율 51.52% 향상은 OpenClaw에 플러그인을 얹은 WideSearch 결과이고, 벤치마크마다 폭이 다름
  • PersonaMem의 48%에서 76%는 개인화 정확도이지 토큰 절감이 아님
  • 팀 메모리는 README가 베타로 표기 중이며 CodeGraph의 프라이빗 저장소 지원과 자산 자동 라우팅은 아직 정리되는 단계

출처: TencentDB Agent Memory 저장소 README, 설치 문서, CHANGELOG, LICENSE