본문으로 건너뛰기
중급

에이전트 메모리는 실제로 어떻게 작동하는가

챗봇에게 두 개의 세션에서 같은 질문을 두 번 하면, 매번 낯선 사람처럼 대답한다. 이것은 버그가 아니라 기본 동작이다. 순수한 언어 모델은 호출 사이에 아무런 메모리가 없다. 하나의 대화 안에서 "기억"하는 모든 것은 컨텍스트 윈도우 안에 존재하며, 그 대화가 끝나면 사라진다.

메모리는 그것을 고치기 위해 덧붙이는 기계 장치다. 즉 에이전트가 무엇을 앞으로 가져가야 하는지, 어디에 저장할지, 그리고 적절한 순간에 적절한 조각을 어떻게 다시 끌어올지를 결정하는 시스템이다. 2026년에 이것은 곁다리 과제이기를 멈추고 에이전트 설계의 일급 구성 요소가 되었으며, 자체 벤치마크, 프레임워크, 그리고 진정한 연구 문헌을 갖추게 되었다. 이 페이지가 그 지도다.

What you'll learn
  • 컨텍스트 윈도우가 왜 메모리가 아닌지, 그리고 그 경계가 실제로 어디에 있는지 이해한다
  • 에이전트가 사용하는 네 가지 메모리 유형을 구별한다: 작업, 일화적, 의미적, 절차적
  • 네 가지 저장 패턴을 비교한다: 전체 컨텍스트, vector/RAG, 지식 그래프, 압축/요약
  • 오늘날 Claude, ChatGPT, Gemini가 각각 메모리를 어떻게 구현하는지 살펴본다
  • 과도한 설계 없이 자신의 에이전트를 위한 메모리 접근법을 선택한다

붙잡아야 할 하나의 아이디어: 컨텍스트 ≠ 메모리​

가장 흔한 혼동은 큰 컨텍스트 윈도우를 "메모리"로 취급하는 것이다. 그렇지 않다. 컨텍스트 윈도우는 한 턴을 위한 작업 공간이다 — 매 호출마다 처음부터 다시 채워지고, 유한하며, 비싸다. 또한 그 안에서 어텐션이 저하된다(Context Engineering에서 다룬 "중간에서 길을 잃는(lost in the middle)" 효과).

메모리는 세 가지 면에서 다르다:

컨텍스트 윈도우메모리
수명한 번의 요청세션, 며칠, 영원히에 걸쳐
크기고정된 token 상한사실상 무제한(외부 저장소)
비용매 턴마다 지불쓸 때 한 번 지불; 참조는 저렴
접근모든 것이 항상 시야 안에선택적 — 관련 있는 것만 검색

에이전트 메모리의 전체 게임은 이 둘 사이에서 올바른 정보를 옮기는 것이다: 매 턴마다 비용을 내지 않도록 지속되는 사실을 윈도우 밖으로 쓰고, 이 특정 단계가 필요로 할 때에만 그것을 다시 안으로 끌어온다. 그 흐름을 제대로 잡으면 에이전트는 언제나 관련 있는 수천 개의 token만 담는 컨텍스트 윈도우로 몇 주 동안 작동할 수 있다.

네 가지 종류의 메모리​

인지 과학에서 (느슨하게) 차용하여, 2026년 에이전트 생태계는 네 가지 범주로 수렴했다. 네 가지 모두가 필요한 경우는 드물다 — 하지만 그것들에 이름을 붙이면 모든 것을 형편없이 하는 하나의 덩어리를 만드는 일을 막을 수 있다.

Guided walkthrough1 of 4
  1. 지금 이 순간 컨텍스트 윈도우 안에 있는 것 — 현재 작업, 최근 몇 턴, 이 단계의 도구 결과. 설계상 휘발적이다. 이것은 스크래치패드이지 아카이브가 아니다. 이것을 잘 관리하는 것이 context engineering이며, 지속성(persistence)이 아니다.

유용한 테스트: *"그게 언제 일어났지?"*로 답하게 된다면 그것은 일화적이다; *"무엇이 참이지?"*로 답한다면 의미적이다; *"이렇게 하는 거야"*로 답한다면 절차적이다; 그리고 다음 몇 초에만 중요하다면 그것은 작업 메모리이며 전혀 지속시킬 필요가 없다.

네 가지 저장 패턴​

무엇을 기억할지 알고 나면, 어떻게 저장하고 검색할지를 고른다. 대략 복잡도 순으로, 네 가지 지배적인 패턴이 있다. 대부분의 실제 시스템은 그중 두세 가지를 결합한다.

