같은 SI 제안, 두 PM.
A는 발주사가 "이거 얼마면 됩니까"라고 묻자, 화면 수와 감(感)으로 "대략 5억이요"라고 답합니다. 수주 후 막상 일을 쪼개 보니 중급 개발자 2명이 더 필요합니다. 적자입니다.
B는 같은 질문에 바로 답하지 않습니다. WBS로 일을 쪼개고, 각 작업에 필요한 인력의 등급과 투입 개월을 매겨 M/M을 합산하고, 등급별 단가를 곱한 뒤, 직접비·간접비·예비비를 더해 견적을 만듭니다. "고급 1명 6개월, 중급 3명 6개월, 초급 2명 4개월 — 총 26 M/M, 직접인건비 OO원에 예비비 8%를 더한 5억 2천입니다." 근거가 있으니 협상에서도 밀리지 않습니다.
둘의 차이는 배짱이 아니라 공수를 숫자로 만드는 능력입니다. 한국 SI에서 이 숫자의 단위가 바로 **M/M(Man-Month)**입니다. 이 모듈은 원가를 추정하고, 자원을 계획하고, M/M으로 인력을 산정·정산하는 법을 다룹니다.
- 1상향식·유사·모수 추정의 차이를 설명하고, WBS 기반 상향식 추정이 왜 가장 정확한지 말할 수 있다
- 2직접비·간접비·예비비(우발·관리)를 구분하고 원가 항목 표를 구성할 수 있다
- 3자원 계획에서 인력·장비·라이선스를 나누어 식별할 수 있다
- 4M/M(Man-Month)의 정의와 계산법(인원 × 기간 × 투입률)을 설명할 수 있다
- 5등급별 단가·투입계획표·투입률을 활용해 인건비를 산정하고 정산 구조를 설명할 수 있다
원가는 '감'이 아니라 '쌓아 올리는 것'
추정에는 세 가지 방식이 있다
원가 추정의 출발은 "얼마면 되는가"에 근거를 붙이는 것입니다. 감으로 던진 숫자는 틀려도 왜 틀렸는지 알 수 없고, 수주 후 적자로 돌아옵니다. 추정 방식은 크게 셋입니다.
- 상향식(Bottom-up): WBS의 가장 작은 단위(작업 패키지)마다 필요한 공수·비용을 추정하고 위로 합산합니다. 가장 정확하지만 WBS가 완성돼 있어야 하고 시간이 많이 듭니다. 그래서 이 모듈의 선수 학습이 WBS입니다.
- 유사(Analogous): 과거 비슷한 프로젝트의 실제 실적을 가져와 빠르게 잡습니다. 정보가 적은 초기·제안 단계에서 빠르지만 정확도는 낮습니다.
- 모수(Parametric): '화면 1개당 3 M/D', '인터페이스 1건당 5 M/D'처럼 단위 원단위 × 수량으로 계산합니다. 통계적 근거가 있으면 빠르면서도 꽤 정확합니다.
| 방식 | 근거 | 정확도 | 속도 | 언제 쓰나 |
|---|---|---|---|---|
| 상향식 | WBS 작업 패키지별 추정 합산 | 높음 | 느림 | 착수 후 상세 계획, 최종 견적 |
| 유사 | 과거 유사 프로젝트 실적 | 낮음 | 빠름 | 제안 초기, 정보 부족 시 |
| 모수 | 단위당 원단위 × 수량 | 중~높음 | 빠름 | 산출물 규모를 셀 수 있을 때 |
실무에서는 제안 단계엔 유사·모수로 빠르게 잡고, 수주 후 WBS가 나오면 상향식으로 정밀화하는 혼합이 일반적입니다.
원가 항목 — 어디에 돈이 나가는가
직접비·간접비·예비비를 나눈다
추정한 숫자를 견적으로 만들려면 돈이 나가는 항목을 빠짐없이 분류해야 합니다. 한 곳이라도 빠지면 그만큼 적자입니다.
- 직접비(Direct cost): 이 프로젝트에 직접 귀속되는 비용. 가장 큰 덩어리는 인건비(M/M × 단가)이고, 그 외 프로젝트 전용 장비·소프트웨어 라이선스·출장비 등이 들어갑니다.
- 간접비(Indirect cost): 여러 프로젝트가 나눠 쓰는 비용. 사무실 임대료, 공통 관리 인력, 전기·통신, 회사 운영 경비 등으로, 보통 직접비에 일정 비율(간접비율)을 곱해 배부합니다.
- 예비비(Reserve): 불확실성에 대비하는 돈. 두 종류를 반드시 구분합니다.
- 우발 예비비(Contingency): 식별·분석된 리스크(known-unknowns)가 실제 발생했을 때 쓰는 돈. 리스크 분석에 근거해 산정하고 PM이 통제합니다.
- 관리 예비비(Management): 전혀 예측 못 한(unknown-unknowns) 상황용. 경영진이 별도로 잡아 둡니다.
| 항목 | 분류 | 예시 | 산정 방식 |
|---|---|---|---|
| 인건비 | 직접비 | 개발·설계 인력 M/M | M/M × 등급 단가 |
| 장비·라이선스 | 직접비 | 프로젝트 전용 서버, DB 라이선스 | 견적·실비 |
| 출장·경비 | 직접비 | 발주사 상주 교통·숙박 | 실비 추정 |
| 공통 관리비 | 간접비 | 사무실·관리인력·운영경비 | 직접비 × 간접비율 |
| 우발 예비비 | 예비비 | 식별된 리스크 발생 대비 | 리스크 분석 기반(예: 직접비의 N%) |
| 관리 예비비 | 예비비 | 미식별 리스크 대비 | 경영진 별도 책정 |
원가 = 직접비 + 간접비 + 예비비. 여기에 회사의 이윤(마진)을 더하면 발주사에 제시하는 견적가가 됩니다.
자원 계획 — 사람만이 아니다
인력·장비·라이선스를 함께 본다
원가의 대부분은 인건비지만, 자원 계획은 사람만 보는 게 아닙니다. 일정 어느 시점에 무엇이 필요한지를 함께 그려야 합니다.
- 인력(Human): 역할·등급별로 몇 명이, 언제부터 언제까지, 얼마의 투입률로 필요한가. 이것이 곧 M/M 산정의 입력입니다.
- 장비(Equipment): 개발·테스트 서버, 단말, 네트워크 회선. 구매인지 임대인지, 언제 입고돼야 일정이 안 밀리는지.
- 라이선스(License): 상용 DB, WAS, 보안 솔루션, 형상관리·이슈관리 도구. 동시 사용자 수 기준인지 코어 기준인지에 따라 비용이 크게 달라집니다.
자원 계획의 핵심은 시점입니다. "총 26 M/M"만으로는 부족합니다. 설계 단계엔 고급 설계자가 몰리고, 구현 단계엔 개발자가 몰리고, 안정화 단계엔 줄어드는 시간에 따른 분포가 있어야 채용·투입·비용 흐름을 통제할 수 있습니다. 이 분포를 표로 만든 것이 바로 다음에 볼 투입계획표입니다.

