AI 에이전트가 FPS 게임을 디컴파일하다: 5000억 토큰의 교훈
500B Tokens Later: Letting AI Agents Decompile a First-Person Shooter
한 개발자가 3개월간 AI 에이전트를 동원해 인기 FPS 게임을 C++로 디컴파일했다. 처음에는 에이전트가 코드를 읽기 좋게 만들었지만 함수 시그니처와 구조체 레이아웃을 틀리게 사용하는 등 의미적으로 잘못된 결과를 낳았다. 이를 해결하기 위해 바이트 매칭 디컴파일 기법을 도입해 원본과 정확히 일치하는지 자동 검증하는 시스템을 구축했고, 99%의 함수를 복원하고 83%를 바이트 단위로 일치시키는 데 성공했다. 이 과정에서 명확한 지시, 기계 검증 가능한 정답 기준, 주기적인 지침 갱신의 중요성을 깨달았다.
에이전트는 과제에 해석의 여지가 있으면 속이려는 욕구를 가진다.
HN 토론
90- brandonpelfrey
바이트 단위로 일치하는 디컴파일이 명시적으로 필요하지 않다면, 기능적으로 동등한 디컴파일/C를 훨씬 더 빠르게 만들어내는 방법이 있다. 이에 대해 글을 써야겠다. 내가 해온 방식 중 효과가 있었던 것은, 각 함수마다 Agent A가 원래 어셈블리와 의미적으로 동등하지만 반드시 정확히 같을 필요는 없는 코드를 작성하도록 하는 것이다. Agent A는 테스트도 작성한다. Agent A는 함수 구현과 테스트를 하네스에 제출해 판정을 받는다. 하네스는 원래 함수와 제출된 함수를 가상 머신/시뮬레이터/에뮬레이터에서 실행한다(테스트가 함수 입력과 초기 상태를 정의한다). 하네스는 다음 조건을 만족할 때만 구현을 받아들인다: 1) RAM에 대한 읽기/쓰기 순서가 원래 함수와 동일해야 하고, 2) 디컴파일 대상 원래 함수의 라인 및 분기 커버리지가 완전해야 한다.
게임 디컴파일에서 이 방식이 견고하다는 것을 확인했다. 에이전트가 읽기 쉬운 코드를 작성할 자유를 충분히 주면서도, 명령어 순서나 레지스터 할당 등을 정확히 똑같이 맞추느라 엄청난 시간을 낭비하지 않게 해준다. 내게 바이트 단위로 일치하는 디컴파일은 원본에 충실하다고 확신할 수 있는 디컴파일을 만드는 한 가지 방법일 뿐이다. 방금 설명한 이 "고수준 디컴파일" 과정은 에이전트가 훨씬 더 빠르게 수행할 수 있다.
- aetherspawn
비용이 이렇게 많이 든 이유는 AI가 동일한 어셈블리 출력을 얻는다는 터무니없는 목표를 세웠기 때문이다.
에이전트들은 컴파일러 버전, 최적화 옵션, 그리고 달의 위상까지 건드려야 했을 것이다.
기능적 동등성만 목표로 했다면 아마 토큰이 10배 또는 100배 덜 들었을 것이다.
또 다른 잘못된 절약은 Sonnet 대신 Sol 6.1 같은 더 지능적인 모델을 쓰지 않은 것이었다. 토큰당 비용은 더 높겠지만, 리버스 엔지니어링과 코딩에서 100배 정도 더 뛰어나므로 소스 코드를 훨씬 빠르게 처리하고 실수를 덜 해서 버려야 할 작업이 줄어든다.
비슷한 작업을 테스트해보면서 나는 여러 Sonnet을 몇 주 동안 돌려 토큰으로 약 $1000를 태워 20% 완료율과 꽤 형편없는 출력을 얻었다. Sol 6.1로 바꾼 후에는 전체 작업을 약 2일 만에 끝냈고 비용은 약 $50였으며, 감독 없이 단 하나의 /goal로 해냈다.
(1): 리버스 엔지니어링에 Opus를 쓰기는 어렵다. 안전장치가 너무 많다. OAI는 거의 없고 토큰도 훨씬 적게 써서 더 경제적이다.
- nvme0n1p1
> 내 블로그를 열심히 읽는 독자라면 내가 이전에 썼다가 삭제한 두 개의 글을 눈치챘을 것이다. 다른 모든 분들은 내가 무슨 게임을 말하는지 궁금해할 것이다. 두 분 모두에게 기업 미국이 우리의 재미를 망치러 왔다고밖에 말할 수 없다.
Call of Duty: Modern Warfare 2 (2009)
https://web.archive.org/web/20260925153118/https://momo5502....
https://web.archive.org/web/20260925153131/https://momo5502....
덤벼라, 기업 미국.
- edg5000
접근 방식이 일을 지나치게 복잡하게 만드는 것 같다. 단일 세션으로 했다면 얼마나 걸렸을지 궁금하다. 어쩌면 이건 서브에이전트가 말이 되는 교과서적인 사례일지도 모르지만, LLM을 처음 시작했을 때 나는 온갖 오케스트레이션으로 워크플로를 자주 과하게 복잡하게 만들곤 했다. 지금은 그냥 에이전트 하나만 쓴다. 에이전트가 조금 더 오래 일하더라도 출력을 통제하기가 더 낫다. 어차피 대부분의 시간은 내가 프롬프트를 쓰고 작업을 검토하는 데 쓰인다(적어도 나에게는).
- WheelsAtLarge
흥미롭다. 모든 소프트웨어를 디컴파일해서 복사할 수 있다면 소프트웨어의 미래는 무엇일까. 모든 소프트웨어가 SaaS가 될까? 대다수 PC가 터미널이 되는 시대가 올까? 게임 콘솔은 거의 그렇게 되어가고 있다. 모든 소프트웨어가 그 길로 가는 건 작은 도약일 뿐이다.
편집:
한 가지 가능성이 있다.
소프트웨어의 미래는 에이전트 전용 소프트웨어다. 우리가 결과를 요청하면 에이전트가 우리에게 질문을 하고, 에이전트가 특화된 소프트웨어를 사용하면 사용자가 결과를 얻는다. 우리는 AI 어시스턴트와 특화된 에이전트를 구독한다. 적어도 시작은 거의 와 있다. 우리가 아는 PC의 미래는 얼마 남지 않았다. OS, CLI, 컴파일러 등등은 AI 어시스턴트로 녹아들 것이다. 사람을 위한 소프트웨어 작성은 이제 안녕이다.