자율 AI 에이전트의 Memory Architecture 2: 장기 작업을 가능하게 하는 상태 관리 체계

핵심 요약

자율 AI 에이전트에서 memory architecture는 단순한 “대화 저장 기능”이 아니라 장기 작업을 가능하게 하는 상태 관리 체계이다. 대형 언어 모델(LLM)은 주어진 입력 문맥을 바탕으로 응답을 생성할 수 있지만, 모델 파라미터 자체가 특정 사용자, 프로젝트, 파일, 결정 이력, 실패 기록을 자동으로 장기 보존하는 것은 아니다. 실제 제품이나 에이전트 시스템이 기억을 제공할 수는 있지만, 그 기억은 보통 모델 내부의 고정된 지식이 아니라 애플리케이션 계층, 데이터베이스, 파일 저장소, 검색 시스템, 권한 정책이 결합된 외부 상태 관리 구조에 의해 구현된다.

컨텍스트 창(context window)은 현재 응답 생성에 사용되는 작업 공간에 가깝다. 긴 컨텍스트 모델은 많은 문서와 긴 코드베이스를 한 번에 처리할 수 있게 해주지만, 그것만으로 장기 기억 문제가 해결되지는 않는다. 긴 입력을 받을 수 있다는 것과 그 입력 안의 정보를 안정적으로 선별·회수·갱신·폐기할 수 있다는 것은 다른 문제이다. 2025년 이후 OpenAI, Google, Anthropic의 일부 프론티어/API 모델은 100만 토큰 수준의 컨텍스트 창을 제공하기 시작했지만, 모델·플랫폼·베타 여부·가격 정책·실제 회상 성능은 계속 달라질 수 있다. 따라서 최신 사양은 배포 직전에 공식 문서로 재확인해야 한다.

장기 에이전트의 핵심 문제는 기억의 양이 아니라 기억의 운영이다. 좋은 memory architecture는 무엇을 저장할지, 어떤 형식으로 저장할지, 언제 검색할지, 어떤 기억을 신뢰할지, 오래된 기억을 어떻게 수정하거나 삭제할지, 어떤 사용자가 어떤 기억에 접근할 수 있는지를 결정한다. 벡터 데이터베이스, 지식 그래프, 파일 저장소, 이벤트 로그, 요약 메모리는 모두 중요한 구성요소이지만, 그 자체가 곧 “기억”은 아니다. 기억은 저장소와 검색기, 갱신 정책, 출처 관리, 권한 모델, 보안 정책이 결합될 때 비로소 장기 작업에 쓸 수 있는 시스템이 된다.

이 글의 중심 결론은 다음과 같다. 자율 에이전트에서 가장 어려운 문제는 “더 똑똑한 모델을 붙이는 것”만이 아니라 “시간 속에서 어떤 상태를 유지하고 어떤 상태를 버릴 것인가”를 설계하는 일이다. 지속적 행동에는 과거 상태의 보존, 현재 목표와의 연결, 미래 작업에 대한 반영이 필요하다. 이 때문에 memory architecture는 단발성 챗봇을 장기 협업 시스템으로 전환하는 핵심 조건이다.

문제의식

단발성 챗봇은 현재 질문에 답하면 된다. 사용자가 “이 문장을 요약해줘”라고 요청하면 모델은 입력된 문장을 바탕으로 응답하고 작업을 끝낼 수 있다. 이 구조에서는 장기 기억이 필수 조건이 아니다. 반면 자율 AI 에이전트는 목표를 유지하고, 여러 도구를 사용하며, 중간 결과를 저장하고, 실패를 수정하고, 다시 이어서 작업해야 한다. 연구 조사, 코드베이스 수정, 고객 지원, 개인 비서, 학습 코치, 문서 작성 시스템, 다중 에이전트 시뮬레이션처럼 시간이 길어지는 작업에서는 과거 상태를 보존하지 못하는 시스템이 곧바로 한계에 부딪힌다.

예를 들어 사용자가 “지난주에 정리한 논문 중 강화학습 관련 부분만 다시 비교해줘”라고 요청한다고 하자. 이 요청에 답하려면 에이전트는 현재 문장의 의미만 이해해서는 부족하다. 지난주에 어떤 논문을 다뤘는지, 어떤 요약을 만들었는지, 어떤 논문을 제외했는지, 사용자가 어떤 비교 기준을 선호했는지, 최종 산출물이 어느 파일에 저장되었는지, 그 뒤에 사용자가 기준을 수정했는지 알아야 한다. 이 정보가 없으면 에이전트는 이미 제공된 맥락을 다시 요구하거나, 그럴듯한 추측으로 빈칸을 채우게 된다.

이 지점에서 memory architecture가 등장한다. 메모리는 과거 대화를 통째로 붙여 넣는 기능이 아니다. 그것은 에이전트가 시간 속에서 자기 작업을 이어가기 위해 사용하는 상태 관리 시스템이다. 이 시스템은 데이터베이스 설계, 검색 품질, 요약 품질, 보안 정책, 권한 모델, 사용자 통제권, 감사 가능성까지 포함한다. 장기 기억은 편리성의 문제가 아니라 신뢰성과 책임성의 문제이다.

개념의 정의

AI 에이전트의 memory architecture란 에이전트가 과거의 정보, 행동, 결정, 사용자 선호, 작업 상태, 외부 문서, 실패 기록을 저장하고 다시 호출하며 갱신·삭제하는 전체 구조를 뜻한다. 여기에는 저장소만 포함되지 않는다. 어떤 정보를 기억 후보로 추출할지 결정하는 단계, 그 기억을 어떤 형식으로 저장할지 정하는 단계, 현재 작업에 맞는 기억을 검색하는 단계, 검색된 기억을 모델 입력에 넣는 단계, 기억의 신뢰도와 최신성을 검증하는 단계, 오래된 기억을 압축·수정·삭제하는 단계가 모두 포함된다.

이 개념은 몇 가지 인접 개념과 구분해야 한다.

