Foundation Model Engineering

16.4 에이전트를 위한 장기 메모리 (Long-term Memory for Agents)

메모리가 없는 에이전트는 잠깐은 유능해 보일 수 있어도 시간이 지나면 금방 한계를 드러냅니다. 현재 step은 처리할 수 있지만, 사용자와의 관계를 이어 가거나, 이전 결정을 재사용하거나, 유용한 운영 규칙을 축적하지 못합니다. 그래서 장기 메모리가 중요합니다. “영속 메모리”가 멋져 보여서가 아니라, 매 세션이 0에서 시작하면 애초에 불가능한 작업이 많기 때문입니다.

이를 실제 업무에 비유하면 더 쉽습니다. 장시간 이어진 장애 대응에 중간 투입된 엔지니어는 첫 한 시간을 맥락 복원에 씁니다. 무엇이 바뀌었는지, 무엇을 이미 시도했는지, 어떤 제약이 아직 살아 있는지를 다시 파악해야 하기 때문입니다. 메모리 시스템은 바로 이 복원 비용을 줄이기 위해 존재합니다.

개발자 관점에서 이 장의 실질적인 가치는 더 분명합니다. 코딩 에이전트는 저장소의 관례를 기억할 수 있고, 지원 에이전트는 오래 유지되는 고객 선호를 기억할 수 있으며, 운영 에이전트는 어떤 복구 절차가 이미 실패했는지를 기억할 수 있습니다. 단기 컨텍스트와 장기 메모리가 분리되지 않으면, 시스템은 맥락 복원 비용을 반복해서 지불하게 됩니다.


1. 실무적인 메모리 계약

벡터 데이터베이스나 그래프 저장소를 고르기 전에, 먼저 메모리 레코드가 무엇을 담아야 하는지 정의하는 편이 좋습니다. 유용한 장기 메모리 항목은 보통 다음 정보를 가집니다.

  • content: 사실, 사건, 선호, 규칙 그 자체
  • type: 사실, 에피소드, 선호, 절차 중 무엇인지
  • source: 사용자 입력인지, 툴 결과인지, 모델 추론인지, 다른 에이전트에서 온 것인지
  • confidence: 얼마나 강하게 믿어야 하는지
  • last updated: 마지막으로 갱신된 시점
  • retention class: 얼마나 오래 보관할지, 삭제 가능해야 하는지

사소해 보이지만, 이 차이가 toy memory와 production memory를 가르는 경우가 많습니다.


2. 메모리는 벡터 저장소 하나로 끝나지 않는다

가장 단순한 에이전트 메모리는 과거 대화를 통째로 저장하고 나중에 retrieval로 꺼내는 방식입니다. 출발점으로는 괜찮지만, 그것만으로는 부족한 경우가 많습니다.

현재의 에이전트 시스템은 보통 최소 세 층을 구분해야 합니다.

  • working memory: 현재 컨텍스트 윈도우
  • episodic memory: 과거의 특정 사건, 행동, 결과
  • semantic / procedural memory: 비교적 안정적인 사실과 재사용 가능한 규칙

엔지니어링 과제는 정보가 어느 층에 들어가야 하는지, 그리고 언제 다른 층으로 이동해야 하는지를 정하는 데 있습니다.


3. 쓰기, 관리, 읽기

실용적인 메모리 루프는 세 부분으로 나눌 수 있습니다.

  1. Write: 무엇을 저장할지 결정한다
  2. Manage: 중복 제거, 업데이트, 압축, 만료 처리를 한다
  3. Read: 필요한 순간에 필요한 메모리를 가져온다

말로는 단순하지만, 실제 실패는 거의 여기서 발생합니다.

자주 보는 write 오류:

  • 너무 많은 것을 저장한다
  • 확신이 낮은 추론을 사실처럼 저장한다
  • 임시 상태를 장기 진실처럼 기록한다

자주 보는 read 오류:

  • 대충 비슷하지만 방해가 되는 메모리를 끌어온다
  • 세상이 바뀌었는데도 오래된 사실을 다시 쓴다
  • 사용자가 준 사실과 에이전트가 추론한 가정을 같은 수준으로 취급한다

4. 어떤 메모리 substrate를 쓸 것인가

Vector Memory

벡터 검색은 좋은 출발점입니다. 의미적으로 비슷한 내용 회수, 대화 요약, 자유로운 history search에는 잘 맞습니다.

Structured Memory

관계가 더 중요한 작업에서는 가벼운 구조가 도움이 됩니다.

  • 안정적인 사실을 위한 key-value store
  • 사건 흐름을 위한 event log
  • 개체와 관계를 위한 graph

모든 에이전트가 거대한 knowledge graph를 가져야 한다는 뜻은 아닙니다. 다만 “사실”, “사건”, “규칙”을 모두 같은 text chunk로 저장하는 방식보다, 성격을 나눠서 다루는 쪽이 보통 메모리 품질이 좋습니다.

Latent 또는 Model-Internal Memory

연구 쪽에서는 데이터베이스보다 모델의 hidden-state dynamics에 가까운 메모리 방향도 탐색합니다. 흥미로운 주제이지만, 지금 실제로 많이 배포되는 retrieval 기반 메모리 시스템에 비하면 운영 성숙도는 아직 낮은 편입니다.

최근의 HippoRAG 같은 연구는 그래프 구조의 메모리가 iterative retrieval보다 더 낮은 비용으로 multi-hop recall을 높일 수 있음을 보여 줍니다 [3]. 핵심 교훈은 모든 에이전트가 그래프를 가져야 한다는 뜻이 아니라, 메모리 substrate가 과업에 맞아야 한다는 점입니다. 의미적 회수, 사건 재생, 관계형 추론은 서로 다른 문제입니다.

