AI Agent 메모리 관리: 장기 기억과 지식 거버넌스 실전

2026-06-08 업데이트: LOCOMO 벤치마크와 각 프레임워크의 기준을 다시 확인했습니다(Mem0 / Letta / Zep / Cognee는 모두 현재 사용 중입니다). 오래된 모델 요금 표현을 일반적인 설명으로 바꾸고 같은 주제의 추가 읽을거리도 보완했습니다. 프레임워크와 벤치마크는 빠르게 바뀌므로 수치는 공식 자료를 기준으로 확인하세요.

“지난번에 확인해 달라고 한 그 주문은 어떻게 됐나요?”

사용자가 이 질문을 던지는 순간 고객 지원 Agent가 멈췄습니다. 현재 대화의 컨텍스트를 아무리 뒤져도 “주문”에 관한 기록이 없었습니다. 해당 조회는 어제 오후, 다른 세션에서 이뤄졌기 때문입니다.

이건 Bug가 아닙니다. 기억 상실입니다.

이 문제를 처음 만났을 때는 꽤 까다로웠습니다. Agent는 답변을 훌륭하게 해냈고 사용자 경험도 좋았지만, 사용자가 창을 바꾸거나 브라우저를 닫거나 몇 시간 뒤에 돌아오기만 해도 모든 것이 초기화됐습니다. Agent는 사용자의 선호를 기억하지 못하고, 이전에 내린 결정도 기억하지 못하며, 왜 그렇게 결정했는지는 더더욱 기억하지 못했습니다.

더 큰 문제는 컨텍스트 창을 단순히 늘리는 것으로는 해결할 수 없다는 점입니다. 오히려 믿기 어렵겠지만 Agent를 더 둔하게 만듭니다. 이것이 이른바 “컨텍스트 부패”입니다. 관련 없는 정보가 잡음처럼 모델의 주의력을 희석하고, 검색 비용은 기하급수적으로 늘며, 지연 시간은 수백 밀리초에서 10여 초까지 치솟습니다.

그렇다면 Agent가 실제로 “기억”하려면 어떻게 해야 할까요? 대화를 데이터베이스에 저장하는 것만으로는 부족합니다. 사람처럼 중요한 것은 기억하고 사소한 것은 잊으며, 필요할 때 떠올리고, 의사 결정을 내릴 때 그 이유를 추적할 수 있어야 합니다.

이제 Agent 메모리 시스템의 기반 논리를 살펴보겠습니다. 세 가지 기억 유형(대부분은 두 가지만 압니다), 주요 프레임워크 6종의 선택 방법, 벡터 데이터베이스의 사각지대를 지식 그래프가 보완하는 방식, 그리고 실제 구현에서 겪기 쉬운 문제를 차례로 설명합니다.

Agent에 독립적인 메모리 시스템이 필요한 이유

컨텍스트 부패: 창이 클수록 오히려 나빠지는 이유

먼저 Agent의 기억 능력을 전문적으로 평가하는 권위 있는 데이터셋인 LOCOMO 벤치마크의 수치를 보겠습니다.

표면적으로는 Full-context의 정확도가 더 높습니다. 하지만 10초를 기다릴 수 있을까요? 더 중요한 문제는 Token 사용량이 13배나 차이 난다는 점입니다. 주요 대규모 언어 모델의 요금을 기준으로 하면 대화 한 번마다 컨텍스트 비용만 수 센트에서 수십 센트까지 발생할 수 있습니다.

창이 클수록 성능이 오히려 나빠질 수 있는 이유는 무엇일까요?

도서관에서 책 한 권을 찾는다고 생각해 봅시다. 책이 10권뿐이라면 한눈에 찾을 수 있습니다. 하지만 책이 10만 권이라면 모든 책의 표지를 동시에 볼 수 있더라도 원하는 책을 찾는 데 오랜 시간이 걸립니다.

모델의 어텐션 메커니즘도 같습니다. 컨텍스트 창에 정보가 많이 들어갈수록 각 정보에 배분되는 모델의 주의력은 줄어듭니다. 관련 없는 과거 대화, 오래된 작업 상태, 이미 해결된 문제 등이 한꺼번에 뒤섞이면 모델은 무엇이 중요한지 오히려 구분하기 어려워집니다.

이것이 컨텍스트 부패입니다. 정보가 많아질수록 신호 대 잡음비는 낮아집니다.

이전에 실험을 한 적이 있습니다. Agent에게 100번의 대화가 끝난 뒤 첫 번째 대화에서 언급된 세부 사항을 물었습니다. 결과는 어땠을까요? 전체 컨텍스트 방식의 정확도는 90%에서 60%로 떨어졌습니다. 반면 메모리 시스템을 사용한 방식은 85% 이상을 안정적으로 유지했습니다.

”도구”에서 “파트너”로: 세션 경계를 넘는 기억

기억이 없는 Agent는 기껏해야 고급 도구에 불과합니다. 사용이 끝나면 사용자를 잊습니다.

기억이 있는 Agent만이 진정한 “파트너”가 될 수 있습니다. 간결한 답변을 좋아한다는 점, 지난번에도 비슷한 질문을 했다는 점, 프로젝트에서 Vue가 아니라 React를 사용한다는 점을 기억합니다. 사용자가 매번 같은 정보를 반복할 필요가 없습니다.

Letta 팀(MemGPT를 만든 회사)은 장기간 실행되는 코딩 도우미를 좋은 사례로 들었습니다. 이 도우미는 프로젝트의 코드 스타일, 이전에 겪은 bug와 해결 방법, 자주 사용하는 서드파티 라이브러리까지 기억합니다. 사용자가 “비슷한 함수를 하나 더 작성해 줘”라고 말하면 “비슷한” 것이 무엇인지 압니다. 지난번에 작성한 함수를 기억하기 때문입니다.

이처럼 세션을 넘나드는 연속성은 Agent가 “도구”에서 “파트너”로 진화하는 기반입니다.

세 가지 핵심 기억 유형: 단기, 장기, 추론(대부분은 세 번째를 놓칩니다)

Agent 메모리라고 하면 많은 사람이 단기 기억과 장기 기억만 떠올립니다. 하지만 세 번째 유형인 Reasoning Memory(추론 기억)가 있으며, 대부분의 시스템에는 바로 이 기억이 빠져 있습니다.

하나씩 살펴보겠습니다.

단기 기억(Short-term Memory): 현재 컨텍스트 창입니다. 용량이 제한적이고 정보가 최신이며 세션이 끝나면 사라집니다. 전원이 꺼지면 내용이 사라지는 RAM으로 이해할 수 있습니다.

장기 기억(Long-term Memory): 외부 스토리지에 저장된 정보입니다. 벡터 데이터베이스, 관계형 데이터베이스, 지식 그래프 등이 될 수 있습니다. 용량이 크고 영구적이며 검색할 수 있습니다. 언제든 읽고 쓸 수 있는 하드 디스크와 비슷합니다.

추론 기억(Reasoning Memory): 가장 놓치기 쉬운 유형입니다. Agent의 의사 결정 과정, 즉 A가 아니라 B를 선택한 이유, 당시의 제약 조건, 중간 추론 과정이 어땠는지를 기록합니다. 추론 기억이 없으면 Agent는 결정을 내리고도 “왜” 그렇게 했는지 설명할 수 없습니다. 설명 가능성, 디버깅, 지속 학습에 모두 매우 중요합니다.

Neo4j 기술 블로그에서는 이를 정확하게 표현한 문장이 있습니다. “실행은 하지만 의사 결정 과정을 설명하지 못하는 Agent는 일은 하지만 회고하지 못하는 직원과 같습니다. 단기적으로는 괜찮아도 장기적으로는 반드시 문제가 생깁니다.”

제가 살펴본 프레임워크 가운데 추론 기억을 구현한 것은 Letta와 Zep 같은 일부에 불과합니다. 대부분은 아직도 “대화를 벡터 데이터베이스에 저장하는” 단계에 머물러 있습니다.

Agent 메모리의 인지 아키텍처

4계층 메모리 모델

운영체제와 인지과학의 설계를 참고해 현대 Agent 메모리 시스템은 대개 계층형 아키텍처를 사용합니다. 가장 대표적인 형태는 Letta/MemGPT의 4계층 모델입니다.

Layer 1: Message Buffer(메시지 버퍼)
    ↓ 넘치면 압축
Layer 2: Core Memory(핵심 기억)
    ↓ 능동적으로 기록
Layer 3: Recall Memory(회상 기억)
    ↓ 필요할 때 검색
Layer 4: Archival Memory(보관 기억)

Message Buffer: 현재 대화의 컨텍스트 창으로, 용량이 제한적입니다(예: 4K 또는 8K Token). 버퍼가 거의 가득 차면 시스템은 오래된 메시지를 요약으로 압축해 새 메시지를 위한 공간을 확보합니다.

Core Memory: 현재 작업과 가장 관련성이 높은 정보를 저장하는, 세심하게 관리되는 작은 “작업 기억”입니다. 사용자의 선호, 현재 목표, 최근 결정 등이 여기에 들어갑니다. 용량은 대략 수백에서 수천 Token이며, 컨텍스트 창 안에 유지되므로 모델이 생성할 때마다 볼 수 있습니다.

Recall Memory: 과거 대화를 벡터로 저장한 공간입니다. Agent가 “지난번에 사용자가 무엇을 물었는지” 떠올려야 할 때 여기서 검색합니다. 의미 유사도뿐 아니라 시간 범위나 키워드 등도 검색 조건으로 사용할 수 있습니다.

Archival Memory: “나중에는 유용할 수 있지만 지금은 필요 없는” 정보를 보관하는 장기 스토리지입니다. 6개월 전 사용자의 대화나 이미 완료된 작업 기록 등이 여기에 해당합니다.

이 계층형 설계의 장점은 무엇일까요? 코드를 작성할 때 Core Memory는 머릿속 정보와 편집기에 열어 둔 몇 개의 파일이고, Recall Memory는 Git 기록과 프로젝트 문서이며, Archival Memory는 컴퓨터의 다른 프로젝트와 온라인 자료실이라고 생각하면 됩니다. 가까운 계층일수록 접근은 빠르지만 용량이 작고, 먼 계층일수록 용량은 크지만 접근은 느립니다.

MemGPT의 운영체제식 관리

MemGPT(현재의 Letta)의 설계 철학은 흥미롭습니다. Agent의 메모리 관리를 운영체제의 메모리 관리에 비유합니다.

운영체제에서 RAM은 제한되어 있고 하드 디스크는 사실상 훨씬 큽니다. RAM이 부족하면 시스템은 일부 데이터를 하드 디스크로 Swap하고 필요할 때 다시 불러옵니다.

