Joel on Software   조엘 온 소프트웨어

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

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

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

앞에서 왜 스펙이 필요한가와 스펙이란 무엇인가에 대한 이야기를 마쳤으니 지금부터는 그렇다면 누가 스펙을 작성해야 할 것인가에 대해 이야기해 보도록 하자.

스펙은누가작성하는가?

마이크로소프트사의 이야기를 잠깐 해보자. 마이크로소프트가 본격적인 성장세에 접어들던 1980년대, 이 회사의 모든 엔지니어들은 소프트웨어 프로젝트 관리 분야의 필독서인 The Mythical Man-Month를 읽었다. (아직 이 책을 읽어보지 않았다면, 꼭 한번 읽어 보시라.) 이 책의 요지는 프로젝트 기간을 단축하기 위해 프로그래머를 더 투입하면 오히려 프로젝트가 더 지연된다는 것이었다. n명의 프로그래머로 구성된 개발팀의 내부 의사소통 경로는 n(n-1)/2개가 되고 그 수는 O(n²)의 비율로 증가하기 때문이다.

때문에, 그 당시 마이크로소프트사의 프로그래머들은 인원을 늘려봐야 프로젝트 기간만 더 길어진다는 당대의 지배적인 명제 앞에서 대규모의 프로그램을 어떻게 개발해야 할 것인지를 두고 고심했다.

마이크로소프트에서 장기간 “개발 책임자”의 자리를 지켰던 Charles Simonyi는 주인프로그래머 라는 개념을 제안했다. 기본적인 아이디어는 한 사람의 ‘주인’ 프로그래머가 모든 코딩을 책임지되, 그 밑에 “코드 담당 하인”의 역할을 수행할 하급 프로그래머를 한 팀씩 두자는 것이었다. 주인 프로그래머는 모든 기능에 대한 디버깅을 일일이 신경 쓸 필요 없이, 원칙적으로 각 기능에 대한 원형(프로토타입)을 만들어 아웃라인을 정한 후에 이것을 하급 프로그래머들에게 던져주고 각각을 그대로 코딩하도록 지시하는 것이다. (물론, Simonyi는 주인 중의 주인 프로그래머가 되었을 것이다.) “주인”이니 “하인”이니 하는 용어들이 다소 봉건적이라 하여 마이크로소프트에서는 “주인 프로그래머” 대신 “프로그램 관리자”라는 말을 사용하기로 했다.

이론적으로는, 이 같은 접근방식을 통해 Man-Month 증가의 문제를 해결할 수 있다. 모든 하급 프로그래머들은 오로지 한 사람의 프로그램 관리자하고만 이야기하면 되니까 내부 의사소통 경로는 O(n²)이 아닌 O(n)의 비율로 증가하기 때문이다.

하지만, Simonyi가 헝가리식 표기법에 대해서는 잘 알고 있었는지 몰라도, 그는 피플웨어(Peopleware)에 대해서는 모르고 있었다. 즉, 아무도 코딩 담당 하인이 되고 싶어하지는 않는다는 사실을 간과했던 것이다. 그의 아이디어는 전혀 먹혀 들지 않았다. 결국, 마이크로소프트사는 Mythical Man-Month 이론에도 불구하고, 유능한 프로그래머들로 증원하면 산출이 늘어난다는 사실을 발견하게 되었다. 비록, 한계 생산성은 체감하더라도. 필자가 엑셀 팀에서 일할 당시 팀원이 50명이었는데, 우리 팀은 25명의 프로그래머로 구성된 팀보다는 생산성이 높았다. 생산성이 그 2배가 되지는 못했지만.

주인/하인 프로그래머의 아이디어는 신뢰를 얻지 못했지만, 마이크로소프트사는 여전히 프로그램 관리자라는 직책을 유지하고 있었다. 그러던 중 Jabe Blumenthal이라는 지혜로운 사람이 나타나 프로그램 관리자의 역할을 근본적으로 재정립했다. 이때부터, 프로그램 관리자는 제품에 대한 설계와 스펙을 책임지게 되었다.

그 후로 지금까지, 마이크로소프트에서는 프로그램 관리자들이 요구사항을 취합하고 코딩의 기본 방향을 설정하며 스펙을작성한다. 대개 한 명의 프로그램 관리자에게는 5명의 프로그래머가 배속되어 있고 이들 프로그래머들은 프로그램 관리자가 스펙의 형태로 제시한 것을 코딩을 통해 구현할 책임이 있다. 또, 프로그램 관리자는 마케팅, 문서와, 테스트, 현지화 및 기타, 프로그래머들이 신경 쓸 수 없는 세세한 사항들을 모두 조정해야 한다. 마지막으로, 마이크로소프트의 프로그램 관리자들은 프로그래머들이 정확한 코딩에만 전념하는 동안 회사의 “큰 그림”을 염두에 두고 프로젝트를 진행해야 한다.

프로그램 관리자 제도는 매우 유용하다. 프로그래머들이 상품성보다는 기술적 정밀성에만 신경을 쓰는 것이 불만이라면 프로그램 관리자 제도를 도입해 보라. 어째서 코드는 잘 쓸 수 있는 사람들이 우리말을 쓰는 솜씨는 신통치 못한 지가 불만이라면 프로그램 관리자 제도를 도입해 보라. 제품이 명확한 방향 없이 떠돌고 있는 것처럼 보인다면 프로그램 관리자 제도를 도입해 보라.

프로그램관리자는어떻게뽑나?

대부분의 회사들은 아직 프로그램 관리자라는 개념 자체가 없다. 필자로서는 퍽 유감스러운 일이다. 필자가 마이크로소프트에서 일할 당시, 유능한 프로그램 관리자가 이끄는 팀은 엑셀, 윈도우 95, 액세스 같은 성공적인 제품들을 만들어냈다. 반대로, MSN 1.0이나 윈도우 NT 1.0 같은 제품을 개발한 팀들은 대체로 개발자들이 프로그램 관리자를 무시하는 경우가 많았다 (이들 프로그램 관리자들은 실력이 없었고 무시당할 만한 사람들이었다).

프로그램 관리자를 선정할 때는 다음과 같은 세 가지 사항에 유의해야 한다.

1. 프로그래머를프로그램관리자로승진시키지마라. 훌륭한 프로그램 관리자에게 필요한 자질 (명확한 문장 전달력, 외교적 수완, 시장 감각, 사용자의 입장에서 생각할 수 있는 능력 및 우수한 UI 설계 능력 등)은