[독후감] 맨먼스 미신

 

저자: 프래드릭 브룩스 

책을 처음 받았을 때는 제목이 대체 무엇을 의미 하는가 ? 에 대한 궁금증이 가장 먼저 들었습니다. 저자인 프래드린 브룩스는 워낙 유명한 소프트웨어 공학자이며 , 책 자체가 워낙 유명했기 때문에 알고 있었는데도 , 막상 책의 마지막 챕터를 접었을 때 무릎을 탁 치지 않을 수 가 없었습니다.

어쩌면 이다지도 적절한 제목이란 말인가.

소프트웨어 개발에서 효율성의 기준으로 이야기되는 man 즉, 사람의 명수 , 그리고 month 얼마의 시간이 소요 되었는가 입니다.저 역시 당연히 어떤 것을 개발하거나 어떤 목적을 달성함에 있어 가장 빠르고, 가장 적은 인원수로 이룬 것이 가장 훌륭하고 효율적이고 경제적이라고 생각하는 맨먼스 이론에 대해서는 매우 동의하는 쪽이었습니다.하지만 이 책의 이름은 man-month 진리가 아니라 man-month mytgical (미신)이었습니다.그것이 저의 흥미를 끌었습니다.유명한 소프트웨어 공학자이며 IBM이라는 가장 유명한 컴퓨터 개발 회사 중 하나를 전두지휘했던 그가 왜 그 효율성에대해 회의적인 목소리를 높이고 있는가.

책의 16장은 그런 그가 가진 맨 먼스 이론에 대한 회의감과, 그것이 왜 비효율적이며 현실성이 떨어지는지를 조목조목 집어가고 있었습니다.중간 중간 그와 친한 다른 공학자들의 의견도 덧붙여 있어 같이 비교해보며 생각하고 읽을 수 있었던 것이 참 흥미로웠던 것 같습니다.소위 “브룩스 법칙”이라고 불리는 그의 이론은 ‘지체되는 개발 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐 이다’라는 말로 대변해 볼 수 있습니다.이를테면 우리가 논에 벼를 1명이 심는다고 했을 때 논의 면적이 1명이 10일쯤 걸려 다 심을 수 있다면 그것은 10명이 벼를 심는다면 하루가 걸린다. 는 다분히 단순계산적인 이론에 반기를 드는 것입니다.

소프트웨어 구축작업은 사람 수를 1명에서 10명으로 늘린다고 해서 하루 만에 끝날 수 없다. 월간 투입인력을 늘린다고 해서 일정이 줄어들 정도로 소프트웨어 개발은 그 성격이 다르다고 말합니다. 그 이유에 대해 소프트웨어의 다양한 특징들에 대해 기술하고 있습니다.그 유명한 늑대인간을 한 번에 죽일 수 있는 “은 총알” 이론이 이 부분입니다.

첫째, 하드웨어는 매우 빠르게 진보하고 있다. 하지만 소프트웨어 기술의 진보는 너무 어렵고 더디다.서로 같은 부분이 없이 기하급수적인 요소의 개수를 늘려가는 작업이므로 수학이나 과학문제처럼 단순화 시킬 수 없이 매우 복잡하다. 소프트웨어는 비선형적 복잡성을 띠고 있어 그 문제들을 한 번의 해결방법을 찾아내는 것으로 끝나는 법이 없다는 점

두 번째, 시시각각 달라지는 인터페이스를 반드시 순응해야 하는 인간조직의 관계 속에서 절충안을 찾아내기 매우 힘들다는 점

세 번째 , 소프트웨어는 시간과 공간, 그리고 사회 속에서 계속 변형되야 한다는 압박을 받고 한정된 비용과 시간 속에서 계속 변경될 수 있다는 비고정성.

네 번째, 설계도나 건축도면을 보여주는 것처럼 딱 한눈에 보이도록 구현할 수 없다는 비가시성과 그것이 야기하게 될 커뮤니케이션의 문제, 그리고 그로 인해 계속 지연되는 시간 등입니다.

여러 가지 이유를 들고 있지만 그가 말하는 소프트웨어 개발의 가장 큰 특성이자 문제점은 그 복잡성에 있습니다.하드웨어는 과학이나 수학식처럼 어떤 도식을 만들어냄으로 인해 나무의 기둥부분처럼 한 눈에 들어오게 구축할 수 있고 쉽게 변형되지 않지만 소프트웨어는 그 변경을 압박받으며 , 모든 개발자 집단 구성원들이 한 눈에 파악해 문제를 찾아내고 개선해서 개발할 수 있는 것이 아니라는 것입니다.이런 문제점들에 대한 주장은 읽는 내내 참 많이 공감이 가기도했지만 그만큼 아직 학생인 나에게는 말 그대로 비가시성, 눈에 쏙 들어오지 않는 추상적인 문제들에 가까웠습니다.그는 그런 소프트웨어의 특성을 기술하고 뒤이어 이 어려움들을 해결하기 위해 기존의 학자, 개발자들이 내놓았던 해결방안에 대해 꼬집고 있는데 이 부분을 읽으면서 그가 이 책을 통해 말하고자 하는 것이 대체 무엇인가? 에 대해 고민을 하며 읽어 내려간 기억이 납니다.

