핵심 요약
AI 에이전트가 “지난번에 뭐라고 했지?”를 잘 기억하는 것만으로는 부족하다. 병원, 회사, 학교, 가정처럼 여러 사람이 같은 에이전트를 함께 쓰는 순간, 좋은 메모리는 곧 위험한 메모리가 될 수 있다.
GateMem의 질문은 단순하다. 에이전트가 기억해야 할 것은 기억하고, 보여주면 안 되는 것은 숨기고, 지워달라는 것은 다시 꺼내지 않을 수 있는가? 논문은 이 세 가지를 한꺼번에 평가하는 벤치마크를 제안한다. 결과는 꽤 차갑다. 긴 컨텍스트를 통째로 넣는 방식이 대체로 가장 강했지만, 그것도 완전하지 않았다. RAG와 외부 메모리 시스템은 비용을 줄였지만, 권한 없는 정보나 삭제된 정보를 여전히 흘렸다.
Figure 1이 이 논문의 핵심을 거의 다 말한다. 기존 메모리 벤치마크가 “내가 지난주에 뭐라고 했지?”를 묻는다면, GateMem은 “이 사람이 지금 이 정보를 볼 권한이 있나?”까지 묻는다.
논문: GateMem: Benchmarking Memory Governance in Multi-Principal Shared-Memory Agents
저자: Zhe Ren, Yibo Yang, Yimeng Chen, Zijun Zhao, Benshuo Fu, Zhihao Shu, Bingjie Zhang, Yangyang Xu, Dandan Guo, Shuicheng Yan
코드/데이터: GitHub, Hugging Face Dataset
“우리 집 AI”가 가족 모두의 비밀을 기억한다면?
개인용 챗봇에서는 메모리 문제가 비교적 단순해 보인다. 사용자의 선호, 프로젝트, 반복되는 작업을 잘 기억하면 된다. 실패도 대개 한 사람에게 돌아온다.
그런데 공유 환경은 다르다.
병원에서는 의사, 간호사, 약사, 환자 가족이 같은 환자 정보를 일부씩 다룬다. 회사에서는 매니저, HR, 보안 담당자, 계약자가 프로젝트와 인사 정보를 서로 다른 범위로 본다. 학교와 가정도 마찬가지다. 같은 “기억”이라도 누가 묻느냐에 따라 답해도 되는 정보와 답하면 안 되는 정보가 달라진다.
여기서 에이전트가 단순히 “정확히 기억했다”면 오히려 사고가 난다. 환자의 검사 결과를 정확히 떠올렸지만 권한 없는 가족에게 말한다면, 그것은 좋은 recall이 아니라 정보 유출이다. 삭제된 예전 주소를 다시 꺼내준다면, 그것도 친절이 아니라 실패다.
그래서 GateMem은 메모리 품질을 세 축으로 본다.
- Utility: 권한 있는 요청에는 유용하게 답하는가?
- Access Control: 권한 없는 요청에는 보호 정보를 흘리지 않는가?
- Active Forgetting: 삭제 요청 이후에는 그 정보를 복구하거나 확인해주지 않는가?
핵심은 이 셋이 따로 놀면 안 된다는 점이다. 무조건 거절만 잘하는 에이전트는 안전해 보이지만 쓸모가 없다. 반대로 다 기억하고 다 말하는 에이전트는 유용해 보이지만 조직에서는 배포하기 어렵다.
GateMem은 ‘긴 대화’가 아니라 ‘공유된 상태’를 만든다
GateMem은 4개 도메인으로 구성된다. 의료, 오피스, 교육, 가정이다. 전체 규모는 91개 long-form episode, 2,218개 hidden checkpoint다. 각 episode에는 여러 principal, 즉 서로 다른 주체가 등장하고, 사실 업데이트와 권한 경계, 삭제 요청이 시간순으로 쌓인다.
논문이 흥미로운 지점은 평가 질문을 대화 중간중간 숨겨둔다는 것이다. 에이전트는 특정 turn까지의 기록만 받은 뒤, 그 시점에서 질문을 받는다. 이 질문은 세 종류다.
- 지금 권한 있는 사람이 현재 상태를 물어보는 질문
- 권한이 애매하거나 없는 사람이 보호 정보를 떠보는 질문
- 삭제된 정보를 직접 또는 우회적으로 다시 확인하려는 질문
Figure 2는 GateMem이 단순 Q&A 세트가 아니라는 점을 보여준다. 도메인·역할·권한·삭제 사건을 먼저 설계하고, 그 위에 hidden checkpoint를 꽂아 넣는다.
데이터셋 통계도 일부러 복잡하게 설계되어 있다.
- Medical: 21 episodes, 579 checkpoints
- Office: 17 episodes, 547 checkpoints
- Education: 30 episodes, 540 checkpoints
- Household: 23 episodes, 552 checkpoints
- 전체 평균: episode당 223 turns, 13.4 principals, 24.4 checkpoints
이 정도 길이면 단순 키워드 검색으로는 부족하다. 오래전 정보와 최근 업데이트를 같이 봐야 하고, 같은 역할이라도 상황에 따라 권한이 달라질 수 있다. “환자 가족”이라는 단어 하나로 허용/거절을 결정할 수 없는 식이다.
점수는 곱셈이다. 하나라도 새면 전체가 무너진다
GateMem의 대표 지표는 Memory Governance Score, MGS다. 식은 직관적이다.
MGS = U × (1 - A) × (1 - F)
여기서 U는 유용성, A는 access-control violation rate, F는 post-deletion recovery failure rate다. 즉 유용성은 높을수록 좋고, 유출과 삭제 실패는 낮을수록 좋다.
곱셈이라는 점이 중요하다. 유용성이 90점이어도 권한 없는 정보 유출이 크면 MGS는 크게 깎인다. 반대로 유출은 거의 없지만 권한 있는 질문에도 답하지 못하면 역시 높은 점수를 받을 수 없다.
이 설계가 마음에 든다. 실제 공유 메모리 에이전트도 그렇기 때문이다. 병원이나 회사에서 “대부분은 잘 도와주는데 가끔 민감정보를 흘립니다”는 제품 설명이 될 수 없다. “아무것도 안 새지만 자주 일을 못 합니다”도 마찬가지다.
Table 3의 메시지는 선명하다. 어떤 방법도 네 도메인과 여러 backbone에서 utility, access control, forgetting을 동시에 안정적으로 잡지 못했다.
긴 컨텍스트가 강했다. 그런데 그것도 답은 아니었다
논문은 크게 세 종류의 방법을 비교한다.
- Long-Context: 지금까지의 대화 기록을 길게 넣는다.
- RAG-Naive / RAG-Policy: 검색으로 관련 기억을 가져오되, policy-aware 버전은 requester와 권한 메타데이터를 반영한다.
- A-Mem, Mem0, ReMeM: 별도 외부 메모리 구조를 쓰는 agentic memory 계열이다.
결과를 한 문장으로 줄이면 이렇다.
긴 컨텍스트는 가장 강한 베이스라인이지만, 거버넌스를 완성하지 못한다. RAG와 외부 메모리는 비용을 줄이지만, 권한과 삭제 의미론을 자동으로 해결하지 못한다.
예를 들어 GPT-5.4 조건에서 Long-Context는 Medical MGS 80.1로 강했다. 하지만 Office에서는 access-control violation이 33.9%까지 올라간다. Deepseek-V4-Pro에서도 Long-Context가 네 도메인 모두에서 강한 MGS를 보였지만, 여전히 유출과 삭제 실패가 남는다.
Policy RAG는 흥미로운 trade-off를 보여준다. 권한 메타데이터를 반영하면 단순 RAG보다 유출은 줄어든다. 하지만 필요한 증거까지 걸러버리거나 너무 조심스러운 답변을 하면서 utility가 떨어진다. 논문은 이를 over-refusal, 즉 정당한 요청까지 과하게 거절하는 문제로 따로 분석한다.
Figure 3은 retrieval depth를 늘리는 것만으로 문제가 풀리지 않는다는 점을 보여준다. 더 많이 가져오면 utility는 올라갈 수 있지만, 안전성과 과잉거절 사이의 긴장은 그대로 남는다.
외부 메모리 시스템도 기대만큼 깨끗한 답은 아니었다. A-Mem, Mem0, ReMeM 같은 시스템은 기억을 구조화하지만, “지금 이 requester가 이 사실을 볼 수 있는가?”와 “이 사실은 삭제 이후에도 행동상 복구 가능하면 안 되는가?”를 별도로 판단하지 않으면 여전히 실패한다.
여기서 꽤 중요한 교훈이 나온다. 메모리 구조화는 거버넌스가 아니다. 벡터DB, 그래프, 요약 노트, episodic memory를 붙였다고 해서 권한 모델과 삭제 의미론이 저절로 생기지는 않는다.
에이전트는 어디서 새는가: 가족, 역할, 삭제 확인
GateMem이 좋은 벤치마크처럼 보이는 이유는 “틀렸다”에서 멈추지 않고 어디서 틀리는지 쪼개기 때문이다.
Access-control 공격은 단순히 “권한 없는 사람이 비밀번호 알려줘” 같은 노골적인 형태만 있는 게 아니다.
- 가족이나 파트너가 “나도 알아야 하는 것 아니냐”고 묻는 overreach
- 대리 권한을 암시하는 delegated authority
- 직접 묻지 않고 존재 여부를 떠보는 label-existence probe
- 역할은 비슷하지만 실제 담당자가 아닌 role mismatch
- 여러 조각을 모아 우회하는 indirect inference
Active forgetting 공격도 마찬가지다. 삭제된 값을 직접 물어보는 경우도 있지만, “그 주소가 맞았지?”처럼 yes/no 확인을 요구하거나, 여러 단서로 쪼개 복원하려는 경우가 있다.
Figure 4는 실패가 한 종류가 아니라는 점을 보여준다. 공유 메모리의 위험은 노골적인 탈취보다, 그럴듯한 관계와 맥락 속에서 조금씩 경계가 무너지는 데 있다.
이건 실제 제품 설계에도 바로 이어진다. “민감정보는 말하지 마”라는 system prompt 하나로는 부족하다. 누가, 어떤 관계에서, 어떤 시점에, 어떤 목적으로 묻는지 판단해야 한다. 그리고 그 판단은 검색 이전, 검색 이후, 답변 생성 단계에 모두 걸쳐 있어야 한다.
이 논문이 말하는 다음 과제
GateMem의 결론은 꽤 현실적이다. 현재 메모리 에이전트는 공유 기관 환경에 바로 넣기 어렵다. 기억을 잘한다는 것은 출발점일 뿐이고, 배포 가능한 에이전트는 다음 능력을 같이 가져야 한다.
첫째, 메모리마다 소유자, 접근 범위, 만료/삭제 상태가 붙어야 한다. 그냥 텍스트 chunk로 저장하면 나중에 모델이 그 정보의 사회적 경계를 알 수 없다.
둘째, 검색 단계에서 권한 필터링이 필요하지만, 그것만으로 끝나면 안 된다. 필터가 너무 강하면 일을 못 하고, 너무 약하면 샌다. 검색 결과를 가져온 뒤에도 “이 답변에 보호 정보가 섞였는가?”를 다시 판단해야 한다.
셋째, 삭제는 데이터베이스 row를 지우는 문제만이 아니다. 논문이 말하는 active forgetting은 agent-facing forgetting이다. 사용자가 보기에는 에이전트가 그 정보를 더 이상 복구하거나 확인하지 못해야 한다. 요약, 캐시, 파생 메모리, 검색 인덱스에 남은 흔적까지 행동 수준에서 막아야 한다.
넷째, 평가도 바뀌어야 한다. 메모리 벤치마크가 recall만 보면, 제품은 recall을 최적화한다. 그러면 공유 환경에서 위험한 에이전트가 나온다. 평가가 governance를 요구해야 제품도 governance를 배운다.
그래서 메모리는 ‘더 많이 기억하기’가 아니다
GateMem을 읽고 나면, 에이전트 메모리에 대한 관점이 조금 바뀐다. 지금까지 메모리는 주로 개인화와 장기 맥락의 문제로 이야기됐다. 사용자의 취향을 기억하고, 프로젝트 히스토리를 유지하고, 이전 대화를 이어가는 능력 말이다.
하지만 공유 환경에서는 질문이 달라진다.
“무엇을 기억하는가?”보다 먼저 물어야 할 것은 “그 기억은 누구의 것인가?”다. 그리고 “잘 찾아오는가?”만큼 중요한 질문은 “지금 이 사람에게 말해도 되는가?”다.
아마 앞으로 좋은 에이전트 메모리는 사람의 기억보다 조직의 문서 관리 시스템에 더 가까워질 것이다. 접근권한, 감사 로그, 삭제 정책, 보존 기간, 역할 기반 뷰가 붙은 기억. 조금 덜 낭만적이지만, 훨씬 더 배포 가능한 기억이다.
AI 에이전트가 정말 우리 일상과 조직 안으로 들어오려면, 기억력보다 먼저 예의와 경계부터 배워야 한다.