🤖 AI

Context as an Environment: Programmatic Context Management for Long-Horizon Agents

이 논문은 에이전트 세션을 추가 전용(append-only) 이벤트 로그와 지속적인 파이썬 커널을 갖춘 실행 가능한 환경으로 취급하여, LLM이 코드를 통해 장기적 상태를 동적으로 관리할 수 있게 함으로써 롱 컨텍스트 벤치마크에서 최첨단 성능을 달축하는 프로그래밍 방식의 컨텍스트 관리 시스템인 Scroll을 소개한다.

원저자: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

게시일 2026-08-25

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

끝나지 않는 대화를 상상해 보십시오. 당신은 코드를 작성하거나, 복잡한 여행을 계획하거나, 깊이 있는 주제를 연구하는 데 도움을 줄 수 있는 매우 똑똑한 컴퓨터 프로그램과 대화하고 있습니다. 처음에는 대화가 쉽습니다. 프로그램은 지난 몇 분 동안 당신이 말한 모든 것을 기억합니다. 하지만 대화가 몇 시간 또는 며칠 동안 길어짐에 따라, 정보의 양은 점점 늘어납니다. 결국, 프로그램이 즉각적인 메모리에 담기에는 너무 많은 양이 됩니다. 인공지능의 세계에서 이 즉각적인 메모리를 '컨텍스트 윈도우(context window)'라고 부릅니다. 이것은 특정 수의 종이를 담을 수 있는 책상처럼 크기가 정해져 있습니다. 종이 더미가 너무 높아지면, 프로그램은 새로운 종이를 위한 공간을 만들기 위해 일부를 버려야 합니다.

문제는 프로그램이 언제 무엇이 중요한지 너무 늦기 전까지는 알지 못한다는 점입니다. 만약 당신이 3일 전에 언급했던 것에 대해 질문한다면, 프로그램은 이미 그 종이를 버렸을 수도 있습니다. 전통적인 해결책들은 과거의 종이들을 짧은 노트로 요약하거나, 몇 가지 사실을 골라 별도의 공책에 보관하는 방식으로 이 문제를 해결하려 합니다. 하지만 이러한 방법들은 위험합니다. 만약 프로그램이 날짜나 숫자와 같은 구체적인 세부 사항을 버린다면, 그 세부 사항은 영원히 사라집니다. 그것은 복구될 수 없습니다. 긴 역사를 되돌아보며 정확한 사실을 찾아내거나 상황이 어떻게 변했는지 추적해야 하는 작업의 경우, 단 하나의 세부 사항을 잃는 것만으로도 프로그램은 실패할 수 있습니다.

한 연구팀이 이 늘어나는 대화를 처리하는 다른 방법을 제안했습니다. 그들은 이 시스템을 '스크롤(Scroll)'이라고 부릅니다. 대화 전체를 프로그램의 즉각적인 메모리에 넣으려고 노력하는 대신, 그들은 역사를 프로그램이 필요할 때마다 방문할 수 있는 별도의 영구적인 환경으로 취급합니다. 이것은 프로그램의 책상 바로 밖에 놓여 있는 거대하고 체계적인 기록 보관소와 같습니다. 프로그램은 보관소 전체를 한꺼번에 읽지 않습니다. 대신, 보관소로 가서 필요한 특정 페이지를 찾아 그 페이지만을 책상으로 가져오라는 검색 쿼리나 명령 같은 작은 지시문을 작성합니다.

이 시스템의 핵심은 모든 상호작용의 영구적인 기록인 '이벤트 로그(Event Log)'입니다. 이 로그는 모든 메시지, 도구의 결과, 그리고 결정을 정확한 세부 사항과 함께 포착하는, 멈추지 않는 테이프 녹음기와 같습니다. 이것은 프로그램의 즉각적인 메모리 외부에 안전하게 저장되므로 아무것도 유실되지 않습니다. 이 로그와 함께, 프로그램이 현재의 생각이나 계산을 유지할 수 있는 일종의 디지털 샌드박스인 '지속적인 작업 공간(persistent workspace)'이 존재합니다. 프로그램이 과거의 무언가를 기억해야 할 때, 요약본에 의존하는 대신, 이벤트 로그를 검색하여 자신이 찾고 있는 정확한 순간을 찾아내고 그 정보를 자신의 작업 공간으로 불러오는 코드를 작성합니다.

이 접근 방식은 프로그램이 자신의 메모리를 생각하는 방식을 바꿉니다. 무엇을 남길지 추측하는 대신, 프로그램은 필요한 순간에 무엇을 찾아볼지 결정합니다. 만약 프로그램이 여행을 계획하다가 몇 주 전에 사용자가 언급한 선호도를 기억해야 한다면, 특정 선호도를 찾기 위한 명령어를 작성합니다. 그런 다음 사용자가 사용했던 정확한 단어들을 불러와 결정을 내리는 데 사용합니다. 프로그램은 오직 필요한 정보만을 자신의 즉각적인 시야로 가져옵니다. 나머지 대화 기록은 보관소에 안전하게 저장되어 나중에 필요할 때 호출되기를 기다립니다.

