장시간 AI 에이전트의 기억을 지키는 메모리 하네스 설계

원문 제목: [한영자막] 장시간 AI 에이전트가 기억을 잃지 않게 만드는 법 — Stefania Druga, Sakana.ai

URL: https://www.youtube.com/watch?v=yUjTWl7tOYc
날짜: 2026-08-14
채널: Tech Bridge
발표자: Stefania Druga (Sakana AI)
영상 길이: 11분 53초
주제: 장기 실행 연구 에이전트(Long-running research agents), 메모리 하네스(memory harness), 로컬 모델(local models)

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==장시간 작업에서 에이전트의 기억을 모델 자체의 장기 기억으로 가정하지 말고, 기록·관리·검색을 통제하는 메모리 하네스라는 제어 루프로 설계해야 한다.== 작업이 컨텍스트 창에 모두 들어갈 때 메모리는 비용만 늘릴 수 있지만, 관련 정보가 창 밖으로 밀려나는 장기 작업에서는 검색 정책의 품질이 성능과 비용을 좌우한다.

• 장기 작업에서는 컨텍스트 폭발(context blow)과 컨텍스트 부패(context rot)가 자기모순, 중복 작업, 질문 이탈로 나타난다.
• 로컬 모델과 로컬 하네스는 데이터·추론 trace·평가의 전 과정을 통제할 수 있어 메모리 정책을 정밀하게 실험할 수 있다.
• X-Bench와 Spider V2 실험에서 무작정 메모리를 붙이는 것보다 순위를 매기는 회수 정책(ranked recall policy)이 효과와 비용 면에서 우수했다.
• 메모리는 데이터베이스에 저장하는 기능이 아니라 모델을 둘러싼 write–manage–read 제어 루프다.

장기 지평(long-horizon) 작업은 늘어나고 모델 릴리스 간격은 길어지는 추세이므로, 모델이 더 큰 컨텍스트를 갖게 될 때까지 기다리는 대신 어떤 기억을 저장하고 어떤 순서로 회수할지에 대한 구조적 정책을 먼저 평가해야 한다.

1. 장기 에이전트에서 기억이 무너지는 이유

장시간 작업의 병목은 모델의 단순한 지식 부족보다, 앞서 수행한 작업과 질문을 지속적으로 추적하지 못하는 컨텍스트 관리 문제에 있다.

1.1. 컨텍스트 폭발과 컨텍스트 부패

1. 자기모순과 중복 작업

   1. 자기모순: 작업이 길어지면 모델이 앞서 한 말과 서로 모순되는 답을 내기 시작한다.
   2. 작업 망각: 이미 수행한 일을 잊어버려 같은 작업을 다시 실행한다.
   3. 질문 이탈: 사용자가 처음 던진 질문을 잊고 원래 요구사항에서 벗어난 방향으로 진행한다.

2. 장기 작업으로의 수렴

   1. 더 긴 작업 지평: METR의 최근 전망을 근거로, AI 시스템이 해결하려는 과제가 점점 더 긴 시간 범위를 갖는 흐름이 제시된다.
   2. 모델 릴리스 감소: 한편 모델 릴리스는 점점 줄어드는 추세로 언급된다.
   3. 문제의 우선순위 상승: 올해 후반에는 장기 작업은 많아지고 모델 릴리스는 적어지는 수렴이 일어날 수 있으므로 컨텍스트 부패 대응이 우선 과제가 된다.

1.2. 로컬에서 문제를 다루는 동기

1. 비용 절감과 사용량 확대

   1. Coinbase 사례: Coinbase CEO가 이틀 전 공유한 사례에서는 AI 사용량을 늘리면서 AI 지출을 줄인 방법으로 로컬 모델의 적극적 활용이 소개된다.
   2. 운영 최적화: 더 나은 라우팅(routing), 캐싱(caching), 깨끗한 컨텍스트 유지, 사용자가 어떤 작업에 AI를 쓰는지에 대한 가시성이 비용 절감과 사용량 증가를 뒷받침했다.

2. 로컬 모델의 실용화

   1. 모델의 경계 통과: 로컬 모델은 에이전트 작업과 도구 사용(tool use)에 활용할 수 있는 수준에 접근하고 있다.
   2. 예시 모델: GLM이 많은 사람의 관심을 받고 있으며, Fable이 사라진 상황과 함께 언급된다. DeepSeek V4 Flash는 M3 Ultra에서 실행할 수 있다.
   3. 남은 병목: 실행 자체보다 RAM이 여전히 병목이며, 로컬 모델 운용은 아직 까다롭다.

2. 실험 환경과 메모리 하네스의 정신 모델

