[10호]개발자 출신 신출내기 사장의 프로젝트 관리 표류기
개발자 출신 신출내기 사장의
프로젝트 관리 표류기
글 : 위드로봇(주) 김도윤 대표
글을 쓰게 된 계기
제가 일하고 있는 위드로봇(주)가 서초동에서 성수동으로 확장 이전한 것을 기념하여 디바이스마트 고객을 대상으로 무료 공개 강좌를 진행한 적이 있습니다. 이 강좌 내용을 디바이스마트 매거진에 지면으로 옮기며 독자 분들과 만난 지 일년이 되어 갑니다.
2011년 12월에는 3축 가속도 센서와 2축 자이로 센서로 구성된 myARS-USB 제품 개발에 관한 개발 과정을 소개하는 원고를 청탁 받고 고민하던 끝에 특정 제품 개발에 관한 이야기보다는 좀 더 일반적인 개발 과정의 이야기로 편하게 독자 분들에게 소개하고, 여러분들은 어떻게 생각하시는지 묻고 싶어졌습니다. WITHROBOT Lab.이라는 조그마한 연구소를 만든 지 이제 3년이 지났고 그간 크고 작은 대기업 연구소, 정부 출연 연구소, 대학 연구실로부터 수주 받아 진행한 과제가 60건 가까이 되기에 다양한 경험을 할 수 있었습니다.
오늘 풀어놓는 이야기는 60여건의 과제를 거쳐온 조그마한 회사의 개발자이자 오너가 겪은 좌충우돌 경험기로 봐주시면 고맙겠습니다.
행복한 개발자는 모순어법인가?
가끔은 고객의 요구를 잘 파악하여 문제없이 술술 진행된 과제도 있었습니다만, 대부분의 과제가 진행 중에 예상하지 못한 어려움 때문에 때론 고통스럽고, 때론 짜증이 나는 경우가 많았습니다. 사실대로 고백하자면 대부분의 과제가 후자쪽이었습니다. 애초 연구소를 처음 만들 때 목표가 “행복한 개발자들의 놀이터”였기에 힘든 상황에 맞닥뜨리게 되면 많은 갈등을 하게 됩니다. 과연 “행복한 개발자”라는 말은 모순어법인 것인지, 개발이라는 과정 그 자체는 결코 행복해 질수는 없는 것인지, 뭐가 근본적인 문제인지… 신문지상과 같은 곳에서 성공 사례를 언급하는 개발자들의 개발후기를 보면 몇 일 몇 달을 밤새고 새벽 별을 보며 퇴근을 한다던 지, 접이식 침대는 연구소의 필수품이요, 커피와 각종 각성제가 들어간 음료수는 무한 공급을 해야 한다는 이야기들을 접하곤 합니다.
이제는 조금은 진부한 표현입니다만 월화수목금금금으로 일하는 개발 과정을 자랑스럽게 이야기하는 기사를 읽다보면 마음 한켠이 어두워집니다. 개발은 정시 퇴근하고, 주말이면 여행도 가고, 영화도 보고, 때론 평일에 조금씩 쉬어가면서 할 수 있는 일은 아닌가요? 고행에 가까운 고통을 감내해야지만 쓸만한 제품이 나오는 것일까요? 진부할 수도 있지만 전형적인 이 땅의 엔지니어라고 생각되는 모습을 한 번 그려보겠습니다.
회사에 입사하여 개발팀 중 한 팀에 들어가 회사에서 부여하는 업무를 진행하게 됩니다. 소위 프로젝트라는 이름을 붙이고 과제 전체를 담당하는 PM(Project Manager)와 잦은 회의를 통해 무엇을 해야 하는지, 언제까지 해야 하는지 업무를 할당 받습니다.
처음에는 잘 해 낼 수 있을 것이라 생각했지만 혼자서 일을 하던 학생 때와는 사뭇 다르게 매우 비효율적으로 일을 진행하는 자신의 모습에 놀라곤 합니다. 회로를 설계하는 경우라면 커넥터 하나를 선정하더라도 여러 사람에게 문의해 봐야 하죠. 바로 한 자리에 모일 수 있는 경우라면 쉽게 결정이 되겠습니다만, 대부분의 경우가 그렇지는 못하죠. 이 경우 메일로 문의하는데 답신이 오는데 하루 이상 걸리곤 합니다. 제 경험상 하루 만에 답신이 와서 결정이 된다면 상대적으로 매우 효율적인 과제에 속합니다. 혼자서 한다면 10분안에 끝났을 커넥터 선정이 하루가 지나도 결정이 안 되는 경우가 있죠. 아, 핸드폰이 있다구요? 좋습니다. 어떤 상의할 상황이 생길 때마다 핸드폰으로 해당 결정자에게 묻는다고 합시다. 개발자마다 다르겠습니다만 제 경우는 어떤 일을 하고 있을 때 핸드폰 전화를 받으면 바로 집중이 깨져버립니다. 3분 정도 통화로 상대방은 뭔가 문제가 해결되었을지 모르겠지만 다시 원래 하던 일에 몰입하기 위해서는 최소 20~30분은 소요되곤 합니다. 문제는 이런 전화가 시도 때도 없이 걸려오면 하루 종일 통화만 하다가 정작 해야 하는 가장 중요한 일은 별 진도가 나가지 않는 경우가 있다는 점입니다.
고객 중 이런 분이 있으셨는데, 시시콜콜한 사항부터 매우 오랜 시간 동안 논의해야 하는 문제까지 핸드폰 통화로 해결했기에 하루에 스무 번 이상 통화를 한 적도 있고 어떨 때는 두 시간 이상 통화를 한 적도 있습니다. 문제는 그 수 많은 통화를 통해 뭔가 결정된 사항들이 시간이 지나면 서로 잊고 있거나 구두로 전달하는데 실수가 들어가 서로가 당연히 알고 있을 것이라 생각했던 부분에 심각한 오류가 있곤 했었습니다. 어쨌건 핸드폰 또는 메일을 통해 커넥터를 결정했다손 치더라도 진행 중에 전혀 엉뚱한 이유로 초기의 결정사항들이 뒤집히곤 합니다. 그러면 설계 변경이 발생하겠죠. 문제는 항상 모든 일에는 마감 기일이 있기에 이러한 설계 변경은 절대 달가울 수가 없습니다.
처음에는 나름 여유 있는 일정이라 생각했지만 전체 일정의 50%쯤 지났을 때는 대부분의 항목들이 지연되고 있음을 발견합니다. 회로 설계는 진작 끝나 PCB가 만들어지고 있어야 하는데, 아직도 부품 선정도 안되어 있습니다. 테스트 코드는 뭔가 작성해서 잔뜩 테스트는 하고 있는 것 같은데, 정작 타겟 보드에서는 아직 테스트를 못 해 봤기에 어떤 문제가 발생할지는 아직 아무도 모르는 상황입니다. 슬슬 일정에 대한 압박감을 느끼기 시작하며 야근을 하며 개발의 속도를 내려고 하지만 갑자기 개발 속도가 빨라질 리는 만무합니다. 그러다 보니 면밀히 검토하지 못한 채 일단 진행하는 회로와 코드들이 늘어나죠. 컴파일해서 일단 간단한 테스트 케이스를 통과하면 면밀한 검토는 우선 제쳐두고 그 다음 단계로 진행합니다. 회로 설계도쪽은 분초를 다투며 쪼임을 당하고, 결국은 의심적은 부분이 있지만 PCB제작에 착수합니다. 코드쪽도 점점 복잡해지고 있고, 어디선가 문제가 조금씩 터져 나오지만 어떻게든 대충 디버깅이 되면 계속 진도를 뽑습니다.
결정적인 문제는 항상 과제 마감 한 달 전쯤 터집니다. 설계한 보드는 우스꽝스런 결정적인 실수가 있어 애초 목표했던 기능을 100% 구현 할 수 없습니다. 코드는 사용자의 편의성이나 심미안적인 아름다움은 저 멀리 안드로메다로 사라진 지 오래고, 그저 개발자 관점에서 디버깅하기 편한 구조와 형태로 짜여져 있을 뿐입니다. 그럼에도 불구하고 개발자는 “일단 기능을 하는 것이 중요하다”라고 항변하며 일정을 늘리는 요구에는 짜증부터 내기 시작합니다.
결국 애초에 생각했던 마감일 일주일 전에 전체 미팅을 통해 일정은 변경되고 목표 스펙 또한 변경되곤 합니다. 상황에 따라서는 새로운 맴버가 투입되기도 합니다. 일정이 늘어났으니 비용은 초기 계획보다 늘어나는 것을 피할 수 없겠죠. 지금부터는 요일도 없고 퇴근 시간도 없는 죽음의 행진이 시작됩니다. 이렇게 해서 애초 계획보다 최소 30% 이상, 심지어는 두 배 이상 지연된 시점에서 과제가 종료됩니다. 놀라운 사실은 이러한 진행 패턴이 과제비가 수 백만원짜리든 수 백억짜리든, 두 세명이 투입된 과제건 수 십 명이 투입된 과제건 대동소이 하다는 점입니다. 이는 극복할 수 없는 과제의 특성일까요?
프로젝트의 정의
앞서 소개한 프로젝트의 종류나 규모에 상관없이 일정 관리에 어려움을 겪는 이유 중 하나는 ‘프로젝트’라는 단어의 정의에서 찾을 수 있습니다. 프로젝트의 정의는 여러 가지로 내릴 수 있겠습니다만, 프로젝트 관리 분야에서 표준이라고 할 수 있는 PMI에서는 ‘프로젝트란 새로운 제품, 서비스 또는 결과를 창출하기 위해 수행하는 일시적인 노력(Temporary endeavor undertaken to create unique product, service, or result)’이라고 하고 있습니다.
이 정의에서 핵심 키워드는 ‘새로운’과 ‘일시적’입니다. 아무리 비슷한 프로젝트라 할 지라도 그 프로젝트만의 고유한 새로운 부분이 있기 마련입니다. 그러한 새로운 부분은 불확실성으로 작용하게 되어 일정 관리에 어려움으로 작용하게 됩니다. 달리 생각해 보면 전에 했던 작업과 100% 동일하다면 그건 프로젝트라 부를 수 없기에 프로젝트는 항상 경험하지 못했던 부분이 포함됩니다. 두 번째 키워드인 ‘일시적’은 달리 표현하면 마감 시한을 가지고 있다는 뜻이 됩니다. 이처럼 프로젝트는 그 특성상 항상 해결책이 무엇인지 모르는 새로운 부분이 들어가고, 이러한 부분을 주어진 시간 안에 해결해야 하기 때문에 우리는 항상 불확실한 계획으로 마감 시간이 다가올수록 일정에 압박을 받는 것이죠.
이러한 프로젝트의 일정 관리를 위한 기법들은 매우 많이 연구가 되었습니다. 서점에 가 보시면 프로젝트 관리 기법류의 책들이 무척 많이 있는 것을 발견할 수 있을 겁니다. 또한 이러한 관리 기법을 도와주는 프로그램 도구들도 많이 나와있죠. MS Project와 Primavera가 대표적인 프로그램입니다. MS Project 프로그램을 접해보지 못한 분들도 계실 수 있겠습니다만, 놀랍게도 MS사에서 출시한 수 많은 제품 중에서 네 번째로 출시한 제품입니다. MS의 첫 번째 제품은 1981년 DOS였고, 두 번째가 1982년 EXCEL, 세 번째가 1983년 WORD 였습니다. MS Project는 1984년도에 출시되는데 MS 사에서는 왜 프로젝트 관리 도구를 다른 더 중요해 보이는 제품들보다 먼저 출시한 것일까요? 그만큼 MS 사에서도 프로젝트 관리가 중요하다는 것을 인지하고 있었다는 반증이기도 합니다. 이러한 프로그램을 소개하는 것이 본 원고의 목적은 아니기에 간단히 제품명만 소개하는데 그칩니다. 프로그램 사용법에 대한 소개는 서점에 무척 많은 책들이 대신해 줄 것입니다. 그런데 아쉽게도 전산학에서 널리 통용되는 표현을 그대로 쓰자면 “은탄환(silver Bullet)은 없습니다”. 만병통치약처럼 어떤 소프트웨어 도구를 사용한다고 해서 문제가 해결되는 것은 아니라는 뜻입니다. 위드로봇에서도 괜찮다는 방법은 이것저것 도입해서 적용해 보았습니다만 결과적으로 대부분 실패로 끝났습니다. 분명 이러한 도구들은 유용하고 필요합니다. 하지만 근본적인 문제의 원인을 해결해 주는 것은 아니라는 뜻입니다. 위드로봇에서는 나름대로 몇 가지 답을 찾았다고 생각하기에 이 부분을 공유하고자 이 글을 씁니다.
고객의 요구를 들어주려고 하지 말고 욕구를 들어주어라
개발자들이 과제에 참여하면 초기에 하는 일 중에 하나가 기능 구현을 위한 요구 사항 명세서 입니다. 소위 말하는 스펙이죠. 백이면 백 모든 개발자들이 과제 초기에 스펙을 정해 달라고 하는데, 재미있는 사실은 60여건의 프로젝트 중에서 스펙이 과제 진행 중에 변경되지 않은 적이 한 번도 없었다는 점입니다. 뒤집어 말하면 고객이 개발자에게 무엇인가를 개발해 달라고 요구할 때 자신도 요구사항을 정확하게 파악하고 있지 못하거나 정확하게 파악하고 있더라도 정확하게 전달하지 못한다는 점입니다. 또한 아무리 시간을 많이 들여 고객의 요구 사항을 청취하고 이를 문서화하였더라도 과제 진행 중에 요구 사항이 바뀌는 것을 경험하였습니다. 그럼 어차피 요구 사항은 바뀌니 대충 스펙을 잡고 진행하면서 바로 잡아가면 될까요? 이럴 경우는 더 큰 재앙을 가진 프로젝트로 변질하곤 합니다. 전산학 쪽에서 매우 유명한 만화로 한 번 설명해 보죠. 여러 가지 버전이 있습니다만 위드로봇에서는 “프로젝트는 어떻게 망가지나?”라는 이름으로 설명하곤 합니다 (출처: http://www.projectcartoon.com) 자, 한 컷 한 컷 보면서 설명해 보겠습니다.
 |
| 1. 고객이 찾아와 아이들이 재미있게 놀 수 있는 놀이기구를 만들어 달라고 이렇게 설명했습니다. 2. 해당 과제 PM은 고객의 요구를 이렇게 이해했습니다. 3. 실무진은 이렇게 이해하고 설계를 시작했습니다. 4. 실무진이 구현한 형태는 이렇습니다. |
 |
| 5. 성능 검증을 위해 고객에게 전달되는 초기 버전 모습입니다. 6. 프로젝트 중간 발표는 이렇게 합니다. 7. 프로젝트 진행 중 문서 작업 상태입니다. 8. 최종적으로 구현한 모습입니다. |
 |
| 9. 고객에게 청구되는 비용은 이런 놀이기구를 만들 정도의 비용이 청구됩니다. 10. 추후 지원에 대한 모습입니다. 11. 광고는 이렇게 나가겠죠. iSwing!!! 12. 원래 고객의 머릿속에 있었던 놀이기구는 이거였습니다. |
강조하고 싶은 부분은 고객은 어떤 욕구가 있어 개발자를 찾아온 점이라는 것입니다. 그 욕구에 의해 도출된 요구 사항들을 개발자에게 설명합니다만, 그 설명은 충분할 수 없을 뿐더러 충분하더라도 전달 과정에서 왜곡되기 쉽습니다. 요구 사항들은 명백한 공학적인 용어로 정의돼서 전달되는 것이 아닌 매우 추상적인 언어로 표현될 것이기 때문입니다. 대표적인 것이 “가능한”, “충분히”라는 단어입니다.
위 만화에서는 아마도 고객은 아이들이 신나게 놀 수 있는 놀이 기구를 만들고 싶었을 것입니다. 복잡하고 세세한 기능이 있는 놀이 기구가 아닌 아이들이 손쉽게 매달려 놀 수 있는 단순한 놀이기구였겠죠. 이를 개발자에게 설명하다 보니 끈이 나무에 매달려 있고, 끈 끝에는 아이들이 앉을 수 있는 장치가 있어야 하고, 아이들이 다치지 않도록 충분히 안전해야 한다는 요구를 했을 것입니다. 때론 설명하다 보니 개발자가 수용하기 어려운 기능을 요구했을지 모릅니다. 아이들이 쉽게 매달릴 수 있도록 특별한 발 받침대가 있어야 한다든지, 가능한 뒤로 넘어지지 않도록 안전 장치가 있어야 한다든지 하면서 말이죠. 개발자는 이러한 요구 사항들을 열심히 수집하면서 “왜 이러한 요구 사항이 나오게 되었는지 그 근본적인 욕구를 읽어내야” 합니다. 그 욕구를 읽어내지 못하면 과제 진행 기간 동안 내내 스펙이 변경되어 했던 일을 다시 엎고 처음부터 시작해야 하는 과정을 반복하게 될 것입니다.
그럼 욕구는 어떻게 읽어낼 수 있을까요? 다른 사진 한 장에서 이야기를 시작해 보겠습니다.
이 멋진 사진은 미국의 요세미티 국립공원에 있는 해발 900여 미터 높이의 수직암벽인 El Capitan 입니다.
이 거대한 화강암 돌기둥은 암벽 등반가들이 세계에서 가장 좋아하는 정복대상 중 하나라고 하네요. 한때는 등반이 불가능한 것으로 여겨지던 이 El Capitan 암벽이 지금은 거대암벽 등반가들의 표준 코스가 되었습니다. 국내에서도 많은 등반가들이 정복한 과정을 블로그나 기사에서 찾아 보실 수 있을 겁니다. 올라가는 경로는 여러 종류가 있지만 가장 인기 있고 역사적으로 유명한 등반 경로는 ‘Nose’라 불리는, 양 암벽면 사이의 돌출부를 따라 올라가는 경로입니다. Nose 암벽의 최초 등반은 1958년 Warren Harding 팀에 의해 이뤄졌는데 무려 45일이나 걸렸다고 합니다. 중간 중간 벽에 못을 박고 그물을 친 다음 이곳에서 먹고 자면서 올라갔다고 하네요. 그런데 50여년이 지난 2010년 11월에는 Dean Potter와 Sean Leart가 2시간 36분 45초만에 올라갔다고 합니다. 50년 전에는 45일이 걸리던 경로가 불과 두어 시간 만으로 줄었다니 그 사이 장비가 좋아진 것일까요? 체력이 좋아진 것일까요?
재미있게도 바뀐 것은 장비도 체력도 아닌,“계획”입니다. 1958년 초기에 등반한 등반가들은 워낙 험준하고 힘들어 보이기에 한 달 이상의 일정으로 계획하고 배낭에 셔츠, 음식, 물과 같은 것들을 잔뜩 짊어지고 등반을 하였습니다. 그래서 오르는데 시간이 많이 소요되었고, 중간중간 캠핑을 해야 했죠. 2000년대 들어와서는 기존 고정 관념을 깨는 계획을 작성하기 시작했습니다. 암벽을 하루 안에 등반할 계획이라면 짊어지고 올라갈 장비 양을 크게 줄일 수 있을 것이고, 두어 시간 안에 올라갈 계획이라면 음식이나 물 따위도 필요 없이 맨 몸으로 올라갈 수 있을 것입니다. 이제는 아무것도 짊어지지 않은 채 최대한 빨리 정상으로 올라가는 데 집중하기에 두어 시간 만에 등반할 수 있게 되었습니다.
이 이야기에서 얻을 수 있는 정보는 (1) 고정 관념에서 탈피하라, (2) 가능한 많은 정보를 얻어라 (3) 가능한 몸을 가볍게 하고 짧고 실천 가능한 계획을 작성하라 입니다.
다시 앞의 놀이기구 프로젝트 만화로 돌아가 볼까요. 프로젝트를 성공하기 위해 개발자는 고객으로부터 가능한 많은 정보를 얻은 뒤 가능한 빠른 시일 내에 자신이 이해한 내용을 프로토 타입으로 구현하여 고객에게 보여주었으면 좋을 걸 그랬습니다.
다른 경우를 들어볼까요? 어떤 프로그램을 작동하는 UI라면 어떻게 하시겠습니까? 가장 일반적인 경우는 Visual Studio에서 기능은 뺀 채 컨트롤들만 배치한 후 보여주는 것이겠죠. 30점입니다. 조금 똑똑한 개발자라면 PPT에서 그려서 보여줄지 모르겠습니다. 50점입니다. VISIO에 멋진 GUI 스텐실들이 있습니다. 이를 이용하면 좀 더 빨리 프로토 타입을 만들 수 있습니다. 70점입니다. 종이에 연필로 그려가며 그 자리에서 빠르게 요구 사항들을 정리하며 고객의 욕구를 파악하면 100점에 가깝습니다. 이러한 기법을 사용자 인터페이스 연구 분야에서는 “paper prototyping”이라고 합니다(http://www.uie.com/browse/paper_prototyping).
우리는 고정 관념에서 탈피하여 짧은 시간 안에 고객의 욕구를 파악해야 합니다. 뭔가 대단히 멋진 것이 필요한 것이 아닙니다. 짧은 시간에 프로토 타입을 만들려면 힘든 방법을 택해서는 안됩니다. 등산 가방에 자꾸 뭔가를 넣으려고 하지 마세요. 회의하는 그 자리에서 프로토 타입이 나올 수 있으면 가장 좋습니다. 프로토 타입은 고객의 욕구를 파악하는 용도이기에 욕구를 파악하고 나서는 바로 파기되는 운명이므로 가능한 힘을 들이지 않고 구현할 수 있어야 합니다. 굳이 스포츠에 비교하자면 고객과 개발자는 테니스를 치는 것 보다는 탁구를 치듯이 빠르게 공을 주고 받으며 요구와 그에 따른 결과물을 확인하며 다시 피드백을 주어야 성공할 수 있습니다. 그래야 서로가 다르더라도 빠르게 수정하여 합의점을 찾아낼 수 있기 때문입니다.
프로젝트는 고객이나 개발자 모두 새로운 일이기에 암벽을 올라가는 것과 같습니다. 가능한 많은 정보를 얻기 위해 고정 관념에서 탈피하여 빠르게 프로토 타입을 만들어 서로의 머리 속에 있는 욕구를 정확하게 파악한다면 45일 걸리던 일을 2시간만에 끝낼 수도 있습니다. 하지만 서로가 무엇을 요구하는지 파악하지 못한다면 90일이 걸려고 못 올라가고 그만 포기할 수도 있습니다.
정리
여러 가지 이야기를 두서없이 늘어놓았습니다.
이제 앞에서 이야기한 내용을 간략히 정리 해 볼 시간입니다.
(1) 개발자들은 항상 일정에 쫓기고 변덕스런 고객에 치를 떱니다.
(2) 프로젝트라는 그 속성상 항상 새로운 일에 도전하는 것이기에 일정이 계획대로 진행되지 않는 리스크를 내포하고 있다고 설명했습니다.
(3) 이러한 리스크를 최소화하기 위해 우리는 고객을 좀 더 잘 알 필요가 있습니다.
(4) 고객은 초기에 이러저러한 요구 사항들을 설명할 것이지만, 추상적인 단어로 설명되기에 근본적으로 뭘 원하는지 알아내긴 힘듭니다.
(5) 그래서 개발자는 최대한 힘을 들이지 않는 방법으로 고객이 요구하는 바를 확인할 수 있는 프로토 타입을 만들어 고객의 욕구를 파악해야 합니다.
다 되었을까요? 한 가지가 더 있습니다. 개발자 또한 인간이기에 시간이 흐르면 자꾸만 예전 일들은 잊습니다. 예전 경험들을 기억하는 가장 좋은 방법은 기록하는 것입니다. 개발하기 바쁘기에 개발 과정을 기록한다는 것이 매우 비효율적으로 보일 수 있습니다만, 무슨 복잡한 정리를 하라는 것이 아닙니다. 노트 한 권 사서 퇴근 하기 전 대여섯 줄 정도만 그날 있었던 일들을 정리하는 정도라면 누구든지 할 수 있을 것입니다. 그날 한 일을 대표하는 블록 다이어그램으로 그려놔도 무척 좋습니다.
이 노트가 힘을 발휘하는 순간은 과제가 힘들어질 때입니다. 제 경우 뭔가 돌파구를 찾지 못하고 있을 때 노트를 펼쳐서 처음에는 어떤 생각을 했는지, 어떤 흐름으로 일을 진행했는지 읽다 보면 해결책이 보이는 경우가 많이 있었습니다. 과제 노트를 볼 때마다 놀라는 점은 당시에는 너무나도 중요했다고 생각했던 점들이 과제가 진행되면서 별 중요하지 않게 되는 경우가 비일비재하며, 오히려 간과하고 넘어갔던 점들이 과제가 진행되면서 더 중요하게 되는 것을 확인할 수 있습니다. 그리고 불과 2, 3개월 전의 일들이 너무나 쉽게 잊혀지기에 과제 중반 이후로는 처음의 생각과 전혀 반대의 결론을 내리기도 한다는 점입니다. 특히 중요한 과제를 맡은 PM일수록 이러한 노트의 필요성은 중요해집니다. 다시 한 번 강조합니다. 인간은 망각의 동물입니다. 뭔가 내가 다 기억하고 있다고 생각하지만 중요한 부분을 잊고 있는 경우가 많습니다.
추천 도서
프로젝트 관리에 관한 내용은 짤막한 글 한 편으로 전달될 내용은 아닙니다. 다행히 좋은 책들이 많이 나와있어 책을 통해 다양한 정보를 수집하실 수 있습니다. 책을 추천하는 것은 한편으론 쉬운 방법이지만 한편으론 매우 조심스럽기도 합니다. 책이라는 것이 읽는 사람에 따라 전혀 다른 정보를 주기도 하기 때문이죠. 그럼에도 불구하고 널리 회자되는 책들을 위주로 소개하는 것은 크게 부담이 되지 않는다고 생각하여 추천 도서 목록을 뽑아봅니다.
 |
·프레더릭 브룩스, “맨먼스 미신,” 케이앤피북스
‘은탄환은 없다’라는 명언이나 ‘프로젝트 말기에 새로운 인력을 투입하지 말라’ 등은 이 책에서 나온 말입니다. 혹시 이 책을 아직까지 읽지 않았다면 꼭 읽어보기 바랍니다. 놀랍게도 1975년에 쓰여진 책이며 아직까지도 널리 읽히고 있습니다. 제가 인상 깊었던 문구를 인용해 봅니다. 각 문구 앞에 있는 숫자는 해당 챕터를 뜻합니다.1.1 프로그래밍 시스템 제품은 개인사용을 목적으로 독자적으로 작성된 컴포넌트 프로그램보다 약 9배 만큼 노력이 더 필요하다. 제품화하려면 3배가 들 것으로 예상된다. 컴포넌트를 설계하고 통합하고 테스트하여 일관된 시스템으로 만드는 데는 3배의 비용이 필요하다. 그리고 이 비용 요소들은 본질적으로 서로 독립적이다. |
 |
· 엘리 골드윗, “더 골,” 동양북스
찬반이 너무나도 극명하게 나뉘는 책입니다. 저는 buffer를 관리하라는 메시지를 핵심으로 봅니다만 다른 부분을 비판하시는 분들도 많습니다. |
 |
· 조엘 스폴스키, “조엘 온 소프트웨어,”에이콘 출판
왜 야근을 하는 것이 생산성에 전혀 도움이 안 되는지, 개발자들이 진정 원하는 것이 무엇인지를 잘 설명하는 책입니다. |
 |
· 제프리 페퍼, “휴먼 이퀘이션,” 지샘
위 세 권과는 조금 다른 성격 인적 경영 관리의 책입니다만 팀장급 개발자라면 도움이 되는 내용을 많이 얻으실 수 있을 것입니다. |
글을 마치며
행복한 개발자가 되기 위해 위드로봇 연구소에 있는 개발자들은 오늘도 답을 찾고자 헤매고 있습니다. 아마 글을 읽으시는 독자 여러분들도 마찬가지일 것이라 생각합니다. 분명 더 좋은 방법, 더 핵심인 내용이 있을 것입니다. 블로그(http://withrobot.tistory.com/281)에 이 글의 전문을 올려 놓을 테니 댓글 형태로 적어주셔서 다른 분들과 공유해 주셨으면 합니다. 그래서 우리 모두가 행복한 개발자가 되었으면 합니다.
 |
 |
 |
 |
| 위드로봇㈜ 사무실 전경 | |