즉각적인 시야가 너무 가득 차지 않도록, 시스템은 현재 사용되지 않는 오래된 정보를 정리하는 방법을 가지고 있습니다. 작업 공간이 혼잡해지면, 시스템은 대화의 가장 오래된 부분들을 다시 보관소로 이동시킵니다. 하지만 다른 시스템들이 이 오래된 부분들을 삭제하거나 요약하는 것과 달리, 스크롤은 그것들을 있는 그대로 유지합니다. 시스템은 프로그램에게 보관소의 해당 부분이 정확히 어디에 저장되어 있는지 알려주는 작은 지도인 '인덱스(index)'를 생성합니다. 만약 프로그램이 나중에 오래된 대화를 확인해야 할 필요성을 느끼면, 이 지도를 사용하여 해당 지점으로 직접 뛰어들어 원문 텍스트를 가져올 수 있습니다. 이는 프로그램이 정보가 더 이상 즉각적인 시야에 없더라도 항상 원천 데이터로 돌아갈 수 있음을 보장합니다.

연구진은 인공지능이 긴 대화를 얼마나 잘 처리할 수 있는지 확인하기 위해 설계된 몇 가지 어려운 과제들로 이 시스템을 테스트했습니다. 한 테스트에서 시스템은 100만 단어가 넘는 대화 기록을 바탕으로 질문에 답해야 했습니다. 또 다른 테스트에서는 도구를 사용하여 정보를 수집하고 문제를 해결하며 장기간 결정을 내리는 에이전트로서 역할을 수행해야 했습니다. 결과는 이 새로운 방법이 매우 효과적임을 보여주었습니다. 긴 역사를 기억하고 추론하는 능력을 측정하는 테스트에서 시스템은 94.8%의 점수를 기록했습니다. 1,000만 단어의 역사가 포함된 또 다른 테스트에서는 73.1%를 기록했는데, 이는 이전에 발표된 그 어떤 시스템보다 높은 수치였습니다. 시스템이 복잡한 과제를 해결하면서 확장되는 환경을 관리해야 하는 테스트에서는 86.7%에 도달하여, 이전의 최고 결과들을 크게 앞질렀습니다.

이 시스템의 성공은 메모리를 프로그래밍 작업으로 취급하는 능력에서 비롯됩니다. 프로그램이 정보를 찾고 사용하는 자신만의 지시문을 작성할 수 있게 함으로써, 시스템은 프로그램의 발전하는 코드 작성 능력을 활용합니다. 이는 프로그램이 중요한 세부 사항을 잃을 수 있는 요약본으로 역사를 압축하도록 강요하지 않습니다. 대신, 프로그램이 필요할 때마다 전체의 편집되지 않은 역사에 접근할 수 있는 도구를 제공합니다. 연구진은 이 방법이 다양한 유형의 강력한 프로그램에서 잘 작동한다는 것을 발견했으며, 이는 코드를 통해 장기 기억을 관리하는 능력이 여러 시스템이 학습할 수 있는 일반적인 기술임을 시사합니다.

이 연구는 우리가 지능형 에이전트를 구축하는 방식의 변화를 시사합니다. 프로그램의 즉각적인 메모리를 더 크게 만들거나 요약 능력을 개선하려 하기보다, 우리는 그것에게 자신의 삶에 대한 영구적이고 검색 가능한 기록에 대한 접근 권한을 줄 수 있습니다. 프로그램은 이 기록을 탐색하며, 무엇을 앞으로 가져오고 무엇을 뒤에 남겨둘지 결정하는 법을 배웁니다. 이는 즉각적인 시야를 맑고 집중되게 유지하는 동시에, 과거의 온전한 진실이 항상 사용 가능하도록 보장합니다. 연구진은 이 접근 방식이 인공지능이 미래에 훨씬 더 길고 복잡한 과제를 처리하는 데 도움이 될 수 있으며, 중요한 세부 사항을 잃지 않고 훨씬 더 깊은 역사로부터 학습할 수 있게 해줄 것이라고 믿고 있습니다.

기술 요약: Scroll – 장기적 관점의 에이전트를 위한 프로그래밍 방식의 컨텍스트 관리

1. 문제 정의