‘ 그는 긍정론자인가 부정론자인가? ‘

가장 성공한 소프트웨어 개발자 중 한명인 그는 소프트웨어 개발이 매우 어려우며 해결되지 않는 문제점 투성이 라고 말하는 것 같다는 느낌이 들었기 때문입니다.그가 말한 이 어려움을 해결하기 위해 나온 해결책은 크게 몇 가지입니다.

첫째, 고수준의 언어를 되도록 많이 사용하여 개발에 필요한 과정들을 단순화 시키는 것이다. 마치 수학의 많은 예제 문제들을 다 규합하여 규칙을 찾아내고 공식으로 외워 모든 사람들에게 교육시키는 것처럼 소프트웨어 개발에 자주 쓰이고, 필요한 것들을 단순화시켜 생산성과 신뢰성을 높이자는 주장.

두 번째, 개발을 긴 문장으로 기술하는 것이 아닌 시분할하여 즉시성을 보존하고 복잡성을 지속적으로 파악할 수 있게 하여 시간을 줄여 효율성을 높이자는 주장.

세 번째는 통합프로그래밍 환경을 만들어 다수의 프로그래밍을 동시에 해결 할 수 있도록 하여 시간적 효율성을 높이자는 주장 등이 있는데 그는 이런 기존의 해결노력에 대해 매우 부정적인 자세를 취하고 있습니다.

그런 해결제안들이 어느 정도 활용한다면 일시적으로 개발자들의 부담을 줄여줄 수 는 있겠지만 새로운 프로그램을 개발하는 것 자체의 시간과 인력적인 부담을 줄여주지도 않을뿐더러 , 그렇게 개발된 프로그램이 , 기존의 방식대로 다수의 인력이 시행착오를 거쳐 가며 심혈을 기울여 만든 프로그램에 비해 과연 더 높은 수준일까 ? 라는 것에 대한 회의감이라고 생각이 들었습니다.그리고 그것은 앞서서 말한 것처럼 소프트웨어의 가장 큰 특징 복잡성으로 귀결되는데, 하드웨어의 개발과는 달리 다양하고 혁신적인 개발이 필요한 소프트웨어 개발 분야에서 이런 수학적인 해결방안들은 그저 개발자들에게 한 두어 시간의 휴식시간을 주는 정도의 해결방안밖에 되지 않을 것이라는 말에는 매우 동의하게 됩니다.

그러면 그는 결국 부정론을 말하고 싶은 것인가 ?

그가 말하는 은　총알 이론에서 , 늑대인간을 한 번에 죽일 수 있는 은 총알이 없는 거라면 우리는 정말 그 총알에 대한 희망을 버린 체 그냥 많은 시간과 노동력을 투자하며 개발에 매진하는 수밖에 없는가 ?building not writing (작성하는 것이 아니라 구축하는 것이다)사실 이 챕터의 모든 부분을 통 털어 브룩스가 내놓은 해결방안 부분이 가장 술술 잘 읽혔고 매우 공감이 갔던 부분이었습니다.

기존의 소프트웨어 개발자(적어도 그가 살았던 1970년대~) 들은 무조건 많은 인력을 충원하여 머리를 맞대고 많은 시간을 투자하며 , 서로 내어놓은 개발안에 대해 발표하여 생각을 나누고 서로의 생각에 대해 반박 혹은 동의를 하고 절충안을 또 회의를 통해 내놓고 , 하나의 오류도 나오지 않기 위해 하나도 나오지 않기 위해 감금도니 것처럼 계속 개발하는 수밖에 없다고 생각했습니다.하지만 그것은 개발자 개개인에게도 너무나 힘든 고난 같은 시간이었고, 그들을 고용하고 일을 의뢰했을 기업 입장에서도 참 수지타산이 맞지 않는 작업일 수밖에 없습니다.저자도 말했던 것처럼 별다른 해결방안을 찾을 수 없었고, 몇 사람이 하는 것보다는 더 많은 사람을 충원해 빠른 시일 내에 개발해 상품화하여 매출을 올릴 방안만을 생각했기 때문에 그런 방법을 바꾸려 하지 않았던 것도 사실입니다.이런 기업의 입장은 1970년대에서 현재 2016년의 대기업, 중소기업에서도 여전히 바꾸려 하지 않는 문제점이기도 합니다.