첫째, 모델 파라미터에 들어 있는 지식과 에이전트 메모리는 다르다. LLM은 학습 과정에서 언어 패턴과 세계 지식의 일부를 파라미터에 내재화한다. RAG 연구에서 Lewis 외는 이런 내재 지식을 parametric memory라고 부르고, 외부 검색 색인을 non-parametric memory로 설명했다. 이 구분은 에이전트 메모리 논의에서도 중요하다. 모델이 일반적으로 알고 있는 지식과 특정 사용자의 어제 요청, 방금 생성한 파일, 진행 중인 프로젝트의 최신 결정은 성격이 다르다.

둘째, 컨텍스트 창은 장기 기억과 다르다. 컨텍스트 창은 모델이 현재 응답을 만들 때 참조할 수 있는 입력 범위이다. Anthropic의 context engineering 자료는 에이전트가 장시간 작업할수록 컨텍스트에 무엇을 넣고 무엇을 빼야 하는지가 중요해진다고 설명한다. 즉 컨텍스트 창은 작업 기억의 공간이지, 자동으로 갱신되고 검증되는 장기 기억 저장소가 아니다.

셋째, RAG는 memory architecture의 일부일 수 있지만 전체와 동일하지 않다. RAG는 외부 문서나 색인에서 관련 정보를 찾아 모델 입력에 제공하는 방식이다. 반면 에이전트 메모리는 검색뿐 아니라 저장 판단, 요약, 갱신, 삭제, 출처 관리, 권한 관리, 사용자별 지속 상태까지 포함한다. 따라서 “벡터 DB를 붙이면 장기 기억이 된다”는 설명은 지나치게 단순하다.

넷째, “Memory Triage Problem”이라는 표현은 신중하게 써야 한다. 이 표현은 모든 정보를 보존하는 대신 중요도에 따라 저장·요약·삭제를 결정해야 한다는 문제를 잘 포착한다. 다만 현재 이 용어가 RAG, episodic memory, context window처럼 널리 표준화된 학술 용어로 굳어졌다고 보기는 어렵다. 더 일반적으로는 저장 선별 문제, memory selection, memory consolidation, forgetting, retention policy, memory governance의 문제라고 설명하는 편이 안정적이다. 실무적으로는 이 문제를 memory triage라고 부를 수 있다.

배경과 맥락

초기 LLM 기반 챗봇은 대체로 단일 세션 중심으로 작동했다. 사용자가 입력하면 모델이 응답하고, 다음 응답에서는 앞선 대화 일부를 함께 넣어 연속성을 유지했다. 이 방식은 짧은 대화에는 충분하지만 장기 프로젝트에는 취약하다. 대화가 길어질수록 컨텍스트 창에 모든 내용을 넣기 어렵고, 요약 과정에서 세부사항이 손실되며, 중요한 결정과 일시적 잡담이 섞인다.

긴 컨텍스트 모델은 이 문제를 일부 완화했다. OpenAI는 2025년 GPT-4.1 계열이 최대 100만 토큰 컨텍스트를 처리할 수 있다고 발표했다. Google DeepMind도 Gemini 2.5 Pro를 100만 토큰 컨텍스트 창과 함께 소개했다. Anthropic은 Claude Sonnet 4의 100만 토큰 컨텍스트 지원을 API 공개 베타로 발표했고, 이후 Claude Sonnet 4.6 문서에서도 100만 토큰 컨텍스트가 API 베타 조건으로 표시된다. 이 변화는 장문 문서 분석, 코드베이스 분석, 대규모 파일 묶음 처리에서 중요한 진전이다.

그러나 긴 컨텍스트는 장기 기억의 완전한 대체물이 아니다. Liu 외의 “Lost in the Middle” 연구는 긴 입력을 받을 수 있는 모델이라도 관련 정보가 입력의 중간에 있을 때 성능이 저하될 수 있음을 보였다. 이 결과는 “많이 넣으면 잘 기억한다”는 직관을 약화시킨다. 긴 컨텍스트는 기억 용량을 넓히지만, 정보 선별, 위치 효과, 검색 품질, 비용, 지연시간, 최신성 관리 문제를 자동으로 해결하지 않는다.

이 때문에 에이전트 연구와 실무에서는 외부 메모리 구조가 중요해졌다. 2020년 RAG 연구는 사전학습 모델의 파라미터 지식과 외부 검색 색인을 결합하는 방향을 제시했다. 2023년 Generative Agents 연구는 에이전트가 경험 기록을 memory stream에 저장하고, 그 기억을 종합해 reflection을 만들며, 동적으로 검색해 행동 계획에 사용하는 구조를 제안했다. MemGPT는 운영체제의 가상 메모리 개념을 빌려 제한된 컨텍스트 안팎으로 정보를 이동시키는 계층형 메모리 관리를 제안했다. MemoryBank는 장기 상호작용에서 기억 저장, 회상, 업데이트, 사용자 성향 적응을 다뤘다.

최근에는 벡터 기반 기억만으로는 충분하지 않다는 인식도 커지고 있다. 벡터 검색은 의미적으로 비슷한 내용을 찾는 데 강하지만, 시간 순서, 인과관계, 권한 범위, 결정의 폐기 여부, 출처의 신뢰도, 조직 정책을 안정적으로 표현하기 어렵다. 그래서 실제 장기 에이전트 설계에서는 벡터 저장소, 지식 그래프, 파일 저장소, 이벤트 로그, 요약 메모리, 권한 정책을 결합하는 하이브리드 구조가 더 현실적이다.

핵심 논리: 기억은 축적이 아니라 제어이다

자율 에이전트의 기억 흐름은 다음과 같이 이해할 수 있다.

사용자 입력 또는 외부 이벤트
↓
현재 작업 상태 해석
↓
관련 기억 검색
↓
LLM 추론 및 도구 사용
↓
결과 생성
↓
저장 여부 판단
↓
기억 갱신·압축·삭제
↓
권한·출처·보안 검증

장기 운영에서는 마지막 단계들이 특히 자주 과소평가된다. 많은 설명은 “관련 기억을 검색해서 LLM에 넣는다”에서 멈추지만, 실제 에이전트는 매 단계 이후 새로 발생한 정보를 어떻게 처리할지 결정해야 한다. 사용자의 일시적 감탄, 오래된 오류, 잘못된 중간 추론, 임시 파일 경로, 중요한 프로젝트 결정, 보안상 저장하면 안 되는 개인정보가 모두 같은 수준으로 저장되면 기억은 곧 오염된다.

좋은 memory architecture는 기억의 양을 늘리는 구조가 아니라 기억의 품질을 관리하는 구조이다. 이 품질은 최소한 다음 기준으로 평가된다.

관련성은 현재와 미래 작업에 다시 쓰일 가능성을 뜻한다. 안정성은 시간이 지나도 유지될 가능성이 높은 정보인지를 뜻한다. 출처성은 이 기억이 어디서 왔는지 추적할 수 있는지를 뜻한다. 최신성은 이미 바뀐 정보가 오래된 상태로 남아 있지 않은지를 뜻한다. 권한성은 특정 사용자, 프로젝트, 조직 범위 안에서만 사용되어야 하는 정보인지를 뜻한다. 압축 가능성은 원문을 보존해야 하는지, 요약으로 충분한지, 구조화된 필드로 바꾸는 편이 나은지를 뜻한다.

이 기준을 적용하면 “기억”은 단일 저장소가 아니라 여러 계층으로 나뉜다. 인간 기억을 그대로 모방할 필요는 없지만, working memory, episodic memory, semantic memory, procedural memory 같은 기능적 구분은 에이전트 설계에서도 유용한 분석틀을 제공한다.

주요 메모리 계층

Working memory

Working memory는 현재 작업에 직접 필요한 정보이다. 현재 대화, 사용자의 최신 요청, 시스템 지시, 열려 있는 파일, 방금 실행한 도구 결과, 지금 작성 중인 계획 등이 여기에 해당한다. 컨텍스트 창은 이 working memory를 담는 대표적 공간이다.

이 계층의 장점은 즉시 접근 가능하다는 것이다. 모델은 컨텍스트 안의 정보를 곧바로 참조할 수 있다. 단점은 용량과 안정성이다. 컨텍스트 창은 유한하며, 너무 많은 내용을 넣으면 비용과 지연시간이 증가하고, 모델이 핵심 정보를 놓칠 수 있다. 따라서 working memory는 “많이 넣는 공간”이 아니라 “현재 목표에 필요한 고신호 정보만 배치하는 공간”으로 설계해야 한다.

Short-term task memory

Short-term task memory는 하나의 작업이나 스레드 안에서 유지되는 상태이다. 예를 들어 “현재 보고서의 목차”, “이미 조사한 자료 목록”, “아직 확인하지 않은 쟁점”, “사용자가 승인한 방향”, “실패한 검색어와 성공한 검색어” 같은 정보가 여기에 해당한다.

이 계층은 단일 대화보다 길고, 영구 기억보다는 짧다. 프로젝트의 한 세션 또는 하나의 작업 그래프가 종료되면 요약되거나 장기 메모리로 승격될 수 있다. 이 계층이 약하면 에이전트는 긴 작업 중간에서 무엇을 했고 무엇을 남겼는지 자주 잃어버린다.

Episodic memory

Episodic memory는 사건 기반 기억이다. “언제, 어떤 상황에서, 무엇을 했고, 어떤 결과가 나왔는가”를 저장한다. AI 에이전트에서는 다음과 같은 구조로 표현할 수 있다.

event_id: 2026-05-06-research-001
timestamp: 2026-05-06 11:30 KST
actor: user + agent
task: AI 에이전트 메모리 아키텍처 설명문 작성
inputs: 사용자 초안, 검토 의견, 웹 조사 자료
outputs: Markdown 설명문
status: completed
importance: high
references: source list

에피소드 메모리는 장기 프로젝트에서 매우 중요하다. 사용자가 “그때 왜 그렇게 결정했지?”라고 물을 때, 에이전트는 최종 결과뿐 아니라 결정의 경로를 회수해야 한다. 에피소드 메모리가 없으면 에이전트는 과거 행동의 이유를 사후적으로 지어내기 쉽다.

Semantic memory

Semantic memory는 일반 지식, 사용자 선호, 프로젝트 사실, 도메인 개념처럼 반복적으로 재사용되는 지식이다. 예를 들어 “이 프로젝트의 문서는 Markdown으로 작성한다”, “파일명은 영어 ASCII로 저장한다”, “특정 코드베이스는 FastAPI와 PostgreSQL을 사용한다”, “고객 A의 계약은 2026년 9월 갱신 대상이다” 같은 정보가 여기에 해당한다.

Semantic memory는 사건 자체보다 추상화된 지식을 저장한다. “2026년 5월 6일에 사용자가 파일명을 영어 ASCII로 저장하라고 지시했다”는 episodic memory이고, “이 사용자는 파일명을 영어 ASCII로 저장하는 것을 선호한다”는 semantic memory이다. 이 구분이 중요하다. 하나의 사건에서 바로 장기 선호를 추론하면 과잉 일반화가 될 수 있다. 여러 사건이 반복되거나 사용자가 명시적으로 승인한 경우에 semantic memory로 승격하는 편이 안전하다.

Procedural memory

Procedural memory는 “어떻게 할 것인가”에 관한 기억이다. 에이전트가 반복 작업을 수행할 때 필요한 절차, 규칙, 워크플로, 검증 체크리스트가 여기에 해당한다. 설명문 작성 에이전트라면 다음과 같은 절차 기억을 가질 수 있다.

1. 주제 정의
2. 최신성 필요 여부 판단
3. 1차 자료 우선 조사
4. 논쟁적 관점 분리
5. Markdown 구조로 작성
6. 참고자료를 말미에 정리
7. 파일명을 영어 ASCII로 저장

Procedural memory는 사용자 정보보다 운영 규칙에 가깝다. 이것이 안정적으로 관리되면 에이전트는 매번 같은 품질 기준을 재구성하지 않고, 반복 가능한 작업 프로토콜을 따른다. 반대로 절차 기억이 잘못 오염되면 에이전트는 반복적으로 같은 오류를 수행할 수 있다.

