AI agent memory eval은 에이전트가 기억을 많이 저장하는지 보는 일이 아닙니다.
중요한 질문은 따로 있습니다. 필요한 순간에 맞는 기억을 꺼냈는지, 틀린 기억을 과하게 믿지 않았는지, 기억 때문에 비용과 지연이 감당하기 어려워지지 않았는지를 봐야 합니다.
그래서 memory 기능을 붙였다면 “느낌상 더 똑똑해졌다”가 아니라, 작은 테스트셋과 회귀 기준으로 검증해야 합니다.
AI agent memory eval을 한 줄로 정리하기
OpenAI Evals는 LLM이나 LLM 기반 시스템을 평가하기 위한 프레임워크로, LangSmith 문서도 offline evaluation과 online evaluation을 분리해 설명합니다.
memory eval도 같은 원칙을 따릅니다. 기능을 붙인 뒤 좋은 예시 몇 개를 보는 것이 아니라, 반복 가능한 평가 세트를 만들고 버전별 결과를 비교해야 합니다.
memory와 RAG를 먼저 구분해야 한다
RAG는 보통 외부 문서에서 근거를 찾아 현재 질문에 넣는 구조입니다. memory는 사용자의 장기 선호, 이전 작업 맥락, 반복되는 제약 조건처럼 이후 대화에서도 다시 쓸 정보를 다룹니다.
둘은 함께 쓰일 수 있지만 평가 기준은 다릅니다. RAG는 문서 검색 정확도와 근거 충실성이 중요하고, memory는 저장할 것과 버릴 것의 판단, 오래된 기억의 갱신, 사용자별 맥락 분리가 더 중요합니다.
따라서 memory eval을 RAG 검색 점수로만 대체하면 안 됩니다. 기억을 정확히 꺼냈더라도 지금 질문에 쓰면 안 되는 상황이 있고, 반대로 검색 순위가 낮아도 사용자 선호를 반영해야 하는 경우가 있습니다.
테스트셋은 기억 종류별로 나눠야 한다
memory 테스트셋은 단순 질의응답 모음이면 부족합니다. 최소한 장기 선호, 프로젝트 사실, 금지 조건, 오래된 정보, 충돌하는 기억을 나눠야 합니다.
- 장기 선호: 사용자가 반복해서 요청한 문체, 출력 형식, 금지 표현을 지키는가
- 프로젝트 사실: 저장소 구조, 배포 절차, 도메인 용어를 다음 작업에서 정확히 재사용하는가
- 금지 조건: 예전에 허용됐더라도 지금은 쓰면 안 되는 정보나 행동을 피하는가
- 충돌 기억: 오래된 기억과 새 지시가 충돌할 때 최신 지시를 우선하는가
- 불확실한 기억: 확신하지 못하는 내용을 단정하지 않고 확인을 요청하는가
좋은 테스트셋은 성공 사례만 모으지 않습니다. 기억 기능이 실수하기 쉬운 반례를 포함해야 합니다. 특히 개인화 기능은 잘 맞을 때보다 틀렸을 때 피해가 커질 수 있습니다.
평가 지표는 recall 하나로 끝나지 않는다
기억을 잘 찾았는지 보려면 recall이 필요합니다. 하지만 recall이 높다고 좋은 memory system은 아닙니다. 너무 많은 기억을 꺼내면 답변이 산만해지고 비용도 늘어납니다.
그래서 최소한 네 가지 지표를 함께 봐야 합니다. 첫째, 필요한 기억을 찾는 recall. 둘째, 불필요한 기억을 끼워 넣지 않는 precision. 셋째, 실제 답변에서 그 기억을 올바르게 쓰는 grounded use. 넷째, 기억 때문에 생긴 latency와 token cost입니다.
memory eval의 핵심은 ‘찾았는가’가 아니라 ‘찾은 기억을 지금 답변에 써도 되는 방식으로 사용했는가’입니다.
회귀 테스트는 memory 기능에서 더 중요하다
memory 기능은 수정할 때마다 부작용이 생기기 쉽습니다. 저장 기준을 넓히면 recall은 좋아질 수 있지만, 민감한 정보나 일시적인 지시까지 장기 기억처럼 남을 수 있습니다.
반대로 저장 기준을 좁히면 비용과 노이즈는 줄지만, 사용자가 기대한 개인화가 사라질 수 있습니다. 그래서 memory 개선은 항상 이전 테스트셋을 다시 돌려야 합니다.
memory_eval_cases = [
{
"name": "사용자 문체 선호 재사용",
"history": ["앞으로 답변은 짧은 문단으로 써줘"],
"prompt": "이 에러 원인을 설명해줘",
"expected": ["짧은 문단", "단계적 설명"],
"forbidden": ["장황한 배경 설명"],
},
{
"name": "오래된 기억보다 최신 지시 우선",
"history": ["항상 Java 예시를 써줘", "이번 글은 Python 예시로 써줘"],
"prompt": "동시성 예시를 만들어줘",
"expected": ["Python 예시"],
"forbidden": ["Java 예시만 사용"],
},
]실제 운영에서는 위처럼 사람이 읽는 테스트 케이스에서 시작해도 됩니다. 중요한 것은 같은 케이스를 반복 실행해 변경 전후를 비교하는 것입니다.
online evaluation으로 운영 중 실패를 잡아야 한다
offline evaluation은 배포 전 품질을 확인하는 데 좋습니다. 하지만 memory 기능은 실제 사용자 상호작용에서만 드러나는 실패가 많습니다.
예를 들어 사용자가 임시로 말한 정보를 장기 기억처럼 저장하거나, 팀 A의 맥락을 팀 B 작업에 섞는 문제가 생길 수 있습니다. 이런 문제는 운영 trace를 샘플링하고, 실패 사례를 다시 offline dataset에 넣어야 줄어듭니다.
LangSmith 문서가 설명하는 online evaluation 흐름처럼, 실서비스에서는 안전성, 형식 준수, 품질 휴리스틱, 사용자 피드백을 모니터링하는 구조가 필요합니다.
실무 체크리스트
- 기억을 저장하는 기준과 삭제하는 기준이 문서화되어 있는가
- 장기 기억, 세션 기억, 검색 context가 분리되어 있는가
- 충돌하는 기억이 있을 때 최신 사용자 지시를 우선하는가
- 민감 정보가 장기 기억에 들어가지 않도록 필터링하는가
- memory 변경 후 기존 eval dataset을 다시 실행하는가
- 비용과 지연 시간이 기능 가치에 비해 과하지 않은가
정리
AI agent memory eval은 기억 기능을 켰는지 확인하는 절차가 아닙니다. 기억을 언제 저장하고, 언제 꺼내고, 언제 무시해야 하는지를 검증하는 작업입니다.
처음부터 거대한 벤치마크를 만들 필요는 없습니다. 중요한 사용자 시나리오 20개, 실패하면 안 되는 금지 사례 10개, 과거 장애 사례 몇 개만 있어도 memory 기능의 착시를 많이 줄일 수 있습니다.
관련해서는 AI eval은 왜 필요할까, LLM 회귀 테스트는 어떻게 해야 할까, RAG에서 context engineering이 중요한 이유도 함께 보면 좋습니다.
