안녕하세요. 10년 차 개발자 김현수입니다.
개발자라면 한 번쯤 들어봤을 전설 같은 이야기가 있죠.
IBM이 PC 운영체제를 찾으러 갔다가, 빌 게이츠의 MS-DOS를 선택하게 된 그 사건 말입니다.
보통은 이걸 '세기의 비즈니스 드라마'로 기억합니다.
Digital Research(DRI)의 게리 킬달이 IBM과의 미팅을 놓쳤다거나, 계약서 문제로 틀어졌다는 식으로요.
하지만 우리 같은 엔지니어의 관점에서 이 사건을 다시 보면, 아주 서늘한 교훈이 숨어 있습니다.
결국 이건 '기술 부채'와 '리소스 관리'의 실패에 관한 이야기거든요.
오늘 커피 한 잔 하면서, 그 시절 코드를 짜던 선배들의 '뼈아픈 실수'를 되짚어보죠.
이건 지금 우리 팀에서 벌어지고 있는 일일지도 모르니까요.
1. "죄송합니다, 아직 포팅이 안 끝났어요"
사실 가장 치명적인 문제는 비즈니스 협상 태도가 아니었습니다.
1980년 8월, IBM 관계자들이 DRI를 찾아왔을 때 상황은 명확했습니다.
IBM은 16비트(Intel 8086) 기반의 PC를 만들고 있었죠.
그런데 당시 업계 표준이었던 CP/M은 여전히 8비트 버전만 돌아가고 있었습니다.
IBM이 "16비트 버전 데모를 보여달라"고 했을 때, DRI는 보여줄 게 없었어요.
반면 마이크로소프트는 재빠르게 움직였죠.
왜 기술력 1위였던 DRI는 16비트 포팅(Porting)이 늦어졌을까요?
여기에 모든 개발자가 공감할 만한 '두 가지 늪'이 등장합니다.
2. 첫 번째 늪: 개발자의 '딴짓' 본능 (feat. 오버 엔지니어링)
당시 DRI의 창업자이자 천재 개발자였던 게리 킬달.
그는 CP/M의 16비트 마이그레이션보다 더 꽂혀 있는 게 있었습니다.
PL/I 컴파일러 개발이었죠.
킬달은 기존 언어들이 마음에 들지 않았고, 완벽한 애플리케이션 언어를 직접 만들고 싶어 했습니다.
우리도 이런 경험 있지 않나요?
회사의 핵심 제품은 유지보수가 시급한데, 갑자기 새로운 프레임워크나 언어론에 심취해서 사이드 프로젝트에 리소스를 쏟아붓는 상황 말이에요.
킬달은 이 컴파일러를 9개월 만에 끝내려 했지만, 결국 2년이 걸렸습니다.
그 2년 동안, 정작 회사의 밥줄인 OS의 차세대 버전(CP/M-86) 개발은 우선순위에서 밀렸죠.
나중에 킬달 스스로도 이 프로젝트를 "엄청난 방향 전환(삽질)"이었다고 회고했을 정도입니다.
3. 두 번째 늪: 성공이 불러온 '유지보수 지옥'
그렇다면 다른 개발자들은 놀고 있었을까요? 아닙니다.
여기서 캐서린 스트루틴스키(Kathryn Strutynski)라는 핵심 개발자가 등장합니다.
그녀는 'CP/M 2의 어머니'라 불릴 만큼 뛰어난 프로그래머였습니다.
문제는 당시 버전인 CP/M 2.2가 너무 성공적이었다는 데 있었습니다.
당시 하드웨어 시장은 춘추전국시대였습니다.
8인치 디스크, 5.25인치 디스크, 심지어 하드 디스크까지 등장했죠.
CP/M의 구조상 하드웨어 제조사(OEM)마다 BIOS를 수정해야 했는데, 이게 말처럼 쉽지 않았습니다.
제조사들은 끊임없이 DRI에 기술 지원을 요청했습니다.
고객사 커스텀 대응 업무가 폭주한 거죠.
아이러니하게도, 캐서린은 차세대 버전인 16비트 CP/M을 개발해야 할 핵심 인력이었지만,
현행 버전(Legacy)의 유지보수와 고객 지원에 발목이 잡혀버렸습니다.
4. 적에게 무기를 쥐여주다
여기서 정말 기막힌 역설이 발생합니다.
당시 캐서린이 가장 열심히 기술 지원을 해준 고객사가 어디였는지 아시나요?
마이크로소프트였습니다.
빌 게이츠와 폴 앨런은 애플 II 컴퓨터에 CP/M을 돌리기 위해 'SoftCard'라는 하드웨어를 만들고 있었거든요.
캐서린은 폴 앨런의 소파에서 쪽잠을 자가며 마이크로소프트가 CP/M을 잘 돌릴 수 있도록 코드를 최적화해 줬습니다.
결국 마이크로소프트는 이 SoftCard로 엄청난 돈을 벌었고, 운영체제 시장에서의 입지를 다졌습니다.
DRI가 '운영 업무'에 치여 허덕이는 동안, 경쟁자는 그 지원을 바탕으로 무럭무럭 성장해 버린 겁니다.
결국 16비트 CP/M 개발은 1년 이상 지연되었고,
그 사이 IBM은 기다리다 지쳐 마이크로소프트의 손을 잡았습니다.
그 뒤의 역사는 우리가 아는 대로입니다.
5. 마치며: 우리는 무엇을 배워야 할까요?
10년 전이나 지금이나 소프트웨어 엔지니어링의 본질은 똑같습니다.
"새로운 기능을 개발할 것인가, 운영 이슈를 막을 것인가."
DRI는 이 밸런스 게임에서 졌습니다.
리더(게리 킬달)는 비즈니스 임팩트가 적은 기술적 이상(컴파일러)을 쫓았고,
핵심 개발자(캐서린)는 과도한 운영 업무(Support)에 매몰되어 미래를 준비할 시간을 뺏겼습니다.
혹시 지금 여러분의 팀도 비슷하지 않나요?
레거시 시스템의 트래픽을 받아내느라 정작 MSA 전환이나 차세대 플랫폼 구축은 계속 미뤄지고 있진 않은가요?
아니면 당장 필요한 기능 배포보다, 팀장이 꽂힌 최신 AI 도구 도입에 시간을 더 쓰고 있진 않은가요?
기술은 거짓말을 하지 않습니다.
하지만 '타이밍'을 놓친 기술은 시장에서 아무런 힘을 쓰지 못합니다.
오늘 동료들과 커피 한잔하며 우리 팀의 리소스는 어디로 흐르고 있는지 한번 점검해 보는 건 어떨까요?
제2의 CP/M이 되지 않으려면 말이죠.
