맨먼스 미신, 개발자의 생산성에 관하여

The Mythical Man-Month

맨먼스 미신, 이게 대체 무슨 말일까?

M/M (Man Month) 라는 말이 있다. 한 사람이 한 달 동안 작업하면 끝낼 수 있는 양이라는 뜻이라고 한다. 그렇다면, Man-Month Myth는 작업 생산성에 대한 근거 없는 이야기 정도로 의역이 될 거 같다 라고 생각한다... 영어는 자신이 없다 😂

뭔가 좀 이상하다. Cowork 해본 사람은 알겠지만, 프로그래밍 만큼 사람 때려박는것에 비해 능률이 눈에 잘 안 띄는게 별로 없지 않나 싶은 기억이 떠오른다. 공감하지 않는 사람도 있을 것 같다. 아마 훌륭한 업무환경에서 일하지 않았나 섣불리 짐작해본다!

책 소개에 이런 말이 적혀 있다.

책 출간 20주년을 맞이하여 브룩스는 원래 아이디어를 다시 점검하고 그의 작업에 익숙한 독자들뿐 아니라 이 책을 처음 읽는 독자들을 위해 새로운 생각과 조언을 덧붙였다. 이 20주년 기념판에는 1판에 없던 「은 탄환은 없다」가 수록되었고 「은 탄환은 없다」 발표 이후 브룩스의 견해가 보충되었으며, 초판의 내용을 회고하고 브룩스의 주장을 재검토하는 장들이 추가되었다. 한국어판에는 이 책이 쓰일 당시의 컴퓨터 환경에 생소한 독자들의 이해를 돕기 위해 이 책에서 언급되는 옛날 컴퓨터에 대한 설명을 부록으로 실었다.

"은 총알"에 대한 이야기들이 많이 나온다. 책에서는 우리가 그동안 개발 기획에 대해 오해하기 쉬웠던 "은 총알" 방식의 해결책에 대한 다시 짚기를 하고 있다.

타르 구덩이와 은 총알

개발은 의도대로 잘 진행되지 않는 경우가 많다. 이는 실제 프로덕션을 만들어 내는 데 있어, 프로그램의 규모가 크고 복잡해지면 추가되어야 하는 노력이 훨씬 많아지기 때문이다. 그 딜레마에서 헤어 나오려고 노력하더라도 적절한 기법이 동반되지 않으면 침식되어 버리고 말 것이다. 이는 마치 "타르 구덩이" 속에 헤어나오지 못하는 것과 유사하다.

"사공이 많으면 배가 산으로 간다" 라는 이야기가 있다. 이는 개발에서도 마찬가지이고, 맨먼스 머신에서도 이를 언급한다. 다시 말해, "은 총알은 없다"라고 이야기 하고 있는 것이다.

처음 이 이야기를 듣고 fireegg를 탁! 칠 수밖에 없었다. 전에 다녔던, 다소 이해할 수 없었던 회사의 행보가 떠올랐고, "은 총알"을 마구 남용하고 있었던 상황이 다시금 떠올랐다. 사람이 부족하면 더 뽑으면 된다고 생각했고, 프로젝트가 늦어지면 사람을 더 때려박으면 된다고 했다. 그런 대책에도 불구하고 소프트웨어는 계속해서 "타르 구덩이"로 빠져 들어가고 있다는 느낌을 지울 수 없었다. 나는 의구심을 가졌지만, 딱히 할 수 있는 말은 없었다.

내가 이 책을 읽게 된 이유도 이렇게 당연한 내용이 어째서 당연한지에 대한 논리적 근거를 얻기 위함이었다.

소프트웨어 공학에 관한 에세이

책에서 다루는 내용 자체는 이러한 "은 총알"들에 대한 내용들이다. 좀 더 정확히는, 이론적인 내용보다는 에세이에 가깝고 저자도 그렇게 이야기하고 있다. 편하게 읽을 수 있지만 동시에 얻어갈 수 있는 것도 많았다. 그리고 사람마다 얻어갈 수 있는 내용이 분명 다를 것이고, 이는 이 책을 읽고 쓴 후기들이 서로 다르다는 것으로부터 쉽게 알 수 있다.

나 또한 내가 얻어간 내용들을 몇 가지 적어보았다.

