[arXiv 2608.01964] LongHorizon-Harness: 감사된 상태로 장기 에이전트 작업을 이어가기

LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks

https://arxiv.org/abs/2608.01964

Ziyu Ma, Hailang Huang, Shun Zou, Yifan Zheng, Zichao Wang, Zheyuan Li, Yanzhe Zhang, Peihao Wang, Xingang Pan, Xiangxiang Chu | DreamX Team, Alibaba Group | arXiv:2608.01964 | 2026년 8월

---

1. 서론: 장기 작업에서 무너지는 것은 문맥보다 상태다

1.1 길어진 실행 궤적이 곧 신뢰성은 아니다

대규모 언어 모델 에이전트는 이제 대화에 답하는 수준을 넘어 소프트웨어 공학, 범용 업무 보조, 과학적 발견, 데스크톱 조작처럼 실제 환경을 바꾸는 작업을 맡는다. 이때 장기 작업은 단순히 호출 횟수가 많은 문제라기보다 서로 의존하는 판단과 도구 사용과 관찰과 수정을 여러 차례 이어 가야 하는 문제다. 한 단계에서 만든 파일이나 설정이 뒤 단계의 전제가 되고, 중간에 발견한 사실이 이후의 선택을 제한하므로, 국소적으로 그럴듯한 행동을 연속해서 생성하는 능력만으로는 충분하지 않다. 저자들은 그래서 에이전트가 얼마나 긴 문맥을 읽을 수 있는가보다 얼마나 오래 정확한 진행 상태를 보존하며 다음 행동에 반영하는가를 중심 문제로 옮긴다.

논문이 인용한 장기 작업 추세에 따르면 첨단 에이전트의 과제 완료 지평은 대략 일곱 달마다 두 배로 늘었고, 최근 모델에서는 그 주기가 약 네 달로 빨라졌다. 그러나 이 수치는 실행이 길어졌다는 사실을 말할 뿐, 긴 궤적의 각 단계가 검증되거나 최종 결과가 신뢰할 만하다는 뜻은 아니다. 몇 시간 동안 프로젝트를 다룰 수 있는 코딩 에이전트도 잘못된 전제 하나를 오래 끌고 가거나, 이미 끝낸 일을 다시 시도하거나, 핵심 산출물이 빠졌는데도 종료할 수 있다. 긴 지평은 행동 기회를 늘리지만, 그 기회를 올바른 상태 전이로 바꾸는 장치는 별도로 필요하다.

저자들이 묶어 제시한 실패 원인은 복합 오류와 목표 표류, 문맥 부패, 작업 상태 손실의 세 갈래다. 앞선 판단의 오류가 누적되면 뒤의 선택은 틀린 전제 위에서 이루어지고, 실행 이력이 커질수록 지금 필요한 단서가 오래된 관찰과 도구 출력 사이에 묻힌다. 더 근본적으로는 충족해야 할 요구사항, 이미 완료한 행동, 생성하거나 수정한 산출물, 환경에서 새로 확인한 사실이 하나의 최신 기록으로 유지되지 않는다. 이 세 문제는 독립적이라기보다, 상태를 잃은 에이전트가 부패한 문맥에서 잘못된 자기평가를 찾아 다시 상태로 받아들이는 연쇄로 연결된다.

1.2 문맥 부패와 작업 상태 손실은 같은 문제가 아니다

문맥 부패는 상호작용 기록이 길어지면서 관련 정보를 찾아 쓰기 어려워지는 현상이고, 작업 상태 손실은 현재 무엇이 참이며 무엇이 남았는지를 정확히 표현하지 못하는 현상이다. 둘은 함께 나타나지만 해결책은 다르다. 문맥을 요약하거나 창을 확장하면 검색 부담은 줄일 수 있어도, 요약에 들어간 완료 주장이 실제 환경에서 참인지 보장하지는 못한다. LongHorizon-Harness가 강조하는 차이는 정보 압축의 문제와 진실 판정의 문제를 분리해야 한다는 데 있다.

예를 들어 실행자가 파일을 만들었다고 보고했을 때, 그 문장을 짧게 요약해 다음 문맥으로 넘기는 것은 기억 관리다. 반면 파일이 요구된 경로에 존재하는지, 내용과 형식이 수용 기준을 만족하는지, 다른 필수 산출물을 훼손하지 않았는지를 환경에서 다시 확인하는 것은 상태 검증이다. 전자를 아무리 효율적으로 해도 잘못된 완료 판단이 압축된 형태로 오래 살아남을 수 있으며, 이후 계획은 그 오염된 기록을 확정 사실처럼 사용한다. 논문의 해법은 실행자의 보고를 곧바로 지속 상태로 승격하지 않고, 독립 감사에서 얻은 증거만 다음 라운드의 사실로 허용하는 것이다.

이 관점에서 장기 작업의 핵심 자원은 거대한 대화 로그보다 요구사항과 산출물과 환경 사실을 연결한 명시적 작업 상태다. 작업 상태는 원래 목표에서 파생된 요구사항, 실행 중 생성되거나 수정된 산출물, 다음 라운드에 필요한 환경 사실을 구조화해 담는다. 각 기록은 완료, 대기, 차단, 신뢰 불가 가운데 하나의 상태를 가지며, 현재 판정을 지지하는 감사 증거를 참조한다. 따라서 오래 지속해야 할 것은 실행자의 모든 사고 흔적이 아니라, 원래 목표와 대조할 수 있고 증거 계보를 가진 최소한의 상태 기록이다.

1.3 논문의 전환: 하나의 세션에서 감사된 상태 전이로

LongHorizon-Harness는 장기 실행을 하나의 계속 커지는 궤적 대신 독립적으로 감사되는 작업 상태 전이의 연속으로 재정의한다. 현재 상태를 읽어 다음 하위 작업을 정하는 관리자, 제한된 새 문맥에서 그 작업만 수행하는 실행자, 변경된 환경을 읽기 전용으로 검사하는 감사자를 분리한다. 다음 라운드로 넘어가는 기억은 실행자의 원시 상호작용 이력보다 작업 상태와 이를 뒷받침하는 감사 보고서다. 이 구조가 Manage-Execute-Audit, 즉 MEA 루프이며, 실행과 기억과 완료 판정을 한 주체의 자기서사 안에 두지 않는 것이 설계의 출발점이다.

서론에 요약된 주된 비교는 같은 기반 모델과 실행 백엔드를 유지한 조건에서 하네스 계층의 효과를 본다. Qwen 3.7-Plus와 Claude Code 조합에서 WeaveBench PassRate는 51.8%에서 80.7%로, Terminal-Bench 2.1 성능은 69.7%에서 77.2%로 높아졌다. 전체 OSWorld 2.0에서는 Qwen 3.7-Plus의 이진 완료율이 2.8%에서 8.3%로 증가했지만, 이 결과는 하이브리드 도구 구성을 사용한 LongHorizon-Harness와 공식 단일 행동 설정을 포함하는 비교라는 조건을 함께 읽어야 한다. 이 수치들은 모델이 새 능력을 학습했다는 증거라기보다 동일하거나 명시된 기반 능력을 하네스가 어떻게 누적된 완료로 변환하는가를 보여 주는 결과다.

Figure 1: 장기 작업 성능과 감사 기반 상태 전이의 개요

왼쪽 패널은 Qwen 3.7-Plus 결과로 WeaveBench가 51.8%에서 80.7%, Terminal-Bench 2.1이 69.7%에서 77.2%, OSWorld 2.0 이진 완료가 2.8%에서 8.3%로 변한 값을 표시한다. 앞의 두 비교는 Claude Code를 실행 백엔드로 유지하며, 전체 OSWorld 2.0 결과는 공식 단일 행동 기준선과 LongHorizon-Harness의 하이브리드 설정을 대조한다. 오른쪽 패널은 관리자, 새 문맥 실행자, 읽기 전용 감사자가 순환하고 감사된 상태만 이어 가는 구조를 보여 준다.

Figure 1의 오른쪽에서 중요한 것은 역할을 세 개의 이름으로 나눈 외형보다 어떤 정보가 어느 경계를 통과할 수 있는지를 제한한 점이다. 관리자는 환경을 직접 만지지 않고, 실행자는 현재 계약에 필요한 문맥만 받으며, 감사자는 결과를 바꾸지 않은 채 수용 기준과 환경을 대조한다. 실행 보고서는 감사 대상이지 완료 증명이 아니고, 감사 결과가 관리자의 상태 갱신을 거쳐야 비로소 다음 계획의 전제가 된다. 다시 말해 이 아키텍처는 행동의 권한, 판정의 권한, 기억의 권한을 분산해 한 번의 잘못된 자신감이 장기 상태 전체를 오염시키는 경로를 끊는다.

2. 배경 및 관련 연구: 모델과 하네스 사이의 책임 경계

2.1 모델의 국소 능력과 시스템의 장기 능력

장기 에이전트 성능을 모델 하나의 속성으로만 설명하면, 모델이 무엇을 잘못했는지와 시스템이 무엇을 잘못 조직했는지가 섞인다. 기반 모델은 한 라운드 안에서 계획을 세우고, 코드를 쓰고, 화면을 이해하고, 도구 결과를 해석하는 국소 능력을 제공한다. 모델 규모와 문맥 창, 코딩 및 에이전트 학습 데이터가 좋아질수록 이 국소 능력의 상한은 올라간다. 그러나 여러 라운드에서 어떤 성과를 확정하고 어떤 실패를 보류할지는 모델의 생성 능력보다 시스템이 상태를 선별하는 규칙에 달려 있다.

좋은 모델도 현재 하위 작업의 결과를 스스로 평가할 때 관찰 누락이나 낙관적 종료를 일으킬 수 있고, 긴 이력 속에서 오래된 상태를 최신 상태로 오인할 수 있다. 반대로 하네스는 모델이 갖지 않은 수학적 추론이나 정밀한 시각 제어 능력을 새로 만들어 낼 수 없지만, 이미 성공한 국소 행동을 잃지 않게 하고 실패한 주장을 다음 계획의 전제로 쓰지 않게 할 수 있다. 논문의 책임 경계는 이 차이를 선명하게 만든다. 모델은 가능한 행동과 해법의 품질을 결정하고, 하네스는 그 국소 결과가 검증되고 회복되고 축적되는 방식을 결정한다.

이 구분은 더 강한 모델과 더 강한 하네스를 경쟁 관계로 보지 않게 한다. 기반 모델이 좋아지면 실행 계약을 더 적은 시도로 충족하고 감사에서 발견된 결함도 더 정확히 고칠 수 있으며, 상태 관리가 좋아지면 그 성공을 후속 라운드가 안정적으로 재사용한다. 따라서 장기 능력은 모델 점수에 하네스의 부가 기능을 얹은 단순 합을 넘어 모델의 국소 행동이 상태 전이를 통과해 최종 완료로 보존되는 시스템 속성이다. 논문이 여러 모델과 여러 실행 백엔드에 같은 구조를 적용하는 이유도 능력의 원천과 능력의 조직 방식을 분리해 평가하기 위해서다.

2.2 기존 하네스가 담당해 온 것과 남은 공백

Claude Code, Codex CLI, OpenClaw 같은 에이전트 하네스는 모델 주변에서 프롬프트 구성, 도구 호출, 문맥 관리, 다단계 실행을 조직하는 표준 시스템 계층으로 자리 잡았다. 이들은 계획과 작업 분해, 셸 실행과 파일 편집, 하위 에이전트 호출, 격리된 문맥의 검토처럼 장기 작업에 필요한 상당한 기능을 이미 제공한다. 그러므로 LongHorizon-Harness의 출발점은 기존 네이티브 루프를 무능하다고 보고 대체하는 것이 아니다. 오히려 각 백엔드가 잘하는 내부 계획과 도구 사용은 유지하면서, 라운드 사이 상태 관리와 독립 판정을 바깥 계층이 맡는다.

