윈도우 x86 실행 파일을 받아 현재 아키텍처용 네이티브 바이너리로 바꾸겠다는 실험적 프로젝트, 'Theseus'가 공개됐다. 핵심은 전통적인 동적 에뮬레이션이나 JIT 대신, 32비트 Windows 실행 파일을 Rust 코드로 정적으로 번역한 뒤 다시 컴파일한다는 점이다.12
이게 중요한 이유는 단순히 "옛날 프로그램을 돌리는 새 방법"이 하나 늘어서가 아니다. 지금 소프트웨어 업계의 더 큰 문제, 즉 내부를 거의 다 갈아엎었는데도 같은 제품이라고 불러도 되는가를 아주 선명하게 보여주기 때문이다. 이 질문은 철학이 아니라 호환성, 신뢰, 마이그레이션 비용의 문제다.
같은 앱인지 판단하는 기준은 코드가 아니라 연속성이다
'테세우스의 배' 역설은 부품을 하나씩 교체해도 같은 배인가를 묻는다.3 소프트웨어에서는 이 질문이 더 자주, 더 실무적으로 등장한다.
예를 들어 UI는 그대로인데 백엔드를 전면 교체한 SaaS, "리빌드 from scratch"를 선언한 모바일 앱, 기존 바이너리를 다른 방식으로 실행하는 호환 계층이 그렇다. 공급자는 같은 제품이라고 말하고 싶어 한다. 사용자도 가능하면 그렇게 믿고 싶다. 하지만 실제 판단 기준은 이름이나 브랜드가 아니다.
실무적으로는 네 가지가 남아 있어야 "같다"는 말이 성립한다. 동작, 데이터, 워크플로, 그리고 기대 가능한 신뢰성이다. 버튼이 같은 자리에 있어도 파일 포맷이 미묘하게 바뀌면 팀의 업무 흐름은 깨진다. 기능 목록이 비슷해도 자동화 스크립트와 플러그인이 안 돌면 운영 관점에선 다른 제품이다.
이 관점은 Theseus를 이해하는 데도 그대로 적용된다. 원본 .exe는 남아 있지만, 실행 방식은 바뀐다. CPU를 그대로 흉내 내는 대신, 분석 가능한 코드를 뽑아 현대 컴파일러에 맡긴다.12 "원본 프로그램을 실행한다"기보다 "원본의 동작을 다른 구조로 재구성한다"에 가깝다. 그래서 질문도 바뀐다. 원본과 같은 코드인가가 아니라, 어디까지 같은 결과를 보장하는가다.
에뮬레이터가 아니라 번역기일 때 생기는 장점과 새 위험
전통적인 에뮬레이터는 대체로 명령어를 해석하거나, QEMU처럼 실행 중 JIT 번역을 수행한다.4 이 방식의 장점은 범용성이다. 다양한 프로그램을 비교적 같은 프레임워크로 다룰 수 있다.
Theseus가 택한 정적 번역은 반대로 범용성을 줄이고, 특정 실행 파일에 대한 최적화를 노린다. 프로젝트 설명에 따르면 Theseus는 32비트 Windows x86 코드를 Rust로 번역하는 컴파일러와, 일부 Win32 API 구현을 함께 제공한다.2 작성자는 이 접근이 JIT의 복잡성을 피하면서도 컴파일러 최적화를 활용할 수 있다고 본다.1
여기서 얻는 실익은 분명하다. 첫째, 성능 잠재력이다. 실행 중 매번 명령어를 해석하는 오버헤드를 줄일 수 있다. 둘째, 배포 형태의 단순화 가능성이다. 성공만 한다면 결과물은 x86이나 Windows에 직접 의존하지 않는 네이티브 바이너리가 된다.2 셋째, 디지털 보존 관점에서 흥미롭다. 낡은 하드웨어를 보존하지 않아도 특정 프로그램의 생명을 연장할 수 있다.
하지만 대가도 크다. 작성자 자신도 이 프로젝트가 "매우 실험적"이며 임의의 프로그램에는 아마 동작하지 않을 것이라고 밝힌다.2 정적 번역의 고질적 한계도 있다. 런타임 코드 생성 같은 경우는 애초에 범위 밖이고, 점프 테이블·간접 호출처럼 정적으로 도달 가능한 코드를 완전히 식별하는 일은 원리적으로 어렵다.1 즉, 빠를 수는 있어도 "아무거나 된다"는 약속은 하기 힘들다.
이 지점에서 반론도 가능하다. "그럼 결국 범용 에뮬레이터보다 불편한 것 아닌가?" 맞다. 많은 사용자에게는 그렇다. QEMU 같은 범용 도구가 여전히 중요한 이유다.4 다만 Theseus의 메시지는 다르다. 모든 프로그램을 다 돌리려 하지 말고, 꼭 살려야 할 몇 개를 더 잘 다루자는 것이다. 보존과 이식의 세계에서는 이 선택이 꽤 현실적일 수 있다.
"같은 제품, 새 엔진"을 볼 때 먼저 확인할 것
Theseus를 흥미로운 실험으로만 보면 절반만 읽은 셈이다. 더 중요한 건 이 프로젝트가 소프트웨어 재작성과 플랫폼 이전을 보는 체크리스트를 준다는 점이다.
첫째, 동일성의 기준을 마케팅 문구가 아니라 사용자 자산으로 잡아야 한다. 데이터 포맷, 저장 파일, 자동화, 플러그인, API 호환성 중 무엇이 유지되는가.
둘째, 성능 주장보다 예외 처리 범위를 봐야 한다. "더 빠르다"는 말은 보통 잘 되는 경로 기준이다. 진짜 리스크는 간접 호출, 오래된 라이브러리, 특이한 시스템 API처럼 가장자리에서 드러난다.
셋째, 지원 대상이 범용인지 선별적인지 확인해야 한다. Theseus처럼 특정 프로그램에 수작업 보정을 감수하는 접근은 연구, 보존, 내부 업무 도구엔 맞을 수 있다. 반대로 불특정 다수 고객용 플랫폼이면 유지보수 비용이 급증할 수 있다.
넷째, 신뢰의 단위를 정해야 한다. 코드가 같지 않아도 결과가 같으면 충분한가, 아니면 디버깅 가능성과 재현성까지 같아야 하는가. AI 제품이 같은 UI 뒤에서 모델과 내부 파이프라인을 계속 바꾸는 지금, 이 질문은 더 날카로워졌다. 사용자에게 "같은 제품"은 보통 같은 아이콘이 아니라 같은 기대를 뜻한다.
Theseus는 아직 실험 단계다. 하지만 바로 그래서 흥미롭다. 내부를 바꾸는 일은 이제 예외가 아니라 기본값이 됐다. 개발자와 구매자 모두에게 필요한 건 "같다/다르다"의 철학적 정답이 아니다. 무엇이 유지되고, 무엇이 깨지고, 그 비용을 누가 떠안는지 묻는 습관이다.
참고
1Theseus, a Static Windows Emulator
2GitHub - evmar/theseus: static translator for win32 executables · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.