MMORPG 샌드박스로 장기 협업을 측정하는 AgentWorld 벤치마크

무엇인가

기존 멀티에이전트 벤치마크는 대부분 경쟁 구도이거나 20스텝 이하의 단기 상호작용을 다루고, 여러 에이전트의 개별 성능을 단순 합산하는 방식이었다. 저자들은 이것으로는 LLM 에이전트의 '진짜 협업 능력'을 분리해 측정할 수 없다고 본다. 실제 소프트웨어 개발이나 과학 연구 같은 과제는 역할이 다른 여러 에이전트가 공유 목표를 향해 오래 조율해야 하는데, 기존 평가는 그 부분을 비켜간다는 문제의식이다.

어떻게 동작하나

제안하는 AgentWorld는 오픈소스 MMORPG 엔진 Kaetram 위에 구축된 샌드박스다. 1056×768 타일, 9개 바이옴, 380여 개 아이템, 144종 몹(레벨 1~250+), 70여 개 NPC, 8개 스킬(벌목·채광·낚시·채집·제작·대장·화살제작·요리)에 걸친 1,531개 채집 노드를 갖췄다. 핵심 설계는 저수준 조작을 감추는 것이다. move, attack, harvest, craft, transfer, chat 등 13개의 고수준 API 도구만 노출해서, attack_entity가 경로 탐색부터 전투·전리품 수집까지 한 번에 처리한다. 즉 에이전트의 의사결정 예산이 '어떻게 조작할까'가 아니라 '무엇을 하고 누구와 조율할까'에 쓰이도록 만들었다. 환경은 실시간이지만 평가 재현성을 위해 턴제로 바꿔, 매 라운드 모든 에이전트가 순차적으로 새 관측을 받고 API 호출 하나를 선택한 뒤 다음 에이전트로 넘어가는 라운드로빈 방식으로 돌아간다. 모든 실험은 블랙박스 설정에서 수행되며, 에이전트는 다른 에이전트의 내부 상태·관측·행동 이력을 볼 수 없고 오직 환경을 통해 라우팅되는 명시적 채팅 메시지로만 협업한다.

무엇과 다른가

과제는 사람이 주석한 100개와 Claude Opus 4.5로 생성하고 사람이 품질을 검증한 증강 변형 100개로 구성된다. 각 과제는 다중 에이전트 협업이 필요한 주 목표, 비대칭 역할·스킬·스폰 위치·시작 아이템을 담은 에이전트 구성, 라운드 예산, 과제별 게임 문서, 그리고 최종 게임 상태를 검사하는 파이썬 성공 판정 함수를 갖는다. 어떤 단일 에이전트도 혼자 성공할 수 없도록 설계됐다. 예로 Task 67(Resource Caravan)은 3개 바이옴에 걸친 8개 에이전트가 필요하다. 리더가 숲의 벌목 팀 둘과 산의 광부들을 조율하고, 제작자가 양쪽에서 재료를 받아 곡괭이를 만든다. 누가 무엇을 캘지 협상하고, 지역 간 자원 수량을 전달하고, 공유 집결지에서 자원을 넘겨야 한다. 과제는 8개 범주(전투·제작·채집·거래·탐험·생존·건설·조율)에 걸쳐 있고, 에이전트 수는 3~20개(3개가 45개 과제로 최다, 20개까지 긴 꼬리), 라운드 예산은 25~55(평균 38)다.

어떻게 쓰나