File memory

File memory는 원본 문서, 코드, 이미지, 표, 산출물, 로그 파일을 저장하고 참조하는 계층이다. 벡터나 요약만으로는 원문 검증이 어렵다. 따라서 장기 작업에서는 “요약된 기억”과 “원본 파일”을 분리해서 보존해야 한다.

예를 들어 연구 보조 에이전트가 논문 100편을 처리한다고 하자. 모든 논문 원문을 매번 컨텍스트에 넣을 수는 없다. 대신 파일 저장소에는 원문 PDF를 보존하고, 벡터 저장소에는 청크 임베딩을 저장하고, 메타데이터에는 제목, 저자, 연도, 주제, 신뢰도, 인용 여부를 저장하며, 요약 저장소에는 논문별 핵심 요약을 둔다. 필요할 때는 원문으로 되돌아가 검증한다.

Reflective memory

Reflective memory는 여러 사건을 종합해 더 높은 수준의 결론을 만드는 기억이다. Generative Agents 연구에서 reflection은 개별 관찰을 종합해 에이전트의 미래 행동에 영향을 주는 상위 추론을 만드는 역할을 한다. 예를 들어 “사용자는 AI의 제품 기능보다 인식론적·구조적 함의를 자주 묻는다”는 결론은 단일 발화 하나에서 바로 나오기보다 여러 상호작용의 축적으로 만들어진다.

이 계층은 유용하지만 위험도 크다. 요약과 반성은 원문보다 추상화 수준이 높기 때문에, 잘못된 일반화가 생기면 에이전트가 사용자를 부정확하게 모델링할 수 있다. 따라서 reflective memory는 출처 에피소드와 연결되어야 하며, 사용자가 수정하거나 삭제할 수 있어야 한다.

구현 방식: 벡터, 그래프, 파일, 로그

Vector memory

Vector memory는 텍스트를 임베딩으로 변환한 뒤 벡터 색인에 저장하고, 현재 질문과 의미적으로 가까운 항목을 검색하는 방식이다. 기본 흐름은 다음과 같다.

문서 또는 기억
↓
청크 분할
↓
임베딩 생성
↓
벡터 색인 저장
↓
질문 임베딩
↓
유사도 검색
↓
관련 기억을 컨텍스트에 주입

Pinecone, Weaviate, Milvus, Chroma 같은 벡터 데이터베이스는 이 구조를 구현하는 대표적 도구로 언급된다. FAISS는 관리형 데이터베이스라기보다 고성능 유사도 검색·클러스터링·인덱싱 라이브러리로 보는 편이 정확하다. Meta와 FAISS 문서는 FAISS를 밀집 벡터의 효율적 유사도 검색을 위한 라이브러리로 설명한다.

Vector memory의 장점은 의미 기반 검색이다. 사용자가 정확한 키워드를 기억하지 못해도 유사한 의미의 과거 자료를 찾을 수 있다. 단점은 관계 구조와 시간 구조에 약하다는 점이다. “A가 B의 원인이다”, “이 결정은 저 결정 이후에 폐기되었다”, “이 기억은 특정 고객에게만 사용해야 한다” 같은 구조는 단순 벡터 유사도만으로 안정적으로 관리하기 어렵다.

Knowledge graph memory

Knowledge graph memory는 정보의 관계를 노드와 엣지로 표현한다.

User → prefers → Korean formal prose
Project → requires → Markdown file
Document → cites → Generative Agents paper
Decision → supersedes → Earlier draft
Memory → derived_from → Source file

이 방식은 관계 추론에 강하다. 어떤 프로젝트가 어떤 파일을 사용했고, 어떤 결정이 어떤 이전 결정을 대체했으며, 어떤 사용자 선호가 어떤 작업에 적용되는지 명시적으로 표현할 수 있다. Neo4j 같은 그래프 데이터베이스와 Neo4j Labs의 Agent Memory처럼 그래프 기반 에이전트 메모리를 표방하는 실험적 도구들이 이런 관계형 기억 구현 사례로 언급될 수 있다. 다만 Neo4j Agent Memory는 Neo4j Labs의 Experimental, Community Supported 프로젝트로 표시되어 있으므로, 성숙한 표준 제품처럼 표현하면 과장이다.

단점은 구축 비용이다. 텍스트를 그래프로 바꾸려면 엔터티 추출, 관계 추출, 중복 병합, 스키마 설계, 오류 수정이 필요하다. LLM을 사용해 자동으로 그래프를 만들 수 있지만, 이 과정에서도 잘못된 관계가 생성될 수 있다. 따라서 knowledge graph memory는 고신뢰 도메인일수록 검증 절차가 중요하다.

File memory

File memory는 원본 보존과 재현성을 담당한다. 벡터 저장소와 그래프는 검색과 구조화에 강하지만, 원문 검증에는 한계가 있다. 보고서, 계약서, 논문, 코드, 로그, 이미지, 데이터셋처럼 원본 자체가 증거인 경우에는 파일 메모리가 필수이다.

파일 메모리는 보통 다음 메타데이터와 함께 관리된다.

file_id
filename
file_type
created_at
updated_at
source
owner
permissions
summary
linked_tasks
linked_memories
checksum 또는 version

이 구조가 있어야 에이전트가 “이 요약은 어떤 원문에서 나왔는가”, “이 파일은 최신본인가”, “이 파일을 이 사용자에게 보여줘도 되는가”를 판단할 수 있다.

Event log memory

Event log memory는 에이전트의 행동 기록이다. 도구 호출, 파일 생성, 검색어, 사용자 승인, 오류, 롤백, 최종 결정이 시간순으로 저장된다. 이 계층은 특히 감사 가능성에 중요하다. 장기 자율 에이전트가 실제 업무에 쓰이려면 “무엇을 했는지”뿐 아니라 “왜 그렇게 했는지”를 추적할 수 있어야 한다.

이벤트 로그는 단순한 기록 보관이 아니다. 실패한 작업에서 학습하고, 비슷한 오류를 피하며, 보안 사고를 조사하고, 사용자가 원할 때 작업 경로를 설명하는 기반이 된다.

