모아사마네집

다른 분야들도 그러하겠지만, 특히 소프트웨어 분야는 한 명의 천재 개발자가, 백명의 일반 개발자보다 낫다는 말을 하곤 합니다.

실제로 구글에서도 보면, 솔직히 저같은 개발자 100명보다는 Jeff Dean 이나, Sanjay Ghemawat 같은 사람 한 명이 더 뛰어난 것 같습니다.

Jeff Dean이나 Sanjay Ghemawat같은 초특급 개발자가 아니라 하더라도,

주위의 많은 개발자들 가운데에서 연봉은 2~3배 밖(??)에 더 받지 않는데, 생산성은 5배 10배의 사람들을 종종 볼 수 있습니다.

세상의 모든 사장, 매니저들은 그러한 사람들로만 회사를 꾸리고, 팀을 꾸리고 싶어할 것입니다.

팀안에 사람이 많아지면 많이잘 수록, 소통해야하는 관계가 증가하게 되고, 이것은 잘못된 오해를 일으키기 쉽습니다. 또한, 사공이 많으면 배는 산으로 가곤 하지요. 적은 수의 사람으로 작은 팀을 꾸리는 것은, 그러한 비용의 증가를 막을 뿐더러, 빠르게 변화하고 있는 시장 상황에 기민하게 반응할 수 있다는 장점도 있습니다.

예를 들어서, 200명이 일하는 프로젝트에 25명의 경험있는 프로그래머들이 매니저로서 일을 하고, 나머지 175명의 초급 프로그래머들에게 일을 시키기로 계획하였다고 합시다. 사실은 175명을 해고하고, 25명의 매니저들을 다시금 경험있는 프로그래머로서 일하도록 하는 것이 더욱 더 효율적인 방법이 될 수 있습니다.

하지만, 여기에는 치명적인 약점이 두개 있습니다.

첫번째는 200명이라는 숫자도 아주아주 커다란 프로젝트를 수행하는데에는 그다지 커다란 숫자가 아니라는 것입니다.

예를 들어서 저자가 일했던 프로젝트중 하나인 OS/360에는 약 5,000 Man-Year (Month가 아니라, Year입니다!) 가 소요되었습니다.

즉, 200명이 일했다면, 약 25년의 시간이 걸렸을 것입니다.

혹시, 여러분들중에 25년전에 만들어진 프로그램 사용하시는 분 계십니까?

약, 12년전에 나온 Windows XP를 쓰는 사람들도 요즘에는 너무 오래된 구닥다리 OS를 사용한다고 무시를 당하기 일쑤입니다.

두번째는 그렇게 뛰어난 사람들은 세상에 그다지 많지 않습니다.

구글처럼 Jeff Dean과 Sanjay Ghemawat을 동시에 가질 수 있는 것도 굉장히 커다란 행운이라고 생각합니다.

즉, 딜레마는, 세상에 뛰어난 사람들이 아주 많지 않은 상황에서 어떻게 커다란 팀을 꾸릴 수 있느냐 입니다.

저자는, Harlan Mills가 "Chief programmer teams, principles, and procedures,"에서 제안한 의료 수술팀의 형태를 제안합니다.

실제로 병원에서 수술을 할 때면, 단 한명이 처음부터 끝까지 모든 수술을 집도하고, 나머지 사람들은 조수로서 거들어 주는 방식의 분업이 이루어집니다.

소프트웨어 개발에서도 비슷한 구성을 할 수 있을 것이라고 합니다.

1.수술집도의 (The surgeon) = 책임 프로그래머 (a chief programmer)

수행할 프로젝트의 모든 것을 알고 있으며, 디자인, 성능 명세서, 코딩, 테스트, 그리고 문서화작업까지 모든 것을 다합니다.

뛰어난 실력과 10년이상의 경험, 그리고 시스템에 대한 충분한 지식을 가지고 있으며, 필요할 때는 수학적인 지식뿐만 아니라, 데이터를 다룰 수 있는 능력까지 지니고 있는 사람입니다.

전체 프로젝트의 책입자이며 상사(boss)이기도 합니다.

2. 부 집도의 (The copilot) = 프로그래머