기존 구조에 남은 첫 번째 공백은 작업 실행과 작업 상태 관리가 같은 성장 문맥을 공유한다는 점이다. 에이전트가 명령을 실행하고 오류를 읽고 대안을 시도하는 과정에는 많은 임시 정보가 생기는데, 같은 문맥이 완료 항목과 미해결 요구사항도 함께 기억해야 한다. 실행 흔적이 길어질수록 상태에 필요한 핵심 기록은 잡음 사이에서 복구하기 어려워지고, 이전 시도의 표현이 현재 환경보다 더 강하게 계획을 좌우할 수 있다. 문맥 창을 늘리는 것만으로는 임시 추론과 지속해야 할 사실 사이의 소유권 경계가 생기지 않는다.

두 번째 공백은 하위 작업을 수행한 주체가 그 완료 여부도 함께 판단한다는 점이다. 실행자는 자신의 의도와 시도 과정을 모두 알고 있으므로, 실제 산출물이 아닌 노력의 일관성이나 화면의 외형을 성공 신호로 받아들이기 쉽다. 이 판단이 요약이나 계획 문서에 기록되면 다음 단계는 확인되지 않은 완료를 전제로 시작하고, 나중에 결함이 드러나도 어느 시점의 주장이 잘못되었는지 추적하기 어렵다. MEA는 이 결합을 끊어 실행자가 낸 보고를 주장으로, 감사자가 환경에서 찾은 증거를 상태 갱신 후보로 다르게 취급한다.

2.3 단일 성장 문맥과 MEA의 책임 배치 비교

아래 Table 1은 논문에 실린 원표를 옮긴 대신 서론과 방법론의 구조 설명을 기준으로 기존 단일 성장 문맥과 MEA를 대조해 만든 리뷰용 합성 표다. 따라서 셀의 표현은 저자들의 설계 논리를 압축한 해설이며 별도의 실험 수치가 아니다. 비교의 핵심은 문맥을 여러 개로 나눈 사실보다 실행 주장, 환경 증거, 지속 상태가 어떤 순서로 연결되는가에 있다. 이 표를 통해 상태가 어디에 저장되고 누가 완료를 확정하는지라는 책임 경계를 한눈에 볼 수 있다.

Table 1. 기존 단일 성장 문맥과 LongHorizon-Harness MEA의 구조 비교

비교 항목	기존 단일 성장 문맥	LongHorizon-Harness MEA
실행 단위	하나의 세션이 연속 실행을 누적	관리자가 정한 경계 있는 계약을 라운드별 실행
작업 상태의 위치	실행 이력과 같은 문맥 안에 암묵적으로 존재	실행 문맥 밖의 구조화된 명시 상태로 존재
라운드 간 기억	관찰, 시도, 오류, 자기평가가 함께 계속 증가	작업 상태와 이를 지지하는 감사 보고서가 지속
완료 판단	실행 주체가 자신의 결과를 직접 평가	읽기 전용 감사자가 환경 증거로 독립 평가
실행자의 원시 궤적	후속 판단의 문맥에 계속 남음	라운드 종료 뒤 폐기되고 실행 보고만 감사로 전달
다음 작업 선택	누적 대화와 현재 자기평가에서 계속 진행	원래 목표와 감사된 최신 상태를 대조해 새 계약 생성
오류 전파 경로	잘못된 자기평가가 지속 기억에 바로 들어갈 수 있음	깨끗한 감사 증거가 없으면 완료 상태로 승격되지 않음
환경 권한	실행과 확인의 권한 경계가 흐릴 수 있음	실행자만 의도적으로 변경하고 감사자는 읽기 전용 검사

Table 1에서 MEA의 장점은 긴 이력을 무조건 없애는 데 있지 않고, 이력의 종류별로 수명을 다르게 정하는 데 있다. 현재 라운드에서 유용한 시행착오는 실행자의 새 문맥 안에서 충분히 활용하되, 라운드가 끝나면 원시 궤적을 폐기한다. 반면 요구사항과 검증된 산출물과 환경 사실은 감사 증거와 연결된 채 다음 라운드로 넘어간다. 그 결과 시스템은 많이 기억하는 대신 오래 기억할 자격이 있는 정보만 기억하게 된다.

2.4 AgentAdapter: 네이티브 루프를 대체하지 않는 경계층

LongHorizon-Harness가 기존 하네스 위에 작동할 수 있는 이유는 가벼운 AgentAdapter가 역할과 백엔드 사이의 공통 경계를 제공하기 때문이다. 어댑터는 계약, 역할별 환경 인터페이스, 실행 예산을 받아 Claude Code, Codex CLI, OpenClaw 같은 기존 백엔드를 하나의 제한된 에피소드로 시작한다. 백엔드 내부에서는 원래의 계획과 관찰과 도구 사용 루프가 그대로 작동하므로, LongHorizon-Harness가 각 제품의 내부 에이전트 로직을 다시 구현하지 않는다. 논문은 지원 범위에 Claude Code, Codex CLI, OpenClaw, Hermes Agent를 들며, 모델과 하네스 백엔드를 역할별로 교체할 수 있는 구조를 목표로 한다.

어댑터가 통제하는 것은 백엔드의 사고 방식보다 공급되는 문맥, 노출되는 도구, 환경 권한, 실행 예산, 반환 보고서다. 같은 네이티브 루프도 실행자 역할에서는 셸과 파일 편집과 테스트처럼 상태를 바꾸는 도구를 받을 수 있지만, 감사자 역할에서는 비변경 명령과 검사 도구만 받아야 한다. 관리자는 애초에 컴퓨터 환경 인터페이스를 받지 않으며, 감사된 기록만으로 상태와 다음 계약을 다룬다. 이 권한 배치는 프롬프트로 역할을 부탁하는 수준을 넘어 시스템 인터페이스로 책임 경계를 강제하려는 설계다.

이 접근은 기반 백엔드가 발전해도 외부 상태 전이 원칙을 유지할 수 있다는 실용적 장점이 있다. 더 나은 코딩 루프나 컴퓨터 사용 에이전트가 등장하면 실행 역할의 구현을 교체할 수 있고, 특정 환경에 더 적합한 백엔드를 GUI와 CLI에 다르게 배치할 수도 있다. 동시에 모든 역할이 같은 기반 모델을 쓰는 비교에서는 성능 변화가 모델 차이보다 상태 관리 계층에서 왔는지 더 분명히 볼 수 있다. 즉 AgentAdapter는 단순 호환성 래퍼를 넘어 모델의 국소 능력과 하네스의 장기 책임을 실험적으로 분리하는 접점이다.

3. 방법론: Manage-Execute-Audit 상태 전이

3.1 라운드 기반 상태 기계로 보는 전체 흐름

장기 작업을 $\mathcal{T}$, 라운드 $i$가 시작될 때의 작업 상태를 $S_i$, 실행 전 환경 상태를 $e_{i-1}$, 이전 감사 보고서의 누적을 $V_{i-1}=(v_1,\ldots,v_{i-1})$라고 하자. 관리자는 이 입력에서 범위가 제한된 하위 작업 계약 $c_i$를 만들고, 새 문맥의 실행자는 환경을 $e_{i-1}$에서 $e_i$로 바꾸며 실행 보고 $o_i$를 남긴다. 이어 감사자는 $e_i$를 읽기 전용으로 검사해 감사 보고 $v_i$를 만들고, 관리자는 이 증거를 $S_{i+1}$에 반영한다. 하나의 라운드는 따라서 계약 생성, 환경 변경, 독립 검증, 상태 갱신이라는 닫힌 전이 단위가 된다.

Figure 2: LongHorizon-Harness의 Manage-Execute-Audit 상태 전이 파이프라인

Figure 2에서 관리자는 $S_i$와 감사 이력을 읽어 목표, 수용 기준, 경계 조건, 관련 증거를 담은 $c_i$를 만든다. 선택된 GUI 또는 CLI 실행자는 제한된 새 문맥에서 환경을 $e_{i-1}$에서 $e_i$로 바꾸고, 감사자는 읽기 전용 도구로 결과를 검사해 $v_i$를 반환한다. 관리자는 이 보고로 상태를 갱신한 뒤 실행, 완료, 차단, 사용자 질의 가운데 다음 경로를 결정하므로, 감사되지 않은 실행 주장은 라운드 경계를 넘는 사실이 될 수 없다.

계약 $c_i$는 단순한 할 일 한 줄보다 현재 라운드가 무엇을 바꾸고 무엇을 지켜야 하는지를 명시하는 통제 문서다. 여기에는 즉시 달성할 목표, 성공을 판정할 수용 기준, 넘지 말아야 할 경계 제약, 실행과 검증에 필요한 이전 상태 기록과 감사 증거가 포함된다. 관리자는 필요한 주된 환경 전이에 따라 계약을 GUI 실행자 또는 CLI 실행자로 보낸다. 이렇게 작업을 제한하면 새 실행자는 전체 역사를 재구성하는 대신 현재 상태에서 다음으로 검증 가능한 변화 하나에 문맥을 집중할 수 있다.

라운드 수는 미리 고정된 단계 목록보다 감사 결과에 따라 동적으로 결정된다. 성공한 전이는 다음 요구사항을 열고, 불완전하거나 무결성이 의심되는 전이는 보수나 재검증 계약을 만들며, 사용자 정보나 권한이 필요하면 실행 대신 질의 경로를 택한다. 논문의 실험 설정에서는 최대 MEA 라운드를 25로 두고, 라운드마다 실행자에 1800초, 관리자와 감사자에 각각 300초의 독립 예산을 부여했다. 이 값은 보편적 알고리즘 상수가 아니라 해당 평가에서 각 역할의 에피소드를 유한하게 묶은 구현 조건이다.

3.2 관리자: 지속 상태의 소유자이자 다음 계약의 설계자

관리자는 원래 작업 $\mathcal{T}$, 현재 작업 상태, 누적 감사 보고서를 읽지만 컴퓨터 환경에는 직접 접근하지 않는다. 애플리케이션 화면을 보거나 작업공간 파일을 검사하거나 GUI와 CLI 도구를 호출할 수 없고, 환경을 수정하는 권한도 없다. 이 제한 때문에 관리자의 판단은 실행자의 생생한 궤적보다 감사자가 환경에서 기록한 증거에 의존해야 한다. 관리자가 지속 상태를 소유하되 관찰과 행동 권한을 갖지 않는 것은 계획이 임의의 미검증 관찰을 사실로 흡수하지 못하게 하는 장치다.

라운드 $i$ 뒤 관리자의 갱신은 $$(S_{i+1},q_{i+1},c_{i+1})=\Phi_{\mathrm{mgr}}(\mathcal{T},S_i,V_i)$$로 표현된다. 여기서 $V_i=(v_1,\ldots,v_i)$이고, 제어 결정 $q_{i+1}$은 execute, done, blocked, ask 가운데 하나다. 더 실행해야 할 때에만 다음 계약 $c_{i+1}$이 반환되며, 완료와 차단과 질의는 각각 다른 종료 또는 대기 의미를 가진다. 이 식은 관리자가 실행 결과 $o_i$를 직접 믿어 상태를 바꾸는 것보다 감사 이력 $V_i$를 통해서만 다음 상태와 제어를 산출한다는 의존성을 드러낸다.

