[심층분석] AI 에이전트에게 '팀 공유 기억'을 달아주다 — 텐센트의 Agent Memory가 던지는 질문

왜 우리는 매번 같은 설명을 반복할까요?

AI 코딩 에이전트 써보신 분들이라면 다들 한 번쯤 느껴보셨을 거예요. 새 세션을 열 때마다 "우리 프로젝트는 이런 구조고, 이 컨벤션을 쓰고, 저 폴더는 건드리면 안 되고..." 하는 설명을 처음부터 다시 해야 하는 그 답답함이요. 어제 에이전트한테 열심히 가르쳐놓은 내용이 오늘이면 깨끗하게 사라져 있거든요. 마치 매일 아침 기억이 리셋되는 신입 사원과 일하는 느낌이랄까요.

더 큰 문제는 팀 단위로 넘어가면 이 낭비가 곱하기가 된다는 거예요. 팀원 A가 자기 에이전트에게 프로젝트 컨텍스트를 다 설명해놨는데, 팀원 B는 또 처음부터 설명해야 하죠. A가 시행착오 끝에 찾아낸 "이렇게 시키면 잘 되더라" 하는 노하우도 B에게는 전혀 전달되지 않아요.

텐센트클라우드가 공개한 TencentDB Agent Memory는 바로 이 지점을 겨냥한 프로젝트인데요. 개인의 에이전트 메모리를 넘어서 "팀 레벨의 메모리 허브"를 만들겠다는 게 핵심이에요. 프로젝트 슬로건이 재밌어요. "Agents remember. Humans innovate." — 기억은 에이전트가 하고, 사람은 혁신에 집중하라는 거죠.

2025년부터 에이전트 메모리는 업계의 뜨거운 주제였어요. Mem0, Letta(구 MemGPT), Zep 같은 메모리 전문 프로젝트들이 쏟아졌고, Claude Code 같은 도구들도 자체 메모리 기능을 넣기 시작했거든요. 그런데 이들 대부분이 "한 명의 사용자 + 한 개의 에이전트" 조합에 초점을 맞췄다면, 텐센트는 처음부터 "팀"과 "거버넌스"를 전면에 내세웠다는 점이 다릅니다.

기술 분석: 기억을 네 가지 '자산'으로 쪼개다

이 프로젝트의 설계 철학에서 가장 눈에 띄는 건, 기억을 뭉뚱그리지 않고 네 가지 재사용 가능한 자산(asset)으로 분류했다는 거예요. 하나씩 풀어볼게요.

• Chat Memory(대화 기억): 에이전트와 나눈 대화에서 중요한 사실과 맥락을 뽑아 저장하는 거예요. "이 프로젝트는 결제 모듈 리팩토링 중이고, DB는 MySQL 8을 쓴다" 같은 것들이요. 사람으로 치면 회의록에서 핵심만 추려 적어두는 것과 비슷해요.
• Skill(스킬): 이게 꽤 흥미로운데요. 한 번 성공한 작업 절차를 재사용 가능한 '레시피'로 만들어두는 개념이에요. 예를 들어 "우리 팀 배포는 이 순서로, 이 체크리스트를 확인하며 진행한다"는 워크플로우를 에이전트가 매번 재발견할 필요 없이 스킬로 꺼내 쓰는 거죠. README에서도 "이미 잘 작동하는 워크플로우를 다시 발견할 필요가 없어야 한다"고 명시하고 있어요.
• LLM-Wiki: 사내 문서나 기술 문서를 LLM이 읽기 좋은 형태의 위키로 변환해서 쌓아두는 거예요. 사람용 문서는 배경 설명이 길고 형식이 제각각이라 LLM이 소화하기 비효율적이거든요. 이걸 에이전트 친화적인 구조로 미리 정리해두면, 문서를 매번 처음부터 읽힐 필요가 없어져요.
• Code-Graph(코드 그래프): 코드베이스의 구조 — 어떤 함수가 어떤 함수를 부르고, 어떤 모듈이 어디에 의존하는지 — 를 그래프, 그러니까 '관계 지도'로 만들어두는 거예요. 에이전트가 코드를 수정할 때 "이 함수를 건드리면 어디에 영향이 가지?"를 지도 보듯 빠르게 파악할 수 있게 되죠.

아키텍처: 프록시가 핵심 한 수

저장소 구조를 보면 시스템이 크게 네 덩어리로 나뉘어요. 기억의 저장과 추출을 담당하는 MemoryCore, 지식 자산을 다루는 MemoryKnowledge, 웹 대시보드인 MemoryPanel, 그리고 MemoryProxy입니다.

이 중에서 설계적으로 가장 영리한 부분이 MemoryProxy인데요. 프록시라는 건 쉽게 말해 에이전트와 LLM 사이에 끼어드는 중간 다리예요. 에이전트가 LLM에게 요청을 보낼 때 프록시가 그 요청을 가로채서, 관련된 팀 메모리를 슬쩍 끼워 넣어주고, 응답에서 기억할 만한 내용을 뽑아 저장하는 거죠.

이 방식의 장점이 뭐냐면, 에이전트 프레임워크를 전혀 수정할 필요가 없다는 거예요. Claude Code든 텐센트의 CodeBuddy든, LLM 호출 경로만 프록시로 돌리면 그 즉시 팀 메모리가 붙어요. 설치도 이 철학을 따라가는데, deploy/global-images에서 .env에 LLM 파라미터 두 세트(메모리용 + 프록시용)를 채우고 ./start-all.sh 한 방이면 세 서비스가 다 뜨고, 끝나면 Claude에 바로 붙여넣을 수 있는 설정 한 줄을 출력해줘요. 대시보드는 localhost:8125에서 열리고요. 전부 셀프호스팅, 그러니까 자기 서버에 직접 설치하는 방식이라는 점도 기업 입장에선 중요한 포인트예요.