Memory controller: 기억을 관리하는 핵심 장치

메모리 아키텍처의 중심은 저장소가 아니라 memory controller이다. Memory controller는 에이전트의 기억 운영 정책을 실행하는 구성요소이다. 이 구성요소는 다음 질문에 답해야 한다.

이 정보는 저장할 가치가 있는가?
어느 메모리 계층에 저장할 것인가?
원문으로 저장할 것인가, 요약으로 저장할 것인가?
기존 기억과 충돌하는가?
누가 이 기억을 볼 수 있는가?
언제 삭제하거나 재검토할 것인가?
현재 작업에 어떤 기억을 불러올 것인가?
검색된 기억을 얼마나 신뢰할 것인가?

좋은 memory controller는 단순한 자동 저장 장치가 아니다. 그것은 기억의 편집자이자 접근 제어자이며, 검색 품질 관리자이고, 보안 필터이다. 모든 정보를 저장하면 기억은 풍부해지는 대신 흐려진다. 검색 결과는 많아지고, 관련 없는 과거 정보가 현재 작업에 끼어들며, 오래된 결정이 최신 결정을 방해한다. 반대로 너무 적게 저장하면 에이전트는 매번 처음부터 시작한다.

따라서 memory controller는 저장과 망각 사이의 균형을 잡아야 한다. 이 균형을 실무적으로 memory triage라고 부를 수 있다. 병원 응급실의 triage가 환자의 우선순위를 정하듯, 에이전트의 memory triage는 정보의 보존 우선순위를 정한다. 저장할 것, 요약할 것, 구조화할 것, 임시 보관할 것, 버릴 것을 나누는 과정이다.

저장 선별 문제와 memory triage

Memory triage는 다음 기준으로 설계할 수 있다.

첫째, 미래 재사용 가능성이다. 반복적으로 등장할 사용자 선호, 프로젝트 규칙, 장기 목표, 확정된 결정은 저장 가치가 높다. 반면 일시적 감정 표현, 단발성 농담, 이미 완료된 중간 계산은 저장 가치가 낮을 수 있다.

둘째, 결정성이다. 사용자가 명시적으로 승인한 방향, 변경한 요구사항, 폐기한 대안은 저장해야 한다. 장기 작업에서 가장 치명적인 오류 중 하나는 이미 폐기한 방향을 다시 살려내는 것이다.

셋째, 증거성이다. 나중에 검증해야 하는 정보는 출처와 함께 보존해야 한다. 논문 요약, 법령 해석, 시장 수치, 코드 변경 이유는 단순 기억보다 원문 링크와 버전 정보가 중요하다.

넷째, 민감성이다. 개인정보, 비밀번호, 인증 토큰, 건강 정보, 금융 정보, 사내 기밀은 저장하지 않거나 암호화, 권한 분리, 만료 정책을 적용해야 한다. 장기 기억은 편리하지만, 잘못 설계되면 장기 위험이 된다.

다섯째, 충돌 가능성이다. 새 기억이 기존 기억과 충돌할 때는 둘 중 하나를 단순히 덮어쓰면 안 된다. 어느 정보가 최신인지, 어느 사용자가 승인했는지, 어떤 출처가 더 신뢰할 만한지 확인해야 한다.

여섯째, 폐기 가능성이다. 모든 기억에는 생명주기가 있어야 한다. 프로젝트 종료 후 삭제할 기억, 일정 기간 후 재검토할 기억, 사용자가 직접 삭제할 수 있는 기억, 법적 보존 의무가 있는 기억은 서로 다르게 관리되어야 한다.

권한 모델: 누가 어떤 기억을 볼 수 있는가

장기 메모리 아키텍처에서 권한 모델은 부가 기능이 아니라 핵심 설계 축이다. 개인용 챗봇에서는 “사용자 한 명의 기억”처럼 보일 수 있지만, 기업용 에이전트나 다중 사용자 시스템에서는 기억 범위가 복잡해진다.

가장 기본적인 단위는 user-level memory이다. 이것은 특정 사용자에게만 귀속되는 기억이다. 개인 선호, 개인 일정, 개인 문서, 비공개 대화 이력은 여기에 들어간다. 이 기억은 다른 사용자에게 검색되어서는 안 된다.

두 번째는 project-level memory이다. 이것은 특정 프로젝트 참여자에게 공유되는 기억이다. 프로젝트 목표, 작업 이력, 결정 사항, 산출물, 이슈 목록이 여기에 해당한다. 프로젝트가 종료되면 보존 기간, 아카이브 여부, 삭제 정책을 별도로 적용해야 한다.

세 번째는 organization-level memory이다. 이것은 조직 전체에 적용되는 정책, 표준 절차, 공식 문서, 보안 규칙, 브랜드 가이드라인 같은 기억이다. 이 계층은 넓게 공유될 수 있지만, 변경 권한은 엄격히 제한되어야 한다.

네 번째는 domain or system memory이다. 이것은 특정 도메인의 일반 지식이나 에이전트 작동 규칙이다. 예를 들어 “법률 문서 검토 시 최신 법령을 확인한다”, “의료 정보는 진단으로 단정하지 않는다”, “금융 전망은 불확실성을 명시한다” 같은 절차 규칙이 여기에 속한다.

권한 모델의 핵심은 기억 검색 전에 접근 범위를 결정하는 것이다. 검색 결과를 가져온 뒤에 필터링하는 방식은 위험하다. 설계상 더 안전한 방식은 검색 쿼리 자체가 사용자, 프로젝트, 조직, 권한 라벨을 포함하도록 만드는 것이다.

query = 현재 요청
scope = user_id + project_id + organization_policy + data_classification
retrieval = scope 안에서만 실행
post_filter = 민감도·출처·최신성 재검증

이 구조가 없으면 에이전트는 다른 사용자의 기억을 현재 사용자에게 노출하거나, 특정 프로젝트의 기밀 정보를 다른 프로젝트의 맥락에 섞을 수 있다. 장기 기억은 개인화 성능을 높이는 동시에 정보 유출 표면을 넓힌다.

