긴 문맥 없이도 장기 작업과 대용량 입력을 처리할 수 있다

무엇인가

이 논문은 긴 문맥이 정말 필요한지를 정면으로 묻는다. 저자들은 문맥 깊이가 커질수록 토큰 생성 비용과 지연, 메모리 사용량이 증가하며, 프런티어 오픈 웨이트 모델에서는 뒤쪽 토큰 생성 비용이 앞쪽보다 최대 7배까지 벌어질 수 있다고 지적한다. 클라우드 GPU에서는 컨텍스트를 짧게 유지할 때 3.6배에서 7배 수준의 비용 절감이 가능하고, 로컬 추론에서도 입력 문맥이 길어지면 토큰 간 지연이 대략 두 배로 늘어나는 모델들이 제시된다. 그래서 저자들은 긴 문맥이 필요한 이유를 장기 작업과 대용량 입력 작업으로 나누고, 장기 작업을 긴 문맥 없이 수행할 수 있는지, 대용량 입력 작업을 긴 문맥 없이 수행할 수 있는지, 그리고 문맥마다 행동을 하나만 취해도 장기 작업이 가능한지를 연구 질문으로 분해한다.

어떻게 동작하나

방법의 핵심은 세 가지 문맥 관리 방식이다. 먼저 전체 이력 누적(FHA)은 모든 행동과 관찰을 하나의 대화에 계속 붙이는 기준선이다. 끝에서 압축하기(EoCC)는 대화가 미리 정한 임계값을 넘으면 모델에게 현재 작업에 필요한 상태를 제한된 길이로 압축하게 하고, 원래 과제와 압축된 상태만 담은 새 대화를 시작한다. 이때 총 문맥 한도와 압축 임계값을 함께 낮추면서 압축 빈도를 높인다. 단일 행동 압축(SAC)은 더 극단적이다. 각 대화에 과제와 현재 의미 상태만 넣고 환경 행동을 정확히 한 번 수행한 뒤, 결과를 상태에 반영하고 대화를 버린다. 대용량 입력 작업에서는 입력 전체를 대화에 넣지 않고 input01.txt 같은 파일로 저장한 뒤, 에이전트가 sed, awk, head 같은 Bash 도구로 필요한 부분만 읽게 한다. 이렇게 하면 긴 입력 작업이 사실상 긴 호흡의 도구 사용 작업으로 바뀐다. 저자들은 이 관찰을 바탕으로, 대화 상태를 자연어 설명으로 유지하면서 다음 행동을 추론하고 결과를 상태에 갱신하는 SSSM(의미 상태 공간 모델) 개념도 제안한다.

무엇과 다른가

실험은 장기 작업 벤치마크 6개와 대용량 입력 벤치마크 7개로 구성된다. 장기 작업 쪽은 SWE-bench Verified 500개, SWE-bench Multilingual 300개, Terminal-Bench 2.1 89개, FRAMES 824개, tau2-bench 184개 황금 세트, BFCLv3 200개 장문맥 에피소드를 사용했다. 대용량 입력 쪽은 LongBench v2 503개, LOONG 1,600개, AA-LCR 100개, NIAH 125개 그리드(16K에서 약 500K 토큰), RULER 13개 과제(256K와 500K), Counting-Stars 192개, BABILong 550개(64K에서 1M 토큰)를 쓴다. 주요 정확도 실험은 Claude Opus 4.5와 GPT 5.6 Sol로 수행했고, 클라우드 처리량과 로컬 추론 실험에는 GLM 5.2, Kimi K2.6, Qwen 3 Coder Next, Qwen 3.6 27B, Gemma 4 31B, Step 3.7 Flash, MiniMax M2.7 같은 오픈 웨이트 모델이 동원됐다.

어떻게 쓰나

장기 작업에서 EoCC는 전체 이력 기준선과 비교해 큰 손실 없이 문맥을 줄였다. SWE-bench Verified, TerminalBench 2.1, SWE-bench Multilingual, FRAMES는 총 문맥 한도와 압축 임계값을 48K/36K, 32K/24K, 24K/18K, 16K/12K로 낮추며 시험했고, BFCLv3는 24K/18K, 16K/12K, 12K/8K, tau2-bench는 16K/12K, 12K/8K, 8K/6K로 시험했다. 전체 벤치마크와 임계값에서 Opus 4.5의 상대 성능은 -3.7에서 +5.6퍼센트포인트, GPT 5.6 Sol은 -3.3에서 +4.4퍼센트포인트 범위였다. 두 모델 모두 22개 임계값 구성 가운데 기준선보다 2퍼센트포인트 넘게 잃은 경우가 5개 이하였다. 비용 절감 배수는 Opus 4.5가 2.2배에서 8.8배, GPT 5.6 Sol이 2.4배에서 5.0배로 추정됐다. 압축 때문에 작업을 다시 하면서 총 토큰 소비가 늘어나는 문제는 일반적으로 나타나지 않았다고 저자들은 밝힌다.

전제와 한계

대용량 입력 작업에서는 선택적 읽기와 압축을 결합한 방식이 거의 모든 경우 전체 입력 기준선과 대등하거나 더 나은 성능을 냈다. Opus 4.5의 상대 성능 범위는 -0.4에서 +40.0퍼센트포인트, GPT 5.6 Sol은 +1.0에서 +30.9퍼센트포인트로 보고됐다. 비용 절감 추정은 Opus 4.5가 6.5배에서 54.6배, GPT 5.6 Sol이 4.4배에서 233.3배에 이른다. 문서 길이가 수십 배로 늘어나도 대화 길이는 대체로 비슷한 대역에 머물렀고, 압축이 실제로 발생한 중앙값은 거의 0에 가까웠다. 즉 입력 문서가 크다는 사실만으로 그 전체를 문맥에 넣어야 하는 것은 아니라는 것이 이 실험의 요지다.

SAC 실험은 더 강한 주장을 뒷받침한다. Claude Opus 4.5는 SAC를 적용해도 SWE-bench Verified에서 mini-swe-agent 기준선 정확도를 유지했고 Terminal-Bench에서는 4.6퍼센트포인트 개선됐다. GPT 5.6 Sol은 SWE-bench Verified 82.4퍼센트, Terminal-Bench 84.3퍼센트(89개 중 75개)로 기준선보다 각각 2.0, 3.3퍼센트포인트 낮았다. 그럼에도 두 모델과 두 벤치마크에서 SAC의 중앙 피크 활성 문맥은 7K에서 9K 토큰에 불과했고, 최대치는 130K에서 200K 토큰에서 15K에서 37K 토큰으로 줄었다. 저자들은 이 결과를 바탕으로 모든 장기 문맥 워크플로를 단일 행동 압축 형태로 바꿀 수 있는지 묻고, 자연어 의미 상태를 유지하는 SSSM을 향후 모델 설계 방향으로 제시한다.

개발자 관점에서 이 논문은 에이전트 하네스에서 전체 대화 이력을 무조건 유지하는 설계를 재검토하게 한다. 대화가 길어질 때 주기적으로 상태를 압축하고, 원본 입력이나 전체 로그는 파일로 보관해 필요할 때 선택적으로 읽게 하며, 행동 사이에는 압축된 의미 상태만 넘기는 방식으로 비용과 지연을 크게 줄일 수 있다는 것이다. 특히 코딩 에이전트처럼 저장소 탐색, 수정, 검증이 길게 이어지는 작업에서는 문맥 길이 자체보다 상태 유지와 선택적 접근이 중요하다는 시사점을 준다. 다만 이때 정확도뿐 아니라 총 토큰 소비, 압축 횟수, 재작업 여부, 피크 문맥 길이를 함께 측정해야 한다.

저자들이 밝힌 한계도 분명하다. 압축은 손실성 압축이므로, 동전 던지기 결과를 모두 기록해야 하는 작업처럼 정확한 이력이 필요한 과제는 압축 때문에 반드시 실패할 수 있다. 다만 이런 경우에도 모든 메시지를 보관하고 선택적 읽기 도구로 조회하게 하면 문제를 대용량 입력 작업으로 바꿀 수 있다고 본다. 논문의 증거는 긴 문맥이 유리한 과제의 존재를 배제하지 않고, 모든 가능한 과제가 짧은 문맥으로 해결된다고 증명하지도 않는다. 대신 긴 입력과 긴 대화 이력에서 나오는 기존의 긴 문맥 필요성 주장이 충분하지 않으며, SSSM 같은 후속 학습 조정이 뒷받침되면 모델의 문맥 창 크기를 크게 줄일 수 있다고 주장한다.