모델에게 내구성 있는 메모리를 직접 부여하는 대신, 메모리 기능이 없는 작은 연구 에이전트와 외부 하네스를 결합해 하네스의 정책만 바꾸는 실험을 구성했다.

2.1. 로컬 실험 환경

1. 하드웨어와 운용 방식

   1. 장비: 도쿄 책상에 둔 Mac에서 평가를 실행하고 휴대전화로 원격 제어했다.
   2. 지속 실행: 며칠 동안 평가를 멈추지 않고 돌리자 기기가 뜨거워졌고, 남편이 주변에 팬을 설치했다. 팬이 부족해지는 상황에서도 기계와 평가는 계속 작동했다.
   3. 구성: M3 Ultra, 96GB 메모리, 28코어 CPU를 사용했다.

2. 평가 모델

   1. Qwen 27B: 4비트 양자화(quantization) 버전을 사용했다.
   2. DeepSeek V4 Flash: 두 번째 평가 모델로 사용했다.
   3. 통제 원칙: 모델은 여러 작업에서 고정하고, 회수 블록의 변수만 바꿔 메모리 정책의 효과를 분리했다.

2.2. 메모리는 저장소가 아니라 제어 루프다

1. write–manage–read 모델

   1. 쓰기(write): 실행 중 발생한 정보와 trace를 기억 시스템에 기록한다.
   2. 관리(manage): 여러 세션에 걸쳐 어떤 정보가 남고 어떤 우선순위를 가질지 관리한다.
   3. 읽기(read): 현재 루프에 필요한 기억을 검색해 모델 컨텍스트에 넣는다.
   4. 제어 루프: 따라서 메모리는 단순한 데이터베이스 저장 기능이 아니라 모델을 둘러싼 제어 루프다.

2. 하네스의 구성 요소

   1. 기억 없는 연구 에이전트: 작은 에이전트는 durable memory가 전혀 없고, 모든 기억을 하네스에서 공급받는다.
   2. trace 코어: 에이전트에게 항상 표시되는 실행 trace의 핵심 블록을 둔다.
   3. recall 블록: 여러 기억 회수 방식을 사다리처럼 배치해 비교한다.
   4. archival 블록: 세션이 바뀌어도 정보를 추적할 수 있도록 세션 간 기록을 보존한다.

2.3. 회수 정책 사다리

1. 기준선부터 정답 참조까지

   1. 메모리 없음: recall을 전혀 사용하지 않는 기준선이다.
   2. 벡터 RAG: 유사도(similarity)를 기준으로 하네스가 가져오는 내용을 그대로 사용한다.
   3. 결정 원장(decisions ledger): 매 턴마다 내린 결정을 기록하고, 그 결정들을 우선순위화해 회수한다.
   4. 오라클(oracle): 각 루프에서 회수해야 할 정확한 기억이라는 ground truth를 하네스에 제공한다.

2. 통제된 비교

   1. 모든 정책에서 모델과 작업을 유지하고 recall 블록의 방식만 바꾼다.
   2. 오라클은 이상적인 회수 대상이 무엇인지 알려주는 참조점이지, 모델이 반드시 그 정보를 사용하도록 강제하는 기능은 아니다.

3. 실험 1: 컨텍스트 안에 들어오는 문헌 검토

작업 전체와 관련 자료가 컨텍스트 창에 들어오는 경우에는 메모리 하네스가 새로운 능력을 거의 추가하지 못하며, 오히려 비용을 늘릴 수 있다.

3.1. 과학적 주장과 철회 사례

1. 문헌 검토 과제 구성

   1. 코퍼스: 큰 과학적 주장이 포함된 논문을 많이 넣은 문헌 코퍼스를 구성했다.
   2. Nature 사례: 742,000개의 유망한 물질을 발견했다는 Nature 논문의 매우 큰 주장을 사례로 들었다.
   3. 철회 정보: 해당 주장은 나중에 철회됐지만, 철회 사실은 헤드라인과 인용 정보에 비해 코퍼스 안에서 훨씬 작은 바늘처럼 묻혀 있었다.

2. 검증 질문

   1. 시스템이 큰 주장 자체가 아니라 그 주장을 바로잡는 철회라는 작은 단서를 회수할 수 있는지 확인했다.
   2. 질문에 필요한 논문과 정보가 모두 컨텍스트에 들어오는 조건에서 메모리 유무를 비교했다.

3.2. 메모리가 항상 이득을 주지 않는 조건

1. 성능 결과

   1. 모든 논문과 정보가 컨텍스트에 들어오면 메모리 사용 여부에 따른 성능 차이가 없었다.
   2. 메모리는 추가 능력을 만들지 못하고 추가 비용만 만들었다.

