[번역] How to be a program manager 진지한척할때

무단번역 from http://www.joelonsoftware.com/items/2009/03/09.html

프로그램 매니저 되기
 조엘 스폴스키

정말 대단한 소프트웨어의 비밀 공식 중 하나는 좋은 프로그램 매니저를 두는 것이다. 그리고, 당신네 팀에는 아마도 좋은 프로그램 매니저가 없을 것이다. 대부분의 팀에는 좋은 프로그램 매니저가 없다.

찰스 시모니는 뛰어난 프로그래머로 위지윅 워드 프로세싱을 공동으로 발명했고, 마사 스튜어드1)와 데이트했고, 마이크로 소프트 주식으로 수억달러를 벌어 우주여행을 했다. 그리고 처음으로 굉장히 커다란 소프트웨어 팀을 어떻게 조직하느냐에 대한 인월미신2) 문제에 대한 해법을 제시했다. 해법은 한 명의 초고수 프로그래머가 상위레벨에서 함수를 만들고, 하위 레벨 함수의 구현은 필요한 만큼의 쫄병 중급 개발자들에게 맡기는 것이다. 당시 이자리를 "프로그램 매니저"라고 불렀다. 시모니는 뛰었났지만, 이 아이디어는 그만큼 뛰어나지 않았다. 아무도 쫄병 중급 개발자가 되려하지 않았기 때문이라고 생각한다.

제이브 블루멘탈(Jabe Blumenthal)은 80년대 매킨토시 엑셀 팀의 프로그래머였다. 그는 "프로그램 매니저"직을 리사이클하여 전혀 다른 일을하는 자리로 바꾸었다. 블루멘탈은 이미 소프트웨어 개발이 너무 복잡해져서, 어떤 프로그래머도 어떻게 쓸모있고, 쓸 수 있는 소프트웨어를 만들지를 고민할 겨를이 없다는 걸 알고 있었다. 마케팅 팀은 고객의 요구에 대해 불평을 해댔고, 그들의 MBA語를 실제의 기능으로 번역할 줄 아는 사람도 없었고, 그들과 이야기 하지도 않았다. 제품 디자인에는 많은 다양한 작업이 들어간다. 사용자와 이야기하고, 사용성 테스트를 돌리고, 경쟁사 제품을 리뷰하고, 어떻게 더 쉽게 만들까를 고민하고... 그러나, 대부분의 프로그래머가 이 모든 걸 하기엔 시간이 부족하다. (프로그래머가 이걸 잘 할 수 있는지는 차치하고 말이다.) 블루멘탈은 "프로그램 매니저"로서, 이 직위가 하는 일을 완전히 재발명해냈다.

프로그램 매니저가 뭘 하는가?

그러니까, 프로그램 매니저는 아마:
 1. UI 디자인
 2. 기능성 스펙 작성
 3. 팀 조직
 4. 고객 편에서 생각
 5. 바나나 리퍼블릭표 바지 착용
같은 일을 할 것이다.

작은 제품에서는 아마 한 명의 프로그램 매니저로 족하겠지만, 대형 제품에서는 프로그램 매니저가 여러 명 있을 것이다.
각 프로그램 매니저는 특정한 기능집합을 책임진다. 괜찮은 어림법칙은 프로그래머 네 명에 한 명 꼴로 프로그램 매니저를 두는 것이다. 기능을 나누는 게 힘들다면, 내가 마이크 콩테(Mike Conte)로 부터 배운 것처럼 사용자 행위별로 제품의 기능을 나누는 것이다. 예를 들면, 트위터는 다음 네가지 행위로 나눌 수 있다.

 1. 사용자 등록 및 익히기
 2. 메시지 포스팅 몇 댓글 읽기
 3. 계정 설정
 4. 뉴스 검색

