HarnessDev, LLM이 에이전트 실행 프레임워크를 만들고 진화시킬 수 있는지 평가

들어가며

에이전트의 성능은 모델 가중치만으로 결정되지 않습니다. 프롬프트를 구성하는 방식, 도구 호출 순서, 메모리, 작업 분해, 오류 복구, 실행 제어가 모두 결과에 영향을 줍니다. 모델 바깥에서 이러한 과정을 조정하는 실행 인프라를 일반적으로 agent harness, 즉 에이전트 하니스라고 부릅니다.

기존 에이전트 평가는 대체로 하나의 하니스를 고정한 뒤 모델의 작업 결과를 비교했습니다. HarnessDev는 이 관점을 뒤집습니다. 모델 가중치를 바꾸지 않고도 LLM이 에이전트 실행 시스템을 직접 만들고, 실제 실행 피드백을 이용해 이를 개선할 수 있는지 묻는 것입니다.

인프라를 평가하는 두 단계

HarnessDev는 두 단계로 구성됩니다.

• Creation(생성): 최소한의 시드와 소수의 사례에서 출발해 완전한 실행 시스템을 구축합니다.
• Evolution(진화): 자신이 만든 하니스를 기반으로 다운스트림 작업의 실행 결과를 확인하며 시스템을 반복 수정합니다.

생성된 하니스는 개발 과정에서 공개되지 않은 보류 작업으로 평가됩니다. 측정 항목은 작업 성공률로 나타나는 능력과 실행 중 소비되는 토큰으로 나타나는 효율성입니다. 보고된 생성 실험은 6개 생성 LLM, 4개 분야, 5개 다운스트림 벤치마크를 포함하며, 총 2,207개의 고유 다운스트림 인스턴스를 다룹니다.

분야별 격차가 뚜렷하다

생성된 하니스가 모든 영역에서 인간이 설계한 성숙한 시스템을 따라잡은 것은 아닙니다. 코드, 검색, 연구에서는 상당한 격차가 남았습니다. 이 작업들은 도구 오케스트레이션, 정보 검증, 장기 계획, 실패 복구를 안정적으로 수행해야 하므로, 한 번의 생성만으로 견고한 실행 절차를 만들기 어렵습니다.

반면 글쓰기와 머신러닝 실험에서는 생성 하니스가 선택된 인간 설계 기준 시스템과 비슷하거나 더 나은 성능을 보였습니다. 자연어 기반 계획이나 실험 피드백을 통한 조정이 가능한 작업일수록 현재 모델이 효과적인 실행 구조를 찾기 쉬울 가능성이 있습니다.

효율성도 중요한 변수입니다. 작업 성공률을 높인 하니스가 더 긴 추론 과정, 더 많은 도구 호출, 반복 시도에 의존할 수 있기 때문입니다. 따라서 유용한 에이전트 인프라를 판단할 때는 정확도만이 아니라 실행 비용도 함께 봐야 합니다.

자기 개선은 자동으로 안정적이지 않다

진화 단계의 개선은 항상 안정적으로 나타나지 않았으며, 런타임 모델에 의존하는 경향도 있었습니다. 한 실행 모델이나 작업 분포에서 효과적인 변경이 다른 환경에서도 재현된다고 보장할 수 없는 것입니다.

실질적인 자기 개선을 위해서는 코드나 프롬프트를 단순히 늘리는 것만으로 부족합니다. 시스템은 성능 병목을 찾아내고, 의미 있는 실험을 설계하며, 우연한 향상과 일반화 가능한 향상을 구분해야 합니다. 동시에 능력과 비용 사이의 균형을 반복 가능하게 조정해야 합니다.

의미와 영향

HarnessDev의 가장 큰 의미는 지금까지 평가에서 가려져 있던 에이전트 엔지니어링 계층을 측정 대상으로 끌어냈다는 점입니다. 앞으로의 경쟁은 더 강한 모델뿐 아니라 안정적이고 저렴하며 다양한 작업에 적응하는 실행 프레임워크를 누가 설계하느냐로도 확장될 수 있습니다. 다만 현재 LLM은 일부 분야에서 유용한 하니스를 만들 수 있을 뿐, 복잡한 영역에서 성숙한 인간 설계 시스템을 전반적으로 넘어섰다고 보기는 어렵습니다.

출처: Hugging Face Daily Papers