7만 줄의 어셈블리 코드를 바이너리 수준으로 재현

이번 작업의 핵심은 1993년 아미가 500(Amiga 500) 기반으로 제작된 게임 '바빌로니안 트윈스(Babylonian Twins)'를 현대의 고도(Godot) 4 엔진으로 옮긴 것이다. 사용된 도구는 클로드 코드(Claude Code) 환경에서 구동된 클로드 페이블 5(Claude Fable 5)다. 이 모델은 주석이 거의 없는 72,758줄의 68000 어셈블리 코드를 읽고 분석해 현대적 언어로 재구현하는 역할을 맡았다.

단순한 기능 모방이 아니라 원본 바이너리와의 일치 여부를 검증하는 과정이 포함됐다. LLM은 현대적 어셈블러인 vasm을 사용해 1993년의 소스코드를 다시 빌드하고, 그 결과값이 실제 출시된 바이너리와 바이트 단위로 일치하는지 diff 도구로 확인했다. 이 과정에서 모델은 서로 다른 어셈블러 간의 문법 차이를 메우는 전처리 단계를 스스로 설계해 적용했다.

데이터 복구 능력도 확인됐다. 헤더와 치수가 없는 압축된 바이너리 레벨 맵에서 타일 그리드 구조, 물리 속성(충돌, 등반 가능 여부 등), 적 캐릭터의 행동 패턴을 역설계해 추출했다. 특히 픽셀 단위 비교를 통해 하늘의 그라데이션과 물의 색상 주기 같은 하드웨어 특화 효과(Copper list)까지 찾아내어 고도 엔진에서 재현했다. 최종적으로 1993년 원작과 2026년 이식판을 하나의 프로그램 내에서 선택해 실행할 수 있는 구조로 통합했다.

'회상'이 아닌 '추론'으로 진입한 레거시 마이그레이션

이번 사례는 LLM이 학습 데이터에 의존하는 '회상' 능력을 넘어, 주어진 코드를 논리적으로 분석하는 '추론' 단계로 진입했음을 보여준다. 아미가 어셈블리 코드는 최신 LLM 학습 세트에 포함된 양이 매우 적다. 그럼에도 모델이 성공적으로 포팅을 수행한 것은 코드의 패턴과 하드웨어 동작 방식을 실시간으로 분석해 작동 원리를 파악했기 때문이다.

채택 흐름의 변화는 개발자의 역할에서도 나타난다. 개발자는 직접 코드를 작성하는 대신, 결과물을 플레이하며 "점프 느낌이 이상하다"거나 "충돌 판정이 어색하다"는 피드백을 주는 결정권자(Decision Maker)의 역할로 옮겨갔다. LLM은 이 피드백을 바탕으로 60Hz와 50Hz라는 서로 다른 틱 레이트(Tick rate) 사이의 마찰력 계산 차이를 찾아내고, 이를 수정하는 방식으로 최적화를 진행했다.

더 주목할 지점은 개발 이후의 운영(Ops) 단계까지 자동화 범위가 확장됐다는 점이다. LLM은 11개 언어의 스토어 스크린샷을 찍기 위해 게임을 직접 실행해 특정 좌표로 캐릭터를 이동시키고 캡처하는 과정을 자동화했다. 또한 API가 없는 스팀(Steam) 대시보드의 경우 브라우저를 직접 제어해 메타데이터를 입력하고 업로드하는 방식으로 배포 공수를 줄였다. 이는 AI가 단일 함수 작성을 넘어 '기획-개발-QA-배포'라는 전체 파이프라인을 핸들링하는 도구로 진화하고 있음을 의미한다.

한국 AI 실무자가 관찰해야 할 지점

국내 기업이나 개발자가 주목해야 할 부분은 문서화되지 않은 '레거시 시스템의 현대화' 가능성이다. 많은 산업 현장에는 소스코드가 유실되었거나, 작성자가 퇴사해 분석이 불가능한 오래된 바이너리 시스템이 존재한다. 이번 사례처럼 LLM이 바이너리 분석과 현대적 엔진 이식을 동시에 수행할 수 있다면, 시스템 교체 비용과 리스크를 획기적으로 낮출 수 있다.

다만, AI가 모든 것을 해결하지는 않는다. 이번 포팅 과정에서도 AI는 가드 캐릭터의 밀치기 범위 설정을 잘못 처리해 벽 너머의 플레이어를 공격하게 만들거나, 사운드 루프 길이를 잘못 계산해 소리가 끊기는 오류를 범했다. 이러한 '논리적 엣지 케이스'는 결국 도메인 지식을 가진 인간의 테스트와 검증을 통해서만 해결 가능하다.

실무자는 이제 "AI가 코드를 짤 수 있는가"가 아니라 "AI가 복잡한 레거시의 맥락을 얼마나 정확하게 추론하고, 이를 검증할 수 있는 자동화 환경(테스트 하네스, 바이너리 비교 도구 등)을 구축할 수 있는가"를 판단 기준으로 삼아야 한다. 특히 이번 사례에서처럼 AI에게 터미널 권한과 파일 시스템 접근권을 주고, 스스로 빌드하고 실행하며 결과를 확인하게 하는 '에이전트형 워크플로우'가 실제 생산성에 어떤 영향을 주는지 관찰할 필요가 있다.