MemGPT도 비슷하게 설계됐습니다.

• RAM = 컨텍스트 창(제한적, 비쌈, 빠름)
• Disk = 외부 스토리지(사실상 무제한, 저렴함, 느림)

Agent에는 “자체 관리” 메커니즘이 있습니다. 컨텍스트 창 안에서 운영체제가 페이지 테이블을 관리하듯 “Core Memory Block”을 유지합니다. Core Memory가 가득 차면 Agent는 일부 정보를 외부 스토리지로 능동적으로 “축출”하고, 보관된 정보가 필요할 때 외부 스토리지에서 직접 “회상”합니다.

이 설계의 핵심은 무엇을 남기고, 무엇을 지우며, 무엇을 검색할지 Agent가 스스로 결정한다는 점입니다. 규칙에 하드 코딩하는 대신 현재 작업에 따라 Agent가 동적으로 조정하게 합니다.

구체적인 예를 들어 보겠습니다. Core Memory Block의 데이터 구조는 다음과 같습니다.

{
  "label": "user_preferences",
  "description": "사용자 환경 설정",
  "value": "간결한 답변을 선호하고 한국어를 사용하며 React 기술 스택을 자주 사용함",
  "limit": 2000
}

limit에 가까워지면 Agent는 압축(핵심 정보 추출), 분할(여러 Block으로 나누기), 축출(Archival Memory로 이동) 중 하나를 선택할 수 있습니다.

Sleep-time Compute: 응답을 막지 않는 비동기 메모리 처리

이는 Letta가 제시한 영리한 설계입니다.

기존 방식은 대화가 끝날 때마다 핵심 정보 추출, 벡터 인덱스 갱신, 요약 생성 같은 메모리 작업을 즉시 처리합니다. 이 과정이 응답을 막기 때문에 사용자는 기다려야 합니다.

Sleep-time Compute는 대화 중에 원본 데이터를 먼저 큐에 넣고 곧바로 응답을 반환합니다. Agent가 “쉬는”(sleep) 동안 메모리를 천천히 처리합니다.

장점은 분명합니다.

1. 사용자가 체감하는 지연 시간이 크게 줄어듭니다
2. 시간 초과를 걱정하지 않고 지식 그래프 구축 같은 복잡한 메모리 처리를 할 수 있습니다
3. 일괄 처리 효율이 높아지고 비용이 낮아집니다

물론 메모리 갱신이 지연된다는 대가가 있습니다. 고객 지원, 도우미, 코딩 파트너 같은 대부분의 시나리오에서는 몇 초에서 몇 분 정도의 지연을 받아들일 수 있습니다. 하지만 실시간 대화 중 감정 인식처럼 실시간 메모리가 필요한 시나리오에는 잘 맞지 않습니다.

기억 축출과 재귀 요약: 연속성을 위해 70% 유지

컨텍스트 창이 가득 차면 무엇을 지우고 무엇을 남길지는 어떻게 결정할까요?

간단한 전략은 재귀 요약입니다. 오래된 대화를 짧은 요약으로 압축해 핵심 정보를 남기고 세부 내용을 버립니다.

하지만 얼마나 압축해야 할까요? 지나치게 압축하면 핵심 정보가 사라지고, 너무 적게 압축하면 공간이 여전히 부족합니다.

Letta 팀의 실험 데이터는 참고값을 제시합니다. 정보량의 70%를 유지하는 것이 연속성과 압축률 사이의 최적 균형점입니다.

구체적으로 어떻게 할까요? 현재 컨텍스트 창에 메시지 100개가 있고 가득 찼다고 가정해 보겠습니다.

1. 앞의 메시지 50개를 500 Token 분량의 요약으로 압축합니다
2. 요약에는 사용자 목표, 핵심 제약, 중요한 결정, 해결되지 않은 문제를 남깁니다
3. 원본 데이터는 Archival Memory로 옮겨 나중에 필요할 때 검색할 수 있게 합니다
4. 새로운 컨텍스트 창 = 요약 + 뒤의 메시지 50개 + 새 메시지

이렇게 하면 연속성(Agent가 이전에 무슨 일이 있었는지 아는 것)을 유지하면서 공간을 확보해 대화를 계속할 수 있습니다.

지식 거버넌스: 기억의 수명 주기 관리

기억은 “저장하면 끝”이 아닙니다. 포착, 압축, 저장, 검색, 감쇠, 정리라는 수명 주기가 있고 각 단계에 전략이 필요합니다.

세 가지 기억의 TTL 전략: 사용자 선호 vs 작업 상태 vs 작업 로그

TTL(Time To Live, 유효 기간)은 메모리 관리의 핵심 매개변수입니다. 기억 유형마다 TTL은 완전히 다릅니다.

사용자 장기 기억: TTL이 무제한이거나 매우 깁니다(수년). 사용자 이름, 선호, 자주 쓰는 도구, 기술 스택 선택 등이 해당합니다. 자주 바뀌지 않으므로 장기간 보관해야 합니다.

작업 기억: TTL을 설정할 수 있습니다(몇 시간에서 며칠). 현재 프로젝트의 컨텍스트, 최근 bug 기록, 진행 중인 결정 등이 해당합니다. 작업이 끝나면 기억을 정리하거나 보관할 수 있습니다.

