5,000억 토큰을 쓰고 나서: AI 에이전트에게 1인칭 슈팅 게임 디컴파일 맡기기

바이트 단위 일치가 꼭 필요하지 않다면, 기능적으로 동등한 C 코드를 훨씬 빠르게 얻는 방법이 있음. 내가 쓰는 방식은 에이전트 A에게 함수마다 원본 어셈블리와 의미가 같은 코드와 테스트를 작성하게 하고, 검증 하네스에 제출하도록 하는 것임.
하네스는 테스트가 지정한 입력과 초기 상태로 원본 함수와 제출된 함수를 가상 머신·시뮬레이터·에뮬레이터에서 실행함. RAM 읽기·쓰기 순서가 동일하고 원본 함수의 모든 줄과 분기를 테스트해야만 구현을 승인함.
게임 디컴파일에 꽤 견고하게 작동하면서도, 명령어 순서나 레지스터 할당까지 맞추느라 시간을 낭비하지 않고 읽기 쉬운 코드를 작성할 자유를 줌. 원본에 충실한지 확인하는 방법이 바이트 일치만 있는 것은 아니며, 이런 고수준 디컴파일은 에이전트가 훨씬 빠르게 수행할 수 있음.

RAM 읽기·쓰기 순서만으로 의미적 동등성을 판정할 수는 없음. 순서가 같아도 FPU·부동소수점 스택이나 레지스터만 사용하는 명령어의 의미가 틀릴 수 있고, 반대로 같은 계산을 해도 변수가 다른 스택 슬롯에 배치되면 접근 순서가 달라질 수 있음.
함수 퍼징은 단순 바이트 비교보다 느리며, 빠른 피드백이 있어야 에이전트도 빠르게 반복 작업을 할 수 있음. 나도 레지스터 선택이나 스택 슬롯 변경을 무시하면서 의미적 동등성을 증명하는 도구를 만들었지만, 하네스로 쓰기에는 너무 느려서 남은 함수 일부를 검증하는 데만 사용함.
실제로 바이트 일치 구현은 그렇게 복잡하지 않았음. 대부분의 함수는 작아서 한 번에 해결했고, 복잡한 함수도 에이전트가 레지스터 선택이나 제어 흐름에 따른 기본 블록 순서를 조절하는 요령을 찾아 기록함. 프로젝트가 진행될수록 정확히 맞추기가 쉬워짐.

이 방식의 기능적 동등성은 테스트의 완전성에 의존하지만, 컴파일 결과가 바이트 단위로 같다면 그렇지 않음. 예를 들어 모든 오버플로 동작을 잡아내지는 못할 수 있음. 원문은 모든 버그의 재현도 중요하다고 명시했고, 많은 버그가 특정 오버플로 동작에서 발생함.

이 기법을 실제로 어떻게 사용했는지 더 자세히 알려줄 수 있을까요? 비슷한 AI 기반 디컴파일 프로젝트를 시작하려고 해서 도움이 될 만한 방법을 찾고 있음.

다만 대부분의 함수와 변수에 꽤 의미 있는 이름을 자동으로 붙이는 일은 LLM만 할 수 있음.

원본과 입력·출력·의존성이 같은 함수를 구현하도록 범위를 제한해서, 에이전트가 설계 결정을 내리지 못하게 한 것인가요?

비용이 이렇게 많이 든 이유는 어셈블리 출력을 완전히 동일하게 만드는 목표 때문임. 컴파일러 버전과 최적화 옵션은 물론 온갖 조건을 조정해야 했을 것임. 기능적 동등성만 목표로 삼았다면 토큰을 10분의 1이나 100분의 1만 썼을 가능성이 있음.
Sonnet을 사용한 것도 잘못된 절약이라고 봄. Sol 6.1은 토큰당 가격은 높아도 역공학과 코딩을 100배쯤 더 잘해서 작업이 빠르고, 실수와 폐기할 결과물이 적음.
비슷한 작업에서 Sonnet 여러 개를 몇 주 돌려 약 1,000달러를 쓰고도 완성도 낮은 결과로 20%만 끝냈음. Sol 6.1로 바꾼 뒤에는 약 50달러와 이틀 만에, 감독 없이 /goal 하나로 전체 작업을 완료함. Opus는 안전장치가 너무 많아 역공학에 쓰기 어려웠고, OAI는 그런 제약이 거의 없으며 토큰도 훨씬 적게 사용해 경제적이었음.

동일한 출력은 터무니없는 목표가 아님. 게임이 모든 면에서 같다는 것을 보장하려면 사실상 필수임. 이런 디컴파일 프로젝트는 에뮬레이션의 고성능 대안인데, 비슷하기만 한 재구현은 아무도 쓰지 않을 것임.
기능적 동등성을 테스트하는 것도 사실상 불가능함. 아직 발견하지 못한 버그까지 똑같이 존재하는지, 새 버그가 생기지 않았는지 어떻게 확인할 것인가요? 스피드런 플레이어에게는 이런 차이가 중요함.

