텐센트, TencentDB Agent Memory 2.0 MIT 오픈소스 공개

텐센트, TencentDB Agent Memory 2.0 MIT 오픈소스 공개

텐센트 클라우드가 AI 에이전트용 팀 메모리 허브 TencentDB Agent Memory 2.0을 MIT 라이선스로 오픈소스 공개했다. 대화와 문서, 코드를 Chat Memory, Skill, LLM-Wiki, Code-Graph 네 가지 자산으로 정리해 팀 전체가 다시 꺼내 쓰게 만드는 구조다. 배포는 Docker 기반 자체 호스팅이고, 공개된 연동 대상은 Claude Code, OpenClaw, Hermes, CodeBuddy다. 프로젝트가 스스로 밝힌 차별점은 검색 정확도가 아니라 ACL(접근 제어 목록) 기반 가시성 통제다.

TencentDB Agent Memory 2.0은 대화·문서·코드를 네 가지 자산으로 나눠 팀 서버에 직접 올려 쓰는 자체 호스팅 메모리 허브다. (이미지: MarkTechPost)

한눈에 보기

· 라이선스는 MIT다. 사내 도입이나 상업적 재배포에 별도 계약 협상이 필요 없다.

· 관리 자산은 네 종류다 — Chat Memory, Skill, LLM-Wiki, Code-Graph.

· 배포는 Docker 자체 호스팅이다. 대화 기록과 코드 그래프를 외부 SaaS에 넘기지 않고 팀 서버에서 돌릴 수 있다.

· 연동 대상으로 이름이 공개된 도구는 Claude Code, OpenClaw, Hermes, CodeBuddy 네 가지다.

· 버전 표기는 v2.0이다. 1.x 대비 무엇이 바뀌었는지는 이번 공개 자료에 나오지 않는다.

네 가지 자산으로 쪼갠 팀 기억

대부분의 에이전트 메모리는 대화 로그를 벡터로 밀어 넣고 비슷한 조각을 다시 꺼내는 방식이다. 이 방식은 개인이 혼자 쓸 때는 그럭저럭 굴러가지만, 사람이 늘어나면 무엇이 확정된 규칙이고 무엇이 지나가는 잡담인지 구분되지 않는다. TencentDB Agent Memory 2.0은 그 뭉텅이를 애초에 네 갈래로 나눠 저장한다.

자산

담는 것

Chat Memory

에이전트와 주고받은 대화에서 남길 만한 맥락

Skill

반복 실행 가능한 절차·작업 방식

LLM-Wiki

문서에서 정제된 팀 공용 지식

Code-Graph

코드베이스의 구조적 관계

분류 자체가 기능이다. 대화에서 나온 임시 결론과 팀이 합의한 규칙이 같은 저장소에 섞여 있으면, 에이전트는 둘을 구분할 근거가 없다. 자산 종류를 나눠 두면 "이건 위키에 올릴 지식인가, 그냥 대화 기록인가"라는 판단이 저장 시점에 한 번 일어난다.

Code-Graph가 따로 있는 점도 눈에 띈다. 코드를 텍스트 조각으로만 다루면 호출 관계나 의존 구조가 사라지는데, 이를 그래프 자산으로 분리했다는 것은 코딩 에이전트를 1순위 사용자로 놓았다는 뜻이다.

검색이 아니라 ACL 거버넌스를 앞세운 선택

이 프로젝트가 스스로 내세우는 지점은 검색 성능이 아니다. 공개 자료는 차별점을 거버넌스, 구체적으로는 ACL 기반 가시성 결정으로 설명한다. ACL은 어떤 사용자나 그룹이 어떤 자원에 접근할 수 있는지를 목록으로 정의하는 오래된 권한 모델이다.

이 선택은 "팀급"이라는 표현과 맞물린다. 개인 도구라면 내 기억을 내가 다 보면 그만이다. 팀 단위로 넘어가는 순간 인사 관련 대화, 보안 설정, 미공개 계약 조건이 같은 메모리 허브에 들어오고, 신입 에이전트 세션이 그걸 전부 읽어도 되는지가 실무 문제가 된다.

검색 품질은 모델과 임베딩이 좋아지면 따라 올라가지만, 권한 모델은 나중에 얹기가 훨씬 어렵다. 저장 구조를 다 만든 뒤에 가시성을 붙이려면 이미 쌓인 기억을 전부 다시 분류해야 하기 때문이다. 다만 공개된 요약만으로는 ACL의 단위가 자산별인지, 그룹별인지, 항목별인지까지는 확인되지 않는다.

