유지보수 계약, 월정액·건별·SLA 방식과 비용 정하기

홈페이지나 시스템을 만들고 나면 반드시 마주치는 질문이 유지보수 계약입니다. 매달 얼마를 내야 적정한지, 어디까지가 무료이고 어디부터 돈을 더 내는지 기준이 없으면 계약할 때마다 헷갈립니다. 2026년 기준으로 실무에서 쓰는 방식은 크게 세 가지, 월 정액형과 건별형 그리고 SLA형입니다. 서비스의 중요도와 변경 빈도가 방식을 정하고 비용은 개발비를 기준으로 계산합니다.

핵심 요약

• 유지보수 계약은 월 정액형·건별형·SLA형으로 나뉜다. 매달 고정비를 낼지, 필요할 때만 정산할지, 응답 시간을 보장받을지의 차이다.
• 비용의 기준은 개발비다. 소프트웨어사업 대가산정 기준은 유지관리비를 개발비의 10~15%, 사정에 따라 최대 20% 범위에서 정하도록 안내한다.
• 무상 하자보수와 유상 유지보수는 다르다. 개발 범위 안의 결함은 통상 1년까지 무상, 그 뒤나 기능 추가·보안 대응은 유상이다.
• 계약서에는 포함 범위와 제외 범위, 응답 시간, 정산 방식을 문장으로 못 박아야 분쟁이 줄어든다.

유지보수 계약, 무엇을 사는 것인가

유지보수라는 말이 넓어서 오해가 생깁니다. 발주자는 고장 나면 고쳐 주는 것으로 생각하고 업체는 정해진 범위 안에서만으로 봅니다. 그래서 계약의 출발점은 요율이 아니라 범위입니다. 크게 네 가지로 나눠서 봐야 합니다. 사이트가 멈췄을 때의 장애 대응, 버그를 잡는 결함 수정, 문구나 이미지·배너를 바꾸는 소소한 변경, 그리고 기능 추가나 개편입니다.

실제로 계약서를 놓고 이야기하다 보면 앞의 세 가지까지가 유지보수고 마지막 기능 추가는 별도 견적이라는 선에서 정리되는 경우가 많습니다. "배너 교체는 유지보수에 포함인가요, 별도인가요?"를 먼저 물어보면 업체의 범위 감각을 바로 알 수 있습니다. 이 경계가 흐릿하면 매달 요청할 때마다 추가 비용 실랑이가 생깁니다.

유지보수 종류, 어디까지 포함할지

소프트웨어 유지보수는 크게 네 갈래로 나눕니다. 먼저 고장 난 것을 고치는 수정 유지보수입니다. 버그나 오류를 잡는 가장 익숙한 형태입니다. 다음은 예방 유지보수로 문제가 터지기 전에 로그를 살피고 보안 패치를 미리 적용하는 일입니다. 세 번째는 적응 유지보수입니다. 브라우저나 운영체제, 결제사 정책이 바뀌면 거기에 맞춰 손봅니다. 우리가 가만히 있어도 바깥이 변해서 생기는 일입니다. 마지막은 개선 유지보수로 쓰다 보니 불편한 흐름을 다듬거나 작은 기능을 더하는 쪽입니다.

계약할 때는 이 네 가지 중 어디까지를 정기 유지보수에 넣을지 정해야 합니다. 실제로 진행해 보면 수정과 예방까지는 유지보수로, 적응과 개선은 사안에 따라 별도로 나누는 경우가 많습니다. 특히 개선은 새 기능에 가까워서 범위를 안 정하면 매달 요청이 쌓이며 분쟁의 씨앗이 됩니다.

정기 유지보수의 리듬도 계약서에 적어 두면 좋습니다. 월 1회 점검 리포트를 받는다든지, 보안 패치는 발표 후 며칠 안에 반영한다든지 하는 식입니다. 이런 리듬이 없으면 유지보수는 문제가 터졌을 때만 연락하는 소극적인 형태로 굳어지고 정작 예방 유지보수가 사라집니다. 무엇을 정기적으로 하고 무엇을 요청할 때만 하는지를 나눠 두는 것이 시작입니다.

