기술 요약: SaaS-Bench

문제 제기

컴퓨터 사용 에이전트 (CUAs) 는 수동적인 텍스트 생성기에서 그래픽 사용자 인터페이스 (GUI) 와 웹 브라우저를 상호작용할 수 있는 능동적 실행기로 진화했습니다. 그러나 이러한 에이전트를 평가하는 기존 벤치마크는 현실 세계의 능력을 체계적으로 과대평가하게 만드는 세 가지 치명적인 한계를 안고 있습니다:

1. 제한된 애플리케이션 복잡성: 많은 벤치마크는 프로덕션 소프트웨어의 전체 프론트엔드 - 백엔드 로직, 동적 상태 의존성, 비즈니스 제약을 결여한 단순화되거나 정적이며 인공적인 웹 환경에 의존합니다.
2. 격리된 워크플로우: 작업은 종종 짧은 범위를 가진 단일 애플리케이션으로 제한되어, 전문 업무에 내재된 애플리케이션 간 조정, 도메인별 지식, 그리고 구조화된 다단계 과정을 포착하지 못합니다.
3. 단기 의존성: 기존 작업은 에이전트의 장기적 계획, 상태 추적, 오류 복구 능력을 테스트하는 데 필요한 확장된 상호작용 시퀀스 (종종 100 단계 이상) 를 거의 요구하지 않습니다.

결과적으로, CUAs 가 현실적이고 고가치인 소프트웨어 서비스 (SaaS) 환경에서 효과적으로 운영될 수 있는지 판단할 엄격한 평가 프레임워크가 부족합니다.

방법론

벤치마크 구축 (SaaS-Bench)

저자들은 현실적이고 배포 가능한 SaaS 환경에서 CUAs 를 평가하도록 설계된 SaaS-Bench를 소개합니다. 구축 과정은 세 가지 핵심 원칙을 준수합니다:

1. 현실적이고 배포 가능한 환경:

   • 이 벤치마크는 장난감 웹사이트가 아닌 23 개의 실제 오픈소스 SaaS 시스템(예: OpenEMR, OnlyOffice, BigCapital) 을 기반으로 구축되었습니다.
   • 이러한 시스템은 Docker 를 통해 컨테이너화되어 완전한 프론트엔드 - 백엔드 로직, 영구 데이터베이스 상태, 사용자 인증을 보장합니다.
   • 재현성을 보장하고 상태 오염을 방지하기 위해 각 작업 전에 환경이 사전 정의된 초기 상태로 재설정됩니다.
   • 의미 있는 비즈니스 컨텍스트를 보장하기 위해 LLM 이 생성한 현실적인 데이터와 가져온 오픈소스 데이터셋을 결합하여 데이터를 의미론적으로 채웠습니다.

2. 전문적, 애플리케이션 간, 멀티모달 워크플로우:

   • 작업은 6 개 전문 도메인(소프트웨어 공학, 비즈니스 운영, 의료 행정, 팀 협업, 농업, 미디어 제작) 에 걸쳐 조직되었습니다.
   • 이 벤치마크에는 실제 워크플로우에 기반한 106 개의 작업이 포함되어 있습니다.
   • **작업의 93.4%**가 최소 두 개의 애플리케이션을 포함하며, 50% 는 세 개의 애플리케이션 간 조정을 요구합니다.
   • 세트에는 74 개의 텍스트 전용 작업과 32 개의 멀티모달 작업(이미지, 문서, 미디어 포함) 이 포함되어 있으며, 주로 농업 및 미디어 도메인에 속합니다.

3. 장기 실행:

   • 작업은 평균 100 개 이상의 상호작용 단계로 설계되었습니다.
   • 4 단계 파이프라인 (작업 시드 $\rightarrow$ 합성 루프 $\rightarrow$ 정적 확인 $\rightarrow$ 실행 확인) 을 통해 작업이 전문적, 실행 가능, 검증 가능하도록 보장합니다. 여기에는 LLM 이 후보를 생성하고 인간 전문가가 모호성, 완전성, 검증 가능성을 검토하는 반복적인 '빌더 - 챌린저 - 리파이너' 루프가 포함됩니다.

평가 프로토콜

• 실행 프레임워크: 에이전트는 browser-use 프레임워크를 사용하여 브라우저 기반 UI 작업 (탐색, 클릭, 입력) 을 통해서만 상호작용합니다. 데이터베이스, API, 또는 파일 시스템에 대한 직접 접근은 금지됩니다.
• 검증: 각 작업은 가중치 부여된 검증 체크포인트로 분해됩니다. 세 가지 검증 방법이 사용됩니다:
  • 상태 확인 (State-Check): 객관적 시스템 상태 (DB 레코드, API 응답) 를 검증합니다.
  • 콘텐츠 확인 (Content-Check): 문자열 매칭을 통해 텍스트 출력을 검증합니다.
  • LLM 판정자 (LLM-Judge): 보고서 품질과 같은 개방형 출력을 평가합니다.
