본문 바로가기
RAG/Memory

Agentic Memory

by AtoN 2025. 10. 31.

Agentic Memory

Agentic Memory는 LLM 자체에 영구 기억이 생긴다는 뜻이 아니라, 에이전트 시스템이 과거의 상태와 정보를 저장하고 필요한 시점에 다시 모델의 컨텍스트로 가져오는 구조입니다. LLM이 현재 응답에서 직접 사용할 수 있는 것은 주어진 context 안의 정보이므로, 이전 대화나 사용자 선호, 과거 작업 결과를 이후에도 활용하려면 runtime이나 외부 저장소가 이를 보존하고 다시 제공해야 합니다.

여기서 context window, short-term state, long-term memory를 같은 것으로 보면 설계가 꼬입니다. Context window는 현재 모델 호출이 실제로 읽는 입력 범위이고, short-term state는 한 thread나 workflow 안에서 이어지는 대화와 작업 상태입니다. Long-term memory는 특정 thread를 넘어 이후의 대화나 작업에서도 다시 사용하기 위해 별도로 저장한 정보입니다.

실제 memory system의 핵심은 많이 저장하는 것이 아니라 무엇을 기억하고, 언제 저장하며, 어떤 상황에서 다시 꺼내고, 기존 기억을 언제 수정하거나 잊을 것인지 결정하는 데 있습니다. 오래되거나 잘못된 정보가 long-term memory에 남으면 이후 여러 session에 반복해서 주입될 수 있고, 반대로 너무 많은 정보를 저장하면 필요한 memory를 제대로 찾지 못하거나 불필요한 context만 늘어날 수 있습니다.

이 글에서는 short-term memory와 long-term memory의 범위를 먼저 나누고, 장기 기억을 semantic, episodic, procedural memory로 분류하는 관점을 살펴봅니다. 이어서 memory를 생성하고 검색하고 갱신하거나 삭제하는 생애주기와, 실제 agent에서 memory의 품질을 어떻게 평가할 것인지까지 연결해서 봅니다.

1장. 모델 context와 시스템 memory를 구분한다

상태 없는 LLM. API 호출 하나하나가 독립적이라 모델은 이전 호출을 기억하지 못하고 가중치도 안 바뀝니다. 어제 얘기했던 그것이 통하는 것은 그 대화를 이번 요청에 다시 실어 보냈기 때문입니다.

정확한 표현은 LLM이 기억하는 것이 아니라 시스템이 기억해서 매번 다시 알려주는 것입니다.

컨텍스트 창은 현재 모델 호출이 읽는 token 범위입니다. 반면 memory는 runtime이 별도 state/store에 유지하는 정보와 그 retrieval/update 정책을 뜻합니다. server-side conversation state처럼 제공자가 상태를 보관하는 API도 있지만, 모델 weight 자체가 대화마다 영구 갱신된다는 뜻은 아닙니다.

메모리 시스템의 실제 일은 저장소에서 무엇을 골라 이번 컨텍스트 창에 넣을지 정하는 것입니다. 즉 메모리는 컨텍스트 창을 채우는 공급자입니다.

그냥 다 넣으면 안 되는 이유. 컨텍스트가 100만 토큰까지 늘어난 지금도 답은 안 된다는 것입니다. 이유가 셋입니다.

① 비용이 선형으로 늘어난다
   입력이 길어질수록 prefill 계산과 attention 비용이 증가한다
   Prompt Caching이 이를 완화하지만
   히스토리 앞부분이 바뀌면 캐시가 무효화된다

② 지연이 늘어난다
   입력 길이는 TTFT를 늘리는 주요 요인 중 하나다

③ 중간을 잘 못 쓴다
   긴 컨텍스트에서 관련 정보가 앞이나 뒤에 있을 때보다
   중간에 있을 때 성능이 눈에 띄게 떨어진다

