예산이 먼저 정해졌다면 범위를 어떻게 잡을까요

먼저 짧게 답부터 드릴게요. 예산이 이미 정해진 프로젝트는 견적을 받아서 깎는 순서가 아니라, 예산을 사람·기간(MM)으로 먼저 바꾸고 그 안에 들어갈 기능을 고르는 순서가 맞아요. 2026년 적용 공표 임금 기준으로 응용SW개발자 월 평균임금은 775만 원이고, 여기에 업계 관행 마진을 얹으면 실제 외주 단가는 1MM당 약 930만～1,160만 원으로 추정돼요(추정치예요). 이 숫자로 나눠 보면 우리 예산이 몇 사람·몇 달인지가 바로 나와요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“예산은 5,000만 원인데, 업체마다 견적이 3,000만 원에서 1억 원까지 와요. 뭘 믿어야 하죠?”

상담에서 가장 자주 듣는 말이에요. 그런데 이 상황의 원인은 업체가 아니라 순서에 있는 경우가 많아요. 범위를 확정하지 않은 채 견적을 받으면, 업체마다 서로 다른 범위를 상상하고 금액을 적거든요. 예산이 이미 정해져 있다면 순서를 뒤집는 게 훨씬 빨라요.

---

1. 왜 견적을 먼저 받으면 안 될까요

견적서를 세 장 받아서 비교하면 정보가 늘어날 것 같지만, 실제로는 판단이 더 어려워져요. 세 장이 같은 것을 재고 있지 않기 때문이에요.

같은 요구사항 문서를 줘도 업체마다 이렇게 갈려요.

• A사는 기획·디자인을 포함해서 적어요
• B사는 개발만 적고 기획은 “고객사 제공”으로 둬요
• C사는 QA(품질 검증)와 3개월 안정화를 포함해요

세 장의 금액 차이가 곧 실력 차이나 바가지가 아니라, 포함 범위의 차이인 거죠. 여기서 가장 싼 곳을 고르면 빠진 항목이 나중에 추가 비용으로 돌아와요. 이건 저가 견적의 함정에서 반복해서 보는 구조예요.

예산이 정해져 있다면 반대로 가세요. “이 돈으로 무엇이 가능한가”를 먼저 계산하고, 그 범위를 문서로 만들어서 업체에 주는 것이 순서예요. 그러면 세 장의 견적이 같은 것을 재게 돼요.

2. 예산을 MM으로 바꾸면 무엇이 보이나요

용어 박스 — MM(맨먼스, Man-Month) 개발자 1명이 1개월 일하는 양을 1MM이라고 불러요. 개발자 3명이 4개월 일하면 12MM이에요. 견적서의 총액은 대개 투입 MM × 월 단가로 만들어져요. 실무에선 “이 프로젝트 몇 MM짜리예요?”라고 규모를 가늠할 때 써요.

예산을 MM으로 바꾸는 계산은 어렵지 않아요. 기준이 될 단가만 있으면 돼요.

공식 외부 기준 — 2026년 적용 SW기술자 평균임금 (한국소프트웨어산업협회 공표)

직무	월평균임금
응용SW개발자	775만 원
IT아키텍트	1,110만 원
IT기획자	1,185만 원
전체 일평균	41만 4,762원 (전년 대비 4.7% 상승)

위 표는 공표 자료 그대로예요. 저희 실거래 단가가 아니에요.

자사 실무 기준 예시 — 예산을 MM으로 환산할 때 저희가 쓰는 어림값 (추정)

예산(VAT 별도)	환산 MM(추정)	현실적인 팀 구성 예
3,000만 원	약 2.6～3.2MM	개발 1명 3개월, 기획·디자인은 최소한으로
5,000만 원	약 4.3～5.4MM	개발 2명 2개월 + 기획·디자인 일부
8,000만 원	약 6.9～8.6MM	개발 2명 3개월 + 기획·디자인·QA
1억 원	약 8.6～10.8MM	개발 2～3명 3～4개월 + 기획·디자인·QA·PM

환산에 쓴 단가는 공표 임금 775만 원에 업계 관행 마진 1.2～1.5배를 얹은 930만～1,160만 원이에요. 관행 마진은 공식 통계가 아니라 시장에서 통용되는 범위라 추정치로 봐 주세요.

