AI 에이전트 시대, 모델만큼 Harness 사양이 중요한 이유

들어가며

AI 에이전트의 성능을 비교할 때 흔히 모델 이름과 벤치마크 점수부터 확인한다. 그러나 대규모 언어 모델은 혼자서 현실의 작업을 수행하지 않는다. 프롬프트, 도구, 실행 환경, 권한, 피드백 경로와 같은 주변 인프라를 통해서만 외부 세계와 상호작용할 수 있다.

arXiv 논문 「Towards Portable Specification of the Agent Harness」는 이 주변 인프라를 ‘Harness’라고 부르며, 모델과 마찬가지로 명시하고 버전 관리해야 한다고 주장한다. 이는 새로운 에이전트 제품을 소개하는 연구라기보다, 모델 외부의 요소까지 포함해 시스템을 비교하고 결과를 재현하기 위한 기록 체계를 제안하는 작업이다.

핵심 내용

• Harness는 단순한 실행 래퍼가 아니다. 모델이 어떤 정보를 받고, 어떤 도구를 호출하며, 결과를 어떻게 관찰하는지를 결정하는 기반이다. 따라서 에이전트의 능력뿐 아니라 실패 방식에도 영향을 준다.
• 8개의 기능 구성요소로 분해한다. 제공된 자료에는 각 구성요소의 구체적인 명칭이 제시되지 않았지만, 이 분해의 목적은 모든 시스템을 모호하게 ‘에이전트 프레임워크’라고 부르는 대신 공통 기준으로 설명하고 비교하는 데 있다.
• 같은 모델도 결과가 달라질 수 있다. 논문은 Harness 설정에 따라 동일 모델의 보고 점수가 몇 배까지 차이 날 수 있다고 설명한다. 모델 이름과 최종 점수만으로는 성능의 원인을 충분히 알기 어렵다는 뜻이다.
• Harness 자체도 공격면이다. 도구 권한, 실행 환경, 설정 관리, 외부 시스템과의 연결 방식은 모델과 별개로 위험을 키울 수 있다. 에이전트가 자신의 도구나 설정을 수정할 수 있다면 이 문제는 더 중요해진다.
• 한 번의 실행 중에도 설정이 바뀔 수 있다. 모델 카드와 에이전트 카드는 출시 정보나 운영 방법을 제공하지만, 한 실행에서 실제로 적용된 설정의 변화 과정까지 남기지는 않을 수 있다.

의미와 영향

평가 측면에서 이 제안은 모델 정보만 공개하는 관행을 재검토하게 만든다. 앞으로는 어떤 모델을 사용했는지뿐 아니라, 어떤 Harness와 도구, 권한, 설정으로 실행했는지도 함께 기록해야 모델의 능력과 오케스트레이션의 효과를 구분할 수 있다.

개발자에게 버전이 지정된 Harness 기록은 디버깅과 회귀 테스트에 유용하다. 시스템 업데이트 뒤 성능이 변했을 때 원인이 모델 변경인지, 주변 인프라의 수정인지 추적할 수 있기 때문이다. 보안팀은 실행 중 권한과 설정이 어떻게 변했는지 확인해 잠재적인 공격 경로를 분석할 수 있다.

논문은 이 제안이 현행 AI 법률의 문서화 의무와 동일하지 않다는 점도 구분한다. 관련 법률은 적용 대상과 시행 시점에 따라 특정 기록을 요구할 수 있지만, 이번에 제안된 공통 Harness 기록 형식을 직접 규정하지는 않는다. 따라서 실제 표준은 연구 관행, 공개 사양, 관련 도구를 통해 형성될 가능성이 크다.

결국 에이전트를 ‘모델과 사용자 인터페이스의 결합’으로만 설명해서는 부족하다. 모델과 모델을 행동 가능하게 만드는 Harness를 하나의 시스템으로 기록해야 평가 결과의 비교 가능성, 재현성, 보안 검토를 함께 높일 수 있다.

출처: arXiv