맨먼스(Man-Month, M/M)는 개발자 한 명이 한 달 동안 일하는 분량을 1로 놓고 프로젝트에 필요한 일의 총량을 세는 단위예요. 한국어로는 인월(人月)이라고 쓰고, 계산식은 투입 인원 수 × 투입 개월 수라는 곱셈 하나가 전부예요. 견적서에 "5 M/M"이라고 적혀 있으면 한 명이 다섯 달 붙는 분량, 또는 다섯 명이 한 달 붙는 분량이라는 뜻이에요. 정의는 여기서 끝나요. 정작 어려운 건 그 5라는 숫자가 타당한지 판정하는 일이고, 이 글은 정의가 아니라 그 판정 절차를 다뤄요.
개발팀이 없는 상태에서 견적서를 받으면 보이는 건 M/M 총합과 금액뿐이에요. 그 숫자가 어디서 나왔는지는 보이지 않죠. 그런데 맨먼스는 원래 결과값이에요. 기능 목록이 있고, 각 기능의 난이도 판단이 있고, 어떤 등급의 인력을 몇 명 붙일지가 정해진 다음에야 곱셈과 덧셈의 끝에서 나오는 숫자예요. 그러니 발주자가 할 일은 우리 총합을 다른 회사 총합과 나란히 놓고 싼 쪽을 고르는 게 아니라, 총합을 만들어낸 재료를 요구해서 한 줄씩 되짚는 것이에요. 아래 순서대로 하면 개발 경험이 없어도 검증할 수 있어요.
맨먼스는 일의 크기를 사람과 시간의 곱으로 환산한 단위예요. 1 M/M은 한 사람이 한 달 동안 온전히 그 프로젝트에만 붙어 있는 상태를 말해요. 3명이 4개월이면 12 M/M이 되고, 6명이 2개월이어도 12 M/M이 돼요. 곱만 같으면 같은 숫자가 나오는 구조라서, 견적서 위에서는 두 계획이 완전히 똑같아 보여요.
이 단위가 널리 쓰이는 이유는 예산을 짜는 쪽의 편의 때문이에요. 인력 한 명의 월 단가가 정해져 있으면 M/M에 단가를 곱해 총액이 바로 나오거든요. 공공 조달과 대형 SI에서 이 방식이 자리를 잡았고, 민간 외주 견적서도 그 표기를 그대로 물려받았어요. 즉 맨먼스는 일의 어려움을 재는 단위가 아니라 돈을 계산하기 편한 단위예요. 이 차이가 뒤에 나올 왜곡의 출발점이에요.
한 가지 먼저 확인해야 할 게 있어요. 1 M/M이 몇 시간인지는 회사마다 정의가 달라요. 월 근무일을 20일로 볼지 22일로 볼지, 하루를 8시간으로 볼지가 견적서에 안 적혀 있으면 같은 1 M/M도 실제 투입 시간이 달라져요. 견적서를 받자마자 "1 M/M의 기준 근무일과 기준 시간이 어떻게 되나요"라고 물어보세요. 이 질문에 바로 답이 오는지 아닌지가 첫 번째 신호예요.
완전히 같지는 않아요. 인월은 맨먼스의 한국어 표기라서 같은 말이 맞아요. 반면 공수(工數)는 더 넓은 말이에요. 공수는 "이 일에 들어가는 작업량"이라는 뜻이고, 그 작업량을 세는 단위가 맨먼스일 수도 있고 맨데이일 수도 있어요. 그래서 "공수 계산"이라고 하면 단위를 정하기 전 단계의 작업량 산정을 가리키기도 해요.
| 용어 | 표기 | 세는 것 | 견적서에서 보이는 자리 |
|---|---|---|---|
| 맨먼스 | M/M | 한 사람이 한 달 일하는 분량 | 총합, 역할별 투입 계획 |
| 인월 | 인월, 人月 | 맨먼스와 동일 | 공공 조달 문서, 국문 견적서 |
| 맨데이 | M/D | 한 사람이 하루 일하는 분량 | 기능별 세부 산정, 추가 작업 단가 |
| 맨아워 | M/H | 한 사람이 한 시간 일하는 분량 | 유지보수 시간제 정산 |
| 공수 | 공수 | 작업량 자체(단위 미정) | 산정 근거 문서, WBS |
실무에서 중요한 건 어느 단위로 적혀 있느냐가 아니라 단위 사이 환산 규칙이 문서에 있느냐예요. 개발 단계는 M/M으로 적고 추가 요청은 M/D로 정산하는 견적서가 있는데, 1 M/M이 몇 M/D인지가 어디에도 없으면 나중에 추가 비용을 다툴 때 기준이 없어요. 환산 기준을 견적서 각주에라도 넣어달라고 요청하세요.
같은 "5 M/M"이라는 표기 뒤에 서로 다른 세 가지가 숨어 있을 수 있어요. 그래서 총합만 놓고 두 견적서를 비교하면 비교가 성립하지 않아요.
총합이 작은 견적서가 싼 견적서가 아니라 범위가 좁은 견적서일 수 있다는 뜻이에요. 그러니 M/M 총합을 비교하기 전에 "이 숫자에 포함된 역할이 무엇이고 빠진 역할이 무엇인가"를 먼저 표로 받아야 해요. 견적서의 다른 항목들은 어떤 순서로 읽어야 하는지도 같이 보면 어느 칸이 비어 있는지 눈에 들어와요.
아래 표가 이 글의 본체예요. 받은 견적서를 옆에 놓고 위에서부터 한 줄씩 통과 여부를 표시하세요. 개발 지식 없이도 판정할 수 있게 질문을 구성했어요.
| 단계 | 확인 질문 | 통과 신호 | 위험 신호 |
|---|---|---|---|
| 1. 분해 | 총 M/M이 기능 단위로 쪼개져 있나요 | 기능 목록마다 개별 공수가 붙어 있어요 | "개발 5 M/M"처럼 한 줄로 뭉쳐 있어요 |
| 2. 역할 | 어떤 역할이 몇 M/M인지 나뉘어 있나요 | PM, 기획, 디자인, 개발, QA가 분리돼 있어요 | 역할 구분 없이 인원 수만 적혀 있어요 |
| 3. 등급 | 인력 등급별 투입량이 적혀 있나요 | 등급별 M/M과 그 등급이 맡을 일이 함께 있어요 | 등급 표기는 있는데 누가 무엇을 하는지 없어요 |
| 4. 가정 | 산정의 전제와 제외 범위가 문서에 있나요 | "이 견적은 A를 전제하고 B는 제외" 문장이 있어요 | 전제가 없어서 나중에 전부 추가 항목이 돼요 |
| 5. 일정 | M/M이 실제 달력 위에 배치되나요 | 월별 투입 인원표와 일정표가 맞아떨어져요 | 총합만 있고 언제 누가 붙는지 모르겠어요 |
| 6. 검수 | 그 공수의 결과물을 무엇으로 확인하나요 | 단계별 산출물과 검수 기준이 명시돼 있어요 | "개발 완료" 외에 확인할 물건이 없어요 |
여섯 줄 가운데 여러 줄에서 위험 신호가 나오면, 그 견적서는 아직 견적이 아니라 어림값이에요. 금액을 깎아달라고 하기 전에 위 여섯 항목을 채워서 다시 달라고 요청하는 게 순서예요. 이 요청 자체가 상대의 역량을 보는 시험이기도 해요. 실제로 산정한 곳은 재료를 갖고 있어서 며칠 안에 채워 오고, 감으로 적은 곳은 이 단계에서 답이 늦어져요.
총합은 검증 대상이 아니라 검증 결과라서 그래요. 5라는 숫자만 놓고는 많은지 적은지 판단할 방법이 없어요. 하지만 회원 가입, 결제 연동, 관리자 화면처럼 기능마다 공수가 따로 붙어 있으면 발주자도 판단할 수 있어요. 결제 연동에 붙은 공수가 관리자 화면보다 큰 이유를 물을 수 있고, 우리가 쓰지 않을 기능에 공수가 붙어 있으면 그 줄을 지울 수 있거든요.
이 분해가 가능하려면 기능이 문서로 확정돼 있어야 해요. 기능 목록이 말로만 오간 상태에서 나온 M/M은 상대가 머릿속으로 상상한 제품의 공수예요. 그 상상이 우리 머릿속 제품과 같을 이유가 없죠. 기능을 어디까지 문서로 적어야 공수가 나오는지와 요구사항을 어떤 형식으로 정리해야 하는지를 먼저 맞춰두면, 견적 단계의 다툼이 줄어들어요.
순서를 정리하면 이래요. 요구사항 정의가 있어야 기능 목록이 나오고, 기능 목록이 있어야 기능별 공수가 나오고, 기능별 공수를 더해야 총 M/M이 나와요. 이 사슬 중 앞쪽이 비어 있는데 뒤쪽 숫자만 있는 견적서는 거꾸로 만들어진 견적서예요. 총액을 먼저 정하고 M/M을 역산한 경우가 여기 해당해요.
등급은 같은 1 M/M에 서로 다른 단가를 곱하기 위한 구분이에요. 경력이 긴 개발자와 짧은 개발자의 한 달이 같은 값일 수는 없으니, 등급을 나눠 단가를 다르게 매기는 거예요. 그래서 견적서에서 진짜 금액을 움직이는 건 총 M/M이 아니라 등급별 M/M 배분인 경우가 있어요. 총합은 그대로인데 고급 인력 비중만 올려도 금액이 달라지거든요.
단가의 기준으로는 한국소프트웨어산업협회가 해마다 공표하는 소프트웨어기술자 평균임금을 참조하는 곳들이 있어요. 공공 사업 예산 산정에서 오래 쓰인 방식이라 민간 견적서도 이 표를 근거로 드는 경우가 있죠. 다만 이 공표값은 해마다 갱신되고, 등급을 나누는 방식과 직무 구분도 시기에 따라 바뀌어 왔어요. 그래서 금액 자체보다 "어느 해의 어떤 기준표를 참조했는지"를 문서로 받는 게 실질적인 검증이에요.
| 확인 항목 | 물어볼 질문 | 왜 중요한가요 |
|---|---|---|
| 기준 출처 | 단가는 어떤 기준표를 참조했나요 | 참조 문서가 없으면 단가가 협상 결과일 뿐이에요 |
| 기준 연도 | 몇 년도 공표값인가요 | 해마다 갱신되므로 연도가 없으면 대조가 안 돼요 |
| 등급 배분 | 등급별로 몇 M/M씩 투입되나요 | 총합이 같아도 배분이 다르면 금액이 달라져요 |
| 담당 업무 | 고급 인력은 구체적으로 무엇을 맡나요 | 서류상 등급과 실제 업무가 어긋나는 걸 막아요 |
| 인력 교체 | 투입 인력이 바뀌면 어떤 절차를 밟나요 | 등급이 낮은 인력으로 조용히 바뀌는 걸 막아요 |
| 기준 근무 | 1 M/M의 기준 근무일과 시간은 얼마인가요 | 같은 M/M도 실제 투입 시간이 달라져요 |
등급 항목에서 가장 실질적인 조항은 인력 교체 조항이에요. 계약 시점에 고급 인력으로 산정해 금액을 받고, 착수 후에 다른 사람이 투입되는 상황을 막으려면 투입 인력의 이름과 등급을 계약 부속 문서에 넣고 교체 시 사전 통보와 동등 등급 보장을 적어두면 돼요.
맨먼스에는 눈에 잘 안 띄는 가정이 하나 들어 있어요. 사람과 시간이 서로 교환 가능하다는 가정이에요. 12 M/M이라는 표기는 3명이 4개월이든 6명이 2개월이든 같은 일이라고 말해요. 하지만 소프트웨어를 만드는 일에서는 이 교환이 성립하지 않는 구간이 있어요.
인원이 늘면 서로 맞춰야 할 대화 경로가 함께 늘어나요. 인원이 n명일 때 두 사람씩 짝지어지는 경로는 n(n-1)/2개예요. 인원이 늘어나는 속도보다 경로가 늘어나는 속도가 빨라요. 게다가 새로 합류한 사람은 프로젝트 맥락을 익히는 동안 생산에 기여하지 못하고, 기존 인원의 시간을 가져가요. 그래서 늦어진 프로젝트에 사람을 더 넣는 결정이 오히려 일정을 더 밀어내는 상황이 생겨요.
두 번째 왜곡은 파는 대상이 결과물이 아니라 투입이라는 점이에요. 맨먼스 계약에서 수행사의 매출은 투입한 사람과 기간에 비례해요. 일을 빨리 끝내면 매출이 줄어드는 구조라서, 효율을 높일 동기가 계약 자체에 들어 있지 않아요. 이건 상대의 도덕성 문제가 아니라 계약 구조가 만드는 방향이에요. 그래서 맨먼스 계약을 고를 때는 결과물을 무엇으로 확인할지를 따로 못 박아야 해요.
세 번째는 난이도가 사라진다는 점이에요. 결제 연동 1 M/M과 공지사항 목록 1 M/M은 견적서에서 같은 무게로 보이지만, 실패했을 때의 결과가 전혀 달라요. 하나는 돈이 잘못 빠져나가고 하나는 화면이 안 예뻐요. 총합만 보는 검토는 이 차이를 못 봐요. 그래서 기능별 공수표를 받았다면 공수가 큰 순서가 아니라 실패했을 때 위험한 순서로도 한 번 읽어보세요.
견적서에 "6명 2개월"이라고 적혀 있으면 그 6명이 동시에 할 일이 실제로 있는지 확인해야 해요. 다음 상황에서는 인원을 늘려도 기간이 줄지 않아요.
그래서 M/M 총합 옆에는 반드시 월별 투입 인원표가 붙어야 해요. 1개월 차에 몇 명, 2개월 차에 몇 명이 붙고 그때 무엇을 하는지가 적혀 있어야 총합이 달력 위에서 말이 되는지 볼 수 있어요. 투입 계획이 일정표에서 앞뒤가 맞는지 어떻게 확인하는지를 참고해서, 앞 단계가 안 끝났는데 뒷 작업 인원이 이미 투입돼 있는 구간을 찾아보세요. 그런 구간이 보이면 그 인원의 공수는 실제로는 대기 시간이에요.
다음 다섯 가지를 요청하면 어림값에 가깝던 견적서가 검증 가능한 견적서로 바뀌어요. 요청은 이메일 한 통이면 충분하고, 이 목록 그대로 보내도 돼요.
이 다섯 가지를 여러 곳에 같은 형식으로 요구하려면 요청 문서 자체를 통일해야 해요. 각자 다른 양식으로 답이 오면 다시 비교가 안 되거든요. 여러 곳에서 같은 기준의 견적을 받으려면 무엇을 보내야 하는지를 보고 요청서 틀을 먼저 만들어 두면, 받은 답변을 표 하나에 나란히 올릴 수 있어요.
맨먼스 계약은 투입한 인력과 기간에 따라 대금을 지급하는 방식이에요. 고정가 계약은 정해진 범위의 결과물을 정해진 금액에 인도하는 방식이고요. 같은 프로젝트라도 어느 쪽을 고르느냐에 따라 위험이 누구에게 가는지가 완전히 달라져요.
| 항목 | 맨먼스 계약(투입형) | 고정가 계약(도급형) |
|---|---|---|
| 대금 기준 | 실제 투입된 인력과 기간 | 합의된 범위의 결과물 |
| 범위 변경 | 공수를 추가하면 처리돼요 | 변경 계약이나 CR 절차가 필요해요 |
| 초과 위험 | 발주자가 부담해요 | 수행사가 부담해요 |
| 총액 예측 | 상한을 안 걸면 예측이 어려워요 | 계약 시점에 확정돼요 |
| 범위 요건 | 범위가 유동적이어도 시작할 수 있어요 | 범위가 문서로 확정돼야 해요 |
| 발주자 부담 | 진행 관리와 우선순위 결정이 계속 필요해요 | 착수 전 문서 작업이 무거워요 |
| 숨은 비용 | 대기 시간도 공수로 청구될 수 있어요 | 범위 밖 요청이 모두 추가 견적이 돼요 |
선택 기준은 간단해요. 무엇을 만들지가 문서로 확정됐으면 고정가가 유리해요. 위험을 수행사가 지고, 우리는 총액을 미리 알 수 있으니까요. 반대로 탐색이 필요해서 범위가 계속 바뀔 게 분명하면 맨먼스가 현실적이에요. 확정되지 않은 범위에 고정가를 씌우면 수행사가 위험분을 금액에 얹거나, 착수 후 모든 요청이 추가 견적으로 돌아와요.
실무에서는 두 방식을 섞기도 해요. 요구사항이 흐릿한 초기 구간만 맨먼스로 짧게 끊어 정의를 마치고, 범위가 잡힌 뒤 본 개발을 고정가로 계약하는 형태예요. 맨먼스로 가더라도 총 M/M 상한을 계약서에 넣고, 상한에 닿기 전에 알리는 의무를 적으면 총액 예측 불가라는 약점이 줄어들어요.
맨먼스 계약은 투입을 사는 계약이라서, 결과물을 확인하는 장치를 계약서가 따로 갖고 있어야 해요. 다음 항목들이 빠져 있으면 협상 단계에서 넣어달라고 요청하세요.
이 중 공수 보고는 언급되지 않은 채 계약이 넘어가기도 해요. 보고가 없으면 청구서에 적힌 M/M이 맞는지 확인할 방법이 없어요. 그리고 계약서에는 넣지 말아야 할 문장도 있어요. 계약서에서 먼저 지워야 할 조항이 무엇인지를 확인해서, 검수 없이 자동 완료되는 조항이나 권리 귀속이 모호한 문장이 남아 있지 않은지 보세요. 대금은 한 번에 주지 말고 어느 시점에 나눠 지급해야 하는지에 맞춰 단계별로 끊는 편이 안전해요.
맨먼스 계약의 약점은 돈을 시간에 지급한다는 데 있어요. 그래서 그 시간이 물건으로 바뀌었는지 확인하는 장치를 발주자가 따로 갖고 있어야 해요. 확인의 근거는 세 가지예요.
이 확인을 매달 몰아서 하면 늦어요. 주기를 짧게 잡고 진행 상황을 2주 단위로 확인하는 방법대로 돌리면, 어긋남을 한 구간 안에서 잡을 수 있어요. 그리고 각 구간의 완료 판정 기준은 미리 합의해 둬야 해요. 무엇을 받아야 그 구간의 공수를 인정할 수 있는지를 착수 전에 정해두면, 완료 여부를 감정으로 다투지 않게 돼요.
추가 공수 요청이 오면 먼저 둘 중 어느 쪽인지를 갈라야 해요. 원인이 다르면 부담하는 쪽도 달라지거든요.
| 구분 | 무슨 상황인가요 | 확인할 것 | 비용 부담 |
|---|---|---|---|
| 범위 변경 | 계약 시점에 없던 요구가 새로 생겼어요 | 원래 범위 문서에 그 항목이 있었는지요 | 발주자 부담이 원칙이에요 |
| 추정 오차 | 범위는 그대로인데 처음 산정이 부족했어요 | 산정 근거 문서와 무엇이 달랐는지요 | 계약 형태에 따라 갈려요 |
| 전제 붕괴 | 견적이 전제한 조건이 실제와 달랐어요 | 가정 목록에 그 전제가 적혀 있었는지요 | 가정을 문서에 적었는지가 기준이에요 |
| 대기 발생 | 우리 쪽 결정이 늦어 인력이 놀았어요 | 지연 기록과 요청 이력이요 | 발주자 책임인 구간이 있어요 |
이 구분을 말로 하면 매번 싸움이 되니 절차로 만들어 두는 게 좋아요. 범위가 바뀔 때 어떤 절차를 밟아야 하는지에 맞춰 변경 요청서를 쓰게 하면, 추가 M/M이 무엇 때문에 왜 얼마나 필요한지가 문서로 남아요. 일정이 밀리는 경우도 같아요. 일정 지연을 계약서로 어떻게 다루는지를 참고해 지연 통지 의무와 회복 계획 제출을 조항으로 두면, 공수만 늘고 일정은 그대로인 상황을 줄일 수 있어요.
개발이 끝나면 공수의 성격이 바뀌어요. 개발 단계의 M/M은 만들 것이 정해진 일에 붙지만, 유지보수의 M/M은 언제 올지 모르는 일에 붙어요. 그래서 같은 단위로 적혀 있어도 계약 방식이 달라져야 해요.
세 방식 모두 무상 하자보수 기간과 유상 유지보수의 경계를 문서로 그어둬야 해요. 만들다 만 것을 고치는 일과 새로 요청하는 일이 섞이면, 하자보수 기간에 유지보수 공수가 청구되거나 반대로 정당한 추가 요청이 하자로 몰려요. 개발이 끝난 뒤 유지보수 비용을 어떻게 잡는지를 개발 계약 협상 때 함께 정해두면, 인수인계 시점에 협상력이 없는 상태로 조건을 받아들이는 일을 피할 수 있어요.
마지막으로 받은 견적서를 앞에 놓고 아래 항목을 순서대로 표시해 보세요. 답이 안 나오는 줄이 그 견적서의 빈칸이고, 그 빈칸이 나중에 추가 비용이나 분쟁으로 돌아올 자리예요.
이 열네 줄을 다 채우기 전에는 금액 협상을 시작하지 않는 편이 좋아요. 빈칸이 남은 상태에서 깎은 금액은 나중에 추가 항목으로 되돌아오거든요. 웹사이트나 홈페이지처럼 비용 구조가 비교적 정형화된 프로젝트라면 비용이 어떤 요소로 결정되는지를 먼저 훑어보고 이 체크리스트를 적용하면 판단이 더 빨라져요.
정리하면 이래요. 맨먼스는 어려운 개념이 아니라 곱셈 하나예요. 하지만 그 곱셈에 들어가는 재료를 보지 않으면 결과값만 보게 되고, 결과값만으로는 아무것도 판정할 수 없어요. 발주자가 가진 가장 강한 도구는 개발 지식이 아니라 재료를 요구하는 질문이에요. 위 질문들을 순서대로 던지는 것만으로 견적서의 품질이 달라지고, 그 과정에서 상대가 실제로 산정을 했는지 아닌지도 드러나요.
1 M/M을 몇 M/D로 볼지는 회사마다 기준이 달라요. 월 근무일을 20일로 잡는 곳도 있고 22일로 잡는 곳도 있어서, 환산 규칙이 문서에 없으면 추가 작업을 M/D로 정산할 때 기준이 사라져요. 견적서 각주에 1 M/M이 몇 M/D인지 명시해 달라고 요청하고, 계약서의 추가 작업 단가 조항이 같은 기준을 쓰는지 확인하세요.
정해진 표준값은 없어요. 월 근무일과 일 근무시간을 곱해 계산하는데 그 두 값을 회사가 각자 정하기 때문에, 같은 1 M/M도 실제 투입 시간이 달라져요. 그래서 시간 자체보다 이 견적서가 쓰는 기준 근무일과 기준 시간을 문서로 받아 두는 게 중요해요. 기준이 서로 다르면 두 견적서의 M/M은 애초에 비교 대상이 아니에요.
문제라기보다 확인이 필요한 신호예요. 개발 공수 안에 포함된 것인지 아예 범위 밖인지에 따라 총액이 달라지거든요. 포함이라면 역할별로 몇 M/M인지 쪼개 달라고 하고, 범위 밖이라면 그 일을 누가 할지 정해야 해요. 발주자가 직접 하기로 했다면 우리 쪽에서 쓰는 시간도 프로젝트 비용이라는 걸 계산에 넣으세요.
한국소프트웨어산업협회가 해마다 소프트웨어기술자 평균임금을 공표하고, 이 값을 단가 기준으로 참조하는 곳들이 있어요. 다만 공표값은 해마다 갱신되고 등급과 직무를 나누는 방식도 바뀌어 왔기 때문에, 금액을 외우기보다 견적서가 어느 해의 어떤 기준표를 참조했는지 문서로 받아 대조하는 편이 정확해요.
계산 구조는 같아요. 다만 회사와 계약할 때 단가에 녹아 있던 PM, QA, 인프라, 대체 인력 같은 부분이 빠지기 때문에 그 일을 누가 할지 발주자가 직접 정해야 해요. 단가만 비교하면 싸 보이지만, 빠진 역할을 채우는 시간과 사람이 이탈했을 때의 공백까지 넣고 비교해야 같은 조건이 돼요.
계산기는 인원과 기간과 단가를 곱해 주는 도구라서, 넣은 값이 틀리면 결과도 틀려요. 기능 목록과 난이도 판단이 없는 상태에서 나온 총합은 계산 결과가 아니라 짐작이에요. 계산기는 이미 산정된 공수를 금액으로 바꿔 볼 때 쓰고, 공수 자체는 기능 단위로 쪼갠 근거 문서에서 나와야 해요.