AI 에이전트 메모리는 무조건 저장 시점에 요약할 필요가 없습니다. JitMem은 과거 작업의 원시 궤적을 남겨 두고, 현재 과업을 받은 뒤에만 필요한 단서를 짧게 엮습니다. 메모리의 핵심 판단을 ‘무엇을 저장할까’에서 ‘지금 무엇을 꺼낼까’로 옮긴 방식입니다.
다만 원문을 많이 쌓는다고 자동으로 똑똑해지지는 않습니다. 검색이 빗나가거나 성공 판정이 틀리면, 읽기 시점의 좋은 요약도 그릇된 재료에서 출발합니다.
30초 요약
- 쓰기 시점 메모리는 작업이 끝날 때 고정된 요약·스킬을 저장합니다.
- JitMem은 성공한 원시 작업 궤적을 보관하고, 새 과업과 함께 읽어 임시 안내문(payload)을 만듭니다.
- 같은 과거 기록도 현재 목표가 다르면 다른 단서로 정리할 수 있습니다.
- 논문 실험의 성과는 벤치마크 결과이며, 실서비스 효과나 비용 절감을 보장하지 않습니다.
왜 저장할 때의 요약이 아쉬울까?
에이전트가 “회원 정보를 수정해 달라”는 작업을 성공했다고 해 보겠습니다. 작업 직후에는 ‘프로필 메뉴에서 수정한다’는 한 줄만 남기고 싶어집니다. 그런데 다음 과업은 주소가 아니라 알림 설정을 바꾸는 일일 수 있습니다. 미래 과업을 모르는 상태의 요약은 나중에 필요한 화면 상태나 실패 회피 조건을 먼저 버릴 수 있습니다.
기존 쓰기 시점 메모리는 보통 작업 종료 뒤 반성문, 워크플로, 스킬, 추론 전략 같은 고정된 산출물을 저장합니다. 이후에는 질의와 유사한 항목을 검색해 실행기의 컨텍스트에 넣습니다. 고정 요약 하나가 여러 미래 과업을 모두 설명해야 한다는 점이 이 방식의 부담입니다.
| 설계 | 저장하는 것 | 새 과업이 왔을 때 | 주요 위험 |
|---|---|---|---|
| 쓰기 시점 큐레이션 | 요약·스킬 같은 고정 산출물 | 유사 항목을 그대로 가져온다 | 나중에 필요한 세부 단서가 이미 빠졌을 수 있다 |
| JitMem 읽기 시점 큐레이션 | 품질 게이트를 통과한 원시 궤적 | 과업과 함께 다시 읽어 임시 payload를 만든다 | 검색·저장·큐레이터 비용과 오류가 남는다 |
생활 비유로 보면, 여행 사진을 앨범에 넣을 때 ‘맛집’ 한 줄만 적는 방식과 비슷합니다. 다음 여행에서 길을 찾고 싶은지, 예약 시간을 확인하고 싶은지에 따라 같은 사진에서 꺼낼 정보가 달라집니다. 물론 앨범을 통째로 식탁 위에 쏟아놓으면 찾는 사람도 지칩니다.
JitMem은 기록을 어떻게 꺼내 정리하나?
논문 속 JitMem은 메모리 은행, 검색기, 큐레이터, 고정된 실행기 네 부분을 둡니다. 저장되는 것은 원시 궤적이고, 큐레이터가 만든 payload는 이번 과업에서만 쓰는 임시 안내문입니다.
- 새 과업 설명으로 메모리 은행에서 관련 원시 궤적을 찾습니다. 논문 구현은 과업 설명에 BM25를 사용했습니다.
- 큐레이터가 새 과업과 검색된 궤적을 함께 읽고, 지금 필요한 전략·조건·주의점을 짧은 자연어 payload로 만듭니다.
- 고정된 실행기가 과업과 payload를 받아 행동합니다.
- 실행 뒤 품질 게이트가 성공으로 판단한 궤적만 은행에 추가합니다.
이 순서의 중요한 분리는 ‘검색’과 ‘정리’입니다. 검색기는 후보 기록을 좁히고, 큐레이터는 후보 안에서 현재 목표에 맞는 결론을 고릅니다. 원시 기록 보존은 검색 품질을 대신하지 않으며, 먼저 맞는 후보를 가져오는 일이 필요합니다.
같은 기록도 질문이 바뀌면 payload가 달라진다
아래는 논문 구조를 설명하기 위한 가상 예시입니다. 실제 JitMem 실행 결과나 공개 API 출력이 아닙니다.
입력으로 과거 궤적 두 개와 새 과업이 들어왔다고 하겠습니다.
과거 궤적 A: 설정 화면 → 알림 탭 → 이메일 알림 해제 → 저장
과거 궤적 B: 설정 화면 → 프로필 탭 → 주소 수정 → 저장
새 과업 1: “이메일 알림을 끄되, 저장 여부를 확인해.”
새 과업 2: “주소를 바꾸되, 알림 설정은 건드리지 마.”
쓰기 시점이라면 A에 ‘알림 변경 방법’, B에 ‘프로필 수정 방법’처럼 각각 한 줄의 고정 요약을 남길 수 있습니다. JitMem식 큐레이터는 새 과업 1에서는 A의 저장 확인 순서를 강조하고, 새 과업 2에서는 B의 프로필 탭과 ‘알림 탭을 피한다’는 제약을 payload에 담는 식입니다. 과업이 바뀌면 같은 기록에서 꺼내는 조건도 달라집니다.
과업 2용 임시 payload 예시
- 설정의 프로필 탭에서 주소를 수정한다.
- 알림 탭은 열지 않는다.
- 저장 후 주소 필드가 바뀌었는지 확인한다.
같은 기록을 다시 요약하는 비용을 내는 대신, 요약의 목적어가 현재 과업으로 고정됩니다. 그래서 논문은 큐레이터의 학습 보상도 먼 미래가 아니라 그 과업의 성공 보상으로 받도록 설계했습니다. 저자들은 이때 GRPO(Group Relative Policy Optimization)를 사용하고 실행기는 고정했습니다.
성과 수치는 어디까지 읽어야 하나?
저자들은 ALFWorld, WebShop, tau2-bench에서 가장 강한 비교 기준 대비 각각 16.2, 16.3, 3.9 절대 성공률 포인트 향상을 보고했습니다. 같은 본문에서 쓰기 시점 방법 대비 입력 토큰 50.3~56.3%, 실행기 단계 28.4~31.4% 감소도 보고합니다.
이 숫자는 흥미롭지만 바로 운영 KPI로 옮기면 안 됩니다. 벤치마크의 과업 분포, 원시 궤적의 형태, 품질 판정 방식, 실행 모델이 다르면 결과도 달라집니다. 논문의 개선 폭은 ‘읽기 시점 큐레이션을 시험할 이유’이지, 모든 제품에서 재현될 약속은 아닙니다.
특히 초반에는 저장된 성공 궤적이 거의 없어 콜드스타트가 생깁니다. 논문도 테스트 시퀀스를 빈 은행에서 시작하면 초기 과업이 메모리 혜택을 덜 받는다고 설명합니다. 원시 기록을 많이 보관하는 설계는 저장 공간, 개인정보·비밀값 마스킹, 보존 기간, 검색 지연을 함께 설계해야 합니다.
언제 JitMem식 설계가 맞을까?
작업 궤적 하나가 여러 목적에 재사용되고, 나중의 질문이 저장 시점에는 예측하기 어려울 때 후보가 됩니다. 브라우저 조작, 고객 지원 도구 사용, 여러 단계의 사내 워크플로처럼 ‘성공한 경로’ 안에 세부 조건이 많은 경우가 여기에 가깝습니다.
반대로 매번 같은 형식의 답만 필요하거나, 원시 로그를 보존할 수 없거나, 검색 후보가 매우 적은 단순 흐름이라면 고정된 짧은 스킬이 더 관리하기 쉽습니다. 도입 기준은 ‘원문을 보관할 수 있나’보다 ‘같은 경험에서 과업마다 다른 단서를 뽑아야 하나’입니다.
시작한다면 모델 학습부터 붙이지 않아도 됩니다. 먼저 성공 궤적의 민감정보를 제거하고, 현재 과업+상위 검색 결과에서 짧은 안내문을 만드는 프롬프트형 큐레이터를 평가해 보세요. 그 다음에 고정 요약 방식과 비교해 과업 성공률, 검색 적중률, payload 길이, 지연 시간을 같은 로그에서 측정하는 편이 안전합니다.
작업 환경을 함께 정리한다면
에이전트 메모리 설계는 소프트웨어 문제지만, 긴 궤적·프롬프트·평가 로그를 대조할 때는 화면을 세우고 창을 오가는 작업도 이어집니다. 아래 두 카드는 검토 흐름을 위한 보조 도구이며, JitMem의 성능을 높이는 제품은 아닙니다.
로그와 문서를 나란히 읽을 자리가 부족하다면 높이조절 노트북 거치대가 화면 배치에 맞을 수 있습니다.
로그 타임라인과 여러 창을 자주 오간다면 블루투스 트랙볼을 포인팅 도구 후보로 볼 수 있습니다. 손 크기와 연결 방식은 카드에서 별도로 확인하는 편이 좋습니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- Zhou, Y. et al., Just-in-Time Memory: Learning to Curate Task-Adaptive Memory for LLM Agents, arXiv:2609.27334v1, 2026-09-23 공개.
- 논문 HTML 전문: Method and experiments
핵심 정리: 다섯 가지 질문과 답
Q. JitMem은 메모리를 아예 요약하지 않나요?
원시 궤적은 저장하고, 새 과업을 받은 시점에 필요한 내용을 임시 payload로 요약합니다. 그 payload 자체는 영구 메모리로 저장하지 않는 구조입니다.
Q. 쓰기 시점 요약보다 항상 낫나요?
아닙니다. 논문은 특정 벤치마크에서의 결과를 보고했으며, 단순하고 반복적인 흐름에서는 고정 스킬이 더 가벼울 수 있습니다.
Q. 왜 원시 궤적을 그대로 보관하나요?
미래 과업이 무엇을 요구할지 모를 때, 고정 요약에서 빠진 세부 단서를 나중에 다시 골라 쓰기 위해서입니다.
Q. 가장 먼저 점검할 위험은 무엇인가요?
원시 로그의 민감정보, 성공 판정 오류, 검색 실패, 초기 콜드스타트, 저장·검색 지연을 함께 점검해야 합니다.
Q. 바로 학습형 큐레이터를 만들어야 하나요?
아닙니다. 먼저 프롬프트형 읽기 시점 큐레이션과 고정 요약을 같은 과업 로그에서 비교해 도입 가치를 확인하는 편이 낫습니다.
'AI > AI 최신 기술' 카테고리의 다른 글
| 토큰 중첩 학습, 두 텍스트를 한 번에 예측해도 되는 이유와 멈춰야 할 지점 (0) | 2026.09.26 |
|---|---|
| SWE-bench 점수, 높은데도 에이전트를 바로 맡기면 안 되는 이유 (0) | 2026.09.25 |
| GameHorizon 장기 행동 평가, 짧은 점수로 에이전트를 믿으면 놓치는 것 (0) | 2026.09.22 |
| RecreationWorld, 화면만 닮은 AI 앱을 멈추게 하는 동작 검증 (0) | 2026.09.21 |
| EvoOntology, 컬럼명만 보고 헤매는 데이터 에이전트를 어떻게 멈추나 (0) | 2026.09.21 |
댓글