Joel on Software   조엘 온 소프트웨어

한글로된 다른 "Joel on Software" 글들

영어로된 다른 "Joel on Software" 글들

필자 메일주소(영어만 사용)

지난해 10월, 미국의 북동부 지역은 어딜 가나 아셀라(Acela) 광고 천지였다. 아셀라란 암트랙(Amtrak)이 워싱턴-보스턴간 노선에서 운행할 새로운 초고속열차의 이름. 끊임없이 쏟아지는 TV 광고와 전광판 광고, 도처에 나붙은 포스터들을 보면서, 누구라도 이 정도의 물량 공세라면 이 새로운 초고속열차 서비스에 대한 수요 창출에 상당히 기여했으리라 생각했을 것이다.

글쎄, 그랬는지도 모르지. 하지만, 정작 암트랙사는 이를 확인해 볼 기회가 없었다. 아셀라 프로젝트가 계속 지연되는 바람에 상용서비스가 개시되지도 않은 상태에서 광고 캠페인만 진행되고 있었던 것이다. 어떤 회사의 신제품 시판을 한달 앞두고 이 제품이 우수한 평가 등급을 받자 마케팅 책임자가 했다는 말이 떠오른다. “대단한 홍보 효과야! 이럴 때 시장에 물건만 풀 수 있었으면 얼마나 좋았을까!”

남성호르몬이 철철 넘치는 게임 업체들은 자사 웹사이트에 “제품 개발이 완료되는 대로” 새로운 게임이 출시될 것이라고 떠들어대기를 좋아한다. 스케줄? 스케줄 같은 건 필요하지 않다. 그들은 폼 나는 게임 개발자들이니까! 하지만, 대부분의 평범한 소프트웨어 업체들에게는 스케줄이 필요하다. 로터스의 경우가 그 좋은 예로, 로터스사가 처음 123 버전 3.0의 개발을 완료했을 때 이 소프트웨어는 그 당시만 해도 아직 보급 대수가 많지 않던 80286 기종의 컴퓨터를 필요로 했다. 로터스는 제품 출시를 16개월이나 미뤘고 그 기간 동안 8086 기종의 메모리 한계인 640K에 맞춰 제품의 용량을 줄였다. 수정된 제품이 완성되었을 때엔 이미 엑셀을 시판중인 마이크로소프트사가 시장에서 16개월 정도 앞서나가고 있었으며, 이 무슨 가혹한 운명의 장난인지, 8086 기종은 이미 시장에서 폐물 취급을 받고 있었다!

이 글을 쓰고 있는 지금도 넷스케이프의 인터넷 브라우저 5.0은 경쟁사에 비해 거의 2년가까이뒤쳐져있다. 개발된 코드를 모두 폐기하고 처음부터 코딩을 다시 시작하는 치명적인 실수를 저질렀기 때문이다. 애시톤-테이트, 로터스, 애플사의 MacOS 등도 똑같은 실수를 저지르는 바람에 소프트웨어 역사의 휴지통(Recycle-bin) 속으로 내던져지는 신세가 되고 말았다. 그 사이 넷스케이프사의 웹 브라우저의 시장점유율은 80%대에서 20%대로 곤두박질쳤지만 이 회사는 아무것도 할 수 없었다. 주력 소프트웨어 제품이 산산조각으로 분해되어 있는 상태에서는 달리 손을 쓸 수 있는 방도가 없었기 때문이다. 단 한번의 잘못된 결정이 넷스케이프를 자폭시킨 핵폭탄이 된 셈이었다. (더 자세한 내용은 Jamie Zawinski의 글 world-famous tantrum을 참조한다).

그래서, 스케줄관리가필요한것이다. 거의 모든 프로그래머들이 하기 싫어하는 일이 바로 스케줄 관리다. 필자의 경험에 따르면, 대다수의 프로그래머들은 어떻게 해서든 스케줄 같은 건 아예 짜지 않고 버텨 보려고 든다. 스케줄을 짜는 극소수의 프로그래머들도 대부분 상사가 하라고 하니까 억지로 하고 있을 뿐, 그 스케줄대로 프로젝트가 진행되리라고 믿는 사람은 그 상사 밖에 없다. 이 상사는 스케줄을 믿는 한편으로, “기한 내에 완료되는 소프트웨어 프로젝트는 없다”고도 믿으며 또, UFO의 존재도 믿는 사람이다.

그렇다면, 왜 아무도 스케줄을 만들려 하지 않을까? 주된 이유는 두 가지다. 첫째는 스케줄을 짜고 관리하는 것이 매우 골치 아픈 일이기 때문이고, 두 번째 이유는 아무도 그것이 그만한 수고의 가치가 있는 일이라고 믿지 않기 때문이다. 스케줄이 지켜지지도 않을 거라면 도대체 왜 그런 수고를 해야 한단 말인가? 스케줄이란 애당초 지켜지는 법이 없고 시간이 지날수록 현실과의 괴리는 점점 더 커지기만 하는데, 뭣 하러 그런 헛수고를 한단 말인가?

여기, 정확하게지켜지는스케줄을만드는간단하고손쉬운방법이있다.

1) 엑셀프로그램을사용하라. MS Project 같은 거창한 프로그램을 사용하려 들지 말라. MS Project는 사용자가 종속성의 문제를 해결하기 위해 많은 시간을 할애할 것이라는 가정하에 만들어진 프로그램이다. 종속성이란, 두 가지 작업을 진행해야 하는 상황에서 하나의 선행 작업이 먼저 완료된 후에만 다음 작업을 시작할 수 있는 경우를 말한다. 소프트웨어 프로젝트의 경우, 작업들간의 종속성은 너무나 당연한 것이기 때문에 굳이 수고스럽게 종속성을 추적할 필요가 없다.

MS Project를 사용하는 경우에 생길 수 있는 또 다른 문제는 이 프로그램을 사용하다 보면 자꾸 스케줄 “균형 조정” 기능을 실행하고 싶어진다는 것이다. 스케줄 균형 조정에는 불가피하게 모든 작업을 재조정하여 다른 사람에게 재할당하는 과정이 포함되는데, 소프트웨어 프로젝트의 경우 이런 재조정은 말이 되지 않는다. 프로그래머들간의 호환이 불가능하기 때문이다. 가령, 리타가 작업한 코드의 버그를 존이 수정하려면 리타 자신이 수정할 때보다 시간이 일곱 배는 더 걸린다. 또, UI 담당 프로그래머에게 WinSock과 관련된 문제를 해결하라고 시키면, WinSock 프로그래밍에 익숙해지는 데에만 일주일은 걸릴 것이다. 결론은