서론

AI 에이전트에게 장기 기억 (Long-term Memory)을 부여하면, 다음에 반드시 발생하는 문제가 있습니다. 기억의 검색 정밀도가 아니라, 기억의 혼재입니다.

개인적으로 사용할 때는 하나의 memory/ 디렉토리에 Markdown을 두는 것만으로도 작동합니다. 하지만 사용자가 늘어나고, AI 파트너가 늘어나며, 업무용과 개인용의 문맥이 나뉘게 되면, "누구의, 어떤 AI의, 어떤 용도의 기억인가"를 혼동하지 않는 설계가 필요해집니다.

이 기사에서는 Agent Memories에서 채택하고 있는 기본 방침으로서, 다음 세 가지 키로 기억을 분리하는 설계를 소개합니다.

user_id : 기억의 소유자

agent_id : 어떤 AI 파트너의 기억인가

memory_space_id : 업무용, 개인용, 프로젝트용 등의 구획

기억 혼재는 검색 정밀도의 문제가 아니다

벡터 검색 (Vector Search)을 도입하면 유사한 내용의 기억을 잘 불러올 수 있게 됩니다. 하지만 그것은 "불러와도 되는 기억"만이 검색 대상이 될 때의 이야기입니다.

검색 대상에 다른 사용자의 기억이 섞여 있다면, 검색 정밀도가 높을수록 위험합니다. 유사하지만 타인의 기억을 확신을 가지고 반환해 버리기 때문입니다.

따라서 기억 검색에서는 먼저 필터 (Filter)를 겁니다. 검색 스코어 (Search Score)는 그 다음입니다.

type MemoryScope = {
user_id: string;
agent_id: string;
...

이렇게 구성해 두면, 검색의 입구에서 반드시 scope를 요구할 수 있습니다.

검색 시에는 scope를 필수 사항으로 한다

검색 함수의 인자로 query만 전달할 수 있는 설계로 만들지 않는 것이 중요합니다. 반드시 scope와 세트로 받습니다.

type SearchInput = MemoryScope & {
query: string;
limit?: number;
...

구현에 따라서는 벡터 DB 측의 filter에만 의존하지 않고, 애플리케이션 측에서도 동일한 조건을 재확인합니다. 중복처럼 보이지만, 기억 혼재는 사고의 영향이 크기 때문에 마지막 출구에서도 방어합니다.

공유 기억은 예외로 취급한다

팀에서 사용하는 경우, 공유 기억 (Shared Memory)도 필요해집니다. 하지만 공유를 기본값으로 설정하면 혼재가 발생합니다. 공유는 예외로 취급하여 명시적인 허가를 갖게 합니다.

function canRead(memory: MemoryRecord, scope: MemoryScope): boolean {
const sameOwner = memory.user_id === scope.user_id;
const sameAgent = memory.agent_id === scope.agent_id;
...

공유 기억도 적어도 용도의 구획은 맞춥니다. 업무용 공유 기억이 개인용 AI 파트너의 대화에 섞여서는 안 됩니다.

source_ai와 source_app을 남긴다

기억은 어디에서 왔는지도 중요합니다. Claude Code로 작업 중에 저장한 기억인지, ChatGPT와의 대화에서 가져온 기억인지, 수동으로 등록한 방침인지에 따라 신뢰도가 달라집니다.

const memory: MemoryRecord = {
id: "mem_20260623_001",
user_id: "user_123",
...

나중에 "이 기억을 정말로 채택해도 되는가"를 판단할 때, 출처가 남아 있으면 리뷰하기 쉬워집니다.

MCP 도구의 입력에도 scope를 갖게 한다

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 에이전트의 기억 기반에서는 검색 정밀도보다 먼저 분리 설계가 필요합니다.

최소 구성은 다음 세 가지입니다.

user_id
agent_id
memory_space_id

이 세 가지로 검색 대상을 좁히고, 공유 기억은 명시적 허가제로 운영합니다. 여기에 더해 source_ai, source_app, visibility, consent를 고려합니다.

이를 유지하면 여러 AI와 여러 사용자가 있더라도 기억을 안전하게 다루기 쉬워집니다.

기억은 편리할수록, 섞였을 때의 피해가 커집니다. 그렇기 때문에 Agent Memories에서는 "어떤 AI라도 기억을 사용할 수 있다"는 것만큼이나, "사용해서는 안 되는 기억을 섞지 않는다"는 것을 중요하게 여깁니다.

Discussion