마이크로소프트에서 내가 처음 맡은 프로그램 매니지먼트는 엑셀의 스크립트와 매크로를 다루는 "고객맞춤"(customization)이라 불리는 사용자 행위와 관련된 것이었다. 내가 처음으로 해야 했던 일은 고객이 원하는 게 뭔지를 알아내는 것이었고, 난 될 수 있는 한 많은 고객을 찾아 이야기하면서 이 일을 했다. 결국 난 계속 똑같은 이야기를 들어 지겨워질 지경이 됐다. 18개월의 릴리즈 기한에 가능한 합리적인 것이 무엇인지를 개발팀과 오랜 시간 토의했고, 또 비주얼 베이직 컴파일러, 편집기, 다이얼로그박스 에디터를 엑셀 매크로에서 쓸 수 있는지를 비주얼 베이직 팀과 다시 오랜시간 토의했다. 뿐만 아니라, 애플스크립트라는 자기들의 유니버설 매크로 언어를 개발하고 있던 애플과도, 엑셀이 한 것을 따라했던 워드, 액세스, 프로젝트, 메일 등의 마이크로소프트 내의 다른 개발팀과도 토의해야 했다. 회의, 이메일, 전화. 이 때의 경험 때문에 난 아직도 내 사무실의 전화가 울리면 공포에 빠지곤 한다.

두번째 단계는 비전 스테이트먼트를 작성하는 것이었다. 비전 스테이트먼트는 비주얼 베이직이 엑셀에서 이렇게 동작한다, 매크로 예제는 이렇게 생겼다, 우리가 만드는 큰 덩어리는 이런 것이다, 고객의 문제는 이렇게 풀 것이다 등등이 적힌 대략적인 문서이다. 반대가 많지 않으면, 난 좀 더 세부적인 스펙을 써 나갔으며, 이 세부사항들은 세세한 것들까지 사용자에게 어떻게 보여져야 하는지를 설명했다.

이것이 기술 스펙과는 다른 기능성 스펙(functional spec)이며, 기능성 스펙은 사용자에게 어떻게 보이는지만을 말하며, 어떻게 구현하는지는 말하지 않는다. (url) 프로그램 매니저는 개발팀이 내부적으로 어떻게 구현하는지에 대해서는 상관하지 않는다. 내가 개발팀장인 벤 월드먼(Ben Waldman)에게 스펙을 보내면, 벤은 그의 팀과 함께 앉아 내부적으로 어떻게 해야 그게 가능한 지를 알아냈다. 그들은 내가 정의한 객체지향 인터페이스를 엑셀 내부함수로 연결시키는 멋지고 깔끔한 테이블을 생각해 냈다. 하지만, 그건 실은 내가 상관할 것은 아니다. 난 엑셀 내부에 대해서도, 어떻게 구현되는지도 잘 몰랐다.

사실을 고백하자면, 난 아무것도 몰랐다. 대학을 갓 졸업한 나는 코딩도, 테스트도, 문서화도, 제품영업도, 사용성 테스트도 몰랐다. 다행히도 마이크로소프트에는 이 각 분야에 상당히 숙련된 도사들이 있었고, 이들이 내가 지금 아는 모든 것을 가르쳐 주었다. 멋진 제품을 진짜 만들어 낸 건 그들이었다. 예를 들면, 난 사용자들이 스프레드시트 셀의 값을 변수로 복사하고 싶어한다는 걸 알고 있었다.

 X = [A1]

이 식이 동작해야 했다. 문제는 셀이 숫자나, 문자열을 담을 수 있었다는 것, 그리고, 베이직 변수는 형이 미리 결정된다는 것이다. 즉, DIM x as Integer 또는 Float 또는 String 이라고 정수, 부동소수점, 문자열 변수를 먼저 정의하고 나서 변수를 사용할 수 있다는 것이다.

베이직이 동적 타이핑이 되야 했다. 그러나 난 그 방법을 알아낼 만큼 똑똑하지 않았다. 그렇지만, 비주얼 베이직 팀의 탐 코버트(Tom Corbett)는 어떻게 할 지를 알아냈다. 그래서 Variants와 IDispatch가 탄생했고, 베이직은 "덕 타이핑(duck typing)"으로 불리는 동적 언어가 됐다. 요점은, 내 일은 문제를 푸는 게 아니라  고객이 원하는 걸 알아내고, 프로그래머가 이 문제를 푸는 지 확인하는 것이었다.