초기 상태 $S_1$은 원래 작업에서 요구사항을 추출하고 모두 대기 상태로 표시해 만든다. 이후 감사 보고가 들어오면 요구사항, 산출물, 환경 사실 기록을 추가하거나 갱신하고, 해결되지 않은 항목은 대기나 차단 또는 신뢰 불가로 남긴다. 완료 표시는 깨끗한 감사 증거가 지지할 때만 허용되므로 실행자의 완료 주장은 그 자체로 지속 상태를 바꾸지 못한다. 이 규칙은 상태가 단순 체크리스트를 넘어 판정 상태와 증거 참조를 함께 가진 감사 가능한 원장이 되게 한다.

다음 계약을 만들 때 관리자는 $S_{i+1}$을 원래 작업과 비교해 아직 해결되지 않았고 현재 상태에서 전진 가능한 목표를 고른다. 의존성과 선행 조건을 확인한 뒤 즉시 목표와 수용 기준과 경계 제약을 묶고, 관련 있는 상태 기록과 이전 감사 보고서만 선택한다. 모든 요구사항이 감사된 상태로 충족되고 미해결 무결성 위반이 없으면 완료를, 허용된 행동으로 더 전진할 수 없으면 차단을, 사용자 정보나 승인이 필요하면 질의를 반환한다. 따라서 관리의 본질은 거대한 계획을 한 번에 생성하는 것보다 감사된 현재 상태에서 안전한 다음 전이 하나를 구성하는 일이다.

3.3 실행자: 새 문맥에서 환경을 바꾸는 유일한 역할

실행자는 관리자가 고른 계약을 수행하며, 세 역할 중 작업 관련 환경을 의도적으로 변경할 수 있는 유일한 주체다. 라운드 $i$에서 원래 작업, 현재 상태 $S_i$, 계약 $c_i$, 계약이 참조한 이전 감사 보고서만 받고, 이전 실행자들의 원시 상호작용 궤적은 받지 않는다. 환경 전이는 $$(e_i,o_i)=\Phi_{\mathrm{exec}}(\mathcal{T},S_i,c_i;e_{i-1})$$로 표현되며, $o_i$에는 수행 행동과 결과 상태와 생성 또는 수정한 산출물과 발생한 문제가 요약된다. 그러나 $o_i$는 실행 결과에 대한 주장이지 계약 완료의 증명은 아니다.

새 문맥 실행은 매 라운드를 기억상실 상태의 단발 호출로 축소한다는 뜻이 아니다. 한 에피소드 안에서는 계획, 환경 상호작용, 관찰, 수정의 여러 순환을 수행할 수 있고, 계약을 해결하는 데 필요한 도구 출력도 계속 사용할 수 있다. 다만 에피소드가 끝나면 내부 추론과 원시 궤적을 버리고, 감사에 필요한 실행 보고만 다음 역할로 전달한다. 이 방식은 현재 하위 작업에는 충분한 국소 문맥을 주면서 과거 라운드의 시행착오가 미래의 지속 기억을 점유하지 않게 한다.

GUI와 CLI 실행자는 서로 다른 환경 인터페이스와 책임 범위를 가진다. GUI 실행자는 스크린샷, 클릭, 스크롤, 텍스트 입력처럼 애플리케이션과 화면 상태 중심의 전이를 맡고, CLI 실행자는 셸 실행, 파일 편집, 코딩, 테스트처럼 작업공간과 프로세스와 프로그램 상태 중심의 전이를 맡는다. 하네스는 선택된 역할에 배정된 도구만 노출하며, 설정으로 명시하지 않은 다른 능력은 사용할 수 없게 한다. 관리자가 계약의 주된 변화 유형에 맞춰 실행 경로를 고르므로, 같은 환경을 다루더라도 변경 책임의 종류가 인터페이스 수준에서 구분된다.

실제 실행은 AgentAdapter를 통해 기존 백엔드의 하나의 예산 제한 에피소드로 시작된다. Claude Code나 Codex CLI나 OpenClaw 같은 백엔드는 자신의 네이티브 계획 및 도구 사용 루프를 유지하고, 역할이 허용한 범위에서 셸 실행과 파일 편집과 코드 작성과 테스트를 수행한다. 외부 하네스는 내부 추론 절차를 대체하지 않고 입력 문맥과 도구와 권한과 예산과 출력 보고 형식을 통제한다. 이 때문에 MEA는 특정 에이전트 구현에 종속된 새 실행기를 넘어 기존 실행기를 감사 가능한 상태 기계에 끼우는 상위 조정 계층으로 이해하는 편이 정확하다.

3.4 감사자: 완료 주장을 환경 증거로 바꾸는 읽기 전용 역할

감사자는 실행 뒤 원래 작업, 상태 $S_i$, 계약 $c_i$, 계약이 참조한 이전 감사, 실행 보고 $o_i$를 받는다. 실행자의 원시 상호작용 궤적과 내부 추론은 받지 않으며, 결과 환경 $e_i$를 독립적으로 검사해 $$v_i=\Phi_{\mathrm{aud}}(\mathcal{T},S_i,c_i,o_i;e_i)$$를 만든다. $o_i$는 관련 파일이나 창이나 로그나 프로세스를 찾는 단서로 쓸 수 있지만, 완료 판정은 계약의 목표와 수용 기준과 경계 제약을 환경 상태에 직접 대조해 내린다. 이렇게 생성된 $v_i$만 지속 감사 이력에 추가되어 다음 관리자 판단의 근거가 된다.

GUI 감사자는 애플리케이션과 화면 상태를 관찰 중심 상호작용으로 확인하고, CLI 감사자는 비변경 명령과 검사 도구로 파일, 메타데이터, 로그, 프로세스, 테스트, 작업공간 상태를 살핀다. 두 경우 모두 실행자의 자신감이나 보고서 문구보다 환경에서 직접 얻은 증거가 결론을 지지해야 한다. 감사자는 필요한 관찰 시점을 바꿀 수는 있지만 보호된 산출물을 생성, 편집, 덮어쓰기, 이동, 삭제할 수 없고 결과를 바꾸는 명령도 실행할 수 없다. 검사 과정이 대상 상태를 고쳐 버리면 검증과 실행의 인과 경계가 무너지기 때문이다.

하네스는 감사 중 작업 관련 작업공간과 산출물 상태를 감시하며, 변이가 감지되면 무결성 위반으로 기록한다. 그런 감사 보고는 완료된 상태 기록을 지지할 수 없으므로, 감사자가 검사 과정에서 실수로 문제를 고친 뒤 성공이라고 선언하는 경로가 차단된다. 읽기 전용은 단순한 역할 지침을 넘어 완료 증거의 출처와 재현성을 지키는 권한 조건이다. 이 원칙 덕분에 감사 결과는 실행자의 보고와 독립된 환경 기반 판정으로서 지속 상태에 들어갈 자격을 얻는다.

감사 보고 $v_i$는 세 종류의 결론을 기록한다. 첫째, 수용 기준을 기준으로 완료, 불완전, 차단 가운데 하나의 완료 상태를 부여하고, 둘째, 작업공간 변이와 산출물 유효성 및 출처와 삭제 제약을 확인해 깨끗함, 의심, 위반 가운데 하나의 무결성 상태를 부여한다. 셋째, 검증된 사실과 지지 증거와 남은 공백을 포함해 작업 상태에 반영할 변경안을 제안한다. 최종적으로 어떤 기록을 $S_{i+1}$에 넣을지는 관리자가 결정하므로, 감사자는 증거와 판정을 생산하고 관리자는 지속 상태의 정책을 집행한다.

3.5 역할별 입력·권한·출력과 라운드 종료

아래 Table 2 역시 논문의 원표를 복제한 대신 방법론의 역할 정의를 입력, 권한, 출력, 지속 여부 축으로 재구성한 리뷰용 합성 표다. 여기서 지속 여부는 역할의 모든 문맥이 저장되는지를 뜻하지 않고, 해당 역할이 만든 정보 가운데 무엇이 라운드 경계를 넘어 공식 상태 계보에 남는지를 뜻한다. 관리자의 상태와 감사 보고는 지속되지만, 실행자의 원시 궤적과 내부 추론은 폐기된다. 이 비대칭이 MEA를 단순한 다중 에이전트 토론과 구별한다.

Table 2. 관리자·실행자·감사자의 정보 및 권한 경계

역할	주요 입력	환경 권한	주요 출력	라운드 간 지속 여부
관리자	원래 작업 $\mathcal{T}$, 현재 상태 $S_i$, 누적 감사 $V_i$	직접 관찰·도구 호출·환경 수정 불가	갱신 상태 $S_{i+1}$, 제어 결정 $q_{i+1}$, 필요 시 계약 $c_{i+1}$	구조화된 작업 상태와 그 증거 참조가 지속
실행자	원래 작업, $S_i$, 현재 계약 $c_i$, 계약이 참조한 감사	할당된 GUI 또는 CLI 도구로 의도적 환경 변경 가능	변경 환경 $e_i$, 실행 요약 $o_i$	원시 궤적과 내부 추론은 폐기되며 $o_i$는 감사 입력으로 전달
감사자	원래 작업, $S_i$, $c_i$, 관련 이전 감사, $o_i$, 결과 환경 $e_i$	관찰과 비변경 검사만 가능하며 작업 관련 상태 수정 금지	완료·무결성·증거·남은 공백을 담은 $v_i$	$v_i$가 지속 감사 이력에 추가되어 관리자에게 전달

루프는 감사된 상태가 원래 작업을 충족하면 끝나지만, 성공만이 종료 이유는 아니다. 남은 요구사항을 전진시킬 허용된 하위 작업이 없으면 차단되고, 사용자 정보나 승인이 필요하면 질의 상태로 넘어가며, 설정된 라운드 예산이 소진되어도 실행은 중단된다. 완료 판정에는 미해결 무결성 위반이 없어야 하므로 산출물이 겉보기에 존재한다는 이유만으로 종료할 수 없다. 이 종료 규칙은 더 행동할 수 있음과 올바르게 끝낼 수 있음을 구분해 장기 실행의 성공 조건을 상태 수준에서 닫는다.

MEA의 전체 상태 전이는 결국 무엇이 다음 라운드의 전제가 될 수 있는지에 대한 보수적 규칙으로 요약된다. 실행자는 환경을 바꾸지만 진실을 확정하지 않고, 감사자는 진실 후보를 환경에서 검증하지만 지속 상태를 직접 소유하지 않으며, 관리자는 검증된 증거로만 상태와 다음 계약을 갱신한다. 새 문맥은 실행 노이즈의 수명을 제한하고, 읽기 전용 감사는 완료 판정의 독립성을 지키며, 외부 작업 상태는 여러 에피소드 사이의 연속성을 담당한다. LongHorizon-Harness의 핵심은 더 긴 생각을 한 번에 유지하는 것보다 짧은 실행 성과를 감사된 상태 전이로 바꾸어 오래 이어 붙이는 것이다.

4. 실험 설정: 세 벤치마크와 공정 비교의 경계

4.1 세 벤치마크가 시험하는 서로 다른 장기 작업

LongHorizon-Harness의 실험은 WeaveBench, OSWorld 2.0, Terminal-Bench 2.1이라는 세 환경을 가로지른다. 세 벤치마크는 모두 여러 단계가 이어지는 작업을 다루지만, 에이전트가 접하는 상태와 성공 판정 방식은 서로 다르다. 따라서 숫자를 한 줄의 통합 순위처럼 읽기보다, 각 환경에서 무엇을 관찰하고 어떤 도구로 상태를 바꾸며 어떤 평가기가 완료를 인정하는지부터 분리해 보아야 한다.

