AI 에이전트가 스스로의 규칙을 다시 쓸 때: Self-Improving Harnesses(자기 개선형 하네스) 설명

AI 에이전트가 프로덕션 환경에서 실패할 때, 본능적으로 모델을 탓하게 됩니다. 하지만 대개 그것은 잘못된 곳을 보고 있는 것입니다.

에이전트의 행동은 기반이 되는 모델만큼이나 그 에이전트를 둘러싼 **하네스 (harness)**에 의해 결정됩니다. 즉, 시스템 프롬프트 (system prompt), 호출 가능한 도구 (tools), 메모리 (memory), 검증 규칙 (verification rules), 런타임 정책 (runtime policies), 그리고 실패 복구 로직 (failure-recovery logic) 등이 이에 해당합니다. SWE-agent, Claude Code, Codex, OpenHands는 모두 동일한 프런티어 모델 (frontier models)을 감싸고 있습니다. 신뢰할 수 있는 에이전트와 불안정한 에이전트를 가르는 차이는 대부분 이 주변 계층 (surrounding layer)에서 발생합니다.

문제는 이 계층이 거의 항상 수동으로 튜닝된다는 점입니다. 엔지니어가 몇 가지 실패 사례를 관찰하고, 직감을 형성하며, 프롬프트나 규칙을 수정하고, 요행을 바라는 식입니다. Shanghai AI Laboratory의 Hangfan Zhang(arXiv:2606.09498의 새로운 Self-Harness 논문 주저자)이 언급했듯이, 더 깊은 문제는 이 패러다임이 "종종 체계적인 피드백 루프 (feedback loop)가 부족하다"는 점입니다. 몇 주마다 새로운 모델이 출시되는 상황에서, 모델별로 특화된 하네스를 수동으로 튜닝하는 것은 아무도 따라갈 수 없는 러닝머신과 같습니다.

아이디어: 에이전트가 스스로의 하네스를 수정하게 하라

Self-Harness는 모델의 가중치 (weights)를 동결한 상태로 유지하며, 에이전트 자체의 실행 트레이스 (execution traces) 증거를 통해 하네스를 개선합니다. 재학습 (retraining)이 필요 없으며, 이를 감독하기 위해 더 큰 외부 모델에 의존하지도 않습니다. 이는 다음과 같은 3단계 루프로 작동합니다:

1. 약점 채굴 (Weakness mining) — 검증 가능한 결과가 나오는 일련의 작업들을 실행한 후, 실패한 트레이스를 분류하여 모델 특화적인 실패 패턴을 찾아냅니다.
2. 하네스 제안 (Harness proposal) — "제안자 (proposer)" 역할이 각 실패 패턴을 해당 특정 메커니즘과 연결된 작고 정밀한 수정 사항으로 변환합니다. 과도한 수정을 피하기 위해 의도적으로 최소한의 수정만을 수행합니다.
3. 제안 검증 (Proposal validation) — 각 후보 수정 사항은 회귀 테스트 (regression tests)를 거치며, 별도의 테스트 데이터셋 (held-out tasks)에서 측정 가능한 성능 저하 없이 성능을 향상시키는 경우에만 승격됩니다. 통과된 수정 사항은 다음 하네스 버전으로 병합되어 다음 라운드의 씨앗이 됩니다.

수락 게이트 (acceptance gate)가 핵심입니다: 데이터로 증명된, 회귀 없는 개선.

결과

MiniMax M2.5, Qwen3.5-35B-A3B, 그리고 GLM-5를 대상으로 Terminal-Bench-2.0(일반적인 도구 사용: 아티팩트 관리 (artifact management), 명령 사용 (command use), 검증 (verification), 오류 복구 (error recovery))에서 테스트를 진행했습니다. 하네스 (harness)를 제외한 모든 요소를 고정했을 때, 홀드아웃 성능 (held-out performance)이 상대적 수치로 **33%에서 60%**까지 상승했습니다. Qwen3.5-35B-A3B의 경우 23.8%에서 38.1%로 향상되었습니다.

이것이 단순한 벤치마크 수치 그 이상인 이유는 무엇이 변했는가 하는 점입니다. 수정 사항은 "프롬프트를 더 길게 만드세요"와 같은 식이 아니라, 구체적이고 읽기 쉬운 형태였습니다:

• MiniMax M2.5는 타임아웃이 발생하여 아무것도 제출하지 못할 때까지 데이터셋 설정 (dataset configs)을 계속 탐색했습니다. Self-Harness는 런타임 정책 (runtime policy)에 "루프 중단기 (loop breaker)"(50번의 도구 호출 후 중단 및 재지정)를 작성했으며, 필요한 모든 아티팩트 (artifact)의 초기 버전을 조기에 생성하는 규칙을 추가했습니다.
• Qwen3.5는 파일 덮어쓰기 오류가 발생하면 동일한 명령을 맹목적으로 재시도하다가 결국 혼란 속에서 파일을 삭제하곤 했습니다. 해결책은 엄격한 명령 재시도 규율 (command-retry discipline)—정확히 중복되는 명령 금지—을 적용하는 것이었습니다.

이것들은 숙련된 엔지니어가 추가할 법한 규칙들이며, 자동으로 발견되고 검증되었습니다.

이것이 벤치마크를 넘어 중요한 이유

실제 워크플로 (workflows)에 에이전트를 배포한다면, 세 가지 시사점이 두드러집니다:

• 모델 업그레이드가 재작업이 되지 않습니다. 더 저렴하고 빠른 모델로 교체하는 것은 대개 하네스를 수동으로 다시 튜닝해야 함을 의미합니다. 자기 하네싱 (self-harnessing) 루프는 새로운 모델의 실패 모드 (failure modes)를 자동으로 재발견합니다.
• 더 저렴한 모델이 신뢰성의 임계점을 넘습니다. 어려운 작업에서 60%의 상대적 성능 향상은 더 작은 모델을 "프로덕션에 사용하기에 충분한" 수준으로 끌어올릴 수 있습니다.
• 디버깅이 경험적 (empirical)이 됩니다. "에이전트가 고장 난 것 같다"와 같은 모호한 실패가 객관적인 수락/거절 게이트 (accept/reject gate)를 가진 테스트 가능한 수정 사항으로 변합니다.

전제 조건은 솔직하게 말해, 이 방식은 성공 여부를 기계가 확인할 수 있는 (machine-checkable) 작업에서만 작동한다는 것입니다. 루프가 하네스를 수정하도록 허용하기 전에, 객관적인 통과/실패 신호가 있는 실제 사례의 벤치마크인 평가 체계 (evaluation)를 먼저 구축하십시오. 그것 없이는 "자기 개선 (self-improving)"은 그저 말뿐인 단어에 불과합니다.

이 글은 배포된 복사본입니다. 부동산 및 프롭테크 (PropTech) 관점을 담은 원문은 VSBD 블로그에서 확인하실 수 있습니다. 논문: arXiv:2606.09498.