[논문 리뷰] HarnessX — 에이전트 하네스를 실행 트레이스로 진화시키기

AI 에이전트를 만들다 보면 금방 깨닫게 되는 사실이 있다. 성능은 모델만으로 결정되지 않는다. 같은 LLM을 써도 어떤 프롬프트를 주는지, 어떤 도구를 붙이는지, 메모리를 어떻게 관리하는지, 실패했을 때 어떤 루프로 되돌리는지에 따라 결과가 크게 달라진다.

말하자면 모델은 요리사이고, 에이전트 하네스는 주방이다. 아무리 뛰어난 요리사라도 칼이 무디고 재료 위치가 뒤죽박죽이면 실력을 내기 어렵다. 반대로 잘 정돈된 주방에서는 평범한 요리사도 꽤 괜찮은 결과를 낸다.

Xiaomi 연구진의 HarnessX는 바로 이 주방, 즉 에이전트를 감싸는 실행 환경을 연구 대상으로 삼는다. 논문의 핵심 질문은 단순하지만 중요하다.

모델을 더 크게 만들지 않고도, 모델 주변의 실행 인터페이스를 자동으로 개선하면 에이전트 성능을 끌어올릴 수 있을까?

논문의 답은 “그렇다”에 가깝다. HarnessX는 ALFWorld, GAIA, WebShop, τ³-Bench, SWE-bench Verified 다섯 개 벤치마크에서 평균 +14.5%, 최대 **+44.0%**의 성능 향상을 보고한다. 특히 베이스라인 성능이 낮은 작은 모델일수록 하네스 개선의 효과가 컸다.

이 결과는 꽤 중요한 메시지를 던진다. 에이전트의 발전은 반드시 모델 스케일링에서만 오지 않는다. 모델 바깥의 실행 구조, 즉 하네스도 독립적인 최적화 대상이 될 수 있다.

하네스란 무엇인가

논문에서 말하는 하네스는 에이전트가 “어떻게 관측하고, 추론하고, 행동하는지”를 매개하는 런타임 구조다. 구체적으로는 다음 요소들이 포함된다.

• 프롬프트와 컨텍스트 구성 방식
• 도구 호출 인터페이스
• 메모리 관리
• 샌드박스와 실행 환경
• 평가자와 보상 신호
• 제어 흐름과 안전 장치
• 트레이싱과 관찰 가능성
• 학습 데이터로 이어지는 브리지

우리가 흔히 “에이전트 프레임워크”라고 부르는 것들이 대체로 이 영역에 걸쳐 있다. LangChain, LlamaIndex, LangGraph, AutoGen, CrewAI 같은 도구들은 프롬프트, 도구, 메모리, 워크플로우를 엮는 방법을 제공한다. Claude Code나 Cursor 같은 제품형 에이전트도 강력한 하네스를 내장하고 있다.

문제는 대부분의 하네스가 여전히 사람이 손으로 짜는 정적 구조라는 점이다. 모델이 바뀌거나, 도구가 바뀌거나, 태스크 분포가 바뀌면 다시 튜닝해야 한다. 실행 중에 쌓이는 풍부한 트레이스는 대부분 로그로만 남고, 하네스를 체계적으로 개선하는 데 쓰이지 않는다.

HarnessX는 이 지점을 바꾼다. 하네스를 코드 속에 묻힌 관습이 아니라, 직렬화하고 비교하고 교체하고 진화시킬 수 있는 1급 객체로 다룬다.

HarnessX의 세 층: Compose, Adapt, Evolve

HarnessX는 크게 세 층으로 구성된다.

1. Compose: 하네스를 타입이 있는 부품으로 조립한다.
2. Adapt: 실행 트레이스를 보고 하네스를 자동으로 고친다.
3. Evolve: 하네스 개선과 모델 학습을 하나의 루프로 연결한다.

이 세 층이 합쳐지면, 에이전트 실행 경험이 다음 하네스 버전의 재료가 되고, 다시 그 경험이 모델 학습 신호가 된다.

Compose: 하네스를 조립 가능한 부품으로 만들기

HarnessX에서 하네스는 모델 설정과 하네스 설정의 쌍으로 정의된다.