WeaveBench는 114개 과제로 구성되며 하나의 워크플로 안에서 GUI와 CLI를 함께 사용해야 한다. 도메인은 데스크톱 애플리케이션, 문서 처리, 게임, 웹 개발, 데이터 분석·시각화, DevOps, 공간·3D, 디자인의 여덟 가지다. 저자들은 공식 과제 정의, 작업 공간, 런타임 자산, 판정 템플릿을 사용하고, 점수가 0.8 이상인 과제의 비율인 PassRate와 114개 과제 점수의 평균인 Overall을 보고한다. PassRate는 퍼센트지만 Overall은 0과 1 사이의 평균 점수이므로 두 열의 차이를 같은 단위로 해석하면 안 된다.

OSWorld 2.0은 전문적인 데스크톱 워크플로 108개를 제공하며, 사람의 중앙 완료 시간이 약 1.6시간인 긴 과제들이다. 실험은 osworld-v2-2026.06.24 릴리스와 Docker 기반 Ubuntu VM, 1920×1080 해상도에서 수행되고 최종 평가는 네이티브 env.evaluate()가 담당한다. Binary Accuracy는 최종 점수가 정확히 1인 과제만 성공으로 세며, Partial Accuracy는 108개 과제의 세부 점수를 평균한다. 그러므로 Binary가 낮더라도 Partial이 오르면 더 많은 요구 조건까지 진행했다는 뜻이지, 완전 성공 과제의 비율과 동일한 의미는 아니다.

Terminal-Bench 2.1은 화면 조작과 달리 격리된 Docker 터미널에서 소프트웨어 엔지니어링과 시스템 관리 같은 현실적인 명령줄 작업을 평가한다. 저자들은 Harbor를 평가 프레임워크로 사용하고 과제마다 정의된 CPU, 메모리, 환경 제약을 유지했으며, 각 과제를 세 번 독립 실행한 뒤 과제별 평균 점수를 다시 집계했다. 한 trial의 제한 시간은 5시간이어서 단일 명령의 정답보다 설치, 빌드, 수정, 검사처럼 지속되는 상태 변화를 시험한다. 이 벤치마크에서의 향상은 GUI 라우팅만으로 설명할 수 없는 장기 실행 효과를 확인하는 대조축이 된다.

Table 3. 세 벤치마크의 평가 설정과 비교 단위

벤치마크	규모·환경	주요 도구 표면	보고 지표	저자 실행의 핵심 설정
WeaveBench	114 tasks, 격리 Ubuntu desktop VM, 8 domains	GUI+CLI, screenshot·pyautogui 계열, 제한적 save_screenshot	PassRate (%), Overall (0–1 평균)	Qwen 3.7-Plus, claude-code 2.1.76, 최대 25 MEA rounds
OSWorld 2.0	108 tasks, osworld-v2-2026.06.24, Docker VM, 1920×1080	공식 기준은 single/batched GUI, LH는 hybrid GUI+CLI	Binary (%), Partial (%)	Qwen 3.7-Plus, claude-code 2.1.176, native env.evaluate()
OSWorld 2.0 subset	34 tasks	baseline single action GUI, LH hybrid GUI+CLI	Binary (%), Partial (%)	Claude Opus 4.7 backbone
Terminal-Bench 2.1	Harbor+Docker, task별 3 independent trials	CLI only	3회 평균 success rate (%)	claude-code 2.1.211, trial당 5시간

4.2 실행 예산과 역할 조건

기본 LongHorizon-Harness 설정에서는 manager, executor, auditor가 특별한 언급이 없는 한 같은 backbone을 사용한다. WeaveBench의 대표 비교에서는 세 역할이 Qwen 3.7-Plus를 사용하고 executor의 실제 실행 백엔드는 Claude Code로 유지된다. 한 라운드의 executor 제한 시간은 1,800초, manager와 auditor는 각각 300초이며 전체 작업은 최대 25라운드까지 진행된다. 즉 성능 차이를 서로 다른 모델을 섞어 만든 결과로 설명할 필요는 없지만, 단일 세션보다 여러 번 실행하고 감사할 수 있는 계산 예산은 결과와 비용에 함께 반영된다.

WeaveBench의 GUI 도구는 공식 화면 캡처와 pyautogui 기반 클릭·입력·스크롤·드래그를 보존하며, 저자들은 현재 실제 화면을 증거 파일로 저장하는 save_screenshot만 제한적으로 더했다. 이 도구는 새로운 환경 제어 능력이나 숨은 정보를 제공하지 않고, 과제가 요구하는 공식 스크린샷 산출물을 보존하는 기능으로 설명된다. 그럼에도 도구 집합은 재현 가능한 비교 조건의 일부이므로 모델 이름만 보고 결과를 동일시해서는 안 된다. 런타임 버전도 WeaveBench 2.1.76, OSWorld 2.1.176, Terminal-Bench 2.1.211로 서로 다르다.

OSWorld의 LongHorizon-Harness는 컴퓨터 MCP를 통한 GUI 조작과 같은 VM 내부의 shell 명령을 함께 쓰는 hybrid tool pool을 사용한다. 반면 표에 인용된 공식 기준선은 single-action 또는 batched-action GUI 설정이므로, Qwen 3.7-Plus라는 모델명이 같아도 도구 권한과 행동 모드까지 일치하는 matched comparison은 아니다. 34개 Claude Opus 4.7 부분집합 역시 backbone은 같지만 single action과 hybrid의 차이가 남는다. 이 결과는 시스템 구성 전체의 유용성을 보여주지만, 순수한 상태 관리 효과만의 인과 추정치로 읽어서는 안 된다.

Terminal-Bench의 Qwen 계열 실험은 baseline과 LongHorizon-Harness 모두 Claude Code를 CLI 실행 에이전트로 사용한다. 저자들은 컨테이너 안의 투명 프록시를 통해 temperature 1.0, top_p 0.95, top_k 20, enable_thinking=true, max_tokens 65,536을 적용했다고 명시한다. 이때 Qwen 3.7-Plus의 69.7% 대 77.2%는 동일 backbone과 실행 백엔드를 둔 저자 자체 실행이어서 핵심 비교로 삼을 수 있다. 반대로 GPT-5.6 Luna와 Codex 조합의 83.1%는 제한된 예산으로 수행한 별도 구성이지, 논문 안에서 동일 조건의 자체 baseline을 모두 다시 돌린 완전한 ablation은 아니다.

4.3 ‘공정 비교’가 성립하는 범위

WeaveBench 표의 회색 행은 공식 논문이 보고한 외부 결과이고 검은 행은 LongHorizon-Harness 저자들의 실행이다. 중요한 차이는 공식 결과가 regular user로 실행된 반면 자체 실행은 과제 VM 안에서 root privileges를 사용했다는 점이다. 따라서 공식 Claude Opus 4.7+Claude Code의 41.2%와 자체 Qwen 결과를 직접 대조해 모델 또는 하네스 우위를 단정할 수 없다. 인과적으로 가장 설득력 있는 비교는 같은 root 조건에서 자체 실행한 Qwen 3.7-Plus+Claude Code 51.8%와 이를 감싼 LongHorizon-Harness 80.7%다.

OSWorld 표의 회색 행도 공식 보고값이고 LongHorizon-Harness 행만 저자들의 hybrid 실행이다. 공식 Qwen single-action 2.8%와 LH hybrid 8.3% 사이에는 상태 관리 구조에 더해 GUI+CLI 도구 선택의 차이가 동시에 들어간다. 따라서 이 수치는 ‘같은 Qwen을 포함한 전체 에이전트 시스템이 얼마나 달라졌는가’를 보여주지만, MEA 루프 하나의 독립 효과를 분리하지는 못한다. Claude Opus 4.7의 34개 부분집합 결과도 동일한 주의를 적용해야 한다.

Terminal-Bench 순위 그림은 저자 자체 실행 세 가지와 공식 leaderboard 또는 각 모델의 공식 보고에서 가져온 외부 수치를 함께 배치한다. 별표가 붙은 값은 외부 보고이며, 별표가 없는 Qwen baseline, Qwen LongHorizon-Harness, GPT-5.6 Luna LongHorizon-Harness만 저자 실행이다. 이 구분을 지우면 83.1%라는 같은 숫자를 가진 GPT-5.5 Codex 외부 결과와 GPT-5.6 Luna LH 자체 결과가 마치 한 통제 실험의 두 조건처럼 보일 수 있다. 논문의 주장을 안전하게 읽으려면 backbone, harness, 도구 권한, 실행 주체를 네 개의 열로 분리해야 한다.

결국 이 논문의 강한 증거와 넓은 일반화 증거는 역할이 다르다. WeaveBench와 Terminal-Bench의 Qwen matched baseline은 같은 모델과 실행 백엔드에서 task-state management 층을 더했을 때의 변화를 비교적 직접적으로 보여준다. OSWorld 전체와 Opus 부분집합은 도구 모드까지 바뀐 종합 시스템 결과로서 외적 타당성을 넓히지만 원인을 한 요소에만 귀속할 수 없다. 논문 어디에도 pretrained 대 finetuned 같은 조건은 없으므로 그런 가상의 축을 추가해 설명해서도 안 된다.

5. 주요 실험 결과: 성공률과 비용을 함께 읽기

5.1 WeaveBench: 가장 선명한 matched 개선

WeaveBench에서 Qwen 3.7-Plus+Claude Code 기준선은 PassRate 51.8%, Overall 0.702를 기록했다. 같은 모델과 Claude Code 실행 백엔드를 유지하고 LongHorizon-Harness를 적용하면 80.7%, 0.835로 오른다. PassRate 증가는 28.9%가 아닌 28.9%포인트이며, 상대적으로는 약 55.8% 증가한 값이다. Overall은 퍼센트 열이 아니므로 변화량을 +0.133의 평균 점수로 표기하는 편이 정확하다.

도메인별 PassRate도 여덟 영역 모두 상승한다. 가장 큰 폭은 디자인의 20.0%에서 80.0%로의 +60.00%포인트와 공간·3D의 16.7%에서 66.7%로의 +50.00%포인트이며, 게임도 29.4%에서 58.8%로 높아진다. 기준선이 이미 83.3%였던 데스크톱은 88.9%로 +5.56%포인트만 상승해 천장 효과를 보인다. 표시된 한 자리 소수의 단순 뺄셈과 부록의 정확 과제 수 기반 델타가 약간 다를 수 있으므로 표에는 논문이 제시한 원시 표시값과 델타를 함께 보존했다.

Table 4. WeaveBench 자체 matched 결과와 도메인별 PassRate

범위	Baseline: Qwen 3.7-Plus+Claude Code	LongHorizon-Harness (Claude Code)	변화
전체 PassRate	51.8%	80.7%	+28.9%포인트
전체 Overall	0.702	0.835	+0.133 점수
DES	20.0%	80.0%	+60.00%포인트
SPA	16.7%	66.7%	+50.00%포인트
DAV	53.8%	84.6%	+30.77%포인트
GAM	29.4%	58.8%	+29.41%포인트
WEB	46.7%	73.3%	+26.67%포인트
OPS	66.7%	91.7%	+25.00%포인트
DOC	76.5%	100.0%	+23.53%포인트
DSK	83.3%	88.9%	+5.56%포인트

여기서 도메인 전반의 상승은 특정 애플리케이션에만 맞춘 편법이라는 설명을 약화한다. 특히 여러 파일·화면·증거를 순서대로 맞춰야 하는 디자인과 공간 작업에서 큰 델타가 나타난다는 점은 외부 상태 기록과 독립 검사의 가설에 부합한다. 다만 모든 도메인 상승 자체가 manager와 auditor 각각의 필수성을 증명하는 것은 아니다. 역할 제거 실험 없이 관찰된 것은 완성된 MEA 시스템과 단일 Claude Code 기준선의 차이다.