이벤트 기억: TTL이 짧습니다(몇 분에서 몇 시간). 현재 대화 차례, 임시 계산 결과, 방금 검색한 정보 등이 해당합니다. 사용이 끝나면 버릴 수 있습니다.

모든 기억을 하나의 벡터 데이터베이스에 넣고 TTL을 전혀 구분하지 않는 프로젝트를 적지 않게 봤습니다. 그 결과 벡터 데이터베이스는 계속 커지고 검색은 느려졌으며 오래되고 관련 없는 정보가 대량으로 회상됐습니다.

합리적인 방법은 세 가지 스토리지를 따로 사용하고 각각 다른 TTL과 정리 전략을 적용하는 것입니다.

사용자 장기 기억 → 벡터 데이터베이스(TTL 없음, 정기 압축)
작업 기억 → 관계형 데이터베이스 + 벡터(작업 주기에 따른 TTL)
이벤트 기억 → 메모리 또는 Redis(짧은 TTL, 자동 만료)

요약 압축의 기술: 200자 구조화 요약

100번의 대화를 한 문단으로 압축하는 일은 간단해 보이지만 실제로는 세부 고려 사항이 많습니다.

요약이 너무 단순하면 정보가 사라집니다. 너무 복잡하면 모델이 이해하기 어렵습니다.

Letta는 효과가 좋은 구조화 템플릿을 제시했습니다.

{
  "goals": ["사용자가 달성하려는 목표"],
  "constraints": ["사용자의 제약 조건"],
  "decisions": ["Agent가 내린 결정"],
  "open_questions": ["아직 해결되지 않은 문제"],
  "evidence_index": ["중요한 정보의 출처 인덱스"]
}

각 대화가 끝날 때 Agent는 약 200자로 구성된 이런 구조화 요약을 생성합니다. 장점은 다음과 같습니다.

1. 명확한 구조: 모델은 각 부분의 의미를 바로 알 수 있습니다
2. 높은 정보 밀도: 핵심만 남기고 불필요한 내용을 제거합니다
3. 추적 가능성: evidence_index가 원본 데이터를 가리키므로 세부 내용이 필요하면 조회할 수 있습니다

이전에 “이 대화는 사용자의 주문 조회에 관한 내용입니다…” 같은 비구조화 요약을 시도해 봤습니다. 결과는 훨씬 나빴습니다. 모델이 읽으면서 핵심 정보를 빠르게 찾기 어려웠고 검색에도 적합하지 않았습니다.

검색 주입 전략: 언제 능동적으로 주입하고 언제 수동으로 검색할 것인가

메모리 검색에는 능동 주입과 수동 검색이라는 두 가지 방식이 있습니다.

능동 주입: 생성할 때마다 관련 기억을 컨텍스트에 자동으로 넣습니다. 기억량이 많지 않고 실시간성이 중요한 시나리오에 적합합니다. 단점은 기억이 너무 많으면 컨텍스트 공간을 차지한다는 것입니다.

수동 검색: 필요할 때만 조회합니다. 모델이 “검색 요청”을 생성한 뒤 벡터 데이터베이스나 지식 그래프에서 찾습니다. 기억량이 많고 지연 시간에 민감한 시나리오에 적합합니다. 단점은 검색 지연이 한 번 더 생긴다는 것입니다.

Letta는 Core Memory는 능동적으로 주입하고 Recall/Archival Memory는 수동으로 검색할 것을 권합니다.

무슨 뜻일까요? Core Memory의 정보(사용자 선호, 현재 목표)는 매번 생성할 때 반드시 알아야 하므로 컨텍스트에 능동적으로 주입합니다. Recall과 Archival에 있는 과거 정보는 모델이 “기억을 떠올려야 한다”고 판단할 때만 검색합니다.

이를 위해 모델은 언제 자료를 찾아야 하는지 아는 “자기 인식”이 필요합니다. GPT-5나 Claude 같은 최첨단 모델은 이 부분에서 좋은 성능을 보이며 Prompt로 유도할 수 있습니다. 소형 모델에는 더 명확한 규칙이 필요합니다.

기억 감쇠와 정리: “기억 팽창” 방지

기억 팽창은 실제로 발생하는 문제입니다. 사용 기간이 길수록 기억이 늘고 검색은 느려지며 회상되는 정보도 더 복잡해집니다.

해결 방법은 감쇠와 정리입니다.

감쇠: 각 기억에는 “중요도 점수”가 있으며 시간이 지나면서 점차 낮아집니다. 오랫동안 검색되거나 사용되지 않으면 점수가 임계값까지 내려가 보관 또는 삭제가 실행됩니다.

정리: 메모리 저장소를 정기적으로 스캔해 만료되거나 중복되거나 가치가 낮은 기억을 삭제합니다.

구체적인 구현은 다음과 같은 메모리 인덱스 설계를 참고할 수 있습니다.

{
  "memory_id": "mem_001",
  "content": "사용자는 React 기술 스택을 선호함",
  "importance": 0.85,
  "last_accessed": "2026-04-12",
  "access_count": 23,
  "decay_rate": 0.01
}

매일 새벽에 정리 작업을 실행합니다.

• importance < 0.2 → 삭제
• 중복 기억 → 병합
• expired TTL → 보관

이렇게 하면 메모리 저장소의 크기를 제어할 수 있고 검색 효율도 안정적으로 유지되어 시간이 흐르면서 팽창하는 문제를 막을 수 있습니다.