스펙작업이 끝나면 개발팀은 일에 착수하고, 나에겐 두가지 책무가 남아있다. 그 두가지는, 디자인에 대한 의문을 풀어주는 것, 개발자들이 몰두할 수 있도록 다른 팀들과의 커뮤니케이션에 임하는 것. 난 테스터를 만나 뭐가 어떻게 돌아가는 것이 정상인지를 설명했고, 어떻게 모든 것을 테스트할 지 계획하는 걸 도왔다. 문서화 팀과는 좋은 엑셀 베이직 튜토리얼과 레퍼런스를 쓰는 걸 도왔다. 난 지역화 전문과들과 만나선 지역화 전략을 고민했다. 영업팀과는 마주앉아 VBA의 영업적 잇점에 대해 설명했다. 사용성 전문가와는 사용성 테스트를 세우는 데 함께했다.

프로그램 매니저는 많은 회의에 참여하지만, 실제 생산하는 것은 스펙문서가 고작이다. 그래서 학교를 갓 졸업한 내가 그 일을 할 수 있었던 것이다. 프로그램 매니저가 14년차 베테랑 프로그래머일 필요는 없다. (사실 14년동안 프로그래밍을 하면, 사용자 편이 되기에는 너무 많은 걸 알고 있게 된다.)

충돌

프로그램 매니저가 없으면, 다재다능하고 천재적인 프로그래머가 완전히 황당한 사용자 인터페이스를 만들어 낼 수 있다. 최고의 프로그래머는 지나치게 똑똑해서, 16개의 한글자 짜리 명령인자를 다 기억하지 못할 수 있다는 걸 자주 까먹는다. 이런 프로그래머는 자기가 처음 생각해 낸 아이디어를 고집하는 경향이 있다. 이미 코드를 다 짰을 때는 더욱 그렇다.

프로그램 매니저가 소프트웨어 디자인 과정에서 하는 가장 멋진 일 하나는 디자인에 대한 제2의 의견을 제시하는 것이다. 이 의견은, 바라건데, 맨 페이지를 읽지 않아도, 스스로 원하는 기능을 위한 이맥스 리습함수를 짜지 않아도, 머릿속에서 8진수를 계산하지 못해도(주) 응용 프로그램을 사용할 수 있기를 바라는 나약한 생각을 가진 그 "덜떨어진 사용자들"에 동정하는 입장이라면 좋다.

좋은 프로그램 매니저는 UI가 어떻게 동작해야 좋을지에 대한 자기만의 아이디어를 갖고 있을 수 있다. 이 아이디어는 개발자의 아이디어보다 좋은 것이거나, 나쁜 것일테다. 어쨌든 그래서 길고긴 토론이 있게 된다. 보통은 프로그램 매니저는 사용자들이 이해하기 좋은 간단한 걸 원한다. 텔레파시로 조작하는 인터페이스, 30인치짜리 주머니에 들어가는 스크린같은 것이다. 반면 개발자는 코드로 구현하기 간단한 걸 원한다. 명령행 인터페이스 ("그게 뭐가 그리 어렵단 말인가?")이나 파이썬 바인딩 같은 것이다.

엑셀 5 프로젝트에서 내가 기억하는 가장 기념비적인 토론은 스프레드시트 그림 영역 위를 떠다니는 피벗테이블을 원했던 개발자와, 피벗 테이블이 스프레드시트 셀 안에 들어가야 한다고 우겼던 프로그램 매니저사이의 토론이었다. 이 토론은 정말정말 오랜 기간을 끌었고, 결국엔 프로그램 매니저의 의견이 우세하게 됐다. 그렇지만, 최종 디자인은 어느 누구 한 사람이 디자인해서 만들 수 있는 것 보다 훨씬 훨씬 좋았다.

