VideoLoop가 긴 영상 에이전트의 기억 비대화를 되쓰기로 막는다

무엇인가

긴 영상 이해는 수천 프레임, 수십 분에서 수 시간에 걸친 영상에서 질문에 관련된 증거를 반복적으로 수집해야 하는 작업이다. 관련 증거는 드물게 흩어져 있고 영상에는 자연적 중복이 많아서, 최근 연구들은 적응적 시간 검색이나 단계적 추론 같은 에이전트 방식을 쓴다. 문제는 대부분의 에이전트 시스템이 단일 추론 루프에 '덧붙이기만 하는(append-only)' 작업기억을 쓴다는 점이다. 관측이 쌓여 LVLM의 유효 컨텍스트 한계를 넘어서면 질의의 핵심 증거에 대한 어텐션이 희석되고, 에이전트는 이미 찾아낸 것에 대한 접근을 잃는다. 저자들은 이를 운영체제의 스래싱에 빗대어 semantic thrashing이라고 부른다. 스래싱에 빠진 OS가 실제 작업 대신 페이지 교체에 사이클을 낭비하듯, 에이전트는 계산을 늘리면서 근거는 잃는다.

어떻게 동작하나

논문은 이것이 튜닝 문제가 아니라 append-only 갱신의 구조적 성질이라고 논증한다. 질의 q에 대한 원자적 증거의 우주를 U_q, 답에 필요한 핵심 증거 집합을 K_q, t시점 작업기억을 M_t라 두고, 상태 발산을 대칭차의 크기 Dist(M_t, K_q) = |M_t △ K_q|로 정의한다. 여기서 M_t = M_{t-1} ∪ {o_t}로 갱신하면 발산 변화는 -|{o_t} ∩ (K_q \ M_{t-1})| + |{o_t} \ (K_q ∪ M_{t-1})|가 된다. 즉 append-only는 새로 관측한 목표 증거를 더할 수는 있어도, 한 번 들어온 무관한 증거를 제거하지 못하고 순서 있는 관측 로그의 성장도 막지 못한다. 노이즈가 컨텍스트 예산을 잠식해 핵심 증거를 가리는 경로가 구조적으로 열려 있다는 것이다.

무엇과 다른가

해법은 VideoLoop라는 이중 루프 구조다. 바깥 루프는 멀티모달 정책 모델 π가 Analyze, Transcribe, Execute, Answer 네 가지 도구로 영상을 탐색하고, 관측과 중간 분석 산출물을 샌드박스 파일시스템에 기록한다. 안쪽 루프는 별도의 LLM인 메모리 오케스트레이터 π_m이 매 스텝 뒤에 파일시스템에서 질의 관련 산출물을 read_file로 검색해, 작업기억을 Update·Append·Delete 편집으로 다시 쓴다. 작업기억은 메타데이터, 서사 이해, 타임스탬프 증거, 시간적 커버리지, 활동 로그, 미해결 조사 대상이라는 여섯 섹션 문서이며 32K 토큰 예산으로 묶인다. 기억은 세 계층으로 나뉜다. 1계층은 바깥 루프가 보는 유계 작업기억, 2계층은 이전 행동들을 압축한 스텝 매니페스트, 3계층은 추출 프레임과 스크립트를 손실 없이 보관하는 무한 파일시스템이다. 바깥 루프의 컨텍스트는 C_t = {q, M_t, Ω_t}로, Ω_t는 최근 k=8개 생각-행동-관측 삼중항의 슬라이딩 윈도다. 두 구성 요소 모두 크기가 제한되므로 전체 컨텍스트는 반복 횟수와 무관하게 상수로 유지된다. 재작성이 이득이 되는 조건도 유도한다. 제거한 비목표 내용 ρ_t, 가져온 누락 목표 증거 σ_t, 실수로 지운 목표 증거 μ_t, 새로 들어온 비목표 내용 ν_t에 대해 발산 변화는 -ρ_t - σ_t + μ_t + ν_t이며, ρ_t + σ_t ≥ μ_t + ν_t일 때만 발산이 줄어든다.

어떻게 쓰나