즉 컨텍스트에 있다고 해서 모델이 실제로 쓴다는 보장이 없습니다.

무엇을 버릴지의 문제. 넣을 수 있는 자리가 유한하고 넣어도 다 쓰이지 않는다면, 메모리 설계의 본질은 무엇을 남기고 무엇을 버릴지입니다. 저장 용량은 사실 병목이 아니고 선택이 병목입니다.

2장. 한 thread 안에서 이어지는 short-term state

단기 메모리는 현재 thread나 workflow를 이어가기 위한 상태입니다. 메시지 이력, tool 결과, 계획 상태처럼 이번 작업의 연속성에 필요한 정보가 들어갑니다. LangGraph 계열에서는 checkpoint를 통해 thread state를 지속화할 수 있어 프로세스 재시작 뒤에도 이어질 수 있으므로 단기 = RAM에만 존재라는 뜻은 아닙니다.

단기 메모리에 담기는 것입니다.

사용자 메시지와 모델 응답
도구 호출과 그 결과
중간 추론 흔적
현재 태스크의 진행 상태
이번 턴에서만 필요한 임시 값

전부 지금 이 작업에 종속되고 다음 대화에서는 대부분 쓸모가 없습니다.

관리 전략 넷. 전체 유지는 모든 메시지를 그대로 이어붙입니다. 정보 손실이 없고 구현이 없다시피 하지만 길어지면 1장에서 본 세 문제를 그대로 맞습니다. 짧은 세션이면 이것이 정답이고 과잉 설계할 필요가 없습니다.

슬라이딩 윈도우는 최근 N개 메시지만 남깁니다. 컨텍스트 크기가 상한을 갖지만 앞부분이 통째로 사라져서, 아까 말한 조건이 윈도우 밖으로 나가면 에이전트가 갑자기 맥락을 잃습니다. 개선 형태로 시스템 프롬프트와 첫 사용자 요청은 고정으로 남기고 중간만 잘라냅니다.

요약은 오래된 부분을 LLM으로 압축합니다. 정보를 어느 정도 살리면서 길이를 줄이지만 요약 호출 비용과 지연이 추가되고 되돌릴 수 없습니다.

선택적 유지는 메시지 종류별로 다르게 다룹니다.

메시지 종류 처리
사용자 요청 전부 유지
모델의 최종 응답 유지
중간 추론 버린다
도구 호출 결과 최근 것만 원문, 나머지는 요약

실무에서 가장 효과가 큰 전략입니다. 컨텍스트를 잡아먹는 것은 대개 도구 결과이기 때문입니다.

요약의 함정. 요약은 손실 압축이고 무엇이 중요한지 판단하는 주체가 LLM입니다. 그 판단이 틀리면 되돌릴 수 없습니다.

전형적인 실패는 사용자가 예산을 500만원으로 제한했다는 사실이 요약에서 빠지는 것입니다. 이후 에이전트가 예산을 무시한 제안을 계속 하는데, 요약본만 봐서는 무엇이 빠졌는지 알 수 없습니다.

완화 방법은 원문을 별도 저장소에 남기고 요약만 컨텍스트에 올려 필요할 때 원문을 되찾을 수 있게 하는 것입니다. 즉 요약을 버리기가 아니라 옮기기로 만듭니다.

그리고 제약 조건과 숫자, 사용자가 명시적으로 거부한 것처럼 반드시 살릴 항목을 요약 프롬프트에 명시합니다.

도구 결과 다루기. 단기 메모리에서 가장 실질적인 문제입니다. 검색 도구 하나가 문서 10개를 반환하면 그것만으로 수천 토큰인데, 그 원문이 다음 턴에도 필요한 경우는 드뭅니다. 대개는 거기서 뽑아낸 결론 한 줄만 있으면 됩니다.

① 도구 결과를 즉시 요약해 요약본만 히스토리에 남긴다
② 원문은 외부 저장소에 두고 참조 ID 만 남긴다
③ 오래된 도구 결과는 결과 생략됨으로 치환한다
④ 같은 도구를 반복 호출했으면 마지막 것만 남긴다

체크포인터. 단기 메모리를 프로세스 밖에 저장하는 장치입니다. 노드 실행마다 상태를 DB에 저장하고 thread_id 로 격리합니다. 그래서 서버가 재시작돼도 대화가 이어지고, 여러 대화를 동시에 격리해 굴리며, 중간에 사람이 개입하고 재개할 수 있습니다.

주의할 것은 체크포인터가 지속을 주지 선택을 주지 않는다는 점입니다. 저장했다고 컨텍스트 문제가 해결되는 것이 아니라 여전히 앞의 관리 전략이 필요합니다.

3장. thread를 넘어 재사용하는 long-term memory

장기 메모리는 현재 thread 밖에서도 다시 사용할 목적으로 저장한 정보입니다. 사용자·조직·프로젝트 등의 namespace로 분리할 수 있지만 구체적인 scope는 애플리케이션 정책에 달려 있습니다.

스코프는 이 축으로 나눕니다.

사용자 단위
   이 사람은 파이썬을 쓴다
   이 사람은 존댓말을 선호한다

조직 단위
   우리 회사 배포는 금요일에 하지 않는다
   고객 응대는 3 문장 이내로

에이전트 단위
   이 유형의 요청은 이 순서로 처리하면 잘 된다

전역
   도메인 지식, 용어집

스코프를 명확히 나누지 않으면 사용자·프로젝트 간 메모리 오염 위험이 커집니다. 대표적인 실패는 A 사용자의 선호가 B 사용자 응답에 섞이는 경우입니다.

RAG와의 차이. 둘 다 검색해서 컨텍스트에 넣는 방식이라 헷갈립니다.

RAG 장기 메모리
대상 미리 준비된 문서 코퍼스 상호작용에서 생긴 사실
생성 사람이 색인한다 에이전트가 스스로 쓴다
변화 문서가 바뀔 때만 대화할 때마다
진실 문서가 진실이다 나중 관찰이 앞선 것을 뒤집을 수 있다

결정적 차이가 마지막입니다. RAG 문서는 서로 모순되면 데이터 문제이지만 메모리는 모순이 정상입니다. 사용자가 서울에 산다는 사실이 6개월 뒤 틀릴 수 있어서, 메모리에는 갱신과 무효화 로직이 필요합니다. RAG에는 그 개념 자체가 약합니다.

무엇을 저장할지. 전부 저장하면 저장소가 대화 로그와 다를 게 없어지고 검색해도 노이즈만 잔뜩 나옵니다. 아무것도 저장 안 하면 장기 메모리가 없는 것과 같습니다.

판단 기준은 하나입니다. 다음 대화에서도 참일 가능성이 높은지 봅니다.

발화 판단
"나는 채식주의자다" 저장
"오늘 점심은 파스타를 먹었다" 저장 안 함
"이 코드베이스는 pnpm 을 쓴다" 저장
"지금 3 번 파일을 보고 있다" 저장 안 함

4장. semantic·episodic·procedural memory

이 분류를 쓰는 이유. 장기 메모리 하나로 뭉뚱그리면 저장 형태와 검색 방식을 설계할 수 없습니다. 사람의 기억 연구에서 쓰던 분류가 실제로 잘 맞아서 그대로 차용됐고, LangGraph를 비롯한 프레임워크 문서가 이 세 갈래를 명시적으로 씁니다.

의미 기억. 사실과 개념의 저장입니다. 사용자 이름이나 선호 언어, 회사 배포 환경 같은 것들입니다. 보통 키-값 또는 짧은 문장 형태로 저장하고 질의와의 의미 유사도로 검색하며, 매번 다시 안 물어보는 개인화에 씁니다.

