Skip to content
←

필사 모드: AI 에이전트의 메모리는 실제로 어떻게 만드는가 — 네 가지 설계와, 벤치마크가 실제로 증명한 것

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — "메모리"는 한 가지가 아니다

"AI 에이전트에 메모리를 붙였다"는 문장은 거의 아무 정보도 주지 않습니다. 그 말이 가리킬 수 있는 설계가 최소 네 가지이고, 서로 비용도 실패 방식도 다르기 때문입니다. 파일에 메모를 적어 두는 것, 대화가 길어지면 요약해서 앞부분을 버리는 것, 사실을 뽑아 임베딩해 두고 질문마다 꺼내 오는 것, 엔티티와 관계를 그래프로 쌓는 것 — 이 넷은 전부 "메모리"라고 불리지만 같은 물건이 아닙니다. 2026년 1월에 나온 서베이(arXiv:2602.06052)가 "메모리는 올해에만 수백 편의 논문이 나왔다"고 적을 만큼 이 말은 과적재돼 있습니다.

그래서 이 글이 먼저 답하는 질문은 이겁니다 — 각 설계가 실제로 무엇을 하고, 어느 쪽이 낫다는 근거가 실제로 측정된 적이 있는가. 결론부터 말하면 이렇습니다. 설계별로 무엇을 하는지는 제품 문서에 명확히 적혀 있습니다. 반면 "어느 쪽이 더 정확한가"에 대한 공개 근거는 생각보다 훨씬 약합니다. 가장 많이 인용되는 비교 논문의 표를 직접 읽어 보면, 정작 그 표에서 1등은 어떤 메모리 시스템도 아니라 "대화 전체를 그냥 프롬프트에 다 붙이기"였습니다. 그리고 그 벤치마크를 직접 열어 토큰을 세어 보면 왜 그런지도 설명이 됩니다. 이 글은 그 과정을 하나씩 확인합니다.

이 글은 컨텍스트 엔지니어링 편이 다룬 설계 패턴을 반복하지 않습니다. 여기서 하려는 건 근거 감사(audit)입니다 — 어떤 숫자가 누구에 의해, 어떤 조건에서, 무엇과 비교해 측정됐는가.

네 가지 설계는 각각 무엇을 하나

용어를 먼저 고정합시다. 아래 넷은 배타적이지 않고, 실제 제품은 보통 섞어 씁니다.

1. 스크래치패드 / 파일 메모리. 에이전트가 파일에 메모를 쓰고 나중에 읽습니다. Anthropic의 memory tool이 정확히 이 모양입니다 — 공식 문서에 따르면 /memories 디렉터리 아래 파일을 만들고, 읽고, 고치고, 지웁니다. 중요한 건 이게 완전히 클라이언트 사이드라는 점입니다. 문서의 표현으로는 Claude는 파일 연산을 요청할 뿐이고, 실행은 여러분의 애플리케이션이 여러분의 저장소에 대고 합니다. 문서는 이 패턴을 just-in-time 컨텍스트 회수라고 부릅니다 — 미리 다 싣지 않고, 배운 걸 적어 뒀다가 필요할 때 읽는다.

2. 요약 / 컴팩션. 대화가 길어지면 앞부분을 요약으로 갈아 끼웁니다. Anthropic의 서버 사이드 compaction이 이겁니다. 문서에 따르면 입력 토큰이 설정한 임계값에 닿으면 API가 대화를 요약해 compaction 블록을 만들고, 이후 요청에서 그 블록 앞의 모든 컨텐츠 블록을 자동으로 버립니다. 베타 헤더는 compact-2026-01-12, 전략 이름은 compact_20260112입니다. 문서가 밝히는 이유가 흥미롭습니다 — 단순히 한도를 넘지 않기 위해서가 아니라, "대화가 길어지면 응답 품질이 떨어지기 때문에" 활성 컨텍스트를 작게 유지한다는 것입니다.

3. 벡터 회수. 대화에서 사실을 뽑아 임베딩해 두고, 질문마다 유사한 것을 꺼내 옵니다. Mem0의 기본 구성이 이 계열입니다. 프로덕션 RAG 패턴의 검색 파이프라인과 기술적으로 같은 물건이고, 다른 건 대상이 문서가 아니라 대화라는 점입니다.