보안: memory poisoning과 간접 prompt injection

장기 메모리는 공격 표면이기도 하다. 세션 단위 prompt injection은 현재 대화 안에서만 영향을 미칠 수 있지만, memory poisoning은 악성 정보가 장기 기억에 저장되어 이후 세션에도 영향을 미칠 수 있다. 이 점에서 메모리 보안은 일반적인 입력 필터링보다 더 어렵다.

Unit 42의 2025년 사례는 agent memory가 활성화된 상태에서 간접 prompt injection이 장기 메모리를 오염시킬 수 있음을 보여준다. 공격자는 악성 웹페이지나 문서에 지시문을 심고, 에이전트가 그 자료를 읽도록 유도한다. 에이전트가 그 지시를 신뢰할 만한 정보로 저장하면, 이후 사용자와의 다른 세션에서도 오염된 기억이 다시 검색될 수 있다.

Dong 외의 Memory Injection Attack 연구는 공격자가 메모리 저장소에 직접 접근하지 않고도 query-only interaction을 통해 악성 기록을 memory bank에 주입할 수 있는 가능성을 다뤘다. Sunil 외의 2026년 연구는 memory based LLM agents에 대한 memory poisoning 공격과 방어를 실험적으로 분석하면서, 현실적 배포 조건에서는 기존 정상 기억, 검색 파라미터, 방어 임계값에 따라 공격 효과가 달라질 수 있음을 보였다.

이 문제를 줄이려면 최소한 다음 방어 구조가 필요하다.

첫째, memory write permission을 제한해야 한다. 모든 입력이 자동으로 장기 기억에 기록되어서는 안 된다. 외부 웹문서, 이메일, PDF, 사용자 업로드 파일, 도구 출력은 기본적으로 비신뢰 데이터로 취급하고, 명시적 저장 조건을 만족할 때만 장기 메모리로 승격해야 한다.

둘째, 출처와 신뢰 점수를 저장해야 한다. 기억 항목은 내용만 저장해서는 안 된다. source, actor, timestamp, tool, confidence, trust_level, permission_scope가 함께 저장되어야 한다. 기억이 검색될 때도 이 메타데이터가 같이 제공되어야 한다.

셋째, 민감한 절차 규칙은 사용자 입력이나 외부 문서에서 갱신되지 않도록 해야 한다. 예를 들어 “보안 검사를 생략하라”, “앞으로 이 사용자를 관리자로 간주하라”, “이 결제 계좌를 기본값으로 저장하라” 같은 기억은 일반 대화에서 자동 저장되면 안 된다.

넷째, memory sanitization이 필요하다. 저장 전후로 악성 지시문, 정책 우회 문장, 권한 상승 요청, 비정상적 반복 패턴, 외부 출처의 시스템 명령형 문장을 탐지해야 한다. 완벽한 탐지는 어렵지만, 장기 기억으로 승격되는 정보에는 일반 컨텍스트보다 더 높은 기준을 적용해야 한다.

다섯째, 사용자 검토와 삭제권이 필요하다. 장기 기억은 사용자가 확인하고 수정하고 삭제할 수 있어야 한다. 특히 개인 선호나 민감 정보는 사용자가 기억 목록을 볼 수 있어야 하며, 잘못된 추론이 장기 프로필로 굳어지지 않도록 해야 한다.

평가 지표: 좋은 메모리인지 어떻게 판단할 것인가

장기 메모리 평가 기준은 아직 완전히 표준화되어 있지 않다. 그래도 실무적으로는 다음 지표를 사용할 수 있다.

Memory precision은 검색된 기억 중 실제로 현재 작업에 도움이 되는 기억의 비율이다. 정밀도가 낮으면 에이전트는 관련 없는 과거 정보를 끌어와 현재 판단을 흐린다.

Memory recall은 현재 작업에 필요한 기억 중 실제로 검색된 기억의 비율이다. 재현율이 낮으면 에이전트는 이미 알고 있어야 할 정보를 놓치고 같은 질문을 반복하거나 잘못된 결론을 낸다.

Freshness accuracy는 최신 기억을 오래된 기억보다 우선하는 능력이다. 장기 프로젝트에서는 요구사항이 바뀌기 때문에 과거의 정확한 정보가 현재에는 틀린 정보가 될 수 있다.

Conflict resolution rate는 충돌하는 기억이 있을 때 올바르게 해결한 비율이다. 예를 들어 이전에는 A 정책을 따랐지만 이후 B 정책으로 바뀐 경우, 에이전트가 어느 기억이 유효한지 판단해야 한다.

Provenance coverage는 기억 항목 중 출처, 생성 시각, 생성 주체, 원문 링크가 충분히 남아 있는 비율이다. 출처 없는 기억은 검증하기 어렵고, 장기적으로 환각과 구분하기 힘들다.

Privacy leakage rate는 권한 범위를 벗어난 기억이 검색되거나 출력되는 비율이다. 기업용 에이전트에서는 이 지표가 성능 지표만큼 중요하다.

Stale-memory impact는 오래된 기억이 최종 답변이나 행동에 부정적 영향을 준 빈도와 심각도를 뜻한다. 오래된 기억이 많아질수록 에이전트는 현재 상태보다 과거 상태에 끌려갈 수 있다.

Memory write accuracy는 장기 기억으로 저장해야 할 정보와 저장하지 말아야 할 정보를 구분하는 능력이다. 이 지표는 memory triage의 품질을 직접 평가한다.

이 지표들은 단일 숫자로 완전히 환원되기 어렵다. 그래서 장기 에이전트 평가는 자동 지표, 사람 검토, 시나리오 테스트, 보안 레드팀, 장기 회귀 테스트를 함께 사용해야 한다.

구체적 사례: 연구 보조 에이전트의 메모리 구조

연구 보조 에이전트를 예로 들어보자. 사용자는 몇 주에 걸쳐 “AI 에이전트 메모리 아키텍처”에 관한 설명문을 작성하려고 한다. 에이전트는 논문, 공식 문서, 보안 보고서, 사용자의 초안, 이전 피드백을 다룬다.