5.2 OSWorld 2.0: 완전 성공과 부분 진척의 동시 상승

OSWorld 2.0 전체 108개 과제에서 공식 Qwen 3.7-Plus single-action 결과는 Binary 2.8%, Partial 21.5%다. LongHorizon-Harness의 hybrid 구성은 8.3%, 35.2%를 기록해 Binary는 +5.5%포인트, Partial은 +13.7%포인트 상승한다. Binary만 보면 약 3.0배지만 이는 절대 격차가 5.5%포인트인 낮은 기저의 배수다. Partial의 상승은 완전 성공에 도달하지 못한 과제에서도 더 많은 세부 조건을 만족했다는 별도의 신호다.

Claude Opus 4.7을 사용한 34개 과제 부분집합에서도 방향은 같다. single-action 기준선의 Binary 20.6%, Partial 55.8%가 LongHorizon-Harness hybrid에서 35.3%, 66.9%로 바뀐다. 각각 +14.7%포인트와 +11.1%포인트이며, 더 강한 backbone에서도 상태 관리형 실행의 이득이 사라지지 않았음을 보여준다. 그러나 전체 108개 Qwen 결과와 34개 Opus 결과는 과제 집합도 다르므로 두 행의 절대 성능을 모델 순위로 비교할 수 없다.

Table 5. OSWorld 2.0 전체 및 Claude Opus 4.7 부분집합 결과

평가 범위	Backbone	Harness / mode	Binary	Partial	출처·비교 성격
Full 108 tasks	Claude Opus 4.8	Batched actions	20.6%	54.8%	공식 외부 보고
Full 108 tasks	Claude Opus 4.7	Batched actions	18.2%	48.9%	공식 외부 보고
Full 108 tasks	GPT-5.5	Batched actions	13.0%	49.5%	공식 외부 보고
Full 108 tasks	Claude Opus 4.8	Single action	18.5%	49.3%	공식 외부 보고
Full 108 tasks	Claude Opus 4.7	Single action	13.9%	49.1%	공식 외부 보고
Full 108 tasks	Claude Sonnet 4.6	Single action	8.3%	41.5%	공식 외부 보고
Full 108 tasks	MiniMax M3	Single action	4.6%	22.3%	공식 외부 보고
Full 108 tasks	Kimi 2.6	Single action	4.6%	22.1%	공식 외부 보고
Full 108 tasks	Qwen 3.7-Plus	Single action	2.8%	21.5%	공식 외부 기준
Full 108 tasks	Qwen 3.7-Plus	LongHorizon-Harness hybrid	8.3%	35.2%	저자 자체 실행
34-task subset	Claude Opus 4.7	Single action	20.6%	55.8%	부분집합 기준선
34-task subset	Claude Opus 4.7	LongHorizon-Harness hybrid	35.3%	66.9%	부분집합 저자 실행

OSWorld 결과에서 가장 중요한 제한은 single action 대 hybrid라는 모드 차이다. shell은 파일, 메타데이터, 스크립트와 긴 텍스트를 다루는 데 유리하므로 향상분 전체를 외부 task state나 auditor 하나에 돌릴 수 없다. 반대로 GUI만 사용한 공식 기준보다 실제 업무에 가까운 혼합 도구 시스템을 평가했다는 실용적 의미는 있다. 이 표는 순수 ablation보다는 배포 가능한 시스템 구성 간 성능 비교로 읽는 편이 타당하다.

5.3 Terminal-Bench 2.1: GUI 밖에서도 유지되는 이득

Figure 3: Terminal-Bench 2.1 자체 실행과 외부 보고 순위

Figure 3. 저자 자체 실행에서 Qwen 3.7-Plus+Claude Code는 69.7%이고, 같은 실행 백엔드를 LongHorizon-Harness로 감싸면 77.2%로 +7.5%포인트 오른다. GPT-5.6 Luna+Codex의 LH 실행은 83.1%지만 제한된 별도 run이다. 별표가 붙은 나머지 값은 공식 leaderboard나 모델 공식 보고에서 가져온 외부 수치다. 같은 막대 길이라도 실행 주체와 예산이 다르므로, Figure 3은 통합 리더보드보다 자체 Qwen 대응 비교와 외부 위치를 동시에 보여 주는 자료로 읽어야 한다.

Qwen의 69.7%에서 77.2%로의 변화는 같은 backbone과 Claude Code를 유지한 자체 비교라는 점에서 중요하다. Terminal-Bench에는 시각 인식이나 GUI와 CLI 사이의 라우팅이 없으므로, 이득을 컴퓨터 사용 전용 기능으로만 설명할 수 없다. manager가 미완료 조건을 계약으로 남기고 fresh-context executor가 다음 상태 변화를 수행하며 auditor가 파일·프로세스·테스트 결과를 확인하는 구조가 순수 CLI에서도 작동한 것이다. 절대 향상은 +7.5%포인트이고 상대 향상은 약 10.8%다.

Figure 3의 최상단에는 Claude Code(Fable 5, xhigh) 83.8%와 Codex(GPT-5.5, xhigh) 83.1%가 별표와 함께 표시된다. 이어 저자 자체 LH-Harness+Codex(GPT-5.6 Luna, max)가 83.1%를 기록하고, 외부 GLM·Fable·Grok·Opus·Terra 결과가 배치된다. 시각적 순위는 현재 생태계에서의 위치를 보여주지만 실행 예산과 보고 주체가 섞인 참고 자료다. 특히 83.1% 자체 run을 외부 75.7% Codex(GPT-5.6 Luna, max)와 단순 차감해 harness의 순효과라고 부르면 공정 비교 범위를 넘는다.

Table 6. Terminal-Bench 2.1 자체 실행과 벤치마크별 토큰 비용

구분	Baseline / reference	LongHorizon-Harness	성능 또는 비용 변화	비고
Terminal-Bench success	Qwen 3.7-Plus+Claude Code 69.7%	Qwen 3.7-Plus+Claude Code 77.2%	+7.5%포인트	두 값 모두 저자 자체 run
Terminal-Bench 별도 구성	동일 조건 자체 baseline 없음	GPT-5.6 Luna+Codex 83.1%	순효과 계산 불가	저자 제한 run
WeaveBench tokens/task	12.0M	27.4M	약 2.3배	total tokens
OSWorld tokens/task	28.9K	104K	약 3.6배	output tokens만 비교
Terminal-Bench tokens/task	4.6M	3.5M	약 24% 감소	total tokens

5.4 비용-성능 곡선은 고정된 세금이 아니다

Figure 4: OSWorld 2.0의 Qwen 3.7-Plus 비용-성능 이동

Figure 4. OSWorld 2.0에서 Qwen 3.7-Plus 기준선은 과제당 평균 출력 토큰 28.9K로 Binary 2.8%, Partial 21.5%를 얻는다. LongHorizon-Harness는 104K 출력 토큰에서 8.3%, 35.2%로 이동한다. 성능 전선은 개선되지만 비용도 약 3.6배이므로, 같은 모델의 무료 향상으로 볼 수 없고 추가 추론과 검증을 산 결과다. 입력 토큰이 공개되지 않은 조건이라 총비용으로 환산할 수 없으며, 이 그래프의 x축은 출력 토큰이라는 제한도 함께 보아야 한다.

OSWorld의 blue star는 고정된 Qwen backbone이 더 높은 Binary와 Partial 지점으로 이동했음을 보여준다. 이는 강한 모델을 새로 투입하지 않고도 harness가 달성 가능한 과제 수준 성능을 바꿀 수 있다는 시스템 관점을 지지한다. 동시에 x축이 28.9K에서 104K로 크게 늘기 때문에, 사용자 입장에서는 성공률에 더해 토큰 예산과 지연 시간을 함께 최적화해야 한다. 논문이 보고하는 3.6배는 출력 토큰 기준이며, 공식 결과가 입력 토큰 통계를 제공하지 않아 OSWorld만 total token과 같은 열에 놓을 수 없다.

WeaveBench에서도 과제당 total token이 12.0M에서 27.4M으로 늘어 약 2.3배가 된다. 반면 Terminal-Bench는 4.6M에서 3.5M으로 줄어 성능이 오르면서도 토큰이 약 24% 감소한다. 즉 manager와 auditor를 추가하면 언제나 일정한 배수의 비용이 붙는다는 모델은 자료와 맞지 않는다. 작업을 짧은 계약으로 나눠 재시도를 줄이는 효과와, 약한 executor를 반복 복구하느라 토큰이 늘어나는 효과 중 어느 쪽이 큰지가 벤치마크마다 달라진다.

비용을 읽을 때는 ‘역할 수가 세 개이니 대략 세 배’라는 단순 계산도 피해야 한다. manager는 짧은 상태 요약과 다음 계약을 만들고, auditor는 읽기 전용 검사에 집중하며, executor가 실제 도구 사용의 대부분을 수행한다. 세 역할의 컨텍스트가 분리되어 있어 각 호출의 길이와 횟수도 동일하지 않다. 따라서 총비용은 역할 수보다 라운드 수, 복구 난도, backbone의 한 번 실행 성공률, 평가에 필요한 증거량에 의해 결정된다.

6. 추가 분석 및 Ablation Study: 어느 작업에서 상태 관리가 이기는가

6.1 먼저 밝힐 점: 이것은 역할 제거 ablation이 아니라 해석적 분해다

논문에는 manager를 제거한 조건, auditor를 제거한 조건, fresh context만 남긴 조건을 동일 예산에서 체계적으로 비교한 표준적인 역할 제거 Ablation Study가 없다. 따라서 이 절에서의 ablation은 완성된 시스템을 비용, 역할, 과제 유형, 실패 범주로 나누어 읽는 해석적 분해다. 토큰 비중이 작다고 manager가 불필요하다고 결론 내릴 수도 없고, auditor 비중이 크다고 성능 향상의 대부분을 auditor가 만들었다고 인과적으로 말할 수도 없다. 관찰 가능한 것은 각 역할이 계산을 얼마나 소비했고 어느 종류의 과제에서 완성 시스템의 델타가 컸는가이다.

가장 가까운 통제 비교는 동일 Qwen+Claude Code의 baseline과 전체 LongHorizon-Harness를 비교한 WeaveBench 및 Terminal-Bench 결과다. 이 비교는 MEA 패키지 전체의 효과를 지지하지만, 명시적 task state, fresh-context 실행, read-only audit 중 어떤 요소가 얼마나 기여했는지는 분리하지 않는다. OSWorld는 여기에 hybrid 도구 풀 변화까지 포함되어 내부 구성요소의 분해가 더 어렵다. 후속 연구라면 동일 총토큰과 동일 도구 권한 아래에서 manager-only, manager+fresh context, manager+auditor, full MEA를 비교해야 한다.

그럼에도 부가 분석은 설계 가설을 점검하는 데 유용하다. 만약 장기 상태 유지가 핵심이라면, 여러 의존 상태와 검증 가능한 산출물을 오랫동안 누적하는 과제에서 큰 이득이 나고 짧은 단일 능력 과제에서는 이득이 작아야 한다. 또한 추가 역할의 계산이 manager보다 감사 단계에 더 많이 쓰이고, 강한 executor가 빠르게 계약을 닫을 때는 총토큰이 줄 수도 있어야 한다. 아래의 역할별 비용과 과제별 델타는 바로 이 예측과 어느 정도 일치한다.

6.2 역할별 토큰: 상태 작성은 작고 검증은 크다

Figure 5: 벤치마크별 관리자·실행자·감사자 토큰 비중