M/M(Man-Month) — 한국 SI 견적의 기본 단위
사람 × 시간을 하나의 숫자로
M/M(Man-Month) 은 '인력 1명이 1개월 동안 풀타임으로 투입되는 작업량'을 1로 보는 공수 단위입니다. 한국 SI 견적·계약·정산이 모두 이 단위로 움직입니다.
기본 계산:
- 1명이 1개월 풀타임 → 1 M/M
- 2명이 3개월 풀타임 → 2 × 3 = 6 M/M
- 1명이 6개월간 투입률 50% → 1 × 6 × 0.5 = 3 M/M
핵심은 M/M이 인원 수도, 기간도, 비용도 아니라 '사람 × 시간'의 양이라는 점입니다. 같은 6 M/M이라도 '6명 1개월'과 '1명 6개월'은 일정·리스크가 완전히 다릅니다(전자는 인력 확보가, 후자는 기간이 부담). 더 작은 단위로 M/D(Man-Day, 사람 1명의 하루)도 쓰며, 보통 1 M/M ≈ 20 M/D로 환산합니다.
인건비는 여기에 등급별 단가를 곱해 나옵니다. 등급은 보통 초급·중급·고급·특급으로 나뉘고, 등급이 올라갈수록 단가가 높습니다(숙련도·경력 기준). 정부·공공 SI에서는 'SW기술자 평균임금' 공표값을 단가 산정의 기준으로 삼는 관행이 있습니다.
| 등급 | 대략적 기준 | 월 단가(예시) | 의미 |
|---|---|---|---|
| 초급 | 경력 3년 미만 | 낮음 | 지시받아 구현 |
| 중급 | 경력 3~6년 | 중간 | 모듈 단위 독립 수행 |
| 고급 | 경력 6~10년 | 높음 | 설계·리딩 |
| 특급 | 경력 10년 이상 | 가장 높음 | 아키텍처·총괄 |
위 단가는 절대 수치가 아니라 상대적 크기만 보여주는 예시입니다. 실제 단가는 매년 공표되는 기준과 회사·계약에 따라 달라집니다.
총 인건비 = Σ(등급별 M/M × 등급별 단가). 이 합이 직접비의 핵심이고, 견적의 뼈대입니다.