• 모델 설정은 어떤 모델이 메인, 심판, 평가자 역할을 맡는지 기록한다.
• 하네스 설정은 모델 정체성과 무관하게 에이전트가 어떻게 행동하는지 기록한다.

즉, 같은 하네스를 여러 모델에 붙일 수 있고, 같은 모델에 다른 하네스를 붙여 비교할 수도 있다. 이 분리가 중요하다. 모델과 하네스가 뒤엉켜 있으면 “이 성능 향상이 모델 덕분인지, 프롬프트 덕분인지, 도구 구성 덕분인지”를 분리해 보기 어렵다.

하네스 설정은 여러 생애주기 이벤트에 붙는 processor들의 목록으로 구성된다. processor는 이벤트를 받아 다음 이벤트를 내보내는 작은 행동 단위다. 가능한 동작은 대략 다음과 같다.

• 그대로 통과
• 변환
• 분할
• 가로채기
• 중단

이 제한된 인터페이스 덕분에 processor들은 레고 블록처럼 조합될 수 있다. 하나를 빼거나 끼워 넣어도 전체 파이프라인의 타입 정합성을 유지할 수 있다.

논문은 하네스의 행동 공간을 아홉 가지 차원으로 나눈다.

차원	의미
D1 모델 선택	어떤 모델이 어떤 역할을 맡는가
D2 컨텍스트 구성	모델에게 무엇을 보여줄 것인가
D3 메모리 관리	무엇을 단계와 세션 간 유지할 것인가
D4 도구 생태계	어떤 도구를 호출할 수 있는가
D5 실행 환경	도구의 부작용이 어디서 발생하는가
D6 평가와 보상	결과를 어떻게 판단하는가
D7 제어와 안전	루프, 비용, 드리프트를 어떻게 막는가
D8 관찰 가능성	이벤트와 호출을 어떻게 기록하는가
D9 학습 브리지	트레이스를 학습 신호로 어떻게 바꾸는가

이 분해가 중요한 이유는, 그래야만 자동화된 수정이 가능하기 때문이다. “프롬프트를 좀 고쳐보자”가 아니라 “D2 컨텍스트 구성의 특정 processor를 교체하자”처럼 변경의 범위를 명확히 할 수 있다.

Adapt: 실행 트레이스로 하네스를 고치기

HarnessX의 적응 엔진은 AEGIS다. AEGIS는 에이전트 실행 트레이스와 verifier 점수를 보고 하네스 편집안을 만든다.

논문은 하네스 진화를 강화학습과 유사한 구조로 해석한다.

강화학습 개념	HarnessX에서의 대응
상태	현재 하네스 설정과 누적 트레이스
행동	프롬프트, 도구, processor, 제어 흐름 등의 코드 레벨 편집
보상	verifier 점수와 실행 결과
정책	어떤 하네스 편집을 제안할지 결정하는 진화 절차
업데이트	편집 후보를 검증하고 채택 또는 거절

이 비유가 단순한 장식은 아니다. 강화학습에서 나타나는 병리도 하네스 진화에서 그대로 나타난다.

첫째, 보상 해킹이다. 하네스 편집기가 실제 문제 해결 능력을 올리는 대신 verifier의 허점을 이용할 수 있다.

둘째, 파국적 망각이다. 어떤 편집이 일부 태스크를 고치면서 다른 태스크를 망가뜨릴 수 있다.

셋째, 과소 탐험이다. 안전한 프롬프트 수정만 반복하다가 구조적 개선으로 넘어가지 못할 수 있다.

AEGIS는 이를 막기 위해 네 단계 파이프라인을 둔다.

1. Digester: 원시 트레이스를 요약한다.
2. Planner: 실패 패턴을 분석하고 수정 전략을 세운다.
3. Evolver: 실제 하네스 편집 후보를 만든다.
4. Critic: 보상 해킹, 회귀, 불안정성을 검사한다.

마지막에는 결정론적 게이트가 후보를 채택할지 거절할지 판단한다. 기존에 풀던 태스크를 망가뜨리면 편집은 통과하지 못한다. 논문은 이를 seesaw constraint로 부른다.

Evolve: 하네스와 모델을 함께 키우기

HarnessX의 세 번째 층은 하네스-모델 공진화다.