이 사람은 책임 프로그래머가 수행하는 대부분의 일을 할 수 있습니다. 다만, 경험이 부족합니다.

책입 프로그래머와 함께 토론하고 새로운 아이디어를 테스트해볼 수 있는 실력이 있는 사람입니다. 코드를 직접 작성할 수도 있지만, 책입 프로그래머의 승락하에서 그 코드가 실제 프로젝트에 적용이 됩니다.

3. 행정 관리자 (the administrator)

책입 프로그래머가 전체프로젝트의 상사이지만, 돈이라던지, 공간, 컴퓨터 기계할당과 같은 일을 다 하기에는 이미 너무 많은 역할이 있으므로, 행정 관리자가 그러한 점들을 도와줍니다. 반드시 하나의 프로젝트에 종속될 필요는 없고, 두개의 프로젝트를 동시에 관리해줄 수도 있습니다.

4. 편집자 (The editor)

프로젝트 안에서 발생하는 모든 문서를 정리하고, 다듬는 역할을 담당합니다. 예를 들어, 프로그래머들이 시스템 디자인에 대한 초안을 만들면, 그것을 다듬에서 대내외적으로 사용할 수 있도록 다시 작업을 해주기도 합니다.

5. 두명의 비서 (Two secretaries)

행정관리자와 편집자를 도와줄 비서가 각각 한명씩, 총 두명이 필요합니다.

6. 프로그램 서기 (The program clerk)

프로젝트가 어떻게 진행되고 있는 모든 기록들을 담당합니다.

7. 도구장이 (The toolsmith)

프로그램을 개발하려면 여러가지 도구들이 필요합니다. 그러한 것들을 개발하고, 지원해주는 팀입니다.

실제로 구글에서는 이러한 도구팀에만 100명이 넘는 엔지니어들이 일을 하고 있습니다.

8. 테스터 (The tester)

기본적으로 프로그래머들이 테스트 케이스들을 작성하기도 하지만, 그것은 단위 테스트일 경우가 많습니다

.이 테스터는 좀더 최종적인 프로젝트의 관점에서 테스트 순서를 세우고 보다 완벽하게 테스트를 합니다.

9. 프로그래밍 언어 상담가 (The language lawyer)

때로는 복잡한 프로그램도 다른 언어를 사용함으로서 쉽게 해결될 수가 있습니다.

그러한 제안을 해주는 것이 바로 이 프로그래밍 언어 상담가입니다.

책입 프로그래머는 때때로 이 상담가를 찾아서 주어진 문제를 이야기하고, 그러한 문제를 해결할 수 있는 가장 최적의 프로그래밍 언어를 알아낼 수 있습니다. 이 상담가는 여러명의 프로그래머를 지원해주고 도와줄 수 있습니다.

10. 왜 10이 없을까요? 그건 5번에서 비서가 두명이기 때문이지요. ^^

자, 그러면 몇명의 책임 프로그래머가 있어야지, 5,000 Man-Year 프로젝트를 1년안에 마칠 수 있을까요?

두가지 가정을 더 해보겠습니다. 저 5,000 Man-Year은 중간 수준의 프로그래머 5,000 명이 1년동안 구현하였다고 하고, 두번째로 10명 팀에서의 책임 프로그래머는 약 7배의 생산성을 가지고 있다고 해보겠습니다.

정답은 5,000 / 7 = 715명이 아닙니다! 그 비밀은 사공이 많을 수록 배는 산으로 가는 것에 있습니다.

실제로 토론하고 결정해야하는 사람의 숫자가 줄어들 수록 효율성은 올라갑니다. 물론, 사람이 줄어드는 만큼 개개인의 역량은 뛰어나야 겠지요.

따라서 실제 정답은 5,000 / 7 / 7 = 102명입니다.

5,000 Man Year 프로젝트를 약 100여개의 작은 프로젝트로 나누고, 각 프로젝트별로 뛰어난 역량의 책임 프로그래머를 임명하고, 그 프로그래머를 도와줄 수 있는 사람들을 붙여주는 것이 가장 효율적으로 일할 수 있는 방법입니다.

