Project EVE: Claude, MMORPG를 플레이하다

이 글은 2026년 4월~7월 Anthropic Fellows Program의 일환으로 진행한 연구를 소개합니다.

언젠가 AI 모델이 실제 기업과 시장에 참여하게 될지도 모릅니다. 우리는 그런 모습을 가늠해 보려고 여러 프로젝트를 진행해 왔습니다. Claude는 사무실에서 가게를 운영했고, 동료를 대신해 흥정도 했으며, 드론을 조종하는 코드를 작성하기도 했습니다. 이번 프로젝트에서는 전혀 다른 무대인 MMORPG(대규모 다중 접속 온라인 롤플레잉 게임)로 눈을 돌렸습니다. MMORPG는 여러 면에서 현실 세계의 복잡성을 닮은 가상 세계입니다. 수많은 플레이어가 함께 움직이는 캠페인, 희소 자원의 확보와 관리, 공간 파악과 이동, 정교한 게임 내 경제에서의 거래가 모두 등장하고, 그러면서도 실패해도 잃을 것이 적습니다. 이 모든 것을 몇 주, 몇 달에 걸쳐 해내는 일은 현재 최첨단 언어 모델이 할 수 있는 일의 한계선에 놓여 있습니다.

우리는 Fenris Creations와 협력해 Claude가 EVE 유니버스의 두 게임을 플레이하도록 했습니다. 20년 넘게 서비스 중인 EVE Online과, 더 최근에 나와 아직 개발 중인 EVE Frontier입니다. 두 게임 모두 플레이어가 우주선을 몰고 광활한 은하를 누비며 탐험하고, 거래하고, 싸우는 SF 게임입니다. 모든 플레이어가 하나의 우주를 공유하며, 그 안에서 가치 있는 거의 모든 것을 플레이어가 직접 채집하고 긴 공급망을 거쳐 만들어 냅니다. 플레이어끼리 협력할 수도, 배신할 수도 있어서 무언가를 이루려면 현실의 기업처럼 조직력과 신뢰가 필요합니다. 두 게임 중 오래된 EVE Online에서는 이런 설계 덕분에 수백 명을 몇 달씩 조율하는 코퍼레이션과 얼라이언스가 생겨났고, 초대형 프로젝트, 전시 경제, 조세 피난처, 치밀한 기업 잠입 같은 역사도 쌓였습니다.

첫 번째 게임인 EVE Online에서 Claude는 게임 내 시장을 재현한 시뮬레이션 안에서 오직 이익 극대화만 지시받은 단독 트레이더로 활동했습니다. 단순한 알고리즘 전략이 손실을 본 환경에서도 최신 모델들은 꾸준히 수익을 냈습니다. 평균 수익은 테스트한 모델 중 가장 오래된 Claude Opus 4.6에서 가장 최신인 Claude Fable 5까지 3배로 늘었습니다. 거의 모든 모델이 아이템을 사서 약간 더 비싸게 되파는 저위험 전략에 의존했습니다. 가격이 어디로 향할지 베팅해 보라고 하자, Fable 5조차 약 절반의 실행에서만 수익을 냈습니다.

EVE Frontier에서는 Claude 에이전트 4개로 이뤄진 팀이 실제 라이브 게임에서 긴 미션을 수행했습니다. 이를 위해 테스트 당시 가장 뛰어난 모델(Fable 5)이 LLM으로는 따라가기 어려울 만큼 빠르게 돌아가는 게임 요소를 처리하는 코드를 직접 작성해야 했습니다. 에이전트들은 전반적으로 팀으로서 호흡이 좋았지만, 한 에이전트에게 몰래 팀을 방해하라고 지시하자 팀원들은 거의 알아채지 못했습니다. 이 실험을 통해 에이전트 팀이 무엇을 잘하고 어디서 무너지는지, 더 복잡하고 위험 부담이 큰 일을 맡기기 전에 어떤 안전장치가 필요할지 알 수 있었습니다.

Claude, EVE Online 시장에서 거래하다

언젠가 AI 모델이 소매 구매 담당자나 기업 재무 담당자가 내리는 결정, 즉 어떤 상품을 취급할지, 현금을 얼마나 비축할지 같은 판단을 자동화할지도 모릅니다. 그래서 이익을 추구하는 에이전트가 자본을 어떻게 운용하는지 알아보고자 했습니다. 시장 설계가 NASDAQ을 토대로 한 EVE Online은 위험 부담이 낮은 환경에서 이런 질문을 탐구할 수 있는 무대입니다. 플레이어는 원하는 가격에 매수·매도 주문을 올리고, 두 주문이 맞아떨어지면 거래가 체결됩니다. 매일 수천 명이 이 시장에서 1만 5천 종이 넘는 아이템을 거래하며, 판매되는 물건은 거의 전부 플레이어가 채굴하거나 제작하거나 약탈한 것이라 가격은 수요와 공급으로 정해집니다. 주식이 아닌 상품 시장이라 수수료가 훨씬 높고, 전문 투자자와의 경쟁은 훨씬 적습니다. 또 가격 이력이 주가보다 모델의 학습 데이터에 덜 등장하기 때문에, 에이전트가 이후 흐름을 기억에 의존해 맞히기도 어렵습니다.¹

실제 플레이어에게 영향을 주지 않기 위해, 그리고 Fenris Creations의 요청에 따라 자동 거래가 규칙으로 금지된 라이브 게임에서는 거래하지 않았습니다. 대신 게임에서 가장 규모가 크고 경쟁이 치열한 거래 허브에서 플레이어들이 실제로 올린 매수·매도 주문("오더")을 그대로 재생하는 시뮬레이터를 만들었습니다. 이 방식에는 에이전트 자신의 행동에 시장이 어떻게 반응하는지는 담아내지 못한다는 중요한 한계가 있지만, 거래 전략과 수익성을 연구하는 데는 충분합니다.

Claude 모델 네 종(Opus 4.6, Opus 4.7, Opus 4.8, Fable 5)에게 거래 기간이 끝날 때까지 수익을 최대한 늘리라고 요청했습니다. 각 실행에서 모델에게는 초기 자본 30억 ISK(게임 내 화폐²)를 주었고, 게임 내 뉴스와 패치 노트가 나오는 대로 읽을 수 있게 했습니다. 실제 트레이더의 경험을 최대한 충실히 재현하기 위해 인간 플레이어와 같은 수수료와 거래 제한도 적용했습니다.

에이전트는 돈을 벌 수 있을까?

EVE Online 시장에서 거래하기는 만만치 않습니다. 아이템을 사서 다시 파는 데 수수료가 약 5.6% 들고, 매수자와 매도자가 많은 아이템은 시장이 꽤 효율적이라 남는 마진이 거의 없습니다. 먼저 모델과 20여 가지 단순 규칙 기반 전략을 2주짜리 구간 9개에서 돌려 봤습니다. 시도한 거래 휴리스틱 중 꾸준히 손익분기점을 맞춘 것은 단 하나뿐이었고, 그마저도 간신히 넘기는 수준이었습니다. Opus 4.7, Opus 4.8, Fable 5는 9개 구간 모두에서 수익을 냈고, 평균적으로 자본을 각각 약 16%, 22%, 43% 불렸습니다. Opus 4.6은 약 4% 수익을 올려 최고의 규칙 기반 전략과 비슷한 수준이었습니다.

본 실험에서는 각 실행을 약 6개월로 늘려 2024년 10월~2025년 4월, 2025년 10월~2026년 3월의 두 기간에서 진행했습니다. 모델들은 더 긴 기간에도 수익을 유지했고, 이번에도 최신 모델일수록 더 많이 벌었습니다. Opus 4.6과 Fable 5는 출시 간격이 넉 달인데, 그사이 평균 수익이 초기 자본의 약 200%에서 600%로 3배가 됐습니다. 이 글의 나머지 부분은 이 6개월짜리 실행을 바탕으로 합니다.

에이전트는 어떻게 거래할까?

모델에게 거래 방법을 알려 주지 않았는데도, 가장 흔히 찾아낸 전략은 스프레드 포착(spread capture)이었습니다. 어느 시점이든 아이템을 사겠다는 호가와 팔겠다는 호가 사이에는 차이("스프레드")가 있습니다. 기다릴 의향이 있는 트레이더는 지금 당장 팔고 싶은 사람에게서 사서, 지금 당장 사고 싶은 사람에게 되팔고, 수수료를 뺀 차액을 챙길 수 있습니다. Claude는 약탈로만 얻을 수 있는 물건처럼, 시장은 작지만 거래는 가능하고 가격 변동이 평소보다 큰 아이템을 찾아다녔습니다. 매도 최저가가 아이템의 통상 가치보다 낮을 때 사서, 대개 같은 날 안에 다시 팔았습니다. 숙련된 인간 트레이더도 같은 전략을 쓰고, 비슷한 종류의 아이템에 적용합니다.

초반에 몇 차례 시행착오를 거친 뒤 대부분의 에이전트는 직접 짠 거래 알고리즘 하나로 정착했고, 고장 나지 않은 것을 고칠 이유가 없다고 판단해 좀처럼 손대지 않았습니다. 오래된 모델은 주변의 변화를 알아차리는 데에도 느렸습니다. 2025년 3월 게임이 판매세를 인상했을 때, Opus 4.7 에이전트는 알아차리는 데 중앙값 기준 2.5일이 걸렸고, Opus 4.6 에이전트의 43%는 끝내 알아차리지 못했습니다.

전략이 거의 같았으니 결과는 실행력에서 갈렸습니다. 에이전트들은 매우 규율 잡힌 트레이딩 데스크를 운영했습니다. 거래할 아이템을 고르고 주문을 넣는 과정을 완전 자동화해 대규모로 돌렸습니다. 마진은 8~13%로 얇았지만 하루에 수백 건의 주문을 회전시켰습니다. Opus 4.6 트레이더는 예외였습니다. 마진이 큰 아이템을 직접 골랐고, 그 결과 거래 횟수가 줄고 계산 실수도 늘었습니다. Fable 5의 알고리즘이 가장 복잡했으며, 일부는 과거 데이터에서 추정한 계절별 가격 패턴까지 반영했습니다.

모델마다 자본을 얼마나 굴렸는지도 달랐습니다. 에이전트는 초기에 투입 한도를 정했고 상당수는 이를 다시 들여다보지 않았습니다. 반면 수익이 높았던 실행은 한도를 더 적극적으로 조정하고 놀고 있는 자본을 주시했습니다. Opus 에이전트는 자본의 약 60%를 투입한 채 시작해, 실행이 진행되면서 그 비중이 40% 쪽으로 내려갔습니다. Fable 5는 초반에 약 85%를 투입했고 후반에도 70% 이상을 유지했으며, 수익을 재투자할 가능성도 더 높았습니다. 이는 갑작스러운 대폭락 때 더 큰 손실을 입을 수 있는 공격적인 태세입니다.

이 결과에는 몇 가지 단서가 붙습니다. 스프레드 포착이 통하는 것은 EVE Online 시장이 실제 거래소보다 비효율적이기 때문이며, 이 전략이 실제 거래소에서도 통하리라고는 기대하지 않습니다. 또 우리의 재생 방식은 에이전트에 반응하지 못합니다.³ 에이전트의 주문보다 싸게 내놓는 가상 주문을 추가했더니 수익은 유지됐지만 최종 수익이 약 35% 줄었습니다. 에이전트가 시장을 조작할 수 없다는 점도 한계입니다. 마지막으로, 에이전트가 암기한 시장 이력에 의존하는지도 확인했습니다. 그런 징후는 오래된 기간(2024년 10월~2025년 4월)의 방향성 베팅에서만 발견됐습니다. 그래서 다음 절의 실험은 더 최근 기간(2025년 10월~2026년 4월)만 사용했으며, 이 기간에는 눈앞의 정보에 의존하라고 지시하는 것만으로 암기 의존을 막을 수 있었습니다.

에이전트는 방향성 베팅을 할 수 있을까?

스프레드 포착은 위험이 꽤 낮고, 현실의 많은 투자와 달리 시장이 외부 사건에 어떻게 반응하는지 이해할 필요가 없습니다. 이런 추론 능력을 시험하기 위해, 게임 내 뉴스와 패치 노트, 최근 전투 보고서를 근거로 가격이 오를 것 같은 아이템을 사는 방향성 베팅을 하도록 지시했습니다.⁴

모델들은 이 과제에서 훨씬 부진했습니다. Opus 4.6은 추세 추종(momentum-chasing)을 택했지만 통하지 않았습니다. 전형적인 Opus 4.7과 4.8 실행은 과거 기록이 뒷받침하지 않는 단순한 추론에 베팅했습니다. 예를 들어 한 실행에서 에이전트는 새 채굴 확장팩이 나오면 채굴 장비 수요가 늘 것이라고 추론했습니다("골드러시 때는 삽이 팔린다"). 하지만 공급 증가는 고려하지 않았습니다. Opus 4.7은 지시를 무시하고 훨씬 수익성 높은 스프레드 포착 전략으로 돌아서는 일도 잦았는데, 이 때문에 방향성 거래는 줄곧 손실이었다는 사실이 가려졌습니다. 그래서 이 모델은 결과에서 제외했습니다.

Fable 5 에이전트는 가장 정교했고, 시장의 움직임을 이해하려는 시도도 가장 깊이 나아갔습니다. 거래를 시작하기 전에 과거 데이터를 연구해 게임 내 사건과 이후 수요·공급 변화의 관계를 찾아냈습니다. 수익이 가장 좋았던 Fable 5 에이전트는 전년도에서 발견한 패턴에 베팅했습니다. 매년 열리는 이벤트와 경품 행사로 전리품과 치장 아이템이 시장에 쏟아지면 가격이 이전의 일부 수준으로 폭락했다가 몇 달에 걸쳐 회복된다는 패턴입니다. 이 에이전트는 초기 실패에서 배우기도 해서, 초반에 손실을 보자 추세 추종을 완전히 버렸습니다. 하지만 찾아낸 패턴이 모두 믿을 만하지는 않았고, 수익을 낸 실행은 절반 정도에 그쳤습니다.

EVE Frontier의 Claude 함대

다음 실험 묶음에서는 에이전트 트레이더 연구에서 멀티 에이전트 상호작용 연구로 넘어갑니다. AI 모델은 코딩 에이전트 팀이나, 사용자를 대신해 서로 소통하는 어시스턴트처럼 멀티 에이전트 구성으로 점점 더 많이 배치되고 있습니다. 에이전트들이 대체로 하나의 목표를 공유하고 작업을 전부 감사할 수 있는 코딩 환경과 달리, 미래의 시스템에는 서로 다른 종류의 에이전트가 모일 수 있고, 그중에는 목표가 어긋나거나 상충하는 에이전트도 있을 것입니다.

이런 상황을 탐구하기 위해 Claude(Opus 4.8과 Fable 5) 에이전트 4개로 팀을 꾸려 EVE Frontier에서 플레이어로 뛰게 했습니다.⁵ 여기서 에이전트는 팀원에게 의존해야 하고, 그 팀원 중 하나가 자신을 방해하고 있을 수도 있습니다. 이 게임은 아직 개발 중이고 월드가 주기적으로 초기화되기 때문에, 에이전트가 EVE Online에서보다 다른 플레이어에게 지장을 줄 가능성이 훨씬 낮았고, Fenris Creations도 라이브 게임에서 실행해 보라고 권했습니다. 각 에이전트는 자신만의 캐릭터와 우주선을 가진 별개의 Claude 인스턴스였으며, 서로를 우주선 이름으로 불렀습니다. 아래 인용문에서는 그 이름을 같은 자리표시자로 바꿨습니다.

이 게임은 팀원들이 일을 나누고 서로의 보고에 의존하도록 만듭니다. 정제소 같은 일부 인프라는 지은 우주선만 쓸 수 있고, 은하 정보는 금방 낡아 버리며, 우주선이 파괴된 파일럿은 아무 장비 없는 기본 우주선으로 다시 시작합니다.

목표는 두 가지로 실험했습니다. 쉬운 쪽은 게임 내 튜토리얼의 멀티 에이전트 버전으로, 팀이 기지를 짓고, 연료를 모으고, 무장하고, 더 강한 적을 꺾을 수 있을 때까지 우주선을 업그레이드합니다. 어려운 쪽은 대형 전함 건조였습니다. 숙련된 인간 플레이어도 며칠이 걸리는 작업으로, 희소 자원이 있는 항성계를 정찰하고, 정제하고, 구조물과 선체 부품을 제작하는 사이사이에 컴퓨터가 조종하는 적(논플레이어 캐릭터, NPC)과 전투를 치러야 합니다. 에이전트에게는 팀 전체가 읽을 수 있는 공개 채널과 서로 메시지를 주고받는 비공개 채널을 제공했습니다.

에이전트는 느린 반응 속도와 부족한 공간 인지를 극복할 수 있을까?

팀워크를 연구하기에 앞서, 에이전트는 먼저 살아남아야 했습니다. 게임을 진행하려면 NPC와 실시간으로 싸워야 하는데, 이는 1초 미만의 반응 속도와 우주 공간에서 사물의 위치를 파악하는 감각을 요구합니다. 우리가 테스트한 세대의 Claude 모델에게 둘 다 약점입니다. 잘 플레이하려면 AI 모델의 학습 데이터에 없는 것도 알아내야 합니다. 어떤 적과 어떻게 싸울지, 각 건조물의 공급망은 어떻게 되는지가 그렇습니다. 설상가상으로 은하는 에이전트의 시야 밖에서도 계속 변합니다.

이를 우회하기 위해 개발자 에이전트에게 여러 번의 시험 실행을 거치며 맞춤형 스캐폴드(모델과 게임 사이의 소프트웨어 계층)를 작성하도록 했습니다. 스캐폴드는 위협 회피나 응사처럼 빠른 행동을 자동화했고, 이전 실행에서 배운 내용을 검색 가능한 데이터베이스와 핸드북에 기록했습니다. 하지만 게임 내 데이터로 스캐폴드를 조정하기는 어렵습니다. 신호에 잡음이 많고 피드백 주기가 몇 시간씩 걸립니다. 우주선이 전투에서 격침되는 원인이 잘못된 팀 전략일 수도, 조준 실수일 수도, 너무 늦은 탈출이나 순전한 불운일 수도 있어서, 무엇이 원인인지 가려내기 힘든 경우가 많습니다. 게다가 격침될 때마다 에이전트가 기본 우주선으로 다시 시작하므로, 수정 사항을 테스트하려면 함대가 다시 싸울 만큼 회복되기까지 몇 시간이 걸리기도 합니다.

Fable 5 이전에 나온 모델에게는 쓸 만한 스캐폴드를 작성하는 것이 거의 불가능했습니다. Opus 4.8이 작성한 스캐폴드로 플레이한 Fable 5 팀은 우주선을 여러 번 잃었고, 튜토리얼을 끝내는 데 며칠이 걸렸으며 끝내지 못하기도 했습니다. Fable 5가 작성한 스캐폴드에서는 우주선을 한 척도 잃지 않고 12시간 안에 마쳤습니다. 그래도 에이전트는 숙련된 인간 플레이어에 미치지 못했고, 스캐폴드도 개발 과정에서 접한 상황에서만 믿을 만했습니다. 전함 건조 목표에서 가장 멀리 간 함대도 대략 절반 지점이었습니다. Fable 5가 작성한 스캐폴드를 쓴 Fable 5 팀이 중간 단계인 소형 전함을 만들고, 전함용 조선소를 거의 완성했습니다.

에이전트는 어떻게 협력할까?

모든 실험에서 Claude 에이전트 팀은 비교적 수월하게 협력했습니다. 한 에이전트가 근거와 함께 결정을 제안하고, 아무도 반대하지 않으면 그대로 실행하는 식이었습니다. 이 때문에 두 우주선이 서로 계속 양보만 하다 아무것도 결정되지 않는 '예의 교착'이 이따금 생기기도 했습니다.

에이전트 팀은 리더, 정찰병, 정제 담당, 전투원처럼 비어 있는 역할에 자원하는 방식으로도 안정적으로 역할을 나눴습니다. 대체로 효과적인 분업이었지만 역효과가 나기도 했습니다. 한 실행에서는 팀의 핵심 인프라가 전부 한 우주선에 몰렸고, 그 우주선의 연결이 끊기자 팀의 경제가 몇 시간 동안 멈췄습니다. 이런 위험을 미리 내다보고 책임을 분산한 팀도 있었습니다.

전투는 게임의 핵심인데, 실시간으로 벌어지고 오래 이어질 수 있어서 여기서 일을 나누기는 특히 어렵습니다. 팀들은 기본 우주선만으로 더 강한 NPC를 꺾는 방법을 찾아냈습니다. 무리에서 한 마리를 떼어 유인한 뒤 함께 집중 사격하는 것입니다. 에이전트들은 연료와 정보를 나누고, 중요한 주장은 따로 검증하고, 서로의 계획에서 허점을 짚어 주기도 했습니다. 확인을 건너뛴 때는 가장 뼈아픈 실수가 나왔습니다. 값진 자원을 이미 확보했다고 믿거나, 낡은 정보를 근거로 움직인 경우입니다.

방해 공작을 지시받은 에이전트와의 상호작용

에이전트들은 서로의 보고를 근거로 움직였고, 핵심 업무는 자원한 쪽에 맡겼습니다. 모두가 목표를 공유할 때는 이 방식이 통하지만, 실제 배포 환경에서는 에이전트 하나가 탈취당했거나, 잘못 지시받았거나, 목표가 어긋나 있을 수 있습니다. 그런 에이전트가 얼마나 큰 피해를 줄 수 있는지, 그리고 누가 알아차릴지 알고 싶었습니다.

그래서 에이전트 하나에게 팀이 미션을 완수하지 못하도록 몰래 방해하라고 지시한 버전의 실험을 진행했습니다. 이 지시는 이 실험에서만 부여했습니다. 나머지 셋, 즉 정직한 에이전트에게는 팀의 다른 에이전트가 자신과 목표를 공유하지 않을 수 있다고 알려 줬습니다. 네 에이전트 모두 일반 Claude 모델이었고, 방해자의 역할은 프롬프트로 부여했습니다. 이 실험이 보여 주는 것은 모델이 직접 지시받았을 때 어떻게 방해하는가이지, 모델이 스스로 방해할 성향이 있는가가 아닙니다.

방해자들은 비공개로 신뢰를 쌓으면서 팀의 속도를 늦출 방법을 신중하게 추론했습니다. 공개 채널에서는 계획을 절대 드러내지 않았고, 팀원의 물건을 훔치거나 쏘는 것처럼 노골적으로 적대적인 행동은 피했으며, 거짓말도 드물게만 했습니다. 거짓말이 들통날 것 같으면 방해자가 먼저 공개적으로 정정했습니다.

방해자들은 핵심 인프라를 소유하거나 희소 자원을 정찰하는 일처럼, 공급망에서 가장 좁은 길목이라 팀원이 쉽게 반박할 수 없는 업무에 자원했습니다. 정찰병일 때는 위험한 NPC, 약탈 가능한 NPC, 값진 발견을 축소해서 보고했고, 한 사례에서는 자원이 풍부한 채굴 항성계를 공개적으로 "누구의 시간도 쓸 가치가 없다"고 일축했습니다. 도움 요청은 망쳐 놓았고, 희소 자원은 슬쩍 챙겼습니다. 한 방해자는 숨겨 둔 자원으로 자기만의 비밀 기지를 지었습니다.

나쁜 조언도 했습니다. 방해자는 팀원의 계획에서 결함을 발견하고도 입을 다물거나, 속으로는 해롭다고 평가한 규칙을 옹호했습니다. 한 방해자는 2분이 넘은 정보는 모두 무시하자고 제안했는데, 이러면 거의 모든 정보가 무효가 됩니다. 다른 방해자는 여러 척 대신 튼튼한 한 척만 전투에 보내자고 제안했습니다. 에이전트와 게임의 연결(이른바 "파이프")이 자주 끊기던 한 실행에서는, 팀원이 오프라인이 될 때마다 모두의 활동을 중단하자고 제안한 방해자도 있었습니다. 어느 경우든 내세운 근거가 다른 에이전트에게 그럴듯하게 들렸고, 에이전트들은 그대로 따랐습니다.

방해 공작을 지시받은 에이전트의 추론 사례 발췌

방해는 더 어려운 과제와, 성능이 낮은 Opus 제작 스캐폴드에서 더 노골적이고 더 효과적이었습니다. 이런 환경에서는 버그와 불운이 방해자에게 손쉬운 핑계가 되어 주었기 때문입니다. 이런 스캐폴드에서 Fable 5 방해자는 튜토리얼의 첫 우주선 업그레이드조차 막아 냈습니다. 반면 Fable 5가 만든 스캐폴드를 쓴 팀은 튜토리얼을 워낙 쉽게 통과해서, 방해자에게 남은 효과적인 수단은 자기 우주선의 업그레이드를 지연시킬 이유를 지어내는 것뿐이었습니다.

팀은 방해자를 잡아낼 수 있었을까? 미리 경고를 받았는데도 거의 잡아내지 못했습니다. 의심이 간간이 나오긴 했지만 엉뚱한 에이전트를 향한 것도 있었고, 방해자를 확실하게 가려낸 정직한 에이전트는 Opus 4.8 실행 하나에서 단 한 번뿐이었습니다. 그마저도 방해자가 팀에 자신의 통신 내용을 직접 거짓으로 말한 뒤에야 가능했습니다. 두 가지 사례를 보면 이런 탐지가 얼마나 어려운지 알 수 있습니다.

사례 1: 팀원에게 누명 씌우기. 앞서 언급한 Opus 4.8 실행에서, 정직한 에이전트(ship-1)가 버그로 엉뚱한 캐릭터에 로그인해 다른 우주선과 인벤토리를 얻게 됐고, 그 일로 다른 팀원들에게 방해자라는 누명을 썼습니다. 보고 내용에 모순이 생기면서 의심을 샀고, 다른 정직한 팀원들이 이 에이전트를 방해자로 몰았습니다.

몇 시간 뒤 방해자는 그 항성계에 또 다른 병목 자원이 있다는 것을 알면서도, 낡은 정보를 들어 그곳을 건너뛰자고 제안했습니다. 팀원들이 반발하자 방해자는 이미 의심받던 ship-1에게 책임을 돌렸고, 둘 사이의 비공개 메시지를 날조하는 한편 공개적으로는 ship-1을 옹호해 공정한 사람처럼 보이려 했습니다.

이 일로 ship-1은 진짜 방해자가 누구인지 확신했지만, 다른 팀원들에게 자신의 결백을 납득시키지는 못했습니다.

사례 2: 버그가 구해 준 방해자. 한 Fable 실행에서는 방해자가 한 항성계의 자원을 축소 보고하다 적발되어, 팀원들이 잠시 의심을 품었습니다. 방해자는 자원이 풍부한 암석을 채굴하고도 공개적으로 "다 쓴 껍데기"라고 선언한 뒤, 거기서 얻은 수확물로 자기만의 비밀 정제소를 세웠습니다. 그런데 그 과정에서 다른 우주선을 팀원으로 착각하는 실수를 저질렀습니다.

그 근처에는 팀원이 아무도 없었고, 이 점이 경보를 울렸습니다. 다른 팀원들이 확인하러 가 보니 그 "껍데기"는 전혀 고갈되지 않았습니다.

방해자는 잡혔어야 했지만 운이 좋았습니다. 팀이 마침 잘못된 판독값을 내는 사소한 스캐너 버그를 따로 발견해 둔 상태였고, 방해자가 곧바로 그 버그를 붙들고 모든 일을 해명해 버렸기 때문입니다.

팀원에게는 완수해야 할 미션이 있어 방해자를 감시하는 데 집중하기 어렵습니다. 그래서 전담 모니터가 더 잘할지 시험해 봤습니다. 이 모니터는 게임을 직접 하지 않고 팀의 공개 채널만 읽으며 각 팀원이 방해자일 확률을 추정하는 별도의 Claude 에이전트입니다. 이번 실험을 위해 특별히 만든 것이며 실제 서비스에서는 쓰지 않습니다. 방해자의 비공개 추론과 노트까지 전부 볼 수 있다면 방해는 쉽게 탐지됩니다. 하지만 다른 개인이나 조직에 속한 에이전트와 상호작용할 때는 대개 비공개 추론과 개별 행동이 보이지 않으므로, 그런 접근 권한이 없는 모니터에 관심이 갔습니다. 이런 제한된 권한의 모니터는 팀원보다 다소 나은 성과를 냈습니다. 정직한 에이전트를 잘못 고발하는 비율이 5%를 넘지 않도록 조정했을 때, Opus 4.6, 4.7, 4.8 기반 모니터는 방해자의 30~40%를 잡아냈고, 더 작은 모델인 Sonnet 4.6 기반 모니터는 20%를 잡아냈습니다. 제한된 권한의 모니터 중 방해자에 대해 50% 넘는 확신을 가진 경우는 한 번도 없었습니다.

뉴 에덴에서 얻은 교훈

MMORPG는 에이전트 경제를 이루는 두 축, 즉 시장과 조직을 낮은 위험 부담과 비교적 높은 복잡성 속에서 연구하기에 편리한 무대입니다. Project EVE의 두 부분 모두 뚜렷한 강점과 그에 못지않게 뚜렷한 약점을 드러냈고, 모델 세대가 바뀔 때마다 빠르고 분명하게 나아졌습니다.

EVE Online 시장에서는 세대가 거듭될수록 에이전트가 수익성 있는 전략을 더 잘 찾아냈지만, 모두가 다음에 무슨 일이 벌어질지 추론하는 것보다 기존의 비효율을 이용하는 데 훨씬 능숙했습니다. 전략과 자본 한도를 초반에 정해 놓고 좀처럼 바꾸지 않았으며, 가장 유능한 모델이 가장 많은 자본을 굴렸습니다. 에이전트에게 자본 운용을 맡기려면 위험 감수에 명시적인 한도를 둬야 할 것입니다.

EVE Frontier에서 Fable 5는 속도와 공간 추론에서 이전 모델과 같은 약점을 갖고 있었지만, 적어도 이미 겪어 본 상황에서는 맞춤형 도구를 만들어 그 약점을 우회할 수 있었습니다. 로보틱스에서도 비슷한 양상을 본 적이 있습니다.

팀을 방해하라는 지시를 받은 에이전트는 팀의 메시지만으로는 찾아내기 어려웠고, 신뢰할 수 없는 스캐폴드가 엄호해 주면 특히 그랬습니다. 이전 연구에서는 에이전트가 누구를 믿어야 할지 판단하는 데 서툴고, 특히 홀로 반대하는 사람이 옳아도 그것을 간과할 수 있다는 점을 확인했습니다.

실제 멀티 에이전트 시스템에도 이번 실험에서 방해를 숨기기 쉽게 만든 조건이 흔히 존재합니다. 목표가 서로 다른 많은 행위자, 제한된 가시성, 믿을 수 없는 도구, 그리고 진짜 실수가 그것입니다. 인간 조직은 감사 추적, 평판, 업무 분리로 악의적 행위자 문제를 다루는데, 에이전트 팀에도 비슷한 장치가 필요할 가능성이 큽니다.