언젠가 모 대기업의 시식 아르바이트를 간 적이 있었습니다.그 기업에서는 매년 새로운 음식과 과자, 각종 의식주 제품을 내놓는 회사인데, 새로 출시 예정인 제품이 정말 상품성이 있을지 , 문제점은 정말 없는지 알아보기 위해 매일 시식이나 시험 아르바이트와 좌담회를 열고 있는데 저로서는 아르바이트를 하기 위해 잠깐 참석했을 뿐이었지만 그 짧은 순간에, 참 많은 대기업운영방식에 대해 생각해 볼 수 있는 계기가 되었습니다.작은 간식 하나 개발하는데도 이미 그 회사는 다양한 포장지와 다양한 원료를 써서 비슷한 제품을 많이 개발하는데 많은 인력과 돈을 투자하였으며 , 또 그것을 출시하기 전에 몇 달에 걸쳐 매일 그렇게 시식, 시험을 열고 있습니었다.그런 시험을 위해 나 같은 아르바이트 고용에 쓰는 돈도 매우 많을 것이며 , 그 아르바이트 생을 고용하기 위해서는 또 다른 협력업체에 돈을 지불했을 것입니다.

그렇게 하나의 개발을 위해 수많은 사람들이 매달 긴 시간동안 수많은 시간과 비용을 투자하는 것입니다.결국 그 출시예정이라는 시식품은 아직도 출시된 것을 본 적이 없습니다.마치 , 그 일련의 과정들 중에 단 하나라도 성공적인 사례가 나오면 그 모든 것은 성공적인 업무였다고 말하겠지만, 이 얼마나 저자가 봤다면 무덤에서 벌떡 일어날 일이란 말입니까.그는 그런 비효율성과 문제점 해결을 위해 여러 가지 설명을 하고 있는데 그 해결방안은 다음과 같습니다.

첫째, 초기 구축을 하지마라. 기존의 다수의 사람들, 기업들이 내놓은 아주 좋은 소프트웨어들을 수집해서 그것을 연구해 복사하고 응용 가능성에 대해 논하는 것이 좋다.

두 번째, 그 복사한 것들을 다듬고 빠른 시제품을 내놓아 시험하라.완벽한 개발을 위해 시간과 인력을 낭비하는 것보다 , 출시 한 다음 시제품을 사용하는 고객들의 의견에 귀 기울이고 그 요구사항을 반복 추출하여 다듬어나가며 버그를 줄여 나가는 것이 훨씬 효율적이다.

세 번째, 개발은 복합적이라 완벽하게 구축될 수는 없다. 차근차근 점증적으로 개발하여 성장시켜라 .

네 번째 , 작성하는 자가 아니라 구축하는 자가 되어라 .( building not writing )

세 번째와 네 번째 해결방안 부분은 실제 21세기에 사는 우리가 느끼기에는 이미 정설처럼 소프트웨어 개발자들에게 이용되고 있는 방법이다.예를 들어 게임이 출시될 때도 , 시제품을 일단 출시하여 한정적이며 전문적인 시제품 체험단을 모집한 다음 그들에게 사용해 보도록 합니다.그리고 의견을 수렴하여 그것들을 토대로 수정해 나가며 몇 번에 걸쳐 버그를 줄여나가고 , 그렇게 어느 정도 완벽성을 갖췄다고 생각할 때 정식출시라는 발표가 납니다.우리가 아는 소프트웨어의 변혁을 이룬 거의 모든 기업들은 현재 이런 방식을 사용하고 있습니다. 그리고 시제품 시험이 다 끝났을 때를 기다리고 , 출시된 다음에는 고객들의 의견에 귀 기울여 나가며 또 수정과 보완을 거듭합니다.

브룩스이론처럼 , 그가 말하는 소수의 인재, 하나의 머리 밑에 단순노무를 담당할 다수의 하부구성원들만으로 소프트웨어 개발에 임하는 것은 그가 이 책을 처음 출간한 ,이후 시대가 변하면서 점점 현실화되고 있습니다 .그것이 이 책이 1970년대에 쓰여 졌음에도 불구하고 많은 사람들에게 바이블처럼 읽어야 하는 필독서로 평가받는 이유라고 생각이 들었습니다.하지만, 소수 혹은 하나의 설계자와 너무 명확하게 그의 업무를 돕는 구성원들의 능력을 단순노무에 한정시키는 느낌은 왠지 읽기 편한 부분은 아니었습니다.새로운 것을 창조하고 개발하는 것은 대단한 일이고, 모든 사람들이 그런 능력을 타고나는 것은 아니다. 하지만 어떤 분야의 일이든 비용과 효율성의 측면에서만 계산기처럼 업무를 처리해 나가는 것이 올바른 것이라고 생각하지는 않기 때문입니다.하지만 소프트웨어 개발의 어려움과 그 개선의 필요성에 대해 분석하고 이 계통에서 일하는 사람들이 이 책을 읽음으로서 그런 어려움에 대해 한번이라도 진지하게 생각해 볼 기회를 얻는다면 그것으로도 충분히 필수도서라고 불릴만한 가치는 있다는 생각도 들었습니다.

개발은 우리의 윤택한 삶을 위해 필요합니다.그러면 그 개발의 해택을 받으며 동시에 창조해야 하는 인간의 존재는 어디에서 의미를 찾을 수 있을까 ?에 대해 생각해 보게 하는 그런 책이었습니다.