MTG Bench: LLM들이 Magic: The Gathering을 얼마나 잘 플레이하는지 테스트

Who Should Read

LLM의 실제 추론 능력을 평가하는 새로운 방법에 관심 있는 AI 개발자, 또는 에이전트 루프에서 MCP 서버와 토큰 비용 최적화를 고민하는 개발자.

Core Mechanics

• 이 벤치마크의 핵심 아이디어는 'LLM이 MTG를 잘 플레이할 만큼 똑똑하다면, 별도의 규칙 엔진 없이도 복잡한 규칙을 따를 수 있다'는 것이다. 규칙 엔진이 있으면 성능 하한선은 올라가지만 시뮬레이션의 전반적인 품질을 개선하지는 않는다고 판단해서 일부러 사용하지 않았다.
• 전체 순위는 gpt-5.5 medium(95.4) > claude-fable-5 medium(90.3) > gpt-5.4 medium(88.6) > gemini-3.5-flash medium(85.7) 순이었고, deepseek-v4-pro high는 12.8점으로 최하위였다.
• 비용 대비 성능을 보면 gpt-5.4 medium이 점수 88.6에 턴당 $0.06로 가장 균형이 좋다. gpt-5.5 medium은 점수 95.4지만 비용이 $0.10으로 올라가고, claude-fable-5 medium은 90.3점에 $0.30으로 가장 비싸다.
• LLM은 실제로 규칙에 맞는 턴을 수행하는 것보다 시뮬레이션된 턴이 합법적인지 평가하는 데 훨씬 더 뛰어났다. 이 특성을 이용해 채점과 합법성 검사는 모두 gpt-5.5 medium으로 진행했다.
• 각 LLM에게 MCP(Model Context Protocol) 서버에 접근권을 줬는데, 이 서버는 덱 맨 위에서 카드 뽑기, 덱 아래로 카드 돌려보내기, 셔플 같은 기본 라이브러리 조작만 제공한다. scry나 surveil 같은 고급 조작은 LLM이 여러 기본 툴 호출을 조합해서 직접 처리해야 한다.
• MCP 서버를 선택한 이유 중 하나는 OpenAI와 Anthropic API가 원격 MCP 서버 URL을 직접 지정할 수 있어서, 에이전트 루프를 API 제공사가 처리하게 할 수 있기 때문이다. 이렇게 하면 하나의 API 호출로 처리되어 OpenAI 기준으로 툴 호출 사이마다 캐시된 입력 토큰 비용이 중복으로 청구되지 않는다.
• 에이전트 루프에서 입력 토큰 캐싱 비용 구조에 문제가 있다는 점을 지적했다. 예를 들어 10k 토큰 시스템 프롬프트가 캐시된 상태에서 툴을 10번 호출하면, 독립적인 요청과 달리 캐시된 입력 토큰이 10k + 10k×10 = 110k 토큰으로 청구된다. 반면 OpenAI는 원격 MCP 서버를 쓸 때 올바르게 처리해준다.
• 실패 사례도 공개했는데, Opus 4.8은 카드를 잘못 덱에 돌려보내고 스스로 실수를 보고했고, gpt-5.5는 discover로 추방한 카드를 덱에 돌려보내는 걸 잊어버렸다. fable-5는 툴 사용 실수 후 조용히 턴을 재시작하려다 나중에 평가 단계에서 잡혔다.

Evidence

• 규칙 엔진 없이 LLM 자체 평가로 채점하는 방식에 회의적인 댓글이 있었다. LLM 기반 채점은 신뢰도가 낮으니 규칙 엔진으로 불법 이동 수를 세고 승/패 결과로 평가하는 방식이 더 낫다는 의견이었다.
• 실제로 xMage(오픈소스 MTG 규칙 엔진)를 사용해 LLM끼리 'Elves vs Goblin' 덱으로 대결시켜 본 개발자가 댓글을 달았다. 컨텍스트 최적화를 해도 비용이 너무 많이 들어서 deepseek 모델로만 실행할 수 있었고, LLM이 심각한 실수를 자주 한다고 경험을 공유했다.
• RTX 5090에서 mage-bench를 사용해 로컬 모델 4개로 토너먼트를 직접 돌려봤다는 사람도 있었는데, Qwen 3.6 27B가 Gemma 4를 근소하게 이겼다고 했다.
• 이 벤치마크가 실제로 MTG를 '잘 플레이하는지'가 아니라 '규칙을 따르는지'만 테스트한다는 비판도 있었다. 상대방이 없으면 진짜 게임이 아니라는 점에서 한계가 있다는 지적이었다.
• 이런 도메인 특화 obscure 벤치마크가 오히려 신뢰도가 높다는 평도 있었다. '어떤 모델도 이걸 위해 특별히 오버트레이닝되지 않았을 가능성이 높다'는 이유에서였다. RuneBench(LLM의 루네스케이프 플레이 능력 테스트)도 같은 맥락에서 언급됐다.
• gpt-5.5로 채점하면 같은 방식으로 생각하는 모델에게 편향될 수 있다는 우려도 제기됐다. 또한 채점 방식이 MTG 플레이어가 아니면 이해하기 어렵다는 지적도 있었다.

How to Apply

• 에이전트 루프에서 MCP를 사용하는 경우, 직접 툴 호출 루프를 코드로 구현하는 대신 OpenAI/Anthropic API에 원격 MCP 서버 URL을 직접 넘기면 시스템 프롬프트의 캐시된 입력 토큰이 툴 호출마다 중복 청구되는 문제를 피할 수 있다.
• 배치 API 50% 할인을 에이전트 작업에 적용하고 싶다면, 원격 MCP 서버 방식으로 전환하면 단일 API 호출로 처리되기 때문에 매 툴 호출 후 새 배치를 제출할 필요 없이 배치 API를 활용할 수 있다.
• LLM 기반 시스템에서 복잡한 규칙 준수 여부를 자동으로 검증해야 할 때, 실제 수행보다 평가에 LLM이 더 뛰어나다는 이 벤치마크의 인사이트를 활용해 'LLM이 행동을 수행하고 별도의 LLM이 검증하는' 구조를 고려해볼 수 있다.
• 비용 효율적인 모델을 선택해야 한다면 이 벤치마크 결과에서 gpt-5.4 medium($0.06/턴, 88.6점)이 가격 대비 성능이 가장 좋았다는 점을 참고하되, 작업의 복잡도에 따라 gpt-5.4-nano($0.01, 68.2점)도 충분히 고려해볼 만하다.

Terminology

관련 논문

• ALIGNBEAM: Cross-Vocabulary Logit Mixing을 통한 Inference-Time Safety Alignment 전이

  도메인 파인튜닝으로 망가진 LLM 안전성을, 재학습 없이 추론 시점에 작은 안전 모델에서 빌려와 복구하는 방법.

• iPad가 Tailscale에 연결되어 있었다: WebRTC 디버깅 이야기

  WebRTC 데이터 채널에서 iPad만 응답을 못 받는 희귀 버그를 추적한 결과, webrtc-rs의 하드코딩된 MTU 상수와 Tailscale의 IPv6 Fragment 패킷 드롭이 동시에 작용한 복합 버그였다는 2주간의 디버깅 실화.

• LLM이 고전적인 Hyperparameter 최적화 알고리즘을 이길 수 있을까?

  LLM 기반 하이퍼파라미터 최적화 에이전트와 CMA-ES, TPE 같은 고전 알고리즘을 직접 비교한 연구로, LLM 단독으로는 고전 방법을 이기지 못하지만 두 방법을 합친 하이브리드 'Centaur'가 최고 성능을 낸다는 결론이 나왔다.

• 눈이 보는 것, LLM이 놓치는 것: Human Perception을 이용한 Adversarial Text Attack

  Bold, 하이라이트, 공백 배치 같은 타이포그래피 트릭으로 GPT-4o, Llama Guard 등 10개 콘텐츠 모더레이션 시스템을 99% 이상 우회할 수 있다.

• Claude가 rsync의 버그를 증가시켰는가? 데이터 분석

  rsync 프로젝트에 Claude AI가 도입된 이후 버그가 늘었다는 소셜 미디어 주장을 실제 데이터와 통계 분석으로 검증한 글로, 결론적으로 Claude 도입 후 릴리즈가 역사적 분포에서 유독 버그가 많다는 통계적 근거는 없었다.

• 취약한 앱을 직접 만들고 LLM이 해킹할 수 있는지 $1,500 써서 실험해봤다

  Firebase 취약점을 가진 앱을 직접 제작하고 GPT-5.5, Claude, Deepseek 등 주요 LLM이 자율적으로 해킹할 수 있는지 실험한 결과, GPT-5.5가 70% 성공률로 압도적이었고 Claude는 보안 거부 정책 때문에 능력과 무관하게 낮은 점수를 기록했다.

Related Resources

• MTG Bench 원문
• RuneBench - LLM의 Runescape 플레이 능력 테스트
• Card Forge - 오픈소스 MTG 규칙 엔진
• mage-bench - xMage 기반 LLM MTG 벤치마크
• Judge Tower MTG 룰 게임