facts

상하이 AI 연구소(Shanghai Artificial Intelligence Laboratory)가 LLM 에이전트의 운영 체계인 '하네스(Harness)'를 스스로 개선하는 프레임워크 'Self-Harness'를 공개했다. 하네스는 시스템 프롬프트, 도구(Tools), 메모리, 검증 규칙, 런타임 정책, 오케스트레이션 로직, 실패 복구 절차 등 모델이 환경과 상호작용하는 데 필요한 주변 시스템 전체를 의미한다.

연구진은 일반적인 도구 기반 실행 능력을 측정하는 Terminal-Bench-2.0 벤치마크에서 Self-Harness의 성능을 검증했다. 테스트에는 MiniMax M2.5, Qwen3.5-35B-A3B, GLM-5 모델이 사용되었으며, 모든 모델은 DeepAgent SDK 기반의 최소 하네스(벤치마크용 시스템 프롬프트와 기본 파일 시스템 및 셸 도구만 포함)에서 시작했다.

검증 결과, Self-Harness를 통해 자동 수정된 하네스를 적용했을 때 홀드아웃(held-out) 작업에서 모델별로 33%에서 최대 60%의 상대적 성능 향상이 관찰됐다. 모델 백엔드, 도구 세트, 벤치마크 환경 및 평가 도구는 고정한 상태에서 오직 하네스 구성 요소만 변경하여 얻은 수치다.

how-it-works

Self-Harness는 인간 엔지니어의 직관이나 외부의 더 강력한 모델에 의존하지 않고, 에이전트가 자신의 실행 흔적(Execution Traces)을 분석해 규칙을 수정하는 3단계 반복 루프를 통해 작동한다.

첫 번째 단계는 '약점 마이닝(Weakness mining)'이다. 에이전트가 초기 하네스로 과제를 수행하며 생성한 실행 트레이스와 검증 가능한 결과물을 분석한다. 이 과정에서 실패한 트레이스를 분류하고, 해당 모델이 반복적으로 보이는 특이한 실패 패턴을 감지한다.

두 번째 단계는 '하네스 제안(Harness proposal)'이다. '제안자(Proposer)' 역할을 맡은 에이전트가 감지된 실패 메커니즘에 대응하는 최소한의 하네스 수정안을 생성한다. 이때 범용적인 수정을 지양하고 특정 실패 원인에만 대응하는 정밀한 수정안을 만드는 것이 핵심이다.

세 번째 단계는 '제안 검증(Proposal validation)'이다. 생성된 수정안을 회귀 테스트(Regression tests)에 통과시킨다. 새로운 수정안이 성능을 향상시키면서도 기존에 성공했던 작업에서 성능 저하를 일으키지 않는 경우에만 최종 하네스 버전으로 승격시킨다. 여러 수정안이 통과하면 이를 병합해 다음 반복 루프의 시작점으로 사용한다.

모델별로 적용된 구체적인 수정 사례는 다음과 같다.

- MiniMax M2.5: 데이터셋 설정을 무한히 탐색하며 타임아웃이 발생하는 문제를 해결하기 위해, 도구 호출 50회 이후 접근 방식을 강제로 변경하는 '루프 브레이커(Loop breaker)'를 런타임 정책에 추가했다.

- Qwen-3.5: 파일 덮어쓰기 오류 발생 시 동일 명령을 반복 수행해 파일을 삭제하는 패턴을 발견하고, 정확히 일치하는 중복 명령 수행을 금지하는 '명령 재시도 규율'과 파일 오류 시 즉시 아티팩트를 재생성하는 메커니즘을 도입했다.

- GLM-5: 셸 세션 간 PATH 변수가 유지되지 않아 발생하는 시간 낭비를 막기 위해 PATH 변수 지속 규칙을 추가하고, 종료 전 반드시 정상성 검사(Sanity check)를 수행하고 실패 시 이를 복구하도록 규칙을 설정했다.

implementation-impact

개발자와 실무자가 Self-Harness를 도입할 때 가장 중요하게 고려해야 할 점은 수동 엔지니어링 비용이 계산 리소스 비용으로 전환된다는 점이다. 기존의 하네스 튜닝이 엔지니어의 직관과 ad-hoc 디버깅에 의존했다면, 이 프레임워크는 경험적 증거 기반의 자동화된 시행착오 방식을 취한다.

이 과정에서 발생하는 구체적인 제약 사항은 다음과 같다. 우선 반복적인 제안 생성과 병렬 후보 평가, 회귀 테스트 과정에서 대량의 API 토큰이 소비된다. 또한 최적화 루프가 진행되는 동안 발생하는 지연시간(Latency)이 존재하며, 평가 작업을 수행하기 위한 별도의 인프라 환경이 구축되어야 한다.

결과적으로 실무자는 모델 자체의 파라미터를 튜닝하는 대신, 모델의 특이한 실패 패턴을 정의하고 이를 검증할 수 있는 테스트 셋을 정교하게 설계하는 방향으로 운영 전략을 수정해야 한다. 이는 특히 기업 내부 문서 스타일 변경과 같이 환경이 변해 에이전트가 갑자기 오작동하는 상황에서, 모호한 실패를 해결 가능한 기술적 문제로 전환해 빠르게 대응할 수 있는 운영 체계를 제공한다.