설계 포인트는 같은 항목이 여러 번 관찰되면 갱신해야 한다는 것입니다. 서울에 산다는 정보가 부산으로 이사했다로 바뀌면 앞의 것을 지우거나 시점을 붙여 보관해야 합니다.

일화 기억. 과거에 무슨 일이 있었는지의 저장입니다. 지난번 배포 실패가 환경변수 누락이었다거나 이 사용자가 지난주 요청한 보고서 형식 같은 것들입니다. 사건 단위 기록이라 시점이 중요하고, 현재 상황과 비슷한 과거 상황을 검색해 few-shot 예시로 넣습니다.

에이전트에서 특히 유용합니다. 성공한 과거 궤적을 예시로 넣으면 같은 유형의 태스크에서 실수가 줄고, 실패한 궤적도 반복을 피하는 데 유용합니다.

절차 기억. 일하는 방식의 저장입니다. 이 사용자에게는 코드 예시를 먼저 보여준다거나 배포 전에는 반드시 스테이징 확인을 넣는다 같은 것들입니다. 지시문, 규칙, 체크리스트 형태이고 대개 검색하지 않고 항상 주입합니다.

LangGraph 문서의 정의가 흥미롭습니다. 에이전트의 절차 기억을 모델 가중치와 에이전트 코드와 에이전트 프롬프트의 조합으로 봅니다. 즉 절차 기억의 상당 부분은 저장소가 아니라 코드와 프롬프트에 이미 들어 있습니다.

동적으로 다루는 가장 단순한 형태는 에이전트가 피드백을 받으면 시스템 프롬프트에 규칙 한 줄을 추가하는 것입니다.

셋을 한 표로 모으면 이렇습니다.

저장하는 것 형태 언제 꺼내나 실패 양상
의미 사실 짧은 문장, 키-값 관련 질의가 왔을 때 오래된 사실이 남음
일화 사건 궤적, 시점 포함 비슷한 상황일 때 특수 사례를 일반화
절차 방식 규칙, 지시문 대개 항상 규칙이 쌓여 서로 충돌

5장. 저장보다 중요한 update·consolidation·forgetting

언제 쓰나. 두 시점이 있고 성격이 완전히 다릅니다.

hot path는 에이전트가 대화 도중 도구를 불러 메모리를 저장합니다. 즉시 반영되고 무엇을 저장했는지 투명하지만 응답 지연이 늘고 저장 판단이 대화 흐름을 방해할 수 있습니다.

background는 대화가 끝난 뒤 별도 프로세스가 추출해 저장합니다. 응답이 안 느려지고 전체 대화를 보고 판단할 수 있지만 즉시 반영이 안 되고 같은 세션 안에서는 못 씁니다.

실무에서는 섞습니다. 사용자가 기억해 달라고 명시하면 hot path, 나머지는 background로 갑니다.

추출. 추출은 결국 LLM 호출입니다. 이 대화에서 다음 대화에도 유효할 사실만 뽑으라고 시키고 출력을 구조화하면 관리가 쉬워집니다.

{
  "type": "semantic",
  "subject": "user",
  "fact": "파이썬을 주로 사용",
  "confidence": 0.9,
  "source_turn": 14,
  "observed_at": "..."
}

type 은 검색 시 필터로, confidence 는 낮은 것을 나중에 정리하는 데, source_turn 은 왜 저장했는지 추적하는 데, observed_at 은 오래된 사실 판단에 씁니다. 출처를 남기는 것이 나중에 오염을 수습할 때 결정적입니다.

어떻게 읽나. 가장 단순한 방식은 질의 임베딩으로 유사도 top-k를 뽑는 것인데, 이것만으로는 부족합니다. Generative Agents 논문이 제안한 세 신호 조합이 지금도 널리 쓰입니다.

최신성 (recency)
   최근 것에 가중. 시간에 따라 감쇠

중요도 (importance)
   저장할 때 LLM 이 매긴 점수

