유지보수 비용은 어떻게 정해지는가 — 요율 방식과 범위 방식

유지보수 견적을 여러 곳에서 받아 보면 금액보다 먼저 표현이 다르다는 것이 보입니다. 한 곳은 「개발비의 몇 퍼센트」로, 다른 곳은 「월 얼마」로, 또 다른 곳은 「인원 몇 명, 몇 개월」로 적어 보냅니다. 같은 시스템을 맡기는 견적인데 값을 정한 기준이 서로 달라서, 금액을 나란히 놓아도 비교가 되지 않습니다.

이 글은 운영 중인 시스템을 맡길 때 그 비용이 어떤 방식으로 정해지는지를 다룹니다. 시스템을 새로 만드는 비용은 기업용 웹·앱 개발 비용은 어떻게 결정되는가에서, 다른 업체가 개발한 시스템을 이어받을 수 있는 상태인지는 기존 시스템, 이어받으려면 무엇이 필요한가에서 다룹니다. 계약서에 범위를 어떤 항목으로 적는지는 유지보수 계약에 넣을 범위에서 따로 정리했습니다.

이 글의 질문은 빌드업웍스의 견적서에도 그대로 적용하실 수 있습니다.

유지보수 비용을 정하는 방식은 네 가지입니다

운영 중인 소프트웨어의 유지보수 비용은 대체로 다음 네 가지 중 하나, 또는 둘 이상을 섞은 방식으로 정해집니다. 다른 업체가 개발한 시스템을 처음 맡을 때는 여기에 초기 안정화 비용이 더해집니다. 방식마다 값을 매기는 기준이 다르고, 그래서 견적서에서 확인할 곳도 다릅니다.

인수 초기 안정화는 매달 반복되는 비용이 아니라 처음 한 번 드는 비용이라 성격이 다릅니다. 이 차이는 「이어받는 초기의 안정화 비용」 절에서 따로 다룹니다.

개발비 대비 요율 방식 — 공공 기준의 대표적인 계산

「유지보수 요율」은 이 방식에서 개발비에 곱하는 비율을 가리킵니다. 국내 공공 소프트웨어 사업에서는 한국인공지능·소프트웨어산업협회(KOSA)가 공표하는 「SW사업 대가산정 가이드」가 대가산정 기준으로 쓰이고, 이 가이드는 응용 소프트웨어 유지관리의 대가를 정하는 방식으로 요율제 외에 변동비 방식 등도 함께 두고 있으며, 그중 2025년 개정판 Ⅳ장 2.1 「요율제 유지관리비」는 다음 식을 제시합니다.

요율제 유지관리비 = 유지관리 대상 소프트웨어의 계약 시점에 재산정된 개발비 × 유지관리 요율(10~15%) + 직접경비

요율은 그 범위 안에서 시스템의 난이도로 정합니다. 가이드는 유지관리 횟수, 시스템 사용자 수, 시스템 중요도, 다른 시스템과의 연계, 오류 복구 신속성 다섯 가지를 점수로 매겨 0~100점의 총점을 내고, 「10 + 5 × (총점 ÷ 100)」으로 요율을 계산합니다. 총점이 0점이면 10%, 100점이면 15%입니다.

눈여겨볼 점은 곱하는 개발비가 처음 계약 금액이 아니라는 것입니다. 가이드는 유지관리되는 동안 기능이 추가·변경·삭제되었을 수 있으므로, 개발비를 유지관리 계약 시점의 기능 규모와 그 시점의 단가로 다시 산정하도록 하고 있습니다. 같은 요율이라도 무엇에 곱했는지가 다르면 금액이 달라지고, 요율이 해마다 같아도 기능 규모나 단가가 바뀌면 금액이 바뀝니다.

구매한 상용 소프트웨어는 기준이 또 다릅니다. 같은 가이드는 상용 소프트웨어의 유지관리비를 개발비가 아니라 최초 라이선스 구매 계약 금액에 유지관리 등급별 요율을 곱해 산정합니다(Ⅳ장 2.2). 견적서에 퍼센트가 적혀 있다면 그 비율이 개발비에 곱해진 것인지 라이선스 금액에 곱해진 것인지부터 구분하실 수 있습니다.

