MVP 유지보수 비용, 얼마를 잡아야 하나

결론부터

MVP 개발 비용만 준비하고 출시 후 비용을 안 잡으면, 3개월 뒤에 서비스가 방치됩니다. 개발 비용의 15~25%를 매년 유지보수 예산으로 잡으세요. 처음부터 계획에 넣는 게 가장 쌉니다.

MVP 출시 후 발생하는 비용 3가지

MVP를 만드는 데만 집중하다 보면, 출시 후 비용을 전혀 고려하지 않은 채 서비스를 오픈하게 됩니다. 17년간 프로젝트를 진행하면서, "출시 후 비용은 생각도 못 했다"는 말을 수없이 들었습니다.

1. 인프라 비용 (서버/호스팅)

서비스가 돌아가려면 서버가 필요합니다. 아키텍처에 따라 다르지만, MVP 단계에서는 월 0~10만 원 수준으로 시작할 수 있습니다.

방식	초기 비용	스케일 시
BaaS (Firebase, Supabase)	무료 티어 가능	월 3~20만 원
서버리스 (Vercel + Supabase)	무료 티어 가능	월 5~30만 원
자체 서버 (VPS)	월 3~10만 원 고정	트래픽 무관, 예측 가능

인프라 비용은 상대적으로 작습니다. 진짜 문제는 아래 두 가지입니다.

2. 유지보수 비용 (코드 관리)

버그 수정, 보안 패치, 소규모 기능 수정 — 코드를 건드리는 모든 작업입니다. 출시 직후에는 괜찮아 보이지만, 사용자가 늘고 시간이 지나면 반드시 필요해집니다.

유지보수가 필요한 대표적인 상황:

• 사용자가 버그를 발견했다
• 앱 스토어 정책이 바뀌어 업데이트가 필요하다
• 의존성 라이브러리에 보안 취약점이 발견됐다
• 텍스트나 설정값을 바꿔야 한다

서비스 규모와 수정 빈도에 따라 다르지만, 시장 기준으로 월 50만~300만 원 범위입니다.

3. 운영 비용 (인프라 관리)

서버 모니터링, 장애 대응, 백업 확인, SSL 인증서 갱신 — 서비스가 멈추지 않도록 관리하는 작업입니다. 자체 서버를 운영하는 경우에 특히 중요하고, BaaS나 서버리스 구조라면 플랫폼이 상당 부분 대신해주므로 비용이 적거나 불필요할 수 있습니다.

유지보수와 운영은 다른 것이다

많은 대표가 "유지보수"라는 말로 출시 후 작업을 전부 뭉뚱그립니다. 하지만 유지보수(코드)와 운영(인프라)은 성격이 완전히 다릅니다. 구분 없이 계약하면 분쟁이 생깁니다.

구분	유지보수	운영
성격	코드/기능 중심	인프라/가용성 중심
하는 일	버그 수정, 보안 패치, 기능 수정	서버 모니터링, 장애 대응, 배포
필요한 순간	"기능이 이상해요"	"서비스가 안 열려요"

계약서에 "유지보수"라고만 써 있으면, 서버가 죽었을 때 "이건 유지보수 범위인가, 아닌가"로 다투게 됩니다. 처음부터 범위를 분리하거나, 묶음으로 계약하더라도 각각의 범위를 명확히 하세요.

하자보수 ≠ 유지보수

개발 완료 직후 일정 기간(보통 1~3개월) 동안 제공되는 하자보수를 유지보수와 혼동하는 경우가 많습니다.

구분	하자보수	유지보수
범위	납품 범위 내 버그 수정만	버그 수정 + 보안 패치 + 소규모 수정
기간	1~3개월 (개발 비용에 포함)	별도 계약 (월 단위)
비용	무료	유료

하자보수 기간은 **"만든 대로 안 되는 것을 고쳐주는 기간"**이지, "무료로 수정해주는 기간"이 아닙니다. 기존 기능의 버그만 해당하고, 새로운 기능이나 디자인 변경은 처음부터 별도 비용입니다.

하자보수가 끝나면 무료 수정은 없습니다. 유지보수 계약 없이 건당으로 의뢰하면, 정기 계약보다 항상 비쌉니다.

