공유 에이전트 메모리에는 접근 제어 문제가 있고, 아직 아무도 해결하지 못했다

1년 전이라면 반박했을 주장부터 하나 하겠다. 에이전트 메모리에서 어려운 부분은 애초에 에이전트가 기억하게 만드는 일이 아니었다. 50개의 에이전트가 똑같은 잘못된 것을 기억할 때 무슨 일이 일어나야 하는지를 정하는 일이다. 단일 에이전트 메모리는 편의성 문제다. 메모리가 팀 전체에 공유되는 순간 조직의 접근 제어 문제가 되고, 수정, 삭제, 충돌의 의미론까지 따라붙는다. 그리고 현재 나온 제품들이 가장 빈약한 부분이 정확히 그 기능들이다.

두 벤더가 몇 주 간격으로 이 문제에 대한 답을 내놓았다. Tencent Cloud의 Team Memory는 내가 출시 당시 별도 글로 다룬 제품으로, 8월 13일 거버넌스가 적용된 메모리 허브를 오픈소스로 공개했다. Asana는 지난해 말부터 자사의 폐쇄형 플랫폼에 묶인 버전인 Agentic Work Management를 AI Teammates와 함께 조용히 운영해 왔다. 이 글은 또 하나의 발표 요약이 아니다. 발표에서 빠뜨린 비교를 한다. 메모리를 수정하거나 삭제하거나 서로 다른 주장 사이에서 판정해야 할 때 각 시스템이 실제로 무엇을 하는지, 그리고 조직 안에서 누가 결정권을 갖는지를 본다.

핵심 요점 - 공유 메모리에서는 잘못된 사실 하나가 한 사용자의 불편에서 모든 에이전트가 물려받는 오류로 바뀐다. 이제 핵심 기능은 검색 품질이 아니라 거버넌스 계층이다. - Tencent의 Team Memory는 가장 명시적인 접근 모델을 제공한다. 네 가지 가시성 등급, 에이전트별 로드아웃, 기본 비공개 설정이 있다. 하지만 이미 다른 에이전트가 소비한 사실을 어떻게 수정하거나 만료시키는지는 문서화돼 있지 않다. - Asana의 Agentic Work Management는 기존 Work Graph 권한을 상속해 기밀 정보 유출 문제를 제대로 해결한다. 다만 메모리는 Asana 플랫폼 안에 머물고, 수정 의미론은 불투명하다. - Zep의 Graphiti는 오래된 사실에 대해 원칙적인 답을 가진 유일한 주류 구현이다. 삭제하지 않고 무효화해 이력을 남긴다. 하지만 팀의 메모리가 아니라 한 에이전트의 메모리를 다룬다. - 같은 대상에 대해 두 에이전트가 서로 모순되는 사실을 썼을 때 충돌을 해결하는 기능은 아직 아무도 제공하지 않는다. 현재 그 질문의 답은 “검색 순위”인데, 그것은 답이 아니다.

무슨 일이 있었나

8월 첫 2주 동안 공유 에이전트 메모리는 연구 주제에서 실제 제품 범주로 넘어갔다. 기준점으로 삼을 사건은 두 가지다.

• 8월 13일 Tencent Cloud는 오픈소스 TencentDB Agent Memory 프로젝트의 팀 규모 확장판인 Team Memory를 발표했다. 대화, 문서, 코드 그래프, 증류된 스킬이 소유자, 버전, 네 단계 가시성 모델을 가진 팀 자산이 되고 에이전트 역할별로 조합된다.

• 그보다 한 주 앞서 VentureBeat가 Asana CPO Arnab Bose와 진행한 대담에서 Asana의 AI Teammates 뒤에 있는 공유 메모리 시스템인 Agentic Work Management(AWM)의 실제 기술적 세부사항이 처음 공개됐다. Asana는 FedEx를 포함한 고객들이 이미 프로덕션에서 이를 사용한다고 말한다.