공공 기준이라는 성격

이 가이드는 국가기관 등이 발주하는 소프트웨어 사업에 적용하도록 만든 기준입니다(Ⅰ장 1.4). 공공 부문은 예전에 정부 고시 「소프트웨어사업 대가의 기준」(지식경제부 고시 제2010-52호)을 썼는데, 이 고시는 사업대가가 민간 자율로 결정되도록 유도한다는 부칙에 따라 2012년 2월 폐지되었고, 협회가 소프트웨어 진흥법 제10조에 근거해 대체 기준으로 이 가이드를 마련했습니다(Ⅰ장 1.2). 같은 법 제46조는 국가기관 등이 소프트웨어 사업을 계약할 때 적정한 수준의 대가를 지급하도록 노력하라고 정하고 있습니다.

그래서 민간 계약에서 10~15%라는 범위는 참고할 수 있는 공공 기준의 값이지, 계약의 정답으로 정해진 값은 아닙니다. 민간 계약의 요율과 범위는 당사자가 계약으로 정합니다.

다른 업체가 개발한 시스템에서 요율 방식이 갖는 한계

요율 방식은 기준이 되는 개발비가 분명할 때 잘 작동합니다. 같은 기관이 개발을 발주하고 기능 규모를 관리해 온 시스템이라면 그 값을 다시 산정할 근거가 남아 있습니다. 다른 업체가 개발한 시스템을 이어받는 경우에는 사정이 다릅니다.

• 기준 개발비를 모를 수 있습니다. 개발 계약서가 남아 있지 않거나, 개발사와 연락이 끊겨 금액을 확인할 수 없거나, 여러 해에 걸쳐 여러 업체가 나누어 개발한 시스템이라면 곱할 금액부터 정해지지 않습니다.
• 알고 있어도 오래전 값입니다. 처음 개발비에는 그 뒤에 더해지고 바뀐 기능이 반영되어 있지 않습니다. 공공 기준이 계약 시점에 기능 규모를 다시 산정하도록 하는 이유가 여기에 있는데, 문서가 없는 시스템에서는 기능 규모를 다시 산정하는 일 자체가 작업이 됩니다.
• 개발비가 현재의 작업량을 직접 나타내지는 않습니다. 개발비는 만드는 데 든 비용이고, 유지보수의 작업량은 지금 그 시스템을 고치고 유지하는 데 드는 일입니다. 개발비가 같아도 지원이 끝난 기술로 만들어졌거나, 소스와 변경 이력이 불완전하거나, 업무 규칙이 자주 바뀌는 시스템은 작업량이 다릅니다. 공공 기준의 난이도 다섯 요소에는 기술 스택의 노후나 문서·소스의 상태가 들어 있지 않습니다.

공공 기준에도 기능점수 방식이 맞지 않는 경우를 위한 예외가 있습니다. 같은 가이드는 규모를 기능점수 방식으로 산정하기 곤란하거나 불합리한 소프트웨어(홈페이지 디자인 같은 콘텐츠, 내부 처리 복잡도가 현저히 높은 소프트웨어 등)는 유지관리에 실제 투입되는 공수를 별도로 산정해 실비로 계상할 수 있고, 요율제를 쓰는 경우에도 유지관리 업무 외의 추가 업무는 투입공수 방식으로 추가 대가를 산정할 수 있다고 적고 있습니다(Ⅳ장 2.1.5).

요율 방식이 잘못된 계산이라는 뜻은 아닙니다. 예산의 규모를 처음 가늠하는 출발점으로는 쓸 수 있습니다. 다만 다른 업체가 개발한 시스템의 견적을 비교할 때는 「몇 퍼센트인가」보다 그 금액으로 무엇을 맡는가가 비교의 기준이 됩니다.

투입 인력 방식과 건별 방식 — 시간 기준과 요청 기준