2. 설계 원칙

   1. 적합성 판단: 작업이 컨텍스트에 들어갈 때는 하네스를 붙이는 것이 자동으로 좋은 선택이 아니다.
   2. 적용 조건: 작업이 장기 지평으로 늘어나 전체 작업 또는 관련 컨텍스트가 들어가지 않을 때 메모리 하네스의 가치가 나타난다.

4. 실험 2: 컨텍스트 밖의 기억을 회수하는 장기 작업

X-Bench에서는 질문이 발생한 시점과 정답이 기록된 시점이 멀리 떨어져 있어, 에이전트가 하네스를 통해 특정 과거 단계를 회수해야 한다.

4.1. X-Bench의 시간적 분리

1. 질문과 정답의 거리

   1. 질문에 대한 정답은 예를 들어 124번째 단계(step 124)에 기록돼 있다.
   2. 실제 질문 시점은 500번째 단계(step 500)다.
   3. 정답이 이미 컨텍스트 창 밖으로 밀려났으므로 현재 모델은 메모리 하네스 없이는 해당 내용을 직접 볼 수 없다.

2. 평가 설계

   1. 메모리 off 기준선과 여러 종류의 recall을 배치했다.
   2. 오라클을 참조 조건으로 사용해 회수 대상이 맞더라도 모델이 이를 활용할 수 있는지 분리해서 확인했다.
   3. 총 68개 질문을 실행했고, 각 질문에 여러 셀과 다양한 random seed를 적용했다.

4.2. 순위 기반 회수의 성능

1. 핵심 결과

   1. 순위 기반 회수(ranked recall)를 사용하면 메모리를 사용하지 않을 때보다 정답을 더 자주 찾았다.
   2. 세부 성능 분해에서 rank-only ledger가 가장 높은 성능을 냈다.
   3. 단순히 “메모리가 필요한가?”를 먼저 판정하는 게이트(gating) 방식보다 rank-only ledger가 좋았다.

2. 오라클이 최고점에 도달하지 못한 이유

   1. 오라클은 올바른 정보와 올바른 기억을 모델에 제공할 뿐, 모델이 그것을 반드시 사용하게 만들지는 않는다.
   2. 모델은 올바른 기억을 받은 뒤에도 잘못된 정보를 다시 회수하거나, 그 기억을 무시하거나, 제공된 기억 때문에 혼란스러워할 수 있다.
   3. 따라서 완벽한 회수 대상이 주어져도 최종 답변 성능은 모델의 선택과 해석 능력에 의해 제한된다.

4.3. 절제(ablation) 실험과 일반화

1. 회수 입력을 흔든 실험

   1. 임의의 예시를 넣었을 때 어떤 결과가 나오는지 확인했다.
   2. 틀린 단계(step)를 제공했을 때의 영향을 확인했다.
   3. 가장 최근 단계를 제공했을 때의 결과도 비교했다.
   4. 이런 조건들을 비교해도 순위 기반 회수 정책이 가장 잘 수행되는 조건으로 남았다.

2. 모델·벤치마크 간 재현

   1. 결과는 Qwen 27B에만 국한되지 않고 DeepSeek V4 Flash에서도 나타났다.
   2. X-Bench 외에 Spider V2에서도 같은 방향의 결과를 확인했다.
   3. 즉 특정 모델이나 특정 벤치마크의 우연한 특성보다 회수 정책 구조 자체의 효과로 해석할 근거가 있다.

5. 비용과 시스템 설계에 대한 시사점

잘못된 기억은 토큰을 더 쓰게 하고 에이전트를 잘못된 방향으로 보내지만, 구조적인 회수 정책은 정확도를 높이면서 예산도 줄일 수 있다.

5.1. 나쁜 메모리의 비용

1. 토큰 비용

   1. 관련 없는 기억을 컨텍스트에 넣으면 모델이 더 많은 토큰을 읽고 처리해야 한다.
   2. 긴 작업에서 이 비용은 누적되어 전체 실행 예산을 크게 만든다.

2. 경로 이탈 비용

   1. 잘못된 기억은 단순히 쓸모없는 정보가 아니라 에이전트를 잘못된 작업 경로로 보낼 수 있다.
   2. 잘못된 경로를 수정하고 재작업하는 비용까지 발생하므로 나쁜 메모리는 비싸다.

5.2. 회수 정책을 일급 평가 지표로 만들기