MIT 라이선스와 Docker 자체 호스팅이 뜻하는 것

MIT는 오픈소스 라이선스 가운데 제약이 가장 적은 축이다. 수정본을 공개할 의무가 없고, 사내 시스템에 통합해 상용 제품에 실어도 저작권 고지만 유지하면 된다. 사내 도입 검토에서 법무 단계가 짧아진다는 뜻이다.

Docker 자체 호스팅은 데이터 위치를 조직이 정한다는 의미다. 에이전트 메모리에는 코드 구조, 내부 규칙, 미완성 의사결정 같은 것이 그대로 쌓이므로, 이 데이터를 외부 관리형 서비스에 두느냐 사내 서버에 두느냐는 보안 심사에서 성격이 다른 문제다.

반대로 자체 호스팅에는 운영 부담이 따라온다. 컨테이너 업데이트, 백업, 저장소 용량, 접근 권한 관리가 전부 도입한 팀의 몫이 된다. 관리형 서비스를 쓸 때 사라졌던 일이 다시 돌아온다는 점은 감안해야 한다.

Claude Code와 OpenClaw를 포함한 연동 대상

공개 자료가 밝힌 연동 대상은 Claude Code, OpenClaw, Hermes, CodeBuddy다. 서로 다른 코딩 에이전트가 같은 메모리 허브를 바라본다는 구성인데, 이는 메모리를 특정 도구의 부속 기능이 아니라 독립 계층으로 두겠다는 설계다.

실무에서 이 구성이 의미를 갖는 경우는 분명하다. 한 팀 안에서도 사람마다 쓰는 에이전트가 다르고, 도구는 1~2년 주기로 바뀐다. 도구별 메모리에 지식이 갇혀 있으면 도구를 바꿀 때마다 팀의 축적이 초기화된다.

다만 자료는 이름만 나열하고 연동 깊이는 밝히지 않는다. 표준 프로토콜을 쓰는지, 도구별 어댑터를 각각 구현했는지, 읽기만 되는지 쓰기까지 되는지는 저장소를 직접 확인해야 한다.

확인된 것

이번 자료로 확인되지 않는 것

MIT 라이선스, Docker 자체 호스팅

필요 리소스, 운영 요구 사양

자산 4종의 이름과 역할

자산 사이의 자동 승격·연결 방식

연동 도구 4종의 이름

연동 방식과 지원 범위

ACL 기반 가시성 통제

권한 부여 단위와 감사 기능 유무

그래서 무엇이 달라지나

확정적으로 달라지는 것은 선택지다. 팀 단위 에이전트 메모리를 MIT 라이선스로, 데이터를 내부에 두고 검토해 볼 수 있게 됐다. 규제 산업이나 사내망 정책이 빡빡한 조직에서 그동안 막혔던 검토가 다시 열린다.

이하는 추정이다. 코딩 에이전트 도입이 개인 생산성 도구 단계를 지나면, 다음 병목은 모델 성능이 아니라 "팀이 합의한 맥락을 에이전트가 아는가"가 된다. 같은 실수 반복, 폐기된 규칙 재적용, 사람마다 다른 답변은 모델을 바꿔서 풀리는 문제가 아니다. 자산 분류와 권한 모델을 앞세운 이번 공개는 그 지점을 겨냥한 것으로 보인다.

지금 할 일은 도입 결정이 아니라 확인이다. 저장소를 열어 Code-Graph가 자기 팀 언어와 저장소 규모를 감당하는지, ACL 단위가 조직 구조와 맞는지, 쓰는 에이전트가 연동 목록에 있는지를 먼저 본다. 여기서 하나라도 어긋나면 나머지 장점은 의미가 없다.

정리

라이선스와 배포 방식은 문턱이 낮은 편이라 소규모 팀도 시험 삼아 띄워 보기 어렵지 않다. 반대로 성능 수치와 운영 요구 사양이 공개되지 않은 상태라 실제 규모에서 버티는지는 직접 재 봐야 한다. 판단 기준은 하나다 — 팀의 기억을 네 갈래로 나누고 권한까지 매길 만큼 지금 에이전트를 여럿이 쓰고 있는가.