계약 방식 세 가지, 월정액·건별·SLA형

세 방식은 목적이 다릅니다. 예측 가능성과 유연함, 보장 수준 중에서 무엇을 우선하느냐로 갈립니다.

구분	월 정액형	건별형	SLA형
정산	매달 고정	요청 시	등급별 정액
강점	예산 예측	비용 절감	응답 보장
맞는 서비스	콘텐츠 잦은 사이트	변경 드문 사이트	예약·결제 서비스

월 정액형은 매달 고정 금액을 내고 일정 시간이나 건수를 포함합니다. 예산을 예측하기 쉬워 소개형 홈페이지나 콘텐츠를 자주 바꾸는 사이트에 잘 맞습니다. 건별형은 필요할 때만 요청하고 그때그때 정산합니다. 변경이 드문 사이트라면 고정비가 아까울 수 있어 이쪽이 낫습니다. SLA형은 장애가 나면 몇 시간 안에 대응한다는 응답 시간과 가동률을 계약으로 보장합니다. 예약이나 결제처럼 멈추면 매출이 빠지는 서비스에 필요합니다. 실제 프로젝트에서 보면 처음에는 건별로 시작했다가 사이트가 커지며 월 정액이나 SLA로 옮겨가는 흐름이 흔합니다.

비용은 어떻게 정해지나

유지보수 금액이 막연하게 느껴지는 이유는 기준을 모르기 때문입니다. 공공과 기업 소프트웨어에서 널리 쓰는 기준은 개발비에 요율을 곱하는 방식입니다. 한국소프트웨어산업협회의 소프트웨어사업 대가산정 기준은 유지관리비를 개발비의 10~15%, 사정에 따라 최대 20% 범위로 안내합니다. 개발비가 클수록, 손이 많이 가는 시스템일수록 유지보수도 올라갑니다.

등급	긴급 대응	요율(개발비 대비)
1등급	2시간 이내	20%
3등급	8시간 이내	16%
5등급	24시간 이내	12%

요율을 가르는 건 난이도입니다. 대가산정 기준은 유지관리 횟수와 사용자 수, 시스템 중요도, 다른 시스템과의 연계, 오류 복구 속도 같은 항목으로 난이도를 점수화합니다. 상용 소프트웨어 쪽을 보면 긴급 대응을 2시간 안에 하는 1등급이 20%, 24시간 기준인 5등급이 12% 식으로 응답 시간이 요율을 끌어올립니다. 빨리 받는 만큼 더 낸다는 뜻입니다. 다만 현실은 가이드와 차이가 있어서 공공 부문에서 기업이 체감하는 요율은 평균 5%대까지 내려간다는 조사도 있습니다. 그래서 숫자를 그대로 들이밀기보다 우리 서비스는 몇 등급 수준의 대응이 필요한가를 먼저 합의하는 편이 낫습니다.

가상 예시로 감을 잡아 보겠습니다. 개발비 2,000만 원 규모의 홈페이지라면 10~15% 요율을 적용했을 때 연 200~300만 원, 월로 나누면 20만 원 안팎이 기준점이 됩니다. 변경이 거의 없다면 건별로 훨씬 적게, 24시간 대응이 필요하면 더 높게 잡힙니다. 노바랩 기준으로도 유지보수는 서비스의 응답 요구 수준에 따라 폭이 큽니다. 이 폭을 계약 전에 좁혀 두는 것이 핵심입니다.

홈페이지·소프트웨어·서버, 대상마다 초점이 다르다