토론이 서로 존중하면서, 사실에 기반한 이성적 토대에서 이루어지도록 하려면, 프로그램 매니저와 개발자가 피어(peer, 동등한 위치의 동료)여야 한다는 것이 절대적으로 중요하다. 개발자가 프로그램 매니저에게 보고한다면, 토론 중 어느 시점엔가 지쳐버린 프로그램 매니저는 모두 귀찮아져서, "좋아, 말은 충분히 들었어. 다들 내가 하자는대로 해."라고 할 수 있다. 이들이 동등한 피어라면, 이런 일은 결코 일어날 수 없다. 마치 법정과도 좀 비슷하다. 법정에선 한 쪽편 변호사가 판결을 내리도록 하지 않는다. 대신 평등한 양쪽 간의 토론 과정을 통해 진실이 드러날 가능성이 가장 높다는 이론에 따라 행동한다. 토론은 어느 한 편에게도 부당한 특권이 없을 때에만 공정할 수 있다.

이것은 중요한 점이다. 만약 중학생인 샐리를 상상하고 있다면, 샐리가 어딨는지 궁금해 한다면, 그 생각을 치워버려라. 샐리는 스콧데일의 생치료사이고, 공화당원이다. 이제 집중하라. 프로그래머는 프로그램 매니저에게 보고할 수 없다. 무슨 말이냐면, 개발팀장이나, CTO, 아니, CEO라도 그가 스펙을 결정하는 사람일 수 없다.

많은 회사가 저지르는 가장 큰 실수는 스펙을 작성하고, 제품을 디자인하는 프로그래머들의 관리자를 두는 것이다. 이건 디자인에 공평한 심사를 받지 못하기 때문에, 그리고, 디자인이 의견충돌과 토론을 거쳐 나오지 않기 때문에, 그래서, 될 수 있는 가장 좋은 디자인이 되지 못하기 때문에 실수이다.

난 이 교훈을 어렵게 배웠다. 포그 크릭 소프트웨어에서, 난 스스로 많은 프로그램 매니지먼트를 했다. 사람들은 내가 틀린 말을 했을 때, 나와 논쟁을 해야만 한다. 프로그램 매니저먼트는 그 사실을 사람들에게 계속 인지시키는 일이었다. 우리 회사는 큰 회사가 아니었지만, 결국엔 진짜 프로그램 매니저, 댄과 제이슨을 둘만큼 커졌다. 그리고, 우리 프로그래머들은 그들과 논쟁하길 매우 좋아한다.

물론, 프로그래머들이 프로그램 매니저의 피어이지만, 프로그래머는 유리한 위치에 있다. 종종 일어나는 데, 이런 일이 있다. 프로그래머가 나에게 와서 프로그램 매니저와의 토론을 중재해 주길 요청한다.

"누가 코드를 작성하지?" 내 질문이다.

"저죠."

"좋아. 소스컨트롤에 체크인하는 건 누구지?"

"아마, 날껄요."

"그럼, 뭐가 문제지? 정확히?" "최종 제품까지 비트 하나하나까지 모든 것들을 제어하는 게 너잖아. 뭐가 더 필요하니? 왕관?"

이제 알겠지만, 이 시스템에선 프로그램 매니저가 프로그래머 설득이라는 짐을 지고 있다. 왜냐하면, 프로그램 매니저가 잘못하면, 프로그래머는 포기하고, 그냥 자기들이 내키는 대로 해버릴 것이기 때문이다. 그래서, 프로그램 매니저로 유능하려면, 그 사람은 먼저 (a) 옳아야 하고, 더불어 (b) 매니저가 옳다고 프로그래머가 동의할 만큼 그들의 존중을 얻을 수 있어야 한다.

그럼 어떻게 존중을 얻을 수 있나?