Figure 5. manager의 정확 토큰 비중은 WeaveBench 2.8%, OSWorld 2.0 2.0%, Terminal-Bench 2.1 8.1%이고, auditor는 각각 19.4%, 24.8%, 38.1%다. 총량은 27.4M, 출력 104K, 3.5M이며 그림 라벨은 비중을 정수로 반올림한다. 명시적 상태 작성보다 독립 검증이 더 큰 추가 계산을 차지한다. 실행자 비중은 나머지 78%, 73%, 54% 수준이며, 역할 셋을 단순히 호출 횟수 세 배로 환산하면 실제 비용 구조를 설명하지 못한다.

manager의 비중이 세 벤치마크에서 2.0~8.1%에 머문다는 것은 외부 task state를 유지하고 다음 subtask contract를 작성하는 텍스트 자체가 주된 비용원이 아님을 뜻한다. 반면 auditor는 19.4~38.1%를 사용해 파일, UI 상태, 테스트, 산출물의 완료 여부를 확인하는 단계가 상당한 계산을 요구한다. 나머지 대부분은 executor가 소비하며, 그림의 반올림 라벨은 WeaveBench 78%, OSWorld 73%, Terminal-Bench 54%로 표시된다. 이 분포는 ‘계획을 길게 쓰는 시스템’보다 ‘실행 결과를 별도 맥락에서 검증하는 시스템’이라는 성격을 더 잘 드러낸다.

특히 Terminal-Bench에서 auditor가 38.1%를 차지하면서 총토큰은 오히려 24% 줄었다는 점이 흥미롭다. 독립 검사가 추가 호출을 만들더라도 잘못된 설치나 빌드 경로를 조기에 발견하고 다음 계약을 좁히면, 하나의 긴 세션이 같은 실패를 반복하는 비용을 상쇄할 수 있다. 반대로 OSWorld의 Qwen 구성에서는 복잡한 GUI 상태와 긴 작업을 복구하기 위해 104K 출력 토큰이 필요해 기준선의 3.6배가 되었다. 동일 구조의 효율은 모델과 환경의 상호작용에 의해 바뀐다.

WeaveBench Games의 별도 비교도 이 상호작용을 보여준다. 17개 게임에서 Claude Opus 4.7은 LongHorizon-Harness 적용 시 평균 점수가 0.680에서 0.809로 오르면서 토큰은 과제당 16.5M에서 11.1M으로 줄었다. Qwen 3.7-Plus는 점수가 0.524에서 0.733으로 오르지만 토큰은 10.7M에서 34.3M으로 늘었다. 같은 하네스라도 강한 executor는 더 적은 audit–replan round로 계약을 닫고, 약한 executor는 실패 바닥을 끌어올리는 대신 반복 복구 비용을 지불한다는 해석이 가능하다.

6.3 과제 유형별 델타: 지속되고 검증 가능한 상태가 있는가

Figure 6: WeaveBench·OSWorld·Terminal-Bench의 과제 유형별 성능 변화

Figure 6. WeaveBench에서는 DES +60.0, SPA +50.0%포인트가 가장 크고, OSWorld에서는 streaming interaction이 평균 점수 0.000에서 0.500으로 오른다. Terminal-Bench는 games +33.3, system-administration +29.6%포인트가 크지만 video-processing은 -33.3%포인트다. 파란 연결은 개선, 빨간 연결은 회귀다. 소표본 범주의 델타는 불확실성이 크고 OSWorld capability tag는 중복되므로, 인과 효과 크기보다 상태의 지속성·검증 가능성과 성능 변화가 함께 움직이는지 보는 분석에 가깝다.

세 패널의 공통점은 인터페이스 종류보다 상태의 지속성과 검증 가능성이 더 중요해 보인다는 것이다. 디자인·CAD 작업은 여러 파일, 레이어, 렌더링, 스크린샷을 순서대로 보존해야 하고, 시스템 관리는 설치된 바이너리, PATH, 서비스, 로그 같은 내구성 있는 상태를 남긴다. streaming interaction과 human-in-the-loop 작업도 시간에 따라 들어온 관찰이나 사용자 응답을 다음 단계의 제약으로 계속 유지해야 한다. 이런 과제에서는 audit report가 다음 executor에게 전달할 압축된 사실 집합으로 기능할 여지가 크다.

OSWorld의 capability tag는 서로 배타적이지 않으므로 각 행의 과제 수를 합쳐 전체 108로 만들면 안 된다. streaming interaction 6개는 평균 점수가 0.000에서 0.500으로, human-in-the-loop 6개는 0.225에서 0.557로, tutorial following 22개는 0.157에서 0.374로 오른다. implicit state inference 43개, visual-spatial precision 45개, cross-source reasoning 46개도 각각 +0.125, +0.100, +0.098의 평균 점수 개선을 보인다. 큰 델타는 상징적 지시와 외부 상태를 bounded subtask로 바꾸기 쉬운 범주에 집중된다.

Terminal-Bench에서는 system-administration 27개가 0.593에서 0.889로 오르고 software-engineering 78개가 0.705에서 0.833으로 오른다. 설치, 서비스 설정, 빌드 출력, 저장소 이력, 비동기 취소 조건처럼 완료 기준이 여러 곳에 흩어진 작업은 한 번의 그럴듯한 명령열로 끝내기 어렵다. manager가 누락된 acceptance criterion을 남기고 auditor가 실제 파일과 테스트를 확인하면 거의 완성된 궤적의 마지막 차단 조건을 복구할 수 있다. hard 과제의 델타 +0.122가 medium의 +0.042보다 큰 결과도 긴 궤적에서 상태 관리의 한계효용이 커진다는 설명과 맞는다.

Table 7. 대표 과제 유형의 baseline, LongHorizon-Harness, 델타와 음의 범주

벤치마크·유형	n	Baseline	LH-Harness	Delta	단위·해석
WeaveBench DES	10	20.0%	80.0%	+60.0	PassRate %포인트
WeaveBench SPA	12	16.7%	66.7%	+50.0	PassRate %포인트
WeaveBench DSK	18	83.3%	88.9%	+5.6	PassRate %포인트
OSWorld streaming interaction	6	0.000	0.500	+0.500	평균 점수
OSWorld human in the loop	6	0.225	0.557	+0.332	평균 점수
OSWorld tutorial following	22	0.157	0.374	+0.217	평균 점수
OSWorld cross-source reasoning	46	0.263	0.361	+0.098	평균 점수
Terminal-Bench games	3	0.000	0.333	+0.333	성공률, +33.3%포인트
Terminal-Bench system-administration	27	0.593	0.889	+0.296	성공률, +29.6%포인트
Terminal-Bench scientific-computing	24	0.375	0.542	+0.167	성공률, +16.7%포인트
Terminal-Bench software-engineering	78	0.705	0.833	+0.128	성공률, +12.8%포인트
Terminal-Bench file-operations	15	0.333	0.333	0.000	변화 없음
Terminal-Bench model-training	12	0.750	0.667	-0.083	성공률, -8.3%포인트
Terminal-Bench data-science	24	0.792	0.667	-0.125	성공률, -12.5%포인트
Terminal-Bench mathematics	12	0.917	0.750	-0.167	성공률, -16.7%포인트
Terminal-Bench video-processing	3	0.333	0.000	-0.333	성공률, -33.3%포인트

6.4 음의 델타가 말하는 한계

LongHorizon-Harness는 모델에 없던 원시 능력을 새로 만들지 않는다. 수학적 추론, 데이터 과학의 평가 규약, 모델 학습의 숨은 임계값, 비디오의 시간 구간 정렬처럼 핵심 병목이 한 단계의 전문 능력에 있으면, auditor는 틀린 결과를 감지해도 올바른 해법을 공급할 수 없다. 더 나쁘게는 manager가 요구 조건을 잘못 해석하고 auditor가 관찰 가능한 대리 상태만 확인하면, 시스템은 틀린 계약을 여러 라운드에 걸쳐 일관되게 수행할 수 있다. Terminal-Bench의 mathematics, data-science, model-training, video-processing 회귀는 이 한계를 드러낸다.

OSWorld에서도 시각 요구를 파일, 코드, 메타데이터, 검색 결과처럼 권위 있는 상태로 환원할 수 있을 때 이득이 크다. 반면 CAD의 미세 좌표, 비디오 타임라인, 정교한 마우스 조작처럼 성공 조건이 순수하게 공간적·운동적으로 남으면 visual localization과 cursor control의 약점이 지속된다. cross-source reasoning은 자료를 이해하는 데 성공해도 최종 답을 잘못된 파일이나 UI 필드에 저장하면 실패할 수 있다. 따라서 정보 획득과 상태 carrier에 올바르게 커밋하는 능력을 별도로 평가해야 한다.

WeaveBench의 데스크톱 도메인은 PassRate가 83.3%에서 88.9%로 오르지만 부록의 평균 점수는 0.8671에서 0.8465로 -0.0205 감소한다. 이는 더 많은 과제를 0.8 통과선 위로 밀어 올리는 동시에, 일부 이미 강했던 궤적에서는 추가 검사와 수리가 세부 점수를 낮출 수 있음을 뜻한다. PassRate 상승만 보면 가려지는 분포 변화이므로 평균 점수와 과제별 결과를 함께 보아야 한다. 하네스는 실패 바닥을 높이는 데 강하지만 모든 상위 궤적을 보존한다고 보장되지는 않는다.

이 추가 분석의 가장 보수적인 결론은 ‘GUI보다 CLI가 낫다’거나 ‘auditor가 성능의 38.1%를 만든다’가 아니다. 더 적절한 결론은 완료 조건이 여러 단계에 걸쳐 지속되고 환경에서 독립적으로 확인될 수 있을수록, 명시적 task state와 감사된 전이가 유용해진다는 것이다. 반대로 핵심 정답이 숨은 평가 규약이나 모델의 단발 능력에 달려 있으면 구조화된 실행만으로는 부족하다. 실제 역할별 기여율을 확정하려면 동일 예산의 체계적 제거 실험이 후속 과제로 남는다.

7. 한계점 및 향후 연구 방향: 감사 가능한 상태에도 경계가 있다

LongHorizon-Harness의 핵심 성과는 긴 실행 기록을 더 오래 붙드는 데 있지 않고, 무엇이 완료되었는지를 환경에서 다시 확인해 명시적 상태로 남기는 데 있다. 그러나 감사 가능한 상태는 곧바로 객관적 진실을 뜻하지 않으며, 감사 도구가 관측할 수 있는 범위와 과업 계약의 해석이 정확하다는 전제 위에서만 유효하다. 따라서 이 논문의 수치를 읽을 때는 모델, 실행 백엔드, 도구 권한, 검증 표면을 하나의 시스템으로 보되 각 요소의 효과가 완전히 분리되지는 않았다는 점을 함께 기억해야 한다. 논문이 보여 준 것은 강한 가능성의 증거이지, 모든 장기 과업에 통용되는 완결된 인과 분해는 아니다.

7.1. OSWorld와 WeaveBench에서 성능 향상의 귀속 범위

OSWorld 2.0 전체 실험에서 LongHorizon-Harness는 Qwen 3.7-Plus의 완전 성공률을 2.8%에서 8.3%로, 부분 점수를 21.5%에서 35.2%로 높였다. 다만 제안 시스템은 GUI와 CLI를 함께 쓰는 하이브리드 도구 풀을 사용하고, 공식 비교 행은 주로 한 번에 하나의 GUI 행동을 허용하는 설정이므로 이 차이를 순수한 MEA 루프의 효과로만 돌릴 수 없다. 셸을 통한 파일·메타데이터·로그 검사는 시각적 상호작용보다 훨씬 강한 관측과 조작 수단이 될 수 있으며, 어떤 과업에서는 도구 표면 자체가 성공 가능성을 바꾼다. 그러므로 OSWorld 전체 결과는 시스템 수준의 우월성을 지지하지만, 역할 분리만의 인과 효과를 확정하는 통제 실험으로 읽어서는 안 된다.

