Doc2Harness, 코딩 에이전트 Harness 설계 능력을 평가하다

배경

코딩 에이전트 평가는 대체로 동일한 도구와 실행 환경을 모든 모델에 제공한 뒤, 버그 수정이나 파일 변경 같은 하위 작업을 완료하는지 측정한다. 그러나 실제 시스템의 성능은 모델만으로 결정되지 않는다. 프롬프트 구성, 도구 호출, 파일과 프로세스 관리, 실행 결과의 전달을 담당하는 Harness 역시 중요한 역할을 한다. Doc2Harness는 이 주변 시스템을 모델이 직접 설계하고 구현할 수 있는지에 초점을 맞춘다.

평가 구조

Doc2Harness는 두 단계로 진행된다. 첫 번째 단계에서 빌드 모델은 고정된 빌더 Harness 안에서 작업한다. 모델에는 인터페이스만 담긴 계약 골격과, 12개 프런티어 Harness의 동작을 통합한 개발 문서가 주어진다. 이를 바탕으로 모델은 격리된 컨테이너 안에서 완전한 후보 Harness를 구축해야 한다.

두 번째 단계에서는 후보 Harness를 동결한 뒤 구축 환경과 분리된 컨테이너에서 실행한다. 테스트 케이스마다 별도의 컨테이너를 사용하고, 스크립트로 작성된 모의 모델이 처음부터 끝까지 Harness를 구동한다. 따라서 구축 과정에서 사용한 환경이 평가를 몰래 지원하는 문제를 줄이고, 각 실행을 비교적 재현 가능하게 만든다.

채점은 네 가지 관찰 가능한 결과를 사용한다. 모델에 전송된 요청, 디스크에 생성된 파일, 프로세스 종료 코드, 명령 출력이 그것이다. 또한 양성 대조군을 활용해 실제 작업을 수행하지 않은 피상적인 구현이 우연히 통과하는 것을 배제한다.

결과

19개 프런티어 모델을 대상으로 모델마다 세 번의 독립적인 구축을 수행하고, 328개 테스트 케이스에서 결과를 비교했다. GPT-6 Astra가 53.05%로 가장 높은 통과율을 기록했으며, 가장 낮은 모델은 27.44%였다. 차이는 약 26%포인트다. 하지만 더 중요한 관찰은 최고 모델조차 테스트의 거의 절반을 통과하지 못했다는 점이다.

실패는 단순히 코드를 생성하지 못한 경우에만 나타나지 않았다. 여러 기능에 걸쳐 사용되는 동작을 어떤 모듈에 배치하고, 장시간 실행 중에도 상태·도구·파일 변경·모델 통신을 일관되게 유지할지 결정하는 과정에서 문제가 집중됐다. 개별 기능은 그럴듯하게 구현해도 전체 실행 흐름에서 모듈 간 계약이 어긋나면 시스템이 무너질 수 있다는 의미다.

의미와 영향

Doc2Harness는 코딩 에이전트의 능력을 모델의 단발성 코드 생성 성능만으로 판단하기 어렵다는 점을 보여준다. 정교하게 만들어진 고정 환경에서 작업을 잘하는 모델이 계약과 개발 문서만 보고 신뢰할 수 있는 실행 기반까지 설계할 수 있는 것은 아니다. 에이전트가 실제 작업공간을 장기간 수정하게 될수록 모듈 경계, 상태 관리, 프로세스 제어, 엔드투엔드 검증이 핵심 요소가 된다.

이 벤치마크는 이러한 문제를 반복 가능하고 비교 가능한 방식으로 측정한다는 데 의미가 있다. 모델 개발자는 장기 실행에서 발생하는 구조적 약점을 찾을 수 있고, Harness 설계자는 더 명확한 인터페이스와 모듈 계약이 필요한 지점을 확인할 수 있다. 앞으로의 코딩 에이전트 경쟁은 더 강한 생성 능력뿐 아니라 복잡한 동작을 안정적인 소프트웨어 구조로 조직하는 능력에도 달려 있을 가능성이 크다.

출처: Hugging Face Daily Papers