4. 지식 그래프. 엔티티와 관계를 그래프로 쌓습니다. Zep의 Graphiti가 대표적이고, 시간 정보를 엣지에 붙여 "언제부터 언제까지 참이었나"를 다룹니다. 그래프를 어떻게 뽑고 무엇을 엔티티로 볼지는 그 자체로 큰 주제이고, 지식 그래프를 실제로 구축하기와 도메인 지식을 온톨로지로 모델링하기 편에서 따로 다뤘습니다. 코퍼스 질의 쪽 이야기는 Graph RAG 편에 있습니다.

연구 쪽 계보를 하나 짚자면, 이 분야의 출발점으로 자주 인용되는 MemGPT(arXiv:2310.08560, 2023년 10월)는 운영체제의 계층 메모리에서 아이디어를 빌려 "가상 컨텍스트 관리"를 제안했습니다. 빠른 메모리와 느린 메모리 사이에 데이터를 옮겨 큰 메모리가 있는 것처럼 보이게 한다는 발상입니다. 지금 제품들의 파일 메모리와 컴팩션은 이 계보 위에 있습니다.

출시된 제품과 연구 논문은 어디서 갈리나

여기서 첫 번째 중요한 구분이 나옵니다.

출시된 제품이 실제로 미는 건 1번과 2번입니다. 이게 의외일 수 있습니다. Anthropic 문서를 보면 context editing 페이지가 이렇게 안내합니다 — 대부분의 용례에서는 서버 사이드 compaction이 긴 대화의 주된 전략이고, context editing의 세부 전략들은 무엇을 지울지 더 세밀하게 통제해야 하는 특정 상황용이라는 것입니다. compaction 문서도 같은 말을 합니다: 장기 실행 대화와 에이전트 워크플로에서 권장되는 전략이라고요.

즉 상용 플랫폼이 기본값으로 권하는 "메모리"는 벡터도 그래프도 아니고, 요약해서 버리기 + 파일에 적어 두기입니다. 가장 단순한 두 가지입니다.

연구와 스타트업이 겨루는 건 3번과 4번입니다. Mem0, Zep, LangMem, A-Mem 같은 시스템들이 여기 있고, 논쟁도 전부 여기서 벌어집니다. 그럼 이쪽이 더 낫다는 근거는 얼마나 단단할까요.

어느 설계가 더 정확한가 — 가장 많이 인용되는 표를 직접 읽기

이 질문에 대해 가장 널리 인용되는 근거는 Mem0 논문입니다(Chhikara 등, arXiv:2504.19413, 2025년 4월 28일 제출, ECAI 2025). 초록의 헤드라인은 이렇습니다 — LLM-as-a-Judge 지표에서 OpenAI 대비 26% 상대 개선, 그래프 메모리를 쓰면 기본 구성보다 약 2% 더 높은 점수, 그리고 풀컨텍스트 대비 91% 낮은 p95 지연과 90% 이상의 토큰 비용 절감.

그런데 논문 본문의 Table 2를 그대로 옮기면 이렇습니다. 모두 저자 자체 측정이고, LoCoMo 벤치마크 기준이며, J는 LLM-as-a-Judge 점수입니다.

방식메모리 토큰검색 p95총 p95J 점수
풀컨텍스트 (전체 대화를 그대로 투입)26,031—17.117s72.90% ± 0.19
Mem0 그래프—0.476s (p50)2.590s68.44%
Mem0 (기본)1,7640.200s1.440s66.88%
Zep3,9110.778s2.926s65.99% ± 0.16
LangMem12759.82s60.40s58.10% ± 0.21
OpenAI4,437—0.889s52.90% ± 0.14
A-Mem2,5201.485s4.374s48.38% ± 0.15

헤드라인 숫자들은 산술적으로 맞습니다. 직접 검산해 봤습니다 — 66.88 나누기 52.90은 1.264이니 OpenAI 대비 26% 상대 개선이 맞고, 1 빼기 (1.440 나누기 17.117)은 91.6%이니 풀컨텍스트 대비 91% 낮은 p95도 맞습니다. 68.44 빼기 66.88은 1.56%p이니 "약 2% 더 높다"도 맞습니다. 아무것도 조작되지 않았습니다.

