HarnessDev가 보여준 것: 모델보다 하네스가 점수를 바꿀 때 | DAKER 커뮤니티

에이전트 성능을 말할 때 우리는 대개 모델 이름부터 떠올립니다. 그런데 같은 가중치를 써도 실행 인프라, 즉 하네스가 달라지면 점수가 크게 달라질 수 있다는 점이 점점 더 중요해지고 있습니다. 2026년 9월 1일 공개된 HarnessDev는 바로 이 지점을 정면으로 다룹니다.

이 논문이 흥미로운 이유는 평가 대상을 과제 출력에서 실행 가능한 하네스 자체로 옮긴다는 데 있습니다. 모델이 답을 잘 내는지뿐 아니라, 스스로 에이전트 실행 시스템을 만들고 고칠 수 있는지도 보자는 제안입니다.

논문은 2026-09-01 arXiv에 올라왔습니다. 초록은 arXiv:2609.01437에서 볼 수 있고, 영문 제목은 HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?입니다. 저자는 Yuhao Wu, Jingyuan Zhang 외 (ByteDance Seed, SUTD, Georgia Tech, M-A-P, TokenWave.AI)입니다. PDF는 같은 번호의 pdf, 관련 페이지는 https://self-developing-agents.github.io/입니다. 아래 내용은 제공된 사실과 초록·본문에서 확인한 범위만 옮깁니다.

평가 대상이 과제 출력에서 하네스로 이동합니다

에이전트가 연구 프로토타입을 넘어 실제 도구에 가까워질수록, 성능은 모델 바깥의 실행 인프라에 크게 좌우됩니다. 기존 평가는 보통 특정 하네스 위에서 나온 다운스트림 점수를 중심으로 읽혔지만, HarnessDev는 모델이 하네스를 직접 개발하는 능력까지 평가 범위에 넣습니다.

같은 가중치라도 하네스가 바뀌면 점수가 바뀔 수 있습니다.

HarnessDev는 두 단계로 구성됩니다. Creation에서는 약한 시드와 소수 사례만으로 완전한 실행 시스템을 만듭니다. Evolution에서는 이렇게 만든 하네스를 다운스트림 실행 피드백을 바탕으로 고칩니다. 논문은 이 과정을 능력, 즉 held-out 과제 성공과 효율, 즉 실행 토큰 비용을 함께 보며 평가합니다.

이 문제의식을 보여주는 예시도 분명합니다. 동일한 GPT-5 가중치가 Terminal-Bench 2.1에서 Terminus 2로는 35.2%, Codex CLI로는 49.6%를 기록합니다. 모델 이름만으로 성능을 설명하기 어렵다는 뜻입니다.

Creation 결과는 넓게 측정됐지만, 사람 설계 하네스를 전반적으로 넘지는 못했습니다

논문이 보고한 Creation 범위는 생성 모델 6개, 도메인 4개, 다운스트림 벤치 5개, 고유 인스턴스 2,207개입니다. 개발 과정에서 숨긴 평가 태스크도 포함됩니다.

결과를 보면 생성 하네스는 코드와 검색·리서치에서는 성숙한 사람 설계 참고 시스템에 크게 못 미칩니다. 반면 글쓰기와 머신러닝 실험에서는 맞추거나 넘는 경우도 보고됩니다. 실행 비용 편차도 큽니다.

생성 하네스가 사람 설계 하네스를 전반적으로 이긴다는 주장은 아닙니다.

Self-Eval에서는 Opus 4.8의 overall이 67.8로 생성 모델 가운데 가장 높았지만, human-engineered reference 86.2보다는 낮았습니다. 이 수치는 생성 하네스가 상당한 수준까지 올라올 수는 있어도, 사람 설계 기준선과 같다고 보기는 어렵다는 점을 보여줍니다.

Evolution은 가능성을 보였지만, 안정적인 자동 개선으로 읽기에는 이릅니다

Evolution 단계는 일부 이득을 보였지만, 논문은 그 효과가 불안정하다고 적습니다. held-out 과제가 바뀌거나 실행 모델이 달라지면 전이가 제한적이었고, 고정 런타임 모델 실험에서도 이득이 실행 모델에 강하게 의존한다고 보고합니다.

Evolution이 안정적 자동 개선을 보장하는 것은 아닙니다.

따라서 Evolution 결과를 읽을 때는 피드백 세트에서 오른 점수와 최종 일반화 성능을 구분해서 보는 것이 중요합니다. 논문이 강조하는 한계도 바로 여기에 있습니다.

실무에서는 모델 점수와 하네스 명세를 분리해 적는 것이 중요합니다

이 논문이 실무 팀에 주는 메시지는 단순합니다. 우리 에이전트의 점수와 우리 하네스의 명세를 분리해서 기록해야 한다는 점입니다. 시드 하네스, 추가한 도구, 검증기, 스텝 한도, 런타임, 권한 범위 같은 요소를 함께 남겨야 비교가 가능합니다.

모델 카드 옆에 어떤 하네스로 돌렸는지를 같이 적어야 합니다.

특히 논문 본문에는 하드코딩된 스텝 한도처럼 실행기 전용 설정이 다른 모델에서 무너진 사례가 언급됩니다. 그래서 실행기별 설정이 모델 이름에 묶여 있는지 점검하는 것이 좋습니다. Controller·Worker 구조를 쓰는 경우에는 하네스 수정 권한과 과제 실행 권한을 분리해 두는 편이 안전합니다.

또 하나 중요한 점은 비용입니다. 코드 하네스가 정교해질수록 능력 점수만 눈에 띄고 실행 토큰 비용은 가려지기 쉽습니다. 논문도 능력과 효율을 함께 봅니다. 따라서 점수 옆에 실행 토큰을 같이 두는 방식이 더 적절합니다.

이 논문을 읽을 때 피해야 할 오해

몇 가지는 분명히 선을 그을 필요가 있습니다. Terminal-Bench 2.1의 35.2%와 49.6%는 HarnessDev 생성 결과가 아니라, 동일 가중치와 다른 하네스의 차이를 보여주는 동기화 예시입니다. Opus 4.8 overall 67.8 역시 Self-Eval 집계이지, 모든 실행기에서 그대로 재현된다는 뜻은 아닙니다.

또한 이 논문은 특정 대회 우승 사례를 발표하는 글이 아니라, 벤치마크와 방법론을 제안하는 연구입니다. 프로젝트 페이지의 표와 부록을 실험 노트로 옮길 때도 생성기 모델 이름(Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro 등)과 자신의 백본 이름을 섞지 않는 편이 좋습니다.

지금 읽는다면 무엇을 가져가면 좋을까요

HarnessDev의 핵심은 에이전트 평가를 더 현실에 가깝게 옮긴다는 데 있습니다. 모델이 좋으냐 나쁘냐만으로는 설명되지 않는 성능 차이를, 하네스라는 단위로 드러냅니다. 같은 모델이라도 실행 시스템이 다르면 결과가 달라지고, 모델이 그 실행 시스템을 직접 만들고 고칠 수 있는지도 별도의 능력으로 봐야 한다는 제안입니다.

그래서 앞으로 에이전트 결과를 읽을 때는 모델 이름만이 아니라 하네스 이름, 런타임, 권한 범위, 스텝 한도, 실행 비용까지 함께 보는 습관이 더 중요해질 가능성이 큽니다.

참고 자료

arXiv:2609.01437 — HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? (2026-09-01)
PDF
https://self-developing-agents.github.io/

여러분은 에이전트 성능을 볼 때 모델보다 하네스가 더 크게 작용했던 사례를 떠올리신 적이 있나요?