개발 외주 견적 방식 3가지, 어디서 돈이 새는지 비교했어요 | MM·시간제·고정가
개발 외주 견적서에는 MM(맨먼스), 시간제, 고정가 세 가지 방식이 섞여 있어요. 2026년 KOSA 노임단가가 응용SW 개발자 기준 12%대 오른 상황에서, 프로젝트 성격에 따라 어떤 방식이 맞는지 운영해본 개발사 기준으로 정리했어요.
개발 견적서에 적힌 MM·시간제·고정가는 어느 하나가 정답이 아니라 프로젝트 성격에 따라 맞는 방식이 달라요. 요구사항이 명확하면 고정가, 계속 바뀌는 프로젝트면 시간제나 MM이 낫고요. 실무에서는 핵심 기능은 고정가로 확정하고 이후 추가·유지보수는 시간제로 진행하는 혼합 방식도 흔해요. 직접 만들고 운영해본 개발사 기준으로 세 방식의 차이를 정리했어요.
“같은 프로젝트인데 어떤 곳은 견적서에 ‘MM’이라고만 써놨고, 어떤 곳은 총액 하나만 딱 적혀 있더라고요.” 발주 전 여러 곳에서 견적서를 받아본 분들이 자주 하는 말이에요. 표기 방식이 다르면 총액을 그대로 비교하기가 어려워져요. 소프트웨어 외주개발 견적을 볼 때 이 세 가지 방식부터 구분할 수 있으면, 견적서 읽는 시간이 훨씬 줄어들어요.
1. 개발 견적서에 낯선 단어부터 정리해볼까요
프로그램 개발 견적이 업체마다 다르게 보이는 이유 중 하나는, 애초에 산정 방식 자체가 다르기 때문이에요. 크게 세 가지예요.
- MM(맨먼스): 개발자 1명이 1개월 풀타임으로 투입되는 작업량 단위예요. ‘3MM’이면 1명이 3개월, 또는 3명이 1개월 일하는 분량이라는 뜻이에요.
- 시간제(T&M, Time & Material): 실제 투입된 시간만큼 정산하는 방식이에요.
- 고정가: 요구사항 명세를 기준으로 총액을 미리 확정하는 방식이에요.
2. MM(맨먼스) 방식, 언제 쓰나요
MM은 투입 인력 수와 월 단가를 곱해 총액을 계산해요. 요구사항이 확정되지 않았거나, 프로젝트 도중 기능이 계속 추가·변경될 가능성이 큰 경우에 자주 쓰여요. 발주자 입장에서는 “몇 명이 몇 개월 붙는지”가 투명하게 보인다는 장점이 있지만, 실제 산출물 대비 비용이 예상보다 늘어날 수 있다는 점은 감안해야 해요.
3. 시간제(T&M) 방식은 뭐가 다른가요
시간제는 MM보다 더 잘게 쪼갠 정산 방식이라고 보면 돼요. 유지보수나 기존 시스템 개선처럼 작업량을 미리 정확히 가늠하기 어려운 경우에 맞아요. 다만 종료 시점을 명확히 정해두지 않으면 총비용을 예측하기 어려워지니, 상한선이나 예상 범위를 계약서에 함께 적어두는 게 안전해요.
4. 고정가 방식은 항상 안전한 선택일까요
고정가는 요구사항 정의서(RFP, 제안요청서)를 기반으로 총액을 미리 확정하는 방식이에요. 발주자 입장에서는 예산이 명확해지는 큰 장점이 있어요. 다만 이 안전함은 요구사항이 얼마나 구체적으로 정의됐는지에 달려 있어요. 명세가 흐릿한 상태에서 고정가로 계약하면, 개발 도중 “이건 견적에 없던 범위”라는 이슈가 생기기 쉬워요.
5. 2026년 개발자 단가는 얼마쯤일까요
한국인공지능·소프트웨어산업협회(KOSA)가 공표한 2026년 적용 SW기술자 노임단가는 전년 대비 평균 4.7% 올랐고, 그중 응용SW 개발자는 12% 이상 상승했어요.
공식 외부 기준 — 2026 KOSA 노임단가(공표 기준)
| 구분 | 대략 수준 | 비고 |
|---|---|---|
| 응용SW 개발자 (월) | 2025년 대비 12%대 상승 | 공식 노임단가 |
| 응용SW 개발자 (시간) | 약 4만 7,000원대 | 공식 노임단가 환산 |
| IT 품질관리·테스터·감리 | 14%대 상승 | 검증 직군 강세 |
자사 실무 기준 — 견적서에서 확인하는 항목
| 항목 | 왜 중요한가요 |
|---|---|
| 산정 방식 표기 | MM·시간제·고정가 중 무엇인지 견적서에 명시돼 있나요 |
| 투입 등급 구성 | 초급·중급·고급·특급 인력 비율에 따라 단가가 달라져요 |
| 방식 혼합 여부 | 핵심 기능은 고정가, 추가 작업은 시간제인지 구분돼 있나요 |
공식 노임단가에 통상적인 마진(관행상 1.2～1.5배)을 더한 실제 외주 단가는 업체마다 차이가 커서 “추정” 범위로만 참고해주세요.
6. 우리 프로젝트엔 어떤 방식이 맞을까요
RFP(제안요청서)는 발주자가 원하는 기능·범위·일정을 문서로 정리한 것이에요. MVP(최소기능제품)는 핵심 기능만 먼저 만들어 검증하는 초기 버전을 말해요. 실무에선 “RFP 명확도가 낮으면 MVP부터 시간제로, 명확하면 고정가로 간다”는 식으로 함께 써요.
요구사항이 이미 문서로 정리돼 있고 범위 변경 가능성이 낮다면 고정가가 예산 관리에 유리해요. 반대로 시장 반응을 보며 기능을 계속 조정해야 하는 초기 서비스라면 MM이나 시간제가 더 현실적이에요. 운영사 Tip — 저희는 핵심 기능은 고정가로 범위를 확정하고, 출시 이후 유지보수나 추가 요청은 시간제로 진행하는 혼합 구조를 자주 권해요. 초기 예산은 지키면서도 이후 변화에 유연하게 대응할 수 있거든요.
7. 견적 방식과 상관없이 놓치기 쉬운 것들
- 개발외주계약서에 방식이 명시되지 않은 경우: 나중에 “이건 포함이었는지 별도였는지” 분쟁이 생기기 쉬워요.
- 저가 견적의 함정: 시장 평균보다 눈에 띄게 낮은 견적은 투입 등급을 낮추거나 QA·유지보수를 뺐을 가능성이 있어요.
- 범위 변경 시 정산 기준 부재: 프로젝트 도중 요구사항이 바뀌었을 때 어떤 방식으로 재산정할지 미리 정해두지 않으면 갈등의 씨앗이 돼요.
저희는 같은 기능 수보다, 출시 후 얼마나 자주 수정될지부터 봐요. 그래서 견적 방식을 정할 때도 초기 산정 값 자체보다, 변경이 생겼을 때 어떻게 처리할지를 먼저 확인해요.
8. 자주 묻는 질문
MM과 시간제, 결국 무엇이 더 저렴한가요?
방식 자체가 저렴함을 결정하지는 않아요. 요구사항이 안정적이면 고정가가, 변화가 잦으면 시간제·MM 혼합이 총비용을 오히려 줄이는 경우가 많아요.
견적서에 산정 방식이 안 적혀 있으면 어떻게 하나요?
먼저 물어보는 게 안전해요. 방식이 불명확한 견적서는 나중에 총액 근거를 확인하기 어려워질 수 있어요.
프로젝트 도중 방식을 바꿀 수도 있나요?
가능해요. 다만 변경 시점과 기준을 계약서에 미리 정해두는 편이 분쟁을 줄여요.
9. 정리하며
납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. 견적 방식도 마찬가지예요. 숫자 하나보다, 이후 변경이 생겼을 때 어떤 기준으로 다시 계산할지가 실제 비용을 좌우해요. 저희는 자체 SaaS 4종을 11년 넘게 직접 운영하며 이런 견적 구조를 수없이 마주해왔어요.
관련해서 함께 보면 좋은 글이에요.