WeaveBench의 공식 결과와 저자 실행 결과 사이에도 권한 차이가 있다. 공식 행은 일반 사용자 계정에서 수행된 반면 저자 실행은 과업 가상 머신 안에서 루트 권한을 사용했기 때문에, 공식 Claude Opus 4.7의 41.2%와 LongHorizon-Harness의 80.7%를 정면 비교하면 모델과 권한과 하네스가 함께 바뀐다. 반면 Qwen 3.7-Plus와 Claude Code를 공통으로 둔 51.8% 대 80.7% 비교는 같은 저자 실행 조건에서 이루어진 유효한 matched baseline이며 논문의 중심 주장에 더 적합하다. 독자는 가장 큰 숫자 차이보다 이 대응 비교를 우선해야 하고, 공식 행은 현재 생태계에서의 위치를 보여 주는 참고선으로 한정해야 한다.

7.2. 권위 있는 종결 조건이 없는 과업은 감사하기 어렵다

감사기는 파일 해시, XML 속성, 설치된 바이너리, 저장된 설정처럼 권위 있는 종결 상태가 존재할 때 가장 강하다. 반대로 화면에서 잠깐 나타나는 변화, 비디오의 특정 시점, 미세한 공간 정렬, 체감 품질, 평가기에만 숨겨진 임계값은 읽기 전용 검사만으로 닫기 어렵다. 부록에서도 OSWorld의 시각·공간 정밀도와 Terminal-Bench의 비디오 처리, 데이터 과학, 숨은 순위 의미론 같은 범주에 잔여 실패가 모인다고 보고한다. 이 경우 감사기는 실행자의 성급한 종료를 늦출 수는 있어도, 관측할 수 없는 정답 조건을 새로 만들어 주지는 못한다.

Figure 7: 멈춘 GUI 상호작용을 미해결 상태로 외부화한 WebRTC 사례

이 사례에서 베이스라인은 Wireshark의 응답 없는 대화상자를 알아차리고도 400단계 넘게 같은 상호작용을 반복해 0.59점에 머문다. LongHorizon-Harness는 실패 자체와 빠진 차트·패킷 증거를 상태에 기록하고, 다음 실행자가 미해결 항목만 수집하게 해 0.92점에 도달한다. 중요한 변화는 모델이 갑자기 네트워크 전문가가 된 데 있지 않고, 실패한 경로를 다음 문맥의 출발점으로 삼지 않았다는 데 있다. 다만 이 복구도 차트와 패킷처럼 후속 감사가 가능한 증거가 있었기에 성립한다.

이 경계는 실서비스 설계에서 더 중요하다. 예를 들어 화상 회의 품질이 실제로 좋아졌는지, 애니메이션이 정확한 시간에 전환됐는지, 사용자가 주관적으로 원하는 배치가 되었는지는 파일 하나로 판정하기 어렵다. 이런 과업에는 환경 센서, 이벤트 로그, 사용자 확인, 독립 평가기처럼 별도의 종결 권위를 계약에 포함해야 한다. 그렇지 않으면 시스템은 확인 가능한 대리 지표를 정교하게 관리하면서도 사용자가 원한 결과와 멀어질 수 있다.

7.3. 잘못 이해한 과업 계약도 정교하게 검증될 수 있다

MEA 루프는 주어진 계약을 충실하게 닫는 장치이지, 계약 해석이 옳다는 사실을 자동으로 보장하는 장치는 아니다. 관리자가 요구사항을 잘못 분해하면 실행자는 잘못된 하위 목표를 성실히 수행하고, 감사자는 그 하위 목표가 환경에 반영되었음을 정확히 확인할 수 있다. 이때 보고서는 근거가 풍부하고 상태 전이는 일관되지만 최종 과업은 틀린, 이른바 정교하게 검증된 오답이 된다. 부록이 숨은 임계값, 평가 관례, 여러 해석이 가능한 의미 조건에서 오히려 자신 있게 잘못된 답을 닫을 수 있다고 지적한 이유다.

이를 줄이려면 상태 레코드에 완료 여부만 두지 말고 요구사항의 출처, 해석 대안, 반증 조건, 평가기와의 연결 경로를 함께 보존해야 한다. 특히 원문 지시와 관리자가 만든 하위 계약 사이의 의미 대응을 매 라운드 검사하면, 실행 결과가 맞더라도 계약 자체가 빗나간 경우를 조기에 드러낼 수 있다. 모호성이 남으면 관리자가 임의로 하나를 고르기보다 ask 경로를 통해 사용자에게 확인하도록 해야 한다. 장기 실행의 신뢰성은 행동 검증에 더해 요구 해석의 계보를 추적할 때 비로소 닫힌다.

7.4. 역할 분리는 같은 백본을 써도 계산 비용이 크다

주 실험은 관리자, 실행자, 감사자에 같은 백본을 사용해 역할마다 더 강한 모델을 배치하는 교란을 줄였다. 그럼에도 세 역할을 순차 호출하고 실패 시 재계획하기 때문에 계산량은 작지 않으며, Qwen 3.7-Plus 기준 WeaveBench에서는 베이스라인의 2.3배 토큰, OSWorld에서는 3.6배 출력 토큰을 소비했다. 관리자의 비중은 벤치마크별 2.0~8.1%로 작지만 감사자는 19.4~38.1%를 차지해 독립 검증이 주된 추가 투자임을 보여 준다. 따라서 같은 모델을 썼다는 사실은 성능 귀속을 깨끗하게 만들 뿐, 역할 분리의 시간·토큰·지연 비용을 없애지는 않는다.

비용이 고정 배수로 증가하지 않는다는 점도 중요하다. Terminal-Bench 2.1에서는 성공률이 69.7%에서 77.2%로 오르면서도 전체 토큰이 24% 줄었고, WeaveBench 게임 하위집합에서도 Opus는 평균 토큰이 16.5M에서 11.1M으로 감소한 반면 Qwen은 10.7M에서 34.3M으로 늘었다. 강한 실행자가 계약을 빠르게 만족하면 감사와 복구가 낭비되는 탐색을 줄이지만, 약한 실행자는 같은 역할 구조 안에서 재시도 비용을 누적한다. 실전 배포에서는 평균 정확도만이 아니라 과업별 라운드 수, 감사 실패율, 복구당 추가 비용을 예산 정책에 연결해야 한다.

7.5. 읽기 전용 감사와 변이 감시는 여전히 신뢰 가정이다

논문은 감사자에게 읽기 전용 도구를 제공해 평가 과정이 환경을 바꾸지 않도록 설계한다. 그러나 실제 읽기 전용성은 프롬프트에 적힌 역할명보다 도구 권한, 운영체제 격리, API의 부작용, 파일 접근 방식으로 강제되어야 한다. 상태를 조회하는 명령도 캐시, 접근 시간, 애플리케이션 잠금, 자동 저장을 바꿀 수 있고, GUI를 열어 확인하는 행위가 세션 상태를 변경할 수도 있다. 따라서 감사 보고서를 신뢰하려면 감사 전후 스냅샷과 변이 모니터가 허용되지 않은 변경이 없었음을 독립적으로 증명해야 한다.

또한 감사자는 실행자와 같은 백본을 쓰므로 지식과 추론 편향을 상당 부분 공유한다. 문맥을 분리하면 실행자의 자기평가를 그대로 답습하는 위험은 줄지만, 동일한 과업 오해나 동일한 시각적 착각까지 독립적으로 사라지는 것은 아니다. 읽기 전용 도구가 올바르게 제한되었다는 가정과 감사자가 충분한 관측 표면을 받았다는 가정이 모두 깨지지 않아야 한다. 보안이나 금전 거래처럼 고위험 과업에서는 모델 역할 분리만으로 독립성을 선언하지 말고 권한 분리, 이종 검사기, 불변 로그를 함께 요구해야 한다.

7.6. 빠진 절제 실험과 오류 검출 지표

현재 결과는 전체 MEA 시스템과 기존 하네스를 비교하지만, 관리자만 추가했을 때, 새 문맥 실행만 적용했을 때, 감사만 붙였을 때, 감사 결과를 상태에 반영하지 않았을 때를 체계적으로 나누지 않는다. 그래서 외부 상태, 문맥 초기화, 독립 검증 가운데 어느 요소가 어느 과업군의 향상을 만들었는지 정량적으로 분해하기 어렵다. 사례 연구는 작동 메커니즘을 설득력 있게 보여 주지만 선택된 성공 사례만으로 구성 요소의 평균 기여를 추정할 수는 없다. 같은 도구 풀과 권한을 고정한 역할 절제 실험이 있어야 성능 향상과 비용 증가의 원인을 더 명확히 설명할 수 있다.

감사 품질 자체에 대한 정밀도와 재현율도 제공되지 않는다. 감사자가 실제 오류를 얼마나 자주 찾아냈는지, 올바른 결과를 잘못 거부한 비율은 얼마인지, 놓친 오류가 이후 상태를 얼마나 오염시켰는지를 알아야 검증 계층의 신뢰도를 판단할 수 있다. 최종 점수 상승은 감사가 유용하다는 간접 증거지만, 거짓 양성과 거짓 음성의 비용이 비대칭인 환경에서는 충분하지 않다. 오류 유형별 탐지 행렬과 감사 불일치 로그를 공개하면 하네스가 어디서 보수적이고 어디서 과신하는지 훨씬 선명해질 것이다.

Table 8. LongHorizon-Harness의 핵심 주장과 증거 경계, 그리고 이를 닫기 위한 후속 검증

주장	근거	남은 불확실성	후속 검증
명시적 감사 상태가 장기 과업 성공률을 높인다	동일한 Qwen 3.7-Plus와 Claude Code 비교에서 WeaveBench PassRate가 51.8%에서 80.7%로 상승	외부 상태, 새 문맥, 감사의 개별 기여가 분리되지 않음	같은 도구·권한·예산에서 manager, fresh context, auditor의 완전 요인 절제 실험
효과가 GUI를 넘어 일반 장기 실행에 확장된다	Terminal-Bench 2.1에서 69.7%에서 77.2%로 상승하고 토큰은 24% 감소	범주별 회귀와 실행자 능력에 따른 비용 분산이 큼	난이도와 과업 길이를 층화한 다중 시드 반복 및 라운드 생존 분석
OSWorld에서 완전 성공과 부분 진척이 함께 개선된다	전체 108개 과업에서 Binary 2.8%에서 8.3%, Partial 21.5%에서 35.2%로 상승	제안 시스템의 하이브리드 GUI+CLI와 공식 single-action GUI 도구 풀이 다름	동일한 GUI-only와 동일한 hybrid pool 각각에서 baseline과 MEA를 교차 비교
독립 감사가 성급한 완료 판정을 차단한다	WebRTC, 문서 스타일, VLOOKUP, Lighthouse의 대응 사례에서 누락 증거를 복구	감사의 오류 검출 정밀도·재현율과 사례 선택 편향이 보고되지 않음	전체 궤적에 오류 라벨을 부여하고 false accept와 false reject를 유형별 측정
읽기 전용 감사가 안전한 상태 전이를 만든다	감사 도구를 실행 도구와 분리하고 감사 보고서만 다음 라운드 상태에 반영	운영체제 수준의 비변이 보장과 조회 부작용 감시가 실험 결과에 드러나지 않음	감사 전후 파일시스템·프로세스·GUI 스냅샷 차분과 변이 방화벽 검증

