AI Agent에 장기 메모리를 붙이면 권한이 새기 시작한다: 컨텍스트 누적과 권한 누수를 막는 운영 설계

OWASP가 2026년 Agentic Applications Top 10에 ASI06: Memory Poisoning을 새로 추가했고, Palo Alto Unit 42는 ChatGPT의 장기 메모리에 indirect prompt injection을 심어 사용자의 모든 대화를 외부로 빼내는 PoC를 공개했다. 멀티에이전트 환경에서 메모리 유출을 측정한 2026년 연구는 토폴로지가 복잡해질수록 누출이 비선형으로 증가한다고 보고했다. 메모리는 이제 에이전트의 편의 기능이 아니라 공격 표면이 됐다.

요약

AI Agent의 운영 사고에서 가장 늦게 인지되고 가장 오래 가는 것은 메모리에서 시작된다. 작업 컨텍스트, 세션 메모리, 장기 메모리는 시간이 지날수록 사용자 데이터, 권한 결정, 시스템 비밀을 빨아들이고, 권한 경계를 흐리며, 외부에서 심어진 지시를 트로이 목마처럼 보관한다. 이 글은 에이전트 메모리가 운영 사고로 이어지는 세 가지 경로 — 컨텍스트 누적, 권한 누수, 메모리 오염 — 와, 운영자가 메모리 계층에 박아야 할 다섯 가지 설계 원칙을 정리한다.

이 글이 필요한 사람

LangChain, LlamaIndex, Mem0, Letta, Bedrock Agent, Azure AI Foundry Agent 같은 프레임워크로 장기 메모리를 가진 에이전트를 운영 환경에 붙이려는 DevOps, 플랫폼, 보안, SRE 엔지니어. 특히 "메모리는 사용자 경험을 위한 것"이라고만 생각하고 권한·데이터 거버넌스를 아직 설계하지 않은 팀.

왜 지금 이 주제인가

에이전트 메모리는 지난 6개월 사이 제품 기능에서 운영 리스크로 위치가 바뀌었다. 2026년 5월 LLMS3는 Memory Poisoning을 "AI 에이전트 보안의 변곡점"으로 정의했고, OWASP는 같은 시기 Agentic Applications Top 10에 ASI06으로 정식 등재했다. arXiv에는 장기 메모리 보안만을 다룬 서베이 논문이 발표됐고, MINJA(Memory Injection Attack via Query-Only Interaction)처럼 일반 사용자와 동일한 인터페이스만으로 메모리를 오염시키는 공격 기법이 학계 수준에서 정리됐다.

업계 도구도 빠르게 따라왔다. Mem0는 메모리 보안 베스트 프랙티스를 별도 문서로 정리했고, IBM은 토큰 한도 기반 메모리 수명 관리를 권장 패턴으로 발표했다. 즉, 메모리는 더 이상 "잘 작동시키면 되는" 영역이 아니라, "사고가 나기 전에 거버넌스를 박아야 하는" 영역이 됐다.

이 변화의 운영적 의미는 단순하다. 권한 사고, 비용 사고, 데이터 유출 사고가 더 이상 호출 한 번에서 끝나지 않고, 메모리에 남아 다음 세션에서 다시 발화한다. 보안 사고의 시간축이 분 단위에서 주·월 단위로 늘어났다.

에이전트 메모리는 왜 운영 리스크인가

에이전트 메모리를 운영 관점에서 보려면 먼저 세 계층으로 나눠야 한다. 첫째, 작업 컨텍스트(working context)는 현재 진행 중인 단일 작업에서 모델 입력에 들어가는 모든 것이다. 둘째, 세션 메모리(session memory)는 한 사용자의 한 대화 세션 안에서 유지되는 상태다. 셋째, 장기 메모리(long-term memory)는 세션을 가로질러 보존되는 벡터 저장소, 지식 그래프, 사용자 프로파일이다.

