당신의 AI 에이전트는 데모에서는 아주 멋지게 작동합니다. 하지만 다음 날 실제 사용자가 돌아오면, 에이전트는 이전 대화에서 아무것도 기억하지 못합니다. 사용자의 이름도, 선호도도, 이미 완료한 구매 내역도 기억하지 못합니다. 모든 세션이 제로(zero) 상태에서 시작됩니다.

"내 AI 에이전트는 세션 사이에 모든 것을 잊어버린다"는 에이전트에 대한 가장 흔한 불만 중 하나입니다. 연구에서는 이를 **메모리 감퇴 (memory decay)**라고 부르지만, 모델이 고장 난 것은 아닙니다. 모델은 설계상 상태가 없는 (stateless) 구조이기 때문입니다. 메모리는 모델 주변에 구축하는 하네스 (harness), 즉 도구, 상태(state), 그리고 저장소(storage)의 영역입니다. 이는 실제적인 트레이드오프 (trade-offs)가 존재하는 설계 결정 사항입니다.

이 포스트는 지도 역할을 할 것입니다. 가장 일반적인 메모리 유형, 각 유형의 장점, 비용, 그리고 그중에서 어떻게 선택해야 하는지를 다룹니다.

왜 "그냥 더 큰 컨텍스트 윈도우 (context window)를 사용하라"는 방법이 실패하는가

유혹적인 해결책은 매 턴마다 전체 대화 기록을 다시 보내는 것입니다. 첫 주에는 잘 작동합니다. 하지만 그 이후에는 다음과 같은 문제가 발생합니다:

• 컨텍스트 윈도우 (context window)는 비용이 많이 듭니다. 매 턴마다 동일한 토큰을 다시 처리하는 비용을 지불해야 하며, 이는 영구적으로 지속됩니다. 대화 기록의 대부분이 현재 질문과 무관하더라도, 기록의 길이가 길어질수록 비용은 증가합니다.
• 세션이 지속되지 않습니다. 사용자가 내일 돌아왔을 때, 어딘가에 저장해 두지 않았다면 다시 보낼 기록이 없습니다.
• 더 많은 컨텍스트가 더 좋은 컨텍스트는 아닙니다. 정확도와 비용 측면 모두에서, 군더더기 없이 관련성 있는 검색된 컨텍스트가 전체 기록을 쑤셔 넣는 것보다 낫습니다. 선택이 양을 이깁니다 (Selection beats volume).

따라서 진짜 질문은 "어떻게 모든 것을 유지할 것인가?"가 아닙니다. "내 에이전트가 실제로 무엇을, 어디에 기억해야 하며, 그것을 어떻게 다시 찾아낼 것인가?"입니다.

메모리는 어떻게 모델에 도달하는가?

모델은 오직 자신의 컨텍스트 윈도우 (context window)만을 봅니다. 모든 메모리는 경계(edges)에서 동일한 방식으로 작동합니다:

• 쓰기 경로 (Write path): 대화 중 또는 대화 후에, 보관할 가치가 있는 무언가를 외부 저장소 (external store)에 저장합니다.
• 읽기 경로 (Read path): 답변하기 전에, 에이전트는 현재 질문과 관련된 몇 가지 항목을 검색하여 프롬프트 (prompt)의 일부로 또는 도구 결과 (tool result)로서 컨텍스트 (context)에 배치합니다.

저장소는 모델과 직접 대화하지 않습니다. 메모리 유형을 구분 짓는 것은 중간 단계, 즉 다시 가져올 적절한 항목을 찾는 방법입니다: 키 (key)를 통해서, 의미 (meaning)를 통해서, 또는 관계 (relationship)를 통해서 찾는 방식입니다.

주요 AI 에이전트 메모리 유형은 무엇인가요? 메모리가 주로 존재하는 네 가지 장소

한 가지 분류를 통해 전체 지형을 관리 가능한 수준으로 나눌 수 있습니다: 메모리가 어디에 존재하는가 (저장 유형, storage type) 대 어떻게 관리되는가 (기능, capabilities)입니다. 먼저 유형부터 살펴보겠습니다.