표 8의 공통 메시지는 최종 점수만으로는 어떤 운영 가정이 성능을 지탱했는지 충분히 알 수 없다는 것이다. 이 논문은 matched Qwen 비교, 세 벤치마크, 두 백본, 토큰 분해, 대응 사례를 통해 상당히 넓은 근거를 제공했다. 다음 단계는 더 큰 숫자를 추가하는 것보다 도구와 권한을 고정하고 상태·문맥·감사의 기여를 분해하며, 감사 오류를 직접 라벨링하는 일이다. 그렇게 해야 LongHorizon-Harness가 좋은 사례를 넘어 재현 가능한 실행 계층의 설계 원리로 자리 잡을 수 있다.

7.7. 향후 연구는 감사 가능성의 설계까지 다뤄야 한다

첫 번째 방향은 과업을 받은 뒤 감사하는 데서 그치지 않고, 처음부터 감사 가능한 계약으로 변환하는 컴파일러를 만드는 것이다. 자연어 요구사항을 상태 변수, 허용된 변이, 관측 도구, 종결 조건, 사용자 확인 지점으로 변환하고 각 항목이 실제 환경에서 측정 가능한지 사전 점검할 수 있다. 측정 불가능한 조건은 대리 지표로 몰래 치환하지 말고 미해결 모호성으로 남겨야 한다. 이 과정은 관리자가 그럴듯한 하위 계약을 발명하는 위험을 줄이고 감사 실패가 실행 후반에야 발견되는 비용을 낮춘다.

두 번째 방향은 감사 강도를 과업 위험과 상태 불확실성에 맞춰 조절하는 것이다. 되돌릴 수 있는 저위험 편집은 단일 감사로 진행하되, 외부 전송·삭제·결제처럼 비가역적인 행동은 이종 감사자 합의와 사용자 승인을 요구할 수 있다. 감사자가 같은 결론을 반복하는 것보다 서로 다른 관측 표면을 사용해 반증을 시도하도록 배치하면 공유 편향도 줄어든다. 성공률과 토큰에 더해 잘못 승인된 변이의 기대 손실까지 목적 함수에 넣어야 실서비스에 맞는 비용·신뢰 균형을 찾을 수 있다.

8. 내 해석: 약점 하나와 후속 제안 하나

30대 AI 개발자이자 연구자인 내가 이 논문에서 가장 아쉽게 본 약점은 하네스 효과의 인과 귀속이 아직 충분히 닫히지 않았다는 점이다. WeaveBench의 matched Qwen 비교는 설득력이 있지만, OSWorld에서는 하이브리드 GUI+CLI와 공식 single-action GUI가 섞이고 전체 실험에는 역할별 절제가 없다. 그래서 현장에서 3배 가까운 개선 수치를 보고도 상태 외부화, 새 문맥, 독립 감사, 더 강한 도구 표면 중 무엇을 먼저 구현해야 할지 결정하기 어렵다. 시스템 전체가 좋다는 결론과 어떤 부품이 비용 대비 핵심인지 안다는 결론 사이에는 실무적으로 큰 간격이 있다.

내가 제안하고 싶은 후속 연구는 저자들이 열거한 일반적 확장 과제를 반복하는 대신, 감사 경계 counterfactual twin 실험을 만드는 것이다. 하나의 실제 궤적을 각 감사 직전 스냅샷에서 복제한 뒤 같은 백본·도구·권한·예산으로 검증된 상태, 실행자의 자기보고, 한 라운드 오래된 상태, 반증 증거를 의도적으로 섞은 상태를 무작위 배정하고 다음 하위 과업의 성공률을 비교한다. 이 설계는 전체 시스템을 다시 달리는 평균 점수보다 어떤 상태 정보가 다음 판단을 실제로 바꾸었는지 직접 측정하고, 감사 오류가 몇 라운드 뒤까지 전파되는지도 보여 준다. 내가 제품 팀에서 채택 여부를 결정한다면 이 결과로 감사 호출을 언제 생략하고 언제 강화할지 정책을 만들겠다.

9. 결론: 모델 능력을 끝까지 운반하는 실행 계층

LongHorizon-Harness가 제시한 가장 중요한 관점 전환은 장기 과업 실패를 모델의 기억력 부족만으로 설명하지 않는 데 있다. 모델은 한 라운드 안에서 충분히 좋은 코드를 쓰고 GUI를 조작하며 오류를 진단해도, 그 성과가 검증된 상태로 바뀌지 않으면 다음 라운드에 전달되지 않는다. 제안 시스템은 관리자에게 다음 상태 전이를 계약하게 하고, 실행자에게 현재 전이만 수행하게 하며, 감사자에게 실제 환경이 계약을 만족했는지 확인하게 한다. 이 구조에서 하네스는 모델보다 더 똑똑한 답을 발명하는 두뇌라기보다 이미 존재하는 국소 능력을 끝까지 운반하는 실행 계층이다.

9.1. 긴 문맥보다 검증된 상태가 더 오래 간다

기존 단일 궤적은 과거 행동, 추측, 실패, 임시 메모, 완료 주장을 같은 문맥에 쌓는다. 시간이 길어질수록 무엇이 환경에서 확인된 사실이고 무엇이 모델의 해석인지 경계가 흐려지며, 오래된 실패 경로가 다음 행동을 계속 끌어당긴다. LongHorizon-Harness는 실행 기록을 버리되 감사 보고서와 미해결 요구사항만 남겨 문맥 길이를 상태 정확도로 바꾼다. 이는 무조건 더 많이 기억하는 전략보다 앞으로의 의사결정에 필요한 검증된 최소 기억을 선별하는 전략이다.

이 때문에 새 문맥 실행자는 전체 역사를 복원할 필요가 없다. 현재 목표, 수용 기준, 경계 조건, 선행 증거가 계약에 들어오고, 실행자는 제한된 시간 안에 하나의 환경 전이를 만든다. 실패하더라도 감사 결과가 미완료 조건을 상태에 남기므로 다음 실행자는 실패한 사고 과정을 재연하지 않고 확인된 진행 지점에서 다시 시작한다. 장기 과업에서 필요한 연속성은 동일한 대화 세션의 지속보다 환경과 상태 레코드 사이의 일관된 대응에서 나온다.

9.2. 완료 주장을 환경 명제로 바꾸는 힘

Figure 8: 겉보기 완료와 의미적 완료를 구분한 문서 스타일 사례

문서 사례는 완료가 화면의 인상이나 실행자의 자신감보다 검사 가능한 환경 명제여야 함을 보여 준다. 베이스라인은 제목이 그럴듯하게 보이도록 XML을 직접 고치고 끝냈지만 지정된 LibreOffice 절차를 따르지 않아 0.00점을 받았다. LongHorizon-Harness는 GUI로 스타일을 적용하고 문서를 다시 확인한 뒤, 감사자가 XML에서 15개 제목의 실제 스타일을 검사해 0.89점을 얻었다. 시각적 결과, 요구된 절차, 내부 구조가 함께 맞을 때만 완료가 상태에 들어간다는 점이 핵심이다.

이 사례는 감사가 단순한 최종 채점을 넘어 다음 계획을 결정하는 제어 신호임을 보여 준다. 제목 몇 개가 틀렸다면 전체 문서를 처음부터 다시 만드는 대신 불일치한 요소만 새로운 계약으로 보낼 수 있고, 모두 맞으면 그 사실만 compact state에 남길 수 있다. 따라서 실행과 평가는 순차 파이프라인의 끝과 끝이 아니라 매 상태 전이에서 맞물리는 폐루프가 된다. 모델의 국소 성공이 최종 산출물로 누적되는 이유는 이 폐루프가 그 성공을 환경 증거로 변환하기 때문이다.

9.3. 에이전트 평가의 단위를 모델에서 운영 계약으로 넓히기

이 논문은 에이전트를 평가할 때 최종 정답만 볼 수 없다는 기존의 에이전틱 하네스 평가 관점을 구체화한다. 같은 백본이라도 어떤 도구를 호출했는지, 라운드별 timeout이 어떻게 적용됐는지, 근거가 어떤 경로로 보존됐는지, 완료 판정이 누가 했는지에 따라 성공률과 비용이 크게 달라진다. 특히 official row와 matched baseline을 구분해야 한다는 사실은 모델 이름만으로 표의 행을 동등하게 취급해서는 안 됨을 잘 보여 준다. 앞으로의 리더보드는 모델과 점수에 더해 도구 풀, 권한, 상태 스키마, 감사 정책, 예산을 함께 기록해야 한다.

동시에 이 연구는 장기 에이전트 벤치마킹이 오래 버틴 시간보다 상태 관리와 실패 복구를 측정해야 한다는 주장에 실험적 형태를 준다. 400단계 넘는 반복은 긴 실행이지만 좋은 장기 수행이 아니고, 검증된 진행을 보존해 다른 문맥에서 미해결 요구만 이어 가는 것이 실제 지속성에 가깝다. 따라서 평균 단계 수나 최대 context length는 보조 지표일 뿐이며, 오류가 상태에 들어오기 전 차단된 비율과 복구가 완료까지 이어진 비율이 더 직접적인 지표가 된다. LongHorizon-Harness는 장기성을 시간의 길이보다 감사 가능한 상태 전이의 연쇄로 재정의한다.

최종적으로 이 논문의 가치는 특정 프롬프트 템플릿보다 책임 경계를 분명히 한 데 있다. 관리자는 무엇을 만족해야 하는지 책임지고, 실행자는 제한된 변이를 만들며, 감사자는 환경 증거에 근거해 상태 편입 여부를 결정한다. 이 구분은 공유 백본 때문에 완전한 독립성을 보장하지는 않지만, 실패 위치를 관찰하고 복구 정책을 붙일 수 있는 인터페이스를 제공한다. 모델 성능이 계속 올라가더라도 이런 실행 계층이 없다면 국소 능력은 긴 과업의 끝까지 안정적으로 전달되지 않을 것이다.

10. 요약 정리: 핵심을 운영 계약으로 접기

• 문제 정의: 장기 과업의 병목은 단순한 context length보다 실행, 상태 관리, 자기평가가 한 문맥에 결합되어 오류와 목표 이탈이 누적되는 데 있다.
• 핵심 구조: 관리자는 감사된 상태에서 하나의 하위 계약을 만들고, 새 문맥 실행자는 제한된 변이를 수행하며, 읽기 전용 감사자는 환경 증거만으로 완료 여부를 판정한다.
• 주요 성과: matched Qwen 3.7-Plus 비교에서 WeaveBench PassRate는 51.8%에서 80.7%, Terminal-Bench 2.1은 69.7%에서 77.2%로 향상되었다.
• OSWorld 해석: 전체 과업에서 Binary 2.8%가 8.3%로, Partial 21.5%가 35.2%로 올랐지만 hybrid GUI+CLI와 official single-action GUI 차이 때문에 역할 분리만의 효과로 귀속할 수 없다.
• 작동 원리: 성공한 행동보다 검증된 사실을 기억하고, 실패 궤적 대신 미해결 요구를 다음 문맥에 전달해 반복·context rot·성급한 완료 판정을 줄인다.
• 비용 구조: 관리자는 토큰 비중이 작지만 감사자는 19.4~38.1%를 차지하며, 약한 실행자에서는 복구 라운드가 늘어 비용이 커지고 강한 실행자에서는 낭비 탐색을 줄일 수 있다.
• 신뢰 경계: 권위 있는 종결 상태가 없는 시각·시간·숨은 임계값 과업, 잘못 해석된 계약, 실제 read-only 보장과 변이 감시는 여전히 열린 문제다.
• 운영 계약: 모델·하네스·도구·권한·예산·감사 정책을 하나의 평가 단위로 기록하고, 역할 절제와 감사 오류 정밀도·재현율을 함께 측정해야 성능을 재현 가능하게 설명할 수 있다.