핵심 요약
- Babylonian Twins는 1993년 바그다드에서 개발된 게임으로, 원작은 68000 어셈블리 72,758줄 규모임
- 작업자는 Claude(요약에 따르면 Fable 5로 표기된 변형)와 Claude Code를 활용해 원작의 동작과 데이터를 분석함
- 분석 결과를 바탕으로 Godot 4 환경에서 원작의 동작과 데이터를 재구축함
분석
목차
LLM 레거시 포팅 사례: 30년 된 68000 어셈블리 72,758줄, Godot 4 이식기
1993년 바그다드, 한 Amiga 개발팀이 68000 어셈블리 72,758줄로 만든 게임이 있다. ‘Babylonian Twins’다. 30년이 지난 2020년대, 이 코드를 LLM 레거시 포팅으로 Godot 4에 올린 사례가 해시코드(원문 보기)에 올라왔다. 작업자는 Claude와 Claude Code를 동원해 원작을 분석하고, 현대판 Godot 4 환경에서 재구축했다. 필자는 이 사례가 단순한 “옛날 게임 복원”이 아니라 LLM 레거시 포팅의 현실적 한계와 가능성을 동시에 보여준다고 본다.
원작의 규모와 세 번에 걸친 변신
원작은 1993년 바그다드에서 태어난 68000 어셈블리 72,758줄짜리다. 이후 2010년경 C++로 다시 짠 버전(약 34,000줄)이 존재했고, 이 C++ 버전을 먼저 Godot으로 옮긴 이력이 있다. 그리고 최근 작업자는 원작 68000 어셈블리까지 직접 LLM 레거시 포팅 대상으로 끌어올렸다. 이 지점이 흥미롭다. 중간 우회 없이 원본 소스에서 직접 동작과 데이터를 추출해 Godot 4로 재구축했다는 뜻이기 때문이다.
| 단계 | 연도 | 언어/엔진 | 코드 규모 | 비고 |
|---|---|---|---|---|
| 원작 | 1993 | 68000 어셈블리 (Amiga) | 72,758줄 | 바그다드에서 개발 |
| C++ 재구현 | 2010 | C++ | 약 34,000줄 | 중간 포팅 단계 |
| Godot 4 포팅 | 2024~ | Godot 4 (GDScript/C#) | 미공개 | Claude 활용 분석 |
LLM 레거시 포팅 절차: Claude로 어셈블리를 어떻게 분석했는가
작업자는 Claude 변형과 Claude Code를 함께 사용했다. 공개된 요약 수준에서는 “원작의 동작과 데이터를 분석해 Godot 4에서 재구축”했다는 설명만 잡힌다. 구체적으로 디스어셈블 결과를 LLM에 어떻게 넣었고, 함수 단위로 어떻게 매핑했는지는 본문에서 확인되지 않는다. 이 부분이 LLM 레거시 포팅 논의에서 가장 아쉬운 지점이다. 도구는 열렸지만 절차는 검증되지 않았다.
50Hz 이중 구동이라는 구조적 시도의 의미
가장 눈에 띄는 시도는 이중 구동이다. 50Hz 기준으로 원작 동작을 별도로 재구현하고, 그 위에 현대판 Godot 4 버전을 얹어 두 게임을 동시에 돌리는 구조다. 원본 충실도와 현대적 편의성을 양쪽으로 잡으려는 의도로 읽힌다. 실무자 입장에서 LLM 레거시 포팅의 이런 접근은 단순 “이식”이 아니라 “재구축과 동시 구동”에 가깝다는 점이 중요하다. 검증된 절차 없이도 결과물 구조는 상당히 공격적이다.
수치와 한계: 무엇이 확인되지 않았는가
모든 수치가 단일 출처(RSS 요약)에 의존한다. 참고로 모은 Anthropic 상거래 에이전트 블루프린트(관련 맥락)은 본 사례와 직접 교차되지 않는다. 따라서 72,758줄, 34,000줄, 50Hz 이중 구동 같은 수치는 1차 소스(작업자 GitHub 또는 블로그)에서 다시 확인해야 한다. 필자가 보기에 이 사례는 LLM 레거시 포팅의 가능성을 보여주지만, 검증 가능한 정보가 충분하지 않다.
시사점: LLM 레거시 포팅, 도구와 절차의 투명성이 함께 가야 한다
LLM 레거시 포팅이 흥미로운 이유는 단순하다. 사람이 읽기 어려운 옛 코드를 모델이 중간에서 해석해 현대 언어로 옮기는 다리 역할을 하기 때문이다. 다만 이 사례처럼 RSS 한 줄로 요약된 정보만으로는 “LLM이 정말 어셈블리를 이해한 것인지, 아니면 C++ 버전을 다시 옮긴 것인지” 구분하기 어렵다. LLM 레거시 포팅 논의가 성립하려면 도구뿐 아니라 절차의 투명성이 함께 따라와야 한다.
쟁점 정리
- 원작 68000 어셈블리 직접 분석인지, 기존 C++ 재구현본을 다시 옮긴 것인지 구분이 안 된다
- 72,758줄·34,000줄·50Hz 이중 구동 수치는 단일 RSS 요약에 의존한다
- 이중 구동 구조는 LLM 레거시 포팅의 새로운 시도지만, 검증된 벤치마크가 없다
- Claude Code 활용 절차(디스어셈블 → 프롬프트 → 매핑)가 공개되지 않았다
- RSS 한 줄과 작업자 1차 자료 사이 검증 거리가 멀다
지금 바로 해볼 것
- 원문 해시코드 글을 직접 읽고 작업자 GitHub·블로그 등 1차 출처를 추적한다
- 본인 레거시 코드를 100~200줄 단위로 잘라 Claude에 입력해 함수 의존성 분석을 시험한다
- Godot 4에서 50Hz 루프와 60Hz 루프를 동시에 돌리는 작은 프로토타입을 만들어 이중 구동 가능성을 자체 검증한다
- 디스어셈블 결과(예: Ghidra 출력)와 원본 동작을 LLM에 교차 검증시키는 프롬프트 템플릿을 만든다
- 단일 RSS에만 의존하지 말고, 작업자의 GitHub 커밋 로그와 이슈 트래커를 함께 대조한다
자주 묻는 질문
Babylonian Twins는 어떤 게임인가요?
1993년 바그다드에서 Amiga용으로 개발된 액션 게임으로, 68000 어셈블리 72,758줄 규모로 만들어졌습니다. 2020년대 들어 LLM 레거시 포팅 사례로 Godot 4 이식이 보고되었습니다.
LLM이 정말 어셈블리를 읽을 수 있나요?
이론적으로는 가능하지만, 공개된 정보에서는 Claude가 원작을 어떻게 분해·매핑했는지의 절차가 확인되지 않습니다. 실제 절차는 작업자의 1차 자료로 검증해야 합니다.
50Hz 이중 구동은 무엇인가요?
원작이 동작하던 50Hz(유럽 PAL 기준) 타이밍을 Godot 4에서 별도로 재구현하고, 그 위에 현대판 게임을 함께 실행해 두 버전을 동시에 돌리는 구조를 말합니다. 원본 충실도를 유지하려는 시도로 보입니다.
지금 바로 LLM 레거시 포팅을 시도해볼 수 있나요?
소규모 코드(수백~수천 줄)부터 함수 단위로 LLM에 입력해 의존성과 동작을 추출해보는 시험부터 가능합니다. 단, 결과를 맹신하지 말고 디스어셈블러·정적 분석 도구와 교차 검증하는 습관이 필요합니다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: geeknews — LLM으로 1993년 Amiga 게임의 68000 어셈블리를 읽어 Godot에 포팅하기
전문가 코멘트(AI)
소프트웨어역공학전문가
LLM 기반 어셈블리 포팅은 역공학 비용을 낮추는 유망한 방향이지만, 검증 파이프라인 없이는 공학적 성취의 실체가 담보되지 않는다
68000 어셈블리 7만 줄을 현대 엔진으로 옮기는 문제는 단순 번역이 아니라 Amiga 커스텀 칩(Blitter·Copper·DMA)의 사이클 단위 동작과 비정형 데이터 레이아웃을 복원하는 역공학 과제다. LLM이 함수 단위 의미 재구성과 데이터 테이블 추출을 보조할 수 있다는 점은 분명한 진전이며, 전통적으로 수개월 걸릴 탐색 비용을 획기적으로 줄인다. 다만 어셈블리 수준에서는 그럴듯하지만 틀린 해석이 치명적이어서, Ghidra 같은 디스어셈블러 출력과 원본 바이너리 실행 결과를 교차 검증하는 결정론적 파이프라인 없이는 결과의 신뢰성이 확보되지 않는다. 50Hz 원작 재현본과 현대판을 동시에 구동하는 구조는 차등 테스트(differential testing)의 실용적 변형으로서 이 접근법에서 가장 공학적으로 가치 있는 아이디어다. 핵심 쟁점은 LLM이 실제로 어셈블리를 입력으로 삼았는지, 훨씬 쉬운 2010년 C++ 재구현본을 다시 옮긴 것인지이며, 이는 사례의 난이도와 의미를 근본적으로 바꾼다. 결국 이 접근법의 미래는 모델 능력 자체보다 검증 가능한 절차를 얼마나 공개하는가에 달려 있다.
게임엔진개발전문가
50Hz 참조 구현과 현대판의 이중 구동은 게임 보존형 포팅의 정석적 설계이지만, 프레임 검증 도구 체계가 뒷받침되어야 데모를 넘어선다
Godot 4는 2D 플랫포머 이식에 충분한 기능을 갖추고 있지만, PAL 50Hz 타이밍에 맞춰 설계된 원작 로직을 기본 60Hz 물리 틱 위에 올리면 정수 기반 물리와 충돌 판정이 미세하게 어긋날 수 있다. 레벨 데이터와 스프라이트 테이블을 원본 소스에서 직접 추출해 재사용하는 전략은 재창작이 아닌 보존 관점에서 올바른 접근이다. 50Hz 참조 구현과 현대판을 나란히 구동하는 이중 구동은 단순한 기술 과시가 아니라 프레임 단위 비교 검증의 토대가 될 수 있는 구조다. 다만 두 루프를 동시에 돌리는 설계는 입력 처리, 상태 동기화, 디버깅 복잡도를 배로 늘리며, 프레임 차이 자동 비교 도구가 없으면 상징적 데모 수준에 머문다. 커뮤니티 주도 레트로 이식은 게임 보존에 실질적 기여를 하지만, 라이선스 정리와 장기 유지보수까지 가야 가치가 완성된다. 원본 충실도와 현대적 편의성을 양립하려는 이중 목표 설정 자체는 이 장르에서 합리적인 방향이다.
비판적 분석가
‘기적의 어셈블리 포팅’ 서사는 기술 기록이라기보다 AI 코딩 도구 경쟁 시대가 요구한 마케팅적 상징일 가능성이 있다
이 사안에서 가장 크게 이득을 보는 주체는 Anthropic을 필두로 한 AI 코딩 도구 생태계다. ‘LLM이 30년 된 어셈블리 7만 줄을 읽었다’는 문장은 도구 경쟁이 치열해진 시점에 벤더와 트래픽을 쫓는 애그리게이터 모두가 필요로 하는 바이럴 서사이기 때문이다. 하지만 이면을 들여다보면, 1차 산출물(저장소·커밋 로그·재현 절차)이 확인되지 않은 채 단일 RSS 요약만으로 파생 콘텐츠가 양산되는 구조는 기록이 아니라 내러티브가 유통되고 있다는 신호로 읽힌다. 요약 속 ‘Fable 5’라는 알 수 없는 모델 명칭처럼 세부가 뒤섞인 점도, 이 사례가 전문 문서가 아니라 콘텐츠 재조합 과정을 통과했을 가능성을 시사한다. 우리가 진짜 주목해야 할 점은 포팅의 성패가 아니라, 검증 불가능한 성취담이 왜 하필 AI 도구 홍보 사이클과 맞물려 유통되는가이다. 독자가 스스로 물어야 할 것은 ‘이 사례를 반증하려면 무엇을 확인해야 하는가’이며, 그 답이 공개되지 않는 한 이 서사는 증거가 아니라 광고일 수 있다.
물밑 시나리오
- 실제 작업은 2010년 C++ 재구현본을 주 입력으로 수행되었고 68000 어셈블리는 부분 참조에 그쳤을 가능성이 있다 — C++ 버전의 존재가 먼저 알려져 있고 어셈블리 직접 분석의 절차 기록이 어디에도 남아 있지 않다는 정황이 근거다.
- 개인 취미 프로젝트가 커뮤니티 애그리게이터와 AI 도구 생태계의 트래픽 필요에 의해 ‘기적 사례’로 증폭되었을 가능성이 있다 — 1차 자료 확인 없이 단일 RSS 요약만으로 다수 파생 글이 생성된 유통 구조가 그 정황 증거다.