관련성 (relevance)
   현재 질의와의 의미 유사도

유사도만으로 안 되는 이유가 있습니다. 사용자가 채식주의자라는 사실은 점심 메뉴를 추천해 달라는 질의와 표면 유사도가 낮지만 반드시 필요한 정보입니다. 중요도 신호가 이런 것을 건져 올립니다.

갱신과 충돌. 새 관찰이 기존 메모리와 충돌하면 세 전략이 있습니다.

전략 A   덮어쓰기
   가장 단순하다
   과거 정보가 사라져 언제부터 바뀌었는지 못 본다

전략 B   시점을 붙여 둘 다 보관
   이력 추적이 된다. 대신 저장소가 커진다

전략 C   무효화 표시
   기존 항목에 invalid_at 을 찍고 새 항목을 추가
   B 와 비슷하되 검색 시 기본 필터링이 쉽다

시간 인지 지식 그래프 계열이 B와 C를 정식으로 다룹니다. 엣지마다 유효 구간을 갖고 그때는 참이었지만 지금은 아닌 사실을 표현합니다.

망각과 갱신. 장기 메모리에서는 빠뜨리기 쉬운 운영 요소입니다. 망각이 없으면 저장소가 무한히 커지고 검색 품질이 계속 떨어지며 틀린 사실이 영원히 남습니다.

기준 대상
시간 감쇠 오래되고 안 쓰인 항목
사용 빈도 한 번도 검색되지 않은 항목
신뢰도 confidence 가 낮은 채로 재확인 안 된 항목
명시적 삭제 사용자가 요청한 것
무효화 새 관찰로 뒤집힌 것

사용자가 지울 수 있어야 한다는 것이 중요합니다. 그거 잊어 달라는 요청이 동작하지 않으면 사용자는 시스템을 신뢰하지 않고, 개인정보 규제 관점에서도 필요합니다.

6장. vector store부터 hierarchical memory까지

버퍼와 요약. 가장 단순한 형태로 최근 메시지 버퍼와 오래된 부분의 요약을 씁니다. 저장소가 없거나 문자열 하나입니다. 짧은 세션과 단일 사용자와 프로토타입에 적합하고, 세션을 넘는 기억이 사실상 없다는 것이 한계입니다.

벡터 저장. 메모리 항목을 임베딩해 벡터 DB에 넣고 질의 임베딩으로 유사도 검색합니다. 구현이 쉽고 RAG 인프라를 재사용하지만, 항목 간 관계를 표현 못 하고 갱신과 무효화를 직접 만들어야 하며 유사도만으로는 검색 품질 문제를 겪습니다.

시간 인지 지식 그래프. Zep의 Graphiti 엔진이 대표적입니다. 엔티티를 노드로, 관계를 엣지로 저장하고 각 엣지에 유효 시점을 붙입니다. 비정형 대화와 정형 비즈니스 데이터를 함께 합성하면서 과거 관계를 유지합니다.

이 사람이 지금 다니는 회사와 예전에 다녔던 회사를 구분할 수 있고, 관계를 타고 다단계 질의가 가능합니다.

대신 그래프 구축에 LLM 호출이 들어가고 같은 사람인지 판별하는 엔티티 해소가 어려우며 운영 복잡도가 벡터 저장보다 확연히 높습니다.

저자 보고로 DMR 벤치마크에서 94.8퍼센트 대 MemGPT 93.4퍼센트를 제시합니다. 벤치마크 조건이 저자 설정이므로 자기 데이터로 재검증이 필요합니다.

OS식 계층 관리. MemGPT가 제안한 접근으로 운영체제의 가상 메모리에서 발상을 가져왔습니다. 빠르지만 작은 메인 컨텍스트와 느리지만 큰 외부 저장소를 두고, LLM이 스스로 도구를 호출해 둘 사이로 데이터를 옮깁니다.

