긴 작업을 맡은 AI 에이전트가 있다. 도구를 수십 번 부르며 일하다 기록 둘 공간이 모자라자, 지금까지를 짧은 요약으로 압축한다. 그런데 압축하자마자, 방금 실패한 그 명령을 똑같이 다시 실행한다.
왜 그럴까. 요약은 "무엇을 했다"는 큰 줄기는 남긴다. 하지만 두 가지를 흘린다. 하나는 "그 명령이 왜 실패했는가"다. 다른 하나는 "이 결론이 어느 자료에서 나왔는가", 곧 주장과 근거를 잇는 끈이다. 앞의 것을 잃으면 에이전트는 같은 실수를 되풀이한다. 뒤의 것을 잃으면 보고서에 그럴듯한 문장을 쓰고도 출처를 엉뚱한 곳에 붙인다.
REMORY는 이 두 구멍을 겨냥한다. 압축하는 순간, 원래 기록과 그 요약을 함께 읽어 '보조 메모리'를 하나 만든다. 사람이 읽는 요약은 그대로 두고, 그 옆에 모델만 읽는 메모리를 덧붙인다. 그래서 흐름은 이렇게 간다. 원본 기록 → (사람용 요약 + 모델용 보조 메모리) → 다음 행동.
결과부터 말하면 둘로 갈린다. 같은 명령을 다시 부르거나 같은 실패를 되풀이하는 헛수고가 줄었다. 그리고 보고서에서 주장을 제 출처에 잇는 능력이 올랐다. 반대로, 없던 내용을 새로 더 찾아내 주지는 않았다. 메모리는 '더 찾기'가 아니라 '제대로 잇기'를 도왔다.
긴 작업일수록 관찰 결과, 도구 출력, 결정이 쌓인다. 맥락 창(모델이 한 번에 볼 수 있는 입력 공간)은 정해져 있다. 그래서 어느 순간 과거를 눌러 담아야 한다. Claude Code나 Codex CLI의 /compact 명령이 그 일을 한다. 이전 대화를 텍스트 요약으로 바꿔 자리를 비우고, 그 요약이 이어 일할 체크포인트가 된다.
그래서 입력 길이는 톱니처럼 움직인다. 쌓이다가 압축 때 뚝 떨어지고 다시 쌓인다. 문제는 그 골짜기, 압축 직후에 생긴다. 요약은 큰 흐름은 지키지만, 앞으로 내릴 모든 결정을 받쳐 준다는 보장이 없다. 게다가 지금 중요한 정보가 한 시간 뒤에도 중요할지는 그때 가 봐야 안다.
여기에 이 연구의 전제가 있다. "요약에 이 세 문장만 더 끼우면 된다"는 식의 사전 선별은 통하지 않는다. 무엇이 쓸모 있어질지 미리 고를 수 없는 상황을 다룬다.
긴 맥락을 다루는 기존 방법은 크게 둘이다. 하나는 과거를 사람이 읽는 글로 저장해 뒀다가 필요할 때 검색해 꺼내는 쪽. 다른 하나는 긴 글을 모델만 읽는 숫자 묶음으로 눌러 담는 쪽.
REMORY는 둘을 겹친다. 텍스트 요약과 검색은 손대지 않는다. 그 위에, 요약과 원본을 함께 보고 만든 숫자 메모리를 한 겹 얹는다. 정확한 과거가 꼭 필요하면 에이전트는 여전히 파일 검색 같은 평범한 도구로 꺼낸다. REMORY가 채우는 건 검색을 부르기 전, 모델이 다음 수를 두는 바로 그 순간이다. 검색을 없애려는 게 아니라, 검색까지 안 가도 될 몫을 미리 채워 둔다.
이 메모리의 정체를 짚자. 네트워크가 내놓는 건 단어가 아니라 모델이 입력으로 바로 읽는 숫자 묶음(연속 벡터)이다. 과거를 글로 다시 쓰는 게 아니라, 모델 입력 자리에 숫자 형태로 놓인다.
규칙이 하나 있다. 실제로 일하는 작업 모델은 건드리지 않는다. 그 모델 안의 학습된 값(가중치)은 그대로 두고, 메모리를 만드는 네트워크만 배운다. 배움은 고정된 작업 모델을 거쳐 메모리 쪽으로만 흐른다.
학습은 두 단계다. 1단계는 복원 연습이다. 원문 한 구절을 메모리로 바꿔 놓아도 그 구절을 되살릴 수 있게 가르친다. 메모리가 원본 정보를 품게 하려는 것이다. 2단계는 역할을 나눈다. 요약과 메모리만 가진 쪽이, 전체 기록을 다 본 쪽과 같은 다음 응답을 내도록 맞춘다. 요약은 이미 주어져 있으니, 메모리는 자연히 요약이 못 채운 빈자리 쪽으로 방향을 잡는다. 그래서 메모리는 요약과 내용이 겹쳐도 되고, 빠진 사실을 전부 복원할 필요도 없다. 요약이 이미 주는 정보까지 메모리가 다 떠안을 이유가 없기 때문이다. 이름의 'RE'가 여기서 왔다. 요약 위에 '차이'만 얹는다는 뜻이다.
- 압축 단위: 최대 1,024개 원본 위치로 된 블록 하나가 64개의 소프트 메모리 토큰을 만든다. 계층적 압축으로 최종 메모리를 4,096 슬롯 이하로 묶되 원본 순서는 보존한다. - 작업 모델에 전달할 때는 요약 뒤에 소프트 메모리 토큰을 이어 붙인다(concatenation). gated cross-attention은 메모리 네트워크가 메모리를 생성하면서 요약을 참조하는 데 쓰인다. - 아키텍처: Qwen3.8-27B에는 DFlash를, GLM-5.3-Flash에는 그룹 동적 컨볼루션을 쓰는 DFlash-2를 적용했다. 메모리 네트워크의 학습 파라미터는 각각 1.94B, 1.502B다. - 1단계 데이터: MMFineReason-Full-2.3M의 텍스트 필드. 교사에게 원문을 그대로 말하라고 지시하고, 학생은 그 구절을 소프트 메모리로 대체해 같은 예측을 하게 한다. - 2단계 데이터: 추론·코딩 궤적. Open-PerfectBlend의 프롬프트와 미리 계산된 요약, Qwen이 생성한 응답을 포함하며, 선행 맥락 길이 순으로 정렬한 커리큘럼을 따른다. - 최적화: 학생→교사 역방향 KL. 전체 히스토리를 본 교사의 다음 토큰 분포를, 요약과 메모리만 가진 학생이 흉내 내게 맞춘다. 손실은 전체 어휘와 응답 전체에 걸치고 앞쪽 위치를 약하게 더 강조한다. 메모리 파라미터만 갱신된다.
실험은 두 질문을 가른다. 메모리가 요약이 놓친 정보를 정말 배우는가. 그리고 단지 자리를 더 줘서 좋아진 건 아닌가.
출처 연결은 SummHay로 잰다. 긴 문서 더미에서 질문에 맞는 통찰을 찾아내고 그 출처를 잇는 능력을 보는 벤치마크다. 네 가지를 견준다. 전체 맥락(raw), 요약만, 요약에 같은 분량의 텍스트를 더 붙인 summary++, 그리고 요약+REMORY.
열쇠는 summary++다. REMORY가 더 쓰는 만큼의 자리를 똑같이 '생성한 텍스트'로 채운 조건이다. "자리를 더 줘서 좋아진 것 아니냐"는 반론을 이 조건이 막는다.
에이전트 성능은 BrowseComp, Terminal-Bench 2.1, AutomationBench, JobBench로 본다. 비교마다 같은 작업 모델 안에서 실행 환경, 프롬프트, 도구, 예산, 생성 설정, 압축 정책을 전부 고정하고 메모리 유무만 바꾼다. 양쪽 다 정확한 과거를 검색할 수 있고, 유일한 개입은 압축 때 최대 4,096 슬롯을 더하는 것뿐이다. 차이가 나면 원인을 메모리로 좁힐 수 있다.
- SummHay: 열 개 컬렉션의 92개 질의 전부를 Qwen3.8-27B로 평가. 답변 생성에는 도구·검색이 없고, 정답 통찰과 인용은 채점에만 쓴다. 채점은 GPT-5.6-Sol. 커버리지와 종합 점수는 621개 전체 참조 통찰에, 인용 F1은 회수된 통찰에 대해 평균한다. - 맥락 창: Qwen 262,144 위치, GLM 100만 위치. - 과제 수·실행: BrowseComp 1,266개·Terminal-Bench 89개는 두 액터 모두 1회, AutomationBench 600개·JobBench 65개는 Qwen으로 5회 실행. - 판정: Terminal-Bench·AutomationBench는 과제 검증기, BrowseComp·JobBench는 GPT-5.6-Sol 판정자. - 비용 기준: 2026년 9월 비캐시 공급가로 액터와 요약 토큰에 값을 매기고 잔차 위치를 입력으로 센 수치. 원본 특징 인코딩, 메모리 네트워크 실행, 도구 비용은 빠져 있다. 즉 토큰 가격 기준 생성 비용이지 총 실행 비용이 아니다.
먼저 행동이다. 네 벤치마크에서 점수가 모두 올랐고, 그 개선은 더 센 작업 모델과 더 큰 맥락 창에서도 유지됐다(GLM-5.3-Flash는 맥락 창 100만, 320B 규모다).
| 벤치마크 | 작업 모델 | 점수 변화 | 실행 |
|---|---|---|---|
| AutomationBench | Qwen | 35.5 → 45.3 (+9.8) | 5회 평균 |
| JobBench | Qwen | 33.4 → 41.0 (+7.6) | 5회 평균 |
| Terminal-Bench | Qwen | 71.9 → 76.4 (+4.5) | 1회 |
| BrowseComp | Qwen | 74.0 → 77.0 (+3.0) | 1회 |
| Terminal-Bench | GLM | 84.3 → 87.6 (+3.3) | 1회 |
| BrowseComp | GLM | 84.9 → 89.0 (+4.1) | 1회 |
더 또렷한 건 '어떻게' 올랐는지다. 한 과제 안에서 같은 도구가 같은 출력을 다시 내는 반복은 17.9~29.8% 줄었다. 실패한 명령이나 도구 오류는 25.3~49.7% 줄었다(반복은 계획·폴링은 빼고 센 값, 오류는 실패 명령과 명시적 도구 오류를 센 값이다). 압축으로 과거를 잃은 에이전트는 방금 한 호출을 또 하거나 같은 실패를 되풀이하기 쉬운데, 그 헛수고가 눈에 띄게 줄었다. 비용도 JobBench($3.09→$3.21) 하나를 빼면 보고된 모든 비교에서 떨어졌다.
압축 직후 '첫 수'만 떼어 본 비교도 있다. 100개 Qwen BrowseComp 기록에서 뽑은 488개 짝지은 다음 행동을, 요약과 상주 지시를 고정한 채 심판 모델이 견줬더니 메모리 쪽이 345승(70.7%), 21무, 122패였다. 단, 이건 '제안한 다음 수'에 대한 선호지, 그 수가 실제로 낳았을 결과의 측정은 아니다.
이제 출처 연결이다. 여기가 이 연구의 진짜 발견이다. SummHay에서 요약만 쓸 때와 요약+REMORY를 견주면 이렇다.
| 무엇을 재나 (요약 단독 → 요약+REMORY) | 변화 |
|---|---|
| 내용 회수 (커버리지) | +0.40 — 사실상 그대로 |
| 출처 연결 (인용 F1) | +4.04 |
| 종합 점수 | +3.55 |
읽는 법은 간단하다. 메모리는 없던 통찰을 새로 찾아 주지 않았다. 대신 이미 찾은 주장을 제 근거에 제대로 이어 줬다. 두 요약 조건 모두에서 회수된 통찰 553개로만 좁혀 봐도 인용 F1은 57.31에서 61.41로 올랐다.
그럼 자리를 더 줘서 좋아진 걸까. 아니다. 같은 자리를 생성 텍스트로 채운 summary++는 요약만 쓸 때와 거의 붙어 있었다.
| 표현 | 종합 점수 | 평균 입력 위치 |
|---|---|---|
| 전체 맥락(raw) | 43.41 | 96,872 |
| 요약 단독 | 39.84 | 1,393 |
| summary++ | 39.78 | 요약 단독 + 추가 텍스트 |
| 요약+REMORY | 43.39 | 5,024 |
같은 공간이라도 평범한 텍스트로 채우면 소득이 없고, 학습된 메모리로 채워야 출처 연결이 올랐다. 게다가 요약+메모리는 전체 맥락이 쓰는 입력 자리의 5.2%만 쓰고도 종합 점수에서 raw에 바싹 붙었다.
먼저 결과가 말해 주지 않는 것부터. 1단계 학습의 목표는 원문을 그대로 복원하는 것이고, 2단계의 목표는 다음 행동에 쓸모 있는 정보를 남기는 것이다. 모든 사실을 되살리는 것과, 당장 다음 수에 필요한 사실만 남기는 것은 다르다. 지금 수치가 보여 주는 신호는 뒤쪽, 즉 행동과 출처 연결이 좋아졌다는 결과다.
이 구분이 중요하다. 도입에서 "실패 이유를 메운다"고 했지만, 실제로 측정된 건 실패가 줄었다는 '행동'이지, 메모리 안에 그 실패 이유가 들어 있다는 '증거'가 아니다. 둘을 가르려면 한 걸음 더 들어가야 한다. 압축 전 기록의 '실패 원인' 같은 정보가 메모리에 살아남았는지 직접 뜯어보거나, 그 정보를 일부러 가렸을 때 압축 직후 행동이 어떻게 달라지는지 보는 식이다. 성능이 좋아진 것과 그 속이 어떻게 돌아가는지 사이에는 아직 이만큼 간극이 있다.
저자들이 밝힌 선도 있다. 그림 1의 프런티어 점수들은 원래 실행 환경과 규약으로 공표된 참고값이지 통제된 비교가 아니다. 앞의 '첫 수' 선호 결과는 제안에 대한 선호지 실제 결과가 아니고, 비용은 토큰 생성가 기준이라 메모리 네트워크를 돌리는 값은 빠져 있다.
적용 조건도 만만치 않다. 이 방법은 작업 모델마다 1.94B·1.502B 규모의 메모리 네트워크를 따로 학습해야 하고, 그 학습이 작업 모델을 거쳐야 한다. 그래서 내부를 못 건드리는 완전한 블랙박스 API 위에는 그대로 올리기 어렵다. 가중치를 직접 서빙하는 쪽에 유리한 설계다. 모든 수치가 특정 두 작업 모델, 특정 벤치마크에서 나온 만큼 다른 모델·도메인으로 번질지는 아직 열린 질문이다.
먼저 선을 긋자. 온틀의 모델은 대부분 외부 API(Vertex 경유 Gemini, Claude) 위에서 돈다. 가중치 접근을 전제로 한 이 기법을 그대로 얹을 수 없다. 그러니 아래는 당장 붙일 기능이 아니라, 온틀에서 시험해 볼 설계 판단 하나다. 핵심은 이것이다. 압축할 때 잃으면 안 되는 업무 상태를, 요약과 분리해 따로 보존한다.
출처가 어긋나면 바로 티가 나는 일부터 보자. 온틀의 AI PM이 경쟁사 랜딩 열 곳을 훑고 그 자료로 제안서를 쓴다고 하자. "이 가격 정책은 A사 페이지에서, 저 혜택 문구는 B사 페이지에서"처럼 주장마다 출처가 정확히 붙어야 한다. 그런데 압축이 한 번 돌면 요약은 "경쟁사 10곳 조사, 제안서 초안 작성"이라는 줄기는 남기지만, 어느 문장이 어느 페이지에서 왔는지는 흐려진다. 바로 이 연구가 개선한 지점이다.
반복 쪽도 같다. 같은 PM이 예약 발행 API를 부르다 실패했는데, 압축이 그 실패 메시지를 흘렸다고 하자. 직후에 같은 호출을 같은 이유로 또 시도한다. 사람 손이 부족한 소기업의 반복 업무를 대신 도는 제품에서, 이 헛호출 한 번은 곧 지연이자 비용이다.
그래서 온틀이 시험할 건 연구 기법의 재현이 아니다. 우리는 반복 낭비를 부르는 정보가 무엇인지 이미 안다. 끝낸 URL, 실패한 호출과 그 원인이다. 질문은 하나로 좁혀진다. 이 '이미 한 일'을 요약과 분리해 따로 들고 가는 것이 값을 하는가.
실험은 이렇게 짠다. 끝낸 URL과 실패한 호출·원인을, 압축과 무관하게 별도 채널로 남기는 경로를 만든다. 그리고 같은 작업을 이 별도 기록이 있을 때와 없을 때로 나눠 돌린다. 볼 지표는 넷이다. 반복 호출, 오류 재발, 작업 성공률, 총비용. 자리를 더 줘서 생긴 효과와 가르려면, 그 자리를 그냥 평범한 텍스트로 채운 조건을 같이 돌려 대조군으로 둔다. 비용은 토큰값과 전체 실행값을 따로 적어야 비교가 공정하다.
판단 기준은 미리 못 박자. 작업 성공률을 지키면서 반복 호출과 총비용이 줄면, 외부 API 위에서도 '이미 한 일' 채널이 제값을 한다는 근거가 된다. 그런 개선이 안 보이면 결론은 "요약 하나로 충분"이 아니다. "이번에 고른 기록과 제공 방식으로는 효용을 확인하지 못했다"까지다. 다른 기록, 다른 방식의 여지는 그대로 열려 있다.
아니다. 블록을 계층적으로 다시 묶어 최종 메모리를 4,096 슬롯 이하로 유지한다. 원본 순서는 보존하되 총량에는 상한이 있다.
필요 없다. 전체 기록을 본 교사는 학습 때 정답 노릇만 한다. 실제 운영에서는 요약과 메모리만으로 다음 응답을 낸다.
맥락 창을 키우면 과거를 원문 그대로 더 많이 들고 가야 해서 입력 자리를 많이 쓴다. REMORY는 훨씬 적은 입력 자리로 비슷한 종합 점수에 닿았다. 자리를 늘리는 접근이 아니라, 적은 자리로 과거의 쓸모만 남기는 접근이다.