Agent 메모리 시스템 설계: 세션에서 장기 기억까지

AI Agent와 하루 종일 아키텍처 방안, 기술 선택, 위험 평가를 논의했습니다. 다음 날 같은 대화를 열자 Agent가 물었습니다. “어떤 내용을 논의하고 싶으신가요?”

어제의 모든 것, 즉 선호 사항과 논의한 결론, 진행 상황이 모두 사라졌습니다. 이는 Agent의 능력 문제가 아닙니다. 문제는 아키텍처 설계에 있습니다. LLM은 기본적으로 무상태이므로, 메모리 시스템을 능동적으로 구축하지 않으면 모든 요청을 백지상태에서 시작합니다. 많은 팀이 Agent를 출시한 뒤에야 이 문제를 발견합니다. 사용자는 “왜 또 물어보나요?”, “지난번에 약속한 일을 왜 잊었나요?”라고 불평하고, 팀은 뒤늦게 수습에 나섭니다.

이 글에서는 완전한 Agent 메모리 시스템 설계 청사진을 공유합니다. 네 가지 메모리 유형을 어떻게 선택하고, 5단계 파이프라인을 어떻게 구성하며, 프레임워크와 비용을 어떻게 결정하고 관리할지 살펴보겠습니다.

1장: Agent에 메모리 시스템이 필요한 이유

LLM은 원래 ‘금붕어 기억력’을 갖고 있습니다. 요청 하나를 보내면 답변 하나를 내놓고 끝납니다. 다음 요청이 들어오면 다시 완전히 새로운 상태가 되어 아무것도 기억하지 못합니다. 이는 결함이 아니라 설계 특성입니다. 추론을 매번 독립적으로 수행해 출력의 예측 가능성을 보장하기 때문입니다.

하지만 이 특성은 Agent 환경에서는 재앙에 가깝습니다.

고객 지원 Agent를 예로 들어 보겠습니다. 사용자가 “주소를 변경하고 싶어요”라고 말합니다. Agent는 “알겠습니다. 새 주소를 알려 주세요”라고 답합니다. 사용자가 “지난번 그 창고 주소요”라고 말하면 Agent는 완전히 막힙니다. 지난번이 언제인지, 어느 창고인지 전혀 알지 못합니다.

더 나쁜 문제는 ‘컨텍스트 부패’(Context Rot)입니다. 대화에 내용을 계속 넣으면 컨텍스트가 길어지고 그 안의 불필요한 정보도 늘어납니다. 사용자가 간단한 질문을 해도 Agent는 수십 차례의 기록 속에서 답을 찾아야 합니다. Redis 공식 블로그 데이터에 따르면 전체 컨텍스트 방식은 p95 지연 시간을 17.12초까지 끌어올리고 토큰 비용을 14배로 늘립니다.

비용 차이는 더욱 큽니다. 제가 본 비교에서는 전체 컨텍스트 방식이 한 달에 100만 달러를 쓰는 반면, 선택적 기억 방식은 10만 달러만 필요했습니다. 무려 10배 차이입니다.

여기서 핵심 모순은 Agent가 모든 것을 기억하기를 바라면서도 모든 내용을 컨텍스트 창에 넣을 수는 없다는 점입니다. 해결책은 간단합니다. Agent에 메모리 시스템을 장착하는 것입니다.

메모리 시스템은 세 가지 핵심 문제를 해결합니다.

세션 간 연속성: 사용자가 오늘 중국어 답변을 선호한다고 말했다면 내일, 다음 주, 다음 달에 다시 열어도 Agent는 이 선호를 기억해야 합니다.

개인화된 경험: 사용자마다 이용 습관, 비즈니스 배경, 과거 기록이 다릅니다. 메모리 시스템이 있으면 Agent가 사용자를 ‘알아볼’ 수 있습니다.

장애 복구: Agent가 작업 도중 오류를 만나도 메모리 시스템이 있다면 재시작 후 중단된 지점부터 이어갈 수 있으므로 처음부터 다시 시작할 필요가 없습니다.

2장: 네 가지 메모리 유형 — 인지과학에서 기술 아키텍처까지