핵심은 모델이 자기 메모리를 관리한다는 것입니다. 컨텍스트가 차면 모델이 스스로 요약해 밀어내고 필요하면 스스로 불러오므로, 페이징을 모델이 수행하는 셈입니다.

컨텍스트 한계를 넘어 긴 문서와 대화를 다루고 메모리 관리 정책을 프롬프트로 조정할 수 있는 것이 장점입니다. 메모리 관리 자체가 토큰을 먹고 모델이 잘못 판단하면 필요한 것을 밀어내는 것이 단점입니다.

자기조직화 노트. A-MEM이 제안한 접근으로 Zettelkasten 노트 방식에서 발상을 가져왔습니다. 새 메모리를 저장할 때 맥락 설명, 키워드, 태그를 갖춘 노트로 만들고, 기존 메모리들을 분석해 관련 있는 것들과 연결을 만듭니다.

벡터 저장은 항목이 서로 모르고 그래프는 관계를 사람이 정의한 스키마로 넣는 반면, A-MEM은 에이전트가 스스로 무엇과 무엇을 이을지 정합니다. 고정된 스키마 없이 구조가 자랍니다.

파일 시스템. 가장 단순하면서 실제로 잘 동작하는 선택지입니다. 에이전트에게 파일 읽기와 쓰기 도구를 주고 메모리를 그냥 마크다운 파일로 관리하게 합니다.

memory/user_preferences.md
memory/project_context.md
memory/lessons_learned.md

사람이 직접 읽고 고칠 수 있고, 버전 관리에 그대로 올라가며, 무엇이 저장됐는지 완전히 투명하고, 별도 인프라가 없습니다. 대신 규모가 커지면 검색이 안 되고 구조를 에이전트가 스스로 지켜야 하며 동시 접근 제어가 없습니다.

단일 사용자나 소수 사용자, 개발 도구형 에이전트, 투명성과 사람의 개입이 중요한 경우에 좋습니다.

방식을 나란히 놓으면 이렇습니다.

방식 관계 표현 시간 처리 운영 복잡도 투명성
버퍼와 요약 없음 없음 매우 낮음 높음
벡터 저장 없음 직접 구현 낮음 낮음
지식 그래프 강함 내장 높음 중간
OS식 계층 약함 직접 구현 중간 중간
자기조직화 노트 자동 생성 직접 구현 중간 중간
파일 시스템 사람이 정리 없음 매우 낮음 매우 높음

7장. memory poisoning과 stale fact

메모리 오염. 가장 위험한 실패입니다. 잘못된 사실이 한 번 저장되면 이후 모든 관련 세션에 계속 주입되고 모델이 그것을 전제로 답하는데, 사용자는 어디서 온 오해인지 알 수 없습니다.

발생 경로
   사용자가 농담으로 한 말을 사실로 저장
   추출 LLM 이 조건절을 놓치고 단정문으로 저장
   외부 문서에 심긴 지시문을 사실로 저장 (프롬프트 인젝션)

방어는 출처를 반드시 남기고, confidence를 붙여 낮은 것은 재확인 전까지 약하게 쓰고, 저장 전에 이것이 사용자에 대한 단정인지 한 번 더 검사하고, 사용자에게 저장된 메모리를 보여주고 지울 수 있게 하는 것입니다.

오래된 사실. 사람은 직장과 거주지, 선호, 프로젝트가 바뀝니다. 갱신 로직이 없으면 에이전트는 계속 옛날 사람에게 말하는 셈이 됩니다.

observed_at 을 붙이고 오래된 항목은 가중을 낮추며, 주기적으로 아직 맞는지 확인하는 흐름을 넣고, 변할 수 있는 사실과 거의 안 변하는 사실을 구분해 다룹니다.

검색 실패. 저장은 됐는데 필요할 때 안 나오는 경우입니다. 질의와 메모리의 표현이 달라 유사도가 낮거나, top-k가 작아서 밀렸거나, 관련 항목이 너무 많아 중요한 것이 묻힌 경우입니다.

