33년 전 워드 1.1a, 64비트로 되살아나다 — 원본 소스 그대로의 이식 실험

1989년 마이크로소프트가 코드네임 'Opus'로 개발했던 Microsoft Word for Windows 1.1a가 최신 64비트 윈도우에서 네이티브로 구동되는 형태로 다시 등장했다. 개발자 jmarshall23가 공개한 이 프로젝트는 원본 워드의 C 소스 코드와 리소스 파일을 그대로 빌드하되, 16비트 어셈블리와 세그먼트 메모리 모델, Win16 플랫폼 경계처럼 현대 환경에서 더 이상 유효하지 않은 부분만 대체하는 방식을 택했다. 그 결과는 에뮬레이터도 아니고, 최신 에디터 컨트롤을 껍데기로 씌운 재구현도 아니다. 원본 워드 애플리케이션과 그 사용자 경험이 문자 그대로 64비트 실행 파일로 돌아간다.

이식의 원칙: 원본을 건드리지 않는다

이 프로젝트에서 가장 눈여겨볼 지점은 이식의 철학이다. 원본 C 코드와 리소스 파일이 여전히 '권위 있는 구현(authoritative implementation)'으로 남아 있고, 포트는 그 코드를 64비트 윈도우에서 안전하게 빌드하고 실행하기 위한 플랫폼 작업만 추가한다. 즉 워드의 동작 로직 자체를 다시 쓰는 것이 아니라, 원본 루틴은 가능한 한 소스 등가(source-equivalent) 번역으로 옮기고, 피할 수 없는 윈도우 API 적응 작업은 포트 경계(port boundary) 한 곳에 격리하는 구조다. 모든 네이티브 인터페이스는 포인터 폭에 안전하도록(pointer-width safe) 다듬어져, 16비트 시절 코드가 64비트 주소 공간에서 깨지지 않게 한다.

흥미로운 결정 하나는 레거시 어셈블리 코드의 처리 방식이다. CMake 빌드 시스템은 원본의 어셈블리 트리를 목록으로는 포함(inventory)하지만, 그 모듈들을 실제 네이티브 타깃으로 컴파일하지는 않는다. 오래된 어셈블리 구현을 참조용 자료로 남겨두면서도, 실제로 빌드되어 배포되는 코드는 전부 AMD64에서 유효하도록 보장하기 위한 절충이다. 역사적 원형을 훼손하지 않으면서 현대 아키텍처에서의 안전성을 확보하는, 아카이브와 실행 가능성 사이의 균형점인 셈이다.

빌드와 검증

빌드 과정은 현대적인 도구 체인 위에 얹혀 있다. 저장소를 클론한 뒤 포함된 CMake 프리셋을 구성하고 파워셸에서 빌드하면 되며, 최적화된 결과물이 필요하면 릴리스 프리셋을 사용한다. 프리셋은 비주얼 스튜디오 2022의 x64 제너레이터를 쓰기 때문에, 구성 후 생성되는 솔루션 파일(out\MicrosoftWordX64Port.sln)을 VS에서 직접 열어 WORD1을 시작 프로젝트로 지정해 작업할 수도 있다. out, build, bin 디렉터리는 구성과 컴파일 과정에서 로컬로 생성된다.

단순히 컴파일만 되는 수준이 아니라 검증 체계도 함께 제공된다는 점이 실무적으로 주목할 만하다. 저장소 루트에서 디버그 혹은 릴리스 테스트 스위트를 실행할 수 있는데, 이 테스트는 이식된 x64 런타임뿐 아니라 원본 워드의 데이터 구조와 커맨드 테이블, 프로세스 시작 과정, 그리고 타이핑·선택·서식 지정·대화상자·저장을 아우르는 자동화된 UI 워크플로까지 다룬다. 다시 말해, 옛 코드가 그저 실행되는 것을 넘어 원본과 동일하게 동작하는지를 회귀 테스트로 확인하겠다는 의도가 설계에 반영돼 있다. 새로 번역한 동작에는 집중적인 테스트를 추가하라는 기여 지침도 이런 방향과 맞닿아 있다.

실무자에게 주는 의미와 한계

한국의 IT 실무자 관점에서 이 프로젝트가 흥미로운 이유는 단순한 향수 이상의 지점에 있다. 16비트에서 64비트로 넘어가는 이식은 세그먼트 메모리에서 평면(flat) 메모리로의 전환, 정수와 포인터 폭 불일치, 플랫폼 API 경계 재설계 등 레거시 마이그레이션에서 반복적으로 마주치는 난제를 압축적으로 보여준다. 특히 '원본 로직은 소스 등가로 옮기고, 플랫폼 종속 코드는 경계 한 곳에 몰아 격리한다'는 원칙은 오래된 코드베이스를 현대 환경으로 옮겨야 하는 팀이라면 그대로 참고할 만한 실전 패턴이다. 레거시를 재작성하지 않고 살려내되, 변경분마다 테스트로 뒷받침한다는 접근은 리스크가 큰 마이그레이션의 정석에 가깝다.

다만 명확한 한계도 함께 짚어야 한다. 프로젝트 스스로 밝히듯 이것은 '연구 목적(research purposes)'의 이식이며, 실무 문서 작업용 제품이 아니다. 더 중요한 것은 권리 문제다. 역사적 소스 파일들은 여전히 마이크로소프트와 제3자의 원본 저작권 표기를 그대로 담고 있고, 저장소에는 현재 최상위 라이선스 파일이 포함돼 있지 않다. 따라서 소스나 바이너리를 재배포하려는 경우 적용되는 권리를 반드시 사전에 확인해야 한다. 결국 이 작업은 상용 활용의 대상이라기보다, 소프트웨어의 이식성과 레거시 보존이라는 주제를 코드 수준에서 관찰할 수 있는 살아 있는 교재에 가깝다.