기술 선택: 벡터 데이터베이스 vs 지식 그래프

벡터 데이터베이스의 장점과 한계: 의미 검색으로는 관계를 복원할 수 없습니다

벡터 데이터베이스는 현재 가장 널리 쓰이는 메모리 저장 방식입니다. Pinecone, Weaviate, Milvus, Qdrant 같은 이름은 한 번쯤 들어봤을 것입니다.

핵심 기능은 의미 유사도 검색입니다. 텍스트를 벡터로 변환해 가장 가까운 이웃을 찾습니다.

“사용자는 간결한 답변을 좋아함”과 “사용자는 짧은 응답을 선호함”은 벡터 공간에서 가까이 있어 서로 검색할 수 있습니다. 이것이 벡터 데이터베이스의 강점입니다.

하지만 벡터 데이터베이스에는 치명적인 사각지대가 있습니다. “관계”를 찾지 못합니다.

예를 들어 대화 기록에 다음 내용이 있다고 합시다.

• “전자상거래 프로젝트를 진행 중입니다”
• “프로젝트는 Next.js를 사용합니다”
• “백엔드는 Supabase입니다”
• “최근 결제 모듈을 처리하고 있습니다”

“프로젝트 기술 스택”을 벡터로 검색하면 “Next.js를 사용합니다”만 회상하고 “백엔드는 Supabase입니다”는 놓칠 수 있습니다. 두 문장은 의미상 충분히 비슷하지 않기 때문입니다. 하지만 실제로는 둘 다 프로젝트 기술 선택이라는 관계가 있습니다.

이때 지식 그래프가 필요합니다.

Graph RAG: Agent가 연결 관계를 이해하게 만들기

지식 그래프는 엔터티와 관계를 저장합니다.

위의 예는 지식 그래프에서 다음과 같이 표현됩니다.

(사용자) --[진행 중]--> (전자상거래 프로젝트)
(전자상거래 프로젝트) --[프론트엔드]--> (Next.js)
(전자상거래 프로젝트) --[백엔드]--> (Supabase)
(전자상거래 프로젝트) --[현재 모듈]--> (결제 모듈)

Agent가 “프로젝트의 기술 스택은 무엇인가요?”라고 물으면 그래프를 따라 탐색해 관련된 기술 선택을 모두 찾을 수 있습니다.

Neo4j 기술 블로그는 완전한 Agent 메모리 구현 방안을 소개했으며 핵심은 세 가지 그래프입니다.

1. 사용자 그래프: 사용자 프로필, 선호, 과거 행동
2. 작업 그래프: 현재 작업, 하위 작업, 종속 관계
3. 지식 그래프: 도메인 지식, 개념 관계

그래프 쿼리의 힘은 멀티홉 검색에 있습니다. 벡터는 “비슷한” 것을 찾지만 그래프는 “관련된” 것을 찾을 수 있습니다.

예를 들어 “사용자가 이 프로젝트에서 어떤 문제를 겪었나요?”라고 조회하면 그래프는 다음과 같이 탐색할 수 있습니다.

• “사용자” 노드에서 시작
• “참여한 프로젝트” 찾기
• 프로젝트와 관련된 “문제” 찾기
• 문제의 “해결 방법” 찾기

이런 멀티홉 관계 검색은 벡터 데이터베이스만으로는 할 수 없습니다.

Reasoning Memory: 의사 결정 추적의 핵심

다시 추론 기억을 살펴보겠습니다. 대부분의 프레임워크가 놓치고 있는 핵심 역량입니다.

추론 기억은 “무슨 일이 있었는지”가 아니라 “왜 그렇게 했는지”를 기록합니다.

예를 들어 다음과 같은 대화가 있습니다.

• 사용자: “로그인 페이지를 만들어 줘”
• Agent: “서드파티 로그인이 필요한가요?”
• 사용자: “필요 없어요. 이메일 로그인만 구현해 주세요”
• Agent 결정: NextAuth를 사용하고 OAuth는 통합하지 않음

추론 기억에는 다음과 같이 기록됩니다.

{
  "decision": "NextAuth를 사용하고 OAuth는 통합하지 않음",
  "reasoning": "사용자는 서드파티 로그인이 아니라 이메일 로그인만 필요로 함",
  "constraints": ["OAuth를 도입하지 않음"],
  "alternatives_considered": ["Clerk", "사용자 정의 인증"],
  "chosen_because": "NextAuth가 가볍고 요구 사항에 맞음"
}

이 기억은 어떤 가치가 있을까요?

1. 설명 가능성: 사용자가 “왜 Clerk를 사용하지 않았나요?”라고 물으면 Agent가 답할 수 있습니다
2. 디버깅: 문제가 생기면 의사 결정 과정을 추적할 수 있습니다
3. 지속 학습: 다음에 비슷한 상황이 생기면 이전 결정을 참고할 수 있습니다

Neo4j 구현에서는 추론 기억을 “의사 결정 노드”로 모델링하고 관련된 “제약 노드”와 “결과 노드”에 연결합니다. 이를 통해 의사 결정의 원인과 결과를 완전히 추적할 수 있습니다.

혼합 방식: 벡터 + 그래프 + 구조화 스토리지

지금까지 살펴본 방식 중 무엇을 선택해야 할까요?

답은 혼합 방식입니다.

벡터 데이터베이스만 사용하면 관계를 잃습니다. 지식 그래프만 사용하면 구축 비용이 높고 의미 검색이 약합니다. 관계형 데이터베이스만 사용하면 유연성과 회상 능력이 모두 부족합니다.

실무에서 가장 좋은 조합은 다음과 같습니다.

• 벡터 데이터베이스: 대화 텍스트를 저장하고 의미 검색 수행
• 지식 그래프: 엔터티 관계를 저장하고 멀티홉 추론 수행
• 관계형 데이터베이스: 구조화 데이터(사용자 정보, 작업 상태) 저장

세 가지의 협업 방식은 다음과 같습니다.

1. 사용자 질문을 먼저 벡터로 검색해 의미상 관련된 대화 조각을 회상합니다
2. 대화 조각에서 엔터티를 추출하고 그래프에서 관련 정보를 조회합니다
3. 구조화 데이터는 관계형 데이터베이스에서 직접 조회합니다

이렇게 하면 의미 검색의 유연성을 유지하면서 그래프의 관계 처리 능력과 구조화 데이터의 효율적인 조회 기능을 함께 얻을 수 있습니다.

주요 프레임워크 6종 실전 비교

이제 이론을 바탕으로 실제 프레임워크를 어떻게 선택할지 살펴보겠습니다.

Mem0: 빠른 통합과 다계층 기억

Mem0는 현재 가장 인기 있는 Agent 메모리 프레임워크 중 하나입니다. “Memory as a Service”를 표방하므로 메모리 저장과 검색을 직접 관리하지 않고 API만 호출하면 됩니다.

핵심 특징:

• 호스팅 서비스로, 인프라를 직접 구축할 필요가 없음
• 21개 프레임워크 통합 지원(LangChain, LangGraph, LlamaIndex, CrewAI 등)
• 자동 메모리 추출, 갱신, 검색
• 멀티테넌시와 다중 세션 지원

LOCOMO 벤치마크 데이터:

• 정확도: 66.9%
• 지연 시간: 0.71초
• Token 사용량: ~2K

적합한 시나리오:

• 빠른 프로토타입 개발
• 음성 Agent(지연 시간에 민감)
• 여러 프레임워크를 통합해야 하는 프로젝트

한계:

• 호스팅 서비스이므로 데이터를 직접 보유하지 않음
• 추론 기억 같은 고급 기능 지원이 제한적임
• 자체 구축 방식보다 사용자 정의 기능이 부족함

코드 예시는 다음과 같습니다.

from mem0 import Memory

m = Memory()

# 기억 추가
m.add("사용자는 간결한 답변을 좋아함", user_id="user_001")

# 기억 검색
results = m.search("사용자 선호", user_id="user_001")

# 반환: ["사용자는 간결한 답변을 좋아함"]

믿기 어려울 만큼 간단합니다. 이것이 Mem0의 가장 큰 장점입니다. 시작 비용이 낮습니다.

Letta: 장기 실행 Agent에 가장 적합한 선택

Letta(이전 이름 MemGPT)는 다른 길을 택했습니다. 메모리 관리를 운영체제식 계층 아키텍처로 설계하고 Agent의 “자체 관리” 능력을 강조합니다.

핵심 특징:

• OS 방식의 계층형 메모리: RAM(컨텍스트) + Disk(외부 스토리지)
• Agent가 메모리 읽기, 쓰기, 축출, 회상을 자율적으로 결정
• Sleep-time Compute 비동기 처리
• 완전한 추론 기억 지원

적합한 시나리오:

• 장기간 실행되는 Agent(코딩 도우미, 개인 비서 등)
• 완전한 의사 결정 추적이 필요한 프로젝트
• 높은 자율성이 필요한 시나리오

한계:

• 학습 곡선이 가파름
• 직접 배포하고 관리해야 함
• 모델 능력이 충분해야 함(소형 모델은 “자체 관리”를 잘 수행하지 못할 수 있음)

아키텍처는 다음과 같습니다.

┌─────────────────────────────────────┐
│          Agent (LLM)                │
│  ┌───────────────────────────────┐  │
│  │      Core Memory (RAM)        │  │
│  │  - Self Block: 나는...         │  │
│  │  - User Block: 사용자는...      │  │
│  │  - Task Block: 현재 작업...      │  │
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘
         ↓ 능동적 관리
┌─────────────────────────────────────┐
│    External Storage (Disk)          │
│  - Recall Memory (벡터 DB)           │
│  - Archival Memory (보관 스토리지)    │
└─────────────────────────────────────┘

사용자와 장기간 함께하는 Agent를 만들고 있다면 Letta는 현재 가장 성숙한 선택입니다.

Zep: 대화 메모리 전문가

Zep은 대화 시나리오의 메모리 관리에 집중합니다. 핵심 기능은 대화가 이어질수록 과거 내용을 계속 압축해 컨텍스트 창을 사용할 수 있게 하는 “점진적 요약”입니다.

핵심 특징:

• 점진적 요약: 대화가 길어질수록 요약이 정교해짐
• 의미 + 시간 혼합 검색
• 사실 추출: 대화에서 엔터티와 관계를 자동 추출
• 멀티모달 지원(텍스트, 이미지)

적합한 시나리오:

• 고객 지원 챗봇
• 대화형 AI 애플리케이션
• 긴 대화 기록이 필요한 시나리오

한계:

• 대화 시나리오에 더 특화되어 범용 Agent 지원은 제한적임
• 오픈 소스 버전의 기능이 제한적이고 엔터프라이즈 버전 가격이 높음

Zep의 장점 중 하나는 대화에서 “사실”을 자동으로 감지할 수 있다는 점입니다. “사용자 이름은 김민수”, “사용자는 서울에 거주” 같은 정보를 추출해 구조화 데이터로 저장합니다. 따라서 다음 대화에서는 과거 기록을 뒤지지 않고 바로 사용할 수 있습니다.

Cognee: 지식 그래프 방식

Cognee는 지식 그래프 메모리에 특화된 프레임워크입니다. 강력한 관계 추론 능력이 필요하다면 우선 고려할 수 있습니다.

핵심 특징:

• 지식 그래프 자동 구축
• 다양한 그래프 데이터베이스 지원(Neo4j, NetworkX 등)
• 엔터티 추출 + 관계 추출 파이프라인
• 증분 갱신 지원

엔터티 추출 비용 비교:

방법	지연 시간	품질	비용
spaCy	~5ms	중간	낮음
GLiNER2	~50ms	높음	중간
LLM	~500ms	가장 높음	높음

적합한 시나리오:

• 지식 집약형 Agent(연구 도우미, 지식 기반 Q&A 등)
• 멀티홉 추론이 필요한 시나리오
• 관계 네트워크가 필요한 시나리오

한계:

• 구축 비용이 높으며 특히 LLM으로 엔터티를 추출하면 비용이 큼
• 그래프 데이터베이스 인프라가 필요함
• 단순한 시나리오에는 과도한 설계일 수 있음

선택 의사 결정 매트릭스

지금까지의 내용을 바탕으로 어떤 프레임워크를 선택해야 할까요? 다음과 같이 의사 결정 매트릭스를 정리할 수 있습니다.

시나리오	추천 프레임워크	이유
빠른 프로토타입 / MVP	Mem0	가장 빠르게 시작할 수 있고 인프라가 필요 없음
음성 Agent	Mem0	지연 시간이 짧고 호스팅 서비스가 안정적임
장기 동반형 Agent	Letta	OS 방식 관리와 완전한 추론 기억
기업 고객 지원	Zep	대화 메모리에 특화되고 사실 추출이 자동화됨
지식 집약형 Agent	Cognee	강력한 그래프 및 관계 추론 기능
자체 인프라 구축	Letta + 직접 선택한 벡터 DB	가장 유연하고 비용을 통제할 수 있음

일반적인 권장 순서는 다음과 같습니다.

• 먼저 Mem0로 프로토타입을 완성합니다
• 장기 기억이 필요해지면 Letta로 이전합니다
• 복잡한 관계 추론이 필요하면 Cognee 또는 Neo4j를 추가합니다

실전 사례와 모범 사례

음성 Agent 메모리 방식

음성 Agent는 지연 시간에 매우 민감합니다. 사용자가 말을 마친 뒤 200ms 안에 반응하지 않으면 버벅인다고 느낍니다.

따라서 메모리 검색은 100ms 이내에 끝나야 합니다. 나머지 100ms는 음성 합성과 전송에 사용해야 합니다.

Mem0 방식은 다음과 같습니다.

1. Core Memory 사전 로드: 사용자 선호와 자주 쓰는 설정을 세션 시작 시 메모리에 한 번에 로드합니다
2. Recall Memory 수동 검색: 명확히 필요할 때만 효율적인 벡터 인덱스로 조회합니다
3. 비동기 갱신: 대화가 끝난 뒤 비동기로 메모리를 갱신해 응답을 막지 않습니다

ElevenLabs가 음성 Agent에 Mem0를 통합해 측정한 결과, 엔드투엔드 지연 시간을 300ms 이내로 제어해 사용자 경험이 양호했습니다.

기업 고객 지원 Agent

기업 고객 지원의 핵심 요구 사항은 사용자를 장기간 기억하고 의사 결정 과정을 설명할 수 있어야 한다는 것입니다.

대표적인 아키텍처는 다음과 같습니다.

사용자 메시지
    ↓
의도 인식
    ↓
┌─────────────────┬─────────────────┐
│  Core Memory     │  Recall Memory  │
│  (사용자 프로필)    │  (과거 대화)      │
└─────────────────┴─────────────────┘
    ↓
지식 베이스 검색(RAG)
    ↓
답변 생성
    ↓
추론 기억 기록(왜 이렇게 답했는가)

Zep은 이 시나리오에서 좋은 성능을 보입니다. 자동 사실 추출로 사용자의 기본 정보를 기억하고, 점진적 요약으로 긴 대화를 처리할 수 있습니다.

개인 비서: 세션을 넘나드는 학습

개인 비서의 핵심 능력은 사용자 선호를 학습하고 세션이 바뀌어도 연속성을 유지하는 것입니다.

핵심 설계는 다음과 같습니다.

1. 사용자 프로필 기억: 장기 저장하며 사용자의 선호, 습관, 자주 쓰는 도구를 기록합니다
2. 프로젝트 컨텍스트 기억: 프로젝트별로 격리하며 프로젝트를 전환할 때 해당 컨텍스트를 로드합니다
3. 추론 기억: 특정 방안을 추천한 이유와 다른 선택지를 포기한 이유를 기록합니다