나는 몇 년간 소프트웨어 프로젝트 일정을 관리하면서 다음과 같은 나름의 법칙을 세워 성공리에 적용해 왔다.
계획 수립: 1/3
코딩: 1/6
구성 요소 테스트와 초기 시스템 테스트: 1/4
모든 구성 요소가 준비된 후의 시스템 테스트: 1/4

(소프트웨어 관리자들은) 생산성 수치, 버그 발생률, 추정 원칙 같은 것을 마련하고 공표해야 한다.

내가 보아왔던 보통의 소프트웨어 관리자들은 무조건 비즈니스 이슈에 맞춰 개발을 진행했다. 일정을 요청하고, ASAP로, 개발을 요청한다, 물론 그것도 고객사가 급하니까 ASAP로. 그리고 항상 production에서는 문제가 발생했고, 그것들은 또 긴급하게 바로잡혀야 하기 때문에 개발자에게 스트레스를 준다. 결국 상처밖에 남지 않는 개발이 진행됐고, 이는 무한히 방복된다. 개발자들은 절대 저 일정으로는 할 수 없다고 이야기했지만, 그들은 고객사가 언제나 으뜸이었다.

고객사가 으뜸이라고 해서 저러한 최소한의 일정 관리 및 통계에 기반한 추측 없이, 최소한의 개발 예상 시간만을 프로젝트 일정으로 잡는 행위가 옳은 행위였을까? 고객사과 개발자 모두의 인내심을 갉아먹는 행위는 아니었을까 난 생각한다. 관리자는 스스로가 불가능한 작업을 가능하게 하도록 하기 위한 채찍질하는 도구가 아니라는 걸 알 필요가 있다고 생각한다. 미완성된 프로덕션이 나갔다는 것은 관리의 끝이 아니고, 실패한 관리자의 결과물이다. 그리고, 이에 대한 책임이 개발자와 고객사에게만 떠넘겨지는 모습을 많이 보아왔다. 극도로 무책임하다.

그렇기에 프로덕션에 문제가 있다면, 그것은 일정 및 품질을 관리하는 관리자의 책임이 훨씬 막중하다고 생각한다.

이뿐만 아니라, 개발보다 테스트와 계획에 드는 비용을 너무 간과하는 경우를 많이 보아왔다. 기획이 제대로 되지 않으면 고무줄 같은 개발 일정과 설계의 실패를 유발하고, 테스트에 시간을 제대로 잡지 않으면 마찬가지로 일정내 제대로 마무리가 되지 못하거나, 아니면 테스트가 제대로 되지 않은 채로 폭탄과도 같은 제품이 그대로 고객에게 전달되는 걸 난 보았다.

부족한 시간 탓에 망가진 소프트웨어 프로젝트 수는 다른 이유로 그렇게 된 경우를 모두 합한 것보다도 많다. ... (중략) ... 일정이 어긋나는 것을 감지했을 때의 자연스러운 (또한 전통적인) 대응이 인력 추가 투입이라는 점이다. 이것은 휘발유로 불을 끄려는 것처럼 사태를 걷잡을 수 없이 악화시킬 뿐이다.

추가 인원을 붓는 건 이미 늦어진 개발 일정에 있어 좋은 선택이 아니다. 의사소통 문제와 작업 인수인계의 오버헤드가 상상 이상으로 크다. 문제는 비개발 부서에는 이 점을 잘 모르고 진행하려 하는 경우가 많다는 것이다. 인력을 "은 총알"로 생각하려고 하는 것이다.

이 부분은 책의 마지막에서 상황에 따라 이를 충분히 보완하고 극복할 수 있다고 쓰여 있다. 하지만, 극단적인 효과를 보는 것이 여전히 어렵다는 점과 오히려 일정이 늦춰질 수 있다는 것은 본질적으로 동일하다.

(프로그래머는 낙관론자다) 인간이 무언가를 만들 때는, 그 생각에 불완전함이나 모순이 있더라도 실제로 만들기 시작한 후에야 그것이 명확해진다. 따라서 이론가들에게는 글로 쓰거나 실험하는 등의 '실제 해보기'가 필수적인 지침이 된다.

