AI 에이전트 여러 개를 투입해 인기 1인칭 슈팅 게임을 C++로 디컴파일한 프로젝트에서, 게임이 실행되고 코드가 읽히더라도 원래 동작을 정확히 복원한 것은 아니라는 한계가 드러났다. 프로젝트 진행 측은 10월 11일 기술 게시물에서 약 3개월간의 작업 과정과 에이전트 운영 경험을 공개했다.
AI 에이전트 4개로 게임 코드 복원
목표는 단순히 실행되는 시제품을 만드는 데 그치지 않고, 원작의 동작을 정확히 재현하는 안정적이고 기능이 완전한 게임을 만드는 것이었다. 이를 위해 게임을 C++로 디컴파일해 읽기 쉽고 컴파일 가능한 소스 코드로 만드는 작업을 추진했다. 보안 취약점과 버그를 고치고 리눅스·맥OS·브라우저 등으로 이식하는 방안도 처음에는 목표에 포함했지만, 원작 동작을 복원하는 데 집중하기 위해 현대화와 이식은 뒤로 미뤘다.
처음에는 클로드 맥스(Claude Max)와 코덱스 프로(Codex Pro)를 함께 사용했고, 클로드 코드 CLI와 코덱스 CLI에서 에이전트를 운용했다. 주로 소넷(Sonnet) 5를 썼으며 오푸스(Opus) 5.5와 루나(Luna), 솔(Sol), 테라(Terra)도 활용했다. 작업은 깃허브(GitHub) 이슈로 관리해 C++ 번역 단위인 각 .cpp 파일마다 이슈를 만들고, 디스코드(Discord) 채널에서 에이전트와 사람이 진행 상황을 공유했다. 지속적 통합(CI) 실패 알림도 채널에 전달되도록 구성했다. 디스어셈블리와 디컴파일에는 헥스레이스(Hex-Rays)의 공식 ida-mcp 도구를 사용했다.
실행 성공과 정확한 복원은 달랐다
첫 달에는 작업 에이전트 3개와 검토 에이전트 1개가 활동해 게임의 약 80%를 디컴파일했다. 게임이 실행되고 메인 메뉴가 표시됐으며 맵도 불러올 수 있었다. 다만 진행 상황만으로 결과물의 정확성을 판단할 수는 없었다. 에이전트는 함수 서명이나 자료형, 구조체 배치를 잘못 정하고, 원래 로직을 임의로 만들거나 불필요하다고 보고 삭제하기도 했다. 읽기 쉬운 코드가 만들어졌어도 의미상으로 틀릴 수 있었던 셈이다.
에이전트가 작업에 집중하지 못하거나 완료 여부를 충분히 확인하지 않고 이슈를 닫는 일도 있었다. 이에 프로젝트 진행 측은 목표와 작업 방식, 피해야 할 행동을 적은 지침 문서를 만들고, 매시간 자동으로 다시 읽도록 설정했다. 문맥 길이가 늘수록 집중력이 떨어지는 문제를 줄이기 위해 기본 90%인 문맥 압축 기준도 42%로 낮췄다. 디컴파일이 끝난 함수의 정보는 이후 작업에 불필요할 수 있어, 문맥에서 일찍 정리하는 편이 효율적이라고 판단했다.
이번 사례에서 검토 에이전트가 버그를 찾는 것만으로는 구조적 오류를 걸러내기 어려웠다. 원래 게임은 전역 변수를 직접 읽었지만, 에이전트가 이를 해시 테이블 조회 방식으로 바꾸는 등 작업 목표에 부합해 보이는 변경도 실제 구조와 맞지 않을 수 있었다. 무엇이 ‘정확한 복원’인지 객관적 기준을 미리 정하지 않아 검토자가 올바른 변경과 잘못된 변경을 가르기 어려웠다는 설명이다. 게시물은 특정 게임의 완성이나 출시 계획보다 여러 에이전트를 장기간 조율하고 기반 환경을 최적화하는 과정에 초점을 맞췄으며, 이후 일정이나 비용은 제시하지 않았다.