유지보수를 안 하면 어떻게 되나

"일단 출시만 하고, 문제 생기면 그때 고치자"는 가장 비싼 전략입니다.

3개월 방치하면:

• 보안 취약점이 패치되지 않아 해킹 위험 증가
• 앱 스토어 정책 변경에 대응 못 해 앱이 내려갈 수 있음
• 사용자가 발견한 버그가 쌓여서 이탈 시작

6개월 이상 방치하면:

• 의존성 라이브러리 버전이 여러 단계 뒤처져, 업데이트 시 연쇄 수정 필요
• 코드 파악에 시간이 걸려 수정 비용이 2~3배로 증가
• 최악의 경우, 처음부터 다시 만드는 게 나은 상황

6개월 뒤 긴급하게 고치는 비용은, 처음부터 월 유지보수를 했을 때의 비용보다 거의 항상 높습니다.

유지보수 비용을 줄이는 4가지 방법

1. 하자보수 기간이 끝나기 전에 유지보수로 전환하라

공백 기간 없이 바로 전환하는 것이 가장 효율적입니다. 시간이 지나면 코드 파악에 추가 비용이 들고, 그사이 쌓인 문제를 한꺼번에 해결해야 합니다.

2. 개발한 업체에 유지보수를 맡겨라

코드를 만든 사람이 가장 잘 압니다. 다른 업체에 넘기면 코드 파악 비용이 추가됩니다. 타사 코드 유지보수는 자사 코드 대비 1.5~2배 비용이 드는 게 일반적입니다. 문서도 없고 테스트 코드도 없으면 그 이상입니다.

3. MVP 단계에서 깔끔한 코드를 요구하라

기술 부채가 많은 코드는 유지보수 비용이 기하급수적으로 올라갑니다. 처음에 시간을 조금 더 쓰더라도 표준적인 구조로 만드는 것이 장기적으로 저렴합니다. 견적을 볼 때 "가장 싼 곳"이 아니라 "가장 깔끔하게 만드는 곳"을 고르세요.

4. 기능을 줄여라

기능이 많으면 유지보수할 것도 많습니다. MVP 단계에서 기능을 최소화하면, 유지보수 비용도 자연스럽게 줄어듭니다. 이건 개발 비용뿐 아니라 유지보수 비용까지 줄이는 가장 확실한 방법입니다.

유지보수 계약 시 확인할 체크리스트

유지보수 계약을 맺을 때 아래 항목을 확인하세요.

범위

• 포함 범위가 구체적으로 정의되어 있는가 (버그 수정, 보안 패치, 소규모 수정 등)
• 제외 범위가 명시되어 있는가 (신규 기능 추가, 디자인 변경, 대규모 리팩토링 등)
• "버그"와 "기능 요청"의 판단 기준이 있는가

비용 구조

• 월 작업 시간(크레딧)이 정해져 있는가
• 미사용 시간의 이월 여부가 명시되어 있는가
• 크레딧 초과 시 단가와 절차가 있는가

서비스 수준

• 응답 시간(SLA)이 명시되어 있는가
• 월간 리포트가 제공되는가 (작업 내역, 잔여 시간, 에러 로그 등)
• 하자보수와 유지보수가 분리되어 있는가

가장 자주 충돌하는 지점은 **"이건 버그인가, 기능 요청인가"**입니다. 납품 시 합의한 기능 명세를 기준으로 판단해야 합니다. 명세에 명시된 대로 작동하지 않으면 버그, 명세에 없던 동작이면 추가 기능입니다. 이 기준이 계약서에 없으면, 매번 싸우게 됩니다.

마무리

MVP는 만들면 끝이 아니라 만들면 시작입니다. 출시 후 비용을 처음부터 계획에 넣지 않으면, 몇 개월 뒤 서비스를 방치하거나 새로 만드는 비용을 쓰게 됩니다. 개발 비용의 15~25%를 매년 유지보수에 잡으세요. 그게 가장 합리적인 투자입니다.

유지보수 계획이 고민되신다면, 프로젝트 요구사항과 함께 문의해 주세요. 아키텍처에 맞는 유지보수 구성을 안내해 드리겠습니다.