[B급 프로그래머] (재난) 마이크로소프트 워드 포 윈도우 프로젝트

약속했듯이 오늘은 재앙에 가까웠던, 아니 재앙 그 자체였던 마이크로소프트 워드 포 윈도우 프로젝트를 살펴봄으로써 과거가 우리에게 주는 몇 가지 교훈을 생각해보자.

빌게이츠 중심의 문화

마이크로소프트 사는 영웅 숭배 시스템을 창조해서 심지어 빌이 만나보지 조차 않은 직원에게까지 빌 게이츠의 의지가 영향을 미치도록 만들었다. 북한의 김일성과 마찬가지로, 시애틀 근교에 있는 회사에도 이런 방식이 통했다.

'김일성'이라는 단어를 보자마자 히스테리를 일으켜서 바로 댓글을 달려는 분들도 있겠지만, 잠깐만 참자. 위 인용구(!)는 Accidental empires를 지은 Robert X Cringely가 한 말이다. 낄낄... 요즘이야 상당히 안정적으로 돌아가는 마이크로소프트 사지만 초기에는 구둣발 문화가 어떠했는지 안봐도 DVD가 아닌가?

이런 시스템의 중심에는 '메타 프로그래밍' 이론을 만들어낸 찰스 시모니가 버티고 있었다. 시모니는 한 명이 대규모 소프트웨어 개발 팀을 제어하도록 만드는 계층적인 구조를 마음 속에 그리고 있었다. 빌은 이런 구조를 "소프트웨어 공장"이라고 마음에 들어했다.

유감스럽게도 이런 방식은 성공하지 못했다. 그래도 '하드 코드'에 나오는 아키텍트와 프로젝트 관리자라는 제도가 자리잡히도록 만들었으니 절반의 성공이긴 하다. 나머지 절반의 실패란? 초기에 이런 절대 군주 구조에 따른 피해는 심각했다. 마이크로소프트 워드 포 윈도우 1.0이 대표적인 예다.

워드 포 윈도우 프로젝트는 원래 리차드 브로디가 이끌었다. 제록스 팔로 알토 연구소의 인턴이었던 브로디는 찰스 시모니의 지도 하(?)에 신형 워드 프로세스 개발에 나섰지만, 엄청난 타격을 입고 작가(마인드 바이러스를 집필했다)이자 프로 포커 선수로 전향한다. 브로디 말을 직접 들어볼까?

1983년 10월에 워드가 출시되었을 때, 지금은 응용 부문이라고 불리는 조직에 프로그래머 30명에 마케팅 1명이었다. 문제는, 멀티플랜(찰스 시모니가 만든 스프레드 시트)이 이미 나와 있었으며, 사용자 인터페이스가 완성되어 있었다. 나는 워드를 멀티플랜과 호환되도록 만들어야만 했다. 내 임무는 다음과 같았다. "스프레드시트 사용자 인터페이스를 탑재한 세상에서 첫번째 워드 프로세스를 만든다."

피해를 복구하기까지 5년이 걸렸다.

이런 생기 발랄한 아이디어를 내고 이를 승인한 사람이 누군지는 독자 여러분들도 알고 계시리라...

잃어버린 5년

스티브 맥코넬이 쓴 Rapid Development 책 9장 '일정'을 보면 지나치게 낙관적인 일정의 대표적인 예로 마이크로소프트 워드 포 윈도우 1.0가 나온다. 잠시 살펴볼까?

윈도우즈용 워드, 줄여서 '윈워드'는 개발 기간 5년과 개발 인력 600월-인원을 들여서 만든 코드 249,000줄짜리 시스템이다. 최종 일정 5년은 원래 계획한 일정보다 대략 5배가 길었다. 1984년 9월에 시작해서 1989년 11월에 끝났다.

앞서 브로디가 말한 잃어버린 5년이 의미하는 바가 슬슬 이해되기 시작할 것이다. 빌게이츠가 비전 문을 어떻게 꾸몄을까?

'역사상 가장 우수한 문서 작성기'를 '가능한 빨리, 가급적이면 12개월 안에' 만들자.

무리한 일정 때문에 계획을 정확하게 세울 수 없었으며, 예측을 10번이나 변경했다. 프로젝트 중도 이직율도 장난이 아니라서, 5년 동안 브로디를 비롯해 개발 수석이 4번이나 바뀌었다. 2명은 일정 압력 때문에, 1명은 건강 문제로 그만두었다고 하니 그 당시 프로젝트 심각성을 미뤄 짐작이 가능하다. 게다가 일정 압력 때문에 개발자들은 기능을 대충 구현했다. 품질이 낮고 미완성이라는 사실을 알면서도 '완료'로 보고했다. 결국 3개월 정도 걸린다고 예상했던 안정화에만 12개월이 걸렸다.

다들 인정하겠지만, 막연한 기대가 주의깊은 계획수립을 대신할 수는 없다. 문제는 요즘도 윈워드 같은 일정 수립이 유행(?)이라는 사실이다.

공포의 버그 양산 프로젝트

워드 포 윈도우즈 프로젝트에서 나온 신조어 중에 "무한 결함"이 있다. 무한 결함? 개발자가 버그를 수정하는 속력보다 테스터가 버그를 찾아내는 속력이 더 빠르며, 버그를 하나 수정할 때마다 다른 버그가 어김없이 튀어나오는 현상이다. 이런 조건 하에서는 일정과 출시 일정 예측이 모두 무의미하다. 셀 수도 없는 버그를 수정하기 위해 코드 상당수를 다시 작성했지만, 복구하는 만큼 오류가 생겼다. 마이크로소프트 사의 테스트 감독인 로저 셔만이 이런 어두운 시기를 어떻게 회상했을까?

사람들은 '망했다'라는 메시지를 받았다... 이는 경주용 자동차 운전과 유사하다. 벽에 충돌하고 나면 벽이 어디에 있는지를 알게 된다.... 사람들은 얼마나 상상력이 풍부한지 얼마나 창의적인지에 무관하게 코드를 통채로 버리지 못하리라는 사실을 알게 되었다. 워드와 쌍 벽을 이루는 엑세스 프로젝트도 교훈이 될만하다. 엑세스 버그 데이터베이스는 덩치가 너무 커서 단일 서버로 처리하지 못했다. 너무나도 많은 활성 버그가 있어서 테스트 팀은 사실상 손을 놓고 있었다. "뭐가 문제야? 개발자들은 이미 우리(테스터)를 따라오려면 2년 어치 백로그부터 처리해야 할테니..." 그래서 테스터들은 모든 시간을 투입해서 자동화와 자동화 도구 개발에 힘썼다.

워드 개발자들이 테스터들을 시험한답시고 폰트 크기를 돌려주는 함수에 항상 12pt 값을 반환하게 만들었다는 이야기가 진실인지 아닌지는 모르겠지만, 위 회고문을 읽어보면 진실일지도 모르겠다는 공포가 엄습한다.

어찌되었거나 마이크로소프트 워드 프로젝트는 행복한 결말로 끝났다. '초난감 기업의 조건'에 아주 잘 나오지만, 경쟁사들이 정신줄을 놓고 있는 사이에 마이크로소프트 사는 완성도가 아주 높은 오피스 슈트를 준비했으며 일단 제국의 역습이 시작된 이래 한 번도 오피스 시장에서 선두를 빼았긴 적은 없다.

EOB