
AI 에이전트의 기억 혼재를 방지하는 namespace 설계: user_id, agent_id, memory_space_id로 분리하기
요약
AI 에이전트의 장기 기억 활용 시 발생할 수 있는 기억 혼재 문제를 방지하기 위한 namespace 설계 방식을 제안합니다. user_id, agent_id, memory_space_id를 활용한 계층적 분리와 필터링 설계를 통해 데이터 보안과 검색 정확도를 동시에 확보하는 방법을 다룹니다.
핵심 포인트
- user_id, agent_id, memory_space_id를 통한 3단계 기억 분리 설계
- 벡터 검색 시 검색 스코어보다 선행되어야 하는 필터링(Filter)의 중요성
- 애플리케이션 레벨에서의 이중 검증을 통한 데이터 혼재 방어
- 공유 기억은 예외로 취급하여 명시적 허가 절차를 거칠 것
- 기억의 출처(Source)를 기록하여 신뢰도 판단 및 리뷰 용이성 확보
AI 에이전트에게 장기 기억을 부여하면, 다음에 반드시 나타나는 문제가 있습니다. 기억의 검색 정밀도가 아니라, 기억의 혼재입니다.
개인적으로 사용할 때는 하나의 memory/ 디렉토리에 Markdown을 두는 것만으로도 작동합니다. 하지만 사용자가 늘어나고, AI 파트너가 늘어나며, 업무용과 개인용의 문맥이 나뉘게 되면, "누구의, 어떤 AI의, 어떤 용도의 기억인가"를 혼동하지 않는 설계가 필요해집니다.
이 기사에서는 Agent Memories에서 채택하고 있는 기본 방침으로서, 다음 3가지 키로 기억을 분리하는 설계를 소개합니다.
user_id: 기억의 소유자
agent_id: 어떤 AI 파트너의 기억인가memory_space_id: 업무용, 개인용, 프로젝트용 등의 구획
벡터 검색 (Vector Search)을 도입하면 유사한 내용의 기억을 잘 불러올 수 있게 됩니다. 단, 그것은 "불러와도 되는 기억"만이 검색 대상이 되어 있을 때의 이야기입니다.
검색 대상에 다른 사용자의 기억이 섞여 있다면, 검색 정밀도가 높을수록 위험합니다. 유사하지만 타인의 기억을 자신 있게 반환해 버리기 때문입니다.
따라서 기억 검색에서는 먼저 필터 (Filter)를 겁니다. 검색 스코어 (Search Score)는 그 다음입니다.
type MemoryScope = {
user_id: string;
agent_id: string;
...
이런 형태로 만들어 두면, 검색의 입구에서 반드시 scope를 요구할 수 있습니다.
검색 함수의 인자로 query만 전달할 수 있는 설계로 만들지 않는 것이 중요합니다. 반드시 scope와 세트로 받습니다.
type SearchInput = MemoryScope & {
query: string;
limit?: number;
...
구현에 따라서는 벡터 DB (Vector DB) 측의 filter에만 의존하지 않고, 애플리케이션 (Application) 측에서도 동일한 조건을 재확인합니다. 이중으로 보이지만, 기억 혼재는 사고의 영향이 크기 때문에 마지막 출구에서도 방어합니다.
팀에서 사용할 경우, 공유 기억도 필요하게 됩니다. 하지만 공유를 기본값으로 설정하면 혼재가 발생합니다. 공유는 예외로 취급하여 명시적인 허가를 갖도록 합니다.
function canRead(memory: MemoryRecord, scope: MemoryScope): boolean {
const sameOwner = memory.user_id === scope.user_id;
const sameAgent = memory.agent_id === scope.agent_id;
...
공유 기억도 적어도 용도의 구획은 맞춰야 합니다. 업무용 공유 기억이 개인용 AI 파트너의 대화에 섞여서는 안 됩니다.
기억이 어디에서 왔는지도 중요합니다. Claude Code로 작업 중에 저장한 기억인지, ChatGPT와의 대화에서 가져온 기억인지, 수동으로 등록한 방침인지에 따라 신뢰도가 달라집니다.
const memory: MemoryRecord = {
id: "mem_20260623_001",
user_id: "user_123",
...
나중에 "이 기억을 정말로 채택해도 되는가"를 판단할 때, 출처가 남아 있으면 리뷰하기 쉬워집니다.
MCP 서버로 만드는 경우도 마찬가지입니다. memory_search나 memory_store의 입력에 scope를 필수적으로 포함시킵니다.
const ScopeSchema = z.object({
user_id: z.string().min(1),
agent_id: z.string().min(1),
...
여기서 scope를 서버 측에서 보완하는 설계로 할 경우에도, 최종적으로는 호출마다 확정된 scope를 로그 (Log)에 남깁니다. 나중에 혼재 사고를 조사할 수 있도록 하기 위해서입니다.
AI 에이전트의 기억 기반에서는 검색 정밀도보다 먼저 분리 설계가 필요합니다.
최소 구성은 다음 3가지입니다.
user_id
agent_id
memory_space_id
이 3가지로 검색 대상을 좁히고, 공유 기억은 명시적 허가제로 만듭니다. 여기에 더해 source_ai, source_app, visibility, consent를 남기면, 복수의 AI와 복수의 사용자 환경에서도 기억을 안전하게 다루기 쉬워집니다.
기억은 편리할수록 섞였을 때의 피해가 커집니다. 그렇기에 Agent Memories에서는 "어떤 AI라도 기억을 사용할 수 있는 것"만큼이나, "사용해서는 안 되는 기억을 섞지 않는 것"을 중시하고 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기