어린 아이들은 꿈을 꿉니다. 그리고 그 꿈을 모두 이룰 수 있다고 믿습니다.

저도 어렸을 때는 노벨상 수상, 당연히 할 수 있을 줄로만 알았고, 마음만 먹으면 우주비행사도 될 수 있을 줄 알았습니다.

어른이 된 우리는 이러한 일들이 그리 쉽게 이루어질 수 없다는 사실을 너무나 잘 알고 있습니다.

하지만, 소프트웨어 엔지니어로서의 우리는 여전히 어린 아이들인 것 같습니다.

어떠한 일을 주고, 이 일을 언제까지 할 수 있느냐고 물어보면, 대다수는 낙관적인 대답을 합니다.

그리곤 부지기수로 그 일을 본인이 대답한 기간내에 끝을 내지 못하고, 상사들에게 쪼임을 당하지요.

혹시, 여러분들 중에 "내가 이때까지 하겠습니다."라고 상사에게 말했을 때,

"그거 너무 낙관적인거 아니야" 라고 되물음을 당하신 적이 있다면, 최소한 여러분은 Information Technology 강국의 상사와 일하고 계십니다.

하지만, 반대로 무리할 일정인대도 항상 "그래, 아주 좋아! 한번 해봐!" 라고 말을 듣는다면, 여러분은 Information and Telecommunication 강국의 상사와 일하고 계십니다.

이 책의 저자는 본인이 관리하는 프로젝트의 일정을 다음과 배분합니다.

1/3 계획

1/6 코딩 및 구현

1/4 개별 테스트 및 초기 시스템 테스트

1/4 전체 시스템 테스트.

첫 인상은, 생각보다, 계획이 길고, 생각보다 구현이 짧다는 것을 알 수 있습니다.

프로젝트를 진행할 때마다, 이러한 말들을 많이 듣습니다. 구현 명세(Specification)이 너무 자주 바뀝니다.

혹시, 이것은 우리가 충분한 시간을 계획에 쏟지 않았기 때문은 아닐까요?

통일이 되어서 서울에서 중국 상하이로 가야 하는데, 자동차 여행을 하려고 합니다.

이때, 단순하게 상하이가 서쪽에 있다고, 무작정 서쪽으로 인천으로 자동차를 운전하면 어떻게 될까요?

충분한 시간을 계획에 투자하는 것이 궁극적으로 시간을 절약할 수 있습니다.

하지만, 충분한 계획을 세운다고 하더라도, 일정은 지연될 수도 있지요.

책에 나와있는 예제는 다음과 같습니다.

3명이 4달동안 일하는 프로젝트 이므로, 이 프로젝트의 Man-Month는 3 Man * 4 Month = 12 Man-Month 입니다.

자. 그런데 그 프로젝트가 지연이 되어서, 두달동안 A를 겨우 도달하였습니다.

이때 우리는 무엇을 할 수 있을까요? 저자는 4가지, 우리가 선택하는 방법들을 말해줍니다.

1. 남은 두달 안에 프로젝트를 반드시 끝내야 된다고 가정합시다. 남은 일의 양은 3 Man * 3 Month = 9 Man-Month 입니다. 이것을 두달 만에 해야하므로, 4.5 명이 필요합니다. 우리에게는 현재 3명이 있으니깐, 1.5명을 더 고용합니다.

2. 역시, 남은 두달 안에 프로젝트를 반드시 끝내야 된다고 가정합시다. 애초에 Man Month를 잘 못 계산하였다고 인정을 합니다. 즉, 이 프로젝트는 3명이서 한달마다  각각의 마일스톤을 달성하는 것이 아니라, 3명이서 2달동안 각각의 마일스톤을 달성할 수 있는 프로젝트였습니다. 3명이서 2달동안 1/4인 A를 도달하였으므로, 원래 필요한 Man-Month는 3 * 2 * 4 = 24 Man-Month 이고, 현재 18 Man-Month 가 남았습니다. 2달이 남았으므로 총 9명이 필요하고, 현재 우리에게 3명이 있으므로, 6명을 추가로 고용합니다.