메모리는 하나의 저장 공간이 아닙니다. 계층과 역할이 나뉩니다. 인지과학에서는 인간의 기억을 작업 기억, 일화 기억, 의미 기억, 장기 기억으로 분류합니다. Agent 아키텍처 설계에도 이 모델을 그대로 참고할 수 있습니다.

작업 메모리(Working Memory)

작업 메모리는 Agent의 현재 세션에서 작동하는 ‘두뇌’입니다. 사용자가 방금 한 말, 현재 작업 진행 상황, 중간 추론 결과처럼 대화 중 Agent가 생각하는 모든 내용이 여기에 있습니다.

저장 위치는 명확합니다. 바로 컨텍스트 창입니다. 수명도 짧아서 대화가 끝나면 작업 메모리가 비워지고, 다음 대화는 처음부터 시작합니다.

기술 구현에서는 대부분의 프레임워크가 Redis 또는 KV Store를 백엔드로 사용하고 Checkpointer로 상태를 주기적으로 저장합니다. LangGraph의 MemorySaver가 대표적인 예입니다. 노드 실행이 끝날 때마다 상태 스냅샷을 메모리나 데이터베이스에 저장합니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

일화 메모리(Episodic Memory)

일화 메모리는 ‘무슨 일이 있었는가’를 기록합니다. 사용자가 지난번에 어떤 질문을 했는지, Agent가 어떻게 답했는지, 중간에 어떤 결정을 내렸는지 같은 이벤트를 시간순으로 저장하는 장부와 같습니다.

작업 메모리와 달리 일화 메모리는 세션이 바뀌어도 유지됩니다. 오늘 대화가 끝나도 내일 대화에서 지난 이벤트 기록을 확인할 수 있습니다.

일반적으로 이벤트 스트림(Redis Streams)이나 시계열 데이터베이스에 저장합니다. 핵심 최적화 전략은 ‘요약 압축’입니다. 원본 이벤트가 길더라도 LLM으로 간결하게 요약하면 핵심 정보는 유지하면서 저장 및 검색 비용을 아낄 수 있습니다.

의미 메모리(Semantic Memory)

의미 메모리는 ‘무엇을 알고 있는가’를 담습니다. ‘사용자는 중국어 답변을 선호한다’, ‘회사 본사는 상하이에 있다’, ‘제품 A의 가격은 500위안이다’ 같은 추상적인 지식과 사실을 저장합니다.

이 정보는 언제, 어느 대화에서 알게 되었는지가 아니라 지식 그 자체만 중요합니다.

주로 벡터 데이터베이스(Pinecone, Weaviate, Milvus)와 지식 그래프를 함께 사용해 저장합니다. 벡터화한 뒤 HNSW 또는 IVF 인덱스로 검색 속도를 높입니다. 지식 그래프는 ‘사용자 A는 B를 선호한다’, ‘회사 C는 D에 위치한다’와 같은 엔터티 관계를 저장합니다.

장기 메모리(Long-Term Memory)

장기 메모리는 ‘사용자가 누구인가’를 담습니다. 쉽게 바뀌지 않고 모든 세션에 걸쳐 유효한 사용자 프로필, 선호 설정, 장기 도메인 지식을 저장합니다.

저장소로는 PostgreSQL, MongoDB 또는 클라우드 공급자가 제공하는 전용 솔루션(Alibaba Cloud AnalyticDB, PolarDB) 같은 영구 데이터베이스를 사용합니다. 일반적으로 의미 검색과 RAG를 결합하고 사용자 ID 등의 속성으로 필터링해 검색합니다.

이 네 가지 메모리는 서로 고립되어 있지 않고 피라미드 구조를 이룹니다. 가장 아래의 작업 메모리는 가장 빠르지만 수명이 가장 짧고, 가장 위의 장기 메모리는 가장 오래 유지되지만 검색이 가장 느립니다. Agent는 작업 요구에 따라 여러 계층에서 정보를 가져옵니다.

3장: 5단계 메모리 파이프라인 — 추출에서 망각까지