문제는 세 계층 모두 시간이 지날수록 무겁고 더럽고 권한이 흐려진다는 점이다. 작업 컨텍스트는 RAG 결과와 도구 출력으로 부풀어 토큰 캡 직전까지 차오르고, 세션 메모리는 사용자가 무심코 흘린 비밀번호와 내부 결정을 그대로 들고 다음 도구 호출에 합류하며, 장기 메모리는 한 번 들어오면 "잊는 방법이 정의되지 않은" 상태로 쌓인다. IBM이 제안한 20,000 토큰 메모리 캡은 이 누적을 강제로 끊기 위한 가장 단순한 운영 장치다.

가장 골치 아픈 것은 메모리가 권한 결정에 영향을 준다는 점이다. 모델은 메모리에 적혀 있는 사실을 "이미 검증된 컨텍스트"로 다룬다. 누군가가 한 번 심어둔 잘못된 사실, 한 번 빠져나온 다른 사용자의 데이터, 한 번 통과한 잘못된 정책 해석은, 다음 세션에서 권한 의사결정의 근거로 다시 등장한다. 메모리는 단순한 저장소가 아니라, 모델이 신뢰하는 컨텍스트의 지속성을 만든다.

경로 1. 컨텍스트 누적: 메모리는 가만히 두면 자란다

세션이 길어질수록 작업 컨텍스트는 RAG 결과, 도구 호출 응답, 사용자 발화, 시스템 지시로 채워진다. 모델이 잊지 않게 하려는 의도는 자연스럽지만, 운영자 입장에서는 두 가지가 동시에 늘어난다. 비용과 노출 면적.

비용은 직관적이다. LeanOps의 2026년 분석은 에이전트가 동일한 작업을 단순 채팅 대비 평균 50배의 토큰으로 처리한다고 보고했고, 누적되는 컨텍스트는 그 50배의 가장 큰 기여자다. 단일 작업이 50만 토큰을 넘기는 사고가 흔히 보고되는 이유도 메모리가 자라기만 하기 때문이다.

노출 면적은 덜 직관적이지만 더 위험하다. 컨텍스트에 들어온 모든 것은 다음 도구 호출의 인자로 흘러갈 수 있다. 첫 번째 도구 호출 응답에 들어 있던 다른 사용자의 PII가, 두 번째 도구 호출의 인자에 그대로 실려 외부 API로 나갈 수 있다. 모델은 "이 데이터를 보내지 마라"는 시스템 지시를 잊고, 메모리에 누적된 내용을 묶어 한 번에 흘려보낸다.

운영자가 메모리 수명 관리를 도입해야 하는 이유가 여기에 있다. 토큰 한도, 시간 한도, 작업 종료 시 강제 폐기를 함께 두지 않으면, 컨텍스트는 사고의 무게를 시간으로 키운다.

경로 2. 권한 누수: 메모리는 권한 경계를 흐린다

장기 메모리는 한 사용자의 데이터가 다른 사용자의 응답에 새어 나오기 가장 쉬운 통로다. 멀티에이전트 환경에서 메모리 누출을 측정한 2026년 연구는 토폴로지가 복잡해질수록 누출이 비선형으로 증가한다고 정량화했다. 에이전트 사이의 메모리 공유, 도구 사이의 컨텍스트 전달, 사용자 사이의 벡터 공간 공유가 모두 한 점이라도 격리에 실패하면 권한이 같이 새어 나간다.

가장 흔한 누수 패턴은 세 가지다. 첫째, 멀티 테넌트 벡터 저장소에서 사용자 ID 필터가 누락된 채 유사도 검색만 수행되는 경우. 둘째, 같은 에이전트 인스턴스가 여러 사용자의 세션을 처리하면서 메모리 네임스페이스를 사용자 단위가 아닌 에이전트 단위로 가져가는 경우. 셋째, 도구가 다른 사용자의 메모리를 결과로 돌려준 뒤 모델이 그것을 현재 사용자에게 그대로 노출하는 경우.

