에이전트 메모리는 저장소가 아니다

한 달 전의 메모가 오늘의 일을 망치는 순간이 있다.

“이 고객은 전화보다 이메일을 선호한다.” 당시에는 맞았다. 그런데 고객이 연락 채널을 바꿨다면? “이 프로젝트는 예외적으로 이 절차를 밟았다.” 당시에는 필요한 우회였다. 그런데 그 절차가 일반 규칙처럼 다음 작업에 붙는다면? “이 정책은 이렇게 해석한다.” 그 정책이 이미 개정됐다면?

에이전트에 장기 기억을 붙일 때 처음 드는 생각은 대개 단순하다. 더 많이 저장하고, 필요할 때 잘 검색하면 되지 않을까. 하지만 오래 일하는 시스템에서 어려운 일은 저장이 아니라 재사용이다. 과거의 문장을 꺼내는 일보다, 그 문장이 지금도 이 사람·이 과업·이 환경에서 유효한지 판정하는 일이 더 어렵다.

기억은 과거를 모아 두는 창고가 아니다. 현재 행동이 무엇을 믿어도 되는지 가르는 작업대에 가깝다.

긴 문맥은 기억과 같지 않다

LLM의 context window가 길어지면 메모리 문제가 사라질 것처럼 보일 때가 있다. 훨씬 많은 대화와 문서를 한 번에 읽을 수 있으니, 따로 저장하고 검색하는 구조가 덜 필요해 보인다. 하지만 긴 문맥은 보관함을 넓힐 뿐, 무엇이 중요한지와 무엇이 아직 유효한지를 자동으로 가려 주지는 않는다.

오히려 모든 기록을 한 번에 넣으면 다른 문제가 생긴다. 오래된 정보가 최신 정보를 누른다. 비슷한 사건들이 서로 섞인다. 한 번의 예외가 일반 규칙처럼 보인다. 중요한 제약은 긴 문서 한가운데 묻힌다. 비용도 커진다.

MemGPT가 context window의 한계를 다루면서 운영체제의 가상 메모리에서 비유를 가져온 이유는 흥미롭다. 제한된 빠른 공간과 더 큰 느린 공간 사이에서 정보를 옮기고, 필요한 때에 꺼내는 관리 정책을 문제로 본다.[1] 이 비유에서 중요한 것은 “무한한 기억”이라는 약속이 아니다. 모든 것을 항상 앞에 두는 대신, 무엇을 언제 옮기고 보존할지 결정해야 한다는 사실이다.

긴 문맥은 기억의 재료다. 기억 시스템은 그 재료를 관리하는 정책이다.

저장·검색·사용은 서로 다른 행동이다

우리는 종종 이 세 가지를 한 기능처럼 말한다. “메모리에 넣었으니 다음에도 기억하겠지.” 실제로는 전혀 다른 판단이 들어 있다.

먼저 무엇을 저장할지 골라야 한다. 대화 중 나온 모든 문장이 장기 기억이 될 필요는 없다. 그다음 현재 요청과 관련된 후보를 검색해야 한다. 마지막으로, 검색된 후보를 지금의 행동 근거로 사용해도 되는지 확인해야 한다. 이 마지막 단계가 빠지면 검색 품질이 좋아도 위험해진다.

예를 들어 “지난번에 이 경로로 배포가 성공했다”는 기록을 찾았다고 하자. 그 기록은 사건 기억이다. 동일한 환경과 버전에서도 유효한 절차인지, 그때만 통했던 임시 우회인지, 이후에 더 권위 있는 배포 규칙이 생겼는지는 별도로 봐야 한다. 검색 결과가 있다는 사실은 적용 가능성을 보장하지 않는다.

그래서 메모리 항목은 문장 하나보다 조금 더 많은 정보를 품어야 한다.

이 다섯 칸을 모두 거창한 ontology로 만들자는 이야기는 아니다. 다만 “이 문장이 맞는가?”만 묻는 구조를 “언제, 어디서, 누구에게, 어떤 조건에서 맞는가?”로 바꾸자는 제안이다.

기억이 많아질수록 ‘틀린 적용’이 늘어난다

메모리가 없으면 과거를 잊는다. 메모리가 잘못 관리되면 과거를 너무 자신 있게 반복한다.

이 둘은 다른 실패다. 전자는 필요한 정보를 찾지 못하는 recall 문제다. 후자는 찾아낸 정보의 시간·범위·권위를 잘못 해석하는 applicability 문제다. 실무에서는 후자가 더 조용하다. 답변은 매끄럽고, 과거 기록도 실제로 존재하기 때문에 그럴듯하다. 다만 오늘의 조건에는 맞지 않는다.