여기서 중요한 건 정확한 숫자가 아니에요. “5,000만 원은 개발자 두 명이 두 달 남짓 일하는 돈”이라는 감각이 생기는 것이 핵심이에요. 이 감각이 있으면 기능 목록을 보면서 “이건 두 달에 안 들어가겠네”를 스스로 판단할 수 있어요.

3. MM에서 기능 목록으로 어떻게 넘어가나요

환산된 MM이 나왔다면, 그 안에 들어갈 기능을 고르는 단계예요. 저희는 기능을 세 칸으로 나누기를 권해요.

1. 없으면 서비스가 성립하지 않는 것 — 회원 가입과 로그인, 핵심 업무 화면 하나, 결제가 필수면 결제
2. 있으면 좋지만 없어도 운영은 되는 것 — 통계 화면, 알림, 관리자 편의 기능
3. 2차에 붙여도 되는 것 — 다국어, 외부 시스템 연동, 권한 세분화

경험상 1번만 추려도 처음 목록의 절반쯤으로 줄어요. 그리고 줄어든 절반이 곧 남은 예산이에요.

여기서 한 가지 주의할 점이 있어요. 2번과 3번을 빼는 건 괜찮은데, 관리자 화면을 통째로 빼는 선택은 대개 손해예요. 관리자 화면이 없으면 운영 중에 데이터를 고칠 때마다 개발사에 요청해야 하고, 그 요청은 유지보수 비용으로 청구되거든요. 자세한 판단 기준은 관리자 페이지의 비용 차이에 정리해 뒀어요.

4. 예산 역산이 잘 맞는 프로젝트는 무엇일까요

모든 프로젝트에 이 방식이 잘 맞진 않아요. 저희 경험상 이렇게 갈려요.

잘 맞는 경우

• 내부 업무용 시스템처럼 사용자가 정해져 있는 프로젝트
• 설비 데이터를 받아 기록하는 측정 프로그램 외주 개발처럼 기능 경계가 뚜렷한 프로젝트
• 이미 쓰고 있는 시스템을 개선하는 프로젝트

잘 안 맞는 경우

• 외부 시스템과의 연동이 많아 상대방 사정에 일정이 걸리는 프로젝트
• 정확도 요구가 높아 검증에 시간이 얼마나 걸릴지 모르는 프로젝트
• 사용자 수가 예측되지 않아 성능 요구가 열려 있는 프로젝트

두 번째 그룹은 예산을 고정하더라도 1차를 ‘검증 단계’로 따로 떼는 편이 안전해요. 작게 만들어 보고 나서 본 개발 범위를 정하는 거죠. MVP와 PoC의 차이와 예산 잡는 법에서 그 단계 구분을 다뤘어요.

5. 업체에는 무엇을 주고 무엇을 물어야 할까요

범위를 정했다면 업체에 이렇게 주세요.

• 예산 범위 (숨기지 않는 편이 결과가 좋아요)
• 1차에 반드시 들어가야 하는 기능 목록
• 2차로 미룬 기능 목록 (있다는 사실만 알려줘도 구조 설계가 달라져요)
• 원하는 오픈 시점

그리고 이렇게 물어보세요.

1. 이 범위가 말씀드린 예산 안에 들어가나요? 안 들어간다면 어디가 넘치나요?
2. 이 예산에서 기획·디자인·QA는 포함인가요, 별도인가요?
3. 2차로 미룬 기능을 나중에 붙일 때 구조를 다시 짜야 하나요?

3번 질문이 의외로 갈라요. 1차만 보고 짠 구조와, 2차를 알고 짠 구조는 다르거든요. 나중에 붙일 때 다시 짜야 한다면 그건 2차 비용에 이미 들어가 있는 셈이에요.

운영사 Tip 예산을 알려주면 그 금액에 맞춰 견적이 올라간다고 걱정하시는 분이 많아요. 저희가 보기엔 반대예요. 예산을 모르면 업체는 안전하게 크게 잡거나, 수주하려고 작게 잡아요. 둘 다 착수 후에 문제가 돼요. 예산을 알려주고 “이 안에서 뭘 뺄지 같이 정하자”고 하면 대화가 훨씬 빨라져요.

6. 예산 역산에서 자주 빠지는 비용은 무엇일까요

MM으로 환산할 때 개발비만 계산하면 예산이 모자라요. 저희가 실제로 자주 보는 누락 항목이에요.