1. Key-value 메모리: 이름이 지정된 키 아래의 구조화된 사실들

사용자의 이름, 언어, 플랜 등급: 에이전트의 도구들이 읽고 쓰는 키 (keys) 아래에 저장된 사실들입니다. 임베딩 (embeddings)도, 검색 인프라 (search infrastructure)도 필요하지 않습니다.

특징. 빠르고, 저렴하며, 키를 알고 있다면 정확합니다. 지속성 (Persistence)은 단계별로 구성됩니다: 프로세스 내 상태 (in-process state), 디스크 상의 세션 파일 (session files on disk), 클라우드 저장소의 세션 객체 (session objects in cloud storage).

사용 시점: 기억할 가치가 있는 것들에 명확한 이름이 있을 때 사용합니다: 프로필 (profile), 선호도 (preferences), 설정 (settings), 카운터 (counters) 등. 이는 예상보다 더 많은 범위를 포괄하며, 모든 에이전트가 시작해야 할 지점입니다.

한계: 모든 읽기 작업은 누군가가 사전에 설계한 조회 (lookup)입니다. 예를 들어 저장소에 다음과 같은 하나의 항목이 있다고 가정해 봅시다:

dietary_notes: "vegetarian, severe shellfish allergy"

정답은 내내 저장소(store)에 있었습니다. 두 번째 질문은 키(key)를 명시하지 않았을 뿐이며, 이 저장소의 유일한 진입 방식은 바로 _키(key)_를 통한 방식입니다. 아래의 각 유형은 새로운 진입 방식을 추가합니다.

개선하기 위한 팁:

• 항목에 버전을 부여하세요. 선호도가 변경되면 기존 값 옆에 모순되는 내용을 덧붙이는 대신, 값을 업데이트하고 버전을 올리세요. 변화 과정이 가시적으로 유지되며 저장소는 깔끔하게 유지됩니다.
• 양식(form)이 아닌 행동으로부터 배우세요. 사용자가 실제로 하는 행동(무엇을 구매하는지, 무엇을 선택하는지, 무엇을 거부하는지)은 사용자가 입력한 그 어떤 것보다 더 신뢰할 수 있는 선호도를 알려줍니다.
• 내구성 사다리(durability ladder)를 의도적으로 오르세요: 임시 데이터(scratch)를 위해서는 프로세스 상태(process state)를, 재방문하는 사용자를 위해서는 세션(sessions)을 사용하세요.

2. 벡터 메모리 (Vector memory): 이름이 아닌 의미로 검색하기

각 메모리를 벡터(vector)로 한 번 임베딩(embed)하고, 들어오는 질문을 임베딩한 뒤, 가장 가까운 이웃(nearest neighbors)을 검색합니다. 키-값(key-value) 방식이 답할 수 없었던 동일한 메모리와 동일한 질문을 적용해 보겠습니다:

질문과 메모리 사이에 공유되는 단어가 없습니다. 하지만 이들은 의미(meaning) 면에서 가깝고, 인덱싱(indexed)된 것은 바로 그 의미입니다.

키-값 방식과의 경계선: 키를 알고 있는가, 아니면 의도(intent)만 알고 있는가?

특징. 사람들이 혼동하는 두 가지 비용이 있습니다: 인덱스 쿼리(querying the index) 비용과 질문을 임베딩(embedding)하는 비용인데, 일반적으로 임베딩 비용이 쿼리 자체보다 더 많이 듭니다. 임베딩 호출 비용이 지배적입니다.

사용 시점: 메모리가 질문이 예측 불가능한 각도에서 접근하게 될 메모(notes), 에피소드(episodes), 히스토리(history) 형태로 성장했을 때 사용하세요.

사용 금지 시점: 키 조회(key lookup)만으로 충분할 때(사용자의 요금제 등급을 가져오기 위해 임베딩 비용을 지불하지 마세요), 또는 질문이 _관계(relationships)_에 관한 것일 때 사용하지 마세요. 아래 내용을 참조하세요.

개선하기 위한 팁:

• 쓰기 시점에 한 번만 임베딩(Embed)하세요. 쿼리(Query) 시점에는 질문만 임베딩해야 합니다.
• 하나의 거대한 인덱스(Index)를 만들기보다 메모리 유형(사실 vs 선호도 vs 에피소드)별로 파티셔닝(Partitioning)하세요. 검색(Retrieval)이 더 정밀해지고 정리(Cleanup) 작업이 매우 효율적으로 변합니다.
• 자체적인 지연 시간(Latency)을 측정하세요. 발표된 수치는 기준점일 뿐 보장된 수치가 아닙니다.

3. 그래프 메모리 (Graph memory): 엔티티(Entities)와 그들 사이의 관계

이제 키(Key)나 의미(Meaning)만으로는 답할 수 없는 질문이 등장합니다. 저장소에는 세 가지 별개의 사실이 들어 있습니다: Maya는 X 회사에서 근무한다 · X 회사는 Y 그룹에 속한다 · Y 그룹은 스페인에서 운영된다.

정답은 단일 메모리에 존재하지 않습니다. 정답은 메모리들을 가로지르는 경로(Path)로서 존재하며, 경로를 따라갈 수 있는 접근 방식이 필요합니다.

특징. 밀리초(Millisecond) 단위의 쿼리, 본질적인 내구성, 그리고 독보적인 **추적 가능성(Traceability)**을 가집니다. 즉, 정답과 함께 그 정답을 도출해낸 사실의 사슬(Chain of facts)이 제공됩니다. 비용 측면에서는 실제 데이터베이스를 실행해야 하며 설계해야 할 스키마(Schema)가 존재합니다.

사용 시점: 도메인이 본질적으로 연결되어 있고(사람, 조직, 의존 관계), 사용자가 이러한 연결을 가로지르는 질문을 던질 때 사용하세요.

사용 금지 시점: 메모리가 독립적인 노트 형태일 때입니다. 서로 연결되지 않은 노드(Node)들로 이루어진 그래프는 불필요한 단계가 추가된 느린 키-값 저장소(Key-value store)에 불과합니다.

개선하기 위한 팁:

• 벡터 인덱스(Vector index)를 그래프 _내부_에 배치하세요 (최신 그래프 저장소는 이를 지원합니다). 유사도(Similarity)를 통해 진입점을 찾고, 탐색(Traversal)을 통해 정답을 찾습니다. 이 조합이 아래에 설명할 "하이브리드(Hybrid)" 패턴입니다.
• 모든 것을 모델링하기보다 실제 질문(예: "내가 아는 ...은 누구인가")으로부터 관계를 설계하세요. 추가하는 모든 엣지(Edge) 유형은 쿼리로서의 가치를 증명해야 합니다.
• 영향 범위(Blast radius)를 주의하세요. 연결성은 강력한 힘인 동시에 취약점이기도 합니다 (아래의 위생(Hygiene) 섹션 참조).

4. 하이브리드 (Hybrid): 하나의 에이전트에 벡터 + 그래프 결합

어떤 질문들은 두 가지 방식이 동시에 필요합니다: "내가 좋아했던 것과 유사한 것을 찾아주되, 내가 관계를 맺고 있는 제공업체의 것만 찾아줘." 어느 한 가지 방식만으로는 답할 수 없지만, 이들을 체이닝(Chaining)하면 가능해집니다:

유사도(Similarity)가 후보를 찾아내면, 탐색(Traversal)이 관계에 따라 이들을 필터링합니다.

하이브리드(Hybrid) 방식에는 두 가지 형태가 있습니다. 두 가지 동작을 모두 지원하는 하나의 저장소(벡터 인덱스가 포함된 그래프 데이터베이스)를 사용하거나, 두 개의 전문화된 저장소를 나란히 두고 에이전트가 질문에 따라 선택하는 방식입니다. 어떤 방식이든 에이전트는 두 가지 경로를 모두 확보하게 됩니다. 여기에는 관리형 버전(Managed version)과 직접 구축하는 버전(Build-it-yourself version)이 있으며, 이들 사이의 트레이드오프(Trade-off)를 측정하는 것이 바로 이 시리즈의 코드 포스트들이 다루는 핵심입니다.