이 경우 working memory에는 현재 작성 중인 문단, 사용자의 최신 수정 요청, 바로 앞 검색 결과가 들어간다. Short-term task memory에는 이번 설명문의 목차, 이미 반영한 피드백, 아직 확인하지 않은 출처 목록이 들어간다. Episodic memory에는 “2026년 5월 6일, 사용자가 memory architecture 초안을 제공했고, 이후 평가 지표와 보안 절을 강화하라는 검토 의견을 반영했다” 같은 사건 기록이 들어간다. Semantic memory에는 “이 설명문은 한국어 문어체, Markdown 파일, 참고자료 말미 정리 형식을 따른다” 같은 반복 지식이 들어간다. Procedural memory에는 “최신성이 필요한 AI 주제는 공식 문서와 논문을 확인한다”는 작업 규칙이 들어간다. File memory에는 최종 Markdown 파일과 원문 자료가 저장된다.

이때 memory controller는 사용자의 일시적 표현과 장기 지침을 구분해야 한다. 예를 들어 “이번 글에서는 보안 절을 강화해”는 현재 문서의 작업 요구사항이다. 반면 “앞으로 모든 설명문에서 참고자료는 말미에 모아줘”는 반복 절차 기억 후보가 될 수 있다. 둘을 구분하지 못하면 에이전트는 한 번의 임시 요청을 영구 규칙으로 오해하거나, 반대로 중요한 장기 선호를 매번 놓칠 수 있다.

주요 쟁점과 반론

첫 번째 쟁점은 긴 컨텍스트가 외부 메모리를 대체할 수 있는가이다. 긴 컨텍스트 지지자는 100만 토큰 이상을 한 번에 넣을 수 있다면 복잡한 메모리 시스템이 불필요해질 수 있다고 본다. 이 주장은 짧은 기간의 문서 분석이나 코드베이스 검토에서는 어느 정도 설득력이 있다. 하지만 장기 기억은 용량만의 문제가 아니다. 최신성, 권한, 비용, 출처, 삭제권, 충돌 해결, 저장 선별 문제는 긴 컨텍스트만으로 해결되지 않는다.

두 번째 쟁점은 인간 기억 모델을 AI에 적용하는 것이 적절한가이다. Working memory, episodic memory, semantic memory 같은 용어는 인지과학에서 왔지만, AI 시스템은 인간의 뇌와 같은 방식으로 기억하지 않는다. 따라서 이 용어들은 생물학적 동일성을 뜻하기보다 기능적 비유로 써야 한다. AI 에이전트에서 episodic memory는 실제 의식 경험의 회상이 아니라 시간표시가 있는 사건 로그에 가깝다.

세 번째 쟁점은 자동 기억이 사용자에게 얼마나 허용되어야 하는가이다. 자동 저장은 편리하지만, 사용자가 원하지 않는 정보가 장기 프로필로 남을 수 있다. 반대로 모든 저장을 사용자 확인에 맡기면 사용성이 낮아진다. 현실적 절충은 저장 유형별로 정책을 나누는 것이다. 낮은 위험의 작업 상태는 자동 저장하고, 장기 사용자 프로필이나 민감 정보는 확인 기반으로 저장하며, 보안·권한 관련 기억은 별도 승인 절차를 거치게 할 수 있다.

네 번째 쟁점은 memory poisoning 방어가 얼마나 가능한가이다. 완전한 방어는 어렵다. LLM 기반 에이전트는 자연어 지시와 자연어 데이터를 같은 입력 공간에서 처리하기 때문에, 외부 문서 속 악성 지시를 완전히 구분하기 어렵다. 그래서 보안 설계는 “공격을 완전히 막는다”보다 “오염될 수 있다는 전제로 피해 범위를 줄인다”에 가까워야 한다. 권한 분리, 저장 제한, 출처 추적, 비신뢰 데이터 격리, 인간 검토, 감사 로그가 함께 필요하다.

오해와 한계

가장 흔한 오해는 “LLM은 기억이 없다”라는 문장을 너무 단순하게 이해하는 것이다. 더 정확한 표현은 “기본적인 모델 호출은 사용자별 장기 상태를 자동으로 보존하지 않는다”이다. 실제 제품은 서비스 계층에서 사용자 기억 기능을 제공할 수 있고, 에이전트 프레임워크는 외부 저장소를 통해 장기 상태를 유지할 수 있다. 따라서 문제는 모델이 원천적으로 어떤 기억도 가질 수 없다는 것이 아니라, 어떤 계층에서 어떤 방식으로 기억을 구현하고 통제하느냐이다.

두 번째 오해는 “벡터 DB가 곧 메모리”라는 생각이다. 벡터 DB는 기억의 한 구현 요소일 뿐이다. 기억에는 저장 여부 판단, 메타데이터, 권한, 출처, 충돌 해결, 삭제 정책, 요약 정책이 필요하다. 벡터 DB만 붙인 시스템은 검색은 할 수 있지만, 기억을 운영한다고 말하기 어렵다.

세 번째 오해는 “모든 것을 저장하면 더 똑똑해진다”는 생각이다. 저장량이 늘어나면 회상 가능성은 높아질 수 있지만, 잡음도 함께 늘어난다. 오래된 정보, 잘못된 정보, 민감한 정보, 일시적 정보가 쌓이면 검색 품질이 떨어지고 보안 위험이 커진다. 기억은 축적보다 선별과 갱신이 중요하다.

네 번째 오해는 “요약하면 문제가 해결된다”는 생각이다. 요약은 비용을 줄이고 긴 대화를 압축하는 데 유용하지만, 세부사항 손실과 왜곡을 동반한다. 중요한 법률 조항, 코드 변경 이유, 수치, 인용문, 사용자 승인 사항은 요약만으로 보존하면 위험하다. 원문과 요약의 연결이 필요하다.