3. 다시 일정을 계획을 세웁니다. 이번에는 다시는 이런 일이 없도록, 아주 조심스럽게 계획을 새로 세웁니다.

4. 프로젝트를 축소하는 것입니다. 이 방법은 일정을 연기하는 비용이 너무 비쌀 때 주로 선택이 됩니다.

여기에서 주목을 해야하는 것은 사람을 추가하는 첫번째와 두번째 방법입니다.

이 방법 들은 아주 중요한 두가지를 빼먹고 있습니다. 훈련과 소통입니다.

새로운 멤버가 중간에 들어오게 되면, 이미 있는 시스템에 익숙해지고,해야할 프로젝트를 이해하는데 시간이 필요합니다.

구글에서는 이 기간을 짧게는 3개월에서 길게는 약 1년정도로 잡고 있다고 들었습니다.

앞의 예에서 만약에 어떠한 사람이 시스템과 프로젝트를 이해하는 데 3개월이 시간이 걸린다고 가정하면, 이미 그 사람이 이해할 때쯤에는 모든 프로젝트가 거의 막 바지에 달해있을 것입니다.

두번재로 소통은 누군가가 들어오면 소통을 해야할 사람이 기하급수적으로 늘어난 다는 사실입니다.

2명밖에 없을 때는 소통의 채널이 A - B만 있으면 되지만,

3명이 되면, A - B, A - C, B - C. 3배로 늘어나고,

4명이 되면, A - B,  A - C, A - D, B - C, B - D, C - D로 2명일 때보다 6배로 늘어나게 됩니다.

함께 프로젝트를 처리해 나가는데 이 소통의 비용 또한 무시할 수 없습니다.

즉, 이러한 훈련과, 소통의 시간 때문에, 실제로 프로젝트 중간에 사람을 추가하는 것은 불난 집에 석유를 붓는 것과 같습니다.

이러한 현실을 저자는 자기의 이름을 붙여 "Brooks's Law"라고 표현하였습니다.

지연된 소프트웨어 프로젝트에 사람을 더 추가하는 것은 그 프로젝트를 더욱 늦게 만든다.

100층 짜리 높은 빌딩을 지을 때, 우리가 기초공사 다지고, 30층까지 지은 빌딩을 허물고 다시 짓지 않을 수 있는 것은, 충분한 경험을 바탕으로 충분한 시간을 들여서 게획을 세우기 때문이라고 생각합니다.

미리 미리 충분한 시간을 들여서 계획을 세울 때만이, 전체적인 프로젝트 일정을 앞당길 뿐만 아니라, 충분한 테스트를 통하여, 더욱 단단한 소프트웨어를 만들 수 있습니다. 사실 이러한 일을 담당하는 사람이 시스템 아키텍쳐인 것 같습니다. 충분한 경험을 바탕으로, 전체적인 시스템의 그림을 그리고, 일정을 짤 수 있는, 이러한 뛰어난 시스템 아키텍쳐가 한국에서도 많이 나오기를 기대합니다.

첫번째 챕터의 제목은 "The Tar Pit"입니다. 솔직하게 "Tar"는 뭔지 알겠는데, "Tar Pit"은 뭔지를 몰랐습니다.

그래서 위키피디아를 찾아보았습니다.

http://en.wikipedia.org/wiki/Tar_pit  에 따르면,

(이 사진도 저 위의 위키 페이지에서...)

즉, 가벼운 것들은 날아가고, 묵직한 것들만 남는다는 말입니다.

무엇이 가벼운 것이고, 어떠한 것들이 묵직한 것은, 잠시후에 계속 이야기 나눠보도록 하겠습니다.

저자는 프로그램의 개발은 4단계로 나누었습니다.

1. Program.

2. A Programming Product

3. A Programming System

4. A Programming Systems Product

가장 첫번째 "Program"은 그냥, 구현하고자 한 기능이 올바르게 동작하는 것입니다. 보통 혼자서 본인의 목적을 위해서 만드는 프로그램이지요.

이 프로그램은 두가지 방향으로 발전할 수 있습니다. "A Programming Product", "A Programming System".

