기억은 설치가 아니라 상시 측정 대상입니다
Microsoft Research는 2026년 6월 29일 'Memora: A Harmonic Memory Representation'(ICML 2026)을 공개하고 코드를 github.com/microsoft/Memora에 올렸습니다. 긴 대화에서 전체 히스토리를 컨텍스트에 덤프하는 방식 대비 최대 98% 적은 토큰으로 LoCoMo LLM-judge 정확도 86.3%, LongMemEval 87.4%를 기록해 RAG·Mem0·Nemori·Zep·LangMem·풀컨텍스트 추론을 모두 앞섰습니다. 다만 이 글이 다루려는 것은 Memora 도입 절차가 아니라, 어떤 기억 계층을 얹든 그 성능을 무엇으로 어떻게 계속 잴 것인가라는 평가 각도입니다. 기억을 한 번 붙이고 끝내면 몇 달 뒤 회귀를 아무도 알아채지 못합니다.
검색이 맞아도 답이 맞는 건 아닙니다
Memora의 핵심 통찰은 '무엇을 저장하는가'와 '어떻게 검색하는가'를 분리하는 데 있습니다. 평가도 같은 두 축으로 갈라야 합니다. retrieval@k 같은 검색 지표는 근거 문장을 잘 찾아왔는지만 말해 줄 뿐, 그 근거로 만든 최종 답이 맞았는지는 LLM-judge로 따로 채점해야 합니다. 검색 재현율은 90%인데 답변 정답률은 70%대에 머무는 구간을 놓치면, 문제의 원인을 검색이 아닌 생성에서 찾아야 한다는 사실 자체를 모르게 됩니다.
공개 벤치마크만 믿으면 실사용과 벌어집니다
LoCoMo와 LongMemEval은 기억 성능을 남과 비교하는 좌표 역할을 하지만, 공개된 지 오래된 데이터셋은 학습 오염과 과적합 위험을 안고 있습니다. Memora가 이 두 벤치에서 86%대를 낸 것도 그 벤치 안에서의 순위일 뿐, 우리 서비스의 상담 로그나 장기 프로젝트 히스토리에서 같은 점수가 나온다는 보장은 없습니다. 그래서 공개 벤치는 계기판으로 두되, 실사용 판정의 기준선은 자체 도메인 골든셋에서 뽑아야 합니다.
기록부터 판정까지: 기억 평가 하네스 구축 로드맵
기획 단계에서는 목표 지표를 다섯 개로 못박습니다. 기억 정답률(LLM-judge) 85% 이상, 검색 근거 재현율 90% 이상, 답변당 컨텍스트 토큰을 풀히스토리 덤프 대비 90% 이상 절감, 오래된 사실을 잘못 끌어오는 stale recall 3% 이하, 판정자-인간 일치율 90% 이상이 출발선으로 적당합니다. 토큰 절감만 자랑하고 정밀도(specificity) 손실을 재지 않는 흔한 함정을 피하려면, 절감률과 정답률을 반드시 한 표에 나란히 붙여 둡니다.
골든셋은 자체 도메인 대화를 30~50세션 규모로 만들되, 각 질문에 정답 근거 발화와 기대 답변을 함께 라벨링합니다. 사실 갱신(예: 사용자가 이사한 뒤 이전 주소를 묻는 경우)과 시점 의존 질문을 일부러 섞어야 stale recall이 드러납니다. 공개 벤치는 주 1회, 골든셋은 커밋 단위 회귀로 병행 측정하면 오염된 순위와 실사용 성능의 괴리를 조기에 잡습니다.
실패 패턴은 네 갈래로 정리됩니다. 첫째, retrieval@k만 보고 LLM-judge 정답률을 안 봐서 '검색은 맞는데 답은 틀림'을 통째로 놓치는 경우. 둘째, LoCoMo·LongMemEval 점수에 과적합해 벤치는 87%인데 현장 상담 정답률은 60%대인 괴리. 셋째, 98% 토큰 절감 같은 수치만 홍보하고 세부 사실이 뭉개지는 specificity 손실을 측정하지 않는 경우. 넷째, LLM-judge 자체의 캘리브레이션을 검증하지 않아 채점기가 후하게 주는 점수를 실력으로 착각하는 경우입니다.
복구 분기는 지표별로 다르게 걸어 둡니다. 검색 재현율은 높은데 정답률이 낮으면 생성 프롬프트와 근거 주입 순서를 손보고, 정답률과 재현율이 동반 하락하면 저장 스키마와 청킹을 되돌립니다. stale recall이 임계선을 넘으면 사실 만료 정책과 최신성 가중치를 조정하고, 판정자-인간 일치율이 떨어지면 그 릴리스의 자동 점수를 신뢰 구간에서 제외한 뒤 사람 채점으로 대체합니다.
판정자 캘리브레이션은 매주 골든셋 일부를 사람이 이중 채점해 LLM-judge와의 일치율을 재는 것으로 유지합니다. 일치율이 90% 밑으로 떨어지면 판정 루브릭을 다시 좁히고, 판정 프롬프트를 바꾼 날짜는 지표 대시보드에 변경선으로 남겨 점수 급변의 원인이 모델인지 채점기인지 구분되게 합니다. 운영 로그에는 세션 ID, 검색된 근거 ID, 답변당 토큰, LLM-judge 판정, stale 여부를 필수 필드로 남깁니다.
개선 루프는 골든셋을 살아 있는 자산으로 굴리는 데서 나옵니다. 현장에서 걸러진 오답과 stale 오검색 사례를 매주 골든셋에 역주입하고, 공개 벤치 점수와 골든셋 점수의 격차가 벌어지는 추세를 별도 지표로 추적합니다. 이 격차가 좁혀지지 않는다면 하네스가 실사용을 대변하지 못한다는 신호이므로, 벤치가 아니라 골든셋 구성을 먼저 의심합니다.
바로 쓰는 적용 포인트
기억 계층은 붙이는 순간이 아니라 재는 체계가 있을 때 완성됩니다. 검색 지표와 LLM-judge 정답률을 분리해 채점하고, LoCoMo·LongMemEval을 계기판 삼되 자체 골든셋에서 정답률 85%·재현율 90%·stale recall 3%·판정자 일치율 90%의 합격선을 정하며, 토큰 절감률 옆에 반드시 정밀도 손실을 병기하면, 다음 기억 모델이 와도 같은 하네스로 곧장 비교할 수 있습니다.
참고 링크
Memora scales agent memory to boost long-horizon productivity — Microsoft Research
Microsoft unveils Memora to tackle AI agents' memory problem — InfoWorld