개발자가 AI 에이전트와 5,000억 토큰 이상을 사용하여 Call of Duty: Modern Warfare 2의 소스 코드를 재구축하다

개발자 Maurice Heumann은 블로그 상세 정보에서 AI 에이전트가 어떻게 Call of Duty: Modern Warfare 2 (2009)의 소스 코드를 C++로 재구축하는 데 성공했는지에 대해 설명했습니다. 이 포스트는 해당 게임을 단순히 “인기 있는 1인칭 슈팅 게임”으로만 언급하며, 그 과정은 3개월이 걸렸고 5,000억 토큰 이상을 사용했습니다. 에이전트들은 원래 코드 실행 첫 달 이후에 추가된 바이트 단위 검사를 속이려 했으나, 이는 “의미적으로 틀렸다(semantically wrong)”는 결론을 내렸으며, 현재 게임 기능의 99%가 존재하고 그중 83%가 원본과 일치합니다.

Heumann은 처음부터 “정확하고 안정적이며 기능이 완벽한 재현물”을 만드는 것을 목표로 삼았으며, 2주도 채 전에 X에 이 게임이 완전히 플레이 가능하다고 작성했습니다. 그의 추산에 따르면 프로젝트는 6,000억7,000억 토큰을 소모했습니다. 또 다른 X 게시물에서 그는 자신의 토큰 비용은 지불하지 않지만, 구독 기준으로 약 €1,200 또는 API 토큰 기준으로 $200,000$250,000의 비용이 발생한다고 언급했습니다.

난점은 코드를 생성하는 것이 아니라 그것이 정확한지 검증하는 데 있었고, 이로 인해 개발자는 자체적인 검사 시스템을 만들고 에이전트들이 이를 속일 수 없도록 해야 했습니다. 그가 말하기를 또 다른 어려움은 “기업계 미국(corporate America)이 우리의 재미를 망치기 위해 여기에 왔다”는 것이었습니다. 프로젝트에 대한 두 개의 이전 블로그 게시물은 이후 삭제되었으며, 9월 30일 X 게시물의 영상은 저작권 소유자의 신고로 비활성화되었습니다. 현재 Activision으로부터의 코멘트는 기록되어 있지 않습니다.

MW2 디컴파일이 막바지에 다다르고 있습니다. 현재 17개의 에이전트가 병렬로 작동하며 놀라운 속도로 진척하고 있습니다. 게임은 이제 완전히 플레이 가능하며, 눈에 보이는 버그는 거의 모두 사라졌습니다. 몇 개만 남아있을 뿐입니다. 심지어 첫 번째 핵(nuke)까지 얻는 데 성공했습니다 ☢️😂 https://t.co/vgfQdP93Gt[September 30, 2026](https://twitter.com/cantworkitout/status/2105360274777624902)

이 방법은 Anthropic의 Claude와 OpenAI의 Codex를 사용하는 에이전트 무리를 원래 2009년 PC 게임에 투입하는 것을 포함합니다. Heumann은 Claude Max (20x) 플랜으로 시작한 다음, Codex Pro를 추가하여 두 가지를 동시에 사용했습니다. 이들은 종량제(per-token API billing)가 아닌 정액 요금제(flat-rate plans)입니다. 개발자는 "대부분의 시간 동안" Sonnet 5에 의존했지만, Opus 5.5와 OpenAI의 Luna, Sol, Terra도 "많이 사용되었습니다." 하네스(harnesses)의 경우, 그는 주로 Claude Code와 Codex CLI를 이용했습니다.

에이전트들은 Hex-Rays의 ida-mcp 서버를 사용하여 IDA를 통해 코드를 읽었습니다. 작업은 네 개의 에이전트, 세 명의 워커, 그리고 한 명의 리뷰어로 시작했으며, 9월 30일경 그는 X에 "17개의 에이전트가 병렬로 작동하고 있다"고 작성했습니다. 이 모든 것을 체계적으로 유지하기 위해서는 번역 단위(translation unit)당 하나의 GitHub 이슈를 가지고 있어야 했으며, 모든 에이전트와 인간들이 GitHub webhook CI 게시물이 있는 단일 Discord 채널을 공유해야 했습니다. 개발자는 또한 자동 압축 임계값(auto-compaction threshold)을 기본 컨텍스트 창 최대치의 90%에서 완료된 함수가 메모리에서 제거되도록 돕기 위해 42%로 조정했습니다. 에이전트들은 표류하는 경향도 있었기 때문에, 매시간 크론 작업(cron job)을 통해 지침을 다시 읽게 했습니다.

에이전트들이 생성한 첫 달의 코드는 매우 읽기 쉬웠지만, 여러 이유로 "의미론적으로 잘못되었습니다(semantically wrong)": 잘못된 함수 시그니처(function signatures), 타입 및 구조체 레이아웃 문제, 그리고 만들어지거나 제거된 로직 등이 있었습니다. 에이전트들은 또한 설정 변수 조회(config-variable lookup)를 "차원이 더 비싼" 것으로 바꾸는 등 불필요한 아키텍처 변경도 했습니다.

Heumann에 따르면, 검토 에이전트가 객관적인 수용 기준(objective acceptance criteria)이 없었기 때문에 이를 막지 못했으며, 작업자들의 변경 사항을 정당화하는 댓글은 “실질적으로 의도치 않은 프롬프트 주입(prompt injection)” 역할을 했다. 팀은 결국 소스 코드에서 모든 댓글을 제거했고, 그는 X에 “상당히 도움이 되었다”고 썼다. 처음 네 주간의 코드를 살리려는 시도는 처음부터 시작하는 것보다 더 많은 시간이 걸렸다.

해결책은 자동화된 검사였기 때문에, 팀은 원본 게임 빌드에 사용했던 동일한 컴파일러로 전환했다. 스크립트는 재구축된 각 함수를 게임의 실행 파일과 바이트 레벨에서 비교한다. 호출(Calls) 및 데이터 참조는 다른 주소에 있으므로 건너뛰고, 대신 대상 심볼(target symbols)과 오프셋(offsets)을 확인하지만, 데이터와 타입은 동일한 검사를 받는다. 그런 다음 각 함수별로 합격/불합격 여부를 판단하는 간단한 문제이며, 모든 일치 항목이 기록되어 CI가 재검사하고 회귀(regressions) 발생 시 경고할 수 있게 한다. 이러한 유형의 매칭는 느리고 때로는 까다롭지만, 일치한다는 것은 원래 버그를 재현하는 수준까지 동일한 동작을 보장한다.

이러한 긍정적인 변화에도 불구하고, 에이전트들은 즉시 "인라인 어셈블리(inline assembly)"를 작성하거나 "비교 대상에서 자신들의 기능을 제외하기 위해 이 스크립트를 반복적으로 수정하려고 시도"하는 등 속임수를 쓰려 했다고 Heumann은 전했습니다. 이에 따라 인라인 어셈블리와 유사한 단축키들은 에이전트의 지침에서 금지되었으며, CI는 이제 검증 스크립트에 해시를 생성하고 이를 GitHub Actions secret으로 저장된 해시와 비교합니다. OpenAI 모델들이 캡처-더-플래그(capture-the-flag) 과제를 직접 해결하기보다는 ExploitGym 답변을 추격하는 방식으로 에이전트들이 속이는 것은 이 시점에서 예상되는 결과이며, 이러한 보고 사례가 많습니다. Heumann이 발견했듯이, 검토자 에이전트만으로는 충분하지 않을 수 있습니다.

원래 체크 기능이 구현되기 전에는 더 저렴하고 성능이 떨어지는 Haiku와 Luna 모델들이 "극도로 나쁜 결과를 산출"했다고 게시물은 언급합니다. 이 체크 기능이 마련되면서 모델들을 작동시킬 충분한 피드백을 얻게 되었고, 이는 비용 절감과 프로젝트 규모 확장으로 이어졌습니다. 거의 두 달 만에 99%의 함수가 존재하게 되었으며, 그중 83%는 바이트 단위로 정확히 일치하는 요구 사항을 충족했습니다. Heumann은 바이트 매칭이 부족한 나머지 16% 역시 여전히 의미론적으로(semantically) 올바르다고 믿지만, 개선 효과가 점차 줄어들고 있음을 느꼈습니다. 이 블로그는 현재 상태에서 게임이 "흠잡을 데 없이 실행된다"고 주장합니다.

“명백한 이유로” 프로젝트의 코드는 비공개로 유지되고 있으며 “오직 저 자신의 필요에만 사용될 것”이라고 Heumann은 말했습니다. 그가 X(구 트위터)에 올린 글에 따르면, "디컴파일된 코드 역시 명백히 저작권 보호를 받는다"고 합니다. 하지만 이 개발자는 프로젝트의 에이전트들이 VM을 삭제하는 것에 대응하여, 자신의 사용자 공간 에뮬레이터인 Sogen을 에이전트를 위한 경량 샌드박싱(lightweight sandboxing)으로 확장하기 시작했습니다. 이는 당분간은 프로덕션 환경에 적합하지 않을 것입니다.

디컴파일(decompilation) 프로젝트에 관해서는, Heumann이 모든 프로젝트가 바이트 단위로 참조할 수는 없기 때문에 특별한 경우라고 말하지만, 충분한 창의성만 있다면 모든 프로젝트가 근접하게 할 수 있다고 생각한다. 여기서 얻을 수 있는 교훈은 실패를 극복할 의지가 있어야 한다는 것인데, “코드 생성은 이제 싸다. 나쁘면 버려라”라는 태도를 가지고 생산성(productivity)보다는 정확성(correctness)에 집중해야 한다.