외주 개발 끝나고 나면? 개발 종료 후 유지보수 비용의 진실
3,000만 원에 만든 앱의 유지보수에 1억 원이 더 들기도 합니다. 출시 후 60~80%를 차지하는 그 비용은 무엇으로 구성되고, 왜 출시 전 계약서에서 이미 정해져야 하는지 살펴봅니다.
Jun 26, 2026
외주 개발 견적서는 대부분 서비스 및 제품 출시까지로 그 범주를 한정하는 경우가 많습니다. 기획·디자인·개발·테스트를 거쳐 서비스가 세상에 나오는 시점, 거기까지의 비용이 견적서에 잡히고 기재됩니다. 그러나 과학기술정보통신부 산하 정보통신산업진흥원(NIPA)의 SW 유지보수 비용 산정 가이드에 따르면 소프트웨어 시스템의 총 생애비용 가운데 60~80%가 출시 이후에 발생합니다. 견적서가 보여준 것이 전체 비용의 20~40%에 불과하다는 뜻입니다.
이 격차야말로 외주 개발의 가장 큰 함정입니다. 출시일에 프로젝트가 끝났다고 생각하는 순간, 정작 더 큰 비용이 시작됩니다. 그리고 그 비용을 누가 어떻게 감당할지는 출시 이후가 아니라 계약 단계에서 이미 결정됩니다. 본 아티클은 앱, 혹은 서비스 출시 후 유지보수 비용이 무엇으로 구성되는지, "무상 유지보수"라는 말이 실제로 무엇을 보장하는지, 그리고 그 비용을 가르는 계약 단계의 선택이 무엇인지를 해부합니다.
출시 후에 발생하는 60~80%의 비용은 출시 전 계약 단계에서 그 크기가 정해집니다. 본 아티클에서 다루려는 것은 그 결정 구조에 대함입니다. 적합한 외주 개발 업체를 선정하는 출발점에서부터 실제 서비스 운용에 소요되는 적정 비용을 산출할 수 있어야 지속 가능하면서도 안정적인 사업 운영이 가능해 지기 때문입니다.
외주 개발의 진짜 비용은 출시 이후부터 시작됩니다
소프트웨어 비용은 출시 시점에 끝나지 않습니다. NIPA의 가이드와 소프트웨어 유지보수 국제 표준인 ISO/IEC 14764가 공통적으로 가리키는 비율은 분명합니다. 개발이 전체 생애비용의 20~40%, 유지보수가 60~80%입니다. 3,000만 원을 들여 만든 앱이라면, 그 앱이 수명을 다할 때까지 유지보수에 적게는 4,500만 원에서 많게는 1억 2,000만 원이 더 들어간다는 의미입니다.
출시 후 비용이 큰 이유는 그 비용의 성격에 있습니다. 개발비는 견적 단계에서 비교적 정확하게 예측됩니다. 기능 목록과 화면 수가 정해지면 인건비와 기간이 산출되기 때문입니다. 반면 유지보수 비용은 예측이 어렵습니다. 출시 후 어떤 버그가 발견될지, 어떤 기능이 추가로 필요해질지, 외부 환경이 어떻게 바뀔지는 출시 전에 알 수 없습니다. 게다가 이 비용은 누적됩니다. 시스템이 오래 운영될수록, 사용자가 늘수록, 기능이 쌓일수록 유지보수 부담은 함께 커집니다.
문제는 견적서가 이 구조를 보여주지 않는다는 데 있습니다. 출시까지의 비용만 적힌 견적서를 받으면, 발주자는 그것이 전체 비용이라고 착각하기 쉽습니다. 가장 싼 출시 견적을 골랐다가 출시 이후에 더 큰 비용을 치르는 일이 흔한 이유입니다.
출시 6개월 뒤, 한 디지털 콘텐츠 기업의 경영진은 외주 계약서를 다시 꺼내 들었습니다. 1억 원짜리 청구서가 도착했기 때문입니다. 구독 플랫폼을 출시한 뒤 결제 오류 수정, 신규 기능 추가, 보안 점검 요청이 차례로 쌓였는데, 그 모든 작업이 별도 견적으로 처리되며 6개월 만에 1억 원이 청구된 것입니다. 처음 받은 출시 견적의 두 배가 넘는 돈을, 출시 이후에 더 쓴 셈입니다.
유지보수 비용을 구성하는 네 가지 영역
유지보수를 한 덩어리로 보면 비용을 통제할 수 없습니다. 소프트웨어 유지보수의 국제 표준인 ISO/IEC 14764는 유지보수를 네 가지 유형으로 나눕니다. 이 분류를 실무 관점으로 옮기면, 유지보수 비용은 버그 수정, 기능 개선, 인프라 운영, 보안·규제 대응의 네 영역으로 구성됩니다. 각 영역은 무상인지 유상인지, 예측이 가능한지 변동성이 큰지가 다릅니다.
버그 수정 (Corrective)
출시된 시스템에서 발견된 결함을 고치는 작업입니다. 수정 유지보수에 해당하며, "원래 약속한 대로 작동하지 않는 것"을 바로잡는 일입니다. 무상 유지보수가 커버하는 핵심 영역이 바로 이것입니다. 하자담보책임 기간 안에서 발견된 결함은 개발사가 무상으로 수정할 의무가 있습니다. 비용 측면에서는 비교적 예측 가능하고, 출시 직후에 집중적으로 발생했다가 시간이 지나며 줄어듭니다.
기능 개선 (Perfective)
새로운 기능을 추가하거나 기존 기능을 향상시키는 작업입니다. ISO 14764의 완전화 유지보수에 해당하고, 유지보수 작업 중 가장 큰 비중(소프트웨어 공학 문헌 기준 약 50~55%)을 차지합니다. 그리고 이 영역은 거의 항상 유상입니다. 처음 약속한 범위를 넘어선 새로운 요구이기 때문입니다. 유지보수 비용에서 가장 큰 부분이 무상이 아니라는 사실은 뒤에서 다룰 "무상 유지보수의 진실"의 핵심입니다.
인프라 운영 (Adaptive)
서버, 데이터베이스, 외부 라이선스, 결제 모듈 같은 인프라를 유지하는 비용입니다. 클라우드 사용료, 도메인·인증서 갱신, SaaS 구독료가 여기에 들어갑니다. 환경 변화에 적응하는 작업이라는 점에서 ISO 14764의 적응 유지보수와 운영비가 겹칩니다. 대체로 유상이며 실비 정산되는 경우가 많습니다.
보안·규제 대응 (Adaptive·Preventive)
보안 취약점 패치, 개인정보 보호 규제 변화 대응, OS·플랫폼 정책 변경에 맞춘 수정이 여기에 해당합니다. 적응과 예방 유지보수가 섞여 있고, 무상과 유상의 경계가 가장 모호한 영역입니다. 출시 시점에 알 수 없는 외부 변화에 대응하는 일이라 변동성이 큽니다.
네 영역을 함께 놓고 보면 한 가지가 분명해집니다. 무상으로 처리되는 것은 주로 버그 수정이고, 가장 큰 비중을 차지하는 기능 개선은 유상이라는 점입니다.
'무상 유지보수'라는 항목 이면의 진실
"1년 무상 유지보수 포함"이라는 문구는 외주 용역을 의뢰하려는 클라이언트 기업의 입장에서 꽤나 매력적으로 들립니다. 그러나 그 무상이 정확히 무엇을 보장하는지를 확인하지 않으면, 출시 후에 예상과 다른 청구서를 받게 됩니다. 무상 유지보수의 법적 실체는 한국소프트웨어산업협회(KOSA)의 SW 표준계약서가 정한 1년 하자담보책임입니다. 곧 "납품한 결과물이 약속한 기준대로 작동하지 않을 때, 1년간 무상으로 고친다"는 약속입니다.
핵심은 "하자"와 "기능 추가"의 경계에 있습니다. 무상이 커버하는 것은 하자, 곧 원래 약속한 것이 작동하지 않는 경우입니다. 결제가 안 되거나, 화면이 깨지거나, 데이터가 누락되는 것은 하자이므로 무상입니다. 반면 "결제 수단을 하나 더 추가하자", "관리자 화면에 통계를 넣자", "다른 시스템과 연동하자" 같은 요구는 새로운 기능이므로 유상입니다. 앞서 본 것처럼 유지보수 작업의 가장 큰 비중인 기능 개선이 바로 이 유상 영역에 들어갑니다. 무상 유지보수라는 단어가 가리는 것이 이 부분입니다.
또 하나 확인해야 할 것은 무상 기간이 끝난 뒤의 절벽입니다. 1년 무상이 끝나는 13개월째부터는 버그 수정조차 유상으로 전환됩니다. 이때의 단가는 공공 SW 사업 기준 연 개발비의 15~20%가 표준입니다. 3,000만 원짜리 시스템이라면 1년차 이후 유지보수에 연 450만~600만 원이 든다는 계산입니다. 무상 기간만 보고 계약하면 이 절벽을 출시 1년 뒤에야 마주하게 됩니다.
한국인터넷진흥원 산하 전자거래분쟁조정위원회의 분쟁 사례에서도 유지보수 범위를 둘러싼 다툼이 반복적으로 등장합니다. 무엇이 무상이고 무엇이 유상인지가 계약서에 명확하지 않으면, 발주자는 "이건 당연히 무상 아니냐"고 보고 개발사는 "이건 신규 작업"이라고 보는 평행선이 그어집니다. 무상이라는 단어 하나로 안심하기보다, 그 무상이 어디까지인지를 계약서에서 확인하는 것이 분쟁을 막는 길입니다.
유지보수 비용은 계약 단계에서 결정됩니다
유지보수 비용은 출시 이후에 발생하지만, 그 비용의 크기는 출시 전 계약 단계에서 결정됩니다. 같은 시스템이라도 어떻게 계약했는가에 따라 유지보수 비용이 두세 배까지 벌어집니다.
세 가지 계약 요소 가운데 가장 눈에 띄지 않으면서 가장 비싼 오류는 인수인계 패키지의 부재입니다. 시스템 아키텍처 다이어그램, 환경별 배포·운영 매뉴얼, 계정·API 키·도메인 권한이 출시 시점에 함께 넘어오면, 이후 누가 유지보수를 맡든 코드를 이해하는 시간이 줄어듭니다. 이 문서들이 없으면 다음 유지보수를 맡는 사람은 코드를 처음부터 분석해야 하고, 며칠에서 몇 주가 걸리는 그 분석 시간이 고스란히 유지보수 단가에 더해집니다. IP 귀속 조항은 이 선택지 자체를 닫는 자물쇠입니다. 소스코드의 소유권이 발주자에게 없으면 다른 회사에 유지보수를 맡기거나 내부에서 운영하는 길이 막혀, 원개발사에 종속됩니다. 여기에 장애 발생 시 몇 시간 안에 대응하는지를 정한 SLA(서비스 수준 약정)가 더해져야 유지보수가 약속으로 작동합니다. 직계약 모델이 이런 위험을 어떻게 줄이는지는 「직계약 개발이 중개 플랫폼보다 안전한 3가지 이유」에서 자세히 다룹니다.
인수인계 문서가 한 장도 없다는 사실을 안 것은, 첫 장애가 발생한 다음이었습니다. 한 중견 제조사가 재고 관리 시스템을 외주로 만들어 출시한 뒤 1년이 지나 결제 연동 부분에 장애가 생겼는데, 그제서야 아키텍처 문서도, 환경 설정 정보도, 배포 매뉴얼도 받은 것이 없다는 사실을 깨달았습니다. 원개발사는 이미 다른 사업으로 옮겨 대응이 느렸고, 새 외주사에 맡기려 하자 "코드 분석부터 해야 한다"며 견적이 신규 개발 수준으로 올라왔습니다. 출시 시점에 인수인계 패키지를 받아두었다면 들지 않았을 비용이었습니다.
출시 후 운영, 누구에게 맡길 것인가
유지보수를 누구에게 맡길지는 세 가지 선택지로 나뉩니다. 원개발사에 계속 맡기는 길, 새 외주사로 바꾸는 길, 내부 팀으로 전환하는 길입니다. 각각 비용 구조와 리스크가 다르고, 어느 것이 정답인지는 시스템의 성격과 회사의 상황에 따라 달라집니다.
원개발사에 계속 맡기는 방식은 코드 이해도가 가장 높다는 것이 장점입니다. 만든 사람이 고치는 것이므로 분석 시간이 들지 않고, 시스템의 맥락을 이미 알고 있습니다. 다만 다른 선택지가 없으면 원개발사가 제시하는 단가를 받아들일 수밖에 없어 협상력이 약해지고, 인수인계 패키지가 없으면 이 종속이 더 강해집니다.
새 외주사로 바꾸면 경쟁 견적을 받아 단가를 비교할 수 있습니다. 대신 새 외주사가 기존 코드를 분석하는 비용을 감수해야 하는데, 인수인계 문서가 잘 갖춰져 있으면 이 비용이 작고 없으면 사실상 재개발에 가까워집니다.
내부 팀 전환은 채용과 학습에 시간이 든다는 점에서 가장 느린 선택입니다. 그러나 2년이 지난 시점에는 단가 경쟁 없이 의사결정할 수 있는 유일한 구조이기도 합니다. 회사 안에 운영 지식이 쌓이고 변경 의사결정이 빨라지기 때문입니다. 내부 팀 전환의 판단 기준은 「내부 개발팀 구축 vs 외주: 어떤 선택이 맞을까」에서 더 다룹니다.
세 선택지에는 공통의 전제가 깔려 있습니다. 코드를 인수받을 수 있어야 이 선택지들이 열린다는 것입니다. 인수인계 패키지와 IP 귀속이 없으면 원개발사 종속 외에는 길이 없습니다.
원개발사에 유지보수를 맡긴 회사와 새 외주로 바꾼 회사의 1년 후는 달랐습니다. 비슷한 규모의 커머스 플랫폼을 운영하던 두 회사 가운데, 인수인계 패키지를 받아둔 회사는 1년차에 유지보수 견적을 세 곳에서 받아 비교한 끝에 단가를 30% 낮췄습니다. 반면 인수인계 없이 출시한 회사는 원개발사 외에 견적을 받을 곳이 없어 제시 단가를 그대로 받아들여야 했고, 결과적으로 같은 수준의 유지보수에 더 많은 비용을 썼습니다. 출시 시점의 인수인계 한 가지가 1년 후의 협상력을 갈랐습니다.
견적 단계에서 확인할 유지보수 체크리스트
유지보수 비용이 출시 전에 결정된다면, 출시 전 견적 단계에서 확인할 것이 정해져 있습니다. 다섯 가지를 계약 전에 물어두면 출시 후 비용의 윤곽이 분명해집니다.
먼저 무상 유지보수의 기간과 범위를 확인합니다. 몇 개월 무상인지, 그 무상이 어디까지 커버하는지(하자만인지, 일부 기능 수정도 포함인지)를 구체적으로 묻습니다. 다음으로 장애 발생 시 몇 시간 안에 1차 대응하는지를 정한 SLA가 있는지 묻습니다. 이것이 정해져 있어야 유지보수가 약속으로 작동합니다. 인수인계 5종(아키텍처 다이어그램, 운영 매뉴얼, 계정·키 인계, SLA 명시, 종료 후 전환 시나리오)이 제공되는지도 요구해 둡니다. 무상 기간이 끝난 뒤의 유상 전환 단가는 계약 단계에서 미리 명시하게 하는 것이 좋습니다. 13개월째에 단가를 처음 듣는 상황을 피하기 위해서입니다. 마지막으로 다른 회사로 유지보수를 이관할 수 있는 구조인지, IP 귀속이 발주자에게 있는지를 확인합니다.
이 다섯 가지는 외주 개발사를 비교할 때 던지는 질문과 자연스럽게 이어집니다. 견적 단계의 더 넓은 질문 목록은 「외주 개발사 비교할 때 반드시 물어봐야 할 10가지 질문」에 정리되어 있습니다.
유지보수 비용은 출시 전 계약에서 정해집니다
유지보수를 줄이고 싶은 비용 항목으로만 보면, 정작 통제할 시점을 놓칩니다. 생애비용의 60~80%가 걸린 이 비용은 이미 발생한 다음에는 줄이기 어렵습니다. 그러나 출시 전 계약 단계에서 무상 범위와 SLA, 인수인계를 명문화하는 순간, 그 비용의 상당 부분이 미리 통제됩니다. 장애가 발생하고 나서야 인수인계 문서가 없다는 걸 아는 상황을 계약 체결 단계에서 예방할 수 있습니다.
스파르타빌더스는 유지보수에 대한 중요성을 잘 알기 때문에, 직접 개발을 대행하는 외주 개발 직계약을 기반으로 출시 이후의 유지보수에 대한 사항들을 면밀히 검토하고 함께 의논하며 계약을 체결하고 있습니다. 직계약 모델이 왜 이 차이를 만드는지는 「직계약 개발이 중개 플랫폼보다 안전한 3가지 이유」에서 다룹니다.
출시를 앞두고 유지보수를 고민 중이라면, 프로젝트 규모에 맞는 유지보수 시나리오를 함께 정리해 드립니다. 문의사항이 있다면 무료 상담을 요청해 주십시오.
Share article