방향은 분명하다. 메모리도 IAM처럼 다뤄야 한다. 사용자별 네임스페이스, 세션별 격리, 메모리 저장소에 대한 Read/Write/Delete RBAC, 메모리 항목에 대한 무결성 검증. 권한 경계는 도구 호출에서만 강제하는 것이 아니라 메모리 읽기·쓰기에서도 동일하게 강제돼야 한다. 도구 호출은 게이트가 막아주지만, 메모리 검색 결과는 그대로 모델 컨텍스트로 들어가서 다음 도구 호출의 신뢰된 인자가 된다.

권한 누수를 막는 첫 단계는 단순하다. 메모리에서 무언가를 읽어올 때마다 "이 항목을 이 사용자가 보아도 되는가"라는 정책 결정을 한 번 더 거치게 만드는 것이다. 정책 결정 없이 유사도만으로 검색되는 메모리는, 권한 경계가 없는 검색 인덱스와 같다.

경로 3. 메모리 오염: prompt injection이 시간을 무기로 쓴다

가장 새로운 위협은 메모리 오염이다. OWASP의 ASI06: Memory Poisoning이 정의하는 시나리오는 다음과 같다. 공격자가 외부 문서, 이메일, 웹 페이지, 도구 출력에 악성 지시를 숨기고, 에이전트가 그것을 장기 메모리에 저장하게 만든다. 며칠 또는 몇 주 뒤, 같은 에이전트가 메모리를 회상할 때 그 지시가 "신뢰된 과거 기록"으로 다시 실행된다.

이 공격이 위험한 이유는 두 가지다. 첫째, 일반적인 prompt injection 방어는 입력 경계에서 동작하지만, 메모리 오염은 입력이 이미 통과한 뒤 시간 차원에서 발화한다. 둘째, 흔히 쓰이는 메모리 방어 — 잘림(truncation), 요약, 검색 순위 — 는 일단 들어온 악성 지시를 안정적으로 제거하지 못한다는 점이 연구로 확인됐다. Palo Alto Unit 42의 PoC는 indirect prompt injection으로 ChatGPT 장기 메모리에 스파이웨어 같은 지시를 심어 사용자의 모든 대화를 외부로 빼내는 시나리오를 실증했다.

MINJA처럼 일반 사용자와 같은 인터페이스만으로 메모리를 주입하는 공격은 권한 통제나 guardrail로 막기 어렵다. 일반 호출과 구분되지 않기 때문이다. 그래서 메모리 오염은 입력 필터링만으로는 충분하지 않고, 메모리 쓰기 자체를 별도 게이트에서 통제해야 한다.

운영자가 만들어야 할 통제는 세 가지다. 메모리 쓰기 단계의 콘텐츠 검증, 시간 기반 감쇠(temporal decay)와 패턴 필터, 메모리 회상 시점의 신뢰도 점수. 메모리 회상 결과에 trust score를 부여해 일정 임계치 이하의 항목은 컨텍스트에 합류시키지 않는 방식이다. 단일 탐지기보다는 시간 신호, 패턴 신호, 콘텐츠 분석을 결합한 복합 점수가 효과적이라는 것이 최근 연구의 일관된 결론이다.

운영 설계 원칙 다섯 가지

첫째, 메모리에 수명을 박는다. 작업 컨텍스트는 작업 종료 시 폐기, 세션 메모리는 시간 한도와 토큰 한도 모두 적용, 장기 메모리는 항목별 TTL과 명시적 만료 정책을 가진다. IBM이 권장한 20,000 토큰 캡과 같은 단순한 상한이라도 없는 것보다 훨씬 낫다.

