오늘날 우리가 당연하게 여기는 디렉터리 구조나 설치형 드라이버 같은 개념이 PC 운영체제에 처음 자리 잡은 시점은 1983년의 MS-DOS 2.0이었다. 그 배경에는 유닉스를 표준으로 만들려던 마이크로소프트의 야심, 메모리에 인색했던 IBM의 요구, 그리고 사내 창업자 두 사람의 정면충돌이 얽혀 있다. 초기 PC 소프트웨어가 어떤 제약 위에서 설계됐는지를 이해하면, 지금 우리가 쓰는 파일 시스템과 드라이버 모델의 뿌리도 함께 보인다.
원치 않았던 자식, 그리고 유닉스라는 꿈
MS-DOS의 출발점은 팀 패터슨이 만든 86-DOS였다. 그의 고용주 시애틀 컴퓨터 프로덕츠(SCP)가 이미 8086 기반 CPU 보드를 출시해 놓고도 마땅한 운영체제가 없었기 때문에, 급하게 만들어낸 임시방편이었다. 패터슨은 학창 시절 Z80용으로 멀티태스킹 시스템을 만든 경험을 살려 제대로 된 시스템을 짜고 싶어 했지만, 시간이 없었다. 그래서 그는 1974년 인텔 8080용으로 나온 최소한의 운영체제 CP/M을 닮은, 이른바 '빠르고 지저분한' 물건부터 만들기로 상사와 합의했다.
반면 폴 앨런과 빌 게이츠는 처음부터 16비트 미니컴퓨터에서 인기를 끌던 유닉스에 승부를 걸었다. 1980년 2월 마이크로소프트는 웨스턴 일렉트릭으로부터 유닉스 V7 소스 코드를 라이선스했고, 이름은 라이선스에 포함되지 않아 같은 해 8월 자체 유닉스 계열 제품인 제닉스(XENIX)를 발표했다. 두 사람은 유닉스의 이식성과 유연성이 제닉스를 16비트 마이크로컴퓨터의 표준으로 만들 것이라 확신했다. 그러나 막상 소스를 손에 넣고 보니 유닉스는 당대 마이크로프로세서, 특히 인텔 8086과 잘 맞지 않았다. 1969년 켄 톰프슨이 PDP-7에서 만든 첫 버전 이후 덩치가 크게 불어난 유닉스는 메모리를 지나치게 잡아먹었다. 결국 마이크로소프트는 유닉스 컨설팅 전문 소기업 SCO에 이식 작업의 상당 부분을 넘겼다.
IBM의 등장과 어정쩡한 피라미드
IBM이 8088 기반 PC를 16KB RAM으로 시작하겠다고 밝히자, 제닉스를 그 안에 욱여넣는 일은 불가능해졌다. IBM은 CP/M 같은 가벼운 무언가가 필요했고, 디지털 리서치와의 라이선스 협상이 무산되자 마이크로소프트로 돌아왔다. 마이크로소프트는 SCP로부터 86-DOS를 사들여 IBM PC에 맞춰 다듬은 뒤 PC-DOS라는 이름으로 1981년 8월 출하했다. 동시에 다른 고객에게 MS-DOS라는 이름으로 팔 권리는 자사가 쥐었다.
그럼에도 단일 작업만 되는 CP/M 클론이 새 세대 PC에 부족하다는 불안은 남았다. 디지털 리서치가 멀티유저·멀티태스킹 MP/M-86과 뒤이어 Concurrent CP/M을 내놓자, 마이크로소프트는 계층형 전략으로 맞섰다. 맨 아래에 단일 사용자·단일 작업 MS-DOS, 맨 위에 멀티유저·멀티태스킹 제닉스, 그 중간에 제닉스의 단일 사용자 버전인 XEDOS를 두는 '상향 호환 운영체제 피라미드'를 1982년 1월 바이트 매거진 사설로 공표한 것이다. XEDOS는 단순한 마케팅이 아니었다. 마이크로소프트와 SCO는 제닉스에서 기능을 덜어내 PC에서 쓸 만하게 만들려 했으나 성과가 거의 없었다. 폴 앨런은 2011년 회고록 『아이디어 맨』에서 축소판 유닉스조차 8086 칩에는 너무 버거웠다고 적었다.
앨런의 고집이 만든 재작성
계획이 바뀐 것은 1982년 초, IBM이 하드디스크를 내장한 PC XT용으로 새 DOS를 요청하면서다. XT는 원본 PC의 소폭 개선판이었고, IBM이 원한 것도 오직 하드디스크 지원뿐이었다. 기능 추가보다 운영체제를 작게 유지하는 편이 훨씬 중요했다. 빌 게이츠는 순순히 따르려 했지만, 폴 앨런은 리드 개발자 마크 즈비코프스키, 애런 레이놀즈와 상의한 끝에 DOS가 관련성을 유지하려면 깨끗한 재작성이 필요하다고 확신했다.
앨런이 밀어붙인 핵심은 세 가지였다. 첫째, FAT 파일 시스템을 확장해 유닉스처럼 루트 디렉터리와 중첩된 하위 디렉터리를 갖춘 계층 구조로 바꾸는 것이었다. 그 결과 CP/M식 파일 컨트롤 블록(FCB) 대신 파일 핸들이 도입됐고, 호환성을 위해 FCB도 남겨 두었다. 둘째는 동적 로드 가능한 드라이버였다. 1.x에서는 단일한 BIOS 모듈이 모든 하드웨어를 다뤄 주변기기 하나만 바뀌어도 BIOS를 다시 컴파일하거나 패치해야 했지만, 2.0에서는 설정 파일이 가리키는 설치형 드라이버를 필요할 때 읽어 들이도록 했다. 셋째는 제한적인 백그라운드 프린트 스풀링으로, 애플리케이션이 프린터 출력을 기다리며 멈추지 않도록 작은 유틸리티가 출력을 대신 떠맡는 방식이었다. 다만 유닉스나 MP/M 수준의 완전한 멀티태스킹은 고려되지 않았다. 여기에 find, more, sort, fc 같은 제닉스 유래 유틸리티와 chdir, mkdir이 추가됐고, 단일 작업 특성상 메모리 파이프는 빠진 형태의 입출력 리디렉션도 포함됐다.
IBM은 이 야심을 반기지 않았다. DOS 1.1이 쓰던 약 8KB 수준을 최대한 지켜 기존 사용자 기반을 흔들지 않기를 원했고, DOS가 메모리를 많이 먹으면 작은 PC에서 인기 앱이 돌 공간이 부족해질까 우려했다. 게이츠는 내부적으로 IBM을 '고객'이라 부르며 관계를 해치기를 극도로 꺼렸고, 보카레이턴에서 불만이 들어오자 IBM을 '멍청이들'이라 부른 앨런과 겁에 질린 즈비코프스키 앞에서 고성을 주고받았다. 결국 게이츠가 물러서 납기만 맞춘다는 조건으로 앨런 팀의 기능 구현을 허락했다.
여섯 명의 팀과 재작성의 규모
MS-DOS 2.0 팀은 폴 앨런, 마크 즈비코프스키, 애런 레이놀즈, 낸시 패너스, 크리스 피터스, 마니 우요아 여섯 명이 전부였다. 1.0을 만든 팀 패터슨과 밥 오리어는 참여하지 않았다. 제품은 1983년 3월 8일 IBM PC XT와 함께 PC-DOS 2.0으로 출하됐는데, 약 20KB RAM을 요구해 1.0보다 훨씬 무거웠던 탓에 한동안 두 버전이 나란히 팔렸다.
재작성의 규모는 소스로 확인된다. MS-DOS 1.25 소스 트리에는 파일이 7개뿐으로, 커널 전체가 MSDOS.ASM 한 파일에, BIOS와 COMMAND.COM도 각각 단일 파일에 담겨 있었다. 반면 2.0 디렉터리에는 118개의 ASM 파일과 문서가 들어 있고, 커널·BIOS·COMMAND.COM이 구조를 반영해 여러 파일로 쪼개졌다. 물론 FNDCLUS, BUFSEC, DATE16, READTIME 같은 루틴은 이름과 주석, 코드까지 거의 그대로 옮겨졌고, XENIX.ASM과 XENIX2.ASM에는 유닉스에서 이식한 새 명령들이 담겼다. 어셈블러와 Z80-8086 변환기, HEX2BIN처럼 1.25에만 있던 도구는 계승되지 않았다.
오늘의 실무자 관점에서 이 이야기가 주는 교훈은 분명하다. 계층형 디렉터리와 설치형 드라이버라는, 지금은 운영체제의 기본기로 여겨지는 요소들이 처음부터 자명했던 게 아니라 메모리 제약과 고객 요구, 그리고 내부의 격렬한 이견 사이에서 겨우 관철된 선택이었다는 점이다. 앨런이 지목한 '유닉스를 향한 작은 한 걸음'은 완전한 유닉스화가 아니라, 제약 안에서 취할 수 있는 요소만 골라 이식한 절충이었다. 축소판이 통하지 않을 때 위에서 덜어내기보다 아래에서 필요한 것만 끌어올리는 편이 현실적이었다는 판단은, 레거시 호환성과 신기능 사이에서 균형을 잡아야 하는 오늘의 시스템 설계에도 여전히 유효하다.