업계 맥락: '개인 메모리'에서 '팀 메모리'로

기존 솔루션들과 비교해보면 포지셔닝 차이가 선명해요.

Mem0나 Zep은 주로 "사용자별 장기 기억"에 집중해요. 챗봇이 개별 사용자의 취향과 이력을 기억하게 만드는 데 강점이 있죠. Letta(MemGPT)는 에이전트가 자기 기억을 스스로 관리하는 아키텍처를 제시했고요. Claude Code의 CLAUDE.md나 자동 메모리도 결국 "한 사용자의 작업 맥락"을 유지하는 도구예요.

비유하자면 기존 도구들이 개인 수첩이라면, 텐센트의 접근은 팀 공유 노션 워크스페이스에 가까워요. 개인 수첩은 나한테는 유용하지만 팀원은 못 보잖아요. 팀 메모리 허브는 한 명이 쌓은 지식을 팀 전체의 에이전트가 공유하게 만들고요.

여기서 자연스럽게 따라오는 게 거버넌스(governance) 문제예요. 거버넌스라는 건 쉽게 말해 "누가 어떤 기억을 보고, 고치고, 지울 수 있는지 관리하는 규칙"이에요. 개인 메모리에선 별문제가 아니지만, 팀 단위가 되면 잘못된 기억 하나가 팀 전체 에이전트를 오염시킬 수 있거든요. 누군가의 에이전트가 "이 API는 폐기 예정"이라는 틀린 정보를 저장하면, 팀원 모두의 에이전트가 그 API를 피해 가는 사태가 벌어질 수 있어요. 이 프로젝트가 README에서 '자산의 관리(governed)'를 강조하고 별도의 관리 패널까지 만든 이유가 여기에 있어요.

RAG(검색 증강 생성 — 필요한 문서를 검색해서 LLM에게 참고자료로 주는 기법)와 뭐가 다르냐는 질문도 나올 수 있는데요. RAG가 "도서관에서 그때그때 책을 찾아 읽는 것"이라면, 이 방식은 "읽은 책의 핵심을 이미 소화해서 팀 노트에 정리해둔 것"에 가까워요. 검색 대상이 원문이 아니라 가공된 지식 자산이라는 게 차이죠.

한국 개발자에게 주는 시사점

구체적인 활용 시나리오를 그려볼게요.

시나리오 1: 온보딩 가속. 신규 입사자가 오면 보통 사수가 며칠씩 붙어서 프로젝트를 설명하잖아요. 팀 메모리 허브가 있다면 신입의 에이전트가 첫날부터 팀의 Chat Memory, LLM-Wiki, Code-Graph를 물려받아요. 사수가 반복 설명하던 것의 상당 부분을 에이전트가 대신하게 되는 거죠.

시나리오 2: 노하우의 자산화. "레거시 모듈 마이그레이션은 이 순서로 해야 안전하다" 같은 암묵지를 Skill로 등록해두면, 담당자가 휴가를 가도 다른 팀원의 에이전트가 같은 절차를 따를 수 있어요.

다만 도입 전에 따져볼 것들이 있어요. 첫째, 비용이에요. 메모리 추출과 프록시 처리에 별도의 LLM 호출이 들어가니까 API 비용이 추가로 발생해요. 둘째, 보안이요. 셀프호스팅이라 데이터가 외부로 안 나가는 건 장점이지만, 팀의 코드 구조와 대화가 한곳에 모이는 만큼 그 서버 자체의 접근 통제가 중요해져요. 셋째, 아직 베타라는 점이에요. 커밋 수가 적은 초기 프로젝트라 프로덕션 도입은 신중해야 하고, 사이드 프로젝트나 소규모 팀에서 실험해보는 게 현실적이에요.

학습 로드맵을 제안하자면 이래요. ① 먼저 지금 쓰는 도구의 개인 메모리(CLAUDE.md 등)를 제대로 활용해보면서 "어떤 기억이 실제로 유용한지" 감을 잡으세요. ② 그다음 로컬에 이 프로젝트를 띄워 프록시 방식이 어떻게 동작하는지 뜯어보세요. Docker 배포 문서가 잘 되어 있어서 진입장벽이 낮아요. ③ 마지막으로 네 가지 자산 중 우리 팀에 가장 아쉬운 게 뭔지 — 문서 정리가 안 돼 있으면 LLM-Wiki, 코드베이스가 복잡하면 Code-Graph — 파악해서 거기부터 채워보는 거죠.

마무리: '에이전트 시대의 사내 위키'가 될까요?

돌이켜보면 팀 협업 도구의 역사는 "개인의 지식을 팀의 자산으로 바꾸는" 방향으로 진화해왔어요. 위키가 그랬고, 노션이 그랬죠. 에이전트 시대에도 같은 흐름이 반복될 가능성이 높아 보여요. 지금은 다들 각자의 에이전트에게 각자 컨텍스트를 먹이고 있지만, 머지않아 "팀 메모리 인프라"가 CI/CD처럼 당연한 팀 인프라가 될지도 몰라요. 텐센트가 이 판에 먼저 깃발을 꽂은 셈이고, 다른 클라우드 벤더들의 대응도 뒤따를 거예요.

여러분 팀은 어떠세요? 에이전트에게 매번 반복해서 설명하고 있는 내용이 있다면, 그게 바로 팀 메모리로 만들 첫 번째 후보일 거예요. 여러분이라면 네 가지 자산 중 뭐부터 쌓고 싶으신가요? 그리고 팀원이 쌓은 에이전트 기억, 어디까지 믿고 공유할 수 있을까요? 댓글로 의견 나눠주세요.