---
title: "1989년 도스 게임 ‘F-15 스트라이크 이글 2’ 복원 프로젝트, 이제 테스트 파일럿 구함"
published: 2026-06-20T15:10:03.000Z
canonical: https://jeff.news/article/4221
---
# 1989년 도스 게임 ‘F-15 스트라이크 이글 2’ 복원 프로젝트, 이제 테스트 파일럿 구함

1989년 도스 게임 ‘F-15 스트라이크 이글 2’의 원본 바이너리를 역공학해서 C 소스 코드로 복원하는 프로젝트가 큰 고비를 넘겼다. 모든 실행 파일의 C 코드와 데이터가 재구성됐고, 이제부터는 opcode 일치 확인을 넘어 실제 게임 플레이에서 터지는 버그를 잡아야 하는 단계다. 프로젝트 측은 도스 환경에서 직접 플레이하며 크래시, 그래픽 깨짐, 키 입력 문제를 찾아줄 테스트 참여자를 찾고 있다.

- 1989년 도스 게임 ‘F-15 Strike Eagle II’를 C 코드로 되살리는 역공학 프로젝트가 꽤 큰 마일스톤을 찍었음
  - 이 프로젝트는 원본 바이너리를 분석해서 당시 게임의 C 소스 코드를 다시 만들어내는 취미 프로젝트임
  - 한 달 전만 해도 두 번째 실행 파일인 `egame`은 몇 년 더 걸릴 분위기였고, 세 번째 실행 파일인 `end`는 아직 손도 많이 남은 상태였다고 함
  - 그런데 지금은 모든 실행 파일의 C 코드가 재구성됐고, 데이터도 assembly에서 C 쪽으로 옮겨졌고, assembly-only 코드 대부분도 C로 기능 대체가 끝난 상태임

- 이제 문제는 “코드가 맞냐”보다 “게임이 제대로 돌아가냐”로 넘어갔다는 점임
  - 기존 툴링은 재구성한 코드의 opcode가 원본과 계속 맞는지 확인해줄 수 있음
  - 하지만 데이터 레이아웃 문제처럼 실제 실행 중에만 드러나는 버그는 자동으로 다 잡아주지 못함
  - 그래서 프로젝트가 조용한 정적 검증 단계에서, 진짜 플레이 가능한 게임을 유지해야 하는 단계로 진입한 셈임

> [!IMPORTANT]
> 이 프로젝트의 핵심은 ‘비슷한 리메이크’가 아니라 원본 바이너리의 동작을 최대한 보존하는 복원임. 그래서 원작에도 있던 버그는 지금 당장 고치면 안 되는 대상임.

- 프로젝트 측은 이제 도스 테스트 파일럿을 모집 중임
  - 최신 릴리스는 `v0.9.1`이고, 원본 게임 `451.03` 버전과 데저트 스톰 확장팩 조합에서 동작해야 함
  - 사용법은 새 실행 파일을 원본 게임 폴더에 넣어 기존 실행 파일을 교체하는 방식임
  - 다만 원본 파일은 백업해두는 게 필수고, 기존 `f15.com`이 새 `f15.exe` 대신 실행되지 않도록 제거해야 할 수도 있음

- 현재 빌드는 설정 화면으로 들어가지 않고, 기본 환경을 가정하고 바로 동작함
  - 화면은 MCGA/VGA로 가정함
  - 사운드와 조이스틱은 없는 것으로 가정함
  - 그래도 미션 브리핑, 비행, 디브리핑까지 게임의 세 파트는 전부 동작해야 한다고 함

- 테스트에서 찾아줬으면 하는 건 전형적인 “실행해봐야만 보이는” 문제들임
  - 크래시가 나는지
  - 그래픽이 깨지는지
  - 키 입력이 안 먹는지
  - DOSBox에서는 `Ctrl+F5`로 스크린샷을 찍을 수 있으니, 화면 문제가 있으면 같이 첨부하면 좋다고 함
  - 어떤 행동을 하다가 문제가 났는지까지 적어주면 재현과 수정에 훨씬 도움이 됨

- 흥미로운 포인트는 이게 ‘버그까지 포함한 재구성’이라는 점임
  - 원작에도 3D 오브젝트가 사라지는 문제, 비행기가 뒤집힌 상태에서 연료가 떨어지면 하늘 쪽으로 떨어지는 이상한 동작 같은 버그가 있었다고 함
  - 이런 동작이 원본에도 있으면 지금은 그대로 유지해야 함
  - 그래서 버그를 제보하기 전에는 원본 게임에서도 같은 현상이 나는지 비교해보는 게 좋다고 프로젝트 측이 강조함

- 결국 이 단계는 포팅 프로젝트로 가기 전 마지막 현실 검증에 가까움
  - 코드가 C로 재구성됐다고 끝이 아니라, 실제 게임으로 굴렸을 때 원본과 같은 방식으로 망가지고 같은 방식으로 돌아가야 함
  - 레트로 게임 보존 프로젝트에서 커뮤니티 플레이 테스트가 왜 중요한지 보여주는 사례임

---

## 기술 맥락

- 이 프로젝트에서 선택한 방식은 새 게임 엔진을 만드는 게 아니라 원본 바이너리를 C 코드로 되살리는 쪽이에요. 왜냐면 목표가 현대식 리메이크가 아니라 1989년 게임의 실제 동작을 보존하는 데 있기 때문이에요.

- opcode 일치 검증은 꽤 강한 안전장치지만, 그걸로 모든 실행 버그를 잡을 수는 없어요. 특히 오래된 C/assembly 코드에서는 구조체 배치나 데이터 정렬 같은 문제가 런타임에서만 이상하게 터질 수 있거든요.

- 그래서 지금 필요한 건 단위 테스트보다 실제 플레이 테스트에 가까워요. 미션 브리핑, 비행, 디브리핑처럼 게임 흐름 전체를 사람이 타고 지나가야 입력, 그래픽, 상태 전환 문제가 드러나기 때문이에요.

- ‘버그까지 보존한다’는 조건도 중요해요. 원작에도 있던 버그를 새 코드에서 고쳐버리면 겉으로는 좋아 보여도, 복원 정확도 관점에서는 오히려 원본에서 멀어진 거거든요.

## 핵심 포인트

- 세 개 실행 파일 전체의 C 코드와 데이터 재구성이 완료됨
- 현재 릴리스는 v0.9.1이며 원본 451.03 버전과 데저트 스톰 확장팩 기준으로 테스트 가능
- 목표는 원작과 같은 동작을 보존하는 ‘버그까지 포함한’ 재구현이라 원작에도 있던 문제는 당장 수정 대상이 아님

## 인사이트

옛 게임 복원이라고 하면 낭만 프로젝트처럼 보이지만, 실제로는 바이너리 호환성, 데이터 레이아웃, 실행 환경 재현이 얽힌 꽤 빡센 소프트웨어 보존 작업이다. 특히 ‘원작의 버그도 보존해야 한다’는 조건이 붙는 순간, 일반적인 리팩터링이나 포팅과는 완전히 다른 게임이 된다.