EvolveTool-Bench: Evaluating the Quality of LLM-Generated Tool Libraries as Software Artifacts

1. 문제 정의 (Problem)

최근 LLM 에이전트들은 런타임 시 Python 함수, API 클라이언트, 데이터 파서 등 실행 가능한 소프트웨어 아티팩트를 직접 생성하여 영구적인 도구 라이브러리에 추가하는 능력이 강화되고 있습니다. 그러나 기존 벤치마크들은 이러한 에이전트의 성능을 하류 작업 (downstream task) 의 성공 여부만으로 평가하는 데 그치고 있습니다.

이는 소프트웨어 엔지니어의 능력을 "코드가 실행되는지 여부"만으로 판단하고, 중복성 (redundancy), 회귀 (regression), 안전성 (safety), 유지보수성 등을 무시하는 것과 유사합니다. 실제로 생성된 도구 라이브러리는 하류 벤치마크에서는 통과하더라도, 중복된 함수가 쌓이거나, 기존 기능을 파괴하거나 (회귀), 엣지 케이스에서 실패하는 등 소프트웨어 품질 측면에서 심각한 위험을 내포할 수 있습니다. 현재까지 생성된 도구 라이브러리의 소프트웨어 품질을 평가하는 표준 벤치마크는 존재하지 않았습니다.

2. 방법론 (Methodology)

저자들은 생성된 도구 라이브러리를 1 차적인 소프트웨어 아티팩트로 간주하고 그 품질을 진단하는 새로운 벤치마크 EvolveTool-Bench를 제안했습니다.

가. 벤치마크 설계

• 작업 세션 구조: 각 세션은 11 개의 작업으로 구성되며, 6 가지 범주 (Seed, Gap, Variant, Compose, Regress, Adversarial) 로 나뉩니다. 이는 실제 소프트웨어 엔지니어링 워크플로우 (기존 코드 사용, 새 구현, 코드 재사용, 함수 조합, 회귀 테스트, 엣지 케이스 테스트) 를 반영합니다.
• 도메인: 실제 도구 실행이 필요한 3 가지 도메인을 포함합니다.
  1. 데이터 변환: 훈련 데이터에 없는 독점 이진 형식 처리.
  2. API 오케스트레이션: HMAC 인증 및 암호화된 커서 페이지네이션이 필요한 HTTP 서버.
  3. 수치 계산: 커브 피팅, 신호 처리, 제약 최적화 등.

나. 평가 지표 (Metrics)

단순 작업 성공률 (Task Completion) 외의 소프트웨어 품질 지표를 도입했습니다.

• 도구 품질 점수 (Tool Quality Score, TQS): 각 생성된 도구에 대해 **정확성 (Correctness), 견고성 (Robustness), 일반성 (Generality), 코드 품질 (Code Quality)**을 종합하여 산출합니다.
• 라이브러리 건강도 (Library Health, LH): 전체 라이브러리 수준에서 다음 6 가지 지표를 측정합니다.
  • 재사용률 (Reuse), 중복도 (Redundancy), 구성 성공률 (Composition Success), 회귀 안정성 (Regression Stability), 생성 효율성, 안전성.
• EvolveTool 점수 (ETS): 작업 완료율 (TC), TQS, 재사용률, 라이브러리 건강도 등을 가중치로 합산한 종합 점수입니다.

다. 실험 설정

• 비교 대상 시스템:
  1. No-Evolution: 시드 도구만 사용 (변화 없음).
  2. ARISE: 런타임 실패를 감지하고 LLM 분석을 통해 실행 가능한 Python 도구를 생성, 샌드박스에서 검증 및 A/B 테스트 후 라이브러리에 추가하는 코드 레벨 진화 시스템.
  3. EvoSkill: 실행 가능한 코드가 아닌 텍스트 프롬프트 기반의 전략 레벨 진화 시스템.
  4. One-Shot: 테스트 없이 일회성 코드 생성.
• 모델: Claude Sonnet 4 및 Haiku 4.5 사용.
• 규모: 3 개 도메인, 99 개 작업, 총 594 회 실행.

3. 주요 기여 (Key Contributions)