LongMemEval이 장기 메모리의 능력을 정보 추출만으로 보지 않고, 다회차 추론, 시간 추론, 지식 갱신, 그리고 답변을 보류하는 능력까지 나눈 이유가 여기에 있다.[2] 특히 보류는 메모리 시스템에서 이상하게 들릴 수 있다. 잘 기억하는 시스템이라면 무엇이든 답해야 한다고 생각하기 쉽기 때문이다. 그러나 근거가 오래됐거나 서로 충돌할 때, “확인할 수 없다”는 답은 기억 실패가 아니라 잘못된 재사용을 막는 능력이다.

기억은 많이 회수하는 시스템이 아니라, 회수하지 말아야 할 때를 아는 시스템이어야 한다.

하나의 ‘메모리’ 안에는 서로 다른 것이 들어 있다

메모리를 한 덩어리로 저장하면 갱신과 검증의 규칙도 한 덩어리가 된다. 이때 자주 망가지는 것은 서로 다른 성질의 정보를 같은 방식으로 다루기 때문이다.

특정 실행에서 일어난 일은 사건 기억이다. “어제 결제 API가 429를 반환했고, 10분 뒤 재시도에서 성공했다.” 이 기록은 미래 행동에 도움이 될 수 있지만, 그것만으로 “결제 API는 10분 뒤 재시도하면 된다”는 절차가 되지는 않는다.

확인된 정책이나 개념의 관계는 사실 기억에 가깝다. 이 정보에는 원문 출처와 버전이 중요하다. 반복적으로 성공한 작업 순서는 절차 기억이다. 여기에는 적용 조건, 성공률, 실패 사례가 중요하다. 특정 사용자의 선호나 조직의 권한은 또 다른 종류다. 주체와 범위를 벗어나면 바로 위험해진다.

이 표는 네 개의 저장소를 만들자는 설계도가 아니다. 같은 retrieval 점수로 판단하면 안 되는 네 종류의 대상을 구분하는 표다. 사건 기억은 시간에서 멀어질수록 일반화가 위험해지고, 정책 기억은 새 문서가 나오면 즉시 대체될 수 있으며, 선호는 사용자를 바꾸는 순간 무의미해질 수 있다.

Agent Workflow Memory는 긴 과업에서 과거 경험으로부터 재사용 가능한 workflow를 유도하고, 이후 과업에 선택적으로 제공하려 했다.[3] 여기서도 핵심은 축적이 아니라 선택이다. 유사한 과업에서 쓸 절차를 가르되, 모든 실행의 흔적을 다음 실행에 밀어 넣지 않는다.

갱신은 덮어쓰기보다 관계에 가깝다

메모리 설계를 할 때 “새 정보가 오면 이전 정보를 업데이트한다”는 문장은 너무 간단하다. 어떤 정보를 어떻게 업데이트하는가. 이전 기록은 틀렸는가, 일부 조건에서만 유효한가, 단지 더 구체적인 정보가 생긴 것인가? 이 차이는 나중에 매우 크게 돌아온다.

가격 정책이 바뀌면 이전 가격표는 대체되었다고 표시할 수 있다. 새 예외 조항이 생기면 기존 규칙은 완전히 틀린 것이 아니라 적용 범위가 좁아진다. 서로 다른 두 출처가 충돌하면 둘 중 하나를 조용히 지우기보다 논쟁 상태로 남기는 편이 안전할 수 있다. 사용자의 선호는 만료 후 재확인이 더 낫다.

A-MEM은 새 기억을 넣을 때 관련 기억을 찾아 연결하고, 새 정보가 기존 기억의 표현과 속성을 갱신할 수 있도록 설계한다.[4] 그 접근이 모든 시스템의 정답이라는 뜻은 아니다. 다만 메모리 구조가 고정된 서랍장이 아니라 새 정보가 들어올 때 다시 정리되는 조직이라는 시각은 유용하다.

그래서 나는 상태를 덮어쓰기보다 관계로 남기는 방식을 선호한다. supersedes, narrows, contradicts, expires, requires_confirmation 같은 관계다. 평소에는 현재 적용 가능한 항목만 꺼내면 된다. 문제가 생겼을 때만, 왜 이 기억이 선택되었고 어떤 갱신을 거쳤는지 되짚는다. 이력이 프롬프트를 늘리는 것이 아니라 감사 가능한 경로가 된다.

검색은 답변이 아니라 후보화다

벡터 검색은 의미가 비슷한 기억을 잘 찾는다. BM25는 표현이 정확히 맞는 항목을 붙잡는다. 그래프 탐색은 관계를 따라간다. 각각 쓸모 있다. 하지만 어떤 검색기도 “이 기억을 지금 행동에 써도 된다”는 판결을 대신하지는 못한다.