프로그램 매니저로서, 자신이 코딩에 능숙하다면 그것은 도움이 된다. 좀 불공평하긴 하다. 프로그램 매니저는 코드를 작성하는 일이 아니지 않은가? 그러나, 프로그래머는 프로그래머를 비프로그래머보다 훨씬 존중하는 경향이 있다. 얼마나 똑똑한 지는 상관없이 말이다. 코딩을 못하고도 유능한 프로그램 매니저가 될 수는 있다. 그러나, 프로그래머들의 존중 획득이라는 부담이 훨씬 클 것이다.

프로그래밍 팀의 존중을 얻는 다른 방법은, 야기되는 모든 토론에서 자신의 지성, 열린마음, 공평성을 보여주는 것이다. 프로그램 매니저가 엉뚱한 말을 한다면, 프로그래머는 그 사람을 가지고 놀 것이다. 프로그램 매니저가 인신공격을 하거나, 감정적이 되거나, 비이성적이 될 때까지 자신이 하고자 하는 걸 고집하거나 하면, 그는 신뢰를 잃을 것이다. 양쪽 모두 그렇겠지만, 특히 프로그램 매니저는 토론에서 감정적으로 떨어져 있어야 하고, 새로운 증거를 고려할 준비가 되어 있어야 하고, 사실에 따라서 자기 의견을 바꿀 수 있어야 한다. 마지막으로, 만약 프로그램 매니저가 사장과 따로 만나거나, 이간질을 통해 토론을 이기려 하는 등 정치놀음을 하는 것으로 보여지면, 그들은 프로그래머로부터 신뢰를 크게 잃을 것이다.

프로그램 매니저가 개발팀의 신뢰를 잃게 되면, 그건 끝이다. 개발팀은 효율적으로 움직이지 않을 것이다. 프로그래머는 자기 멋대로 자기가 원하는 걸 할 것이다. 이렇게 되면 코드는 나빠지고, 시간은 낭비된다. 당신은 무능한 프로그램 매니저에게 봉급을 주고 있을 뿐 아니라, 무능한 프로그램 매니저가 회의를 소집해서, 다른 사람의 시간을 뺐고, 코드는 전혀 좋아지지 않기 때문이다.

스펙? 정말로? 그건 애자일 하지 않은데.

스펙이라구? 그건 애자일 하지 않잖아!

많은 개발조직에서 스펙은 의미없는 관료적인 문서조각에 지나지 않았기에, 스펙을 작성하지 말자는 움직임이 조직적으로 일어나기시작했다. 이런 움직임은 잘못된 것이다. 기능성 스펙을 작성하는 것은 애자일 개발방법의 가장 핵심이다. 왜냐하면, 기능성 스펙은 실제 코드를 작성하기 전에 많은 디자인 가능성을 거쳐서 점검하게 해 준다. 코드에 비하면, 스펙문서를 변경하는 건 아주 간단하다. 스펙문서를 써봄으로 인해서, 머릿속에 들어 있다고 생각하는 디자인을 훑을 수 있고, 따라서 그 안의 오류를 빨리 발견해서 디자인을 조금씩 변경하고 더 많은 디자인을 시도할 수 있는 것이다. 기능성 스펙을 사용하는 팀은 더 나은 디자인의 제품을 만들어낸다. 빨리빨리 더 많은 가능성을 탐구하는 기회를 갖기 때문이다. 또 이들은 코드도 더 빨리 짠다. 왜냐면, 시작할 때 벌써 뭐가 필요한지에 대한 명확한 청사진을 갖고 있기 때문이다. 기능성 스펙은 너무 중요해서, 포그 크릭에는 드문 변치않는 법칙 중 하나가, "스펙없이 코드없다"이다.