Letta의 설계는 이 시나리오에 잘 맞습니다. Core Memory에는 사용자 프로필을, Recall Memory에는 프로젝트 기록을, Archival Memory에는 보관된 프로젝트를 저장합니다.

문제를 피하기 위한 가이드

실제 경험에서 자주 만난 문제를 공유하겠습니다.

문제 1: 모든 기억을 벡터 데이터베이스에 넣기

문제점: 벡터 데이터베이스는 의미 검색에만 강하며 정확한 조회와 관계 추론에는 약합니다.

해결 방법: 혼합 스토리지를 사용합니다. 사용자 ID와 프로젝트 상태 같은 구조화 데이터는 관계형 데이터베이스에, 의미 기억은 벡터 데이터베이스에, 관계 기억은 그래프에 저장합니다.

문제 2: TTL 전략이 없음

문제점: 기억이 계속 늘고 검색은 느려지며 오래된 정보가 대량으로 회상됩니다.

해결 방법: 기억 유형별로 TTL을 설정합니다. 이벤트 기억은 몇 시간 뒤 만료하고, 작업 기억은 작업이 끝나면 정리하며, 사용자 프로필은 장기 보관합니다.

문제 3: 추론 기억을 무시함

문제점: Agent가 결정을 내리지만 그 이유를 설명할 수 없습니다. 디버깅이 어렵고 사용자가 의문을 제기하게 됩니다.

해결 방법: 의사 결정 과정을 명시적으로 기록합니다. 중요한 결정마다 무엇을 선택했는지, 왜 선택했는지, 포기한 선택지는 무엇인지 기록합니다.

문제 4: 메모리 관리를 LLM에 지나치게 의존함

문제점: 소형 모델이 무엇을 기억하고 무엇을 지울지 스스로 결정하게 하면 결과가 좋지 않습니다.

해결 방법: 소형 모델에는 규칙을 보조 수단으로 사용합니다. 명확한 엔터티 추출 규칙, 고정된 메모리 템플릿, 사전 설정된 중요도 가중치 등을 적용합니다.

결론

핵심은 다음과 같습니다.

첫째, 메모리는 Agent의 “두 번째 두뇌”이며 선택 기능이 아니라 핵심 아키텍처입니다. 메모리가 없는 Agent는 하드 디스크가 없는 컴퓨터와 같습니다. 전원이 꺼지면 기억을 잃고 매번 처음부터 시작합니다. Agent를 “도구”에서 “파트너”로 발전시키려면 메모리 시스템을 피할 수 없습니다.

둘째, 세 가지 기억 유형이 모두 필요합니다. 단기 기억은 컨텍스트를, 장기 기억은 영속성을, 추론 기억은 설명 가능성을 담당합니다. 대부분의 프레임워크는 앞의 두 가지만 구현하며 추론 기억은 심각하게 저평가되어 있습니다.

셋째, 프레임워크는 시나리오에 맞춰 선택해야 하며 만능 해법은 없습니다. 음성 Agent에는 Mem0(짧은 지연 시간), 장기 작업에는 Letta(OS 방식 관리), 지식 집약형 작업에는 Cognee(강력한 그래프), 고객 지원에는 Zep(대화 특화)이 적합합니다.

넷째, 벡터 데이터베이스는 만능이 아닙니다. 의미 검색은 “비슷한” 것을, 지식 그래프는 “관계”를, 구조화 스토리지는 “정확한 값”을 찾습니다. 세 가지를 결합해야 합니다.

다섯째, 기억은 저장만 하면 끝나는 것이 아니라 거버넌스가 필요합니다. TTL 전략, 감쇠 메커니즘, 정기 정리가 모두 필요합니다. 그렇지 않으면 메모리 저장소가 쓰레기장처럼 팽창합니다.

바로 실행할 수 있는 제안:

1. LOCOMO 벤치마크 데이터부터 살펴보며 메모리 시스템의 성능 지표를 이해합니다
2. Mem0 또는 neo4j-agent-memory로 프로토타입을 빠르게 만들고 먼저 실행해 봅니다
3. Reasoning Memory에 주목합니다. 이는 다음 단계 Agent 역량 경쟁의 핵심 차별점입니다

Agent의 미래는 단순히 “더 똑똑한 모델”에만 있지 않고 “더 오래 지속되는 기억”에도 있습니다. Agent가 한 달 전에 한 말을 기억하고, 사용자가 왜 그런 결정을 내렸는지 이해하며, 다음 대화에서도 컨텍스트를 이어 갈 수 있을 때 비로소 진정한 “지능”에 가까워집니다.

---

관련 글

• AI Agent 아키텍처 설계 실전
• LangGraph 상태 관리 실전: Checkpoint와 실패 복구
• RAG 벡터 데이터베이스 선택 가이드

참고 자료

• State of AI Agent Memory 2026 - Mem0 공식 블로그, LOCOMO 벤치마크 데이터 출처
• Agent Memory: How to Build Agents that Learn and Remember - Letta 공식 블로그, OS 방식 메모리 관리
• Meet Lenny’s Memory: Building Context Graphs for AI Agents - Neo4j 공식 블로그, 지식 그래프 메모리 구현
• The 6 Best AI Agent Memory Frameworks - 프레임워크 비교
• AI Agent 도입이 실패하는 이유? 장기 기억의 세 가지 유형과 3단계 파이프라인이 핵심 - 중국어 심층 분석