계좌에 60달러가 있다. 작업하는 내내 최소 20달러는 남겨둬야 한다는 조건이 걸려 있다. 에이전트가 60달러짜리 수수료를 한 번에 결제한다. 그 순간 잔액은 0이 된다. 조건을 깼다.
결제는 시스템이 받아줬다. 얼마 뒤 환불과 조정이 들어오고, 마감 시점 잔액은 다시 20달러 위로 올라온다. 숫자만 보면 아무 일도 없었던 것처럼 보인다.
그래도 이 업무는 실패다. 승인받지 않은 송금은 돈이 나중에 돌아와도 컴플라이언스 위반으로 남는다. 중간에 한 번 선을 넘었다는 사실은 결과가 복구돼도 지워지지 않는다.
이 장면이 BizBench라는 벤치마크가 재려는 바로 그 지점이다. Ant International과 베이징대(Peking University) 연구진이 만들었다. 결제 회사의 실제 업무 절차를 그대로 옮긴 환경에서, 여러 단계의 업무를 이어서 처리하는 AI(이하 에이전트)를 시험한다. 보통의 평가는 "일을 끝냈는가"만 본다. BizBench는 "끝내는 과정에서 규칙을 지켰는가"까지 본다. 그것도 사람 심판의 감이 아니라, 미리 정한 규칙으로 같은 기록에 늘 같은 판정을 내리는 방식으로 — 이를 결정론적 채점이라고 한다.
50개 과제에 최신 모델들을 돌렸다. 최상위 모델조차 엄격 성공률은 60%대에 머물렀다. 그리고 결과만 보는 평가가 여태 가려온 것 — 결과는 맞았는데 과정에서 규칙을 어긴 실행 — 이 똑똑히 드러났다.
기존 벤치마크 대부분은 마지막 상태만 본다. 저장소 이슈를 고쳤는가(SWE-bench), 최종 애플리케이션 상태가 맞는가(AutomationBench) 같은 식이다. 최종 상태만 채점하면, 거기까지 가는 길에서 벌어진 위반은 집계에서 사라진다. 앞의 60달러처럼. BizBench는 중간 행동 하나하나를 그 시점에 유효한 규칙에 비추어 본다. 갈림길이 여기다.
규칙을 지키는 일이 왜 그렇게 어려운가. 규칙 자체가 어지럽기 때문이다. 현실의 업무 규칙은 정책 매뉴얼과 FAQ, 운영 공지에 흩어져 있다. 서로 다른 팀이 서로 다른 시점에 고친다. 낡은 지침이 현행 정책 옆에 멀쩡히 살아 있다. 겉보기엔 충돌하는 두 지침이 실은 적용 대상만 다른 경우도 있다 — 나라가 다르거나, 상품이 다르거나, 유효 기간이 다르거나. 만료된 보험 약관이라도 약관이 살아 있던 시절의 사고는 여전히 보장하는 것과 같다. 그래서 "관련 문서를 검색해 찾기"로는 부족하다. 지금 이 거래에 권위 있고, 현행이며, 적용 가능한 규칙이 어느 것인지를 골라내야 한다. BizBench는 낡고 충돌하는 지침을 환경 안에 일부러 섞어 넣는다. 이 '선택'을 과제의 일부로 만든 것이다.
BizBench는 한 과제를 세 각도에서 채점한다.
세 검사를 모두 통과해야 과제 성공으로 센다. 그래서 이름이 '엄격 성공(strict success)'이다. 설계 의도는 분명하다. 좋은 결과 하나로 중간의 위반을 덮게 두지 않는다. 그렇다고 정해진 정답 경로 하나를 강요하지도 않는다. 조건만 충족하면 서로 다른 정당한 전략을 모두 인정한다.
채점은 사람이 아니라 기계가 정해진 규칙으로 한다. 업무 상태와 거래 내역 장부(원장), 영수증, 이벤트 이력을 증거로 삼아, 실제로 실행된 행동과 제안·승인·거부에 그친 시도를 구분한다. 승인이 실제 실행된 조건을 정확히 덮는지, 순서상 승인이 작업보다 먼저였는지를 중간중간 확인한다. 최소 준비금처럼 작업 내내 지켜야 하는 조건은 상태가 바뀌는 매 지점마다 다시 검사한다.
한 가지가 이 채점을 특히 까다롭게 만든다. 고객이 처음부터 "알아서 다 해"라고 백지 승인을 주지 않는다는 점이다. 고객 역할은 시뮬레이터가 맡아, 여러 턴의 대화로 정보를 흘려주고 승인 요청에 답한다. 승인은 구체적인 요청과 그 시점의 조건에 묶여 기록된다. 조건이 바뀌면 기존 승인은 효력을 잃고, 다시 받아야 한다. 이 규칙 하나가 뒤에서 결과를 가른다.
기술 노트 — BizBench 환경 - 동결된 릴리스 기준 50개 과제, 지식 문서 789개. - 에이전트가 상시 쓰는 도구는 9개이고, 이를 통해 601개 업무 기능을 발견·호출한다. 고객 시뮬레이터 전용 도구는 10개. - 모든 실행은 데이터베이스의 독립 복사본 위에서 돌아간다. 한 과제가 다른 과제를 오염시키지 않는다. - 러너는 누적 토큰·도구 호출·스케줄러 스텝에 상한을 두지 않고(벽시계 타임아웃과 도구 오류 임계값만 유지), 컨텍스트가 넘치면 지식 검색·문서 읽기 응답 중 가장 오래된 4분의 1을 교체하되 전체 실행 기록은 보존한다. - 세 검사를 모두 통과했다는 조건을 논문은 G ∧ P ∧ F로 표기한다.
숫자를 보기 전에 열의 뜻부터. 목표·과정·보호는 각 검사를 통과한 비율이다. 중간실패(IF)는 결과가 어떻든 중간에 규칙을 어긴 실행의 비율이다. 엄격성공은 세 검사를 모두 통과한 비율이다. 모두 백분율. 그리고 조건이 하나 붙는다. Claude Opus 5와 Muse Spark 1.3은 과제당 1회 실행이고, 나머지는 3회 실행한 뒤 한 번의 실행이 성공할 값을 평균한 것이다.
| 모델 | 목표 | 과정 | 보호 | 중간실패(IF) | 엄격성공 |
|---|---|---|---|---|---|
| Claude Opus 5 (1회) | 64.0 | 96.0 | 98.0 | 4.0 | 64.0 |
| GPT-6 Sol | 64.7 | 94.7 | 100.0 | 5.3 | 61.3 |
| GLM-5.3-Flash | 48.0 | 79.3 | 87.3 | 29.3 | 43.3 |
| DeepSeek-V4.1-Flash | 46.7 | 92.0 | 96.7 | 9.3 | 43.3 |
| DeepSeek-V4-Pro | 41.3 | 85.3 | 88.7 | 24.7 | 39.3 |
| Muse Spark 1.3 (1회) | 38.0 | 94.0 | 98.0 | 6.0 | 38.0 |
| Qwen3.8-27B | 42.0 | 74.0 | 93.3 | 28.0 | 32.7 |
| DeepSeek-V4-Flash | 7.3 | 53.3 | 95.3 | 47.3 | 5.3 |
| Qwen3.5-397B-A17B | 1.3 | 46.7 | 93.3 | 56.7 | 0.7 |
| Qwen3.5-9B | 0.0 | 18.7 | 89.3 | 83.3 | 0.0 |
맨 윗줄부터. 최상위 모델인 Claude Opus 5와 GPT-6 Sol의 엄격 성공률은 각각 64.0%, 61.3%다. 눈에 띄는 건 이 두 모델의 목표 점수와 엄격 성공이 거의 붙어 있다는 점이다(Opus 5는 둘 다 64.0, GPT-6 Sol은 목표 64.7에 엄격 61.3). 과정 검사에서 깎여 점수가 낮아진 게 아니라는 뜻이다. 이들에게 어려운 건 중간에 규칙을 지키는 일이 아니라, 업무 전체를 끝까지 완수하는 일 그 자체다.
그러면 결과만 보면 놓치는 위반은 어디서 드러나나. 목표와 엄격 성공 사이가 벌어진 모델을 보면 된다. Qwen3.8-27B는 목표를 42.0% 달성하지만 엄격 성공은 32.7%로 떨어진다. 결과만 봤다면 42%짜리 성능으로 읽혔을 실행이, 과정의 유효성까지 따지자 10%포인트 가까이 깎였다. 결과 기반 평가가 무효한 실행을 성공으로 집계할 수 있다는 우려가, 여기서 숫자로 확인된다.
말이 아니라 실제 실행에서도 그대로 나왔다. DeepSeek-V4.1-Flash의 네 번 실행은 목표를 달성했고 마감 시점 현금 준비금도 요구 임계값 위에서 끝냈다. 그런데 중간 어느 단계에서 그 임계값을 이미 한 번 깬 뒤였다. 겉으로는 성공, 과정으로는 실패. 글머리의 60달러 장면이 실제 모델에서 재현된 셈이다.
여기까지가 수치가 분명히 말해주는 것이다. 완수 자체가 어렵다는 것, 그리고 결과만 보면 위반이 가려진다는 것. 수치가 말해주지 않는 것도 있다. 엄격 성공률 64%가 "모델이 아직 멀었다"는 신호인지 "벤치마크가 현실 결제 업무의 난이도를 정직하게 담았다"는 신호인지는, 이 한 숫자로 가를 수 없다. 둘이 섞여 있을 것이다.
같은 모델도 돌릴 때마다 결과가 출렁인다. GPT-6 Sol은 세 번 실행해서 세 번 다 성공한 과제가 40.0%에 그쳤다. "선택한 실행 전부에서 성공한 과제의 비율"을 일반화한 지표를 pass^k라고 부르는데, 복잡한 계산을 걷어내고 말하면 '여러 번 시켜서 매번 통과하느냐'를 보는 잣대다. 한 번은 되고 한 번은 안 되는 불안정성이 여기서 드러난다. 그래서 과제당 1회만 돌린 Opus 5·Muse Spark 1.3과 3회 평균을 낸 나머지를 한 표에서 비교할 때는, 1회 실행이 운 좋은·나쁜 실행을 평균으로 눌러주지 못한다는 점을 감안해 읽어야 한다.
실행 기록에는 신뢰성 말고 효율의 신호도 남는다. DeepSeek-V4.1-Flash는 한 번 실행에 평균 191.3회 도구를 호출했다. 모범 실행보다 약 70% 많다. 목표를 꽤 맞추는 모델조차 상당한 낭비를 안고 간다. 작은 모델에서는 더 극적이다. Qwen3.5-9B는 평균 187.2회를 호출했고 그 절반 이상이 오류였다. 오류의 주원인은 비공개 자원에 접근하려는 시도였고, 150번 실행하는 동안 모든 과제의 목표를 달성한 사례는 한 번도 없었다. 그래서 호출 횟수 자체보다, 실패한 호출을 원인별로 갈라보는 게 먼저다. 권한 밖 자원을 계속 두드린다면 그건 성능 문제가 아니라 권한 모델의 문제다.
보호 점수는 표 전체에서 유독 높다. 꼴찌인 Qwen3.5-9B조차 보호가 89.3이다. 여기서 "보호는 쉬운 능력"이라고 결론 내리기 쉽다. 그러나 보호 대상을 건드리지 않은 것과 업무를 안전하게 완수한 것은 다르다. 목표에 거의 닿지 못한 실행은, 애초에 위험한 행동을 할 기회 자체가 적었을 뿐일 수 있다. 아무것도 제대로 못 하면 깨뜨릴 것도 없다. 보호 점수는 따로 떼어 읽지 말고, 그 모델이 목표를 얼마나 달성했고 실제로 얼마나 행동했는지와 함께 봐야 뜻이 산다.
그렇다면 완수에 실패한 모델은 '어디서' 실패했을까. 이 질문에 논문이 답을 다 주지는 않는다. 논문이 관찰로 짚은 건 Qwen3.5-9B 사례처럼 권한 밖 자원 접근이 오류를 키웠다는 정도다. 여기서부터는 실무 관점의 정리다. 실패 지점은 대체로 셋으로 갈린다. 어느 규칙을 적용할지 잘못 고르는 규칙 선택, 승인의 범위나 순서를 어기는 승인 관리, 작업 순서를 틀리는 실행 순서. 셋은 처방이 다르다. 규칙 선택이 문제면 규칙 저장소의 메타데이터와 검색을, 승인 관리가 문제면 승인과 실행을 맞춰보는 로직을, 실행 순서가 문제면 계획과 게이트 설계를 손봐야 한다. 어느 쪽인지 가르려면 실행의 중간 기록이 남아 있어야 한다. 결과만 적힌 로그로는 애초에 진단이 안 된다.
채점기를 믿을 수 있어야 점수도 의미가 있다. 연구진은 과제마다 모범 실행 기록 하나를 만들어 둔다. 규칙을 다 지키면서 그 과제를 실제로 풀어낸 기록이다(논문은 골든 트레이스라 부른다). 이게 있다는 건, 목표·과정·보호를 동시에 만족하는 해가 적어도 하나는 존재한다는 보장이다. 여러 작업이 공유 자원과 타이밍으로 얽히면, 따로따로는 가능한 일들이 함께 놓였을 때 양립 불가능해지기도 한다. 그래서 작업을 개별 검증한 뒤에도 전체 과제를 처음 상태부터 다시 재생해 상호작용을 확인한다. 공개된 50개 과제는 모두 이 모범 실행을 통과한다.
채점기는 거꾸로도 시험한다. 같은 목표를 다른 경로로 푼 유효한 실행은 통과시키고, 특정 요건을 일부러 깨뜨린 실행은 떨어뜨려야 한다. 앞의 준비금 예처럼 중간에 선을 넘었다가 나중에 복구한 실행은 과정 검사에서 반드시 실패해야 한다. 거래의 유효성을 좌우하는 사실을 바꾸면 판정도 따라 바뀌어야 하고, 반대로 결과가 같은 변형 — 같은 작업을 다시 불러도 결과가 달라지지 않는 재시도 같은 것 — 은 판정을 바꾸지 말아야 한다. 연구자 5명과 업무 도메인 전문가 팀이 과제와 합격 검사를 고객 요청·문서·기록에 비추어 검토했고, 어긋난 곳은 고쳐 다시 돌렸다.
벤치마크는 하나의 선도 결제 회사 절차에 뿌리를 둔다. 기밀 때문에 민감한 세부는 추상화하고 다시 썼으니, 실제 운영 환경의 모든 결을 담았다고 보긴 어렵다. 과제 수 50개는 깊이, 즉 길고 여러 워크플로가 얽힌 과제를 택하는 대신 넓이를 양보한 선택으로 보인다. 그러니 이 점수를 모든 산업, 모든 도메인 에이전트의 신뢰성으로 넓히면 과장이다. 저자들도 이걸 "복잡한 비즈니스 환경에서 과제 완료를 넘어선 신뢰성"을 재는 테스트베드로 선을 긋는다.
구조적 한계도 밝혀둔다. 고객 시뮬레이터로 DeepSeek-V4.1-Flash를 쓰기 때문에, 시뮬레이터 자체의 안정성이 평가에 영향을 줄 수 있다. 논문은 이를 별도 절(5.6)과 부록에서 따로 점검한다.
마지막으로 역할을 헷갈리면 안 된다. BizBench는 위반을 실행이 끝난 뒤에 찾아내는 평가기다. 실제 제품에 필요한 건 위반이 일어나기 전에 막는 장치다. 둘은 다른 물건이다. 그리고 기계가 딱 떨어지게 판정하기 어려운 영역 — 애매한 정책 해석 같은 것 — 이 남는다면, 거기에 사람 검토를 어디서 끼울지는 미리 정해 둬야 한다.
소기업 고객사의 AI PM에게 요청이 하나 들어온다. "다음 달 광고 예산을 재배분해줘." PM은 승인을 받고 재배분 계획을 짠다. 여기까지는 깔끔하다.
작업 도중 고객이 한마디를 덧붙인다. "아, 남는 예산으로 외주 디자이너 잔금도 정리해줘." 사람 담당자라면 자연스럽게 묶어 처리할 요청이다. 그런데 바로 이 지점에 BizBench가 집어낸 함정이 그대로 들어 있다.
처음 받은 승인은 '광고 예산 재배분'까지였다. 잔금 집행은 거기 없던 새 지출이다. 집행의 금액과 범위가 바뀌었으니, 기존 승인은 이 새 집행을 덮지 못한다. 다시 받아야 한다. 게다가 잔금 집행은 돈을 빼내는 일이라 월 운영 준비금 하한을 건드릴 수 있고, 외주 계약 단가는 작년 버전과 올해 버전이 드라이브 어딘가에 함께 살아 있을 수 있다 — 어느 쪽이 지금 유효한 단가인지 골라야 한다.
올바른 처리는 한 줄기로 이어진다. 집행 범위가 바뀐 것을 먼저 알아차리고, 기존 승인이 이 집행까지 덮는지 확인하고, 못 덮으면 재승인을 요청하고, 준비금 하한을 깨지 않는지 확인한 뒤 실행한다. 최종 결과만 보는 자동화는 이 과정을 건너뛰고 "예산 재배분 완료, 잔금 지급 완료"라고 보고하고 끝난다. 그사이 준비금을 잠깐 깼거나, 바뀐 범위를 재승인 없이 집행했거나, 만료된 단가를 적용했다면 — 화면상으로는 멀쩡해도 컴플라이언스상으로는 사고다.
온틀은 이 흐름의 앞부분을 이미 제품에 넣어 뒀다. 외부로 나가는 발신은 승인 게이트를 먼저 통과시키고, 되돌리기 어려운 작업은 실행 전에 계획을 확정받는다. '최초 집행 전에 승인을 받는다'는 단계는 작동한다는 뜻이다. 아직 설계가 더 필요한 쪽은 그다음이다. 작업 중간에 집행 조건이 바뀌었을 때 기존 승인을 자동으로 무효 처리하고 재승인을 요구하는 것, 그리고 준비금 하한처럼 작업 내내 지켜야 하는 한도를 매 단계 검사하는 것. 조건과 상태에 묶인 이 중간 검사를 자동화 로직의 정식 단계로 끌어올리는 일이, 우리에게 남은 설계 과제다.