그 주변에는 오픈소스 단일 에이전트 메모리 계층인 Mem0, Zep의 Graphiti, Letta가 있다. 여전히 대부분의 팀이 실제로 쓰는 메모리 인프라는 여기에 가깝다. 흥미로운 변화는 이제 이 모든 시스템이 같은 네 가지 질문으로 평가된다는 점이다. 누가 메모리를 읽을 수 있는가? 틀렸을 때 무엇이 일어나는가? 삭제하면 무엇이 일어나는가? 두 메모리가 서로 충돌하면 무엇이 일어나는가?

Tencent Cloud는 2026년 8월 13일 에이전트 팀을 위한 거버넌스형 공유 메모리 허브 Team Memory를 출시했다. 발표에 따른 내용이다. 며칠 앞선 2026년 8월 3일 VentureBeat 인터뷰에서는 Asana CPO가 AI Teammates를 뒷받침하는 공유 메모리 시스템 Agentic Work Management의 세부사항을 설명했다.

네 가지 질문으로 비교하기

이 범주를 게으르게 보면 “Tencent 대 Asana”, 중국 오픈소스 대 미국 SaaS라고 정리하기 쉽다. 실제 구조는 그렇지 않다. 진짜 갈림길은 메모리를 권한이 붙은 문서로 관리하는 시스템과 생명주기가 있는 사실로 관리하는 시스템 사이에 있다. 아직 어느 쪽도 두 절반을 모두 갖추지 못했다.

수정과 충돌 행을 따라 읽으면 불편한 패턴이 보인다. 가장 중요한 두 칸이 바로 아무도 채우지 못한 두 칸이다.

Team Memory 자체 문서는 “누가 사용할 수 있는지, 어떤 버전이 유효한지, 어떤 Agent가 받아야 하는지”를 구분한다. VentureBeat가 보도한 Tencent 문서에 따른 내용이다. Zep의 Graphiti는 프로젝트 저장소에 설명된 대로 오래된 사실을 삭제하지 않고 무효화한다. Tencent와 Asana 어느 쪽도 다른 에이전트가 이미 소비한 공유 메모리의 수정 또는 충돌 해결 절차를 공개 문서로 설명하지 않는다.

각 시스템이 잘하는 것

Tencent의 기여는 접근 모델이다. 다른 곳이 모호하게 넘기는 부분을 명시적으로 만든 점은 인정할 만하다. 모든 메모리 자산에는 소유자, 버전, 가시성 등급(비공개, 팀, 제한, 에이전트)이 붙고, 새 자산은 기본적으로 비공개이며, 에이전트는 허브 전체에 접근하는 대신 역할에 맞는 “Agent Loadout”을 받는다. 조사를 담당하는 Scout 에이전트는 시장 분석 자산을 받고 Builder 에이전트는 코드 그래프를 받는 식이다. 이는 메모리를 잠금 정책이 있는 조직 인프라로 다루는 방식이다. VentureBeat 보도가 지적하듯 문서 자체도 단순 RAG와 선을 긋는다. 검색은 무엇을 찾을 수 있는지를 답하지만 Team Memory는 누가 그것을 사용할 수 있는지도 답한다.

Asana의 기여는 유출 경계다. 그 예시는 모든 거버넌스 자료에 들어가도 좋다. 임원의 AI Teammate가 기밀 M&A 프로젝트에서 메모리를 쌓았다고 하자. 나중에 같은 Teammate와 대화하는 동료가 그 컨텍스트를 물려받아서는 안 된다. VentureBeat 인터뷰에서 Bose가 내놓은 답은 AWM이 18년간 쌓인 Asana의 Work Graph 위에 있다는 것이다. 따라서 메모리 접근은 기반 업무와 같은 권한을 상속한다. 프로젝트를 볼 수 없다면 에이전트가 그 프로젝트에 대해 기억하는 것도 당신 것이 아니다. 새로운 권한 시스템을 만들지 않는 방식으로 정말 어려운 문제를 푼 셈이고, Asana가 이미 누가 무엇을 볼 수 있는지 알고 있기 때문에 가능한 해법이다. Asana는 지난해 9월 AI Teammates 발표 때부터 팀 전체 메모리와 엔터프라이즈 통제를 이야기했지만, M&A 경계 사례가 처음으로 제시된 구체적인 메커니즘이다.

