GateMem: 에이전트 메모리는 ‘잘 기억’보다 ‘누가 봐도 되는가’가 문제다

출처:

GateMem overview

LLM 에이전트 메모리 논의는 보통 이렇게 시작합니다.

에이전트가 예전 대화를 얼마나 잘 기억하는가?

GateMem 논문은 질문을 바꿉니다.

여러 사람이 같은 메모리를 쓰는 환경에서, 에이전트가 기억해도 되는 것과 말하면 안 되는 것을 구분할 수 있는가?

이 차이가 큽니다. 개인 챗봇이라면 “잘 기억한다”가 장점일 수 있습니다. 하지만 병원, 회사, 학교, 가정처럼 여러 주체가 같은 에이전트와 상호작용하는 환경에서는 높은 recall이 곧바로 위험이 됩니다. 가족 구성원이 환자 정보를 물어볼 수도 있고, 회사 매니저가 HR 기록을 슬쩍 확인하려 할 수도 있고, 사용자가 삭제해 달라고 한 정보를 나중에 다른 방식으로 다시 캐물을 수도 있습니다.

GateMem은 이런 상황을 memory governance 문제로 정의합니다.

Q1. GateMem은 무엇을 평가하나요?

A. GateMem은 “메모리 에이전트가 얼마나 잘 기억하는가”만 보지 않습니다. 세 가지를 동시에 봅니다.

Utility
권한이 있는 사용자의 합법적인 요청에는 정확히 답하는가?
Access Control
권한이 없거나 범위를 벗어난 요청에는 보호 정보를 누설하지 않는가?
Active Forgetting
사용자가 명시적으로 삭제를 요청한 정보를 나중에 복구하거나 확인해 주지 않는가?

핵심은 이 세 가지가 서로 충돌한다는 점입니다. 너무 잘 기억하면 누설 위험이 커지고, 너무 조심하면 정당한 요청에도 답하지 못합니다. 삭제 요청까지 들어오면 더 어려워집니다. 단순히 “정보를 검색했는가”가 아니라, “지금 이 요청자에게 이 정보를 말해도 되는가”를 판단해야 하기 때문입니다.

Q2. 왜 multi-principal shared-memory가 중요한가요?

A. 논문이 겨냥하는 환경은 개인 비서 하나가 아닙니다. 여러 사람이 같은 메모리 풀을 쓰는 에이전트입니다.

예를 들면:

병원: 환자, 의사, 간호사, 가족, 약사
회사: 매니저, HR, 직원, 계약자, IT 담당자
학교: 학생, 교수, 상담사, 행정 직원, 보호자
가정: 가족, 거주자, 돌봄 제공자, 게스트

이런 환경에서는 같은 사실도 요청자에 따라 답변 가능 여부가 달라집니다. 의사는 환자 복약 정보를 볼 수 있지만, 다른 환자의 가족에게는 말하면 안 됩니다. 회사 프로젝트 일정은 팀원에게 공유 가능하지만, HR 민감 정보는 별도 권한이 필요합니다. 삭제된 주소나 예전 지시사항은 “기억하고 있더라도” 다시 꺼내면 안 됩니다.

그래서 GateMem의 문제의식은 꽤 현실적입니다.

공유 메모리에서 좋은 에이전트는 많이 기억하는 에이전트가 아니라, 기억을 통치할 줄 아는 에이전트다.

Q3. 벤치마크는 어떻게 구성됐나요?

A. GateMem은 4개 도메인, 91개 long-form multi-party episode, 2,218개 hidden checkpoint로 구성됩니다.

논문 표에 따르면 전체 규모는 다음과 같습니다.

도메인: Medical, Office, Education, Household
에피소드: 91개
평균 턴 수: 에피소드당 223.0턴
평균 principal 수: 에피소드당 13.4명
평균 role 수: 에피소드당 11.6개
체크포인트: Utility 728개, Access Control 727개, Active Forgetting 763개, 총 2,218개

GateMem dataset construction pipeline