"A Programming Product"는 우리가 혼자서 만든 프로그램의 구현을 좀더 일반적으로 하고, 테스트도 꼼곰하게 하고, 문서화 작업도 합니다.

그래서 이 프로그램을 많은 사람들이 다시금 사용할 수 있고, 확장할 수 있는 단계입니다.

제가 직접 예를 들어보면, 1번의 경우에는 자신의 필요에 의해서 프로그래밍을 짭니다.

그리고 2번은 그 프로그래밍을 오픈소스화해서, 많은 사람들과 함께 개발해 나가는 단계라고 할 수 있겠습니다.

"A Programming System"은 다른 시스템과의 통합을 위해서 interface를 구축하는 것입니다.

숨길 것은 숨기고, 드러내야할 것은 드러내는 API 설계와 같은 것이지요.

4번 "A Programming Systems Product"는 2번과 3번이 모두 구현된 것이고요.

자 그러면 왜 제목이 "Tar Pit"일까요? 저자는 왜 이러한 제목을 뽑았는지를 명시적으로 설명해주지는 않습니다.

다만, 1번에서 2번으로 갈 때나, 1번에서 3번으로 갈 때, 1번의 개발 시간 보다 약 3배의 시간이 보통 걸린다고 주장합니다.

궁극적으로 4번으로 가기위해서는 3배 * 3배. 즉, 개발시간보다 약 9배의 시간이 필요합니다.

즉, 1번의 시간과 합치면, 우리가 처음에 계획한 시간보다 약 10배의 시간이 보통 필요합니다.

우리는 보통 1번의 코딩을 마치면, 이제 거의 다 이루어졌다고 생각합니다. 재미있는 일은 이제 끝이 난 것이지요.

하지만, 우리가 만든 "Program"이 진정한 가치를 지니기 위해서는 지금까지 쏟은 시간의 약 9배의 시간이 더 필요합니다.

그리고 그 시간은 우리가 실어하는 테스팅, 문서화, 그리고 API설계등입니다.

가볍고 즐거운 일은 모두 날아가버리고, 묵직하고 하기 싫은 것만 남은 "Tar Pit"이 남은 것이지요.

하지만, 우리가 프로그래밍을 통해서 무엇인가를 창조하는 기쁨은, 비록 9배의 시간이 걸리는 테스팅과 디버깅의 즐거움을 능가하지요? :-)

그렇기에 다음 프로그래밍을 위해서, "Tar Pit"의 시간들을 잘 이겨낼 수 있다고 생각합니다.

그리고 이책은 앞으로 어떻게 하면, 그 "Tar Pit"을 조금더 쉽게 이겨낼 수 있을지에 대해서 이야기해볼 것입니다.

2005년 제법 찬바람이 불기 시작한 늦 가을이었습니다.

3년여의 병역 특례가 마칠 때가 되어가고 있어서, 그 이후의 진로에 대해서 심각하게 고민을 시작하였습니다.

당시에 하고 있었던 3D Online Game을 만든 것에 대해서 불만도 별로 없었고, 앞으로도 계속 프로그래머로서 살아간다는 사실에 대해서는 별로 의심하지 않았습니다.

2006년, 2007년, 그리고 어쩌면 2010년에 해야할 일에 대해서는 별로 불안감이 없었지만, 2020년, 2030년의 나의 모습에 대해서는 너무나 불투명한 미래라고 생각하였기 때문에, 고민을 시작했던 것 같습니다.

지도교수님을 찾아뵈었습니다. 그리고, 상담을 시작하였습니다.

교수님께서는 왜 한국에서, 40살, 50살 먹은 프로그래머가 없는줄 아느냐. 그것은 한국의 소프트웨어 산업이 그만큼 성숙하지 못하였기 때문이다. 아직도 어린아이와 같은 수준이기 때문에, 20년 30년의 경력이 필요 없는 그러한 사회이기 때문에, 40살, 50살이 된다고 하더라도, 여전히 20대, 30대 친구들이 하는 일과 비슷한 일을 해야하고, 젊은 그들과 경쟁을 하여야 한다. 라고 말씀하였습니다.

약 8년의 시간이 지났지만, 현실은 그다지 크게 바뀌지 않은 것 같습니다.