하네스를 고치면 실행 트레이스가 바뀐다. 이 트레이스는 다시 모델 학습 신호가 될 수 있다. 모델이 좋아지면 같은 하네스가 더 잘 작동하거나, 더 나은 하네스 편집이 가능해진다.

논문은 이를 cross-harness GRPO로 구현한다. 여러 하네스 버전에서 나온 trajectory를 사용해 모델이 successive harness의 전략을 내면화하도록 만든다.

흥미로운 점은 하네스 단독 진화에는 천장이 있다는 것이다. 예를 들어 GAIA와 WebShop에서 하네스만 고치는 방식은 각각 약 37%, 49% 부근에서 정체했다. 그런데 Qwen3.5-9B 작업 에이전트로 공진화를 적용하자 GAIA는 37.4%에서 41.7%, WebShop은 49.0%에서 54.0%로 올라갔다. 평균 **+4.7%**의 추가 이득이다.

하네스가 모델을 보조하고, 모델은 그 경험을 다시 학습한다. 이 루프가 HarnessX의 장기적인 지향점이다.

실험 결과: 약한 모델일수록 하네스의 효과가 크다

HarnessX는 다섯 개 벤치마크와 세 종류의 task agent를 사용했다.

• 벤치마크: ALFWorld, GAIA, WebShop, τ³-Bench, SWE-bench Verified
• task agent: Claude Sonnet 4.6, GPT-5.4, Qwen3.5-9B
• meta-agent: 주로 Claude Opus 4.6

핵심 결과는 다음과 같다.

벤치마크	대표 결과
ALFWorld	Qwen3.5-9B가 53.0%에서 97.0%로 상승, +44.0%
WebShop	세 모델 모두 +13.0% ~ +18.0%
GAIA	Sonnet 4.6은 +9.7%, Qwen3.5-9B는 +17.1%, GPT-5.4는 단일 하네스 전략에서 정체
SWE-bench Verified	+10.9% ~ +18.2%
τ³-Bench	GPT-5.4는 +14.5%, Qwen3.5-9B는 baseline이 이미 높아 +1.1%

가장 눈에 띄는 패턴은 베이스라인이 낮을수록 개선폭이 크다는 점이다. Qwen3.5-9B는 ALFWorld에서 +44.0%, GAIA에서 +17.1%, SWE-bench Verified에서 +18.2%를 얻었다.

이 결과는 꽤 직관적이다. 강한 모델은 어느 정도 스스로 빈틈을 메운다. 반면 작은 모델은 프롬프트, 도구 선택, 작업 분해, 메모리 관리 같은 외부 구조의 도움을 더 크게 받는다. 좋은 하네스는 작은 모델이 혼자서는 만들기 어려운 행동 패턴을 대신 제공한다.

온디바이스 에이전트나 경량 모델 기반 제품을 고민하는 입장에서는 특히 중요한 포인트다. 모델을 키우는 대신 하네스를 고도화하는 쪽이 더 현실적인 지렛대가 될 수 있다.

단일 하네스의 한계와 variant isolation

모든 결과가 깔끔하게 오른 것은 아니다. GAIA에서 GPT-5.4는 단일 global harness 전략으로는 개선되지 않았다. 초기 73.8%에서 정점도 73.8%, 최종은 오히려 49.5%까지 떨어졌다.

논문은 이를 이질적인 태스크 집합에서 단일 하네스가 겪는 구조적 한계로 해석한다. 어떤 편집은 한 작업군에는 좋지만 다른 작업군에는 나쁠 수 있다. 하나의 하네스로 모든 태스크를 커버하려 하면 “고치면 다른 쪽이 망가지는” 시소가 발생한다.

이를 해결하기 위해 논문은 variant isolation, 즉 여러 하네스 변형을 유지하고 태스크별로 적절한 변형에 라우팅하는 전략을 실험했다.

전략	최종 정확도	정점	토큰
Ensemble / variant isolation	87.4%	87.4%	107.8M
Global single harness	49.5%	73.8%	143.7M

variant isolation은 정확도뿐 아니라 비용도 개선했다. 모든 편집을 전체 태스크에 억지로 적용하지 않고, 특정 클러스터에만 적용하기 때문이다.

이 대목은 실제 에이전트 운영에서도 중요하다. “하나의 만능 프롬프트”나 “하나의 만능 agent loop”보다, 태스크군별로 다른 하네스를 두고 라우팅하는 편이 더 안정적일 수 있다.