1. LLM 생성 소프트웨어 아티팩트의 품질 정의: 개별 도구의 품질 점수 (TQS) 와 라이브러리 수준의 6 가지 건강도 지표를 정의하여, 생성된 코드를 소프트웨어 공학 관점에서 평가할 수 있는 기준을 마련했습니다.
2. 검증 및 검증 프레임워크: 숨겨진 유닛 테스트, 적대적 입력 (adversarial inputs), 샌드박스 실행, LLM-as-judge 를 통한 진화 트리거 결정, 그리고 명시적인 회귀 테스트를 포함하는 평가 하네스를 구축했습니다.
3. 통제된 진단 세션: 의존성 관계가 알려진 11 단계 작업 시퀀스를 통해 에이전트가 코드 재사용 기회를 인지하는지, 자체 함수를 구성하는지, 라이브러리 안정성을 유지하는지 측정할 수 있게 했습니다.

4. 실험 결과 (Results)

• 작업 완료율의 함정: 모든 시스템의 작업 완료율 (TC) 은 6368% 로 비슷했으나, **EvolveTool 점수 (ETS)**는 0.5160.612 로 큰 차이를 보였습니다. 기존 TC 중심 평가라면 성능이 낮은 것으로 오인될 수 있는 시스템이 실제로는 더 높은 소프트웨어 품질을 가질 수 있음을 보여줍니다.
• 코드 진화 vs 전략 진화: 코드 레벨 진화 시스템인 ARISE가 전략 레벨 진화 시스템인 EvoSkill 보다 훨씬 높은 ETS(0.603 vs 0.520) 를 기록했습니다. EvoSkill 은 실행 가능한 도구를 전혀 생성하지 못해 라이브러리 건강도가 초기 상태와 동일했습니다.
• 테스트되지 않은 코드의 위험: 테스트 없이 생성된 One-Shot 방식의 라이브러리 건강도 (38.3%) 는 아예 진화를 하지 않은 경우 (41.4%) 보다 낮았습니다. 이는 검증되지 않은 코드가 기술 부채로 작용함을 의미합니다.
• 보상 설계의 중요성: 휴리스틱 보상만으로는 진화가 발생하지 않았으며, LLM-as-judge 보상만이 효과적인 진화를 유도했습니다.
• 모델 비용 대비 효율: 더 저렴한 모델 (Haiku) 을 사용한 ARISE 가 고가 모델 (Sonnet) 보다 약간 더 높은 ETS(0.612 vs 0.603) 를 기록하며, 적은 수의 도구로도 높은 품질을 달성할 수 있음을 보였습니다.
• 품질의 한계: 생성된 도구들의 평균 TQS 는 0.34~0.35 수준으로 낮았으며, 특히 정확성이 가장 약한 부분이었습니다. 에이전트가 스스로 생성한 테스트는 숨겨진 결함을 놓치는 경향이 있었습니다.

5. 의의 및 결론 (Significance & Conclusion)

이 연구는 LLM 에이전트가 생성하는 도구 라이브러리를 단순한 "블랙박스"가 아닌 1 차적인 소프트웨어 아티팩트로 취급해야 함을 강조합니다.

• 평가 패러다임의 전환: 하류 작업 성공률만으로는 소프트웨어의 중복성, 회귀, 안전성 등 중요한 품질 요소를 놓칠 수 있음을 입증했습니다.
• 거버넌스 필요성: 생성된 코드를 축적하는 시스템은 독립적인 검증 (샌드박스 실행, 회귀 테스트 등) 과 품질 거버넌스가 필수적입니다.
• 향후 방향: 보상 설계 (Reward Design) 가 진화 시스템의 병목 현상이며, 생성된 코드의 품질을 높이기 위해서는 더 강력한 검증 메커니즘이 필요함을 시사합니다.

결론적으로, EvolveTool-Bench는 생성된 도구 라이브러리의 소프트웨어 품질을 체계적으로 평가할 수 있는 첫 번째 벤치마크로서, LLM 에이전트 개발 및 평가에 있어 코드 품질과 유지보수성을 핵심 지표로 삼아야 함을 주장합니다.