문제는 같은 표의 맨 윗줄입니다. 풀컨텍스트가 72.90%로 1등입니다. 대화 전체를 그냥 프롬프트에 붙이는, 메모리 시스템이라고 부를 수도 없는 방식이 모든 메모리 시스템을 이겼습니다. 논문도 이걸 숨기지 않습니다 — 본문에 약 26,000 토큰을 통째로 넣는 풀컨텍스트가 여전히 가장 높은 J 점수(약 73%)를 낸다고 적혀 있고, Mem0 그래프가 "계산적으로 감당하기 어려운 풀컨텍스트에만 뒤진다"고 명시합니다.

그러니 정확히 말하면 이렇습니다. 26%라는 헤드라인은 OpenAI의 52.90%를 기준으로 잰 것입니다. 표에서 가장 약한 비교 대상입니다. 표에서 가장 강한 기준선은 아무 메모리 시스템도 이기지 못했고, 초록은 그 사실을 언급하지 않습니다. 거짓은 없지만, 프레이밍이 고릅니다. 논문이 파는 진짜 가치는 정확도가 아니라 비용입니다 — 1,764 토큰으로 26,031 토큰짜리 방식의 92% 수준 정확도를 낸다는 것. 그건 실제로 유용한 결과이고, 정직하게 말하면 그게 결론이어야 합니다.

표를 조금 더 보면 다른 것도 눈에 띕니다. LangMem의 메모리가 127 토큰이고 검색 p95가 59.82초입니다. 60초짜리 검색은 어떤 프로덕션에서도 정상 설정이 아닙니다. 남의 시스템을 최적 설정으로 돌리는 게 얼마나 어려운지 보여주는 신호이고, 이 신호가 바로 다음 이야기로 이어집니다.

왜 풀컨텍스트가 이겼나 — 벤치마크를 직접 열어봤다

풀컨텍스트가 이긴 이유를 알려면 LoCoMo가 뭔지 봐야 합니다.

LoCoMo는 원래 대화 메모리 벤치마크입니다(Maharana 등, arXiv:2402.17753, 2024년 2월 27일). 논문 Table 1이 기술하는 데이터셋은 이렇습니다 — 50개 대화, 대화당 평균 304.9턴, 평균 19.3세션, 평균 9,209.2 토큰. 질문은 다섯 범주로 나뉩니다: single-hop, multi-hop, temporal, commonsense/world knowledge, 그리고 adversarial.

그런데 Mem0 논문은 풀컨텍스트에 26,031 토큰을 넣었다고 적습니다. 9,209와 26,031은 세 배 가까이 차이가 납니다. 어느 쪽이 맞는지 확인하려고 공개 데이터셋을 직접 내려받아 세어 봤습니다.

공개 저장소(snap-research/locomo)에 실제로 들어 있는 파일은 locomo10.json입니다. 이름 그대로 10개 대화입니다 — 논문이 기술한 50개가 아닙니다. tiktoken의 cl100k_base로 대화 본문(발화 텍스트와 이미지 캡션)만 세어 본 결과는 이렇습니다.

locomo10.json  (직접 측정, tiktoken cl100k_base, 발화 텍스트 + BLIP 캡션)
  대화 수:        10           (논문 Table 1은 50개를 기술)
  대화당 토큰:    최소 12,218 / 최대 23,406 / 평균 20,034 / 중앙값 21,387
                               (논문 Table 1은 평균 9,209.2)
  대화당 세션:    평균 27.2 (최소 19, 최대 32)   (논문은 평균 19.3)
  대화당 턴:      평균 588.2                     (논문은 평균 304.9)

  질문 총계:      1,986
    범주1 single-hop      282
    범주2 multi-hop       321
    범주3 temporal         96
    범주4 open-domain     841
    범주5 adversarial     446   <- 446개 중 444개에 `answer` 필드가 없음
                                   (`adversarial_answer` 필드만 있음)

즉 모두가 벤치마킹하는 공개 파일은 논문이 기술한 데이터셋의 대략 두 배 길이입니다. 제 측정치 20,034 토큰은 Zep이 주장한 "16,000~26,000 토큰" 범위와 일치하고, Mem0의 26,031 토큰과도 방향이 맞습니다(Mem0 쪽은 타임스탬프나 관찰 필드 등 스캐폴딩을 더 포함했을 가능성이 큽니다). 논문 초록의 "평균 9K 토큰"과는 맞지 않습니다.