메모리는 대화를 저장한다고 끝나는 것이 아닙니다. 추출, 통합, 저장, 검색, 망각으로 이어지는 완전한 파이프라인이 필요하며 각 단계마다 고려할 점이 있습니다.

Stage 1: 추출(Extraction)

대화의 모든 문장을 기억할 필요는 없습니다. “안녕하세요”, “감사합니다”, “잠시만요” 같은 노이즈는 저장해도 공간만 낭비합니다.

추출 단계에서는 어떤 정보를 보존할 가치가 있는지 판별합니다. 일반적인 방법은 LLM 분류와 규칙 기반 필터링을 결합하는 것입니다. LLM이 해당 정보에 장기적인 가치가 있는지 판단하고(‘사용자는 중국어 답변을 선호한다’ vs ‘사용자가 인사했다’), 규칙 필터가 지나치게 짧거나 단순한 인사말 같은 명확한 패턴을 추가로 처리합니다.

# 추출 단계 의사 코드
def extract_memories(conversation):
    candidates = []
    for message in conversation:
        # LLM 분류: 기억할 가치가 있는가?
        classification = llm.classify(message, "memory_candidate")
        if classification == "worth_remembering":
            candidates.append(message)
    # 규칙 필터링: 명확한 노이즈 제거
    candidates = filter_noise(candidates)
    return candidates

Stage 2: 통합(Consolidation)

추출된 정보에는 중복이 있을 수 있습니다. 여러 대화에서 ‘사용자는 중국어를 좋아한다’는 내용이 세 번 등장하더라도 세 개를 모두 저장할 필요는 없습니다.

통합 단계의 역할은 중복을 합치고, 기존 메모리를 갱신하고, 지식 그래프 트리플을 구축하는 것입니다.

예를 들면 다음과 같습니다.

• 기존 메모리: “사용자는 중국어 답변을 선호한다”
• 새로 추출한 정보: “사용자는 간결한 중국어 답변을 더 좋아한다고 말했다”
• 통합 후: “사용자는 간결한 중국어 답변을 선호한다”(병합 및 구체화)

# 통합 단계 의사 코드
def consolidate_memories(new_memories, existing_memories):
    for new in new_memories:
        # 기존 메모리와 중복되거나 관련이 있는지 확인
        similar = find_similar(new, existing_memories)
        if similar:
            # 병합 또는 갱신
            merged = llm.merge(new, similar)
            update_memory(similar.id, merged)
        else:
            # 새 메모리 추가
            add_memory(new)

Stage 3: 저장(Storage)

저장 단계에서는 저장 형식과 인덱스 방식이라는 두 가지 핵심 결정을 내려야 합니다.

저장 형식은 메모리 유형에 따라 달라집니다. 작업 메모리에는 KV Store, 일화 메모리에는 이벤트 스트림, 의미 메모리에는 벡터 데이터베이스, 장기 메모리에는 관계형 데이터베이스를 사용합니다.

인덱스 방식은 검색 성능에 영향을 줍니다. 대표적인 선택지는 HNSW와 IVF입니다.

• HNSW: 중소 규모 데이터 세트(10만~100만 규모)에 적합합니다. 같은 지연 시간에서 재현율이 더 높지만 메모리 사용량이 큽니다.
• IVF: 대규모 데이터 세트(100만~1억 규모)에 적합합니다. 메모리 효율은 높지만 정확도가 약간 낮습니다.

Redis 블로그 데이터에 따르면 HNSW는 같은 지연 시간 목표에서 일반적으로 더 높은 재현율을 제공하고, IVF는 대규모 데이터에서 메모리를 더 적게 사용합니다. 데이터 규모와 정확도 요구 사항에 맞춰 선택해야 합니다.

Stage 4: 검색(Retrieval)

Agent가 메모리를 사용해야 할 때 검색 단계에서 관련 정보를 찾아옵니다.

순수 벡터 검색만으로는 정확도가 부족할 때가 있습니다. 더 나은 방법은 벡터 검색, 전체 텍스트 검색, 속성 필터링을 결합한 ‘하이브리드 검색’입니다.