투입 인력 방식은 인원과 기간, 직무별 단가로 비용을 정합니다. 흔히 인월(M/M, 한 사람이 한 달 동안 일하는 양) 방식이라고 부르며, 공공 기준도 일상 운영과 사용자 지원 같은 소프트웨어 운영 사업은 이 방식을 기본으로 합니다(Ⅳ장 3.1). 전담 인력이 필요한 운영이라면 예산을 예측하기 쉽습니다. 이 방식에서 비용을 지불하는 대상은 인력의 투입 시간이므로, 견적서에서는 그 시간에 무엇을 하는지, 담당자가 바뀌면 어떻게 인계되는지, 작업 기록과 문서가 결과로 남는지를 확인하실 수 있습니다.

건별 방식은 요청이 생길 때마다 범위를 파악하고 견적을 내 진행합니다. 수정 요청이 드문 시스템에서는 고정 지출이 생기지 않는다는 장점이 있습니다. 다만 요청할 때마다 파악·견적·승인 절차가 반복되고, 요청이 없는 기간의 정기 업데이트와 보안 점검, 백업 확인은 따로 정하지 않으면 담당이 정해지지 않은 채 남습니다. 맡는 곳이 매번 바뀌면 시스템에 대한 이해와 이력도 한곳에 축적되지 않습니다.

대상 시스템과 지원 범위로 정하는 월 정액

범위 기반 월 정액은 기준을 개발비가 아니라 맡을 범위에 둡니다. 어떤 시스템을 대상으로 하는지, 매달 반복되는 일이 무엇인지(오류 접수와 수정, 정기 업데이트, 점검, 배포와 변경 기록), 기능 개선 요청은 어떻게 처리하는지, 범위를 넘는 요청은 어떤 절차를 거치는지를 정한 뒤 그 범위에 대해 월 금액을 정합니다.

기준이 맡을 범위이므로, 개발비를 모르는 시스템에서도 금액의 근거를 설명할 수 있습니다. 공공 기준의 고정비/변동비 방식도 비슷한 구조를 씁니다. 일상 운영과 지원, 환경 변화 대응과 오류 수정처럼 기능을 바꾸지 않는 일은 고정비로 보고 투입공수로 산정하며, 기능 개선은 변동비로 보고 예상되는 개선량을 기능점수로 산정합니다(Ⅳ장 4.1). 반복되는 일과 개선을 나누어 값을 정한다는 점에서 같습니다.

월 정액에서 확인할 것은 두 가지입니다.

• 범위에 드는 개선이 어느 크기까지인가 — 작은 수정과 큰 기능 추가를 구분하는 기준이 문서에 있어야 매달 같은 금액이 같은 일을 뜻합니다.
• 범위를 넘는 요청은 어떤 절차로 처리되는가 — 공공 기준도 유지관리 범위를 넘는 기능 수정과 추가 개발은 「재개발」로 따로 구분하고 기능점수로 대가를 산정합니다(Ⅳ장 1). 월 정액은 정해진 범위에 대한 금액이므로, 그 밖의 일은 착수 전에 범위와 비용을 확인하고 승인하는 절차가 있는지를 보실 수 있습니다.

이어받는 초기의 안정화 비용은 따로 봅니다

다른 업체가 개발한 시스템을 처음 맡을 때는 매달 반복되는 일보다 먼저 해야 하는 일이 있습니다. 소스코드와 빌드, 배포 절차, 계정 명의, 백업과 복구 절차를 확인하고, 운영 문서와 위험 목록을 만들고, 반복되는 오류가 있으면 원인부터 정리하는 일입니다.

이 작업량은 시스템의 상태에 따라 크게 달라집니다. 소스와 변경 이력, 배포 절차가 기록으로 남아 있는 시스템과 그렇지 않은 시스템은 출발점이 다릅니다. 무엇이 남아 있어야 하는지는 기존 시스템, 이어받으려면 무엇이 필요한가에 여섯 가지로 정리해 두었습니다.