저장소 수준의 소프트웨어 엔지니어링이나 심층 웹 조사와 같은 대규모 언어 모델(LLM) 에이전트의 장기적 과업(long-horizon tasks)은 단일 모델의 컨텍스트 창을 훨씬 초과하는 상호작용 이력을 생성합니다. 기존의 솔루션들은 주로 컨텍스트 압축(절단, 요약 또는 오래된 구간 폐기)이나 외부 메모리(별도의 저장소로 사실을 추출)에 의존합니다. 두 접근 방식 모두 근본적으로 **손실적(lossy)**입니다. 즉, 미래에 무엇이 필요할지 알기 전에 어떤 정보를 보존할지를 미리 결정해 버립니다. 결과적으로, 요약 과정에서 특정 세부 사항을 놓치거나 추출 과정에서 뉘앙스를 놓치게 되면, 해당 정보가 디스크에 원본 로그로 존재하더라도 복구가 불가능해집니다. 이러한 한계는 에이전트가 과거의 사건에 대해 정밀한 역사적 비교를 수행하거나 비사소한 계산을 수행하는 것을 방해하며, 특히 필요한 정보가 사전에 알려지지 않은 경우 더욱 그렇습니다.

2. 방법론: Scroll 프레임워크

본 논문은 세션 이력을 프롬프트로 직렬화할 텍스트가 아니라, 에이전트가 자신의 이력과 프로그래밍 방식으로 상호작용할 수 있는 **실행 가능한 세션 환경(executable Session Environment)**으로 재정의하는 컨텍스트 관리자, Scroll을 소개합니다.

핵심 구성 요소

추가 전용 이벤트 로그 ( $L_t$ ): 모든 상호작용(사용자 메시지, 모델 응답, 도구 호출, 결과)을 기록하는 내구성이 있는 그라운드 트루스(ground-truth) 기록입니다. 모든 이벤트에는 고유하고 단조 증가하는 시퀀스 주소(seq)가 할당됩니다. 로그는 SQLite에 저장되며, 임베딩 대신 결정론적인 전체 텍스트 검색을 위해 BM25를 활용합니다.
내구성 있는 저장소 ( $P_t$ ): 원시 페이로드(예: 전체 도구 출력, 아티팩트)는 외부(JSON, 파일 시스템)에 저장되며, 지연된 핸들(deferred handles)을 통해 이벤트 로그에 의해 참조됩니다. 이를 통해 로그는 경량성을 유지하면서도 완전한 충실도를 보존합니다.
지속적인 Python 커널 ( $V_t$ ): 샌드박스화된 Python 커널은 모델 호출 간에도 지속됩니다. 이 커널은 상주 변수(Python 객체, DataFrame, 지연된 핸들)의 타입화된 네임스페이스를 유지합니다. 결정적으로, 중간 계산 및 도구 결과는 이 커널 내에 머물며, 명시적으로 요청되지 않는 한 프롬프트로 직렬화되지 않습니다.

프로그래밍 인터페이스

모델은 지속적인 커널 내에서 실행될 코드를 작성함으로써 자신의 컨텍스트를 구축합니다. ms라는 기능 객체를 통해 노출되는 인터페이스는 컨텍스트 구축을 네 가지 연산으로 구분합니다:

LOCATE: ms.search(query, k, ...)는 전체 텍스트 검색과 구조화된 필터를 통해 후보 이벤트 로그 레코드를 찾아 안정적인 seq 주소를 반환합니다.
MATERIALIZE: ms.expand(seq)는 정확한 턴(turn)이나 구간을 복구하고 외부화된 페이로드를 Python 객체로 로드합니다.
COMPUTE: 모델은 상주 변수에 대해 표준 Python 및 허용된 데이터베이스 인터페이스를 사용하여 필터링, 조인, 집계 및 유도를 수행합니다.
EXPOSE: print(value)는 모델의 작업 뷰(working view)로 넘어가는 유일한 메커니즘입니다. 명시적으로 출력된 투영(projection)만이 다음 모델 컨텍스트에 진입합니다.

제거(Eviction) 및 탐색

작업 뷰가 토큰 예산에 도달하면, Scroll은 이벤트 로그에서는 삭제하지 않되 *뷰(view)*에서 오래된 구간을 제거하는 제거 절차를 수행합니다.

복구 가능성: 제거된 이벤트는 이벤트 로그에 그대로 남아 있습니다.
제거 인덱스: 전체 로그 검색의 필요성을 방지하기 위해, Scroll은 제거된 구간에 대한 "헤드라인"(태스크, 상태, 다음 행동)의 계층적 인덱스를 유지합니다. 이 인덱스를 통해 에이전트는 주소 앵커를 사용하여 제거된 영역으로 직접 탐색할 수 있으며, $O(k \log k n)$ 복잡도를 유지하기 위해 오래된 항목들을 더 거친 범위로 롤업합니다.

3. 주요 기여