1. 전체 컨텍스트(다 집어넣기)​

전체 이력을 유지하고 매 턴마다 다시 보낸다. 인프라 제로, 완벽한 회상 — token 상한, 비용 곡선, 또는 "중간에서 길을 잃는(lost in the middle)" 문제에 부딪히기 전까지는. 짧은 어시스턴트에는 괜찮지만, 오래 실행되는 무엇에는 막다른 골목이다. 이것은 다른 모든 패턴이 개선하는 기준선이다.

2. Vector / RAG 메모리​

각 메모리를 embedding으로서 vector 데이터베이스에 쓴다; 쿼리 시점에 현재 턴을 embedding하고 가장 유사한 top-k 메모리를 검색한다. 이것은 문서 대신 대화 이력을 향한 retrieval-augmented generation이다. 저렴하고, 확장 가능하며, 사실과 선호의 의미적 회상을 위한 기본값이다.

그 약점: 시간적 또는 멀티홉(multi-hop) 질문에서는 유사도 ≠ 관련성이다. "예산이 삭감된 이후에 우리가 무엇을 결정했지?"는 순서에 대한 질문이며, 코사인 유사도는 시간 감각도, 두 사실을 연결하는 감각도 없다.

3. 지식 그래프 메모리​

메모리를 엔터티와 관계로 저장한다 — 노드와 엣지, 종종 엣지에 타임스탬프를 붙인다. 질문에 답하려면 vector를 퍼지 매칭하는 대신 그래프를 순회(traverse)한다. 이것이 멀티홉 및 시간적 추론을 다룰 수 있게 만드는 것이다("사용자가 항의한 계정을 소유하던 사람을 대체한 사람은 누구지?"). Zep/Graphiti 같은 프레임워크는 시간적 지식 그래프를 중심으로 그들의 전체 세일즈 포인트를 구축했다. 그 비용은 실제 엔지니어링이다: 추출, 엔터티 해소(entity resolution), 그리고 그래프가 썩지 않게 유지하기.

4. 압축 및 요약​

실행 중인 이력을 주기적으로 증류된 요약으로 압축하고 거기서부터 계속한다 — 축자적(verbatim) 회상을 더 작고 저렴한 윈도우와 맞바꾸는 것이다. 이것이 Claude Code에서 /compact가 하는 일이며, 많은 채팅 제품에서 "자동 요약"이 하는 일이다. 이것은 장기 메모리의 가장 저렴한 형태이며, 실제로 처음 필요한 것인 경우가 많다. 그 위험: 요약이 당신이 필요로 했던 바로 그 세부 사항을 조용히 떨어뜨린다. 이것이 몇 시간에 걸친 실행에서 어떻게 전개되는지는 Long-Running Agent Harnesses를 참고하라.

Pro tip

실제 시스템은 이것들을 층층이 쌓는다. 흔한 2026년 스택: 실행 중인 대화에는 압축(compaction), 의미적 사실에는 vector, 그리고 시간적/멀티홉 쿼리가 실제로 트래픽에 나타날 때에만 그 위에 그래프(graph). 그래프가 해결하는 고통을 느끼기 전까지는 그래프를 만들지 마라.

빅3는 어떻게 하는가​

이제 모든 주요 어시스턴트가 어떤 형태로든 메모리를 탑재한다. 그것들은 같은 것이 아니며, 그 차이가 중요하다.

제품무엇을 기억하는가어떻게 작동하는가(대략)
Claude두 층: 당신의 선호에 대한 앱 수준 메모리, 그리고 에이전트를 위한 개발자 대상 memory tool.Claude app memory는 채팅 전반에 걸쳐 사실을 저장한다; API memory tool plus context editing은 에이전트가 클라이언트 측 저장소에 노트를 쓰고 오래된 도구 결과를 자동으로 정리(prune)하여 긴 실행을 견디게 해준다.
ChatGPT"저장된 메모리"(명시적 사실)와 과거 채팅에 대한 참조.사용자가 진술한 사실과 자동으로 추출된 선호의 혼합이며, 이후 턴에서 시스템 컨텍스트에 주입된다. 사용자가 편집 가능하고 토글 가능하다.
Gemini당신의 채팅에서, 그리고 선택적으로 더 넓은 Google 계정 표면에서 끌어온 개인적 컨텍스트.이전 대화의 세부 사항을 회상하고, 개인정보 통제에 따라 계정 컨텍스트를 사용해 개인화할 수 있다.