둘째, 메모리 네임스페이스를 사용자 단위로 강제한다. 에이전트 단위, 도구 단위, 세션 단위의 네임스페이스는 멀티 테넌시 누수의 주된 원인이다. 사용자 ID가 항상 메모리 키의 일부로 들어가게 만들고, 벡터 검색에도 사용자 ID 필터를 메타데이터 레벨에서 강제한다.

셋째, 메모리 읽기·쓰기에 RBAC을 둔다. Read, Write, Delete는 서로 다른 권한이고, Write는 특히 보수적으로 다룬다. 외부 콘텐츠에서 직접 메모리에 쓰는 경로는 명시적인 화이트리스트 외에는 금지하고, 쓰기 직전에 콘텐츠 검증을 한 번 거친다.

넷째, 메모리 회상에 신뢰도 점수를 붙인다. 항목의 출처(사용자 발화, 도구 출력, 외부 문서), 나이(temporal decay), 패턴 매칭 결과를 결합한 단일 trust score를 산출하고, 임계치 이하의 항목은 컨텍스트에 자동으로 포함시키지 않는다. 회상 결과를 모델이 무조건 신뢰하지 않도록, 회상 단계와 모델 입력 단계 사이에 정책 결정 한 단계를 둔다.

다섯째, 메모리 감사 로그를 도구 호출 로그와 같은 수준으로 운영한다. 누가, 어떤 사용자 컨텍스트로, 어떤 메모리 항목을 읽었거나 썼는지를 도구 호출 감사와 동일한 보존 정책으로 기록한다. 사고 분석에서 도구 호출 로그만 있고 메모리 접근 로그가 없으면, "이 결정의 근거가 어디서 왔는가"를 추적할 수 없다.

AWS / Azure 관점

AWS 환경에서는 Bedrock Agent의 메모리 기능을 사용할 때 사용자 단위 세션 식별자를 명시적으로 부여하고, 장기 메모리는 별도 OpenSearch Serverless 또는 Aurora pgvector 컬렉션에 사용자 ID를 메타데이터 필드로 강제하는 패턴이 자연스럽다. 메모리 쓰기 경로는 Lambda 프록시 한 점으로 집중시켜 콘텐츠 검증과 감사 로그를 같은 자리에서 처리하고, CloudWatch Logs에 메모리 접근 이벤트를 도구 호출과 동일한 보존 기간으로 저장한다. Bedrock Guardrails는 입력·출력 단계에 적용되지만, 메모리 쓰기 단계에서도 별도의 콘텐츠 정책을 한 번 더 거는 것이 안전하다.

Azure 환경에서는 AI Foundry Agent Service에서 메모리 저장소로 Azure AI Search나 Cosmos DB의 벡터 인덱스를 쓰는 경우가 일반적이다. 사용자 분리는 인덱스 또는 컨테이너 레벨이 아니라 메타데이터 필터로 강제하되, RBAC은 Managed Identity 단위로 Read와 Write를 분리한다. 메모리 쓰기 검증은 Azure API Management 정책 또는 Function App 측에서 처리하고, 감사 로그는 Application Insights와 Log Analytics에 동일 워크스페이스로 모은다. Prompt Shields는 indirect prompt injection 탐지 기능을 포함하지만, 메모리에 이미 저장된 항목에는 회상 시점에 한 번 더 검사를 거는 것이 안전하다.

두 클라우드 모두 공통점은 같다. 모델 공급사가 제공하는 메모리 기능은 사용성 위주의 기본값을 가지고, 운영자는 그 위에 수명·격리·검증·감사 네 층을 별도로 설계해야 한다.

실무 체크리스트