이 초기 비용은 월 금액에 나누어 넣을 수도 있고 별도 프로젝트로 견적할 수도 있습니다. 어느 쪽이든 견적서에서 그 비용이 어디에 들어 있는지가 보여야 월 금액을 같은 기준으로 비교할 수 있습니다. 한 견적의 월 금액에는 초기 작업이 섞여 있고 다른 견적에는 빠져 있다면, 두 금액은 같은 일을 가리키지 않습니다.

유지보수 비용을 움직이는 요인

방식이 같아도 금액은 시스템의 조건에 따라 달라집니다. 견적 금액의 차이를 해석할 때 함께 보실 요인은 다음과 같습니다.

• 대상 시스템의 수와 복잡도 — 맡기는 시스템이 몇 개인지, 각 시스템에 사용자 역할과 권한, 데이터 처리 규칙이 얼마나 많은지가 작업량의 바탕입니다. 화면 수보다 화면 뒤에서 처리되는 규칙의 양이 작업량에 가깝습니다.
• 기술 스택의 노후 — 지원이 끝난 언어, 프레임워크, 운영체제 버전 위에서 동작하는 시스템은 업데이트 하나에도 호환성 확인이 길어지고, 보안 업데이트가 더 나오지 않는 구성 요소를 어떻게 다룰지도 정해야 합니다.
• 문서와 소스의 상태 — 소스와 변경 이력, 배포 절차, 운영 문서가 남아 있으면 파악이 빨라지고, 없으면 남아 있는 코드와 설정에서 구조를 읽어 정리하는 일이 먼저 필요합니다.
• 변경 빈도 — 업무 규칙이 자주 바뀌는 시스템은 개선 요청이 많습니다. 공공 기준도 연간 유지관리 횟수를 난이도 요소의 하나로 둡니다.
• 다른 시스템과의 연계 — 외부 시스템과 데이터를 주고받는 지점이 많을수록 변경 하나의 영향 범위를 확인하는 일이 늘어납니다.
• 대응 시간대와 복구 요구 — 업무 시간 외 대응이나 장애 복구에 걸리는 시간을 어디까지 요구하는지가 필요한 인력 구성을 바꿉니다. 공공 기준의 오류 복구 신속성 요소가 같은 성격입니다.
• 시험 환경의 유무 — 운영과 분리된 시험 환경이 없으면 변경마다 확인 부담이 커집니다.

이 요인이 견적서에 적혀 있지 않다면, 그 견적이 어떤 전제로 계산되었는지 업체에 확인하실 수 있습니다.

유지보수 견적을 비교할 때 물어볼 질문

금액을 비교하기 전에 다음 일곱 가지 질문의 답을 견적서마다 맞춰 보실 수 있습니다. 어느 업체에 묻든 같은 질문이 유효합니다.

1. 대상 시스템은 무엇이고, 어디까지인가 — 애플리케이션만인지, 데이터베이스와 서버, 외부 서비스 계정까지인지. 공공 기준도 소프트웨어 운영 단계의 요구에 인프라 운영과 유지관리가 포함되면 대가를 별도로 산정합니다(Ⅳ장 1).
2. 매달 포함되는 작업은 무엇인가 — 오류 접수와 수정, 정기 업데이트, 보안 점검, 배포와 변경 기록, 운영 문서 갱신 중 무엇이 들어 있는지.
3. 기능 개선은 포함인가 — 포함이라면 어느 크기까지이고, 우선순위는 누가 어떻게 정하는지.
4. 범위 밖 요청은 어떻게 처리되는가 — 착수 전에 범위와 비용을 안내받고 승인하는 절차가 있는지, 그 판단을 누가 하는지.
5. 처음 맡는 시점의 작업은 어디에 들어 있는가 — 현황 파악과 안정화가 월 금액에 포함인지, 별도 견적인지.
6. 요율이라면 무엇에 곱하는가 — 어느 시점의 개발비인지, 개발비인지 라이선스 금액인지.
7. 대응 시간대와 연락 경로는 무엇인가 — 업무 시간 외 대응이 포함인지 별도인지.