두 가지 요점. 첫째, 소비자 메모리는 대체로 의미적이다 — 선호와 사실 — 완전한 일화적 재생이 아니다. 둘째, 만약 당신이 에이전트를 구축하고 있다면, 제품에 내장된 메모리는 당신의 메모리 시스템이 아니다; 당신은 Claude의 memory tool 같은 프리미티브나 외부 프레임워크를 사용해 그 층을 직접 소유한다.

순수한 모델을 노트 작성 에이전트로 바꾸기 (가장 저렴한 진짜 메모리)

You have a file called MEMORY.md that persists between our sessions.

At the END of each session, append any durable facts worth keeping:
- my stable preferences (tools, formats, style)
- decisions we made and WHY
- open threads to resume next time

At the START of each session, read MEMORY.md first and use it.
Keep it under 30 lines — when it grows past that, consolidate and
delete anything stale. Never store secrets or credentials.

바로 그 단일 패턴 — 외부 파일에 지속되는 노트를 쓰고, 다음번에 그것을 다시 읽는 것 — 이 에이전트 메모리의 80/20이다. 아래의 프레임워크 기계 장치 대부분은 정확히 이것의 더 자동화되고 더 확장 가능한 버전이다.

메모리 측정하기: LoCoMo 벤치마크​

측정할 수 없는 것은 개선할 수 없으며, 벤치마크가 등장하기 전까지 메모리는 측정하기 어려웠다. 가장 많이 인용되는 것은 LoCoMo("Evaluating Very Long-Term Conversational Memory of LLM Agents")다: 매우 긴 다중 세션 대화 — 수십 개의 세션에 걸친 수백 턴 — 와 다섯 가지 종류의 질문-답변 쌍: 싱글홉(single-hop), 멀티홉(multi-hop, 세션 간), 시간적 추론, 오픈 도메인, 적대적(adversarial).

LoCoMo가 드러내는 것은 설계 시 대비해야 할 패턴이다: 시스템은 싱글홉 사실 회상에서는 잘 해내고 시간적 및 멀티홉 질문에서는 무너진다. 그 실패 양상이 바로 지식 그래프 메모리가 존재하는 이유다 — 그것은 그 두 범주를 가장 크게 끌어올리는 패턴이다. 자신의 에이전트 메모리를 평가할 때는 멀티홉과 시간적 사례에 큰 가중치를 두어라; 싱글홉 회상은 거의 모든 것을 좋아 보이게 만든다.

과도하게 만들지 않으면서 접근법 선택하기​

Guided walkthrough1 of 5
  1. 아무것도 하지 마라. 작업 메모리(컨텍스트 윈도우)로 충분하다. 여기에 메모리 저장소를 추가하는 것은 순전한 오버헤드다.

함정은 다섯 번째 단계에서 시작하는 것이다. 그래프 메모리는 데모에서 인상적이고 프로덕션에서 비싸다. 사다리를 올라가되, 당신의 실제 문제를 해결하는 첫 번째 가로대에서 멈춰라.

Check yourself

0/4
  1. 큰 컨텍스트 윈도우가 왜 에이전트 메모리와 같지 않은가?
  2. 사용자가 묻는다: '예산이 삭감된 바로 이후에 우리가 무엇을 결정했지?' 어떤 메모리 접근법이 정확히 답할 가능성이 가장 높은가?
  3. '사용자는 미터법 단위를 선호한다'에 대한 올바른 분류는 무엇인가?
  4. 당신은 짧은 단일 세션 도우미 봇을 만들고 있다. 올바른 메모리 설계는 무엇인가?
에이전트 메모리 어휘
Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 8

결론​

메모리는 켜는 하나의 기능이 아니다 — 그것은 당신이 설계하는 흐름이다: 무엇이 윈도우를 떠나는지, 어디에 저장되는지, 그리고 어떻게 다시 돌아오는지. 네 가지 메모리 유형에 이름을 붙여서 그것들 전부를 위한 하나의 덩어리를 만들지 않도록 하라. 당신의 문제를 해결하는 가장 저렴한 저장 패턴에서 시작하고, 다음 것의 고통을 느낄 때에만 올라가라. 그리고 시간적 및 멀티홉 사례로 측정하라, 왜냐하면 싱글홉 회상은 모든 것을 실제보다 더 똑똑해 보이게 만들기 때문이다.

메모리는 Context Engineering의 나머지 절반이다: context engineering은 이번 턴에 무엇이 윈도우를 채우는지를 결정하고; 메모리는 턴 사이에 무엇이 살아남는지를 결정한다. 이 둘이 함께, 챗봇과 당신이 오래 함께 일할수록 더 나아지는 에이전트를 가르는 것이다.

출처 및 더 읽을거리​