Self-Harness: LLM 에이전트가 스스로 실행 환경을 개선하는 프레임워크
목차
개요
언어 모델 에이전트의 성능은 모델 파라미터뿐만 아니라 에이전트를 둘러싼 실행 환경, 즉 하네스(harness)에 의해 크게 좌우된다. 하네스는 시스템 프롬프트, 도구 목록, 메모리 관리 방식, 런타임 제어 정책 등을 포함하는 비파라메트릭(non-parametric) 구성 요소 전체를 가리킨다. 기존에는 이 하네스를 사람이 직접 설계하거나, 더 강력한 외부 모델이 최적화하는 방식이 일반적이었다.
이 논문은 Self-Harness라는 프레임워크를 제안한다. Self-Harness는 에이전트 자신이 실패 실행 추적(execution trace)을 분석하고, 하네스 수정 후보를 생성하며, 회귀 테스트를 통해 유효한 변경만 수락하는 반복 루프를 통해 스스로 하네스를 개선한다. 인간 엔지니어링이나 외부 강력 모델 없이 모델 고유의 실패 패턴에 맞춘 개선을 자율적으로 수행한다는 점이 핵심이다.
논문은 MiniMax M2.5, Qwen3.5-35B-A3B, GLM-5 세 모델에 대해 Terminal-Bench-2.0 벤치마크(64개 태스크 부분집합)를 사용해 검증하였으며, held-out 통과율이 각각 40.5% → 61.9%, 23.8% → 38.1%, 42.9% → 57.1%로 향상되었다.
방법론
Self-Harness는 T 라운드 반복 루프(Algorithm 1)로 구성된다. 각 라운드 t에서 수행되는 단계는 다음과 같다.
- 현재 하네스 h_t 하에서 모델 M을 held-in 분할 D_in과 held-out 분할 D_ho 모두에 적용해 성능을 평가한다.
- 실패 실행 추적을 클러스터링하여 반복적 실패 패턴(Weakness Mining)을 식별한다.
- 식별된 실패 패턴에 근거한 K개의 다양한 하네스 수정 후보(Harness Proposal)를 생성한다.
- 각 후보를 회귀 테스트로 검증하고, 수락 기준을 충족하는 후보만 병합한다.
- T 라운드 후 최종 하네스 계보(harness lineage)를 반환한다.
고정된 요소는 모델 파라미터, 평가자(evaluator), 벤치마크 환경, 태스크 분할이다. 수정 가능한 요소는 하네스 정의 파일 내 선언된 구성 지점(instructions, tools, verification guidance, runtime control policies)으로 제한된다.
하네스(Harness)의 구성 요소
하네스는 에이전트 배포를 지배하는 비파라메트릭 스캐폴딩(scaffolding) 전체를 포함한다.
| 구성 요소 | 설명 |
|---|---|
| 시스템 프롬프트 및 지시사항 | 부트스트랩, 실행, 검증, 실패 복구 지침 |
| 도구 | 파일 시스템 조작, 쉘 실행 등 |
| 메모리 및 상태 관리 메커니즘 | 에이전트 실행 중 상태 유지 방식 |
| 런타임 제어 정책 | 도구 메시지 횟수 상한 등 |
| 검증 규칙 및 권한 정책 | 결과물 검증 기준 |
| 런타임 어댑터 및 메커니즘 | 모델-환경 상호작용 매개 요소 |
초기 하네스는 최소한의 “Terminal Bench 2 Harbor” 시스템 프롬프트와 기본 DeepAgent 도구로 구성된다. DeepAgent는 기본 파일 시스템 및 쉘 도구를 제공하는 SDK이며, Self-Harness는 DeepAgent 인스턴스화를 구성하는 하네스 정의 파일만 수정할 수 있다.
Weakness Mining: 실패 패턴 분석
Weakness Mining은 행동 실패를 구조화된 증거로 변환하는 단계다.
실행 추적은 결과 레코드로 정리된다. r_i = (x_i, τ_i, y_i, z_i) 형태이며, z_i = ℰ(x_i, τ_i, y_i)는 평가자 결과다. 실패 레코드 집합은 F_t = {r_i ∈ R_t | z_i = fail}로 추출한다.
각 실패에는 실패 서명(failure signature)이 부여된다. φ(r_i) = (c_i, q_i, m_i) 형태이며, 각 요소는 다음을 의미한다.
- c_i: 검증자 수준의 terminal 원인
- q_i: 에이전트 행동의 인과적 상태
- m_i: 노출된 추상 에이전트 메커니즘
동일 서명을 공유하는 레코드가 클러스터링된다. C_φ = {r_i ∈ F_t | φ(r_i) = φ}
클러스터는 지지도(cluster size)와 추정 실행 가능성(actionability) 기준으로 정렬되어, 제안 단계에서 가장 가치 있는 수정을 우선 처리하도록 유도한다. 구조화된 실패 패턴에는 클러스터 크기, 대표 인스턴스, 공유 증상, 검증자 증거, 추론된 메커니즘이 포함된다.
Harness Proposal: 수정 후보 생성
제안 단계는 K개의 상호 구별되는 후보를 생성한다. P_t = {(Δ_j, a_j)}^K_{j=1}
각 편집 Δ_j는 현재 하네스를 후보 하네스로 변환한다. h_t(j) = Δ_j(h_t)
각 후보에는 감사 레코드 a_j가 포함되며, 대상 실패 패턴, 편집된 구성 요소, 예상 효과, 회귀 리스크를 기술한다. 제안자는 다음 원칙을 따른다.
- 증거에 의해 지지되고 하네스 개입이 가능한 실패 패턴만 선택한다.
- 좁은 프로토콜 변경으로 완화 가능한 구체적이고 반복적인 메커니즘을 우선한다.
- 브랜치 간 다양성을 장려하고, 각 브랜치 내에서는 최소성(minimality)을 강제한다.
Proposal Validation: 검증 및 수락 기준
후보 h_t(j) = Δ_j(h_t)에 대해 분할별 개선도를 계산한다.
Δ_in(j) = P_in(h_t(j)) − P_in(h_t)
Δ_ho(j) = P_ho(h_t(j)) − P_ho(h_t)
수락 조건은 다음 세 가지를 동시에 충족해야 한다.
- Δ_in(j) ≥ 0 (held-in 성능 저하 없음)
- Δ_ho(j) ≥ 0 (held-out 성능 저하 없음)
- max(Δ_in(j), Δ_ho(j)) > 0 (최소 한 분할에서 실질적 개선)
이 보수적인 게이트는 한 분할에서의 이득을 다른 분할의 손실로 맞바꾸는 후보를 거부한다. 수락된 후보는 현재 하네스에 병합되고, 거부된 후보는 로그에만 기록되며 활성 하네스에는 반영되지 않는다. 각 후보 하네스 평가는 2회 반복 시도로 이루어지며, 태스크당 단일 시도 성공률(Pass %)이 기본 지표다.
주요 결과
Terminal-Bench-2.0 성능 비교
Terminal-Bench-2.0은 89개의 컨테이너화된 터미널 태스크로 구성된 벤치마크다. Self-Harness 평가에는 불안정한 외부 웹 리소스 의존 태스크나 멀티모달 입력을 요구하는 태스크를 제외한 64개 부분집합이 사용되었다. 태스크는 아티팩트 관리, 명령어 사용, 검증 행동, 실행 오류로부터의 복구를 테스트한다.
아래는 세 모델의 held-in 및 held-out 초기 대비 최종 통과율 비교다.
| 모델 | Held-In 초기 | Held-In 최종 | Held-Out 초기 | Held-Out 최종 | Held-Out 절대 향상 | Held-Out 상대 향상 |
|---|---|---|---|---|---|---|
| MiniMax M2.5 | 43.0% | 50.0% | 40.5% | 61.9% | +21.4pt | +53% |
| Qwen3.5-35B-A3B | 15.1% | 36.0% | 23.8% | 38.1% | +14.3pt | +60% |
| GLM-5 | 47.7% | 57.0% | 42.9% | 57.1% | +14.2pt | +33% |
held-out 분할에서 MiniMax M2.5가 +21.4 포인트(+53%), Qwen3.5-35B-A3B가 +14.3 포인트(+60%), GLM-5가 +14.2 포인트(+33%) 향상을 달성했다. held-in 분할에서도 세 모델 모두 유의미한 향상이 확인되었다.
모델별 발견된 하네스 개선 내용
Self-Harness가 각 모델에서 발견·채택한 개선 사항은 모델 고유의 실패 패턴을 직접 반영한다.
MiniMax M2.5(40.5% → 61.9%)에서는 다음 변경이 채택되었다.
- 필수 출력 아티팩트를 더 이른 단계에 생성하도록 변경
- 구조화된 도구 출력을 더 세밀하게 처리
- 장시간 지속되는 도구 사용 루프 이후 실행 방향 전환
max_total_tool_messages런타임 상한 추가
Qwen3.5-35B-A3B(23.8% → 38.1%)에서는 다음 변경이 채택되었다.
- 의존성 사전 점검(dependency prechecking) 강조
- 반복 실패 명령 회피
- 무한 탐색 루프 탈출
- 도구 오류 발생 시 아티팩트 복구 미들웨어 추가
- 재시도 규율(retry discipline) 제약 구현
GLM-5(42.9% → 57.1%)에서는 다음 변경이 채택되었다.
- 쉘 명령 간 환경 설정 유지
- 장기 탐색에서 구현 및 테스트 단계로의 전환 촉진
- 환경 수정 후 도구 접근 가능성 검증
- 단일 대규모 다운로드 대신 단계적이고 범위가 한정된 작업 구현
세 모델 모두 아티팩트 신뢰성 향상이라는 공통 방향으로 이익을 얻었으나, 각 모델이 실패하는 구체적 메커니즘이 달라 채택된 변경 내용도 상이하다. 채택된 하네스 변경은 범용적 지시 추가가 아닌 특정 실패 메커니즘에 직접 대응하는 “작고 감사 가능한 구성 변경(small, auditable changes)”이며, held-in 증거를 넘어 미관측 태스크로도 일반화된다.
한계와 주의사항
Self-Harness에는 다음과 같은 한계가 존재한다.
첫째, 개방형 무제한 개선이 아닌 경계가 있는 편집(bounded edits)과 고정된 벤치마크 내에서만 동작한다. 벤치마크 범위를 벗어난 개선으로 일반화될 수 있는지는 검증되지 않았다.
둘째, 수락된 편집이 벤치마크 특정 패턴을 반영할 수 있다. 64개 태스크 부분집합으로 최적화된 하네스가 다른 분포의 태스크에서도 동일하게 유효하다는 보장이 없다.
셋째, 프레임워크 성능은 평가자(verifier) 품질과 추적 충실도(trace fidelity)에 의존한다. 평가자가 불정확하거나 추적 데이터가 충분하지 않으면 Weakness Mining의 신뢰도가 저하된다.
넷째, 논문은 공식적인 절제 연구(ablation studies)를 제공하지 않는다. Weakness Mining, 제안 제약, 검증 게이트 각 구성 요소의 기여도를 분리하는 통제 실험이 없어, 각 단계의 독립적 효과를 정량적으로 파악하기 어렵다.
다섯째, 분석은 주로 정성적 수준에서 이루어진다. 세 모델에 대한 진화 궤적과 보존된 코드 수준 편집 검토에 그치며, 광범위한 통계적 유의성 검증이 부족하다.
결론
Self-Harness는 LLM 에이전트가 외부 개입 없이 자신의 실행 환경을 스스로 개선하는 최초의 체계적 프레임워크 중 하나다. Weakness Mining → Harness Proposal → Proposal Validation의 세 단계 반복 루프를 통해 모델 고유의 실패 패턴을 식별하고, 이에 대응하는 최소한의 하네스 수정을 자율적으로 수락한다.
Terminal-Bench-2.0에서 MiniMax M2.5, Qwen3.5-35B-A3B, GLM-5 세 모델 모두 held-out 통과율에서 14 포인트 이상의 향상을 기록하였다. 채택된 변경은 모델별로 상이하며, 각각의 구체적 실패 메커니즘을 직접 겨냥한 “작고 감사 가능한” 구성 변경임을 확인하였다.
이 연구는 하네스 설계를 인간 엔지니어링의 전유물로 보는 관점에서 벗어나, 에이전트 자신이 자신의 실행 환경 구성에 참여할 수 있음을 보여준다. 향후 연구에서는 더 넓은 벤치마크 범위로의 일반화, 절제 연구를 통한 구성 요소별 기여 분석, 그리고 장기 반복에서의 안정성 검증이 필요하다.