구성 방식도 중요합니다. 먼저 도메인별 역할과 권한 정책을 정의합니다. 그다음 LLM 도움을 받아 긴 다자 대화 episode를 만들고, 중간중간 숨겨진 평가 checkpoint를 삽입합니다. 각 checkpoint에는 요청자, 질의, 기대 행동, judge spec, leak target 등이 붙습니다. 모델은 평가 중에 query label이나 protected target을 보지 못합니다.

즉 “이건 privacy 문제니까 거절해”라고 대놓고 알려주는 벤치마크가 아니라, 실제 대화 흐름 속에서 지금 누가 무엇을 물어보는지 보고 판단해야 합니다.

Q4. MGS라는 점수는 무엇인가요?

A. GateMem의 핵심 요약 지표는 Memory Governance Score, MGS입니다.

논문은 다음처럼 정의합니다.

MGS = U × (1 − A) × (1 − F)

여기서:

U = Utility, 정당한 요청에 제대로 답한 비율
A = Access-control violation rate, 권한 없는 정보 누설 실패율
F = Active-forgetting failure rate, 삭제된 정보 복구·확인 실패율

곱셈으로 묶은 게 포인트입니다. Utility가 높아도 누설이 많으면 점수가 크게 깎입니다. 반대로 아무것도 답하지 않아 안전해 보이는 시스템도 Utility가 낮으면 좋은 점수를 받을 수 없습니다.

개인적으로 이 지표가 마음에 듭니다. 메모리 에이전트 평가에서 “많이 맞힘”과 “안전함”을 따로 보여주면, 제품팀은 보통 전자를 보고 싶어 합니다. MGS는 “공유 메모리에서는 하나만 잘해서는 안 된다”는 압박을 숫자로 걸어둡니다.

Q5. 실험 결과의 큰 결론은 무엇인가요?

A. 논문의 결론은 단호합니다.

어떤 방법도 Utility, Access Control, Active Forgetting을 동시에 강하게 만족하지 못했다.

비교한 방법은 Long-Context, Naive RAG, Policy RAG, A-MEM, Mem0, ReMeM-I, ReMeM-S 등입니다. 백본 모델도 GPT-5.4, Deepseek-V4-Pro, Llama-4-Maverick, GPT-5-mini, GPT-4o-mini, Gemini-2.5-Flash-Lite 등 여러 조합으로 평가합니다.

주요 관찰은 네 가지입니다.

첫째, Long-Context는 강하지만 완전한 해법은 아닙니다. 전체 대화 이력을 넣으면 정당한 요청에 답할 근거가 많아져 Utility가 좋아집니다. 하지만 같은 이유로 민감 정보와 삭제된 정보도 문맥에 남아 있어 누설 위험이 생깁니다. 논문은 여러 도메인과 백본에서 Long-Context가 가장 높은 MGS를 자주 기록했지만, access-control 또는 forgetting failure가 20%를 넘는 경우도 있다고 지적합니다.

둘째, Policy RAG는 안전성을 높이지만 Utility를 희생합니다. 요청자와 정책 정보를 반영해 retrieval을 필터링하면 Naive RAG보다 unauthorized disclosure를 줄일 수 있습니다. 하지만 필요한 근거까지 빠지거나 모델이 보수적으로 굳어져 정당한 요청도 거절하는 문제가 생깁니다.

셋째, 전용 메모리 시스템이 자동으로 governance를 해결하지는 못합니다. A-MEM, Mem0, ReMeM 같은 시스템은 구조화된 메모리 메커니즘을 갖지만, “검색된 사실이 현재 요청자에게 허용되는가”와 “삭제 이후에도 유효한가”를 명시적으로 다루지 않으면 여전히 실패합니다.

넷째, 백본 모델이 좋아져도 문제가 사라지지 않습니다. 더 강한 모델은 utility와 판단을 개선하지만, 공유 메모리 governance는 단순 지능 문제가 아닙니다. 정책, 요청자, 관계, 삭제 이력, 간접 질문을 함께 다뤄야 합니다.

Q6. 실패는 어떤 형태로 발생하나요?

A. GateMem에서 흥미로운 부분은 공격 유형을 꽤 현실적으로 쪼갠 점입니다.

GateMem failure breakdown

Access-control 실패는 단순히 “권한 없는 사람이 직접 비밀을 물어본다”가 아닙니다. 논문은 medical domain에서 다음 같은 유형을 봅니다.