토큰 사용량이 매우 커 보여도 토큰 수가 곧 비용은 아님. 엄격한 하네스 덕분에 성능이 매우 낮은 모델도 효율적으로 활용할 수 있었고, 최소 2,000억~3,000억 토큰, 어쩌면 그 이상을 Luna가 처리한 것으로 봄.
Astra의 토큰당 가격은 Luna의 100배라서, Luna 3,000억 토큰은 비용상 Astra 30억 토큰이나 Sol 약 150억 토큰에 해당함. 안타깝게도 로그 상당 부분이 사라져 모델별 사용량과 비용을 자세히 분석할 수는 없음.

동일한 어셈블리 출력만이 기능적 동등성을 보장하는 방법임. 그렇지 않으면 일부 상황에서만 같을 뿐 100% 같지는 않음. 누군가에게는 버그가 다른 누군가에게는 기능일 수 있음.

vtable, 팻 포인터·슬라이스, 트레이트 같은 동적 디스패치의 역공학은 지옥 같을 것임. 패딩과 컴파일러 설정 차이도 크게 작용함.
디컴파일러를 항상 신뢰할 수 없어 결국 어셈블리를 직접 읽어야 하는데, 그 미묘한 동작을 해독하는 일은 LLM 이전에도 사람에게 쉽지 않았음. CTF를 하면서 내린 결론도 그랬음.
특히 JIT 같은 자기 수정 코드에서 두드러짐. 명령어 포인터와 점프해 들어간 영역에 따라 실행 흐름이 달라지므로, 단계 실행 디버거로 실제 제어 흐름을 확인해야 함. 이 지점에서는 IDA나 Ghidra를 이용한 정적 분석이 더 이상 통하지 않음.

접근 방식이 지나치게 복잡한 것 같아 단일 세션으로 했다면 얼마나 걸렸을지 궁금함. 보조 에이전트를 쓰기에 딱 맞는 작업일 수도 있지만, 나도 LLM을 처음 쓸 때는 각종 실행 조율 장치로 작업 흐름을 과하게 복잡하게 만들곤 했음.
지금은 에이전트 하나만 사용함. 조금 오래 걸려도 결과물을 통제하기가 더 쉽고, 어차피 내 시간 대부분은 프롬프트 작성과 검토에 들어감.

가장 빠른 모델도 초당 약 1,000토큰 수준이므로 10억 토큰을 순차 처리하면 1~2주가 걸림. 5,000억 토큰이면 그 500배임. 실제로 그만큼 필요하지 않았더라도, 필요한 양이 그보다 한두 자릿수 적은 수준이었다면 이런 접근이나 동등한 결과를 내는 다른 병렬 처리 방식이 필수였을 것임.

모든 소프트웨어를 디컴파일하고 복제할 수 있다면 앞으로는 어떻게 될까요? 전부 SaaS가 되고 PC 대부분은 단말기가 될까요? 게임 콘솔은 이미 거의 그 단계이며, 모든 소프트웨어가 그렇게 바뀌는 데 큰 도약은 필요하지 않아 보임.
또 다른 가능성은 에이전트만 사용하는 소프트웨어임. 사용자가 원하는 결과를 말하면 에이전트가 질문하고 전문 소프트웨어를 사용해 결과를 돌려주는 방식임. 우리는 AI 비서와 전문 에이전트를 구독하게 될 것임. 이미 그 시작에 가까워졌으며, 지금 같은 PC의 시대는 끝을 향하고 있음. 운영체제·CLI·컴파일러 등이 AI 비서에 흡수되면 사람을 위한 소프트웨어를 만드는 시대에도 작별하게 될 것임.

크래킹은 원래 가능했으니, 달라진 것은 기술 지식 없이도 독점 소프트웨어를 수정·개선할 수 있다는 점임. 이제 Astra나 Fable에 Adobe Photoshop의 원하는 기능만 설명해 추가해 달라고 해도 성공할 수 있을 것 같음. Fable은 안전장치 때문에 안 될 수도 있고 며칠 걸리겠지만, 가능하다고 봄. PhotoBench라고 부르면 될까요?

SaaS가 아닌 폐쇄형 소프트웨어는 이미 끝난 것 아닌가요? 머지않아 모두 AI가 만든 맞춤형 소프트웨어를 사용할 것 같음. 나도 제작 비용이 워낙 낮아서 작업마다 일회용 소프트웨어를 만들어 사용하고 있음.

모든 것이 SaaS가 되는 미래는 LLM에 원하는 것을 말해 맞춤 구현을 얻을 수 없을 때만 성립함. 원래 개인 프로젝트를 많이 했지만 이제 개발 속도가 크게 빨라졌고, 돈 내고 쓰던 여러 제품을 충분히 잘 작동하는 자체 구현으로 대체함. 멀티플레이어 게임처럼 통일된 경험을 원하는 공동체가 필요한 서비스가 아니라면 SaaS가 지속 가능한 사업 모델일지 의문임.

