UniClawBench로 보는 2026년의 에이전트 벤치마크 — 살아 있는 컨테이너와 숨은 감독자

들어가며 — 정적 벤치마크가 저무는 자리에서
무엇이 새로운가 — 살아 있는 컨테이너와 단계별 체크포인트
닫힌 고리 — 실행자, 숨은 감독자, 사용자 에이전트
모델과 스캐폴드를 분리한다 — 다섯 가지 능력
마치며
참고 자료

들어가며 — 정적 벤치마크가 저무는 자리에서

앞서 코딩 평가에서 신호와 잡음을 가려내는 글에서, 가장 널리 쓰이는 코딩 벤치마크가 오염과 채점 결함으로 흔들린다는 이야기를 했습니다. 미리 기록된 정답을 맞히는 정적 방식은 암기와 하네스 차이에 취약합니다. 그렇다면 질문이 뒤집힙니다 — 도구를 직접 굴리는 에이전트 를 위한 벤치마크는 대체 어떻게 생겨야 할까요.

홍콩대(HKU) MMLab이 2026년 7월 9일 arXiv에 올린 UniClawBench 는 그 질문에 대한 구체적인 한 가지 답입니다. 부제는 "실제 과제에서 프로액티브 에이전트를 위한 범용 벤치마크"입니다. 여기서 프로액티브 에이전트란 일상적인 도구를 직접 조작하며 실제 환경에서 사용자를 돕는 에이전트를 뜻합니다.

저자들이 지목하는 기존 벤치마크의 한계는 세 가지입니다. 첫째, 대부분 샌드박스 환경 에 의존합니다. 둘째, 단일 턴 평가 방식이라 대화형 보조 작업의 실제 흐름을 담지 못합니다. 셋째, 시나리오 기반 과제 분류가 여러 능력을 한 범주에 뒤섞어 놓아, 에이전트가 실패했을 때 그 원인이 무엇인지 짚기 어렵습니다. UniClawBench는 스스로를 "동적인 실제 환경에서 프로액티브 에이전트를 평가하는 최초의 능력 중심 벤치마크"라고 소개합니다.

무엇이 새로운가 — 살아 있는 컨테이너와 단계별 체크포인트

가장 눈에 띄는 설계는 채점 방식입니다. 정적으로 미리 기록해 둔 정답과 문자열을 대조하는 대신, UniClawBench는 에이전트를 살아 있는 Docker 컨테이너 안에서 돌리고 세밀한 단계별 완료 체크포인트 로 채점합니다.

이 차이가 왜 중요한지는 실제 과제를 떠올리면 분명해집니다. "식당을 예약하고 그 일정을 캘린더에 넣어라" 같은 요청에는 중간 상태가 있습니다. 최종 답만 대조하는 방식은 그 문자열 하나만 봅니다. 반면 체크포인트는 "예약이 실제로 잡혔는가", "캘린더에 항목이 생겼는가"를 환경 안에서 단계마다 확인합니다. 사람 비서를 평가하는 방식에 훨씬 가깝습니다 — 결과물뿐 아니라 과정이 실제로 일어났는지를 봅니다.

물론 공짜는 아닙니다. 살아 있는 컨테이너는 정적 JSON 정답 파일보다 돌리는 비용이 크고, 결정적(deterministic)으로 유지하기도 더 까다롭습니다. 다만 이 비용은 에이전트가 실제로 무언가를 해냈는지 를 보기 위해 치르는 값이고, 정적 벤치마크가 놓치는 지점이 바로 거기입니다.

닫힌 고리 — 실행자, 숨은 감독자, 사용자 에이전트

두 번째 핵심 설계는 평가 루프 자체를 세 개의 에이전트로 짠 닫힌 고리(closed-loop) 입니다.

실행자(executor) 에이전트 — 실제로 과제를 수행합니다. 우리가 점수를 매기려는 대상입니다.
숨은 감독자(supervisor) 에이전트 — 단계별 체크포인트로 진행을 채점하되, 채점 기준을 노출하지 않습니다.
사용자(user) 에이전트 — 사람 사용자를 대신해 다중 턴 피드백을 줍니다.