같은 유지보수라도 대상이 무엇이냐에 따라 챙길 것이 달라집니다. 홈페이지 유지보수는 콘텐츠 교체와 보안 패치, 문의 폼이나 예약 같은 연동이 계속 도는지를 주로 봅니다. 방문자가 직접 쓰는 화면이라 작은 오류도 눈에 잘 띕니다. 소프트웨어나 웹앱 유지보수는 기능이 많은 만큼 결함 수정과 라이브러리·운영체제 업데이트 대응이 큰 비중을 차지합니다. 서버와 인프라 유지보수는 성격이 또 다릅니다. 가동 상태 감시와 백업, 트래픽 증가 대응처럼 눈에 안 보이지만 멈추면 전부가 멈추는 영역입니다.

그래서 계약서를 쓸 때 우리 대상이 어디에 무게가 실리는지를 먼저 정해야 합니다. 홈페이지 하나만 있는 곳이 24시간 서버 감시까지 계약하면 과하고 결제가 도는 서비스가 콘텐츠 교체 수준의 계약만 두면 위험합니다. 대상과 계약 범위가 맞아야 돈이 헛되지 않습니다.

대상이 섞여 있는 경우도 많습니다. 예약이 도는 홈페이지라면 화면과 서버가 함께 걸려 있어 콘텐츠 유지보수와 서버 감시를 한 계약에 담아야 합니다. 이럴 때는 각각의 대응 수준을 따로 적는 편이 낫습니다. 콘텐츠는 월 몇 건, 서버 장애는 몇 시간 안에처럼 대상별로 기준을 나눠 두면 나중에 책임 소재가 분명해집니다. 규모가 커질수록 이 구분이 더 중요해집니다. 방문자가 늘면 서버 쪽 대응 비중이 커지고 기능이 쌓이면 소프트웨어 유지보수의 손이 늘어납니다.

유지보수 견적, 같은 기준으로 비교하기

유지보수 견적서를 여러 곳에서 받으면 요율이나 월 금액만 눈에 들어옵니다. 그런데 같은 20만 원이라도 무엇이 포함되느냐에 따라 실제 부담은 크게 다릅니다. 그래서 비교할 때는 금액을 같은 기준으로 풀어 봐야 합니다.

최소한 네 가지를 나란히 놓고 봅니다. 월에 포함되는 작업 시간이나 건수, 그걸 넘겼을 때의 초과 단가, 장애가 났을 때의 응답 시간, 그리고 정기 점검이 있는지입니다. 이 네 가지를 표로 정리해 업체마다 채워 보면 싸 보이던 곳이 사실은 포함 범위가 좁아 더 비싼 경우가 드러납니다. 견적을 받을 때 이 항목을 먼저 물어보면 비교가 쉬워집니다.

싼 견적이 무조건 나쁜 건 아닙니다. 다만 유지보수는 문제가 생겼을 때 진가가 드러나는 서비스라 응답이 느슨하거나 담당자가 자주 바뀌는 곳이면 급할 때 곤란해집니다. 그래서 금액과 함께 누가 얼마나 빨리 대응하는지를 같이 확인하는 편이 낫습니다. 몇 달 지나 담당자가 사라지는 계약보다 조금 비싸도 연락이 닿는 계약이 결국 싸게 먹힙니다.

무상 하자보수와 유상 유지보수의 경계

가장 많이 부딪히는 지점입니다. 하자보수는 개발 범위 안에서 원래 되어야 할 기능이 안 되는 결함을 고치는 것으로 통상 사업 종료일부터 1년까지 무상입니다. 반면 유지보수는 그 1년이 지난 뒤의 결함이나 새 기능 추가, 운영체제·브라우저 업데이트 대응, 보안 조치처럼 범위를 넘거나 시간이 흐르며 생기는 일을 다루며 유상입니다.

여기서 오해가 생깁니다. 무료 기간이니 이것도 해 달라며 새 기능을 요구하는 경우인데 새 기능은 하자보수가 아니라 개발입니다. 반대로 명백한 버그를 유상으로 청구하면 그것도 맞지 않습니다. 계약서에 하자보수 기간과 그 범위를 적어 두면 이 실랑이가 크게 줄어듭니다. 오픈 뒤의 운영 흐름은 웹사이트 운영 시작 글에서 단계별로 정리한 내용과 함께 보면 도움이 됩니다.

계약서에 꼭 담을 항목

유지보수 분쟁은 대부분 그건 계약에 없었다에서 시작합니다. 그래서 아래 항목은 말이 아니라 문장으로 남겨야 합니다.

1. 포함 범위와 제외 범위를 예시까지 적는다. 문구·이미지 교체는 포함, 신규 페이지는 별도처럼.
2. 월 포함 시간이나 건수, 초과했을 때의 단가를 정한다.
3. 장애 대응 응답 시간과 연락 창구를 정한다. 카톡·메일·전화 중 무엇으로 몇 시간 안에 받을지.
4. 하자보수 기간과 유상 전환 시점을 명시한다. 통상 1년이 기준이다.
5. 정산 주기와 계약 해지·이관 조건을 넣는다. 소스코드와 계정 인수 조건도 함께.

업체를 고를 때 이 항목을 그대로 물어보면 준비된 곳인지 금방 드러납니다. 계약 전 확인할 것은 홈페이지 제작 단계에서부터 챙기는 편이 좋습니다. 업체 선정 관점은 홈페이지 개발 업체 계약 전 확인 글과 함께 보면 빠짐이 줄어듭니다.

계약 해지와 이관, 시작할 때 정해 둔다

유지보수는 시작보다 끝이 더 문제입니다. 업체를 바꾸거나 자체 운영으로 돌릴 때 인수인계가 안 되면 멀쩡한 사이트를 두고도 손을 못 대는 상황이 생깁니다. 그래서 계약을 맺을 때 해지 조건을 함께 정해 둬야 합니다. 해지를 며칠 전에 알릴지, 남은 기간의 정산은 어떻게 할지를 미리 적어 둡니다.

더 중요한 건 이관입니다. 소스코드와 서버·도메인 계정, 운영 문서를 빠짐없이 넘겨받는 조건을 계약서에 넣습니다. 실제로 넘겨받아 보면 계정 권한 하나가 빠져 며칠을 헤매는 일이 잦습니다. 해지 공문을 보내기 전에 이관 목록을 먼저 맞춰 두면 이런 공백을 줄일 수 있습니다.

이관을 미루면 협상력도 사라집니다. 계약이 끝나가는 시점에 계정을 못 받으면 아쉬운 쪽은 발주자라 불리한 조건에 재계약하기 쉽습니다. 그래서 이관 목록은 계약을 시작할 때 부록으로 붙여 두고 중간에도 문서와 계정을 정리해 두는 편이 안전합니다. 인수인계 문서가 부실하면 다음 업체의 초기 비용이 올라갑니다. 코드 구조를 파악하는 데 드는 시간이 곧 견적에 얹히기 때문입니다. 이관은 지금 업체와의 마무리이자 다음 업체와의 협상 카드입니다.

자주 하는 오해와 결정 기준

정리하면 오해는 세 가지입니다. 첫째, 유지보수는 다 비슷하다는 생각입니다. 방식에 따라 비용도 대응 속도도 크게 다릅니다. 둘째, 요율 몇 퍼센트만 알면 된다는 생각입니다. 같은 요율이라도 포함 범위가 다르면 실제 부담이 달라집니다. 셋째, 무료 기간이면 뭐든 된다는 생각입니다. 무상은 결함 수정까지입니다.

결정은 이렇게 잡으면 단순합니다. 변경이 거의 없는 소개형 사이트면 건별형으로 시작합니다. 콘텐츠를 자주 바꾸고 예산을 고정하고 싶으면 월 정액형이 편합니다. 멈추면 매출이 빠지는 예약이나 결제 서비스면 SLA형으로 응답 시간을 보장받습니다. 어느 쪽이든 계약 전에 포함과 제외, 응답 시간, 초과 단가를 문장으로 정해 두면 나중 실랑이의 대부분이 사라집니다.