실험은 세 벤치마크에서 이뤄졌다. VideoMME(long)은 30~60분 영상에 대한 900개 객관식 문제, VideoMMMU는 교육 영상 300개에서 뽑은 900문항(Perception·Comprehension·Adaptation 각 300문항), LongVideoBench(long)은 900~3600초 영상 188개에서 나온 564문항이다. Gemini 3.1 Pro를 정책 모델로 쓴 VideoLoop는 VideoMME(long) 88.3%, VideoMMMU 88.8%, LongVideoBench(long) 80.9%를 기록했다. 같은 네이티브 모델 대비 각각 +4.5, +4.2, +3.2포인트이고, 가장 강한 기존 에이전트 방식 대비로는 +7.1, +10.4, +4.5포인트다. 정책 모델을 바꿔도 재학습 없이 일관되게 개선되어 Gemini 3.1 Pro +4.5, Gemini 3 Flash +5.1, Kimi K2.5 +3.5, MiMo-V2-Omni +3.7포인트를 얻었다.

전제와 한계

구성 요소별 절제 실험도 수치로 제시된다. 네이티브 추론 80.7%에서 append-only 에이전트는 81.9%(+1.2), 이중 루프 재작성은 83.3%(append-only 대비 +1.4), 여기에 파일시스템 접근을 더하면 85.8%(이중 루프 대비 +2.4)가 된다. 전체 VideoLoop는 append-only보다 +3.9포인트, 네이티브보다 +5.1포인트 높고, 가장 어려운 분기(Q4)에서 +9.3포인트가 나온다. 기억 품질은 영상·도구 접근 없이 컨텍스트 스냅샷만 읽는 블라인드 심사자로 측정했는데, append-only는 가장 쉬운 Q1에서 86.7%였다가 가장 어려운 Q4에서 60.9%로 떨어지는 반면 VideoLoop는 94.7%에서 81.1%로만 떨어진다. 토큰 효율에서는 Gemini 3 Flash 기준 append-only가 질문당 614.9K 토큰으로 81.9%, 이중 루프만 쓰면 647.0K로 83.3%(+5.2% 오버헤드), 파일시스템까지 포함한 전체 설계는 618.2K로 85.8%(+0.5% 오버헤드)를 낸다. 출력 토큰은 늘지만 입력 토큰이 584.6K에서 559.0K로 줄어, 전체 이력을 매번 컨텍스트에 싣는 대신 파일시스템으로 외부화해 선택적으로 재사용한다는 해석이 가능하다. 행동 분석에서도 VideoLoop는 프레임 열람 분포가 저비용 구간에 몰리고 반복 횟수가 적으며, 영상 타임라인 전반에 더 고르게 퍼진다.

개발자 관점에서 이 논문의 핵심은 '기억은 쌓는 것이 아니라 큐레이션하는 것'이라는 원칙을 구현 패턴으로 제시한다는 점이다. 긴 컨텍스트 에이전트를 만들 때 원본 관측은 손실 없이 외부 저장소에 두고, 모델이 보는 작업기억은 고정 예산 안에서 매 스텝 삭제·갱신 가능한 문서로 유지하는 구조는 영상에 국한되지 않는다. 다만 도입 전에 확인할 것은 재작성 품질 조건이다. 오케스트레이터가 노이즈를 지우면서 목표 증거를 실수로 삭제하면 발산은 오히려 커지므로, 삭제·갱신 연산의 정확도와 예산 설정을 자체 워크로드에서 검증해야 한다.

저자들이 명시한 전제와 한계도 분명하다. OS 스래싱과의 유비는 정리(theorem) 수준의 환원이 아니라 개념적 진단 도구이며, 발산 감소 조건 ρ_t + σ_t ≥ μ_t + ν_t는 재작성 품질에 대한 조건일 뿐 무조건적 보장이 아니다. 즉 이 구조가 항상 개선을 보장하지는 않고, 오케스트레이터가 잘못된 편집을 하면 손해가 날 수 있다. 또한 실험은 Gemini 3.1 Pro·Flash, Kimi K2.5, MiMo-V2-Omni 네 백본에 한정되어 있고, VideoMMMU는 자막이 없어 Whisper-large로 별도 전사했으며, 최대 50회 반복·최소 6회, 작업기억 32K 토큰, 키프레임 최대 6장 같은 하이퍼파라미터에 결과가 의존한다.