평가 지표는 세 가지다. 성공률(SR)은 과제별 파이썬 검증기가 최종 게임 상태(인벤토리 아이템 수, 킬 수, 생존 여부 등)를 검사해 판정한다. 부분 성공률(PSR)은 검증기가 보고하는 체크포인트 달성 비율의 평균이다. 여기에 더해 저자들은 Causal Collaboration Effectiveness(CCE)를 제안한다. SR이 '무엇을 달성했나'만 재고 '얼마나 협업적으로 달성했나'는 못 잰다는 문제, 그리고 LLM-as-judge 방식의 협업 품질 점수(예: '조율을 1~5로 평가')가 주관적이고 판정 모델이 바뀌면 흔들린다는 문제를 지적한다. CCE는 과제 궤적 위에 인과 행동 그래프를 만든다. 먼저 목표를 직접 달성한 성공 행동을 찾고, 라운드를 거꾸로 훑으면서 각 라운드마다 LLM에게 '이미 기여 행동으로 판정된 행동을 인과적으로 가능하게 한 행동이 무엇인가'를 이진 판단으로 묻는다. 이 BFS 유사 과정으로 성공까지의 인과 경로에 있는 모든 행동 집합 C를 모으고, CCE = |C|/|T|(T는 전체 행동 집합)로 계산한다. 실패 과제는 정의상 CCE=0이다. 판정 LLM은 '새우 낚시가 나중의 새우 전달을 가능하게 했는가' 같은 객관적 이진 판단만 하므로, 주관적 품질 평가보다 판정 모델 버전 간 재현성이 높다고 주장한다.

전제와 한계

실험은 Gemini 3 Flash, Claude Haiku 4.5, GPT-5 Mini, DeepSeek R1-70B 네 모델을 동일한 시스템 프롬프트·템플릿·도구 정의로 돌린다. 본 세트에서 Gemini 3 Flash가 SR 52.0%로 1위, Claude Haiku 4.5 45.0%, GPT-5 Mini 36.0%, DeepSeek R1-70B 20.0% 순이다. PSR은 모든 모델에서 SR보다 높아 DeepSeek 43.5%에서 Gemini 71.5% 사이다. CCE는 DeepSeek 0.125에서 Gemini 0.320으로, 최고 모델조차 전체 행동의 3분의 1 미만만 성공에 인과적으로 기여한다. DeepSeek은 약 88%의 행동이 낭비된 셈이다. 행동 양상도 갈린다. Gemini는 라운드를 가장 적게(26.4) 쓰고, DeepSeek은 채팅을 가장 적게(7.5) 보내며, GPT-5 Mini는 행동을 가장 많이(131.3) 하고 메시지도 가장 많이(44.1) 보낸다. 증강 세트에서는 전 모델이 크게 하락해 Gemini 52→24%, Claude 45→26%, GPT-5 36→21%, DeepSeek 20→10%가 됐다. 범주별로는 생존이 가장 쉽고(모델별 50~100% SR, 평균 통과율 67~100%) 조율(0~50%, 평균 12%)·건설(0~60%, 평균 20%)·거래(8~46%)가 가장 어렵다. 성공 과제만 조건으로 보면 Claude가 과제당 협업 효율 0.653으로 Gemini(0.609)보다 높고 GPT-5 Mini가 0.571로 가장 낮다.

저자들은 CCE의 신뢰성을 여러 방식으로 검증한다. 사람 주석자와 GPT-4.1 판정을 84개 행동-기여 판단에서 비교했을 때 82% 원시 일치, Cohen's κ=0.64('상당한' 수준)였다. 두 판정 모델(GPT-4.1 vs Claude Sonnet 4) 간 일치도 κ=0.66(84% 원시, 7,298개 결정)으로 비슷한 수준이었다. 즉 사람과 판정 모델의 일치가 서로 다른 판정 모델 간 일치와 비슷하다는 것이다. 판정 모델을 GPT-4.1, Claude Sonnet 4, Llama-4 Maverick으로 바꿔도 모델 순위(Gemini > Claude > GPT-5 > DeepSeek)는 완전히 보존되고 절대값 변동은 최대 약 0.05에 그쳤다. 다만 저자들은 의도적으로 관대한 라벨링 정책을 써서 주변적으로라도 도움이 된 행동을 기여로 세므로, CCE를 '진짜 유용한 행동 비율의 상한'으로 읽어야 한다고 밝힌다.

베이스라인과 절제 실험도 설계를 뒷받침한다. 무작위 행동은 5.7%, 단일 에이전트가 모든 역할과 아이템을 맡는 베이스라인은 28.6%만 성공해 과제가 실제로 다중 에이전트를 요구함을 보인다. 통신을 끄면 성능이 떨어지고, 사람이 쓴 공유 계획을 먼저 주고 통신을 막으면 오히려 조금 더 나빠진다(22.9% vs 17.6%). 실행 중 계획을 수정할 수 없으면 팀원 진행 상황을 확인하거나 가정이 깨졌을 때 복구할 수 없기 때문이다. 오라클 통신(한 에이전트가 모든 메시지를 보고 팀을 조율)은 52.0%를 60.0%로 올리지만, 그럼에도 40%가 실패한다는 것은 난이도가 분산 구조만의 문제가 아니라 장기 계획과 자원 배분 자체에 내재한다는 뜻이다. 35개 과제 부분집합 절제 실험에서는 전체 54.3% 대비 과제별 문서를 빼면 29.4%, 라운드 예산을 50에서 10으로 줄이면 37.1%, 스폰 위치를 무작위화하면 51.4%로 떨어졌다. 문서와 지평이 가장 큰 하락을 만든다는 것은 이 요소들이 없으면 협업이 아니라 정보 수집과 시간 압박이 병목이 된다는 의미다. Gemini 3 Flash를 시드 42·819·314로 3회 돌린 결과 SR은 매번 54.3%(표본 표준편차 0.0%p)였고, 라운드는 18.77·15.25·18.91(표준편차 2.07), 채팅은 4.69·4.50·4.34(표준편차 0.18)였다. 통신 오류를 Gemini 3 Flash의 100개 과제 궤적에서 군집화하면 6가지 유형으로 나뉘고, 가장 큰 유형은 '진부하고 중복된' 메시지로 오류의 37.7%를 차지한다. 원인은 다른 에이전트의 상태를 잘못 이해하거나 예측하는 것으로 추정된다.

개발자 관점에서 이 논문의 실용적 시사점은 명확하다. 첫째, 멀티에이전트 파이프라인을 평가할 때 성공률만 보면 착시가 생긴다. 한 에이전트가 일을 다 하고 나머지가 놀아도 SR은 100%가 될 수 있다. CCE처럼 '전체 행동 중 성공에 인과적으로 기여한 비율'을 별도로 추적하면 낭비되는 행동과 역할 중복을 드러낼 수 있다. 둘째, 통신량이 협업 성능을 예측하지 않는다. 채팅을 가장 많이 보낸 GPT-5 Mini가 3위였고, 실패 과제에서 행동의 26%를 채팅에 썼다. DeepSeek은 첫 메시지를 평균 5라운드에 보내 초기 조율 창을 놓쳤다. '조율에 충분하되 생산적 행동을 밀어내지 않을 만큼'의 통신 예산을 설계 변수로 다뤄야 한다. 셋째, 계획은 실행 중 수정 가능할 때만 값을 한다. 고정 배정은 팀원 진행을 확인할 수단이 없으면 오히려 발목을 잡는다. 넷째, PSR과 SR의 격차(예: Gemini 71.5% vs 52.0%)는 에이전트가 협업을 시작은 하지만 후반부 조율에서 무너진다는 신호이므로, 중간 체크포인트 기반 모니터링이 유용하다.

한계도 저자들이 직접 밝힌다. 3회 반복 실행은 단일 모델에 대한 분석이라 모델 간 안정성이나 모델 차이의 통계적 유의성을 확립하지 못한다. 집계 SR이 같다고 개별 과제 결과가 같다는 뜻도 아니다. CCE는 여전히 인과 판단에 LLM을 쓰며, 관대한 라벨링 정책 때문에 상한값으로 읽어야 한다. 또한 과제 설계상 문서 제공과 충분한 라운드 예산이 전제되어 있어, 이 요소들을 제거하면 협업 능력이 아니라 정보 수집·시간 압박이 점수를 좌우한다. 벤치마크는 시뮬레이션 샌드박스이므로 실제 프로덕션 환경의 협업 난이도와 1:1로 대응하지는 않는다.