기능 계층: 메모리와 잡동사니 서랍을 구분하는 것

유형(Types)은 어디에(where) 저장할지를 결정합니다. 유형과는 독립적인 세 가지 기능(Capabilities)은 _무엇을, 무엇을 하지 않을지, 그리고 왜(what, what not, and why)_를 결정합니다.

선택적 메모리(Selective memory): 에이전트가 실제로 무엇을 기억해야 하는가?

실제 대화는 지속적인 사실(Durable facts), 일회성 잡담(Throwaway small talk), 선호도(Preferences), 그리고 이벤트(Events)가 뒤섞여 있습니다. 이 모든 것을 저장하면 메모리는 값비싼 소음(Noise)이 됩니다. 아무것도 저장하지 않으면 다시 기억상실증에 걸린 에이전트로 돌아가게 됩니다. 누군가, 혹은 무언가가 반드시 **선택(Select)**해야 합니다.

누군가는 그 결정을 내려야 하며, 그 주체에 대해서는 세 가지 옵션이 있습니다:

1. 에이전트 자신 (The agent itself): 대화 도중 호출하는 메모리 도구(memory tools)를 사용합니다. 자유롭게 구축할 수 있지만, 선택의 품질은 대화에 집중하느라 바쁜 모델의 성능에 달려 있으며, 선택 작업이 매 턴의 지연 시간(latency)에 영향을 미칩니다.
2. 자체 추출기 (Your own extractor): 대화 경로를 벗어나 매 턴이 끝난 후 실행됩니다. 메모리 유형별로 특화된 프롬프트(prompts)를 사용하며, 각 프롬프트는 "기억할 가치가 없음"이라는 답변을 내릴 수 있는 권한을 가집니다. 단일 목적의 프롬프트는 멀티태스킹보다 뛰어나며, 대화 흐름을 방해하지 않습니다. 대가로는 프롬프트를 직접 관리해야 하며 토큰 비용을 지불해야 합니다.
3. 관리형 서비스 (A managed service): Amazon Bedrock AgentCore Memory와 같은 서비스입니다. 가공되지 않은 대화 턴(raw turns)을 보내면, 내장된 전략(의미적 사실(semantic facts), 사용자 선호도(user preferences), 요약(summary), 에피소드(episodic))이 대신 추출해 줍니다. 쓰기 경로(write path)가 가장 저렴하고 유지 관리할 파이프라인이 없습니다. 단점은 추출이 비동기 방식(memories become queryable with a lag, not instantly)으로 이루어져 메모리가 즉시 조회되지 않고 지연이 발생하며, 유지/폐기 기준을 직접 조정할 수 없다는 점입니다.

메모리 유형은 인프라 기능이 아니라 설계 결정 사항입니다. 관리형 플랫폼은 이를 내장된 형태로 제공하지만, 여러분도 프롬프트와 체계적인 규칙을 통해 동일한 분류 체계(taxonomy)를 구축할 수 있습니다.

팁: 결정 주체(selector)를 평가할 때는 결정론적 정답(deterministic ground truth)을 사용하세요. 테스트 대화에 '기억해야 할 정보'와 '미끼(decoys)'를 심어두고, 무엇이 살아남았는지 *점수(score)*를 매기세요. "무언가를 기억하는 것 같다"는 식의 판단은 평가가 아닙니다.

메모리 위생(Memory hygiene): 에이전트가 반드시 기억하지 말아야 할 것

저장된 메모리는 권위를 가집니다. 에이전트는 이를 진실로 취급하며 재확인 없이 이를 바탕으로 답변을 생성합니다. 이 때문에 오염된 메모리(dirty memory)는 두 가지 측면에서 위험합니다:

• 오염된 메모리 (Dirty memory): 잘못된 사실, 오래된 사실(변경된 주소, 취소된 계획), 중복 및 모순된 정보입니다. 에이전트는 이를 검색하고 신뢰하며, 자신의 저장소 위에서 자신 있게 환각(hallucination)을 일으킵니다. 어제의 실수가 오늘의 확신이 되어버립니다.