최근 메모리 연구가 실제로 보여 주는 것

영향력 있는 연구들은 하나의 정답 아키텍처를 제시하기보다, 서로 다른 설계 교훈을 던져 줍니다.

  • Generative Agents 는 자연어 이벤트 로그를 전부 저장하고, recency, relevance, importance 기준으로 꺼내며, 그 위에 상위 수준의 reflection summary를 쌓습니다 [1]. 여기서의 교훈은 raw event 저장과 reflective abstraction이 서로 다른 메모리 연산이라는 점입니다.
  • MemoryBank 는 에빙하우스 망각 곡선에서 영감을 받아, 시간이 지나면 약해지고 중요한 기억은 강화되는 forgetting-and-reinforcement 메커니즘을 넣습니다 [4]. 즉, 장기 메모리 품질은 retrieval만이 아니라 retention policy에도 크게 좌우됩니다.
  • MemGPT 는 메모리를 활성 컨텍스트와 느린 외부 저장소로 나뉜 계층 구조로 봅니다 [2]. 여기서의 교훈은 메모리가 단순 저장 문제가 아니라, 무엇을 working set에 남기고 무엇을 바깥으로 내보낼지 정하는 스케줄링 문제이기도 하다는 점입니다.
  • HippoRAG 는 반복적인 retrieve-and-rerank 루프를 늘리지 않고도 graph-structured memory가 multi-hop recall을 도울 수 있음을 보여 줍니다 [3]. 즉, 관계형 추론은 의미적 유사도 검색과는 다른 substrate를 요구할 수 있습니다.

5. 진짜 어려운 문제: 오래된 정보, 출처, 프라이버시

메모리의 가장 어려운 문제는 정보를 저장하는 것 자체가 아닙니다. 저장된 정보가 언제부터 미래 행동을 지배하지 않아야 하는지를 아는 것입니다.

Staleness

사용자가 예전에 “나는 뉴욕에서 일한다”고 말했다가 나중에 “방금 시카고로 이사했다”고 말하면, 시스템은 현재의 진실을 갱신해야 합니다. 그렇다고 과거 기록 자체를 완전히 지우는 것도 항상 바람직하지는 않습니다.

Source Tracking

메모리에는 provenance가 필요합니다. 사용자가 직접 준 정보, 모델이 추론한 정보, 다른 에이전트가 남긴 정보는 같은 신뢰도로 다뤄서는 안 됩니다.

Privacy

메모리 시스템이 성공할수록 프라이버시 시스템에 가까워집니다. 보관 기간, 삭제 경로, 저장 위치, 누가 읽을 수 있는지에 대한 명확한 정책이 필요합니다.


6. 인터랙티브 시각화: 메모리 통합

아래 시각화는 consolidation의 감각을 보여 줍니다. 모든 임시 관찰을 같은 장기 저장소에 넣는 것이 아니라, 정보의 성격에 따라 적절한 위치로 보내야 메모리 품질이 올라갑니다.

Asynchronous Memory Consolidation

Working Memory (Context)
"I am moving my Acme Corp data pipeline to Snowflake. Always use Python 3.11."
Graph Memory (Entities)
Waiting for entities...
Vector Memory (Semantic)
Waiting for embeddings...
Procedural Memory (Rules)
Waiting for instructions...

7. 핵심 정리

에이전트의 장기 메모리는 결국 LLM 바깥에 놓인 retrieval 및 데이터 관리 문제로 보는 편이 가장 현실적입니다. 벡터 저장소는 도움이 되지만, 프로덕션 수준의 메모리는 정책이 핵심입니다. 무엇을 저장할지, 어떻게 갱신할지, 확신도를 어떻게 추적할지, 언제 잊어야 할지를 함께 설계해야 합니다.

다음 절에서는 메모리에서 신뢰성으로 넘어갑니다. 에이전트 루프가 잘못됐을 때 어떻게 복구할지, 그리고 이런 시스템을 운영 가능하게 만드는 guardrail은 무엇인지 살펴봅니다.


Quizzes

Quiz 1: 과거 대화를 벡터 데이터베이스에 모두 저장하는 것만으로는 에이전트 메모리에 왜 보통 부족한가요? 실제 메모리 시스템은 임시 컨텍스트, 과거 사건, 안정적인 사실, 재사용 가능한 규칙을 구분해야 하기 때문입니다. 모든 것을 같은 text chunk로 취급하면 retrieval이 noisy해지고 update logic도 약해집니다.

Quiz 2: 오래된 정보(staleness)가 메모리에서 특히 어려운 이유는 무엇인가요? 현재 믿어야 할 사실을 갱신하면서도, 과거에 그런 정보가 존재했다는 기록은 필요에 따라 남겨야 하기 때문입니다. 단순 저장 문제가 아니라 업데이트와 우선순위의 문제입니다.

Quiz 3: 메모리 항목에 source tracking이 필요한 이유는 무엇인가요? 사용자 입력, 다른 에이전트의 기록, 모델 자신의 추론은 신뢰도가 다르기 때문입니다. provenance가 있어야 추측이 사실처럼 취급되는 일을 줄일 수 있습니다.

Quiz 4: 메모리 설계가 곧 프라이버시 문제로 이어지는 이유는 무엇인가요? 장기 사용자 정보를 잘 저장하고 잘 찾아낼수록, 보관 기간, 삭제 정책, 접근 권한, 저장 위치 같은 프라이버시 정책도 함께 설계해야 하기 때문입니다.


References

  1. Park, J. S., et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. arXiv:2304.03442.
  2. Packer, C., et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.
  3. Gutiérrez, B. J., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2025). HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. arXiv:2405.14831.
  4. Zhong, W., et al. (2023). MemoryBank: Enhancing Large Language Models with Long-Term Memory. arXiv:2305.10250.