자신의 프로그래밍 팀이 절반 정도로 일정에 맞추지 못하는 것을 발견했는데, 각 작업은 개산치의 약 2배 정도의 시간이 걸리고 있었다. ... (중략) ... 그의 팀이 일하는 시간의 50%만 실제 프로그래밍 작업과 디버깅 작업시간으로 쓰였다는 사실을 발견할 수 있었다. 개산 오류는 바로 이런 점을 간과한 데서 발생한 것이었다. 나머지 시간은 머신이 작동을 멈춘 시간, 우선순위가 더 높지만 작업과는 관계없는 업무들, 회의, 문서 작업, 회사 일, 병, 개인 시간 등에 쓰였다.

저자는 숙련된 프로그래머들이 프로그램 작성을 시작하기 전에 판에 박힌 듯이 상세한 흐름도를 만드는 것을 본 적이 없다. 조직에서 요구하는 표준에 흐름도가 포함되어 있더라도 대부분은 프로그램이 실체화된 이후에 만들어진다.

대부분의 프로젝트에서 나온 첫 시스템은 거의 쓸 수 없는 수준이다. ... 버려지기 위한 시스템을 만드는 것은 피할 수 없다.

XP(eXtreme Programming)과 궤를 같이 하는 내용이라고 생각한다. 설계도보다는 prototyping이 더 중요할 때가 꽤 있다. 탁상 회의만으로는 실무에서 마주치는 이슈를 파악하기에는 한참 부족하다.

널리 쓰이는 프로그램의 경우, 유지 관리 총 비용은 대개 개발비용의 40% 또는 그 이상에 이른다.

유지보수 비용을 결코 간과해서는 안 된다. 이따금씩 이를 신경쓰지 않고 "요즘은 신개발 건도 없는데, 왜 이렇게 바쁘다고 그러는 거야?" 라고 위에서 치부하는 경우가 있다. 그동안 진행한 수많은 개발에 대한 유지보수 비용을 제대로 계산하지 못하고 있는 경우고, 이런 경우 보통은 유지보수 비용을 줄이는 작업에 대한 가치를 느끼지 못하더라. (리팩토링 안 함)

이처럼 때로는 유지 관리에 드는 비용 자체도 제대로 파악을 못하고 있는 경우도 있다. "기술 부채" 관리는 이러한 점에 있어서 중요한 포인트가 될 수 있다고 생각한다.

동일한 훈련과 2년 경력의 수준에서, 매우 훌륭한 프로그래머는 좋지 못한 프로그래머보다 생산성이 10배 높다.

서로 소통해야 하는 사람 수가 전체 비용에 영향을 미친다고 했다. 이것은 비용의 대부분이 커뮤니케이션에, 그리고 잘못된 커뮤니케이션의 부작용을 바로잡는 데(즉 시스템 디버깅에) 소요되기 때문이다.

위의 맨먼스 내용에서 보다 더 직접적인 생산성에 대한 이야기다. 소수의 엘리트 프로그래머들이 가진 집착과 설계 능력은 다른 평범한 개발자들의 것을 아득히 뛰어넘는 것은 분명하다. 내로라하는 스타트업들이 보통 2~3명의 초창기 멤버를 가졌다는 건 많이 알려져 있는 이야기이다.

비단 스타트업뿐만은 아니다. 회사에서도 그러한 사람들을 어렵지 않게 찾아볼 수 있다. 그리고 나는 인사팀들이 이런 엘리트 프로그래머의 전문성을 간과하는 경우를 나는 종종 봐왔다. 그들은 공기업 연차 쌓는 것 마냥 프로그래머들을 대우해줬고, 높은 실력자들은 연차 1~2년 정도 더 쳐 주는게 그만이었다. 그렇게 출중한 실력을 가진 친구들은 다른 회사로 오퍼를 받고 떠났고, 그렇지 못한 사람들만이 회사에 남게 되었다. 그런 사람들과 커뮤니케이션하는 데 드는 비용은 분명히 더 비싸다.

설계와 구축에 소수 인원만이 관여하는 게 낫지만, 큰 규모의 시스템을 만들려면 적절한 기간 내에 완성할 수 있을 만큼의 인원이 필요하다. 상충된 두 가지를 어떻게 하면 조화시킬 수 있을까? ... (중략) ... 한명이 문제를 해결해 가는 동안 다른 이들은 그 사람이 효율과 생산성을 높일 수 있도록 여러 방면에서 지원해 주는 것이다.

위에서 엘리트 프로그래머의 생산성이 압도적으로 높다는 이야기가 되었지만, 이는 적은 인원들로 진행하는 설계의 효율성에서 기인하는 바도 크다. 이러한 특성을 살려, 거대 프로젝트를 진행함에 있어서 최적의 효율적인 모습은 "귀족 정치"의 모습이 되는 것이다.

(창조적인 즐거움은 모두 아키텍트 몫이 되고 구현자들의 독창성은 배제될 것인가?) 주어진 명세에 맞춰 작업한다고 해서 구현 중에 창조성과 독창성을 발휘할 기회가 그리 줄어드는 것도 아닐 뿐더러, 오히려 그로 인해 창조성의 수준이 더 높아질 수도 있다.

위의 "귀족 설계"를 이야기를 보다 보면, '설계자가 아주 막강한 권한을 가지고 있고, 고급 인원들만 할 수 있는 게 아닌가?' 라는 생각이 든다. 실제로 숙련된 프로그래머들이 설계자의 위치에 서는 경우가 많았고, 이들이 정하는 방향성이 프로젝트 성공의 여부를 가르는 경우도 많았다.

그렇다고 구현자들이 하는 일이 중요하지 않다는 이야기가 아님을 이 문단에서는 이야기하고 있다. 구현자들도 세부 설계에 대해서 많은 창의력과 구현 능력을 필요로 하고, 이 과정은 충분히 재미있으며 숙련도를 요구한다고 이야기한다.

그런데 이 부분에 대해서도 역할 분담이 중요하다는 걸 느낀다. 이따끔씩 아키텍트 설계자가 개발자가 해야 하는 현업 부분까지 설계할 권한을 가진 경우가 있다. 이 경우는 개발자 입장에서 문제가 있다고 생각해도 설계를 뒤엎을 권한 자체가 부족한 경우도 많았고, 정해진 일만 해야 하는 개발 자체가 "아주 재미없는 일"이 된다.

이야기 하는 바는 맞지만, 현업에서 이러한 밸런스가 잘 이루어질 수 있도록 하는 것이 쉬운 일이 아닌 것처럼 보인다.

프로젝트 규모가 작더라도 관리자는 처음부터 이런 일련의 문서를 공식화해두어야한다. 문서 하나하나를 준비하면서 생각의 초점이 모이고 논의가 명확해진다. 글로 적는 행위는 수백가지의 작은 의사결정이 필요하며 분명하고 정확한 정책이 모호한 정책과 구분되는 부분은 이러한 의사 결정의 존재 여부에서다.

역으로 생각하면, 글로 문서를 정리하지 못한다는 말은 이해를 제대로 못 했다는 방증이기도 하다. 그리고, 이후 인수인계를 생각하면 문서화는 필수적이다. 하지만 수고스럽다는 이유만으로 이를 등한시 하는 경우를 너무나도 많이 보았다. 사실, 남에게 설명해줄 만큼 문서 자체를 쓸줄 몰라서인 건 아닐까?

개발은 혼자 하는 것이 아니기에, 문서화와 같이 설계를 전달할 수 있는 능력은 개발자에게 있어 엄청나게 중요한 역량이라고 생각한다. 특히나 개발자들을 지휘할 아키텍처 설계자에게 있어 그 중요성은 두말할 필요가 없을 듯...

(기록물 가설) 오로지 글로 적을 때에만 빠진 곳이 나타나고 모순들이 드러난다. 글로 적는 행위에는 수백 가지의 작은 의사 결정이 필요하며, ... (중략) ... 결정된 내용을 그 문서를 통해 다른 이들에게 알릴 수 있기 때문이다.

이건 예전과 현재의 관점이 다르다.

• 모든 내용 공유하기: 팀 전체가 의사소통함으로서 사소한 오해 발생하는 걸 막을 수 있지만, 의사소통 비용 그 자체가 굉장히 비싸다.
• 제한된 인터페이스 등으로 설계와 구현 한정시키기 (정보의 차단): 효율적인 명세라면 "재앙"을 피하기에 충분할 것이며, 의사소통 비용의 절감 또한 확실하다.

OOP/은닉화가 대세가 된 요즘은 무조건 후자일 것이다. 다만, 후자를 하더라도 충분한 문서화는 필수이다. 최소한의 문서화는 최소한의 의사소통을 보장하니까... 특정 인터페이스를 어떻게 쓰느냐에 따라 성능에 큰 변화가 발생하게 된다던가...

(대규모 프로그래밍 프로젝트 내의 의사소통?) 워크북을 활용한다.

다른 선택지로 전화, 회의가 있었다. 전화와 같은 경우는 휘발성이라 기록이 제대로 남지가 않아서 프로그래밍과 같은 논리적인 의사소통을 하기에는 다소 부적합한 경험이 있었다. 주기적인 회의의 경우에는 수많은 사소한 오해들을 해결하는 데 있어 효과적이었다. 하지만 그 무엇보다도 워크북만큼 방대한 개발 자료를 서로에게 공유하는 데 있어 좋은 방안은 없는 것 같다.

소규모 프로그램에 대한 데이터를 프로그래밍 시스템 제품에 적용해서는 안 된다. ... (중략 ) ... 작업에 드는 노력이 프로그램 크기의 거듭제곱에 비례하여 늘어남을 시사한다.

개발 팀들이 실제 프로그래밍과 디버깅에 쓸 수 있었던 시간은 전체의 50% 밖에 되지 않았다.

개발 일정관리에서 흔히 놓치는 부분 중 하나라고 생각한다. "프로덕션이 작았을 때는 어렵지 않게 잘 됐는데, 어느 순간부터 생산성이 저하되는 것 같다"에 대한 답이 될 수 있을 것 같다. 물론, 비단 이것이 절대적인 요인은 아닐 것이지만 중대사항인 건 맞을 것이다

숙련공들은 평생에 모은 공구 세트를 갖추고 있으며, 조심스레 그것을 잠가두고 지킨다. 이 공구들은 그의 기량을 보여주는 증거인 셈이다. 프로그래머도 마찬가지로 편집기, 정렬 기법, 이진 덤프, 디스크 공간 관련 유틸리티 등을 자기 파일 속 어딘가에 몰래 숨겨둔다.
하지만 이런 접근 방식은 프로그래밍 프로젝트에서는 어리석은 짓이다. 근본적인 문제는 의사소통이고, 둘째로 환경이 변하기 때문에 도구의 수명은 길지 않다. 마지막으로 개개인보다는 다같이 도구를 유지보수하는 것이 더 낫다.
...(중략)...
프로젝트 관리자는 공용 도구 제작과 관련된 정책을 세우고 자원을 확보해 둘 필요가 있다.

이 부분을 간과하기 쉽다고 생각하는 것이, 해당 부분에 대한 정책이 없어도 그럭저럭 조직은 굴러가기 때문이라고 생각한다. 필요하면 필요한대로 현업에서는 어떻게든 방법을 찾아내어 이슈를 해결하게 된다. 그 흔적이 바로 숙련공의 "공구"가 되는 것이다.

하지만 의사소통의 문제는 치명적이다. 공구를 쓸줄 아는 사람이 그 숙련공 뿐이면, 대체불가인력처럼 되어 특정 문제 발생 시 그 숙련공에게 오롯이 부담이 전가되게 된다. 버티지 못하고 그 사람이 퇴사해 버리면 대 혼란이 벌어질 것이다.

관리자는 이러한 점을 잘 캐치할 수 있어야 한다고 생각한다. 그러한 점에서 어떻게 보면 bottom-up 방식의 커뮤니케이션이 필요한 부분이라는 생각이 들기도 한다. 물론, 위에서 도구에 대한 가이드까지 해 준다면 더할 나위 없이 좋겠지만...

저자는 오랫동안 프로그래머 후보들에게 "다음 11월은 어디 있는가?"라는 질문을 즐겨 해왔다. 질문이 너무 애매해서 이해하기 힘들다고 대꾸하면 "달력에 대한 당신의 정신적 모델에 대해서 말해보라"고 되묻는다. 정말 훌륭한 프로그래머는 뛰어난 공간 감각을 갖고 있으며, 대개 시간에 대한 자기 나름의 기하학적 모델을 갖고 있고, 설명하지 않아도 저자의 위 첫 질문을 잘 이해한다. 그들은 아주 개인적인 모델을 갖고 있다.

"설계 능력"에 대한 이야기이다. 무엇인가를 구현하기 위해 사용해야 하는 자료구조, 알고리즘부터 시작해서 큰 틀에서의 아키텍처까지 빠르게 떠올릴 수 있느냐의 능력이 중요하다. 필요하면 추가적인 조건을 확인해 나갈 수도 있어야 한다.

이러한 것들을 공간 내의 도표로 표현할 수 있을 것이라고 주장하였는데, 이는 소프트웨어의 개념적 구조가 위상기하학적인 성질을 가진다는 전제에서 비롯된 것이다. 위의 질문은 이를 테스트하고자 함이다. 이 방식 자체가 "은 탄환" 이라기보다는, 이런 기하학적 구조/구체화를 잘하는 사람들이 보통은 생산성이 몹시 좋은 느낌이었달까..?

뭔가 "기술 면접"의 추억이 떠오를 것만 같은... 그런 구절이었다.

사람들은 객체 지향이 설계의 한 종류라고 가르치면서 그에 따른 설계 원리를 알려주는 대신, 특정한 도구를 사용하는 것이 객체 지향이라고 가르쳐 왔습니다.

이 책이 개발 서적은 아니지만, 으레 개발서적 및 개발론에서 남용되고 있는 객체 지향에 대한 현실을 아주 잘 긁어주고 있다. 객체 지향이라는 "은 탄환"이 있어도, 개발자가 이를 쏠 줄 모르면 아무 쓸모가 없다.

"은 탄환"은 없다?

글쓴이는 이 책 전체에 걸쳐 흔히 퍼져있는 근거 없는 개발 관련 이야기들을 낱낱히 파헤쳐가며, 아주 강력하게 "은 탄환"은 없다고 주장하고 있다. 그리고 소프트웨어 개발 자체는 복잡성을 필연적으로 동반할 수밖에 없고, 복잡성에 대한 본질적인 해결책이 없기 때문에 더더욱 그렇다고 이야기하고 있다. 이는 사실이고, 실제로 해당 분야 전문가들과 "은 탄환은 없다"에 대한 논의가 지속적으로 이루어졌으며 절대적인 정답을 얻지 못한 것으로 보인다.

그래도 이 책에서 주장하는 본질적인 개발의 어려움이 아니라 부수적인 개발의 어려움에 대한 해결책마저도 제대로 이행하지 않고 있는 경우를 나는 너무 많이 봤다. "은 탄환"은 아니더라도, 당장 "놋쇠 탄환"이라도 쏴야 되는 경우가 부지기수였는데, 사실 우리한테 필요한 건 "놋쇠 탄환"이 아니었을까?

이러한 점에 비춰 본다면, 일반적인 소프트웨어의 개발에서의 효율성은 여전히 크게 오를 여지가 있다고 생각한다.

관리자라면 읽어봐야 할 책

생산성에 대해서 이상하다고 느끼고는 있었지만 잘 몰랐던 부분을 속시원히 긁어준 책이었다. 개발자나 관리자 말고도, 인사팀에서도 이 책은 읽어보는 게 좋을 것 같다.

단순 개발과 아키텍처 설계에 관한 지식을 쌓는데만 집중했지, 이런 책은 처음 읽어 보았다. 하지만 분명 중요한 내용이다. 본질적으로 우리는 프로젝트를 성공시키는 게 중요한 것이지, 훌륭한 기술적 접근과 같은 것이 반드시 필요한 건 아니기 때문이니까 인력 관리가 어떻게 보면 진정한 근본적 해결책일지도 모른다.

의외로 벤처나 스타트업에서 일하는 사람들이 읽으면 참 좋을 것 같다는 생각이 들었다. 회사의 특성상 업무 관련하여 대기업 대비 수많은 의사결정을 거쳐야 하는데, 경험이 부족하다면 최적의 정답을 찾기란 결코 쉬운 일이 아니다. 이 책에 담겨있는 풍부한 경험으로부터 많은 대답을 얻을 수 있을 것 같다.

고전인데도 여전히 많은 사람들 입에 오르내리는 이유가 있었다는 걸 다시금 느꼈다.

PS. 미리 적어두지만, 일부 구절은 다른 포스팅이나 검색 결과로부터 긁어온 것도 있습니다. 책을 읽으면서 동시에 쓴 포스팅이 아니라...