이게 풀컨텍스트가 이긴 이유입니다. 대화 하나가 2만 토큰이면 요즘 모델의 컨텍스트 윈도우에 아무 부담 없이 들어갑니다. 장기 메모리를 압박하는 시험이 아니라, 그냥 다 넣으면 되는 시험입니다. Zep이 자기 블로그에서 지적한 문장이 정확합니다 — 전부 넣는 게 전문 메모리 시스템보다 나은 결과를 낸다면, 그 벤치마크는 실제 에이전트가 겪는 메모리 압박을 재고 있지 않다는 뜻입니다.

범주 5도 눈여겨볼 만합니다. 446개 중 444개에 answer 필드가 아예 없습니다(대신 adversarial_answer가 들어 있습니다). 그래서 Mem0와 Zep 둘 다 이 범주를 평가에서 제외했습니다. 전체 질문의 22.5%가 사실상 쓸 수 없는 상태라는 뜻이고, 이 제외가 다음 장에서 벌어지는 사고의 원인이 됩니다.

벤더끼리 숫자가 안 맞으면 어떻게 되나 — Mem0 대 Zep의 기록

이 분야에서 "측정된 것"과 "주장된 것"의 간극을 가장 잘 보여주는 사건이 2025년 5월에 공개적으로 남아 있습니다. 시간 순으로 정리하면 이렇습니다.

2025년 4월 28일. Mem0 논문이 올라옵니다. Zep을 65.99%로 보고하고 SOTA를 주장합니다.

2025년 5월 6일. Zep이 블로그로 반박합니다(Daniel Chalef, Preston Rasmussen). 요지는 Mem0가 Zep을 잘못 구현해 놓고 측정했다는 것입니다. 구체적으로 세 가지를 듭니다 — 대화 참가자 양쪽 모두에게 user 역할을 부여해 단일 사용자의 정체성이 매 메시지마다 바뀌는 것처럼 만들었고, 타임스탬프를 Zep의 created_at 필드 대신 메시지 본문에 덧붙였으며, 검색을 병렬이 아니라 순차로 돌려 지연을 부풀렸다는 것입니다. 그러면서 올바르게 구현하면 Zep이 84%라고 주장합니다.

2025년 5월 9일. Mem0의 CTO Deshraj가 Zep 저장소에 이슈를 엽니다(getzep/zep-papers 이슈 5번). 반박의 핵심은 산술입니다 — Zep의 84%는 모두가 제외하기로 한 범주 5의 정답을 분자에는 넣고 분모에서는 뺀 계산이라는 것입니다. 이걸 바로잡으면 84%가 아니라 58.44%라는 것입니다. 약 25.56%p가 부풀려졌다는 주장입니다.

2025년 5월 12일. Zep의 Chalef가 계산 오류를 인정합니다. 그런데 정정된 값은 58.44%가 아니라 75.14% ± 0.17(10회 실행 평균)이었습니다. 그리고 나머지 비판 — Mem0의 실험 설정과 LoCoMo 선택 자체가 잘못됐다는 주장 — 은 철회하지 않았습니다. Zep은 블로그에도 정정 공지를 붙였고, 지금도 그 문구가 남아 있습니다.

2025년 5월 19일. 이슈가 "비활성으로 인해" 닫힙니다.

여기서 중요한 건 두 진영의 숫자가 끝내 일치한 적이 없다는 사실입니다. Mem0는 Zep이 58.44%라 하고, Zep은 정정 후에도 75.14%라 합니다. 같은 벤치마크, 같은 시스템, 17%p 차이. 어느 쪽이 맞는지 이 글은 판정하지 않습니다 — 판정할 근거가 공개돼 있지 않기 때문입니다.

산술이 말이 되는지는 확인해 볼 수 있습니다. 제가 센 대로 범주 1~4가 1,540문항, 범주 5가 446문항입니다. 범주 5의 정답을 분자에 넣고 분모는 1,540으로 두면, 25.56%p를 부풀리는 데는 범주 5에서 약 394문항(446개의 88%)이 정답 처리돼야 합니다. Mem0가 주장한 메커니즘과 규모가 서로 모순되지는 않습니다. 다만 이건 주장의 내적 정합성 확인이지, 어느 쪽 점수가 옳다는 증명이 아닙니다.

