Joel on Software

Joel on Software   조엘 온 소프트웨어

 

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

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

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

 

손쉬운 기능 스펙 작성법 – 제 3부 : 그렇다면, 어떻게 작성할 것인가?


글 : Joel Spolsky
번역 : AhnLab
2000년 10월 4일 수요일

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

스펙은누가작성하는가?

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

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

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

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

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

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

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

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

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

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

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

1. 프로그래머를프로그램관리자로승진시키지마라. 훌륭한 프로그램 관리자에게 필요한 자질 (명확한 문장 전달력, 외교적 수완, 시장 감각, 사용자의 입장에서 생각할 있는 능력 우수한 UI 설계 능력 ) 훌륭한 프로그래머에게 요구되는 자질과는 매우 거리가 있다. 물론, 가지 역할을 모두 소화해낼 있는 사람들도 없지는 않다. 허나, 그런 사람들은 매우 드물다. 훌륭한 프로그래머에 대한 상이랍시고 이들을 C++ 대신 우리말로 프로그램을 저작해야 하는 전혀다른직책으로 승진시키는 것이야말로 피터의 법칙 전형적인 사례라 있다 (피터의 법칙 : 조직 구성원들이 승진을 계속하다 보면 결국 자기 능력 이상의 단계까지 승진해 올라가는 경향이 있다는 주장).

2. 마케팅전공자를프로그램관리자로앉히지마라. 마케팅 전공자들의 기분을 상하게 마음은 없지만, 유능한 마케팅 전문가가 제품을 설계할 있을만한 충분한 기술 지식을 갖추고 있는 경우는 극히 드물다는 사실에는 독자들도 아마 동의할 것이다.

기본적으로, 프로그램 관리는 새로운 독자적 직무 영역이다. 프로그램 관리자는 기술적인 지식에 정통해야 하지만, 그렇다고 유능한 프로그래머가 되어야 필요는 없다프로그램 관리자는 UI 설계하고 고객들과 직접 접촉하며 스펙을작성한다. 이들은 기술적인 것에 대해서는 일자무식 고객들에서부터, 영화 스타 트렉에나 나올법한 옛날옛적 우주복 같은 옷을 걸치고 다니는 프로그래머들과 2,000 달러짜리 명품 정장을 입고 고상한 하는 영업 담당자들까지, 매우 다양한 부류의 사람들은 만나야 한다. 어떤 의미에서 프로그램 관리자는 소프트웨어 팀의 구성원을 하나로 결집시키는 접착제와 같다. 카리스마는 필수적이다.

3. 프로그래머가 프로그램 관리자에게 보고하도록 만들지 마라. 이는 자칫 그냥 지나치기 쉬운 사항이다. 마이크로소프트에서 프로그램 관리자로 일할 당시, 필자는 엑셀용 VBA (Visual Basic) 전략을 설계했고 엑셀에서 VBA 어떻게 구현할 것인가에 대해 가장 세세한 부분까지 빠짐없이 스펙을 작성했다. 필자가 만든 스펙은 500쪽에 달하는 방대한 분량이었다. 엑셀 5.0 개발 작업이 한창일 때는 매일 아침마다 250 정도 되는 사람들이 일을 하러 나왔고 필자가 작성한 스펙을 바탕으로 작업을 했다. 사람들이 워낙 많다 보니 필자로서는 누가 누구인지도 없었지만, 프로젝트와 관련하여 문서화 작업에만 매달리는 사람이 Visual Basic 팀에만도 정도는 됐다 (엑셀 쪽에서 문서화 작업을 진행하는 팀이나 도움말 파일의 하이퍼링크를 책임지는 담당자들은 말할 것도 없고). 그런데, 이상한 것은 프로그램 관리자인 필자가 보고 체계의 있었다는 사실이다. 그랬다. 필자에게 보고하는 사람은 아무도 없었다. 프로그램 관리자인 필자가 사람들에게 뭔가 일을 하게 만들려면, 그들에게 그것이 맞는 일임을 납득시켜야 했다. 수석 프로그래머였던 Ben Waldman 필자가 작성한 스펙 중에서 내키지 않는 부분이 있으면 부분은 코딩을 하지 않았다. , 테스트 담당자들이 필자가 작성한 스펙 중의 특정 부분이 완벽한 테스트가 불가능하다고 불평하면 필자는 부분을 수정해야 했다. 만일 이들 누군가가 필자한테 보고를 하도록 정해져 있었다면, 제품은 만들어질 없었을 것이다. 만일 필자가 보고를 받는 입장이었다면, 프로그래머들이나 테스트 담당자들도 상사가 만든 스펙에 대해 비판하는 것은 부적절한 일이라고 생각했을 지도 모른다. 필자 역시 편하게 자리에 앉은 채로 독단적인 혹은 근시안적인 태도로 필자의 방식대로 작업할 것을 그들에게 명령했을 지도 모른다. 하지만, 당시 실제로는 필자의 입장에서 이들의 합의를 이끌어내는 밖에 달리 도리가 없었다. 이와 같은 의사결정 형태야말로 올바르게 프로젝트를 진행해나가는 가장 좋은 방법이었다.

이 기사는 영어로 Painless Functional Specifications Part 3 라는 이름의 기사가 원본입니다. 

Joel Spolsky는 뉴욕에 위치한 작은 소프트웨어 회사인 Fog Creek Software의 창업자입니다. 예일 대학교를 졸업하고 Microsoft, Viacom, Juno등에서 프로그래머와 매니저로 일했습니다.


이 페이지의 내용은 한사람의 의견을 대변합니다.
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky