코딩 에이전트 하네스는 돈값을 할까?

요약

코딩 에이전트의 성능과 비용 효율성을 분석하기 위해 API 명세와 테스트로 구성된 '하네스'를 활용한 실험을 진행했습니다.
실험 결과 저성능 모델은 하네스를 통해 성공률을 높이고 비용을 절감할 수 있었으며, 저자는 모델 성능에 따라 하네스 활용 시점과 방식을 차별화하는 전략을 제안했습니다.

같은 API 서비스(Java로 만드는 BFF)를 코딩 에이전트에게 맡기고, 하네스를 줬을 때와 안 줬을 때를 모델마다 10번씩 비교한 실험입니다.
하네스는 API 명세와 예시(가이드), 계약 검사와 API 테스트(센서)로 구성했고, 에이전트가 개발하면서 직접 돌려 볼 수 있게 했습니다. 완성된 앱은 따로 만든 인수 테스트 178개로 평가했고, 하네스는 이 평가 세트에 접근할 수 없었습니다.
GPT-6 Sol은 하네스가 있든 없든 10번 다 통과했습니다. 하네스를 쓰면 토큰은 약 10.5배, 비용은 약 7배 더 들었습니다.
싼 모델인 GPT-6 Luna는 하네스 없이 10번 중 3번, 하네스가 있으면 10번 다 통과했습니다. 하네스를 쓴 Luna는 회당 약 $0.273으로 하네스 없는 Sol(약 $0.406)보다 약 33% 쌌습니다.
하네스 없이 실패한 앱도 178개 중 144개 이상은 통과했습니다. 놓친 건 주로 타임아웃 때 202와 모니터 링크를 돌려주는 흐름, Kafka 메시지 형식, 정확한 HTTP 에러 응답 같은 세부였고, 요구사항 문서에 다 적혀 있던 내용입니다. 저자는 센서가 빨간불을 내면 빠뜨린 요구사항을 다시 챙기게 된다며 이걸 executable attention이라고 부릅니다.
저자 제안은 싼 모델은 개발 내내 하네스를 돌리고, 프런티어 모델은 끝에 독립 검증을 한 번만 두자는 겁니다. 모델 성능에 따라 바뀌는 건 검증을 언제 얼마나 돌리느냐이고, 독립 검증 자체는 어느 모델이든 필요하다고 봅니다.
한계도 적어 뒀습니다. 모델마다 10번씩 새 서비스 1개로 돌린 결과이고, 요구사항 문서가 유난히 자세했습니다. 비용은 API 가격으로 환산한 추정치라 명세와 예시를 만들고 관리하는 사람 시간은 빠져 있습니다.