기업이 돈을 내는 소프트웨어 대부분은 사실상 SaaS이거나, 소프트웨어 자체는 제공물의 작은 일부이고 지원 서비스가 실제 수익원인 형태임.

이 글은 AI가 쏟아내는 PC 이식작을 왜 게임 보존이라고 보기 어려운지 잘 보여줌. 내게는 보존이 이런 이식의 목적이었고, LLM 유행 이전의 애호가들도 대체로 그것을 추구했음.
눈에 띄는 버그가 없고 원작의 모든 기능이 있으며, 바이트가 일치하지 않는 나머지 함수도 의미는 정확하다고 믿는다고 하지만, 믿음 외에는 확인할 방법이 없음. 결국 수천 개의 미세한 변경으로 원래 의도와는 다른 게임이 만들어졌을 수 있음.

DMCA 통지를 몇 차례 받아서 중단한 것임. 계속했다면 최대한 100%에 가깝게 맞췄겠지만, 이런 상황에서는 의미가 없었음. 그래서 우리의 확신과 몇 차례 최종 테스트로 마무리함.

Fable 5.1조차 컨텍스트 압축 전에 기록한 memory 파일 내용을 안정적으로 기억하지 못함. 그렇다면 장황해서 반드시 컨텍스트 한도를 넘기고 압축이 필요해질 어셈블리를 처리하면서, 어떤 부수 효과도 잊지 않을 것이라고 어떻게 믿을 수 있을까요?

게임에 관한 모든 세부 사항을 지우라고 위협할 때 어떤 법적 근거를 썼는지 이해하기 어려움. 게임명과 회사명을 알려줄 수 있을까요?
게임을 역공학해 코드를 공개하면 구체적으로 무엇을, 어떻게, 어느 관할권에서 침해하게 되나요? LLM으로 했을 때는 무엇이 달라지나요?
지금 LLM 디컴파일이 걷잡을 수 없이 확산하고 있어 무언가 제동을 걸 것 같기는 함. 미국 LLM의 시스템 프롬프트가 역공학 지원을 금지하고 의심스러운 활동을 법무 신고 창구에 바로 전달하도록 바뀌는 것은 아닐지 우려됨.

이전 버전의 페이지에 나온 게임명은 Call of Duty: Modern Warfare 2 (2009) 임.

1986년 Whelan Associates Inc. v. Jaslow Dental Laboratory 판결은 프로그램의 구조·순서·조직을 저작권으로 보호했음. 코드를 그대로 복사하거나 기계적으로 번역하지 않고 독립적으로 작성해도 이런 요소를 베끼면 침해가 될 수 있었고, 이후 약 6년간 소프트웨어 복제물은 사실상 침해로 취급될 만큼 보호 범위가 넓었음.
1990년대 초 Computer Associates International, Inc. v. Altai Inc. 등에서 기준이 좁아졌고, 1992년 이후 대부분의 법원은 비문언적 요소의 보호 가능성과 침해 여부를 판단할 때 추상화·여과·비교의 3단계 테스트를 사용해 왔음.
하지만 Whelan 기준이 법률이나 판결로 완전히 폐기된 것은 아니며, 이 기준으로 승소한 기업도 있음. 대표적으로 Android의 Java API를 둘러싼 Oracle과 Google 소송이 있음. Google의 최종 승소는 대법원이 API 사용을 공정 이용으로 인정했기 때문이지, 선언 코드의 구조·순서·조직에 관한 연방항소법원의 저작권 판단을 뒤집어서가 아님. 게임 전체를 역공학한 경우에도 대법원이 같은 호의를 보일지는 의문임.
이런 프로젝트는 Whelan 기준은 물론 더 엄격한 Altai 기준에서도 저작권을 침해할 수 있다고 봄. 원본은 C이고 재구현은 Rust라는 이유나, 각 함수를 조금씩 다르게 작성했다는 이유만으로 면책되지는 않음.

핵심적인 AAA 게임 개발 지식 상당수가 이미 공개돼 있는데 기존 게임 바이너리를 역공학하는 것은 불필요해 보임. https://github.com/ValveSoftware/halflife/blob/master/pm_sha...
LLM도 이런 자료를 학습했을 가능성이 높음. Hammer와 Unity 사이의 크기 변환은 간단한 선형 연산이고, BSP에서 지오메트리를 추출한 뒤 이미 검증된 타이밍을 활용하면 맵 개발을 크게 가속할 수 있음. 바이너리를 직접 공략하는 것은 인상적이지만 전혀 필요하지 않음.

LTO를 사용하면 이런 분석이 좀 더 어려워질지 궁금함. 작은 컴파일 단위로 나눌 수 없다면 기계어에서 C 코드를 복원할 방법도 찾기 어려울 것 같음.