코딩 에이전트를 하루 종일 켜 두면 이상한 세금이 쌓인다. 어제 설명한 인증 모듈 제약을 오늘 세션에서 다시 말하고, 지난주에 읽힌 설계 문서를 다른 에이전트가 처음부터 다시 읽고, 이미 한 번 뚫린 배포 체크리스트를 다음 사람이 처음부터 다시 짠다. 모델은 빌릴 수 있고 도구는 복붙할 수 있는데, 세션이 끝난 뒤 남는 경험만은 매번 증발한다.
TencentDB Agent Memory는 그 증발에 팀 단위 허브로 답한 오픈소스다. 2026년 4월 공개 뒤 빠르게 성장했고, 8월 초 v2.0.0과 함께 “Team Memory” 포지션을 전면에 올렸다. 작성 시점 기준 스타 약 1.7만, 포크 1,500+. 라이선스는 MIT. 슬로건이 제품 정의를 잘 요약한다.
Agents remember. Humans innovate.
이번 글의 테제는 단순하다. 에이전트 메모리는 채팅 로그 창고가 아니라, 거버넌스 가능한 메모리 자산이다. 텐센트의 답은 “더 긴 컨텍스트”가 아니라 “누가, 어떤 버전을, 어느 에이전트에 장착하는가”다. #37 컴퍼니 브레인이 회사 지식을 유지 문제로 옮겼다면, 이 프로젝트는 그 지식을 에이전트 팀의 장비 체계로 옮긴다.
한 줄로 말하면 뭔가
README의 자기 정의는 이렇다. 대화·문서·코드를 네 가지 재사용 자산으로 바꾸고, 팀 안에서 공유·심사·장착한다.
| 자산 | 무엇이 되는가 | 어디에 쓰이는가 |
|---|---|---|
| Chat Memory | 선호·사실·결정·상호작용 이력 | 다음 세션이 자기소개부터 시작하지 않게 |
| Skill | 버전·트리거·실행 단계·검증 규칙이 있는 SOP | 한 번 뚫린 워크플로를 다른 에이전트가 재실행 |
| Wiki | 문서 → 구조화 페이지 + 링크 그래프 | 파일 목록부터 다시 읽지 않게 |
| CodeGraph | 심볼·파일·호출·영향 경로 | 고치기 전에 “건드리면 어디가 깨지나” |
비교표도 솔직하다. 채팅 이력과 표준 RAG는 “찾을 수 있나”에 가깝고, 이쪽은 소유권·버전·상태·팀 공유·에이전트 로드아웃·ACL까지 한 축에 올려둔다. 메모리를 “프롬프트에 더 많이 넣는 기술”이 아니라 “인프라 자산“으로 취급한다는 뜻이다.
영감의 출처도 숨기지 않는다. Wiki는 Karpathy의 LLM Wiki 쪽 사고를 빌렸고, CodeGraph 모듈은 colbymchenry/codegraph 코드를 사용하며, Skill 쪽은 Hermes Agent의 일부를 가져가 확장했다고 명시한다. #15와 #17에서 따로 본 조각들이, 여기서 팀 허브라는 한 지붕 아래로 모인다.
아키텍처: 네 모듈, 한 파이프라인
레포 구조는 제품 경계를 그대로 드러낸다. 타입스크립트 비중이 크고(Node ≥ 22.16), 런타임은 기본적으로 로컬 SQLite + 파일 쪽으로 기울어 있다.
Coding agent (Claude Code / CodeBuddy / OpenClaw / Hermes / custom)
│ OpenAI / Anthropic 프로토콜 그대로
▼
MemoryProxy :8096
│ 세션 초기화 · 컨텍스트 주입 · 대화 회수 · 인증
├──────────► Upstream LLM
│
└─ HTTP ──► MemoryCore Gateway :8420
├ Memory L0/L1/L2/L3
├ Skill / Meta (Team·Agent·Task·ACL)
└ Knowledge metadata
│
└─► MemoryKnowledge :8424 (Wiki / CodeGraph 본문)
│
Panel UI :8125 ◄── 사람이 팀·자산·장착을 다루는 제어판역할 분담이 깔끔하다.
- MemoryCore — 기억·메타데이터·자산 관리의 데이터 플레인. 에이전트를 호스팅하거나 스케줄하지 않는다. “호출자 + 관리 대상 엔티티”일 뿐.
- MemoryKnowledge — Wiki 파싱·CodeGraph 인덱싱·본문 검색. Core는 지식 메타만 들고, 내용 처리는 여기.
- MemoryPanel (Hub) — 팀·에이전트 생성, 자산 심사·공유·장착, 가시성 전환.
- MemoryProxy — 코딩 에이전트가 업스트림 LLM으로 가던 경로를 가로채, 기억 주입과 회수를 프로토콜 변경 없이 수행.
설치 권장 경로도 이 삼총사다. deploy/global-images에서 .env에 메모리용 LLM 그룹과 프록시 업스트림 그룹을 채운 뒤 ./start-all.sh. 끝나면 admin sk-mem-... 키와 Claude Code에 붙여 넣을 한 줄이 찍힌다. 패널은 http://localhost:8125.
이 분리는 #35 하네스 엔지니어링 관점에서도 읽힌다. 모델은 그대로 두고, 컨텍스트 배달·검증·기억·샌드박스 쪽을 별 레이어로 키운다. 메모리가 에이전트 프로세스 안에 녹아 있으면 프레임워크를 바꿀 때마다 다시 심어야 한다. 바깥 허브로 빼면 “재장착”이 된다.
기억에도 층이 있다 — L0에서 L3로 증류
Chat Memory의 층 구조가 이 프로젝트의 기술 핵심이다. 대화를 통째로 벡터 DB에 넣는 방식이 아니라, 비동기 파이프라인으로 입도를 나눈다.
| 층 | 저장 내용 | 주 용도 |
|---|---|---|
| L0 Conversation | 원문 대화 | 정확한 문구·시간·출처 확인 |
| L1 Atom | 사실·선호·제약·사건 | 행동 가능한 정보의 정밀 회수 |
| L2 Scenario | 프로젝트·시나리오 단위 블록 | 작업 컨텍스트 빠른 복원 |
| L3 Core / Persona | 장기 프로필·안정 패턴 | 사용자·팀 맥락으로 즉시 진입 |
생성도 회수도 계층적이다. 평소에는 L2/L3로 컨텍스트를 부트스트랩하고, 구체 사실이 필요할 때 BM25 + 벡터 + RRF로 L1/L0까지 내려간다. 결과 개수·문자 예산·타임아웃으로 상한을 걸어 기억이 컨텍스트 창을 삼키지 않게 한다. MemoryCore 기본값도 원격 임베딩을 끄고 BM25를 남기는 쪽이라, “임베딩 없으면 못 돈다” 구조는 아니다.
이 설계는 #30 컨텍스트 엔지니어링의 “무엇을 뺄까”와 같은 축이다. 더 넣는 게 목표가 아니라, 다음 턴에 필요한 입도만 남기는 것이 목표다. “모바일 클라이언트가 아직 구 인증 모듈을 쓴다” 같은 한 줄이 L1에 살아 있으면, 다음 에이전트가 그 모듈을 리팩터링하기 전에 제약을 다시 배울 필요가 없다.
공식 벤치마크는 PersonaMem 하나다. 장기 상호작용 뒤 사용자 정보를 바르게 이해하고 적용하는 테스트에서 48% → 76% (+59% 상대 개선). 숫자는 방향 신호로 보면 된다. 평가 스위트가 넓지 않고, 토큰 절감 비율 같은 운영 지표는 README 본문에 없다. 제품 성숙도보다 문제 정의의 성숙도가 앞선 단계로 읽는 게 맞다.
로드아웃: 메모리는 전역 프롬프트가 아니다
두 번째 핵심 문장은 README에 거의 그대로 있다.
Memory isn’t a global prompt — it’s the Agent’s loadout.
로드아웃(loadout)은 게임에서 출전 전에 고르는 무기·장비 구성을 부르는 말이다. 모든 판에 같은 짐을 메고 나가는 게 아니라, 이번 임무에 필요한 것만 골라 챙긴다. 메모리를 로드아웃이라 부르는 순간, 문제는 “시스템이 무엇을 아는가”에서 “이 에이전트에게 무엇을 들려 보낼 것인가”로 바뀐다.
네 자산은 전부 Memory Asset으로 등록되고, Hub는 고정 바인딩 + ACL로 “이 에이전트가 지금 무엇을 쓸 수 있는지”를 정한다. 먼저 Team / User / Agent / 가시성으로 권한 범위를 좁히고, 그다음 질의에 맞는 회수를 한다.
가시성 모델도 기본값이 안전 쪽이다.
| 가시성 | 의미 |
|---|---|
private |
Owner만 — 팀 관리자도 못 봄 |
team |
팀원 열람, Owner/Admin 관리 |
restricted |
User / Role / Agent ACL |
agent |
같은 팀 안 특정 에이전트 장착용 |
새 Chat Memory와 Skill은 기본 private. 공유는 명시적 행위다. “팀 메모리를 켠다 = 전부가 새어 나간다”는 공포를 제품 기본값으로 차단하려는 선택이다.
플레이 스타일도 이 모델 위에 그려져 있다. 1인 회사라도 Scout / Builder / Reviewer를 나누고, 각각 다른 장비를 준다. Scout에게 시장 조사 Wiki와 경쟁 분석 Skill, Builder에게 제품 Wiki와 CodeGraph, Reviewer에게 장애 이력 Memory와 릴리즈 체크리스트 Skill. 역할이 다르면 컨텍스트 노이즈의 정의도 다르다. 전 직원에게 같은 RAG 인덱스를 열어 주는 것과, 역할별 로드아웃을 짜는 것은 같은 “기억” 문제가 아니다.
이건 multi-agent 논의에서 자주 빠지는 축이다. #49가 서로 다른 실패 모드를 교차 검증에 쓰자고 했다면, 이쪽은 서로 다른 기억 장비를 역할에 붙이자는 쪽이다. 에이전트를 여러 개 띄우는 것만으로는 팀이 안 되고, 공유할 것과 사적으로 둘 것의 경계가 자산 단위로 잡혀야 팀이 된다.
MemoryProxy가 진짜 DX다
기술적으로 가장 현실적인 모듈은 Proxy다. 코딩 에이전트(Claude Code, CodeBuddy 등)가 LLM을 직접 치지 않고 Proxy(:8096)를 경유하게 하면, 에이전트 코드를 한 줄도 안 고치고 팀 기억·Skill·Knowledge를 태울 수 있다. Anthropic /v1/messages와 OpenAI /v1/chat/completions를 그대로 포워드한다.
요청 파이프라인은 대략 이렇다.
x-tdai-user-key로 인증 →user_id해석- 첫 턴에 team / agent / task 선택 (세션 바인딩)
- 해당 에이전트 로드아웃의 Skill·Knowledge·Memory L2/L3를 시스템 프롬프트에 주입
- 업스트림 LLM 호출
- 턴 종료 후 대화 슬라이스를 Core로 비동기 회수 (L0 기록, Skill 추출 트리거)
- 사용량·관측 리포트
디테일 하나가 특히 좋다. L0/L1은 시스템 프롬프트에 때려 넣지 않고, 모델이 필요할 때 부르는 읽기 전용 툴로 노출한다. Proxy README 표현 그대로, 업스트림 KV 캐시 무효화를 피하려는 선택이다. #48에서 본 규칙 — 변하는 것을 앞에 두면 히트율이 죽는다 — 을 메모리 레이어가 의식하고 있다는 신호다. “기억 많이 넣기”와 “캐시 가능한 프롬프트 구조”가 충돌한다는 사실을, 제품이 설계 단계에서 이미 알고 있다.
SDK도 있다. TypeScript @tencentdb-agent-memory/memory-sdk-ts-v2, Python tencentdb-agent-memory-sdk-python. v3 isolation에서는 teamId / agentId / userId가 필수다. 프레임워크 어댑터로는 OpenClaw 플러그인, Hermes Memory Provider가 레포 안에 들어 있다. “에이전트 프레임워크와 메모리를 디커플”한다는 문장이 빈 구호가 아니라, Proxy + SDK + 플러그인이라는 세 진입점으로 구현돼 있다.
콜드 스타트: 학습 비용을 세이브 파일로
제품이 반복해서 쓰는 비유가 “읽기(load the save file)“다. 대부분의 에이전트 첫 작업은 프로젝트 재학습이다. Hub는 이미 치른 학습 비용을 세 갈래로 수입한다.
- 코드베이스 → CodeGraph (심볼·호출·영향 경로)
- 문서 → Wiki (페이지 + 링크 그래프)
- 과거 세션 → Chat Memory + Skill 추출
#17에서 codegraph가 “discovery phase 토큰 세금”을 줄인다고 했을 때, 사람들은 바로 “문서·스펙도 같은 지도에 넣어 달라”고 요구했다. 이 레포는 그 다음 문장을 제품으로 만든 셈이다. 코드 그래프만 있는 도구와, 코드 + 문서 + 대화 경험 + 권한을 한 자산 모델로 묶는 허브는 카테고리가 다르다.
다만 현재 한계도 README가 직접 적는다. Wiki/CodeGraph는 비동기 구축이라 ready까지 시간이 필요하고, CodeGraph는 공개 HTTPS 저장소 우선이며 private/SSH는 아직 다듬는 중이며, Hub의 자산 바인딩은 수동이 중심이고 완전 자동 라우팅은 아직 이터레이션 중이다. “세이브 파일” 비유는 강하지만, 세이브 슬롯을 자동으로 골라 주는 로더는 아직 사람 손이다.
지형도에서 어디쯤인가
비슷한 이름을 단 것들과 뭐가 다른지 짚어 보면 이렇다.
| 계열 | 대표 | 푸는 문제 | TencentDB Agent Memory와의 거리 |
|---|---|---|---|
| 개인/앱 장기 기억 | Mem0, Zep/Graphiti 등 | 사용자·세션 사실을 오래 들고 회수 | 겹치는 층은 L1~L3. 여기는 팀 자산·ACL·에이전트 장착이 중심 |
| 회사 지식 검색 | Glean, Cerebras Knowledge(#37) | 흩어진 사내 지식을 사람과 에이전트가 검색 | 여기는 검색 엔진보다 에이전트 로드아웃 + 코딩 에이전트 Proxy |
| 코드 지도 | codegraph(#17) | 심볼 그래프·impact | CodeGraph 자산으로 흡수, 단독 도구가 아니라 Hub 자산 |
| 에이전트 런타임 | OpenClaw, Hermes(#15) | 루프·도구·게이트웨이 | 메모리를 런타임 밖으로 빼 어댑터로 붙임 |
한 문장으로 압축하면, 에이전트 팀용 메모리 제어판 + 투명 프록시다. “더 좋은 벡터 DB”가 아니고, “더 긴 컨텍스트 창”도 아니다. #43 그래프 엔지니어링이 지식/메모리 그래프를 오케스트레이션 그래프와 구분했듯, 여기서도 그래프(CodeGraph·Wiki 링크)는 수단이고 제품의 중심 추상은 Asset + Loadout + ACL이다.
아직 거친 가장자리
분석글이 README 번역이 되지 않으려면 한계를 또렷이 써야 한다.
1) 벤치가 얇다. PersonaMem 한 줄은 방향만 보여 준다. 다중 에이전트 협업, Skill 재사용률, CodeGraph impact 정확도, 프록시 주입 후 캐시 히트율 같은 운영 지표는 공개 스위트에 없다. “스타 수 = 프로덕션 준비”가 아니다.
2) 이슈 트래픽이 많다. 작성 시점 open issues가 500대를 넘긴다. v2.0이 Team Memory로 급선회한 직후라 문서·마이그레이션·연동 질문 비중이 높다. feat/server_team이 기본 브랜치로 보이는 점도, 아직 “제품 동결” 단계가 아님을 암시한다.
3) 자동화와 보안 경계가 미완. 자산 라우팅 자동화, private repo CodeGraph, 완전 자동 Skill 품질 게이트는 로드맵 문장에 가깝다. ACL 모델은 방향이 맞지만, 실제 조직에서 Role/Agent ACL을 운영하려면 Hub UX와 감사 로그가 더 두꺼워져야 한다.
4) 운영 비용은 “로컬 무료”가 아니다. 기억 추출·Wiki/Skill 생성에 LLM이 들어가고, Proxy 업스트림과 메모리 그룹용 모델을 따로 둘 수 있다. 로컬 SQLite 스토리지는 싸지만, 증류 파이프라인은 토큰을 태운다. “기억 레이어를 얹으면 무조건 토큰이 준다”는 보장은 없다. 잘 설계하면 discovery 재학습을 줄이고, 못 설계하면 추출 비용만 는다.
5) 프레임워크 커버리지는 선택적. OpenClaw·Hermes·Claude Code·CodeBuddy·SDK가 공식 언급이다. 생태계 전체 표준이 아니라, 연동 표면을 넓히는 중인 허브로 보는 게 맞다.
실전에서 가져갈 다섯 문장
레포를 당장 안 돌려도, 설계에서 이식할 원칙은 분명하다.
1) 메모리를 로그가 아니라 자산 스키마로 정의하라. 원문(L0), 원자 사실(L1), 시나리오(L2), 페르소나(L3)처럼 입도를 나누지 않으면 회수는 “비슷한 대화 덩어리”로 끝난다.
2) 기본 공유를 끄고, 장착을 켜라. 팀 메모리는 유출 사고가 한 번이면 끝이다. private 기본 + 명시적 share + agent loadout이 한 세트다.
3) 주입 경로를 에이전트 코드 밖에 둬라. Proxy처럼 프로토콜 계층에서 끼워 넣으면 프레임워크 교체 비용이 떨어진다. 메모리 로직을 에이전트 본체에 심지 마라.
4) 자주 쓰는 층과 가끔 파는 층을 분리하라. L2/L3는 부트스트랩, L0/L1은 툴 호출. 캐시 친화적 프롬프트와 정밀 회수를 동시에 챙기는 패턴이다.
5) 코드·문서·대화를 같은 자산 레지스트리로 올려라. 검색 엔진 세 개를 나란히 두는 것과, Owner·버전·가시성·에이전트 바인딩이 같은 메타모델인 것은 운영 난이도가 다르다.
남는 것
에이전트 메모리는 아직 표준이 없다. 어떤 스택은 사용자 선호를 벡터에 묻고, 어떤 스택은 그래프에 시간을 찍고, 어떤 스택은 MEMORY.md 한 장에 전부 적는다. TencentDB Agent Memory가 흥미로운 이유는 그 스펙트럼에서 팀 운영 체제 쪽 끝으로 명확히 이동했기 때문이다.
- 저장 단위: 대화 턴이 아니라 자산
- 소비 단위: 전역 RAG가 아니라 에이전트 로드아웃
- 통합 단위: 프레임워크 플러그인만이 아니라 투명 LLM 프록시
- 통제 단위: 임베딩 점수만이 아니라 Owner / version / ACL
#25에서 루프가 경험을 남기지 않으면 같은 실패를 더 빠르게 반복할 뿐이라고 썼다. 이 레포의 문장은 그 다음이다. 루프가 남긴 것을 다음 에이전트의 출발선으로 만들어라. 구현은 아직 베타의 거친 면이 있고, 벤치도 더 쌓여야 한다. 그래도 문제 정의만큼은 2026년 중반 에이전트 인프라가 실제로 막혀 있는 지점 — 세션 세금, 역할 간 경험 단절, 프레임워크에 갇힌 기억 — 을 정확히 가리킨다.
에이전트는 이미 충분히 빠르게 돈다. 이제 병목은 속도가 아니라, 팀이 한 번 배운 것을 다음 에이전트가 다시 배우지 않게 하는 구조다. 그 구조를 오픈소스로 한 번에 보여 준 것이, 이 레포를 읽어 볼 이유다.