에이전트 하네스를 컨텍스트가 아니라 코드로 키우는 실패 기반 학습법

무엇인가

이 논문이 다루는 문제는 LLM 에이전트가 같은 작업군(task family)의 과제를 연속해서 처리할 때, 표준적인 하네스가 매 과제의 컨텍스트 안에서 동일한 제어 결정을 모델에게 반복적으로 재구성하게 만든다는 점이다. 목표와 관측은 과제마다 달라지지만 질의를 다듬고, 관측을 필터링하고, 진행을 검증하고, 오류에서 복구하고, 언제 멈출지 정하는 주변 제어는 반복된다. 이런 위임을 되풀이하면 결정마다 추론 호출이 하나씩 늘고, 프롬프트와 관측, 출력이 실행 이력에 계속 쌓여 컨텍스트가 커진다. 저자들의 질문은 과제 피드백이 이 반복 제어를 재사용 가능한 실행 코드로 바꿔줄 수 있는지, 그리고 LLM 호출은 과제별 의미 추론에 남겨둘 수 있는지다.

어떻게 동작하나

제안 방법인 Growing Harness는 전략 없는 스캐폴드(strategy-free scaffold)에서 출발한다. 이 스캐폴드는 과제 진입점과 고정된 LLM·도구 인터페이스만 노출하고, ReAct식 도구 호출 루프 같은 과제 해결 컨트롤러는 전혀 담지 않는다. 학습 대상은 하네스 코드 h뿐이며 모델 M과 도구 T는 고정된다. 각 과제 실행마다 함수 호출, LLM·도구 호출, 반환, 런타임 오류를 노드로 하는 함수 단위 실행 DAG를 기록하고, 이를 τ_i = (x_i, G_i, y_i, o_i, u_i) 형태의 트레이스로 남긴다. 여기서 o_i는 성공 여부, u_i는 토큰·비용·실행시간 측정값이다. 실패가 발생하면 그 트레이스에서 호출된 하네스 함수 집합 F(τ_i)를 추출해, 최적화기가 손댈 수 있는 코드 표면을 그 함수들로 제한한다.

무엇과 다른가

학습은 현재 실패들을 담는 유한한 윈도우 W_t를 유지하는 실패 윈도우 커리큘럼으로 진행된다. 이미 푼 과제는 커리큘럼에서 빠지고, 미해결 과제는 갱신된 트레이스와 시도 횟수를 달고 남으며, 시도 횟수가 R_max에 도달하면 은퇴한다. 최적화기는 윈도우 안의 실패들을 한꺼번에 수리하도록 요구받는데, 이는 여러 실패에 공통으로 나타나는 재사용 가능한 동작을 유도하기 위해서다. 편집 범위는 진입 함수 main과 트레이스에 등장한 함수들로 제한되고, 수정·신규 도입 함수 수가 편집 예산 L을 넘을 수 없으며, 함수 시그니처와 런타임 인터페이스는 보존해야 하고 과제 식별자나 정답, 고정 해법을 코드에 넣는 것도 금지된다. 파싱, 검증, 상태 갱신, 조건부 질의 개선, 오류 복구, 정지 판단 같은 결정적이고 재사용 가능한 제어는 코드로, 의미 해석과 합성, 모호한 비교, 답 생성은 LLM 호출로 남기도록 방향을 잡는다. 수리된 후보는 활성 윈도우 전체에서 재실행되고, 통과한 편집은 하나의 공유 하네스에 누적된다.

어떻게 쓰나

회귀를 막는 장치가 성공 우선(success-first) 홀드아웃 게이트다. 별도로 떼어둔 게이트 검증 집합 G에서 현재 하네스의 성공률이 마지막으로 수용된 체크포인트보다 낮으면, 이전 게이트 이후의 수리 시퀀스 전체를 롤백한다. 롤백은 코드뿐 아니라 과제 커서, 실패 윈도우, 카운터, 학습 기록까지 되돌려 거부된 시퀀스가 시작되던 상태를 그대로 복원한다. 규칙은 성공 우선이어서 온라인 비용이 낮다는 이유로 게이트 성공률 하락을 상쇄할 수 없다. 학습 스트림과 윈도우가 소진된 뒤에도 마지막 체크포인트 이후의 변경분에 대해 최종 게이트 평가를 한 번 더 수행하고, 게이트 성공률이 더 낮으면 최신 수용 체크포인트를 복원한 뒤 최종 평가 집합 D_te에서 단 한 번 평가한다.

전제와 한계