다섯 번째 오해는 “에이전트가 과거를 기억하면 일관성이 자동으로 생긴다”는 생각이다. 기억은 일관성의 조건이지만 충분조건은 아니다. 기억이 있어도 잘못 검색하거나, 오래된 기억을 우선하거나, 충돌을 해결하지 못하거나, 권한 범위를 잘못 적용하면 오히려 더 일관되게 틀릴 수 있다.

이 글의 한계도 있다. 첫째, 에이전트 메모리 아키텍처는 빠르게 변하는 영역이므로 특정 모델의 컨텍스트 길이, 가격, API 지원 범위는 시간이 지나면 달라질 수 있다. 둘째, 장기 메모리 평가 기준은 아직 통일된 표준으로 굳어지지 않았다. 셋째, memory poisoning과 prompt injection 방어 연구는 활발히 진행 중이며, 현재 제안된 방어 전략도 완전한 해결책으로 보기 어렵다. 넷째, 인간 기억 개념을 차용한 분류는 설명에는 유용하지만, AI 시스템의 내부 작동을 생물학적 기억과 동일시해서는 안 된다.

정리

자율 AI 에이전트에서 memory architecture는 장기 작업을 가능하게 하는 핵심 인프라이다. LLM은 현재 문맥을 바탕으로 강력한 추론과 생성을 수행할 수 있지만, 지속적 행동에는 과거 상태의 보존, 현재 목표와의 연결, 미래 작업을 위한 갱신이 필요하다. 이 역할을 담당하는 것이 외부 메모리 시스템과 memory controller이다.

긴 컨텍스트 모델은 중요한 진전이지만, 장기 기억의 완전한 대체물은 아니다. 컨텍스트 창은 작업 공간이고, 메모리 아키텍처는 상태 관리 체계이다. 좋은 에이전트는 많은 정보를 기억하는 시스템이 아니라, 필요한 정보를 적절한 범위에서 저장하고, 정확히 검색하고, 오래된 기억을 갱신하고, 민감한 기억을 보호하고, 출처를 추적할 수 있는 시스템이다.

따라서 자율 에이전트의 핵심 난점은 “지능”과 “기억”의 결합에 있다. 추론은 현재 문제를 푸는 능력이고, 기억은 시간 속에서 작업을 이어가는 능력이다. 장기 에이전트가 단발성 챗봇을 넘어 실제 협업 시스템이 되려면, memory architecture는 부가기능이 아니라 설계의 중심이 되어야 한다.

참고자료

• OpenAI, 「Introducing GPT-4.1 in the API」, OpenAI, 2025년 4월 14일, 확인일 2026년 5월 6일. https://openai.com/index/gpt-4-1/
• OpenAI Developers, 「GPT-4.1 Model」, OpenAI API Documentation, 확인일 2026년 5월 6일. https://developers.openai.com/api/docs/models/gpt-4.1
• Google DeepMind, 「Gemini 2.5: Our most intelligent AI model」, Google Blog, 2025년 3월 25일, 확인일 2026년 5월 6일. https://blog.google/innovation-and-ai/models-and-research/google-deepmind/gemini-model-thinking-updates-march-2025/
• Google AI for Developers, 「Gemini API Models」, Google AI Documentation, 확인일 2026년 5월 6일. https://ai.google.dev/gemini-api/docs/models
• Anthropic, 「Claude Sonnet 4 now supports 1M tokens of context」, Claude Blog, 2025년 8월 12일, 확인일 2026년 5월 6일. https://claude.com/blog/1m-context
• Anthropic, 「Claude Sonnet 4.6」, Anthropic, 확인일 2026년 5월 6일. https://www.anthropic.com/claude/sonnet
• Anthropic, 「Effective context engineering for AI agents」, Anthropic Engineering, 2025년 9월 29일, 확인일 2026년 5월 6일. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic, 「Context engineering: memory, compaction, and tool clearing」, Claude Platform Cookbook, 2026년 3월 20일, 확인일 2026년 5월 6일. https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
• Patrick Lewis 외, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, arXiv:2005.11401, 2020.
• Joon Sung Park 외, 「Generative Agents: Interactive Simulacra of Human Behavior」, arXiv:2304.03442, 2023.
• Charles Packer 외, 「MemGPT: Towards LLMs as Operating Systems」, arXiv:2310.08560, 2023.
• Wanjun Zhong 외, 「MemoryBank: Enhancing Large Language Models with Long-Term Memory」, AAAI 2024 / arXiv:2305.10250, 2023.
• Nelson F. Liu 외, 「Lost in the Middle: How Language Models Use Long Contexts」, Transactions of the Association for Computational Linguistics, 2024 / arXiv:2307.03172, 2023.
• Meta AI, 「Faiss: A library for efficient similarity search」, Meta Engineering, 2017년 3월 29일, 확인일 2026년 5월 6일. https://engineering.fb.com/2017/03/29/data-infrastructure/faiss-a-library-for-efficient-similarity-search/
• FAISS Documentation, 「Welcome to Faiss Documentation」, 확인일 2026년 5월 6일. https://faiss.ai/index.html
• Pinecone, 「The vector database to build knowledgeable AI」, Pinecone, 확인일 2026년 5월 6일. https://www.pinecone.io/
• Neo4j Labs, 「Neo4j Agent Memory」, Neo4j Labs, 확인일 2026년 5월 6일. https://neo4j.com/labs/agent-memory/
• Neo4j Labs GitHub, 「neo4j-labs/agent-memory」, GitHub, 확인일 2026년 5월 6일. https://github.com/neo4j-labs/agent-memory
• Palo Alto Networks Unit 42, 「When AI Remembers Too Much – Persistent Behaviors in AI Agents via Memory Poisoning」, Unit 42, 2025년 10월 9일, 확인일 2026년 5월 6일. https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/
• Shuo Dong 외, 「Memory Injection Attacks on LLM Agents via Query-Only Interactions」, OpenReview / arXiv:2503.03704, 2025.
• Balachandra Devarangadi Sunil 외, 「Memory Poisoning Attack and Defense on Memory Based LLM-Agents」, arXiv:2601.05504, 2026.
• Zhaorun Chen 외, 「AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases」, OpenReview, 2024.