유지보수 계약(SLA), 어디까지 넣어야 할까요 | 범위 기준
서비스 유지보수 범위는 장애대응·하자보수·기능개선·운영지원 네 갈래로 갈라 적어야 다툼이 줄어요. 행안부 공공 SLA 표준은 1등급 장애조치 120분, 2등급 180분을 필수지표로 두고 2027년 의무화돼요. 계약서에 넣을 항목을 정리했어요.
핵심 요약 — 유지보수 계약에서 다툼이 나는 자리는 금액이 아니라 범위예요. 장애 대응·하자 보수·기능 개선·운영 지원을 네 갈래로 갈라 적고, 각각에 대응 시간과 제외 항목을 붙이면 대부분의 분쟁이 사라져요. 행안부 공공 SLA 표준은 장애조치 최대 허용시간을 1등급 120분, 2등급 180분으로 두고 2027년부터 의무 적용돼요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.
“이 정도는 유지보수에 포함되는 거 아닌가요?” 검수가 끝나고 두어 달쯤 지나면 발주자와 개발사가 거의 예외 없이 주고받는 말이에요. 계약서를 다시 펴보면 대개 이렇게 적혀 있어요. “본 계약의 유지보수 범위는 상호 협의하여 정한다.” 그 한 줄이 나중에 몇 달치 감정 싸움이 되기도 해요. 유지 보수 범위는 금액보다 먼저 정해야 하는 항목인데, 실제 계약서에서는 가장 뒤로 밀려나요.
1. 유지보수 계약서에서 범위만 유독 흐릿한 이유
개발 계약을 쓸 때는 만들 것에 집중해요. 화면 수, 기능 목록, 일정, 대금 지급 방식까지는 꼼꼼히 적어요. 그런데 유지보수는 “그때 가서 정하죠”로 넘어가는 경우가 많아요. 아직 만들지도 않은 것을 어떻게 고칠지 미리 정하기가 어색하기 때문이에요.
문제는 이 시점 차이예요. 계약할 때는 양쪽 다 여유가 있지만, 범위를 다시 이야기하는 시점은 대개 뭔가 잘못됐을 때예요. 서비스가 멈췄거나, 요청이 거절당했거나, 청구서가 예상보다 나왔을 때죠. 그때 범위를 처음 논의하면 감정이 먼저 붙어요. 개발 외주 계약서 핵심 조항은 무엇인가요라는 질문에 저희가 항상 유지보수 범위를 먼저 꼽는 이유예요.
2. 서비스 유지보수 범위는 어디까지인가요 — 네 갈래로 갈라 적어요
유지보수를 한 덩어리로 적으면 반드시 다퉈요. 성격이 완전히 다른 일 네 가지가 섞여 있거든요.
| 갈래 | 무엇을 하나요 | 계약서에 적을 것 |
|---|---|---|
| 장애 대응 | 서비스가 멈추거나 오작동할 때 복구 | 접수 창구·대응 시간·등급 구분 |
| 하자 보수 | 인수 시점에 이미 있던 결함 수정 | 무상 기간·하자 판정 기준 |
| 기능 개선 | 기존 기능 수정·화면 조정 | 정액 포함 범위·초과 시 단가 |
| 운영 지원 | 배포, OS 대응, 모니터링, 백업 확인 | 주기·보고 방식·정기 점검 횟수 |
자사 실무 기준으로 계약서를 나눌 때 쓰는 구분이에요. 법정 분류가 아니라 실무 구분이니 프로젝트마다 조정해서 쓰세요.
이 표에서 가장 자주 새는 칸은 기능 개선이에요. “기존 기능 수정”과 “새 기능 추가”의 경계가 없으면 요청이 계속 흘러들어와요. 저희는 화면이나 데이터 항목이 하나라도 늘어나면 새 기능으로 본다는 식으로 문장을 박아둬요. 기준이 다소 거칠어도, 기준이 없는 것보다는 훨씬 나아요.
3. 무상 하자보수와 유상 유지보수, 경계선은 어디에 긋나요
하자보수는 인수 시점에 이미 있던 결함을 고치는 일이라 원칙적으로 무상이에요. 국내 실무에서는 하자보수 기간을 개발 완료 시점부터 1년으로 잡는 경우가 흔하고, 규모가 작으면 1～6개월로 줄여 계약하기도 해요. 반대로 운영 중 발생한 개선 요청이나 환경 변화 대응은 유상 유지보수로 넘어가요.
경계에서 애매한 상황이 두 가지 있어요. 하나는 발주자가 제공한 자료나 지시 때문에 생긴 문제예요. 발주자가 준 물품이나 데이터의 규격이 기준에 맞지 않았거나, 발주자 지시대로 구축한 결과라면 실무에서는 하자보수가 아니라 유상 유지보수나 재개발로 보는 게 일반적이에요. 다른 하나는 OS·브라우저 업데이트로 생긴 오류예요. 우리 코드가 바뀐 게 아니라 바깥 환경이 바뀐 거라, 이건 계약서에서 어느 쪽으로 볼지 미리 정해두지 않으면 매번 부딪혀요.
용어 짚고 가요 — SLA(서비스수준협약) 서비스 제공자와 고객이 서비스의 품질·성능·지원 수준을 숫자로 합의해 문서로 남긴 계약이에요. “최선을 다해 대응한다” 같은 문장을 “1등급 장애는 접수 후 2시간 안에 조치한다”로 바꾸는 장치라고 보면 돼요. 실무에서는 “SLA 걸었어요?”라는 말을 대응 시간이 계약서에 숫자로 박혀 있느냐는 뜻으로 써요.
4. SLA에는 어떤 지표를 넣어야 다툼이 줄어들까요
민간 계약에는 정해진 표준이 없어서 뭘 넣을지 막막해요. 이럴 때 공공 기준을 참고하면 출발점이 잡혀요. 행정안전부가 마련한 공공 정보시스템 SLA 표준안은 두 가지를 필수지표로 두고 있어요.
| 구분 | 공공 SLA 표준안 기준 (공식 외부 기준) |
|---|---|
| 장애조치 최대 허용시간 | 1등급 120분 · 2등급 180분 · 3등급 300분 · 4등급 480분 |
| 시스템 가용률 | 필수지표, 종합평가에서 30% 이상 비중 |
| 위약금 (월간 평가) | 미흡(80～85점) 계약금액의 5% · 불량(80점 미만) 10% |
| 위약금 (연간 종합) | 탁월 95점 이상 전액 면제 · 우수 25% · 보통 50% 부과 |
| 적용 일정 | 2026년까지 시범 적용 → 2027년부터 1·2등급 사업 의무화 |
출처: 행정안전부 공공 정보시스템 SLA 표준안 관련 보도 종합. 공공 사업 기준이며 민간 계약에 그대로 적용되는 값은 아니에요.
민간 프로젝트에 그대로 옮길 필요는 없어요. 다만 구조는 그대로 가져올 만해요. 장애를 등급으로 나누고, 등급마다 대응 시간을 숫자로 적고, 못 지켰을 때의 결과까지 적는 세 단계요. 실무에서는 심각도에 따라 초기 대응 시간을 4시간·24시간·72시간처럼 나누고, 지원 시간대를 평일 8시간부터 24시간 무휴까지 서비스 성격에 맞춰 정하는 방식이 흔해요.
이 표준안은 공공 사업을 하지 않는 회사에도 의미가 있어요. 전산장비와 응용프로그램, 클라우드 기반 시스템까지 운영·유지관리 사업 전반을 포괄하고, 2026년까지 시범 적용을 거쳐 2027년부터 1·2등급 사업에 의무화되거든요. 발주 기준이 한 번 자리 잡으면 민간 계약서의 문장도 따라 움직여요. 지금까지 “장애 발생 시 신속히 대응한다”로 끝나던 조항이 등급과 시간이 적힌 형태로 바뀌어갈 거예요. 미리 그 구조로 계약해두면 갱신할 때도 수월하고요.
5. 계약서에서 빠지면 나중에 문제되는 항목
범위를 적을 때 포함 항목만큼 제외 항목이 중요해요. 실제로 분쟁이 붙는 자리는 대부분 “안 적힌 것”이에요. 저희가 계약서를 검토할 때 빠졌는지 먼저 보는 항목들이에요.
- 제외 항목 명시 — 신규 기능 개발, 디자인 전면 개편, 제3자 솔루션 자체 결함, 발주자 임의 수정으로 생긴 오류
- 접수 창구와 근무 시간 — 어디로 접수하고 야간·주말은 어떻게 처리하는지
- 대응 시간과 복구 시간의 구분 — 연락받는 시간과 고치는 시간은 다른 값이에요
- 정액에 포함되는 월 작업량 상한 — 시간이든 건수든 상한이 있어야 정액이 성립해요
- 계약 종료 시 인수인계 범위 — 소스코드, 서버 계정, 배포 문서, 운영 이력
- 연간 갱신 조건 — 요율 조정 기준과 통보 시점
여섯 번째 항목이 특히 자주 빠져요. 갱신 조건이 없으면 매년 계약 시즌마다 처음부터 다시 협상하게 돼요.
흔한 실수 — 유지보수 요율만 협상하고 범위는 그대로 두는 경우예요. 요율을 낮추면서 범위를 손대지 않으면, 개발사는 요청을 거절할 근거가 없고 발주자는 대응이 느려졌다고 느껴요. 값을 깎을 때는 반드시 범위나 대응 시간 중 하나를 함께 조정해야 서로 지킬 수 있는 계약이 돼요.
6. 앱 수정·프로그램 수정 견적은 유지보수에 포함되나요
앱 수정 유지보수 견적이나 프로그램 수정 유지보수 견적을 문의받으면, 저희는 먼저 수정의 성격부터 물어봐요. 건수보다 성격이 값을 정하기 때문이에요.
문구나 이미지를 바꾸는 일은 데이터만 바뀌는 작업이라 정액 범위 안에서 처리되는 경우가 많아요. 반면 화면 흐름이 바뀌거나 저장하는 데이터 항목이 늘어나면 설계·개발·테스트가 다시 돌아야 해서 별도 견적으로 넘어가요. 겉보기에는 둘 다 “버튼 하나 바꾸는 일”처럼 보이지만 안에서 하는 일이 달라요.
앱에는 여기에 한 가지가 더 붙어요. OS 업데이트 대응이에요. iOS와 안드로이드는 매년 새 버전을 내놓고, 그때마다 동작이 달라지거나 스토어 정책이 바뀌어요. 이 대응이 정액에 포함되는지 아닌지는 연간 비용을 꽤 크게 바꾸니 계약 전에 꼭 확인하세요.
7. 운영까지 해본 개발사는 범위를 어떻게 나눌까요
저희는 자체 SaaS 4종(D:VALUEUP·Likepro·Globing·Linkmix)을 직접 운영해요. 남의 서비스가 아니라 우리 서비스의 유지보수 요청을 매일 받는 쪽이기도 해요. 그러면서 배운 게 하나 있어요. 범위를 아무리 잘 적어도 요청은 경계선 위로 오게 돼 있다는 거예요.
그래서 저희는 범위 문서에 판단 기준을 하나 더 붙여요. 애매한 요청이 왔을 때 사용자 영향도와 발생 빈도를 먼저 보고 순서를 정하는 방식이에요. 계약서 범위 안팎을 따지기 전에 서비스가 실제로 겪는 손해부터 재는 거죠. 이렇게 하면 경계선 논쟁이 “누가 맞나”가 아니라 “무엇이 급한가”로 바뀌어요.
운영사 Tip — 유지보수 계약을 새로 쓰거나 갱신할 때, 지난 6개월 동안 실제로 들어온 요청을 목록으로 뽑아 네 갈래로 분류해보세요. 우리 서비스가 어떤 유형의 요청을 주로 받는지가 그대로 드러나요. 그 분포에 맞춰 범위와 요율을 정하면 추정이 아니라 실측으로 계약하게 돼요.
납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. 유지보수 범위를 정하는 일도 마찬가지예요. 잘 짜둔 범위 문서는 개발사를 보호하는 장치가 아니라, 발주자가 무엇을 요구할 수 있는지 알게 해주는 문서예요.
8. 자주 묻는 질문 (FAQ)
서비스 유지보수 범위는 어디까지인가요?
한 덩어리로 적으면 반드시 다퉈요. 장애 대응, 하자 보수, 기능 개선, 운영 지원 네 갈래로 갈라서 각각 어디까지인지를 따로 적는 걸 권해요. 특히 기능 개선은 “기존 기능 수정”과 “새 기능 추가”의 경계를 문장으로 정의해둬야 해요. 화면이 하나 늘어나는 순간부터는 별도 견적이라는 식으로요.
개발 외주 유지보수는 어떻게 진행되나요?
보통 검수 완료 후 무상 하자보수 기간이 먼저 돌아가고, 그게 끝나면 유상 유지보수 계약으로 넘어가요. 하자보수 기간은 실무에서 1년으로 잡는 경우가 흔해요. 유상 계약으로 넘어가면 월 단위 정액이나 연간 요율 방식으로 계약하고, 접수 창구와 대응 시간을 SLA로 정해 운영해요.
앱 수정 유지보수 견적은 어떤 기준으로 나오나요?
수정 건수보다 수정의 성격이 값을 정해요. 문구나 이미지 교체처럼 데이터만 바뀌는 건 정액 범위 안에서 처리하는 경우가 많고, 화면 흐름이나 데이터 구조가 바뀌면 별도 견적으로 넘어가요. 앱은 여기에 OS 업데이트 대응이 매년 붙기 때문에, 이 항목이 정액에 포함되는지를 계약 전에 확인하는 게 좋아요.
9. 정리하면
유지보수 계약에서 값보다 먼저 정해야 하는 건 범위예요. 네 갈래로 갈라 적고, 등급마다 대응 시간을 숫자로 넣고, 제외 항목과 갱신 조건까지 채우면 대부분의 다툼이 계약 단계에서 끝나요.
아직 우리 서비스에 어떤 범위가 맞을지 감이 안 잡히더라도 괜찮아요. 지난 요청 목록만 있어도 방향은 잡을 수 있거든요. 지금 운영 상황부터 편하게 들려주세요 →
저희는 10년 넘게 50개가 넘는 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요.
관련 글