작업 컨텍스트가 작업 종료 시 자동 폐기되는가 세션 메모리가 시간과 토큰 두 축 모두에서 한도를 가지는가 장기 메모리의 모든 항목에 TTL 또는 명시적 만료 정책이 있는가 모든 메모리 키에 사용자 ID가 포함돼 있고, 검색에도 사용자 ID 필터가 메타데이터 레벨에서 강제되는가 메모리 Read, Write, Delete가 서로 다른 RBAC 권한으로 분리돼 있는가 외부 콘텐츠가 메모리에 직접 쓰이는 경로가 차단돼 있거나 화이트리스트로 제한돼 있는가 메모리 회상 결과에 출처·나이·패턴 기반 trust score가 적용되는가 임계치 이하의 메모리 항목이 자동으로 컨텍스트에서 제외되는가 메모리 접근 이벤트가 도구 호출 로그와 같은 수준의 감사 로그로 남는가 사고 분석 시 "이 결정의 근거가 메모리의 어떤 항목에서 왔는가"를 역추적할 수 있는가

흔한 실수

가장 자주 보이는 실수는 메모리를 사용자 경험 기능으로만 다루는 것이다. 메모리는 권한, 데이터 거버넌스, 보안 사고의 시간축을 모두 늘리는 운영 표면이고, UX 기능이 아니라 IAM 자원처럼 다뤄야 한다.

메모리 네임스페이스를 에이전트 단위로만 가져가는 것도 흔하다. 같은 에이전트가 여러 사용자를 처리하면 네임스페이스가 사용자 경계와 어긋난다. 사용자 ID는 메모리 키의 가장 바깥에 있어야 한다.

prompt injection 방어를 입력 경계에서만 처리하는 것도 위험하다. 메모리 오염은 입력이 통과한 뒤 시간 차원에서 발화한다. 입력 필터 외에 메모리 쓰기 게이트와 회상 시점의 신뢰도 검사가 함께 있어야 한다.

메모리 잘림과 요약만으로 악성 지시가 제거된다고 보는 것도 잘못된 가정이다. 연구는 잘림·요약·검색 순위가 일단 들어온 악성 지시를 안정적으로 제거하지 못한다는 점을 반복적으로 보고했다. 들어오기 전에 막고, 들어온 뒤에는 trust score로 격리해야 한다.

감사 로그를 도구 호출에만 두고 메모리 접근에는 두지 않는 패턴도 사고 대응을 어렵게 만든다. 메모리는 의사결정의 근거가 되므로, 그 근거가 어디서 왔는지 추적할 수 없으면 사고 원인 분석이 멈춘다.

마무리

AI Agent의 메모리는 편의 기능에서 운영 표면으로 옮겨 가는 중이다. 컨텍스트 누적은 비용과 노출 면적을 동시에 키우고, 권한 누수는 멀티 테넌시 경계를 흐리고, 메모리 오염은 prompt injection의 시간축을 분에서 주·월로 늘린다. 운영자가 메모리에 박아야 할 다섯 가지 — 수명, 네임스페이스, RBAC, 회상 신뢰도, 감사 — 는 따로따로가 아니라 동시에 갖춰야 작동한다. 에이전트에 메모리를 한 줄 추가할 때마다 "이 메모리는 언제 사라지고, 누구의 것이고, 누가 쓰며, 회상될 때 얼마나 신뢰받는가"를 묻는 습관이, 결국 메모리가 만드는 사고의 크기를 결정한다.

---

이 글이 유용했다면 다음 편도 확인해보세요.

다음 글: AI Agent의 도구 호출 결과를 컨텍스트에 안전하게 합치는 방법: 출력 신뢰 경계 설계

References

• OWASP Top 10 for Agentic Applications - ASI06 Memory Poisoning (https://owasp.org/www-project-top-10-for-agentic-applications/)
• LLMS3 - When Memory Became the Attack Surface (https://llms3.com/blog/when-memory-became-the-attack-surface-may-2026)
• Palo Alto Unit 42 - When AI Remembers Too Much (https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
• Mem0 - State of AI Agent Memory 2026 (https://mem0.ai/blog/state-of-ai-agent-memory-2026)
• Mem0 - AI Memory Security Best Practices (https://mem0.ai/blog/ai-memory-security-best-practices)