견적서를 나란히 놓을 때는 한 장의 표로 옮겨 적으면 차이가 드러납니다. 한쪽에만 적혀 있는 칸이 금액 차이의 후보이고, 비어 있는 칸은 업체에 추가로 확인할 항목입니다.

금액이 낮은 견적이 범위를 좁게 산정한 것인지 효율적으로 산정한 것인지는 이 칸을 채운 뒤에 판단할 수 있습니다. 칸이 비어 있다고 그 견적이 부실하다는 뜻은 아닙니다. 요청서에 그 내용이 없었다면 견적서에도 없는 것이 자연스럽습니다.

빌드업웍스의 비용 구조

빌드업웍스의 소프트웨어 관리·개선은 앞의 방식으로 보면 인수인계·안정화를 별도 프로젝트로, 이후의 운영을 범위를 정한 월 정액으로 나눕니다.

1. 무료 상담 — 30분 상담 뒤, 이어받을 수 있는 상태인지와 먼저 확보할 것을 서면으로 정리해 드립니다. 무료 범위는 이 단계까지이며 코드 수정·장애 복구·배포는 포함되지 않습니다.
2. 인수인계·안정화(프로젝트 견적) — 코드, 빌드, 배포, 계정, 백업과 복구 절차를 점검하고 운영 문서와 위험 목록을 만듭니다. 반복되는 오류가 있으면 이 단계에서 원인부터 정리합니다.
3. 월 운영·유지보수(월 정액) — 오류 접수와 원인 분석·수정, 정기 업데이트, 배포와 변경 기록을 맡습니다. 대상 시스템과 지원 범위는 계약에서 정합니다.
4. 지속 개선(범위 안은 월 정액에 포함) — 기능 추가, 성능 개선, 테스트 보강 요청을 목록으로 관리하고 합의한 우선순위대로 반영합니다. 큰 기능이나 구조 변경은 별도 견적입니다.

합의한 범위를 넘는 작업은 착수 전에 범위와 비용을 안내하고 승인을 받은 뒤 진행합니다. 월 정액은 정해진 운영·개선 활동을 약속하는 활동 약정이며, 특정 결과를 보장하는 계약이 아닙니다. 빌드업웍스가 구축한 시스템은 구축 계약에 이어 같은 방식으로 운영합니다.

금액은 대상 시스템과 범위를 확인한 뒤 안내합니다. 포함 항목과 구조는 요금 안내의 소프트웨어 관리·개선 절에도 정리돼 있습니다.

다음 단계

견적서를 받아 두셨다면 견적 비교표의 칸부터 채워 보실 수 있습니다. 비어 있는 칸이 어디인지 정리되면 각 업체에 무엇을 추가로 확인할지가 정해집니다.

지금 시스템에 무엇이 남아 있는지부터 확인하고 싶으시면 이어받기 진단에서 연락처 없이 현재 상태를 점검하실 수 있습니다. 안정화에서 무엇을 확인해야 할지 가늠하는 데 쓰실 수 있습니다. 유지할지 다시 만들지부터 판단해야 하는 상황이라면 유지보수와 재구축의 판단 기준을 함께 보실 수 있습니다.

받으신 견적의 범위를 함께 맞춰 보고 싶으시면 상담 신청으로 연락 주십시오. 판단의 근거는 함께 정리해 드리고, 결정은 고객사에서 하십니다.

참고 자료

• 한국인공지능·소프트웨어산업협회 — SW사업 대가산정 가이드(2025년 개정판, 2025-08 공표) · Ⅰ장 1.2·1.4 · Ⅳ장 1(개요) · 2.1 요율제 유지관리비 · 2.2 상용 소프트웨어 유지관리비 · 3.1 투입공수 방식 SW운영비 · 4.1 고정비/변동비 방식
• 소프트웨어 진흥법 (국가법령정보센터) — 제10조 한국소프트웨어산업협회 · 제46조 적정 대가 지급 등