무슨 일이 있었나
ReC98 프로젝트의 메인 개발자 nmlgc가 프로젝트 블로그에 은퇴 소식을 올렸어요. ReC98은 일본의 고전 PC인 PC-98용으로 나온 초기 동방 프로젝트(Touhou Project) 게임들을 리버스 엔지니어링하는 프로젝트예요. 동방 프로젝트는 개발자 ZUN 한 명이 만든 탄막 슈팅 게임 시리즈예요. 우리가 아는 윈도우판보다 먼저, 1990년대 PC-98으로 나온 다섯 작품(TH01~TH05)이 있어요. ReC98은 이 다섯 게임의 실행 파일을 분석해서 원래 소스 코드에 최대한 가까운 C++ 코드로 되돌리는 걸 목표로 오랫동안 이어져 왔어요.
은퇴한 구체적인 사정이나 앞으로 저장소를 누가 어떻게 관리할지는 원문 블로그에 자세히 나와 있으니 직접 읽어보세요. 이 글에서는 이 프로젝트가 기술적으로 어떤 일을 했는지, 그리고 우리가 여기서 뭘 배울 수 있는지 정리해볼게요.
디컴파일이 뭐길래
컴파일은 사람이 읽는 소스 코드를 기계가 실행하는 바이너리로 바꾸는 과정이에요. 디컴파일은 그 반대고요. 문제는 이게 깨진 그릇 조각을 다시 맞추는 일에 가깝다는 거예요. 컴파일하면서 변수 이름, 주석, 함수 경계 같은 정보가 대부분 사라지거든요. 그래서 바이너리만 보고 원래 코드를 복원하려면 추론을 정말 많이 해야 해요.
ReC98이 특히 까다로운 이유는 대상이 1990년대 16비트 x86 실행 파일이라서예요. 이 시절 코드는 세그먼트 메모리 모델을 써요. 이게 뭐냐면, 메모리 주소를 숫자 하나로 쓰지 않고 '세그먼트:오프셋' 두 조각으로 나눠서 가리키는 방식이에요. 아파트 주소를 '동'과 '호수'로 나눠 부르는 거랑 비슷해요. 포인터도 near와 far로 나뉘어서, 64비트 평면 메모리에 익숙한 요즘 개발자 눈에는 꽤 낯설어요. 게다가 원작은 C/C++과 어셈블리가 섞여 있고, PC-98 전용 그래픽 하드웨어를 직접 다루는 코드도 많아요.
'바이트 단위로 똑같이'라는 집요함
ReC98의 핵심 원칙은 이거예요. 복원한 코드를 당시와 같은 계열의 컴파일러(볼랜드 Turbo C++ 계열)로 빌드하면 원본과 바이트 단위로 똑같은 실행 파일이 나와야 해요. 비슷하게 돌아가는 코드로는 부족하고, 컴파일 결과가 원본과 완전히 같아야 하는 거죠.
이렇게까지 하는 이유는 검증 때문이에요. 동작만 비슷하면 미묘한 버그나 타이밍 차이를 놓칠 수 있어요. 바이트가 일치하면 '이 코드가 원본 그 자체'라는 게 증명돼요. 대신 개발자는 옛날 컴파일러가 C++ 코드를 어떤 기계어로 바꾸는지, 레지스터를 어떤 순서로 쓰는지 같은 습관까지 다 알고 있어야 해요. 블로그에는 수년 동안 쓴 분석 글이 쌓여 있어요. 원작 코드의 버그와 이상한 설계, 그 버그가 실제 게임플레이에 어떤 영향을 주는지까지 꼼꼼하게 다뤘어요.
크라우드펀딩으로 굴러간 1인 프로젝트
운영 방식도 독특해요. ReC98은 팬들이 돈을 내고 작업 시간을 '주문'하는 크라우드펀딩으로 유지됐어요. 후원자가 원하는 작업(특정 작품 디컴파일, 버그 분석, 포팅 준비 등)에 돈을 걸면, 개발자가 그만큼 작업하고 결과를 블로그로 보고하는 구조예요. 오픈소스를 어떻게 지속할지에 대한 꽤 신선한 실험이었다고 볼 수 있어요.
업계 맥락: 게임 디컴파일 붐
최근 몇 년 사이 고전 게임 디컴파일은 하나의 흐름이 됐어요. 슈퍼 마리오 64나 젤다의 전설: 시간의 오카리나 같은 닌텐도 64 게임들이 매칭 디컴파일(원본과 똑같은 바이너리가 나오게 복원하는 방식)로 되살아났어요. 그 덕분에 PC 네이티브 포트, 고프레임 모드, 각종 모드(mod)가 쏟아져 나왔죠. ReC98도 같은 철학을 따라요. 다만 대상이 훨씬 마이너하고 자료도 적은 PC-98이라는 점, 그리고 거의 한 사람이 오랫동안 끌고 왔다는 점이 달라요.
한국 개발자에게 주는 시사점
실무에서 PC-98 디컴파일을 할 일은 없겠지만, 배울 건 많아요.
첫째, 컴파일러가 코드를 어떻게 바꾸는지 아는 능력은 성능 최적화나 보안 분석(악성코드 분석, 취약점 연구)에 그대로 쓰여요. Ghidra나 IDA 같은 도구를 한 번 만져볼 좋은 계기가 될 거예요.
둘째, 결과물을 검증할 수 있게 만드는 태도예요. '바이트 일치'라는 분명한 기준이 있었기 때문에 수년간의 작업이 흔들리지 않았어요. 리팩터링 전에 테스트부터 깔아두는 것과 같은 원리예요.
셋째, 1인 오픈소스의 지속 가능성이에요. 훌륭한 프로젝트도 결국 사람에게 달려 있어요. 그 사람이 떠날 때를 대비한 문서화와 인수인계가 얼마나 중요한지 다시 생각하게 돼요.
마무리
한 줄 정리: ReC98은 잃어버린 소스 코드를 바이트 단위로 되찾는 일이 얼마나 집요하고 멋진 작업인지 보여준 프로젝트예요.
1인 개발자가 오래 끌어온 오픈소스가 멈출 때, 커뮤니티가 이어받으려면 무엇이 준비돼 있어야 할까요? 그리고 매칭 디컴파일처럼 완벽한 검증을 위해 큰 비용을 치르는 방식, 실무에서도 가치가 있다고 보시나요?
🔗 출처: Hacker News