Graphiti의 기여는 생명주기다. 대부분의 시스템은 틀린 사실을 삭제 문제로 본다. Graphiti는 시간 문제로 본다. 어떤 사실이 더 이상 참이 아니게 되면 엣지를 지우지 않고 무효화하고 타임스탬프를 붙인다. 그래서 에이전트는 “지금 무엇이 참인가”와 “3월에는 무엇이 참이었나”를 모두 답할 수 있다. 감사가 필요한 어떤 용도에서든 이것이 맞는 기본 요소다. 그리고 그 기본 요소가 새로운 팀 시스템 두 곳이 아니라 단일 에이전트 세계에서 나왔다는 점도 눈에 띈다.

Tencent는 기본 비공개 공유와 가장 명시적인 접근 등급을 제공한다. Asana는 VentureBeat에서 CPO Arnab Bose가 설명한 대로 에이전트 메모리를 기존 Work Graph 권한에 맞춰 범위 지정해, 기밀 프로젝트의 메모리가 권한 없는 동료에게 새지 않게 한다. Zep의 Graphiti는 저장소에 설명된 대로 오래된 사실을 삭제하지 않고 타임스탬프로 무효화한다.

해결되지 않은 중간 지대: 수정, 충돌, 전파

이제 두 출시 이야기가 모두 건너뛴 부분이다. 단일 에이전트 메모리의 잘못된 사실은 사용자 한 명이 같은 내용을 반복해서 고쳐야 하는 비용을 만든다. 공유 저장소의 잘못된 사실은 누군가 알아차리기 전에 그것을 읽은 모든 에이전트에게 전파된다. 그런데 현재 출시된 어떤 시스템도 그다음 절차를 문서화하지 않는다. VentureBeat의 출시 보도에는 출시 몇 시간 만에 실무자들이 지적한 빈틈이 모여 있다. 이미 소비된 사실의 수정과 만료, 애초에 무엇은 절대로 기록하지 말아야 하는지에 대한 결정, 두 팀원의 에이전트가 같은 모듈에 대해 서로 모순된 사실을 썼을 때 공유 저장소가 누구의 말을 선택해야 하는지가 그것이다. 단일 에이전트 메모리는 천천히 표류한다. 공유 메모리는 빠르게 표류한다. 오래된 쓰기 하나가 그 쓰기가 만들어진 세션을 보지도 못한 사람들에게 전달되기 때문이다.

이것은 다음 포인트 릴리스에서 고칠 구현상의 사소한 흠이 아니다. 2026년 3월 논문 “거버넌스가 적용된 메모리: 멀티 에이전트 워크플로를 위한 프로덕션 아키텍처”는 공유 멀티 에이전트 메모리 전반의 구조적 위험으로 거버넌스 파편화와 피드백 루프 없는 조용한 품질 저하를 지목한다. 학술적으로 정중하게 말했지만 요지는 실패 모드가 특정 벤더가 아니라 아키텍처 자체에 들어 있다는 것이다. 보안 관점에서는 문제가 더 커진다. OWASP의 에이전트형 위협 가이드는 메모리 오염을 별도의 공격 유형으로 명시하고, 공유 저장소는 곧 공유된 영향 범위다. Asana의 권한 상속과 Tencent의 기본 비공개 등급은 오염되거나 오래된 메모리를 누가 읽을 수 있는지는 제한한다. 하지만 잘못된 것을 누군가 이미 읽은 뒤 무슨 일이 일어나는지는 둘 다 해결하지 않는다.