실무적으로 읽으면 무엇이 남는가

HarnessX를 제품이나 내부 에이전트 시스템 관점에서 읽으면 몇 가지 시사점이 뚜렷하다.

1. 프롬프트만 버전 관리해서는 부족하다

에이전트 성능은 프롬프트뿐 아니라 도구, 메모리, 제어 흐름, 평가기, 관찰 가능성이 함께 만든다. 따라서 개선 단위도 프롬프트 파일 하나가 아니라 하네스 전체여야 한다.

2. 트레이스는 로그가 아니라 학습 자산이다

에이전트가 실패한 실행 기록은 단순 디버깅 로그가 아니다. 실패 패턴, 도구 호출 순서, verifier 결과, 중간 reasoning 흔적은 다음 하네스 편집의 근거가 된다. 운영 환경에서 trace를 얼마나 구조화해 남기느냐가 곧 개선 속도를 결정한다.

3. 작은 모델은 하네스 최적화의 수혜자가 될 가능성이 크다

논문 결과처럼 약한 모델일수록 하네스 개선의 이득이 컸다. 이는 비용 제약이 큰 조직에 유리한 방향이다. 무조건 더 큰 모델을 쓰는 대신, 작은 모델에 더 나은 실행 구조를 붙이는 전략이 가능하다.

4. 단일 에이전트보다 변형과 라우팅이 중요하다

이질적인 태스크를 하나의 하네스로 처리하려 하면 회귀가 누적된다. 태스크군별 하네스 변형을 유지하고, 성능 이력에 따라 라우팅하는 구조가 더 견고하다.

5. 평가 게이트 없이는 자동 진화가 위험하다

자동으로 하네스를 고치는 시스템은 보상 해킹과 회귀를 만들 수 있다. HarnessX가 Critic과 deterministic gate를 둔 이유도 여기에 있다. 자동 개선을 실무에 적용하려면 평가셋, 회귀 테스트, 비용 추적, exploit 탐지가 필수다.

한계도 분명하다

논문이 보고한 결과는 인상적이지만, 그대로 일반화하기에는 조심해야 한다.

가장 큰 한계는 held-out 평가가 없다는 점이다. 성능 향상은 진화에 사용한 동일한 태스크셋에서 측정되었다. 따라서 미지의 태스크에도 같은 개선이 유지되는지는 아직 확인되지 않았다.

또한 실험은 텍스트 기반의 이산적 행동 공간에 집중되어 있다. 로봇 제어처럼 연속적이고 물리적인 행동 공간에서도 같은 접근이 잘 작동할지는 별도 검증이 필요하다.

메타 에이전트로 강한 폐쇄형 모델을 사용했다는 점도 현실적인 제약이다. 하네스 진화 자체가 상당한 선불 비용을 요구하기 때문에, 호출 빈도가 충분히 높은 서비스가 아니라면 투자 대비 효과가 낮을 수 있다.

결론: 에이전트의 다음 병목은 모델 바깥에 있다

HarnessX의 가장 중요한 주장은 “모델이 전부가 아니다”라는 것이다.

지금까지 많은 에이전트 개선은 더 큰 모델, 더 긴 컨텍스트, 더 좋은 reasoning 모델에 집중되어 있었다. 물론 그것도 중요하다. 하지만 에이전트는 모델 혼자 움직이는 시스템이 아니다. 모델은 하네스를 통해 세상을 보고, 도구를 쓰고, 기억하고, 실패를 복구한다.

따라서 하네스를 1급 객체로 만들고, 실행 트레이스를 통해 자동으로 개선하는 방향은 에이전트 엔지니어링의 자연스러운 다음 단계다.

좋은 모델을 고르는 일만큼이나 중요한 것은 좋은 주방을 만드는 일이다. HarnessX는 그 주방을 사람이 매번 손으로 고치는 대신, 실행 경험으로부터 스스로 정리하고 진화시키는 방법을 보여준다.

그리고 이 메시지는 특히 경량 모델과 실무형 에이전트를 만드는 사람들에게 실용적이다.

참고 자료

• PyTorchKR 글: HarnessX: 에이전트 하네스를 실행 트레이스로 진화시키는 연구
• 논문: HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry