Heart’s Develop Inside

새로운 개발을 진행하거나 유지보수 개발을 하게 되면 가장 먼저 나오는 이야기는 ‘인력 계산’ 일 것이다.
이 인력 계산으로 단가가 결정되고, 인력이 할당되며, 일정이 수립되기 때문이다.

개발자/PM이면 다들 아는 단위가 Man-Month이다.
말 그대로, 한 사람이 한 달을 일했을 때의 생산량을 의미하는 단어이다.

보편적으로 쓰는 단위가 이렇다보니 결국 인력 계산은 단순히 ‘n Man-Month’로 뭉뚱그려지기 마련이다.
특히 유지보수 개발은 더더욱…

하지만 개발자의 생산량 개인 편차는 상당한 차이가 있다.
보통 고급 인재가 일반 인재의 5배 정도 생산량이 있다는 이야기는 책이나 돌아다니는 이야기에서 어렵지 않게 접할 수 있다.
(스펙이나 경력에서 그다지 차이가 나 보이지 않는 경우에도 실제로는 두배 이상의 차이가 나는 경우도 많다.)

Man-Month는 그 점을 간과하는 단위이다. ‘일반적인’ 한 사람을 가상으로 세우는 것이다.
‘일반적인’ 한 사람을 가상으로 만들고 실제로 일할 사람의 생산량을 가상의 사람과 비교하여 그 비율을 곱해야 정상적인 Man-Month가 나오지만, 이 과정이 제대로 지켜지는 경우는 드물다.
보통은 산정하는 사람의 주관적인 기준이 작용하거나, 이른바 ‘갑’의 요구사항대로 쥐어짜는 경우가 다반사이다.
실제로 개발하는 사람에 따라 들쑥날쑥하다기 보다는 산정하는 사람의 기준에 맞춰진다는 게 아이러니이다.

근데, 이를 더 복잡하게 하는 것들이 있다. 바로 Man-Month에 사칙연산을 가하는 경우이다.

가령 9 to 6로 운영되는 회사에서 야근에 철야까지 고려해 Man-Month를 2로 나눠버리는 경우라던지, 2 Man-Month니까 두명 넣으면 2로 나눠서 1 Man-Month가 된다던지…

그냥 수학적으로 보면 일리가 있지만, 사실 이렇게 계산하는 것 자체가 말이 되지 않는다.
사이드 이펙트, 즉 부수효과가 전혀 고려되지 않았기 때문이다.

후자의 경우에는 Man-Month가 가지는 단점이 약간 더 커진다. 한 명을 ‘일반적인’ 기준과 맞춰야 하는 것이 아니라 두 명을 맞춰야 하니…
그래도 이건 조금 용인할 만 하다. Man-Month라는 단위를 쓴다면 어차피 감수해야 하는 것인데…

정말 위험한 계산은 전자의 경우이다.
바이오리듬이나 컨디션, 기타 등등 개발에 영향을 끼칠 수 있는 수많은 것들이 생산량에 포함되어 있다.
근데 하루 가용시간을 늘리면서 Man-Month를 줄일 때, 위와 같은 ‘중요한’ 요인들은 계산에서 제외되기 일쑤이다.

오래 머리를 쓰고 몸을 굴릴 수록 효율성은 급격히 떨어진다.(사람에 따라 그 시간의 격차가 있을 뿐이다.)
또한 사람의 컨디션을 회복하는 유일한 방법은 휴식뿐이다.
전자의 경우 이 두 가지 중요한 사실이 무시되는 것이다.
사람이 로봇이 아닌 이상은 저 계산은 언제나 틀리다.

하루에 8시간씩 공부하던 사람에게 억지로 16시간을 공부시킨다고 그 사람이 공부를 두배 더 잘하게 될 것이라고 생각하는 사람은 없다. 효율성을 생각하기 때문이다.
IT 개발 또한 머리를 쓰는 일이기 때문에 효율성이 중요함은 당연한 이야기이다.

Man-Month를 수식인 양 계산하는 것은 그만큼의 효율성도 가져오지 못할 것은 물론 장기적으로 사람을 지치게 만들어 회의감에 따른 생산량 하락 또는 심한 경우 전직을 유발할 수 있다.
(국내 개발자에 대한 분위기, 또는 시선이 극도로 좋지 못한 첫번째 이유가 이것이라고 생각한다.)

단기적인 안보다는 장기적인 혜안을 바라보고 Man-Month 쥐어짜기가 사라지는 그 날이 오길 이 나라의 개발자로써 빌어 마지 않는다.