--- title: "인간 기억에 근접하다 — 텐센트 Agent Memory" date: 2026-10-08 time: 19:10 model: admin category: reviews summary: "텐센트 클라우드가 MIT 라이선스로 공개한 팀 단위 에이전트 메모리 허브. 대화·문서·코드를 네 가지 기억 자산으로 바꾸고, 접근 권한까지 관리한다. 설치 경로와 실제 쓰임새를 정리했다." tags: TencentDB, Agent Memory, 에이전트, 메모리, 팀 협업, MIT, 오픈소스 --- 에이전트에게 프로젝트 배경을 매번 다시 설명하는 일은 지치는 일이다. 문서도 매번 처음부터 읽히고, 지난 세션에서 통한 방식은 다음 세션에서 사라진다. TencentDB Agent Memory는 이 반복을 없애겠다고 나선 오픈소스 프로젝트다. 텐센트 클라우드 데이터베이스 팀이 MIT 라이선스로 공개했고, 저장소 이름은 TencentCloud/TencentDB-Agent-Memory다. 단순히 대화를 메모리에 남기는 도구가 아니라, 팀 단위로 기억 자산을 관리하고 에이전트에게 나누어 주는 허브에 가깝다. --- ## 무엇을 해결하려는가 이 프로젝트가 시작점으로 삼은 질문은 실용적이다. 프로젝트 맥락을 이미 설명했다면 새 세션에서 다시 설명할 필요가 없는 것 아닌가. 문서를 읽었다면 모든 에이전트가 첫 장부터 다시 읽을 필요가 없는 것 아닌가. 한 번 통한 작업 방식을 다음에 또 헤맬 필요가 있는가. 기존 정보를 재사용 가능한 기억 자산으로 바꾸고, 더 적은 턴과 더 적은 재작업으로 이어지게 한다는 흐름이다. README가 쓰는 비유는 세이브 파일이다. 대부분의 에이전트 첫 임무는 프로젝트를 다시 배우는 일이고, 이 도구는 이미 치른 학습 비용을 팀이 처음부터 불러올 수 있는 세이브 파일로 만든다는 얘기다. --- ## 기억 자산 네 가지 기억을 하나의 뭉뚱그린 덩어리로 두지 않고 네 가지 자산으로 나눈다. - **Chat Memory** — 선호도, 사실, 결정, 상호작용 이력을 담는다. 새 에이전트를 만들 때마다 자기소개를 다시 할 필요가 없다. - **Skill** — 반복 가능한 작업 절차. 버전, 리소스 파일, 트리거 경계, 실행 단계, 검증 규칙을 포함한다. 그냥 붙여넣는 프롬프트 조각이 아니라 버전 관리되는 실행 매뉴얼에 가깝다. 코드 리뷰, 장애 대응 체크리스트 같은 것을 한 번 배우면 팀 전체가 쓴다. - **LLM-Wiki** — 제품 문서, 설계 시방, 운영 런북을 링크 그래프가 있는 구조 페이지로 바꾼다. 카르파티의 LLM 지식 베이스 아이디어에서 영향을 받았다고 밝히고 있다. - **Code-Graph** — 코드 심벌, 파일, 호출 관계, 영향 경로를 색인한다. 단순 RAG가 에이전트에게 코드 위치를 알려준다면, CodeGraph는 여기를 고치면 저쪽에 영향이 갈 수 있다고 알려준다. 함수를 고치기 전에 호출자와 피호출자를 확인하고 영향 분석을 할 수 있다. Skill 메커니즘은 Nous Research의 Hermes Agent에서 빌려왔고, CodeGraph는 오픈소스 codegraph 프로젝트를 기반으로 한다. --- ## 인간형 4단계 기억 계층 Chat Memory는 평면 기록으로 두지 않는다. 원본 대화가 저장된 뒤 비동기 파이프라인으로 단계적으로 응축된다. | 계층 | 저장 내용 | 용도 | | --- | --- | --- | | L0 Conversation | 전체 문맥이 있는 원본 대화 로그 | 표현 확인, 타임스탬프, 출처 확인 | | L1 Atom | 추출한 사실, 선호도, 제약 조건, 이벤트 | 실행 가능한 정보의 정밀 검색 | | L2 Scenario | 프로젝트·시나리오 중심 지식 블록 | 새 세션에서 작업 맥락 신속 복원 | | L3 Core / Persona | 장기 프로필, 안정된 행동 패턴 | 팀의 핵심 맥락에 즉시 동기화 | 검색도 계층적이다. 보통 L2와 L3가 먼저 컨텍스트를 빠르게 잡아주고, 특정 사실이 필요할 때만 L1과 L0으로 내려간다. 검색은 BM25, 벡터 검색, RRF(Reciprocal Rank Fusion)를 결합한 하이브리드 방식이다. 결과는 항목 수, 문자 예산, 타임아웃으로 제한된다. 기억이 실제 작업의 컨텍스트 윈도우를 밀어내지 않게 한다는 설계다. 메모리를 얹었다가 프롬프트가 메모리로만 차는 실패 모드에 대한 직접적인 대응이다. --- ## 통합 방식과 접근 제어 통합은 단일 프록시 서버 방식이다. 플러그인이나 훅, MCP 서버를 따로 구축할 필요 없이 에이전트의 Base URL만 프록시로 바꾸면 된다. 공식 지원 리스트에는 Claude Code, Codex, CodeBuddy, WorkBuddy, Hermes, OpenClaw, DeepSeek Harness가 있다. SDK는 TypeScript와 Python을 제공한다. 설치는 Docker 이미지 세 개를 띄우는 형태다. memory-core, memory-hub, proxy를 한 번의 스크립트로 올리고 패널은 localhost:8125에서 연다. 기본 포트는 코어 8420, 패널 8125, 지식 8424, 프록시 8096이다. 셀프호스팅이며, MongoDB 저장 백엔드는 실험적이라 기본값은 꺼져 있다. 접근 제어가 이 프로젝트의 실질적 차별점이라는 평가가 많다. RAG는 무엇을 찾을 수 있는가를 묻는다면, 팀 메모리는 누가 쓸 수 있는가, 어느 버전이 유효한가, 어느 에이전트에게 줄 것인가를 묻는다. 가시성은 네 단계다. - **private** — 소유자만. 팀 관리자도 못 읽는다. - **team** — 팀 전체 열람, 소유자·관리자만 관리. - **restricted** — 사용자·역할·에이전트 ACL로 세밀하게 제어. - **agent** — 팀 안 특정 에이전트에게만 지급. 새 Chat Memory와 Skill은 기본값이 private이다. 공유는 명시적 행위다. 실제 코드베이스를 다루는 도구라면 이 기본값이 맞다. 릴리스용 Skill은 릴리스 에이전트에게만, 아키텍처 Wiki는 개발 에이전트 전원에게, CodeGraph는 코더와 리뷰어에게만 주는 식의 장비 구성이 가능하다. --- ## 수치와 성능 주장 공식 발표와 저장소 문서에 나오는 수치를 정리한다. 아래 숫자는 모두 제작 측 주장이다. - 안정판 v2.0.0은 2026년 8월 3일 공개. 그 뒤 v2.0.1(8월 25일)까지 배포됐다. - TeamMemory 업데이트는 2026년 8월 13일 발표. 개인용 기억을 팀 협업으로 확장하는 내용이다. - 공식 발표 기준 90일 만에 GitHub 스타 2만 개를 넘겼고, GitHub 트렌딩 1위에 오른 적이 있다. 2026년 10월 8일 기준 저장소 조회 기준 약 27,788스타다. - 토큰 사용량 최대 61.38% 절감, 과제 통과율 상대적 51.52% 향상이라는 내부 벤치마크 수치를 공개했다. - PersonaMem 기준 48퍼센트에서 76퍼센트로의 상승을 자기 보고했다. 독립 재현은 아직 없다. 숫자를 그대로 믿을 필요는 없다. 다만 방향은 분명하다. 기억을 잘라내고 예산을 걸면 컨텍스트가 줄고, 컨텍스트가 줄면 비용과 오류가 줄어든다는 설계 명제다. --- ## 경쟁 도구와 비교 단일 에이전트 기억 도구는 이미 많다. Cognee, Mem0, Supermemory, Honcho 같은 제품이 있다. 이 프로젝트가 다르게 접근하는 지점은 거버넌스다. 동료의 에이전트가 내 에이전트가 배운 것을 읽을 수 있어도, 내가 공유했을 때만 읽을 수 있다는 점이다. 기본값이 비공개고, ACL이 실질적으로 동작한다. 한 사람, 하나의 에이전트, 지속 기억이라면 다른 도구가 더 단순할 수 있다. 여러 사람이 여러 에이전트를 돌리는데 전원이 전부 보면 안 되는 정보가 있다면, 이 조건을 일급 사안으로 다루는 오픈소스 옵션은 아직 드물다. --- ## 총평 TencentDB Agent Memory는 기억을 세션 산출물이 아니라 팀 자산으로 취급한다는 점에서 방향이 뚜렷하다. 네 가지 자산 구조, 계층적 응축, 예산이 걸린 하이브리드 검색, 소유자·버전·ACL을 묶은 관리 패널이 하나의 흐름으로 이어진다. MIT 라이선스에 셀프호스팅이라 의존성 부담도 크지 않다. 다만 여전히 확인할 것은 있다. 벤치마크가 자기 보고 수치에 의존한다는 점, TeamMemory가 빠르게 움직이는 만큼 문서와 동작이 계속 바뀐다는 점, 프록시를 통하는 구조라 기존 에이전트 설정을 한곳에 모아야 한다는 점이다. AI 에이전트를 팀으로 돌리기 시작했다면, 기억을 개인이 아니라 팀 자산으로 관리할 시점이 왔는지를 확인하는 용도로 읽어보기 좋다. 기억 자산을 어떻게 나누고, 누구에게 줄 것인가를 미리 정해두는 일은 코드보다 먼저 생기는 편이 낫다.