이 사건에서 실무자가 가져갈 교훈은 "누가 나쁜 놈인가"가 아닙니다. 경쟁 제품을 최적 설정으로 돌려서 측정하는 일은 선의로도 대단히 어렵고, 그래서 벤더가 남의 제품에 대해 보고한 숫자는 기본적으로 약한 증거라는 것입니다. 앞서 본 LangMem의 60초 검색도 같은 범주의 신호입니다. Zep의 65.99%도, Zep이 자기 손으로 잰 75.14%도 각자 자기 이해관계가 붙어 있습니다.

더 어려운 벤치마크에서는 어떤가 — LongMemEval

LoCoMo가 너무 쉽다면 더 어려운 게 있습니다. LongMemEval(Wu 등, arXiv:2410.10813, 2024년 10월 v1, 2025년 3월 v2, ICLR 2025)입니다.

설계가 확실히 더 공격적입니다. 500개 질문이고, 표준 설정이 둘입니다 — LongMemEval_S는 문제당 약 115k 토큰, LongMemEval_M은 500세션에 약 150만 토큰. LoCoMo의 2만 토큰과는 자릿수가 다릅니다. 그리고 LoCoMo에 없던 능력을 명시적으로 시험합니다: 정보 추출, 멀티세션 추론, 시간 추론, 지식 갱신(사실이 바뀌는 상황), 그리고 기권(모르면 모른다고 하기).

논문이 보고하는 결과는 이렇습니다. 초록은 "상용 챗 어시스턴트와 롱컨텍스트 LLM이 30% 정확도 하락을 보인다"고 적지만, 본문은 더 정확하게 30%~60% 성능 하락이라고 씁니다. 그리고 상용 시스템에 대한 문장에는 반드시 보존해야 할 단서가 붙어 있습니다 — 수작업 평가에서 최신 상용 시스템들이 30%~70% 정확도에 그쳤는데, 그건 LongMemEval_S보다 훨씬 단순한 설정에서였다는 것입니다. 즉 실제 난이도에서의 상용 시스템 점수가 아닙니다.

Zep은 자기 논문(arXiv:2501.13956, 2025년 1월)에서 LongMemEval을 선호한다고 밝히고, 최대 18.5%의 정확도 개선과 90%의 지연 감소를 보고합니다. "최대(up to)"라는 한정어가 붙어 있고, 저자 자체 측정입니다. 같은 논문은 DMR 벤치마크에서 MemGPT 대비 94.8% 대 93.4%를 보고하는데, 1.4%p 차이를 근거로 SOTA를 말하는 건 그 자체로 얇습니다.

여기서 정직하게 말해야 할 것이 있습니다. LongMemEval 위에서 Mem0, Zep, 파일 메모리, 컴팩션을 동일 조건으로 나란히 돌린 독립적인 제3자 비교는, 제가 확인한 범위에서 공개돼 있지 않습니다. 각 벤더가 자기 파이프라인에서 자기 프롬프트로 잰 숫자들이 있을 뿐입니다. 공통 벤치마크가 없으면 벤더 A의 자체 측정과 벤더 B의 자체 측정을 나란히 놓고 비교할 수 없습니다 — 이 글이 그런 표를 만들지 않는 이유입니다.

Anthropic의 39%는 무엇을 잰 숫자인가

상용 쪽 숫자도 같은 잣대로 봐야 공평합니다.

Anthropic이 2025년 9월 29일 context editing과 memory tool을 발표하면서 공개한 수치는 이렇습니다 — memory tool과 context editing을 함께 쓰면 기준선 대비 39% 성능 향상, context editing 단독으로는 29% 향상. 그리고 100턴 웹 검색 평가에서 context editing이 없었으면 컨텍스트 고갈로 실패했을 워크플로를 완주시키면서 토큰 소비를 84% 줄였다고 합니다.

이 숫자들에 붙어 있는 조건을 그대로 옮기면 이렇습니다. 첫째, 에이전틱 검색에 대한 내부 평가 세트(internal evaluation set) 기준입니다. 벤더 자체 측정이고, 외부에서 재현할 수 없습니다. 둘째, 기준선의 절대 점수가 공개되지 않았습니다. 39% 향상이 40점에서 55.6점인지 70점에서 97점인지 알 수 없습니다. 셋째, 세 숫자가 각각 다른 것을 잽니다 — 39%와 29%는 정확도 계열, 84%는 토큰 소비입니다.

그리고 하나 더, 시간이 지나면서 생긴 어긋남이 있습니다. 저 39%는 2025년 9월에 context editing + memory tool 조합을 잰 숫자입니다. 그런데 지금 Anthropic 문서가 장기 실행 대화의 주된 전략으로 권하는 건 서버 사이드 compaction이고, 그건 베타 헤더가 compact-2026-01-12인 이후 기능입니다. 즉 널리 인용되는 39%는 현재 권장 기본값을 측정한 숫자가 아닙니다. 이건 Anthropic이 뭘 잘못했다는 뜻이 아니라, 제품이 움직이는 속도보다 숫자가 느리게 늙는다는 뜻입니다. 벤더 수치를 인용할 때는 그 수치가 어느 시점의 어느 구성을 잰 것인지 함께 적어야 합니다.

측정되지 않은 것 — 실패 방식

정확도 표에 나오지 않는 실패들이 있습니다. 이쪽은 대체로 벤치마크가 아니라 문서의 경고문 형태로만 존재합니다.

메모리 오염과 프롬프트 인젝션. 에이전트가 읽은 내용을 메모리에 적고, 그 메모리를 나중에 신뢰해서 읽는다면, 오염된 입력 하나가 세션을 넘어 지속됩니다. Anthropic 문서는 memory tool에 대해 경로 탐색 공격을 명시적으로 경고합니다 — /memories/../../secrets.env 같은 경로가 메모리 디렉터리 밖 파일에 닿을 수 있으므로 모든 명령의 모든 경로를 검증해야 한다는 것입니다. 실행 주체가 여러분의 애플리케이션이므로 방어도 여러분 몫입니다.

민감정보 기록. 같은 문서의 표현을 그대로 옮기면, Claude는 민감정보를 메모리 파일에 쓰기를 대체로(usually) 거부합니다. 더 강한 보장을 원하면 핸들러가 파일을 쓰기 전에 민감 데이터를 걸러내는 검증을 직접 붙이라고 안내합니다. "대체로"라는 한정어를 "안 한다"로 올려 읽으면 안 됩니다.

지식 갱신. 사용자가 이직하면 예전 직장 정보는 틀린 게 됩니다. LoCoMo에는 이걸 시험하는 질문이 아예 없습니다(Zep의 지적이고, 제가 범주 분포를 확인한 것과 일치합니다). LongMemEval은 지식 갱신을 다섯 능력 중 하나로 명시하고 있습니다 — 그래서 더 나은 시험입니다.

무한 성장과 만료. Anthropic 문서는 파일 크기 상한을 두고, 오래 접근되지 않은 메모리 파일을 주기적으로 지우라고 권합니다. 즉 "무엇을 잊을 것인가"에 대한 정책이 필요하다는 뜻인데, 이 부분을 자동으로 잘 푸는 공개 근거는 없습니다.

이 실패들에 대해 공개된 정량 비교는 사실상 없습니다. 그러니 메모리 시스템을 고를 때 정확도 표만 보는 건 잘못된 축을 보는 것일 수 있습니다.

그래서 무엇을 써야 하나 — 결정 규칙

근거의 상태를 감안한 결정 규칙은 이렇습니다. "상황에 따라 다르다"로 끝내지 않겠습니다.

1. 대화나 작업이 컨텍스트 윈도우에 들어가면, 메모리 시스템을 붙이지 마십시오. 그냥 다 넣으십시오. Mem0 논문 자신의 표가 이 결론을 지지합니다 — 2만 토큰짜리 LoCoMo에서 풀컨텍스트가 72.90%로 모든 메모리 시스템을 이겼습니다. 이건 벤치마크의 약점이지만, 동시에 여러분의 상황이 그 벤치마크와 닮았다면 그대로 적용되는 결론입니다.

2. 안 들어가면, 먼저 컴팩션과 파일부터. 상용 플랫폼이 기본으로 권하는 게 이 둘이라는 사실 자체가 신호입니다. 서버 사이드 compaction은 클라이언트 요약 코드 없이 동작하고, 파일 메모리는 여러분이 저장소를 통제합니다. 둘 다 구현 표면이 작고, 실패했을 때 디버깅할 수 있습니다(파일은 열어 보면 됩니다). 벡터나 그래프는 여기서 실패를 확인한 다음에 꺼낼 도구입니다.

3. 세션을 가로지르는 사실 회수가 실제 실패 지점으로 확인되면, 벡터. 여기서 파는 건 정확도가 아니라 비용입니다. Mem0의 표를 정직하게 읽으면 그 시스템의 가치는 1,764 토큰으로 26,031 토큰 방식의 약 92% 정확도를 낸다는 데 있습니다. 그게 필요한 트레이드오프면 좋은 선택이고, 아니면 아닙니다.

4. 시간에 따라 바뀌는 관계를 다뤄야 하면, 그래프. "언제부터 언제까지 참이었나", "이 사람이 지금 속한 팀은" 같은 질문입니다. 다만 Graph RAG 편에서 정리한 색인 비용과 갱신 부담이 그대로 따라옵니다.

5. 무엇을 고르든, 여러분의 질의로 평가하십시오. 이건 상투어가 아니라 이 글이 확인한 사실에서 직접 나오는 결론입니다. 공개 벤치마크 중 하나는 논문과 공개 파일의 통계가 어긋나 있고, 그 위에서 벤더끼리 17%p를 다투다 합의에 이르지 못했으며, 상용 수치는 재현 불가능한 내부 평가입니다. 이 상태에서 남의 순위표를 믿고 아키텍처를 고르는 건 근거 없는 선택입니다. 20~50문항짜리 자체 평가 셋이 이 글에 나온 모든 숫자보다 여러분에게 더 유용합니다.

언제 쓰지 말아야 하나

정직하게 적을 부분입니다.

  • 대화가 짧습니다. 대부분의 챗봇 세션은 몇 천 토큰입니다. 메모리 인프라를 붙일 이유가 없습니다.
  • 틀린 기억이 맞는 기억보다 비쌉니다. 의료·법률·금융처럼 잘못된 개인화가 손해를 내는 도메인에서는, 기억하지 않는 편이 안전합니다. 앞서 본 대로 오염과 갱신 실패에 대한 정량적 근거가 없습니다.
  • 규제 대상 데이터를 다룹니다. 메모리는 정의상 개인 데이터를 지속시킵니다. 삭제 요구권과 보존 정책을 설계하지 않았다면 붙이지 마십시오.
  • 아직 실패를 확인하지 않았습니다. "나중에 필요할 것 같아서" 메모리를 붙이는 건 이 글이 본 근거가 지지하지 않는 선택입니다.

마치며

정리하면 이렇습니다. "에이전트 메모리"는 최소 네 가지 설계를 뭉뚱그린 말이고, 각각이 무엇을 하는지는 제품 문서에 분명히 적혀 있습니다 — 파일 스크래치패드, 컴팩션, 벡터 회수, 지식 그래프. 상용 플랫폼이 기본으로 권하는 건 앞의 둘, 가장 단순한 둘입니다.

반면 "어느 쪽이 더 정확한가"의 공개 근거는 약합니다. 가장 많이 인용되는 비교의 표에서 1등은 메모리 시스템이 아니라 풀컨텍스트였고(72.90% 대 68.44%), 그 벤치마크를 직접 열어 보니 대화 하나가 평균 2만 토큰이라 애초에 장기 메모리를 압박하지 못하는 시험이었습니다. 그 위에서 벤더 둘이 서로의 측정을 반박했고, 한쪽이 계산 오류를 인정하고도 두 숫자는 끝내 만나지 않았습니다. 더 어려운 벤치마크는 존재하지만, 그 위의 독립적인 제3자 비교는 공개돼 있지 않습니다.

이건 이 분야가 가짜라는 뜻이 아닙니다. 컨텍스트를 관리하는 문제는 실재하고, 컴팩션과 파일 메모리는 실제로 출시돼 돌아가고 있습니다. 다만 "메모리를 붙이면 좋아진다"는 문장에는 아직 그 문장을 지지하는 공개된 측정이 붙어 있지 않습니다. 그러니 순위표가 아니라 여러분의 실패에서 출발하십시오. 무엇이 안 되는지 먼저 확인하고, 가장 단순한 것부터 붙이고, 여러분의 질의로 재십시오. 도구가 아니라 실패가 먼저입니다.

참고 자료

현재 단락 (1/101)

"AI 에이전트에 메모리를 붙였다"는 문장은 거의 아무 정보도 주지 않습니다. 그 말이 가리킬 수 있는 설계가 최소 네 가지이고, 서로 비용도 실패 방식도 다르기 때문입니다. 파일...

작성 글자: 0자원문 글자: 11,818자작성 단락: 0/101