User-Agent   →  다중 턴으로 요청·후속 질문·피드백을 전달
Executor     →  컨테이너 안에서 도구를 조작하며 과제를 수행
Supervisor   →  단계별 체크포인트로 진행을 채점 (기준은 숨긴 채)

"숨은"이 핵심입니다. 채점 기준이 대화에 새어 나오면 실행자는 과제를 해내는 대신 채점 기준에 맞는 말을 하도록 최적화될 수 있습니다. 감독자의 루브릭을 감춰 두면 그 지름길이 막힙니다 — 이는 앞 글에서 다룬 오염·게이밍 문제를 정면으로 겨냥한 설계입니다. 다중 턴 구성도 같은 맥락입니다. 실제 보조 작업은 한 번의 프롬프트가 아니라 대화이고, 사용자 에이전트가 그 후속 요청과 명료화를 공급합니다.

모델과 스캐폴드를 분리한다 — 다섯 가지 능력

UniClawBench는 400개의 이중 언어 과제를 다섯 가지 기초 모델 능력 으로 나눕니다 — 기술 사용(skill usage), 탐색(exploration), 긴 맥락 추론(long-context reasoning), 멀티모달 이해(multimodal understanding), 크로스 플랫폼 조율(cross-platform coordination). 과제마다 겨냥하는 능력이 정해져 있으니, 실패가 안개가 아니라 원인을 가리킵니다 — "탐색에서 무너졌다"와 "긴 맥락을 놓쳤다"를 구분할 수 있습니다. (참고로 어느 두 언어인지는 초록에 명시되어 있지 않습니다.)

가장 developer 관점에서 반가운 부분은 마지막입니다. 저자들은 베이스 모델의 능력과 프레임워크 수준의 설계 선택을 분리 하려고, 최신 모델들을 여러 에이전트 프레임워크 위에서 평가합니다. 이는 앞 글에서 확인한 사실 — 스캐폴드(하네스)만 바꿔도 점수가 몇 %p씩 움직인다 — 에 대한 정공법입니다. 스캐폴드를 고정하거나 의도적으로 바꿔 보지 않으면, 모델 A가 모델 B를 이긴 건지 A의 하네스가 더 좋았던 건지 알 수 없습니다.

한 가지는 분명히 해 둡니다. 초록은 모델과 프레임워크가 "성능을 함께 빚어낸다"는 결론을 제시하지만, 구체적인 순위나 점수를 초록에 담고 있지는 않습니다. 본문에 어떤 표가 있든 그것은 저자 보고값이며, 아직 독립적으로 재현·감사되지 않았습니다. 벤치마크와 코드는 공개한다고 밝히고 있으니, 검증은 커뮤니티의 몫으로 남습니다.

마치며

UniClawBench 한 편으로 2026년 에이전트 벤치마크 설계의 방향이 꽤 또렷하게 읽힙니다 — 정적보다 살아 있는 환경, 최종 답보다 단계별 체크포인트, 새어 나가는 루브릭보다 숨은 감독자, 그리고 모델과 스캐폴드의 분리. 이 네 가지는 점점 기본기가 되어 가고 있습니다.

물론 유보할 지점도 많습니다. 나온 지 며칠 된 논문이고, 수치는 저자 보고값이며, 이중 언어의 정체도 초록엔 없습니다. 살아 있는 컨테이너 방식은 비싸고 재현이 까다로우며, 어떤 벤치마크든 결국은 포화하고 게이밍됩니다 — 앞 글이 남긴 교훈 그대로입니다. 그래도 설계의 방향만큼은 옳습니다.

그러니 쓸모 있는 질문은 "누가 UniClawBench 1위인가"가 아닙니다. "환경이 살아 있고, 턴이 여러 번이고, 채점자가 기준을 알려 주지 않을 때, 내 에이전트가 버티는가"입니다. 리더보드 숫자 하나가 아니라 그 조건이 진짜 신호입니다.