Windows ConfidentialWindows 95 뒷이야기

Raymond Chen

Windows® 95용 32비트 프로그램은 보편적인 32비트 컴파일러로 개발할 수 있었고 16비트 프로그램은 보편적인 16비트 컴파일러로 개발할 수 있었지만 Windows 95 자체를 개발하는 데는 32비트와 16비트 영역을 모두 이해하고 둘 사이를 잇는 특별한 컴파일러가 필요했습니다. 또한 Windows 95에는 이러한 두 가지 유형의 코드를 연결할 줄 아는 사용자 지정 링커도 필요했고, VxD(Windows 95의 드라이버 형식)를 위한 사용자 지정 링커도 필요했습니다.

Windows 95 팀은 언어 및 도구 사업부의 도움을 받아 이러한 특수 목적 컴파일러와 링커를 제공받을 수 있었습니다. 언어 사업부의 입장에서 "X, Y 그리고 Z 작업을 수행하면서, 수명이 다할 때까지 오직 두 개의 DLL을 컴파일하는 데만 사용될 컴파일러를 작성해 달라”라는 요청은 생소하게 들렸을 것입니다. 사실입니다. 다만 이 두 가지는 아주 중요한 DLL이었습니다.

얼핏 말이 안 되는 요청이었지만 어쨌든 언어 및 도구 사업부는 요구 사항에 따랐고, 고도로 전문화된 이 컴파일러와 링커는 Windows 95 빌드 프로세스의 일부가 되었습니다. 물론 컴파일러가 처음부터 완벽하게 제공된 것은 아닙니다. Windows 팀은 예비 버전을 받았고 이후 새로운 최적화가 구현되고 버그가 수정된 업데이트를 정기적으로 받았습니다.

그러던 어느 날 Windows 95 빌드가 예기치 못한 지체에 직면했습니다. 원래 몇 초에 불과했던 파일 링크 시간이 훨씬 더 늘어났던 것입니다. 파일 생성은 여전히 정상적으로 이루어졌지만 시간이 너무 많이 걸렸습니다. 게다가 이 문제는 개발자 한 명의 컴퓨터가 아니라 전체 팀원들에게서 일어났습니다. 코드가 갑자기 링커의 약점을 건드린 것일까요? 아니면 링커의 버그였을까요?

얼마간의 디버깅 후 문제의 근원을 찾았습니다. 최신 버전의 링커에 언어 팀 직원들이 Windows 팀에 코드를 넘기기 전에 깜박하고 제거하지 않은 약간의 진단용 코드가 포함되어 있었던 것입니다. 이 진단용 코드는 출력을 파일에 기록했고, 이 파일은 한 컴파일러 팀원 자리에 있는 컴퓨터에 저장되었습니다. 그런데 이 컴퓨터가 꺼진 것입니다. 이 사건은 분산 시스템을 “다운된 사실이 알려지지 않은 한 컴퓨터로 인해 아무런 작업도 완료할 수 없게 되는 시스템”으로 묘사하여 유명해진 Leslie Lamport를 연상시킵니다.

fig84a.gif

문제의 링커 버전은 그전까지 몇 주 동안 아무 문제 없이 실행되었습니다. 누군가가 Windows 95를 빌드할 때 VxD를 링크하려고 시도할 때마다 그 컴파일러 팀원의 컴퓨터에 위치한 파일이 업데이트되었습니다. 이 컴퓨터가 켜져 있고 네트워크에 연결되어 있는 동안에는 아무도 문제를 알아채지 못했습니다. 그런데 어느 날 이 컴퓨터가 꺼지면서 모든 작업이 지체된 것입니다.

일단 문제의 원인이 밝혀지자 컴파일러 담당 직원들은 오래지 않아 링커의 진단용 코드를 제거하는 패치를 Winodws 팀에 전달했습니다.

이 이야기에는 화자에 따라 여러 가지 반전이 숨어 있습니다. 필자가 이 이야기를 할 때 반전은 “그 컴파일러 개발자가 나중에 Windows 팀으로 와서 내 상관이 됐잖아”입니다. 필자는 이 이야기를 가벼운 우스개로 종종 써먹곤 합니다.

그런데 필자의 상관이 이야기의 화자라면 반전은 이렇게 달라집니다. “나중에 밝혀진 사실이지만 그 진단용 코드를 작성한 사람은 내가 아니야. 코드의 주인은 내 동료 중 한 명인데, 이 친구가 자기 컴퓨터 대신 내 컴퓨터로 진단 정보가 전송되도록 한 거라구!”

Raymond Chen은 자신의 웹 사이트 The Old New Thing에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있으며 동명의 저서에서도 이에 대해 다루었습니다. Raymond의 DNA는 아마 폐기된 코드로 가득 차 있을 것입니다.