그림: M/M(인원×개월×투입률)에 등급별 단가를 곱해 인건비를 쌓고, 직접비·간접비·예비비·이윤을 더해 견적가를 만든다 — 비용은 인원 수가 아니라 등급×M/M의 문제다.
직접 해보기 — M/M 투입계획과 원가 산정
가상의 6개월 SI 프로젝트입니다. 아래 인력 구성으로 (1) 각 인력의 M/M을 계산하고, (2) 총 M/M을 구한 뒤, (3) 등급별 단가를 곱해 직접인건비를 추정해 보세요. 단가는 비교를 위한 상대값(단위: 백만 원/월)으로 가정합니다 — 특급 10, 고급 8, 중급 6, 초급 4.
투입계획표(역할·등급·기간·투입률):
역할 등급 기간(개월) 투입률 M/M
PM 특급 6 50% ?
아키텍트 고급 4 100% ?
백엔드 개발 중급 6 100% ?
백엔드 개발 중급 6 100% ?
프론트 개발 초급 4 100% ?
QA 초급 2 100% ?
각 행의 M/M = 기간 × 투입률로 계산하고, 등급별로 M/M을 모아 단가를 곱한 뒤 모두 더하면 직접인건비가 나옵니다. 우발 예비비로 직접인건비의 8%를 추가해 보세요. 정답과 풀이는 아래 ObserveBlock에 있습니다.
M/M = 인원 × 투입 개월 × 투입률- PM(특급): 6개월 × 50% = 3.0 M/M
- 아키텍트(고급): 4개월 × 100% = 4.0 M/M
- 백엔드 개발 2명(중급): 각 6.0 M/M → 합 12.0 M/M
- 프론트 개발(초급): 4개월 × 100% = 4.0 M/M
- QA(초급): 2개월 × 100% = 2.0 M/M
- 총 M/M = 3 + 4 + 12 + 4 + 2 = 25.0 M/M
- 등급별 인건비(단가 × M/M): 특급 10×3=30, 고급 8×4=32, 중급 6×12=72, 초급 4×(4+2)=24 → 직접인건비 합 158(백만 원)
- 우발 예비비 8% = 약 12.6 → 인건비+예비비 ≈ 170.6(백만 원). 여기에 장비·라이선스·간접비·이윤을 더하면 견적가가 된다
- 핵심 감각: 같은 25 M/M이라도 등급 분포가 달라지면 비용이 크게 바뀐다 — 산정은 "인원 수"가 아니라 "등급 × M/M"의 문제다
현장에서 자주 보는 함정
증상: 계약은 '총 25 M/M'으로 맺었습니다. 그런데 프로젝트 중반, 발주사가 "실제로 몇 M/M 투입됐는지 증빙을 달라"고 합니다. PM은 "사람은 다 들어왔다"고 하는데, 막상 따져 보니 어떤 개발자는 다른 프로젝트와 겸임해 절반만 일했고, 어떤 인력은 두 달 늦게 합류했습니다. 청구한 M/M과 실제 투입 M/M이 안 맞아 정산 분쟁이 납니다.
원인: 견적의 M/M은 '계획값'인데, 정산의 M/M은 '실제 투입값'입니다. 둘을 잇는 것이 투입률 × 실제 투입 기간인데, 이를 인력별·월별로 기록하지 않았습니다. 투입률 50% 인력을 100%로 청구하면 과청구이고, 합류가 늦은 인력을 처음부터 청구하면 역시 안 맞습니다.
해결 방향(실무 표준):
- 투입계획표를 인력별 × 월별 투입률 매트릭스로 관리하고, 매월 실제 투입 실적을 갱신한다.
- 정산 M/M = Σ(인력별 실제 투입 개월 × 실제 투입률). 계획과 실제의 차이를 매월 추적해 조기에 협의한다.
- 투입·철수 시점, 겸임 여부, 투입확인서(발주사 확인) 같은 증빙을 남겨 분쟁을 예방한다.
- 인력 교체가 생기면 등급을 맞추거나 단가 차이를 정산에 반영한다(고급 → 중급 교체 시 비용·품질 모두 영향).
M/M은 견적을 만드는 숫자이자 정산을 끝내는 숫자입니다. 계획값만 있고 실제값 기록이 없으면, 견적이 아무리 정교해도 끝에서 무너집니다.
한국 SI/SM 현장에서 PM·PMO·사업관리자의 핵심 업무 중 하나가 바로 이 M/M 산정과 투입관리입니다. 제안 단계에서는 발주사의 RFP를 보고 "이 일은 몇 M/M짜리인가"를 등급별로 끊어 견적을 만들고, 수주 후에는 투입계획표대로 인력이 들어오는지, 투입률이 계획과 맞는지를 매월 관리합니다.
이 자리에서 당신은 직접 코딩하지 않더라도, 협력사(하도급) 인력의 등급·단가·투입률·투입확인서를 검토하고, 계획 대비 실제 투입을 추적해 원가를 통제합니다. 특급이라고 청구된 인력이 실제로는 중급 수준인지, 투입률 100%로 잡힌 인력이 다른 현장과 겸임하는지를 보는 눈이 곧 적자를 막는 능력입니다.
공공 SI에서는 'SW기술자 평균임금' 같은 공표 기준이 단가 산정·정산의 근거가 되므로, 그 기준을 알고 견적에 반영하는 것도 관리자의 몫입니다. 기술을 아는 관리자는 협력사가 부풀린 M/M을 잡아내고, 반대로 정당한 공수는 지켜 줍니다 — 그래야 다음 프로젝트도 같이 합니다.
관련 모듈로 더 깊이:
- WBS와 일정 관리 — M/M 산정의 토대가 되는 작업분해와 일정
- 계약·과업범위·M/M·검수 — 계약·과업범위에서 M/M와 검수가 묶이는 구조
- 리스크와 이슈 관리 — 투입률·단가 추정을 위협하는 원가 리스크를 다루는 법
다음 모듈에서는 이렇게 산정한 원가와 일정을 위협하는 불확실성을 어떻게 다루는지 — 프로젝트의 리스크와 이슈 관리를 정리합니다.