기능성 스펙의 정확한 양식은 딱 정해져 있지 않다. 기능성 스펙이 해야 하는 것은 프로그램이 어떻게 동작할 지를 설명하는 것이다. 내부적으로 코드가 어떻게 돌지에 대해선 아무런 언급도 하지 않는다. 가장 윗 레벨에서 시작한다. 한 장을 넘지 않는, 새로운 기능의 핵심만을 설명하는 비전 스테이트먼트가 그것이다. 이것이 확정되면, 스토리보드를 개발한다. 사용자가 으용프로그램을 진행할 때의 스크린에 어떻게 도는지를 설명하는 메모가 곁들여진 가상화면이다. 많은 유형의 기능성 정의에선, 특별히 UI가 많은 기능성 정의에서는, 스토리보드로 끝이다. 이게 스펙이다. 제이슨 프라이드, 이제 가도 좋다. (link)

더 복잡한 유형의 기능성 정의에는 UI 스토리보드에는 드러나지 않는 숨겨진 동작이 있고, 더 많은 세부사항을 적어야 한다. 그러나, 모든 경우에서 스펙을 적어 나가는 것이 문제점, 의견충돌, 디자인 이슈를 코드를 쓰기 전에 발견해 내는 데 도움이 된다. 그렇게 하면, 코딩을 할 때 예상치 못했던 문제가 튀어나와 코드를 다시 만들거나, 최적화 되지 않은 디자인을 얻어야 하는 확률이 적어진다.

프로그램 매니저가 되는 법을 어떻게 배울까?

대게는, 프로그램 매니저가 된다는 건 배움과 관련되어 있다. 기술을 배우고, 인간과계를 배우고, 정치적인 조직에서 어떻게 효율을 내는지를 배운다. 좋은 프로그램 매니저는 엔지니어가 기술을 디자인 하는 접근법과 정치가가 합의를 끌어내고, 사람을 모으는 능력을 조화시켜야 한다. 이런 걸 배우는 한 편으로, 읽어야 할 몇 권의 책도 있다:

내가 아는 한, 스콭 버쿤(Scott Berkun)의 <Making Thing Happen>이 프로그램 매니저의 임무를 대부분 다루는 유일한 책이다. 이 책부터 읽어봐라. 스콭은 수년간 인터넷 익스플로러 팀의 프로그램 매니저였다.

프로그램 매니저의 일 중 또 한가지는 사용자 인터페이스 디자인이다. 스티브 크룩의 <Don't Make Me Think>와 내가 쓴 <User Interface Design for Programmers>를 읽으라.

마지막으로, 좀 지겹게 들리것 같지만, 데일 카네기의 1937년 저작 <How to Win Friends & Influence People>은 정말 인간관계 기술에 대한 멋진 소개서이다. 난 포그 크릭의 관리자 과정 직원에게 다른 어떤 책보다도 이 책을 먼저 읽도록 한다. 매번 이 책을 읽으라고 권할 때는 비웃지만, 읽어본 후에는 좋아하게 된다.

---
조엘 스폴스키 블로그의 글을 무단으로 1차 번역했고, 퇴고는 1/3 정도만 한번 했습니다. 뽑아놓고 한글만 보고 고쳐보니 한국어가 훨씬 좋아지더군요. 나머지 2/3은 영문에서 바로바로, 좀 급하게 한 것이라서 매끄럽지 못한 부분이 있을 수 있네요. 또, 제 지식이 부족하여 오역을 했을 가능성도 있습니다. 만, 전 현역 프로그래머이고, 이런 부분이 관심이 좀 있어서, 기술분야의 아주 엉뚱한 오역은 없을 것입니다. 조엘 스폴스키에게 허락을 받지 않은 번역입니다.

이상한 부분은 가차없이 댓글로 지적해 주시기 바랍니다.

덧글

  • C2S 2010/02/03 11:35 # 삭제

    정말 공감가는 글이군요.
    좋은 글을 무리없이 읽게 해주셔서 감사드립니다.
  • daewonyoon 2010/02/03 11:56 #

    저를 위해 번역해 본 것인데, 누군가에게 도움이 된다니 기쁘군요. 생각난김에 퇴고 한 번 더 해봐야겠습니다.
※ 이 포스트는 더 이상 덧글을 남길 수 없습니다.



잇기고리

이글루스 백기운동