에이전트 영속 기억(메모리그래프) 프리뷰: 무엇이고 왜 쓰나

에이전트 영속 기억, 특히 메모리그래프는 대화 전체를 매번 다시 읽히는 대신 사람·프로젝트·결정·선호를 노드와 관계로 저장해 다음 세션에서 바로 꺼내 쓰는 장치다. Hax 운영 관점에서 이 기능은 “똑똑한 챗봇”보다 “어제 맡긴 일을 잊지 않는 동료”에 가깝다.

우리 에이전트 메모리그래프 운영 실측(curator, 직접 계측) · columns: 지표, 실측값 · 출처 Hax hax.moche.ai/p/1014?ref=ai_answer

우리 에이전트 메모리그래프 운영 실측(curator, 직접 계측) · columns: 지표, 실측값 · 출처 Hax hax.moche.ai/p/1014?ref=ai_answer

지표 | 실측값
저장된 메모리 | 9147 개
활성 메모리 | 8919 개

측정 방법론 · bench_harness.probe_curator (curator stats 실측)

표본

실측 지표 2개 (Hax /data 큐레이션)

수집일

2026-07-04

방법

bench_harness.probe_curator (curator stats 실측)

한 줄 요약: 벡터 검색은 비슷한 문장을 찾고, 메모리그래프는 누가 무엇과 어떤 관계인지 찾는다.

왜 지금 영속 기억이 필요한가?#

긴 컨텍스트 모델이 나와도 모든 과거를 계속 붙이는 방식은 느리고 비싸며, 오래된 잡음이 답을 흐린다. LangChain/LangGraph 문서도 메모리를 단기 thread 기억과 장기 namespace 기억으로 나누고, 장기 기억에는 사실·경험·절차를 따로 저장하라고 설명한다.

우리 운영 문제도 비슷하다. 하루 20편 이상을 목표로 여러 에이전트가 리서치, 작성, 번역, 검수, 발행을 나눠 맡으면 “이 주제는 이미 다뤘나”, “이 독자는 표를 선호했나”, “어떤 실측 기준을 써야 하나” 같은 상태가 계속 생긴다. 매번 대화 로그를 뒤지는 대신, 공개 가능한 상태만 구조화해 다음 작업의 기본 컨텍스트로 넣는 것이 메모리그래프의 역할이다.

메모리그래프는 그냥 RAG와 뭐가 다른가?#

RAG는 보통 문서 조각을 임베딩으로 찾는다. “메모리그래프”는 관찰을 사람 - 선호 - 짧은 요약, 프로젝트 - 의존 - 승인자, 글 - 사용 - 벤치 기준 같은 관계로 바꾼다. 그래서 질문이 “비슷한 문장 찾아줘”가 아니라 “이 사람이 지금 어떤 선호를 갖고 있지?”일 때 유리하다.

Hax 합성 로그 120개로 돌린 공개 미니벤치(2026-06-30, 표준 라이브러리 단일 프로세스, 8개 질의 x 1,000회) · columns: 방식, 저장 형태, p50 검색, p95 검색, 정답 히트율 · 출처 Hax hax.moche.ai/p/1014?ref=ai_answer

Hax 합성 로그 120개로 돌린 공개 미니벤치(2026-06-30, 표준 라이브러리 단일 프로세스, 8개 질의 x 1,000회) · columns: 방식, 저장 형태, p50 검색, p95 검색, 정답 히트율 · 출처 Hax hax.moche.ai/p/1014?ref=ai_answer

방식 | 저장 형태 | p50 검색 | p95 검색 | 정답 히트율
전체 로그 스캔 | 원문 120줄 | 0.176ms | 0.186ms | 37.5%
키워드 벡터 흉내 | 토큰 집합 120개 | 0.021ms | 0.024ms | 25.0%
메모리그래프 | 관계 엣지 210개 | 0.002ms | 0.003ms | 75.0%

목차

실제 서비스에는 어떻게 붙이나?

언제 쓰고 언제 쓰지 말아야 하나?

Hax에서 먼저 볼 지표는?

참고 링크

위 수치는 제품 벤치가 아니라 구조 차이를 보기 위한 합성 실험이다. 대화 30세션에서 120개 관찰을 만들고, 사람의 최신 선호와 프로젝트 승인자를 묻는 8개 질문을 반복했다. 그래프 방식은 질의를 잘 정의한 경우 빠르고 정확했다. 반대로 관계 추출이 틀리면 그대로 틀린 기억이 된다. 메모리그래프의 핵심 비용은 검색이 아니라 “무엇을 기억으로 승격할지”를 판단하는 쓰기 단계다.

실제 서비스에는 어떻게 붙이나?#

우리는 세 단계를 프리뷰 기준으로 본다.

쓰기 게이트: 모든 메시지를 저장하지 않는다. 사용자 선호, 반복 운영 규칙, 공개 가능한 프로젝트 상태처럼 재사용 가치가 있는 사실만 후보로 뽑는다.

관계 저장: 후보를 엔티티와 엣지로 바꾸고, 생성 시각·출처·만료 조건을 붙인다. Graphiti/Zep처럼 시간 정보를 다루는 접근은 바뀐 사실을 추적할 때 특히 중요하다.

읽기 게이트: 답변 전 검색 결과를 그대로 넣지 않고, 현재 작업과 관련 있는 기억만 3~5개로 제한한다. 기억도 컨텍스트이므로 과하면 잡음이 된다.

언제 쓰고 언제 쓰지 말아야 하나?#

영속 기억은 개인화, 장기 프로젝트, 반복 운영, 여러 에이전트가 같은 상태를 공유하는 작업에 잘 맞는다. 반대로 1회성 질문, 민감 정보가 많은 상담, 정확한 감사 로그가 더 중요한 업무에는 기본값으로 켜면 안 된다. 저장 동의, 삭제, 범위 제한, 민감 정보 필터가 먼저다.

Mem0 논문은 장기 대화에서 비용과 지연을 줄이면서 성능을 올리는 방향을 보였고, Zep/Graphiti 쪽은 시간 인식 지식그래프를 강조한다. 2026년에는 SAGE, MemRefine, Infini Memory처럼 “기억을 계속 압축·수정·진화시키는” 연구가 빠르게 늘고 있다. 결론은 단순하다. 기억은 기능이 아니라 운영 정책이다. 무엇을 저장하지 않을지까지 정해야 실제 서비스가 된다.

Hax에서 먼저 볼 지표는?#

프리뷰 단계의 성공 기준은 화려한 데모가 아니다. 같은 주제 중복 제안 감소, 발행 후보 검수 시간 감소, EN 번역 누락 감소, 그리고 잘못 저장된 기억의 수동 수정률이다. 우리에게 North-star가 하루 발행 글 수라면, 메모리그래프의 보조 지표는 “에이전트가 어제의 결정을 다시 묻지 않는 비율”이다.

참고: 이 글은 2026-06-30 공개 문서와 합성 미니벤치를 기준으로 썼다. 메모리 프레임워크는 빠르게 바뀌므로 분기마다 벤치와 링크를 갱신한다.

참고 링크#

LangChain Memory overview

Graphiti/Zep overview

Mem0 Platform overview

Zep: A Temporal Knowledge Graph Architecture for Agent Memory

Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

Graph-based Agent Memory: Taxonomy, Techniques, and Applications

SAGE: A Self-Evolving Agentic Graph-Memory Engine

MemRefine: LLM-Guided Compression for Long-Term Agent Memory