앞서 본 다중 신호를 쓰고, 중요한 항목은 검색 대상이 아니라 상시 주입으로 승격합니다.

프라이버시. 장기 메모리는 개인정보 저장소가 됩니다. 사용자가 무심코 말한 민감 정보가 영구 저장될 수 있어서, 저장 전 민감정보 필터와 사용자별 격리, 조회, 수정, 삭제 경로, 보존 기간 정책이 필요합니다.

망각이나 consolidation이 없으면 저장소가 계속 커지고 오래된 정보와 중복이 retrieval을 방해할 수 있습니다. 규모가 작거나 규정상 삭제할 수 없는 저장소도 있으므로 물리적 삭제만이 답은 아니며, expiry·versioning·supersede·retrieval filtering 같은 정책을 조합합니다.

8장. retrieval과 answer quality를 따로 평가한다

어려운 이유. 기억을 잘한다는 것을 어떻게 잴지가 문제입니다. 저장 정확도만 재면 부족한데 저장은 잘했어도 못 꺼내면 소용없습니다. 꺼내기만 재도 부족한데 애초에 저장 안 했으면 못 꺼냅니다. 결국 끝단에서 재야 합니다.

쓰이는 벤치마크. LOCOMO는 아주 긴 다중 세션 대화를 두고 앞선 세션의 정보를 물어보는 QA입니다. DMR은 MemGPT 팀이 주 평가 지표로 세운 벤치마크이고 이후 여러 메모리 시스템이 이것으로 비교합니다.

메모리 시스템 논문의 수치는 대부분 저자 보고이고 비교 대상의 설정을 저자가 정합니다. 특히 전체 컨텍스트를 다 넣는 베이스라인의 설정에 따라 결과가 크게 달라집니다.

자체 평가는 이렇게 설계합니다.

① 실제 대화 로그에서 다중 세션 시나리오를 뽑는다
② N 번째 세션에서 언급된 X 를 M 번째 세션에서 쓸 수 있나 형태의
   질문 세트를 만든다
③ 메모리 켠 상태와 끈 상태를 비교한다
④ 오염 테스트를 넣는다
   일부러 틀린 사실을 심고 그게 얼마나 퍼지는지 본다

오염 테스트는 실제 운영에서 중요한 실패를 잡으므로 평가 항목에 포함하는 편이 좋습니다.

9장. 작은 structured store부터 시작한다

결정 흐름입니다.

① 세션을 넘어 기억할 게 있나
   아니오는 단기 메모리만. 버퍼와 요약으로 충분
   예는 ②로

② 사용자가 여러 명인가
   아니오는 파일 시스템 메모리를 먼저 고려
   예는 ③으로

③ 항목 간 관계와 시점이 중요한가
   예는 시간 인지 지식 그래프
   아니오는 ④로

④ 항목 수가 수천 이상으로 커지나
   예는 벡터 저장과 다중 신호 검색
   아니오는 구조화된 키-값 저장으로 충분

흔한 과잉 설계. 메모리 시스템이 필요하다고 판단하기 전에 세 가지를 봅니다. 세션이 실제로 얼마나 긴지, 저장할 사실이 실제로 몇 개인지, 이미 있는 데이터로 대체되는지입니다.

세션이 짧고 저장할 사실이 적다면 복잡한 vector memory를 먼저 도입할 이유가 약합니다. 기존 profile DB나 간단한 structured store로 충분한지 확인한 뒤 retrieval·consolidation이 실제로 필요할 때 더 복잡한 구조로 확장하는 편이 낫습니다.

시작 순서를 제안하면 이렇습니다.