예를 들어 검색 상위 결과가 특정 고객의 선호를 말해 준다고 하자. 그 정보가 팀 전체의 권한을 바꾸는 규칙인지, 몇 달 전의 대화에서 나온 임시 요청인지, 이미 다른 채널에서 철회되었는지는 유사도만으로 알 수 없다. 접근 권한도 별도다. 관련 있다고 해서 볼 수 있는 것은 아니다.

그래서 retrieval 뒤에는 짧지만 분명한 관문이 필요하다.

현재 요청
→ 범위·권한 필터
→ lexical + semantic 후보 검색
→ 출처·최신성·충돌·적용 조건 확인
→ 재사용 / 조건부 인용 / 확인 요청 / 보류

이 흐름에서 메모리는 답변을 밀어 넣는 재료가 아니다. 현재 판단이 기대는 근거 후보가 된다. 출처와 유효 범위를 제시할 수 있는 기억만 행동에 더 강하게 영향을 준다.

그렇다면 무엇을 측정해야 할까

메모리 시스템은 대개 Recall@k, 정답률, 응답 지연으로 비교된다. 필요하다. 그러나 그것만으로는 “오래된 예외를 최신 정책으로 가져온 시스템”과 “필요할 때 확인을 요청한 시스템”을 구분할 수 없다.

좋은 메모리 평가는 회수 여부와 함께 다음을 본다. 필요한 항목을 찾았는가. 그 항목은 현재 과업에 적용되는가. 더 최근이거나 더 권위 있는 갱신을 우선했는가. 충돌한 항목을 그럴듯한 한 문장으로 합쳐 버리지 않았는가. 근거가 부족할 때 보류했는가. 마지막으로, 어떤 기억이 행동에 영향을 주었는지 사람이 나중에 복원할 수 있는가.

여기서 마지막 질문이 의외로 중요하다. 에이전트가 “예전 기록에 따라 이렇게 했다”고 말하는 것과, 실제로 어떤 기록의 어느 버전을 참조했는지는 다르다. 재사용된 memory ID와 원문 앵커, 상태, 적용 판단을 실행 기록에 남겨야 나중에 그 차이를 확인할 수 있다.

메모리가 지능처럼 보이기 시작하는 순간, 메모리는 거버넌스가 된다.

그 말은 거창한 통제 체계를 뜻하지 않는다. 무엇을 기록했는지. 무엇을 다시 썼는지. 무엇이 바뀌었는지. 그리고 확실하지 않을 때 무엇을 하지 않았는지. 이 네 가지를 확인할 수 있게 만드는 일이다.

에이전트가 오래 일할수록, 과거는 점점 더 큰 자산이 된다. 동시에 더 그럴듯한 오류의 원천이 된다. 그래서 좋은 기억의 기준은 저장한 양이 아니라, 현재 행동이 과거를 얼마나 조심스럽게 다시 쓰는지에 있을 것이다.

이 관점에서 보면 메모리의 삭제도 실패가 아니다. 원문이 사라질 수 있는 기록은 보관 정책으로 옮기고, 민감한 정보는 접근 범위를 줄이며, 오래된 선호는 재확인 대상으로 바꾼다. 중요한 것은 과거가 화면에서 완전히 사라지는지가 아니라, 현재 실행이 그것을 어떤 자격으로 만날 수 있는지다. ‘보관됨’과 ‘현재 행동을 이끌 수 있음’은 전혀 다른 상태다.

또 하나는 기억을 쓰는 주체의 문제다. 한 에이전트가 남긴 임시 가설을 다음 에이전트가 검증된 사실처럼 받으면, 오류는 저장소 안에서 조용히 승격된다. 그래서 기억에는 내용만큼 생성 주체와 검토 상태가 필요하다. 사용자가 확인한 선호인지, 도구가 관찰한 사건인지, 모델이 임시로 요약한 가설인지가 다르면 재사용의 강도도 달라져야 한다.

이 정도 구분을 넣으면 메모리는 똑똑해 보이기 위한 기능이 아니라, 긴 작업에서 판단을 망치지 않기 위한 기반이 된다. 에이전트가 과거를 말할 때 우리가 듣고 싶은 것은 “기억합니다”가 아니다. “어느 기록을, 어떤 범위에서, 왜 지금 다시 썼는지 알고 있습니다”에 더 가깝다.

이 기준은 기술 선택에도 영향을 준다. 벡터 DB, 그래프, 파일 기반 노트, 요약 계층 가운데 무엇이 유행하는가보다, 현재 시스템이 출처와 범위와 갱신을 잃지 않는지가 먼저다. 저장 형식은 바뀔 수 있다. 재사용의 책임은 남는다.

[1]: MemGPT: Towards LLMs as Operating Systems

[3]: Agent Workflow Memory

[2]: LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory

[4]: A-MEM: Agentic Memory for LLM Agents

[5]: A Survey on the Memory Mechanism of Large Language Model-based Agents