• 지표:
  • 해결 점수 (Resolved Score): 이진 (1 또는 0); 모든 체크포인트가 통과할 때만 1 입니다.
  • 체크포인트 점수: 진행 상황을 반영하는 가중치 부여된 부분 점수로, 장기 작업에서의 중간 성공 측정을 가능하게 합니다.

주요 결과

성능 개요

실험은 7 개의 최첨단 모델 (Claude Opus 4.6, GPT-5.4 High, Qwen 3.6 Plus 등 포함) 로 수행되었습니다. 결과는 현재 에이전트가 현실적인 SaaS 워크플로우에서 크게 어려움을 겪고 있음을 나타냅니다:

• 낮은 엔드투엔드 완료율: 가장 강력한 모델인 Claude Opus 4.6조차 **해결 점수가 불과 1.9%**에 그쳤으며 (엔드투엔드로 완료된 작업이 4% 미만), 이는 전체 워크플로우를 완료하는 데 실패했음을 의미합니다.
• 체크포인트 점수: 최상위 모델의 전체 체크포인트 점수는 **43.2%**였으며, 이는 에이전트가 종종 중간 단계를 완료할 수는 있지만 전체 워크플로우를 완료할 만큼 일관성을 유지하지 못함을 나타냅니다.
• 도메인 편차: 성능은 도메인에 따라 달라졌으며, "팀워크" 작업이 일반적으로 엄격한 수치적 제약과 도메인별 절차를 포함하는 "비즈니스" 및 "의료" 작업보다 쉬웠습니다.

실패 모드 분석

이 논문은 낮은 해결 점수를 설명하는 네 가지 근본적인 실패 모드를 식별합니다:

1. 장기 완료의 취약성: 성공 확률의 곱셈적 성질 ($p^N$) 로 인해, 높은 체크포인트별 정확도 (예: 95%) 라도 10~20 개의 체크포인트를 가진 작업의 경우 거의 0 에 가까운 해결 점수를 초래합니다.
2. 애플리케이션 간 워크플로우에서의 오류 연쇄: 단일 의미론적 오류 (예: 고객을 "개인"이 아닌 "회사"로 잘못 분류) 는 의존성 체인을 통해 조용히 전파되어, 에이전트가 작업이 완료되었다고 믿더라도 하류 검사가 실패하게 만듭니다.
3. 불안정한 자기 검증: 에이전트는 종종 수정 후 행동을 재검증하지 못합니다. 오류를 인식하고 수정을 시도한 후 수정이 성공했는지 확인하지 않고 다음 하위 작업으로 진행하여 "조용한" 실패를 초래합니다.
4. 높은 실행 간 변동성: 성능은 매우 불안정합니다. 동일한 모델이 동일한 작업에서 한 실행에서는 0.80 점, 다른 실행에서는 0.10 점을 기록할 수 있습니다. 이는 단일 실행 지표 (pass@1) 에 의존하는 현재 평가가 오해의 소지가 있음을 시사하며, pass@k 지표는 에이전트가 때때로 성공적인 경로를 찾을 수는 있지만 일관성이 여전히 주요 과제임을 보여줍니다.

중요성과 주장

이 논문은 SaaS-Bench가 전문적, 애플리케이션 간, 장기 환경에서 CUAs 를 평가하는 첫 번째 엄격하고 현실적인 테스트베드를 제공한다고 주장합니다. 그 중요성은 다음과 같습니다:

• 능력 격차 노출: LLM 의 발전에도 불구하고, 현재 에이전트는 현실 세계의 SaaS 환경에서 전문 워크플로우를 신뢰할 수 있게 해결할 능력이 없으며, 엔드투엔드로 완료된 작업이 4% 미만임을 보여줍니다.
• 평가 기준 재정의: 단기, 단일 애플리케이션 벤치마크는 불충분하다고 주장합니다. 이 분야는 에이전트가 장기간에 걸쳐 여러 시스템 간에 상태를 유지하고, 오류에서 복구하며, 조정하는 능력을 평가하는 방향으로 전환해야 합니다.
• 구조적 한계 식별: 결과는 주요 병목 현상이 지식 검색뿐만 아니라 계획, 상태 추적, 오류 복구에 있음을 강조합니다. 이 논문은 현재 에이전트 아키텍처가 장기 작업의 취약성을 처리하는 데 필요한 폐쇄 루프 검증 메커니즘이 부족하다고 제안합니다.

저자들은 SaaS-Bench 가 상당한 한계를 드러내지만, 더 신뢰할 수 있고 실제로 배포 가능한 컴퓨터 사용 에이전트에 대한 향후 연구에 필요한 기초를 제공한다고 결론지었습니다.