2026년 10월, 기술 전문 매체 Windows Latest가 흥미로운 사실을 확인했다. 가장 최신 운영체제인 윈도우 11 26H2의 깊은 곳에 1995년에 작성된 윈도우 95의 메모리 관리 코드가 여전히 남아 있다는 것이다. 이 유물 같은 코드는 정리되기는커녕 마이크로소프트에 의해 다시 컴파일되어 호환성 계층에 그대로 포함되었다. 이 코드의 유일한 목적은 30년 전 메모리 처리 규칙을 잘못 작성한 고전 프로그램들을 온전히 구동하는 데 있다.
마이크로소프트에게 하위 호환성이란 과거 소스 코드의 복사본을 영구히 보존하는 작업에 가깝다. 오래된 모듈을 최신 운영체제 안에 그대로 담아두면서, 과거 프로그램의 결함을 운영체제의 영구적인 규약으로 끌어올린 것이다. 오늘날 윈도우 11을 사용하는 모든 PC는 30년 전 이루어진 상업적 타협의 대가를 여전히 짊어지고 있다.
윈도우 11 도구 상자에 버젓이 자리 잡은 윈도우 95 코드
윈도우 11 26H2에서 이 살아있는 화석을 찾아내는 일은 어렵지 않다. 마이크로소프트 공식 Windows ADK 도구 모음을 설치하고 ‘Application Compatibility Tools’ 항목을 선택한 뒤 32비트 호환성 관리자를 실행하면 된다. 수많은 시스템 수정 패치 목록 속에서 EmulateHeap이라는 항목을 확인할 수 있다.
그림: 윈도우 11 호환성 관리 도구의 EmulateHeap 수정 옵션. 출처: Windows Latest
EmulateHeap의 작동 방식은 단순하면서도 과격하다. 오래된 소프트웨어에 이 옵션을 적용하면 시스템이 해당 프로그램의 힙 메모리 호출을 강제로 가로챈다. 메모리 할당 함수인 HeapCreate부터 메모리 고정 함수 LocalLock, 재할당 함수 GlobalReAlloc까지 모든 명령이 특수하게 구현된 모듈로 전달된다. 이 구현체의 동작 방식은 1995년에 출시된 윈도우 95와 정확히 일치한다.
마이크로소프트는 현대적인 알고리즘으로 옛 시스템의 동작을 흉내 내는 방식을 택하지 않았다. 오랜 기간 마이크로소프트의 핵심 개발자로 일한 레이먼드 첸(Raymond Chen)의 기록에 따르면, 개발팀은 윈도우 95 힙 관리자의 원본 소스 코드를 직접 가져와 다시 컴파일한 뒤 호환성 모듈에 넣었다. 동작 흉내라는 불완전한 방식 대신 정품 원본 코드를 그대로 써서 예측 불가능한 호환성 문제를 원천 차단한 것이다. 그렇게 31년 전의 기계어 명령들은 최신 운영체제에서도 당당히 자리를 지키게 되었다.
심시티 하나를 구하기 위해, 게임 개발사의 버그를 떠안은 마이크로소프트
이 비상식적으로 보이는 패치는 30년 전의 치열한 비즈니스 경쟁에서 비롯되었다. 1995년 마이크로소프트가 윈도우 95 출시를 앞두고 있던 당시, 전 세계적으로 큰 인기를 끌던 PC 게임 ‘심시티(SimCity)‘가 테스트 환경에서 계속 비정상 종료되는 현상이 발생했다. 새 운영체제에서 대작 게임이 제대로 돌아가지 않는다면 사용자들은 게임이 아니라 운영체제 자체에 문제가 있다고 여길 것이 분명했다.
그림: 당시 전 세계적으로 인기를 끈 도시 경영 시뮬레이션 게임 ‘심시티 2000’. 출처: Nap’n’Retrogaming
마이크로소프트 엔지니어들이 원인을 추적한 결과 문제는 전적으로 게임 내부에 있었다. 심시티 개발자 존 로스(Jon Ross)는 훗날 프로그램 안에 전형적인 ‘해제 후 사용(use-after-free)’ 결함이 있었다고 밝혔다. 게임이 운영체제에 메모리를 반환한 뒤에도 이미 버린 메모리 공간의 데이터를 계속 읽으려 했던 것이다.
윈도우 3.x 시절에는 초기의 허술한 메모리 구조 덕분에 이런 심각한 결함이 겉으로 드러나지 않았다. 16비트 기반 시스템은 협조적 멀티태스킹 방식을 사용했기 때문에, 애플리케이션이 메모리를 해제하더라도 물리 주소의 데이터가 즉시 비워지거나 회수되지 않았다. 이전 데이터가 제자리에 그대로 남아 있었기에 게임은 운 좋게 정상 작동할 수 있었다. 하지만 윈도우 95가 선점형 멀티태스킹과 32비트 힙 관리자를 도입하면서 해제된 메모리는 즉시 덮어쓰이거나 비워졌고, 게임은 실행 즉시 튕겨버렸다.
전 마이크로소프트 프로그램 매니저 조엘 스폴스키(Joel Spolsky)는 2000년에 발표한 글에서 당시의 비화를 밝혔다. 마이크로소프트는 게임 제작사인 맥시스(Maxis)에 긴급 패치를 요구하는 대신, 윈도우 95 커널의 메모리 할당자 안에 맞춤형 감지 로직을 추가했다. 실행 중인 프로그램이 심시티로 확인되면 메모리 할당자가 메모리를 즉시 회수하지 않는 특수 모드로 작동하도록 한 것이다. 상용 소프트웨어의 원활한 안착을 위해 운영체제가 제3자의 코드 결함을 스스로 떠안은 셈이다.
심각한 보안 결함을 시스템 계약으로 승격시킨 타협
당시 소프트웨어 시장에는 이러한 결함이 흔했다. 1990년대 중반 PC 소프트웨어 시장이 폭발적으로 성장하면서 미완성 상태의 32비트 프로그램들이 쏟아져 나왔다. 수많은 개발자들은 윈도우 95의 너그러운 실행 환경에 익숙해진 나머지 ‘메모리를 해제한 후에도 옛 데이터를 읽을 수 있는 현상’을 운영체제의 기본 사양처럼 여겼다.
이후 윈도우 NT 계열이 기존 9x 계열을 완전히 대체하면서 보다 엄격한 기업용 보안 힙 구조가 도입되었다. 그 결과 수많은 고전 게임과 기업용 소프트웨어들이 새 운영체제에서 줄줄이 오작동을 일으켰다. 마이크로소프트가 수천 개의 프로그램마다 커널에 개별 예외 코드를 일일이 집어넣는 것은 불가능했다. 방대한 소프트웨어 생태계를 보호하는 것과 운영체제 구조의 순수성을 지키는 것 사이에서 개발팀은 실용적인 타협안을 택했다.
그림: 최신 호환성 계층 안에서 살아남은 윈도우 95 힙 관리 코드의 흐름. 출처: Windows Latest
개발팀은 윈도우 95 소스 코드 저장소에서 힙 관리 컴포넌트를 통째로 분리해 EmulateHeap이라는 독립적인 호환성 수정 플러그인을 만들었다. 보안 관점에서 보면 해제 후 사용은 임의 코드 실행으로 이어질 수 있는 고위험 결함이다. 하지만 데스크톱 운영체제 시장의 현실 앞에서 하위 호환성은 시스템 설계의 원칙을 압도했다. 과거의 프로그램 오류가 운영체제의 공식적이고 장기적인 규약으로 굳어진 것이다.
현대적인 WinUI 3로 인터페이스를 바꾸면서도 1995년 모듈을 붙들고 있는 현실
호환성에 대한 이러한 집착은 개발 현장에서 독특한 대비를 만들어낸다. 마이크로소프트는 운영체제의 겉모습을 현대화하는 데 많은 노력을 쏟고 있다. 수십 년 동안 쓰이던 파일 속성 창까지 최신 WinUI 3 프레임워크로 교체되고 있으며, 메모리 안전성을 근본적으로 개선하기 위해 윈도우 커널에 Rust 언어를 적극 도입하고 있다.
하지만 화려한 현대식 인터페이스 이면에는 오랜 기술적 부채가 고스란히 남아 있다. 2026년에 나온 윈도우 11 26H2 버전에서조차 마이크로소프트는 최신 컴파일 파이프라인을 사용해 31년 전 윈도우 95 힙 관리자 코드를 다시 빌드하고 설치 이미지에 담아 배포한다. 반면 과거 사용자들의 큰 사랑을 받았던 기본 탑재 게임 ‘3D 핀볼’은 일찌감치 자취를 감추었다.
64비트 전환 당시 3D 핀볼이 제외된 이유는 지극히 현실적이었다. 핀볼의 충돌 감지 코드가 전부 32비트 어셈블리어로 작성되어 있었고 부동소수점 관련 로직 문서도 전혀 남아 있지 않았다. 64비트 환경으로 옮겨오자 공이 패들을 그대로 뚫고 지나가는 문제가 발생했다. 원인을 분석하는 데 며칠이 넘는 시간이 걸릴 것으로 보이자 마이크로소프트는 미련 없이 게임을 삭제했다. 마이크로소프트의 과거 코드 수용에는 분명한 기준이 있다. 기본 게임은 언제든 버릴 수 있지만 기반 시스템의 호환성은 절대 건드릴 수 없다는 점이다.
31년간 이어진 끝없는 타협, 최신 하드웨어가 치르는 비용
마이크로소프트가 수십 년 동안 지켜온 이 유물 코드는 최신 하드웨어 환경에서 점차 한계를 드러내고 있다. 윈도우 11 22H2 이후 버전부터 고전 게임 팬들 사이에서 EmulateHeap이 제대로 작동하지 않는다는 불만이 꾸준히 제기되고 있다. ‘GTA 바이스 시티’나 ‘니드 포 스피드: 모스트 원티드’ 같은 명작 게임을 이 옵션으로 실행하면 배경음이 출력되지 않거나 실행 직후 꺼지는 문제가 빈번하게 발생한다.
그 원인은 현대 PC 구조가 1995년 당시의 물리적 설계를 완전히 벗어났기 때문이다. 요즘 컴퓨터는 멀티코어 프로세서를 탑재하고 정교한 비순차적 명령어 실행과 하드웨어 메모리 격리 체계를 갖추고 있다. 윈도우 95의 힙 관리자는 단일 코어와 평면 메모리 환경을 전제로 설계되었기 때문에, 현대의 최신 그래픽 드라이버 및 복잡한 멀티스레드 환경과 원활하게 어우러지기 어렵다.
끝없는 하위 호환성은 윈도우의 독보적인 비즈니스 방벽을 만들어주었지만, 동시에 막대한 기술적 부채를 안겨주었다. 운영체제가 한 단계 발전할 때마다 마이크로소프트는 어제의 짐을 전부 등에 짊어져야 했다. 30년 전 작성된 임시 패치는 이제 쉽게 걷어낼 수 없는 디지털 화석이 되었다. 기술이 너무나 멀리 나아간 지금, 과거를 무한히 배려하겠다는 약속은 결국 최신 환경을 이용하는 모든 사용자에게 무거운 부담으로 돌아오고 있다.
참고 자료:
- Windows Latest 보도: 왜 윈도우 11에 여전히 윈도우 95 메모리 관리자가 숨겨져 있는가
- 조엘 온 소프트웨어 칼럼: 전략 서한 2권: 닭과 달걀의 문제
- 마이크로소프트 기술 문서: 윈도우 호환성 칼럼의 EmulateHeap 메커니즘 분석