구글에서 "프로그래머"로 검색어를 넣으면, 두번째로 나오는 것이 치킨집이니까요.

"닭 튀김 수렴공식"도 있으니까요. 궁금하시면 검색해보세요. ^^

그러한 상담끝에, 세계에서 가장 소프트웨어가 성숙하였고, 성장하였다는 미국으로 유학을 왔고, 취직을 하였습니다.

이곳 미국에서 나름 가장 잘 나간다는 "소프트웨어" 회사에서 약 4년반, 인턴까지 하비면 5년여의 시간을 일하면서 느낀점은.

1. 확실히 한국보다는 성숙하였다.

2. 그렇지만, 여전히 소프트웨 산업은 더욱 성숙하여야 한다.

한국의 소프트웨어 산업이 유치원/초등학생 이라면, 미국의 소프트웨어 산업은 중학생/고등학생의 느낌입니다.

이러한 점은 소프트웨어 프로젝트를 진행할 때 잘 나타난다고 생각합니다.

아직 어리고, 경험이 부족하기 때문에, 내가 지금 하려는 것이 무엇인지, 그리고 그 일이 얼마나 걸릴 것인지 제대로 예상할 수 없는 것이지요.

대표적인 예로 교육행정정보시스템(NEIS)를 들 수 있다고 생각합니다.

http://ko.wikipedia.org/wiki/%EA%B5%90%EC%9C%A1%ED%96%89%EC%A0%95%EC%A0%95%EB%B3%B4%EC%8B%9C%EC%8A%A4%ED%85%9C 을 보시면,

2010년에 "차세대 나이스 구축 기본계획"을 수립하였고, 2011년 2월에 구축을 완료하였습니다. 즉, 1년만에 "계획", "구현", "테스트"를 완료한 셈이지요. 그리고는 2011년에 7월에 성적이 잘 못 입력되는등 소위 "나이스 대란"이 발생하였습니다.

하지만, 이러한 문제는 비단 한국만의 문제는 아닌 듯합니다.

미국이 조금더 성숙하였다고는 하지만, 여전히 청소년 인 것은 맞으니까요.

그 대표적인 증거중 하나가 "The Mythical Man-Month"라는 20주년 기념 증보판 발매입니다.

이 책은 Frederick P. Brooks, Jr. 라는 University of North Carolina at Chapel Hill의 교수가 쓴책인데, 소위 IBM System/360의 아버지라고 불리우는 분입니다. 오랜 기간동안 프로젝트를 관리해오시면서, 겪었던 일들을 기반으로 하여서, 약 20년전에 "The Mythical Man-Month" 라는 소프트웨어 프로젝트 관리에 대한 책을 쓰셨는데, 최근에 약 4개의 챕터를 더해서 증보판이 발매가 되었습니다.

이러한 점이 저의 관심을 끌기에 충분하였습니다.

그리고, 첫 두챕터를 읽으면서, 이 책의 내용들을 한국에 있는 소프트웨어 개발자들과 나누고 싶어졌습니다.

여전히 성장하고 있는 미국의 소프트웨어 산업의 한 가운데에서, 20년전 발매된 고전을 읽으며, 앞으로 한국의 소프트웨어 산업이 나아가야할 방향을 함께 고민해볼 수 있기를 바랍니다. 저는 반드시 한국이 미국의 뒤를 따라가야한다고 생각하지는 않습니다. 그 고전을 통해서 미국이 걸어온 길을 함께 토론하고 이야기해보면서, 잘한 것은 따라하고, 미국이 미리 겪었던 실수는 피해갈 수 있는 지혜도 얻을 수 있기를 바랍니다.

사실, 저는 이제 겨우 11년차밖에 되지 않은 개발자입니다. 그리고, 저는 소프트웨어 공학을 전공하지도 않았고, 이 책을 다 읽은 것도 아닙니다. 다만, 조금씩 읽으면서 나누는 이야기들이 서로에게 도움이 되기를 바라는 마음에서 이러한 글을 남김니다. 건설적인 비판은 날카로울 수록 환영합니다. 소모적인 비난은 조용하게 무시하도록 하겠습니다. ^^