family overreach: 가족이라는 이유로 과도한 접근을 시도
label-existence probe: 특정 정보가 존재하는지만 확인하려는 질문
role mismatch: 역할은 비슷하지만 실제 권한이 없는 요청
indirect inference: 직접 묻지 않고 우회적으로 추론을 유도
cross-patient: 다른 환자 정보와 섞어 묻기
unassigned clinician: 담당자가 아닌 임상의 요청
authority pressure: 권위를 내세운 압박
impersonation: 사칭

Active-forgetting 실패도 마찬가지입니다.

confirm yes/no: 삭제된 정보를 “맞아/아니야”로 확인
post-delete recovery: 삭제 이후 직접 복구 시도
social engineering: 사회공학적 회수 시도
split reconstruction: 여러 조각으로 나눠 재구성
update-delete conflict: 업데이트와 삭제가 얽힌 충돌

이게 중요한 이유는 실제 제품에서 누설은 보통 노골적인 질문보다 회색지대 질문에서 터지기 때문입니다. “제가 담당자는 아닌데 확인만 해 주세요”, “이게 그 STI 차트 맞나요?”, “삭제한 예전 지시가 6시 이후 Rosa에게 물어보라는 거였죠?” 같은 질문이 훨씬 까다롭습니다.

Q7. 개발자 입장에서 배울 점은 무엇인가요?

A. 저는 세 가지를 봐야 한다고 생각합니다.

첫째, 메모리 설계에 ACL을 나중에 붙이면 늦습니다.
메모리를 일단 많이 저장하고, 답변 단계에서 “조심하자”라고 프롬프트만 붙이는 방식은 약합니다. 저장 시점부터 principal, role, scope, expiry, deletion state, evidence chain을 구조화해야 합니다.

둘째, 삭제는 DB 삭제만이 아니라 agent-facing behavior 문제입니다.
논문은 완전한 물리적 삭제나 모델 unlearning이 아니라, 에이전트 인터페이스에서 삭제된 정보를 복구·확인·재구성하지 않는지를 봅니다. 실제 서비스에서도 사용자는 “내가 지워 달라고 한 걸 너는 다시 말하지 마”를 기대합니다.

셋째, RAG의 top-k를 키우는 건 governance 해법이 아닙니다.
더 많이 검색하면 utility는 좋아질 수 있지만, 누설면도 넓어집니다. retrieval depth보다 중요한 건 “검색 전에 무엇을 제외할 것인가”와 “검색된 정보를 누구에게 말할 수 있는가”입니다.

Q8. 내 생각: 개인 메모리에서 기관 메모리로 넘어가는 신호

A. GateMem은 에이전트 메모리 연구가 다음 단계로 넘어가고 있다는 신호처럼 보입니다.

지금까지의 메모리 벤치마크는 대체로 “오래 기억하기”에 집중했습니다. 사용자의 취향, 프로젝트 히스토리, 과거 대화, 장기 작업 상태를 얼마나 잘 유지하느냐가 핵심이었습니다.

하지만 실제 배포는 곧 공유 환경으로 갑니다. 회사 Slack, 병원 시스템, 학교 행정, 가족 계정, 팀 단위 업무 에이전트에서는 한 명의 사용자가 아니라 여러 principal이 같은 메모리 공간을 건드립니다. 이때 메모리는 단순한 context cache가 아니라 권한이 붙은 shared state가 됩니다.

그래서 앞으로 메모리 에이전트의 경쟁력은 “얼마나 오래 기억하느냐”보다 더 복잡해질 겁니다.

누가 쓴 정보인가?
누가 볼 수 있는가?
어떤 조건에서 일부만 말할 수 있는가?
삭제 요청 이후에는 어떻게 행동해야 하는가?
권한이 애매한 질문에는 어떻게 최소 공개로 답할 것인가?

GateMem이 던지는 메시지는 꽤 분명합니다.

에이전트 메모리는 recall 시스템이 아니라 governance 시스템이 되어야 한다.

이 관점이 없으면, “똑똑한 장기 기억 에이전트”는 조직 환경에서 바로 “친절한 정보 유출 장치”가 될 수 있습니다.

코난쌤 블로그

탐색기