ENTERPRISEOPS-GYM: 기업 환경에서의 상태 기반 에이전트 계획 및 도구 활용을 위한 환경과 평가

기존 AI 에이전트 벤치마크는 단순한 API 호출의 정확도에만 집중했으나, 실제 기업 환경은 복잡한 데이터베이스 상태 변화와 엄격한 보안 정책이 얽혀 있다. 이 논문은 실제 업무와 유사한 고충실도 샌드박스를 제공하여 현재 AI가 자율적인 기업 업무 수행에 있어 '전략적 계획 수립' 능력이 가장 큰 병목임을 입증했다.

LLM은 Attention을 통해 문맥을 이해하고 Embedding 공간에서 유사한 정보를 찾는 데 능숙하다. 하지만 기업 업무는 단순한 문맥 이해를 넘어, 수십 개의 테이블이 얽힌 데이터베이스의 외래 키 관계나 엄격한 보안 정책 같은 명시적 제약 조건을 만족해야 하는 '상태 기반(Stateful)' 환경이다.

ENTERPRISEOPS-GYM은 이러한 제약 조건을 시스템의 '상태'로 정의한다. 에이전트가 도구를 하나 사용할 때마다 데이터베이스 상태가 변하며, 이 변화가 다음 도구 선택의 논리적 제약이 된다. 이는 단순한 다음 토큰 예측을 넘어선 고차원적 논리 추론과 제약 조건 만족(Constraint Satisfaction) 능력을 요구한다.

실험 결과, 모델의 크기를 키우거나 추론 시간(Thinking Budget)을 늘리는 것보다 '어떤 순서로 도구를 사용할지'에 대한 전략적 사고가 성능에 더 결정적인 영향을 미친다는 점이 확인됐다. 이는 현재의 AI 에이전트가 도구 사용법(Syntax)은 익혔으나, 문제를 해결하기 위한 전략적 순서(Logic)를 짜는 데는 여전히 한계가 있음을 의미한다.

8개 도메인(CSM, HR, ITSM, Email, Calendar, Teams, Drive, Hybrid)을 선정하고 각 도메인에 특화된 데이터베이스 스키마와 512개의 API 도구를 설계했다. 도메인 전문가들이 실제 업무 시나리오를 바탕으로 1,150개의 작업을 생성했으며, 각 작업은 평균 9.15단계의 실행 과정을 포함한다.

검증 시스템은 결과 기반(Outcome-based) 방식을 채택했다. 작업 완료 후 SQL 스크립트를 실행하여 [최종 DB 상태 → 조건 일치 여부 확인 → 성공/실패 판정] 순으로 평가한다. 이는 에이전트가 중간에 어떤 경로를 택하든 최종 결과의 무결성과 정책 준수 여부만을 엄격히 따지는 방식이다.

평가 지표로는 pass@1을 사용했다. [N번의 독립적인 실행 결과] → [성공한 횟수가 1회 이상인지 확인] → [전체 시도 중 성공 비율 계산] 순으로 산출하며, 에이전트가 단 한 번의 기회에 작업을 완벽히 완수할 확률을 측정한다. 또한 불가능한 작업(Infeasible tasks)을 포함하여 에이전트의 안전한 거절 능력도 평가했다.

Claude 4.5가 37.4%의 성공률로 1위를 기록했으나, 이는 실무 투입이 가능한 수준에 크게 못 미치는 결과이다. 특히 ITSM(28.5%)이나 하이브리드(30.7%)처럼 여러 시스템이 얽힌 복잡한 도메인에서 성능이 급격히 하락하는 양상을 보였다.

인간이 작성한 계획(Human Plans)을 주입했을 때 성능이 14~35%p 향상되었다. 이는 에이전트의 실패 원인이 도구 호출 기술 부족이 아니라, 복잡한 제약 조건을 고려한 장기 계획 수립 능력의 부재에 있음을 시사한다. 반면 단순히 추론 토큰(Thinking tokens)을 늘리는 것은 특정 도메인에서 성능 정체 현상을 보였다.

불가능한 작업(Infeasible tasks)에 대한 거절 능력 평가에서 최선의 모델도 53.9%의 정확도에 그쳤다. 이는 에이전트가 잘못된 명령을 무비판적으로 수행하여 시스템 상태를 오염시키거나 보안 정책을 위반할 위험이 큼을 보여준다.

164개의 테이블과 512개의 도구로 구성된 복잡한 관계형 데이터 생태계를 Docker 컨테이너로 격리하여 제공한다. 각 테이블은 평균 1.7개의 외래 키(Foreign Key)로 연결되어 있어 에이전트가 데이터 간의 관계를 정확히 이해해야만 유효한 인자를 생성할 수 있다.

실패 모드 분석 결과, '전제 조건 조회 누락(Missing Prerequisite Lookup)', '연쇄적 상태 전파 실패(Cascading State Propagation)', '잘못된 ID 해석(Incorrect ID Resolution)' 등이 주요 원인으로 식별되었다. 이는 에이전트가 시스템의 상태 변화를 실시간으로 추적하고 관리하는 데 어려움을 겪고 있음을 나타낸다.

검증기는 세 가지 유형으로 나뉜다. i) Task Completion(주요 목표 달성 여부), ii) Integrity Constraints(외래 키 관계 등 DB 무결성 유지 여부), iii) Permission and Process Compliance(보안 정책 및 절차 준수 여부)를 각각 SQL로 검증하여 다각적인 성능 분석을 가능하게 한다.

현재 벤치마크는 텍스트 기반의 도구 사용에 집중되어 있으며, GUI 조작이나 멀티모달 입력 처리는 포함되지 않았다. 또한 30개의 불가능한 작업 시나리오는 전체 규모에 비해 다소 적어 더 광범위한 안전성 평가가 필요하다.