예를 들어 사용자가 “지난번에 말한 창고 주소가 뭐였죠?”라고 묻는다면 다음 순서로 처리합니다.

1. 벡터 검색: 의미가 비슷한 메모리(‘창고 주소’, ‘물류 정보’) 찾기
2. 속성 필터링: 해당 사용자의 메모리만 확인하기
3. 시간순 정렬: 최신 메모리를 우선 반환하기

# 하이브리드 검색 의사 코드
def retrieve_memories(query, user_id):
    # 벡터 검색
    vector_results = vector_db.search(query, top_k=20)
    # 속성 필터링: 현재 사용자의 메모리만 확인
    filtered = [m for m in vector_results if m.user_id == user_id]
    # 시간순 정렬: 최신 항목 우선
    sorted_results = sort_by_time(filtered, descending=True)
    return sorted_results[:5]

Stage 5: 망각(Forgetting)

망각은 부정적으로 들리지만 메모리 시스템에서는 매우 중요합니다. 잊지 않으면 저장소가 끝없이 커지고 노이즈가 가치 있는 정보를 덮어 버립니다.

망각 전략은 크게 두 가지입니다.

시간 감쇠: 시간이 지날수록 메모리의 중요도가 낮아집니다. 한 달 전의 선호 설정은 이미 달라졌을 수 있으므로 가중치를 자동으로 낮춥니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

중요도 기반 제거: 접근 빈도, 사용자 피드백, 검증 횟수 등의 지표로 중요도를 평가합니다. 중요도가 낮은 메모리는 정기적으로 정리합니다.

쉽게 놓치는 문제 중 하나는 ‘일회성 오류의 고착화’입니다. 사용자가 무심코 잘못된 정보를 한 번 말했는데 Agent가 이를 ‘사실’로 저장하면 매우 위험합니다. 통합 단계에 검증 로직을 추가하거나, 신뢰도가 낮은 메모리에 ‘확인 필요’ 표시를 붙여 해결할 수 있습니다.

4장: 프레임워크 비교 — Mem0 vs Zep vs LangMem vs LangChain

이미 성숙한 메모리 프레임워크가 있으므로 처음부터 새로 만들 필요는 없습니다. 문제는 무엇을 선택하느냐입니다.

네 프레임워크는 저마다 특징이 있습니다. 먼저 비교표를 보겠습니다.

선택 의사 결정 트리

프레임워크를 선택하기 전에 먼저 세 가지 질문을 해 보세요.

Q1: 지식 그래프가 필요한가?
    → 예 → Mem0 Pro 또는 Zep(둘 다 성숙한 그래프 기능 제공)
    → 아니요 → Q2로 이동

Q2: 관리형 서비스가 필요한가?
    → 예 → Mem0(간단한 시작) 또는 MemoClaw(API Key 설정 불필요)
    → 아니요 → Q3로 이동

Q3: LangGraph를 사용하는가?
    → 예 → LangMem(네이티브 통합, 추가 의존성 없음)
    → 아니요 → 직접 구현(LangChain Checkpointer + 벡터 데이터베이스)

실제 상황별 추천

지능형 고객 지원 → Mem0

고객 지원 Agent는 사용자 선호, 과거 주문, 불만 기록을 기억해야 합니다. 이런 정보는 ‘사용자 A가 제품 B를 구매했다’, ‘사용자 A가 문제 C에 대해 불만을 제기했다’처럼 지식 그래프에 저장하기 좋습니다. Mem0 관리형 버전은 운영 비용을 줄여 주며 Pro 버전은 그래프 기능을 제공합니다.

의료 진단 Agent → Zep

의료 분야에는 증상이 언제 나타났는지, 약물을 언제 조정했는지, 검사 결과가 어느 시점에 바뀌었는지처럼 복잡한 엔터티 관계와 타임라인이 있습니다. Zep의 핵심 강점은 ‘시간 순서가 있는 사실’(Temporal Facts)로, 이벤트의 시간 차원을 정확하게 추적할 수 있어 병력 추론이 필요한 분야에 적합합니다.

내부 도구 Agent → LangMem

Agent가 이미 LangGraph로 구축되어 있다면 LangMem을 바로 추가하는 것이 가장 간단합니다. LangGraph의 네이티브 라이브러리라서 추가 의존성이 필요 없고 Checkpointer와 메모리 저장소가 통합되어 있습니다.

빠른 프로토타입 검증 → MemoClaw

계정을 등록하거나 API Key를 설정하지 않고 메모리 시스템의 효과를 먼저 시험해 보고 싶나요? MemoClaw는 ‘서비스형 메모리’를 제공하므로 store/recall 두 인터페이스를 간단히 호출하면 됩니다. 프로토타입 단계에는 적합하지만 프로덕션급 프로젝트에는 더 강력한 프레임워크가 필요할 수 있습니다.

Mem0의 통합 생태계

Mem0의 통합 범위도 주목할 만합니다. Mem0 공식 블로그의 2026년 초 데이터에 따르면 OpenAI, LangChain, LlamaIndex, CrewAI, AutoGen 등 21개 프레임워크 및 플랫폼과 이미 통합할 수 있습니다. 주류 프레임워크를 사용한다면 기존 통합 패키지가 있을 가능성이 높습니다.

5장: 프로덕션급 구현 — 비용 관리와 성능 최적화

데모가 실행된다고 프로덕션에서도 잘 작동하는 것은 아닙니다. 메모리 시스템을 출시하기 전에 성능이 충분히 빠른지, 비용이 충분히 낮은지, 보안이 안정적인지라는 세 가지 문제를 해결해야 합니다.

인덱스 선택: 정확도 vs 규모

벡터 검색의 성능 병목은 인덱스입니다. 대표적인 선택지는 세 가지입니다.

FLAT: 무차별 검색 방식으로 정확도는 완벽하지만 느립니다. 소규모 데이터(1만 미만)나 100% 정확도가 필요한 분야에 적합합니다.

HNSW: 계층적 소규모 세계 그래프로 재현율이 높고 빠릅니다. 중소 규모(10만~100만)에 적합하지만 메모리 사용량이 비교적 많아 벡터 100만 개당 대략 수 GB의 메모리가 필요합니다.

IVF: 역파일 인덱스로 벡터를 버킷에 나눈 뒤 검색할 때 일부 버킷만 탐색합니다. 대규모(100만~1억)에 적합하고 메모리 효율이 높지만, 대상 버킷 밖의 관련 벡터를 놓칠 수 있어 정확도가 약간 낮습니다.

선택 기준은 간단합니다. 데이터가 적으면 FLAT 또는 HNSW, 데이터가 많으면 IVF를 선택합니다. 의료 진단처럼 정확도가 특히 중요해 속도를 희생하더라도 높은 재현율이 필요하다면 HNSW가 적합합니다.

지연 시간 최적화: 초 단위에서 밀리초 단위로

사용자가 한마디를 하면 Agent가 메모리를 검색하고 추론한 뒤 답변을 생성합니다. 각 단계의 지연 시간이 누적됩니다. 전체 컨텍스트 방식이 느린 이유는 추론 전에 매우 긴 컨텍스트를 처리해야 하기 때문이며, p95 지연 시간이 17초에 이를 수 있습니다.

최적화 방법은 검색을 추론 전에 수행하되 빠르게 만드는 것입니다.

Redis는 통합 플랫폼으로서 1밀리초 미만의 쿼리를 처리할 수 있습니다. 벡터 검색, 이벤트 스트림, KV 저장소를 모두 지원하므로 작업 메모리, 일화 메모리, 의미 메모리를 한곳에 둘 수 있고 서비스 간 호출에 따른 네트워크 지연도 줄일 수 있습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

또 다른 함정은 ‘여러 차례의 추론 누적’입니다. 일부 설계는 검색 → LLM으로 검색 결과 정리 → 다시 추론해 답변하는 방식입니다. LLM을 두 번 호출해 지연 시간이 두 배가 됩니다. 더 나은 방법은 검색 결과를 컨텍스트에 바로 주입하고 한 번의 추론으로 처리하는 것입니다.

비용 관리: 10배 차이의 비결