실험은 BrowseComp-Plus(고정된 인간 검증 검색 코퍼스 기반 심층 검색 벤치마크)와 WebArena-Verified(수정된 과제와 결정적 평가기를 갖춘 다단계 웹 에이전트 벤치마크)에서 수행됐다. 각 벤치마크마다 학습 200개, 홀드아웃 게이트 50개, 최종 평가 50개 과제를 쓴다. 배포 모델은 gpt-oss-120b, gpt-oss-20b, Qwen3.5-4B 세 가지다. 비교 대상은 고정된 비학습 에이전트인 Tool-Calling이며, BrowseComp-Plus에는 IRCoT와 Self-Ask를, WebArena-Verified에는 WebDreamer와 AgentOccam을 각각 맞춰 적용했다. 모든 방법이 배포 LLM, 과제 분할, 도구, 평가 프로토콜을 공유하고, 방법-모델 조합마다 3회 독립 실행해 최종 평가 과제당 단일 시도 롤아웃을 수행하며, 최선 시도를 고르지 않고 평균을 낸다. 불확실성은 과제 단위 클러스터 부트스트랩 10,000회, 시드 42로 추정한다.

결과는 여섯 개 벤치마크-모델 조합 중 다섯 개에서 Growing Harness가 최고 평균 성공률을 기록했고, 나머지 한 조합에서는 최고 평균에 0.7pp 못 미쳤다. Tool-Calling 대비 LLM 호출은 76.0~91.8% 줄었고 온라인 비용은 74.4~98.6% 감소했다. 호출을 훨씬 적게 쓰면서도 여섯 개 중 다섯 개 설정에서 Tool-Calling보다 평균 성공률이 높았고, 나머지 하나에서도 0.7pp 이내를 유지했다. WebArena-Verified에서 성공률은 세 모델 규모에 걸쳐 44.7~45.3%의 좁은 범위에 머무른 반면, Tool-Calling은 gpt-oss-120b에서 30.0%였던 것이 Qwen3.5-4B에서는 6.7%로 떨어졌다. 즉 가장 작은 배포 모델에서 이득이 가장 크게 나타났다. 절제 실험은 BrowseComp-Plus, 배포 모델 gpt-oss-20b, 최적화기 GPT-5.6-terra(High), 10회 최적화 스텝, 동일한 50과제 최종 평가 집합에서 수행됐다. 함수 단위 지도를 제거하면 최종 성공률이 36%에서 18%로 반토막 났고, 게이트 검증을 끄면 게이트 성공률이 30%까지 오른 뒤 16%로 떨어졌으며, 실패 윈도우를 K=1로 줄이면 최종 성공률이 8pp 낮아졌다. 수렴 분석에서는 두 하네스가 같은 전략 없는 시드 프로그램에서 출발했음에도 BrowseComp-Plus 쪽은 질의 생성, 증거 수집·압축, 답 검증을 모든 과제가 재사용하는 단일 검색·검증 파이프라인으로 자랐고, WebArena-Verified 쪽은 일반적인 LLM 유도 브라우저 루프 주위에 Shopping, Reddit, Map용 특화 핸들러를 추가하는 형태로 자랐다.

개발자 관점에서 이 논문이 주는 실무적 시사점은 명확하다. 같은 작업군을 반복 처리하는 에이전트를 운영한다면, 반복 제어를 매 실행마다 모델 컨텍스트에서 재생성하는 대신 하네스 코드로 옮겨 저렴한 코드 경로로 실행하고, 모델 호출은 과제별 증거 해석과 의미 판단에만 쓰는 구조를 검토할 수 있다. 특히 소형 모델을 모바일이나 자원 제약 환경에 배포하는 팀에게는 모델 스케일과 온라인 추론이 제한된 상황에서도 성공률을 유지하는 경로가 될 수 있다. 다만 도입 전에 확인할 것은 학습된 하네스를 충분히 재사용해 오프라인 최적화 비용을 상쇄할 수 있는지, 그리고 생성된 코드를 어떤 샌드박스와 권한 경계 안에서 실행할지다.

저자들이 밝힌 전제와 한계도 분명하다. 이 방법의 가치는 학습된 하네스를 재사용하는 정도가 오프라인 최적화 비용을 상쇄할 만큼 커야 한다는 조건에 달려 있다. 또한 실제 배포에는 샌드박싱, 명시적 권한 경계, 생성된 코드의 검증이 필요하다고 명시한다. 비용 계산은 배포 에이전트의 LLM 호출만 포함하고 평가자와 오프라인 최적화기 호출은 제외하며, 캐시 재사용은 같은 과제 내 이전 요청과 공유하는 최장 프리픽스만 가정하고 과제 간 캐시 재사용은 가정하지 않는다. 두 벤치마크가 서로 다른 학습 설정을 사용하므로, 단일 파이프라인 대 특화 핸들러라는 대비는 이 실행들에 대한 서술일 뿐 난이도 비교가 아니라고 저자들은 못박는다.