단계 무엇
1 단계 단기 메모리만. 슬라이딩 윈도우와 도구 결과 압축
2 단계 구조화된 사용자 프로필을 상시 주입 (의미 기억)
3 단계 과거 성공 궤적을 few-shot 으로 (일화 기억)
4 단계 피드백을 시스템 프롬프트 규칙으로 (절차 기억)
5 단계 항목이 많아지면 검색 기반 저장소 도입
6 단계 관계와 시점이 문제가 되면 그래프로

어느 단계까지 필요한지는 사용자 수, memory cardinality, update 빈도와 retrieval 요구에 따라 달라집니다. 단계표는 구현 순서를 생각하기 위한 휴리스틱으로 보는 편이 안전합니다.

10장. memory는 storage보다 policy 문제다

Agentic Memory는 모델 weight에 기억을 새기는 기능이 아니라 runtime의 state, storage, retrieval, update 정책입니다. 단기 상태와 장기 저장은 scope와 생애주기가 다르고, 장기 메모리는 특히 잘못된 정보의 갱신·출처·삭제 정책이 중요합니다. 성능을 높이려면 저장량 자체보다 언제 무엇을 다시 넣을지를 평가해야 합니다.

장기 메모리 세 갈래. 의미 기억은 사실을 저장하고 개인화에 쓰며, 일화 기억은 과거 경험을 저장하고 few-shot으로 쓰고, 절차 기억은 일하는 방식을 저장하고 프롬프트에 상시 반영합니다.

무엇을 먼저 만들까. 가장 먼저 만들 것은 저장소가 아니라 무엇을 저장할지 판단하는 기준과, 저장된 것을 사람이 볼 수 있는 화면과, 지울 수 있는 경로입니다. 이 셋이 없으면 저장소가 아무리 좋아도 오염을 수습할 수 없습니다.

용어 정리

용어 한 줄 뜻
단기 메모리 (short-term) 스레드 범위 메모리. 하나의 세션 안에서만 유효
장기 메모리 (long-term) 세션과 스레드를 넘어 유지되는 메모리
스레드 (thread) 하나의 대화 단위. 단기 메모리의 격리 경계
체크포인터 노드 실행마다 상태를 저장해 재개를 가능하게 하는 장치
네임스페이스 장기 메모리를 사용자, 조직 등으로 나누는 조직 단위
의미 기억 (semantic) 사실과 개념의 저장. 개인화에 쓰임
일화 기억 (episodic) 과거 사건과 궤적의 저장. few-shot 예시로 쓰임
절차 기억 (procedural) 일하는 방식과 규칙의 저장. 프롬프트에 반영
lost in the middle 긴 컨텍스트의 중간에 있는 정보를 모델이 잘 활용하지 못하는 현상
hot path 저장 대화 도중 즉시 메모리를 쓰는 방식
background 저장 대화 종료 후 별도 프로세스가 추출해 저장하는 방식
추출 (extraction) 대화에서 저장할 사실을 골라내는 단계
통합 (consolidation) 중복되거나 충돌하는 메모리를 정리해 합치는 단계
망각 (forgetting) 오래되거나 무효해진 메모리를 제거하는 단계
최신성, 중요도, 관련성 Generative Agents가 제안한 메모리 검색의 세 신호
메모리 오염 잘못된 사실이 저장돼 이후 세션에 계속 주입되는 실패
시간 인지 지식 그래프 엣지에 유효 시점을 붙여 과거와 현재 사실을 구분하는 그래프
MemGPT / Letta 운영체제의 가상 메모리에서 발상을 가져온 계층형 메모리 관리
Graphiti Zep의 시간 인지 지식 그래프 엔진
A-MEM Zettelkasten 방식으로 메모리 노트를 자기조직화하는 시스템
Mem0 대화에서 추출, 통합, 검색을 수행하는 메모리 중심 아키텍처
LOCOMO 아주 긴 다중 세션 대화 기반 메모리 평가 벤치마크
DMR (Deep Memory Retrieval) MemGPT 팀이 세운 메모리 검색 평가 벤치마크

참고자료

댓글

티스토리툴바