항목	왜 빠지나요	어떻게 잡나요
서버·인프라 비용	개발비가 아니라서 견적서에 없어요	월 비용으로 따로 잡아요. 트래픽에 따라 달라져요
외부 서비스 이용료	결제·문자·지도 API는 쓰는 만큼 나가요	예상 사용량으로 월 비용을 계산해요
QA·테스트 기간	개발이 끝난 뒤 일이라 축소되기 쉬워요	개발 기간의 일정 비율로 미리 떼어 둬요
오픈 후 안정화	”다 만들었으면 끝” 이라고 생각하기 쉬워요	오픈 후 1～3개월을 계약에 포함해요
유지보수	1년 차 예산에 안 잡혀요	연간 운영비로 별도 항목을 만들어요

특히 마지막 두 줄이 중요해요. 저희는 자체 SaaS 4종을 직접 운영하고 있어서 오픈 직후가 가장 손이 많이 가는 시기라는 걸 매번 겪어요. 사용자가 실제로 쓰기 시작하면 예상 못 한 경로로 들어오고, 데이터도 예상과 다르게 쌓이거든요. 이 구간을 예산에 안 넣으면 그 비용은 결국 급하게 추가 계약으로 나가요.

7. 운영까지 보면 무엇이 달라질까요

예산 역산의 마지막 조정은 “1차에 넣을 기능”이 아니라 “1차에 넣을 구조”를 고르는 일이에요.

같은 예산이라도 이렇게 갈려요.

• 기능을 최대한 많이 넣는 선택 — 오픈 직후 보기엔 좋지만, 수정 요청이 들어올 때마다 손이 많이 가요
• 기능을 줄이고 구조에 여유를 두는 선택 — 처음엔 허전해 보여도 2차 개발 비용이 확실히 줄어요

저희는 같은 기능 수보다, 출시 후 얼마나 자주 수정될지부터 봐요. 하루에 한 번 보는 화면과 하루에 백 번 쓰는 화면은 같은 개발 시간을 써도 가치가 다르거든요. 예산이 빠듯할수록 자주 쓰는 쪽에 시간을 몰아주는 편이 3년 총비용에서 유리해요.

방향이 아직 명확하지 않아도 괜찮아요. 예산 금액만 알려주셔도 그 금액에서 현실적으로 가능한 범위를 함께 그려 볼 수 있어요. 견적서를 받기 전에 기준부터 잡고 싶으시다면 지금 예산으로 무엇이 가능한지 같이 계산해 볼까요 →

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논·코닥·KICT 같은 곳과도 함께해 왔고요. 그래서 납품 금액만이 아니라 그 뒤에 이어지는 운영 비용까지 같이 봐 드릴 수 있어요.

8. 자주 묻는 질문 (FAQ)

CRM 개발 비용은 유형 별로 얼마나 필요한가요?

CRM(고객관계관리 시스템)은 어디까지 직접 만드느냐에 따라 폭이 커요. 기존 솔루션을 쓰고 화면만 우리 업무에 맞추는 방식이면 상대적으로 작게 잡히고, 영업 파이프라인·자동화·외부 연동까지 직접 만들면 훨씬 커져요. 예산이 정해져 있다면 위 2번의 MM 환산부터 해 보시고, 그 범위에서 직접 만들지 솔루션을 쓸지를 먼저 정하시는 편이 빨라요.

기업을 위한 AI·Gen AI 개발 외주를 맡기려면 어떻게 해야 하나요?

AI 관련 프로젝트는 예산 역산 전에 연결할 시스템 목록부터 만들어야 해요. 모델 비용보다 기존 시스템에 붙이는 작업이 금액을 더 크게 움직이거든요. 그리고 1차는 되도록 검증 단계로 떼어 두세요. 검증에서 나온 결과로 본 개발 범위를 정하는 편이 예산을 지키는 데 유리해요.

개발 외주 플랫폼에서 업체를 찾는 것과 직접 연락하는 것, 어느 쪽이 나을까요?

둘 다 장단이 있어요. 개발 외주 플랫폼은 여러 곳을 한 번에 비교하기 좋지만, 범위가 정해지지 않은 상태에서 받은 견적은 비교가 어려워요. 그래서 “개발 외주 업체 추천해주세요”라고 묻기 전에 이 글의 1～3번을 먼저 끝내시길 권해요. 범위 문서가 있으면 어느 경로로 찾든 받은 견적을 나란히 놓고 비교할 수 있어요. 채널별 차이는 개발 업체는 어디서 찾는 게 맞을까요에 정리돼 있어요.