내가 보기에 수정과 충돌 해결은 결국 다른 모든 공유 정보 시스템에서 그랬듯 사회적인 방식으로 굴러갈 것이다. 자산마다 이름이 있는 소유자, 검토 습관, 만료 규칙이 필요하다. 이 범주에서 이기는 도구는 그 사회적 절차를 없애겠다고 약속하는 도구가 아니라 쉽게 만들어주는 도구일 것이다. 위키, CRM, 기능 플래그에서도 이미 같은 영화를 봤다. 거버넌스 기능이 곧 제품이다. 이는 에이전트 거버넌스 글에서 내린 결론과 같고, 에이전트형 아키텍처에서 “메모리만 추가하자”가 계획이 아닌 이유와도 같다.

Team Memory 출시 직후 실무자들은 수정, 만료, 충돌 해결이 문서화되지 않은 빈틈이라고 지적했다. VentureBeat에 정리돼 있다. 2026년 3월 “거버넌스가 적용된 메모리” 논문은 같은 문제를 공유 멀티 에이전트 메모리의 구조적 위험으로 지적하고, OWASP의 에이전트형 AI 위협 가이드는 메모리 오염을 별도의 공격 유형으로 분류한다.

지금 무엇을 해야 하나

이번 분기에 공유 에이전트 메모리를 평가한다면 네 가지를 이 순서대로 하자.

1. 오늘: 어떤 데모를 보기 전에 네 가지 답을 적어라. 읽기 범위, 수정 절차, 삭제 의미론, 충돌 규칙이다. 기능별로 그 답을 맞출 수 없는 벤더는 곧 자기 로드맵이 어디서 끝나는지 알려주는 셈이다.

2. 이번 주: M&A 테스트를 해보라. 기밀 프로젝트 아래에 메모리 하나를 만든 뒤, 그 프로젝트 접근 권한이 없는 사용자로 같은 에이전트에게 질문하라. Asana는 이 경우를 명시적으로 설계했다. 다른 모든 제품도 직접 시연하게 해야 한다.

3. 이번 달: 샌드박스에서 일부러 하나를 오염시켜라. 그럴듯하지만 틀린 사실을 공유 저장소에 쓰고, 에이전트 두 개가 소비하게 한 뒤 철회해 보라. 오후 한 번으로 전파와 정리에 대해 배우는 것이 어떤 아키텍처 다이어그램보다 가치 있다.

4. 지속적으로: 소유자를 지정하라. 정확성을 책임지는 이름 있는 사람이 없는 메모리 자산은 벡터 인덱스가 붙은 기술 부채다.

메모리 요구가 아직 단일 에이전트 수준이라면 계산은 다르고 더 가볍다. 그쪽의 선택지는 셀프 호스팅 에이전트 글에서 다뤘다.

자주 묻는 질문

공유 에이전트 메모리를 한 문장으로 설명하면?

여러 에이전트와 그들을 사용하는 사람들이 함께 읽고 쓰는 사실, 절차, 컨텍스트의 영속 저장소다. 덕분에 팀은 에이전트마다 처음부터 다시 설명하는 일을 멈추고, 대신 서로의 실수까지 물려받기 시작한다.

Tencent의 Team Memory와 Asana의 AI Teammates 중 무엇이 더 안전한가?

서로 다른 질문에 답한다. Tencent는 네 단계, 에이전트별 로드아웃, 기본 비공개 설정으로 더 세밀하고 명시적인 접근 모델을 제공하고 셀프 호스팅도 가능해 데이터 위치를 직접 선택할 수 있다. Asana 모델은 더 거칠지만 이미 검증된 워크스페이스 권한을 상속해 기밀 업무를 통제한다. 여기서 “안전”은 대부분 “우리 조직 구조에 맞게 범위가 제대로 잡혔는가”라는 뜻이고, 그 답은 조직 자신만 안다.

공유 메모리가 틀리면 무엇이 일어나나?