본 논문은 세 가지 주요 기여를 합니다:

지연 선택 정책 (Deferred Selection Policy): 미래의 요구사항을 알기 전에 컨텍스트 맵을 고정하는 기존 방식과 달리, Scroll은 컨텍팅 구축을 쿼리 시점으로 지연시킵니다. 모델은 무엇을 회상, 계산 및 노출할지 결정하기 위해 각 단계에서 프로그램 $\pi_t$ 를 작성합니다.
실행 가능한 컨텍스트 기질 (Executable Context Substrate): 지속적인 샌드박스형 Python 커널과 추가 전용 이벤트 로그의 구현입니다. 이는 컨텍스트 관짐을 텍스트 처리에서 프로그래밍으로 전환하며, 검색, 변환 및 상태를 관리하기 위해 모델의 코딩 능력을 활용합니다.
손실 없는 탐색 알고리즘 (Lossless Navigation Algorithm): 작업 뷰를 제한하면서도 이력을 잃지 않는 제거 메커니즘입니다. 제거된 구간은 온전히 유지되며 압축된 주소 앵커에 의해 인덱싱되어, 에이전트가 전체 로그를 검색하는 대신 제거된 영역으로 직접 탐색할 수 있도록 합니다.

4. 실험 결과

저자들은 Qwen3.8-Max를 백본으로 사용하여 세 가지 벤치마크에서 Scroll을 평가했습니다:

LongMemEvalS (장기 기억 검색): Scroll은 **94.8%**의 정확도를 달성하여 최첨단 시스템들과 경쟁력 있는 성능을 보였습니다.
BEAM10M (10M 토큰 이력): Scroll은 **73.1%**를 달성하여 기존에 발표된 가장 우수한 메모리 시스템보다 5.1포인트 앞섰습니다. 특히 지식 업데이트(92.5%) 및 모순 해결(88.1%)과 같이 정확한 역사적 증거가 필요한 카테고리에서 탁월한 성과를 보였는데, 이는 손실적인 요약 방식이 실패하는 지점입니다.
LOCA256K (장기적 관점의 행동): Scroll은 **86.7%**의 정확도를 달성했습니다. 동일한 백본을 사용하는 다른 컨텍스트 관리 전략들과 직접 비교했을 때, Scroll은 컨텍스트가 커짐에 따라 우수한 안정성을 보여주었습니다. 128K에서 256K 토큰으로 증가할 때 요약 및 검색 에이전트가 약 21%의 하락을 보인 것에 비해, Scroll은 단 **2.6%**의 하락만을 기록했습니다.

**절제 연구(Ablation Studies)**를 통해 손실 없는 이벤트 로그가 필수적임을 확인했습니다(이를 제거했을 때 BEAM10M에서 약 20%로 성능이 급락함). 또한 지속적인 커널은 인커널(in-kernel) 집계를 가능하게 함으로써 성능을 7.3포인트 향상시켰으며, 제거 인덱스는 흩어진 이력에서의 탐색을 도와 1.8포인트의 이득을 제공했습니다.

비용 효율성: Scroll은 코퍼스의 아주 작은 부분만을 모델에 노출합니다. BEAM10M에서 중앙값 입력 토큰 수는 약 105K(코퍼스의 약 1%)였으며, 출력 토큰은 이보다 한 자릿수 더 작았습니다.

5. 의의 및 주장

본 논문은 Scroll이 컨텍스트 관리를 압축 문제에서 프로그래밍 과업으로 근본적으로 변화시킨다고 주장합니다. 세션을 실행 가능한 환경으로 취급함으로써, 에이전트는 자신의 컨텍스트를 동적으로 관리하기 위해 발전하는 LLM의 코딩 능력을 물려받게 됩니다.

저자들은 Scroll이 무엇을 유지할지 또는 어떻게 검색 코드를 작성할지를 규정하지 않는다는 점을 강조합니다. 이러한 결정은 모델에게 맡겨집니다. 이러한 유연성은 시스템이 모델의 역량과 함께 확장될 수 있게 합니다. 본 논문은 성공적인 궤적(trajectory)이 하위 모델로 지도 학습 기반 미세 조정(SFT)을 통해 증류될 수 있으며, 이때 밑단의 컨텍스트 메커니즘은 고정된 상태로 유지될 수 있음을 시사합니다.

이 연구는 정확한 역사적 증거가 필요하거나 과거 사건에 대한 복잡한 계산이 필요한 장기적 과업의 경우, 프로그래밍 방식의 접근을 통한 손실 없는 검색이 사전 계산된 요약이나 고정된 메모리 저장보다 우월하다고 단언합니다. 이는 현재의 압축 패러다임에 내재된 정보의 돌이킬 수 없는 손실을 피할 수 있기 때문입니다.