개발 예산이 부족할 때 무엇부터 덜어낼까요 | 순서 7가지
견적이 예산을 넘었을 때 기능부터 자르면 대개 손해예요. 지원 범위와 디자인 방식을 먼저 조정하는 게 순서예요. MVP는 공개 시장 자료 기준 500만～3,000만 원대에서 시작해요. 덜어내는 순서 7가지와 줄이면 안 되는 3가지를 정리했어요.
견적서를 받았는데 예산보다 한참 높을 때, 대부분 기능 목록부터 열어요. 그런데 실제로 그 방식이 가장 손해인 경우가 많아요. 서비스 형태는 망가지는데 금액은 생각만큼 안 내려가거든요.
10년 넘게 발주 상담을 하면서 정리한 순서가 있어요. 무엇을 먼저 덜어내고 무엇을 끝까지 지켜야 하는지, 실제로 쓰는 기준으로 적어볼게요.
1. 예산이 부족하다는 건 보통 어떤 상황일까요
세 가지 중 하나예요.
첫째, 예산을 먼저 정하고 요구사항을 나중에 만든 경우. 가장 흔해요. 작년 예산 규모나 다른 회사 이야기를 기준으로 숫자를 잡아둔 뒤 요구사항이 붙으면서 벌어져요.
둘째, 요구사항이 커진 경우. 처음 생각보다 화면이 늘고 관리자 기능이 붙으면서 자연스럽게 올라간 상황이에요.
셋째, 견적에 그동안 안 보이던 항목이 들어온 경우. QA, 유지보수, 서버 구축처럼 예전 견적에는 없던 항목이 포함돼서 높아 보이는 거예요. 이건 사실 부족한 게 아니라 제대로 계산된 것에 가까워요.
세 번째라면 깎기 전에 항목부터 확인해보세요. 개발 견적서에서 어떤 항목이 빠지면 나중에 돈이 더 드는지를 보시면 판단이 빨라요.
2. 덜어내도 되는 것과 지켜야 하는 것
기준은 하나예요. 나중에 되돌릴 수 있으면 덜어내도 되고, 되돌리기 어려우면 지켜야 해요.
기능은 나중에 추가할 수 있어요. 화면도 나중에 예쁘게 만들 수 있고요. 반면 데이터 구조, 권한 체계, 서버 구성은 나중에 바꾸려면 이미 쌓인 데이터를 통째로 옮겨야 해서 훨씬 비싸져요.
| 성격 | 예시 | 판단 |
|---|---|---|
| 되돌리기 쉬움 | 부가 기능, 화면 꾸밈, 지원 기기 확대 | 나중으로 미뤄도 괜찮아요 |
| 되돌리기 어려움 | 데이터 구조, 권한 설계, 결제 흐름 | 지금 제대로 잡는 게 싸요 |
| 미루면 더 비쌈 | QA, 문서, 소스 인계 준비 | 줄이더라도 없애지 마세요 |
3. 덜어내는 순서 일곱 가지
위에서부터 차례로 검토하시면 돼요. 아래로 갈수록 손대기 부담스러운 항목이에요.
- 지원 범위 축소 — 지원 브라우저, 화면 크기, 기기 종류를 좁혀요. 개발량보다 검증량이 줄어서 효과가 커요.
- 디자인 방식 조정 — 전 화면 커스텀에서 핵심 화면만 커스텀으로 바꿔요.
- 관리자 기능 단순화 — 초기에는 데이터를 직접 조회하는 수준으로 두고 화면은 나중에 만들어요.
- 부가 기능 이월 — 통계, 알림, 내보내기처럼 없어도 서비스가 도는 기능을 2차로 넘겨요.
- 연동 대상 축소 — 외부 시스템 연동은 하나 줄일 때마다 검증 기간이 함께 줄어요.
- 오픈 범위 분할 — 전체를 한 번에 열지 않고 일부 사용자나 일부 지점으로 먼저 열어요.
- 핵심 기능 축소 — 여기까지 왔는데도 안 맞으면 서비스 정의 자체를 다시 봐야 해요.
7번에 도달했다면 예산 문제가 아니라 범위 설계 문제일 가능성이 커요. 이때는 깎기보다 다시 그리는 게 빨라요.
4. 기능을 고를 때 쓰는 질문
어떤 기능을 남길지 고민될 때 저희가 쓰는 질문은 두 개예요.
“이 기능이 없으면 사용자가 서비스를 끝까지 쓸 수 있나요?” 없으면 불편한 정도라면 2차로 넘겨도 돼요. 없으면 아예 진행이 막히면 남겨야 하고요.
“이 기능을 하루에 몇 번 쓰나요?” 월에 한 번 쓰는 기능은 처음엔 사람이 손으로 처리해도 돼요. 관리자 기능에서 특히 그래요. 정산이나 통계처럼 월 단위 작업은 개발 대신 파일로 받아 처리하다가, 손이 정말 아플 때 만드는 편이 낫습니다.
이 두 질문만 통과시켜도 초기 범위가 눈에 띄게 정리돼요. 공개 시장 자료 기준으로 MVP나 시범 구축은 500만 원에서 3,000만 원대에서 시작하는데, 이 범위 안에 들어오려면 대개 기능을 절반 이하로 줄여야 해요. MVP와 PoC의 예산 잡는 법에 유형별 기준을 정리해뒀어요.
5. 줄이면 나중에 더 비싸지는 항목
경험상 이 세 가지는 줄인 만큼 나중에 두 배로 돌아와요.
QA와 테스트. 결함은 늦게 발견될수록 고치는 비용이 커져요. 오픈 후에 발견하면 사용자 대응까지 함께 해야 하고요. 없애지 마시고 범위를 좁히세요. 결제와 로그인처럼 실패하면 치명적인 흐름만 집중해서 보는 방식이 현실적이에요.
문서와 인계 준비. 개발사가 바뀌거나 담당자가 나가면 그때부터 값이 매겨져요. 소스 구조와 배포 절차가 문서로 안 남으면 다음 사람이 코드를 읽는 데만 몇 달을 써요.
초기 데이터 설계. 나중에 통계를 보려고 했는데 기록이 안 쌓여 있으면 과거를 복구할 방법이 없어요. 화면은 나중에 만들어도 되지만 쌓이는 데이터는 지금부터 쌓여야 해요.
6. 단계로 쪼갤 때의 실제 방법
단계 분할은 예산 부족의 가장 실용적인 답이에요. 다만 그냥 반으로 자르면 안 돼요.
1차에 넣을 것 — 사용자가 처음부터 끝까지 한 바퀴 돌 수 있는 최소한의 흐름. 가입해서 원하는 걸 하고 나가는 경로가 끊기지 않아야 해요.
2차로 미룰 것 — 그 경로를 편하게 만들어주는 기능들. 검색 필터, 알림, 통계, 대량 처리 같은 것들이에요.
계약할 때 2차 범위를 지금 확정하지 않는다는 점을 명시해두시면 좋아요. 1차를 오픈하고 실제 사용 데이터를 본 뒤에 정하는 게 목적이니까요. 미리 확정하면 단계로 나눈 의미가 사라져요.
3년 기준으로 총비용이 어떻게 움직이는지는 개발 외주 3년 총비용 정리에서 따로 다뤘어요.
7. 개발사에 어떻게 이야기하면 좋을까요
“예산이 이만큼인데 맞춰주실 수 있나요”보다 “예산이 이만큼인데 무엇을 빼면 맞을까요”가 훨씬 좋은 질문이에요.
앞쪽 질문에는 두 가지 답만 나와요. 못 한다고 하거나, 같은 범위에 금액만 낮춘 견적을 주는 거예요. 후자가 더 위험해요. 어디선가 줄인 건데 어디를 줄였는지는 안 보이거든요. 대개 QA와 유지보수 쪽이에요. 저가 견적의 함정이 어디에 숨는지에서 실제 사례를 정리해뒀어요.
뒤쪽 질문을 하면 개발사가 판단 근거를 함께 내놓게 돼요. 어떤 기능이 왜 비싼지, 무엇을 빼면 검증까지 줄어드는지 설명이 나와야 정상이고요. 그 설명이 안 나오는 개발사면 범위 관리도 기대하기 어려워요.
8. 운영해보면 알게 되는 것
저희는 자체 SaaS를 4종 직접 운영해요. 그러면서 확실해진 게 있어요. 처음에 넣은 기능의 상당수는 실제로 잘 안 쓰여요.
기획 단계에서 꼭 필요해 보였던 기능이 오픈 뒤 지표를 보면 거의 눌리지 않는 경우가 자주 있어요. 반대로 급하게 만든 작은 기능이 매일 쓰이기도 하고요. 이 차이는 만들어서 열어보기 전에는 알기 어려워요.
그래서 예산이 부족한 상황을 저희는 나쁘게만 보지 않아요. 어차피 줄여야 한다면 덜 확실한 것부터 미루고 실제 사용을 보고 결정하는 순서가 되니까요. 문제는 예산이 부족한 게 아니라, 부족한 상태에서 전부 만들려다 품질을 깎는 쪽으로 가는 거예요.
9. 자주 묻는 질문
견적이 예산보다 높으면 기능부터 줄여야 하나요?
기능은 마지막 수단에 가까워요. 지원 범위와 디자인 방식을 먼저 조정하시면 서비스 형태를 덜 망가뜨리면서 금액을 내릴 수 있어요. 지원 기기나 브라우저를 좁히는 건 개발량보다 검증량을 줄여서 효과가 생각보다 커요.
예산을 맞추려고 QA를 빼도 괜찮을까요?
권하지 않아요. 없애는 대신 범위를 좁히세요. 결제와 로그인처럼 실패하면 치명적인 흐름만 집중 검증하고 나머지는 가볍게 보는 방식이면 비용과 안전 사이를 맞출 수 있어요.
단계를 나눠서 개발하면 총비용이 더 드나요?
단순 합계로는 조금 더 들어요. 대신 2차 범위를 실제 사용 데이터를 보고 정할 수 있어서 안 쓰는 기능을 만드는 낭비가 줄어요. 다만 같은 개발사와 이어서 하는 걸 전제로 계산하셔야 해요.
10. 마무리
예산이 빠듯한 상태에서 좋은 결정을 하려면, 깎을 곳을 찾기 전에 지켜야 할 곳을 먼저 정하셔야 해요. 그 순서만 바꿔도 같은 금액으로 훨씬 오래 가는 서비스가 나와요.
지금 받은 견적에서 무엇을 미루고 무엇을 남겨야 할지 판단이 어려우시다면, 범위부터 같이 정리해드릴게요 →
저희는 10년 넘게 50개 이상의 프로젝트를 진행하면서 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 만들고 끝난 게 아니라 운영까지 해봤기 때문에, 지금 줄이면 나중에 어디서 되돌아오는지를 기준으로 봐드릴 수 있어요.
관련 글