오늘 기준으로는 대부분 자동으로 아무 일도 일어나지 않는다. Tencent는 버전과 상태를 추적하지만 이미 소비된 사실의 수정 또는 만료 절차를 문서화하지 않는다. Asana는 사람의 피드백 루프로 행동을 수정하지만 메모리 자체의 수정 절차는 공개하지 않았다. Graphiti는 오래된 사실에 타임스탬프를 붙여 무효화하는데 지금 가능한 기본 요소 중 가장 낫지만, 한 에이전트의 그래프를 관리한다. 어느 것을 선택하든 수동 검토 절차에 예산을 잡아야 한다.

두 에이전트의 서로 모순되는 메모리를 자동으로 조정할 수 있나?

내가 근거를 확인할 수 있는 현재 출시 제품에는 없다. 현재 동작은 검색 순위가 하나를 선택하는 식이다. 즉 충돌이 쿼리마다 유사도 점수에 의해 보이지 않게 해결된다. 규제, 재무, 안전처럼 사실이 중요한 용도라면 “누구의 메모리가 이기는가”를 나중에 나올 기능이 아니라 직접 정해야 할 정책 질문으로 다뤄라.

결론

공유 메모리는 올바른 방향이지만 미완성 제품이다. Tencent와 Asana는 접근 제어 절반을 만들 수 있다는 것을 서로 다른 방식으로 입증했다. 한쪽은 개방적이고 이동 가능하며, 다른 쪽은 폐쇄형이지만 기존 권한 체계에 자연스럽게 붙는다. 그것만으로도 8월은 실제 이정표다. 그러나 수정, 만료, 충돌이라는 나머지 절반은 현재 아무도 제대로 문서화하지 않았고, 기본적으로 당신의 책임이다. 접근 제어는 사더라도 수정 절차는 직접 계획하라. 모든 공유 메모리는 이미 팀 전체가 행동에 반영한 사실이라고 가정하는 편이 낫다. 잘못됐다는 것을 알아차릴 때쯤에는 실제로 그랬을 가능성이 높다.

공유 메모리를 자신의 에이전트 스택 어디에 둘지 고민하고 있다면, 나는 이런 주제를 고객과 정기적으로 논의한다. 연락해 달라.

출처

• Tencent Cloud, “TencentDB Agent Memory, Team Memory 출시”: https://www.tencentcloud.com/dynamic/news-details/101465 (2026년 8월 13일 게시, 2026년 8월 29일 확인)

• VentureBeat, “Tencent의 Team Memory, 팀 전체에 AI 에이전트 메모리를 공유하지만 잘못됐을 때의 거버넌스는 아직 없다”: https://venturebeat.com/data/tencents-team-memory-shares-ai-agent-memory-across-a-team-with-no-governance-yet-for-when-its-wrong (2026년 8월 7일 게시, 2026년 8월 29일 확인)

• VentureBeat, “Asana의 AI 에이전트는 회사 전체에 메모리를 공유하지만 비밀은 공유하지 않는다”: https://venturebeat.com/orchestration/asanas-ai-agents-share-memory-across-your-company-but-not-your-secrets (2026년 8월 3일 게시, 2026년 8월 29일 확인)

• Asana, Inc., “Asana, 새로운 AI Teammates 발표”: https://investors.asana.com/news-releases/news-release-details/asana-announces-new-ai-teammates-collaborative-agents-deliver/ (2025년 9월 25일 게시, 2026년 8월 29일 확인)

• TencentCloud, TencentDB-Agent-Memory 저장소: https://github.com/TencentCloud/TencentDB-Agent-Memory (2026년 8월 29일 확인)

• Zep, Graphiti 저장소: https://github.com/getzep/graphiti (2026년 8월 29일 확인)

• Mem0 저장소: https://github.com/mem0ai/mem0 (2026년 8월 29일 확인)

• OWASP, “에이전트형 AI 위협과 완화책”: https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ (2026년 8월 29일 확인)