악순환의 프로젝트

대략적으로 만들어야 하는 제품을 기준으로 각 구성요소들을 단순 무식하게 계산하여 약 400 M/M 사이즈 프로젝트가 있다고 하자.

1인당 1달 유지비를 1천만원(유지비에는 월급, 행정 처리, 프로젝트 진행 잡비 등등)으로 잡는다고 했을 때, 이 프로젝트는 최소한 40억은 있어야 한다. 그 외에는 별개로 이익 5% 까지 계산하면, 42억 정도 잡힌다.

24개월 기준으로 보면 최소 16명이 있어야 되며, 16명이 24개월 정도 업무를 수행해야 한다. 그런데, 이 M/M에는 함정이 있다. 바로 인력의 개개별의 능력이나 속도 그 외 업무에 대한 이해도 따위는 전혀 없다.

다행히 1~2명은 사업에 대한 이해나, 관련 기술의 이해가 있다고 치다.

문제는 주변인이다. 많게 쳐서 4명이 잘 안다고 해도, 16 명 중 4명 빼면 12명이 있는데, 이 사람들은 이 사업에 대한 이해에서 부터 기술이 전무하다고 하면 아주 진행이 웃기게 된다.

자.. 이것이 한국형 계산법이다.

그런데 한국에서는 저 40억이라고 하면 무척 많은 금액이라고 한다. 그러니 자연스럽게 400 M/M이 걸리는 작업을 마구 후려쳐서 200 M/M으로 계산한다. 즉 40억을 20억으로 줄인다. 상도덕 적으로 40억을 20억으로 줄였으니 전체적인 업무를 줄여야 하는데, 또 그렇지가 않다. 즉 400 M/M짜리를 금액만 200M/M 으로 줄이게 된다.

이와 같은 형태가 되면 어떻게 될까? 그나마 16명으로 어떻게든 유지해보려는 프로젝트는 8명이 해야 되고, 일은 2배가 된다. 인력이 마구 투입된다고 자연스럽게 흘러가지도 않겠지만, 그렇다고 무턱대고 줄이면, 그 나머지 업무를 결국 개개인에게 쏠리게 된다.

이게 야근의 원리다.

결국 전체적인 프로젝트의 퀄리티는 저하될 수 밖에 없고, 개발자는 자연스럽게 허덕이고 야근하고 개발을 하게 된다.

그런데 저 사이즈의 프로젝트가 되게 되면 자연스럽게 개발과는 상관 없는 사업관리 조직이 생긴다. 줄어든 금액에서 또 쪼개 쪼개서 사업관리를 하게 된다. 금액의 절약은 다시 개발자에게 얹어지게 되고, 개발자는 더 많은 일을 할 수 밖에 없는 구조가 계속 진행되게 된다.

이렇게 만들어 놓고 많은 금액을 투입했으니, 넉넉한 기간을 주었으니 잘 만들어 달라고 한다.

?