1. 정책 자체를 측정하기

   1. 메모리를 저장했는지만 보지 말고 recall policy를 first-class metric으로 평가해야 한다.
   2. 어떤 종류의 기억을 저장할지, 기억의 순위를 어떻게 정할지, recall function을 어떻게 설계할지를 독립적인 설계 질문으로 다뤄야 한다.

2. 반복 실행에서 살아남는 기억

   1. 동일한 작업을 반복 실행하고 여러 세션을 거칠 때 어떤 정보가 계속 살아남는지 확인해야 한다.
   2. 한 번의 검색 적중보다 여러 실행과 세션을 넘어 유지되는 정보의 안정성이 더 중요하다.
   3. 저장·관리·회수 전 과정을 함께 평가해야 하며, 단순 벡터 유사도만으로 장기 기억을 설계해서는 안 된다.

6. 메모리 기술의 넓은 지형과 로컬 주권

메모리 구현은 단순 파일 검색부터 학습된 메모리 모델까지 넓은 스펙트럼에 있으며, 로컬 실행은 이 전체 파이프라인을 직접 통제하는 주권적 실험 환경을 제공한다.

6.1. 기술 지형

1. 구조와 인지 기법의 다양성

   1. 오픈소스 저장소 Diamond에는 실행 가능한 메모리 cookbook이 30개 이상 공유돼 있다.
   2. 메모리는 단기 기억과 장기 기억으로 나뉘며, 서로 다른 인지적 기법(cognitive techniques)을 적용할 수 있다.
   3. 평가 결과를 메모리 설계에 다시 반영하는 방식도 활용할 수 있다.

2. 구조화 정도의 스펙트럼

   1. 한쪽에는 구조가 약한 파일 시스템 검색이 있다.
   2. 다른 쪽에는 메모리 모델 자체를 학습시키는 완전히 구조화된 접근이 있다.
   3. 이 사이에 다양한 recall·archival·학습·평가 조합이 존재하며, 앞으로 이 분야에서 많은 연구가 나올 것으로 전망된다.

6.2. 로컬 실행의 장점과 대가

1. 통제권과 주권

   1. 로컬 모델에서는 사용 데이터, 전체 compute trace, 평가 절차를 모두 통제할 수 있다.
   2. 어느 단계에서 어떤 기억이 입력됐는지 확인할 수 있어 메모리 능력을 검증하기에 매우 좋은 환경이다.
   3. 이러한 통제 가능성은 발표자가 “주권(sovereignty)”의 사례로 보는 이유다.

2. 현실적인 제약

   1. DeepSeek V4 Flash는 배치 질의(batch querying)를 지원하지 않아 평가를 직렬로만 실행해야 한다.
   2. 그래서 도쿄의 컴퓨터에서 장시간 평가를 계속 돌렸고, 이곳으로 오는 비행기 안에서도 평가를 실행했다.
   3. 시간이 오래 걸리는 대가가 있지만, 파이프라인의 모든 단계를 통제할 수 있다는 점에서 로컬 접근은 여전히 강력하다.

3. 더 큰 생태계

   1. 로컬 주권 역량은 일본의 Sakana AI가 중요하게 보는 더 큰 생태계의 일부다.
   2. 장기 에이전트 메모리 연구는 모델 성능 경쟁만이 아니라 데이터·추론·평가를 누가 통제하는가의 문제이기도 하다.

주요 발언 모음

“메모리는 단순한 데이터베이스 저장소가 아니라, 모델을 둘러싼 제어 루프다.”

“나쁜 메모리는 비싸다. 토큰을 더 쓰게 할 뿐 아니라 에이전트를 잘못된 방향으로 보낼 수 있다.”

“회수 정책을 일급 평가 지표로 생각하기 시작해야 한다.”

“모든 파이프라인의 단계를 통제할 수 있을 때 메모리가 무엇을 할 수 있는지 매우 잘 시험할 수 있다.”

“이것은 주권의 한 사례다.”

핵심 데이터 & 수치

• 11분 53초: 발표 분량이다.
• M3 Ultra / 96GB / 28코어 CPU: 로컬 평가에 사용한 Mac의 사양이다.
• Qwen 27B 4비트 양자화: 첫 번째 평가 모델이다.
• DeepSeek V4 Flash: 두 번째 평가 모델이며 M3 Ultra에서 실행했다.
• 742,000개 유망 물질: 나중에 철회된 Nature 논문이 내세운 과학적 주장이다.
• 124단계와 500단계: X-Bench에서 정답이 기록된 단계와 질문이 제기된 단계의 예시다.
• 68개 질문: X-Bench 평가에 사용한 질문 수다.
• 30개 이상 cookbook: Diamond 오픈소스 저장소에 공유된 실행 가능한 메모리 실험 모음의 규모다.
• 직렬 실행 제약: DeepSeek V4 Flash가 배치 질의를 지원하지 않아 평가를 한 번에 하나씩 실행했다.

