맨먼스(M/M)란? 개발 공수를 계산하는 방법과 쓸 때 주의할 점

외주 견적서를 받거나 개발 일정표를 짜다 보면 "이 작업은 3 M/M 정도 잡겠습니다" 같은 말이 꼭 나옵니다. 처음 들으면 무슨 단위인지 감이 안 오는데, 뜻은 간단합니다. 사람 한 명이 한 달 동안 일해서 처리할 수 있는 작업량. 이걸 맨먼스(Man-Month)라고 부르고 줄여서 M/M이라고 씁니다.

단위는 시간 길이에 따라 나뉩니다

같은 개념을 기간만 바꿔서 여러 단위로 씁니다.

계산은 "사람 수 × 기간"입니다. 혼자 10달 걸리는 일이면 10 M/M이고, 두 명이 다섯 달 하는 일도 똑같이 10 M/M으로 셉니다. 한 사람이 열흘 일하는 분량은 주 5일 기준으로 2 M/W, 한 달을 근무일 20일 정도로 보면 0.5 M/M입니다. M/W는 실제로는 잘 안 쓰고, 큰 프로젝트는 M/M, 작은 기능 단위는 M/D로 말하는 경우가 대부분입니다.

여기서 헷갈리기 쉬운 게 "한 달"의 정의입니다. 달력상 30일인지, 근무일 기준인지, 하루를 몇 시간으로 보는지에 따라 같은 1 M/M이라도 실제 시간이 달라집니다. 견적을 주고받을 때는 이 기준을 문서에 한 줄이라도 적어 두는 게 나중에 정산할 때 다툼을 줄입니다.

공수를 잡을 때 쓰는 방식

저는 보통 작업을 화면이나 기능 단위로 잘게 쪼갠 다음, 각각을 M/D로 추정하고 그걸 합쳐서 M/M으로 올립니다. 처음부터 "이 프로젝트는 대충 3개월"이라고 통으로 잡으면 빠지는 작업이 반드시 생깁니다. 로그인, 권한, 엑셀 내보내기, 관리자 화면 같은 건 기획서에는 한 줄인데 실제로는 며칠씩 잡아먹는 대표적인 항목입니다.

여러 명이 일하는 팀이라면 사람별 공수를 더해 전체 작업량을 보고, 그 합계를 기준으로 누구에게 어떤 일을 얼마나 줄지 나눕니다. 진행 중에 어떤 모듈이 예상보다 오래 걸리면, 해당 부분의 공수를 늘려 다시 잡고 다른 작업에서 사람을 빼 오거나 범위를 줄이는 식으로 일정을 맞춥니다. 숫자로 정리돼 있으면 이런 조정 논의가 감이 아니라 근거를 가지고 진행됩니다.

사람을 늘리면 기간이 줄어드나

M/M의 함정이 바로 여기 있습니다. 10 M/M짜리 일을 열 명이 하면 한 달에 끝날 것 같지만 현실은 그렇지 않습니다. 사람이 늘어나면 서로 맞춰야 할 일, 설명해야 할 일, 코드가 부딪히는 일이 함께 늘어납니다. 이미 늦어진 프로젝트에 인원을 더 넣으면 오히려 더 늦어진다는 말이 있을 정도인데, 프레더릭 브룩스가 쓴 책 『맨먼스 미신(The Mythical Man-Month)』이 이 문제를 다룬 고전입니다.

같은 1 M/M이라도 일의 성격에 따라 무게가 다르다는 점도 기억해야 합니다. 기존 화면을 복사해서 항목만 바꾸는 반복 작업과, 처음 보는 외부 API를 붙이면서 원인 모를 오류를 잡는 작업은 같은 한 달이라도 결과물 양이 전혀 다릅니다. 개발자 역량에 따라서도 차이가 크고요. 그래서 공수를 추정할 때는 작업 난이도와 맡을 사람을 같이 놓고 보는 게 맞습니다.

M/M은 일정과 비용을 이야기하기 위한 공통 언어 정도로 쓰는 게 적당합니다. 숫자를 확정된 사실처럼 다루기보다는, 처음 추정치와 실제 소요를 기록해 두었다가 다음 견적 때 보정 근거로 쓰면 추정이 점점 정확해집니다.