앞서 전체 컨텍스트와 선택적 기억의 비용 차이가 10배라고 언급했습니다. 어떻게 가능한 걸까요?

핵심 전략은 세 가지입니다.

선택적 기억: 모든 대화 기록을 넣지 않고 가치 있는 정보만 저장합니다. 추출 단계에서 노이즈를 걸러 내고 저장 단계에서 메모리 수를 제한합니다.

요약 압축: 원본 대화가 수천 자라도 요약하면 수백 자가 됩니다. LLM으로 일화 메모리를 주기적으로 간결한 버전으로 압축해 토큰 사용량을 줄입니다.

지능형 망각: 저장소는 끝없이 커질 수 있으므로 중요도가 낮은 메모리를 정기적으로 정리합니다. 시간 감쇠와 접근 빈도 기반 제거를 통해 메모리 풀을 관리 가능한 규모로 유지합니다.

Mem0 공식 팀의 추산에 따르면 선택적 기억 방식은 월 비용을 100만 달러에서 10만 달러로 줄일 수 있습니다. 주로 토큰 비용과 저장 비용이 감소하기 때문입니다.

보안과 개인정보 보호: 메모리 격리

메모리 시스템은 사용자 데이터를 저장하므로 보안 설계를 소홀히 해서는 안 됩니다.

메모리 격리: 각 사용자의 메모리를 독립적으로 저장하고 검색할 때 user_id로 엄격하게 필터링합니다. ‘사용자 A가 사용자 B의 메모리를 검색하는’ 사고가 절대 발생해서는 안 됩니다.

메모리 오염 방어: 악의적인 사용자가 Agent가 잘못된 사실을 기억하도록 의도적으로 허위 정보를 입력할 수 있습니다. 통합 단계에 검증 로직을 두어 신뢰도가 낮은 정보에 ‘확인 필요’ 표시를 붙이고 장기 메모리에 바로 기록하지 않도록 해야 합니다.

데이터 비식별화: 휴대전화 번호, 주민등록번호 같은 민감 정보는 저장 전에 마스킹해야 합니다. 검색 후 복원할 때도 권한을 통제해야 합니다.

일관성 유지: 분산 락 + 성찰

다중 인스턴스 배포에서는 메모리 일관성이 문제가 됩니다. 인스턴스 A가 메모리를 갱신해도 인스턴스 B는 여전히 이전 버전을 사용할 수 있습니다.

두 가지 메커니즘으로 해결할 수 있습니다.

분산 락 + 버전 관리: 메모리를 갱신하기 전에 락을 걸고, 갱신 후 새 버전을 기록합니다. 검색 시 기본적으로 최신 버전을 가져오면 오래된 데이터를 읽는 일을 피할 수 있습니다.

주기적 성찰: LLM이 메모리 저장소를 정기적으로 검사해 모순되거나 오래된 정보를 찾아 능동적으로 정리하거나 갱신하게 합니다. Alibaba Cloud AnalyticDB 솔루션에는 이 메커니즘이 기본 제공됩니다.

결론

결국 메모리 시스템은 Agent의 ‘선택 기능’이 아니라 일반 LLM 인터페이스와 Agent를 구분하는 핵심 역량입니다. 메모리가 없는 Agent에게는 매 대화가 새로운 만남입니다. 사용자를 진정으로 ‘이해’할 수도, 장기 작업에서 일관성을 유지할 수도 없습니다.

그러나 메모리 시스템을 장착한다고 모든 일이 한 번에 해결되는 것은 아닙니다. 지식 그래프가 필요한지, 관리형 서비스를 받아들일 수 있는지, 현재 프레임워크가 무엇에 결합되어 있는지 먼저 생각해야 합니다. 이 질문에 답하면 프레임워크 선택도 자연스럽게 명확해집니다.

여전히 확신이 없다면 LangMem 또는 Mem0 오픈 소스 버전부터 실험해 보기를 권합니다. 투입 비용이 가장 적고 효과도 가장 직관적입니다. 작업 메모리에 익숙해진 뒤 일화 메모리와 장기 메모리로 확장해도 늦지 않습니다.