핵심 요약 (20줄)

1. 장기 실행 에이전트는 컨텍스트 폭발과 컨텍스트 부패 때문에 자기모순·중복 작업·질문 이탈을 일으킨다.
2. 장기 작업은 늘고 모델 릴리스는 줄어들 전망이어서 기억 관리가 핵심 인프라가 된다.
3. Coinbase 사례는 로컬 모델, 라우팅, 캐싱, 컨텍스트 정리, 사용량 가시화로 비용을 낮추면서 사용량을 늘릴 수 있음을 보여준다.
4. GLM과 DeepSeek V4 Flash 같은 로컬 모델은 에이전트와 도구 사용에 활용 가능한 수준으로 접근하고 있다.
5. 로컬 모델 운용의 주요 병목은 RAM이며 모델 실행과 평가에는 여전히 현실적인 제약이 있다.
6. 실험은 M3 Ultra, 96GB 메모리, 28코어 CPU에서 Qwen 27B와 DeepSeek V4 Flash를 사용했다.
7. 메모리는 데이터베이스가 아니라 쓰기·관리·읽기를 연결하는 모델 주변의 제어 루프다.
8. 기억 없는 연구 에이전트에 trace 코어, recall 블록, archival 블록을 연결해 하네스를 구성했다.
9. 회수 정책은 메모리 없음, 벡터 RAG, 결정 원장, 오라클 순서로 비교했다.
10. 문헌 검토 자료가 컨텍스트에 모두 들어오면 메모리는 성능을 높이지 못하고 비용만 추가했다.
11. 742,000개 유망 물질을 주장했다가 철회된 Nature 논문이 큰 주장과 작은 정정 정보의 대비를 제공했다.
12. 작업과 관련 컨텍스트가 창 밖으로 밀려나는 순간부터 메모리 하네스의 가치가 커졌다.
13. X-Bench에서는 124단계의 정답을 500단계에서 찾아야 하므로 과거 기억 회수가 필수였다.
14. 68개 질문과 여러 셀·시드 평가에서 순위 기반 회수가 가장 좋은 성능을 보였다.
15. 단순히 메모리 사용 여부를 판정하는 게이팅보다 rank-only 결정 원장이 우수했다.
16. 오라클은 올바른 기억을 제공하지만 모델이 이를 사용하도록 강제하지 않으므로 최고 성능에 도달하지 못했다.
17. 임의·오류·최신 단계 입력을 비교한 절제 실험에서도 순위 기반 정책이 가장 강했다.
18. 같은 경향이 Qwen 27B, DeepSeek V4 Flash, X-Bench, Spider V2에서 반복됐다.
19. 잘못된 메모리는 토큰과 재작업 비용을 늘리므로 회수 정책을 일급 지표로 평가해야 한다.
20. 로컬 실행은 속도와 배치 처리의 대가를 요구하지만 데이터·trace·평가 전체를 통제하는 주권을 제공한다.

결론 및 시사점

1. 작업 적합성부터 판단한다: 컨텍스트에 모든 자료가 들어오는 작업에는 메모리 하네스를 추가하지 않는 편이 비용 면에서 낫다.
2. 회수 정책을 별도 시스템으로 설계한다: 무엇을 저장할지보다 무엇을 언제 어떤 순위로 모델에 보여줄지가 장기 에이전트 성능을 결정한다.
3. 결정과 trace를 구조화한다: 단순 유사도 검색을 넘어 턴별 결정 원장을 축적하고 우선순위를 매기는 접근을 우선 검증한다.
4. 오라클을 성능 상한이 아닌 진단 도구로 쓴다: 올바른 기억을 넣고도 모델이 무시하거나 오해하는지 확인하면 회수 문제와 추론 문제를 분리할 수 있다.
5. 나쁜 기억의 비용을 측정한다: 정확도뿐 아니라 추가 토큰, 잘못된 경로, 재작업, 세션 간 유지율을 함께 측정해야 한다.
6. 여러 모델·벤치마크·세션에서 반복한다: 특정 모델의 우연한 결과를 피하려면 Qwen·DeepSeek와 X-Bench·Spider V2처럼 서로 다른 조건에서 검증한다.
7. 로컬 주권을 실험 전략으로 활용한다: 실행이 느리고 직렬이어도 데이터와 전체 파이프라인을 통제하면 메모리 설계의 인과 효과를 더 명확히 관찰할 수 있다.