요청이 한꺼번에 몰리면 무엇부터 고칠까요 | 유지보수 우선순위
유지보수 요청이 몰릴 때 순서를 정하는 기준을 정리했어요. 장애·하자·개선·신규 네 갈래로 가르고 영향 범위로 등급을 매기면 다툼이 줄어요. 공공 현장은 유지관리요율 10% 미만이 41.4%로 가장 많았어요. 자체 SaaS 4종을 운영하며 쓰는 기준이에요.
핵심 요약
- 유지보수 요청은 성격이 다른데 한 줄로 쌓여요. 장애·하자·개선·신규 네 갈래로 먼저 갈라야 순서가 보여요.
- 순서는 목소리 크기가 아니라 영향 범위와 우회 가능 여부로 정해요. 이 둘을 표로 만들면 등급이 저절로 나와요.
- 공공 현장 조사에서 유지관리요율은 10% 미만이 41.4%로 가장 많았고, 민간 평균은 14.2%였어요. 요율이 낮으면 붙는 인력도 줄어요.
- 자체 SaaS 4종을 직접 운영하며 쓰는 기준과, 발주 단계에서 미리 적어 둘 문장을 정리했어요.
“오픈하고 두 달쯤 지나니까 요청 목록이 40건이 넘었어요. 개발사는 순서대로 하겠다는데, 저희가 보기엔 순서가 이상해요.”
운영에 들어간 서비스에서 가장 자주 나오는 이야기예요. 개발사가 게으른 것도, 발주사가 까다로운 것도 아니에요. 무엇을 먼저 할지 정하는 기준이 계약 어디에도 없었던 것뿐이에요.
1. 요청은 왜 항상 한꺼번에 몰릴까요
오픈 직후가 사용자가 처음으로 실제 데이터를 넣어 보는 시기이기 때문이에요.
개발 기간에 하는 테스트는 아무리 꼼꼼해도 만든 사람의 상상 안에서 도는 일이에요. 실제 사용자는 전혀 다른 순서로 누르고, 전혀 다른 값을 넣어요. 그래서 오픈 2～8주 사이에 요청이 집중돼요.
이때 목록을 그냥 쌓아 두면 두 가지가 벌어져요. 급한 장애가 개선 요청에 밀리고, 반대로 사소한 요청이 “이것부터 해 달라”는 전화 한 통으로 앞으로 당겨져요. 둘 다 계약을 지키지 못하는 상황이 아니라, 지킬 기준 자체가 없는 상황이에요.
2. 먼저 갈라야 할 네 갈래
성격이 다르면 돈을 내는 주체도, 대응 속도도 달라요.
| 갈래 | 무엇인가 | 비용 부담 | 대응 속도 |
|---|---|---|---|
| 장애 | 지금 서비스가 안 돌아요 | 유지보수 계약 안 | 가장 빠르게 |
| 하자 | 원래 되기로 한 게 안 돼요 | 무상 하자보수 기간 안이면 개발사 | 빠르게 |
| 개선 | 되긴 되는데 불편해요 | 유지보수 계약 안 (공수 한도) | 월 단위 계획 |
| 신규 | 없던 기능을 새로 만들어요 | 별도 계약 | 별도 일정 |
현장에서 가장 자주 부딪히는 건 하자와 개선의 경계예요. 발주사는 하자라 하고 개발사는 개선이라 하죠. 이 경계는 검수 기준 문서로만 갈릴 수 있어요. 검수할 때 무엇을 합격으로 봤는지 적혀 있지 않으면, 나중에는 기억으로 다투게 돼요.
용어 정리 — 하자보수: 납품한 결과물이 약속한 대로 동작하지 않을 때 무상으로 고쳐 주는 기간이에요. 유지보수: 정상 동작하는 시스템을 계속 돌보는 유상 계약이고요. SLA: 장애를 몇 시간 안에 처리할지처럼 서비스 수준을 숫자로 약속하는 조항이에요. 실무에서는 “이건 하자니까 무상, 저건 개선이라 공수 차감”처럼 말해요.
3. 우선순위는 무엇으로 정할까요
영향 범위와 우회 가능 여부, 두 축이면 충분해요.
| 우회 방법이 없음 | 우회 방법이 있음 | |
|---|---|---|
| 전체 사용자 | 1등급 — 즉시 | 2등급 — 당일 |
| 일부 사용자 | 2등급 — 당일 | 3등급 — 주간 계획 |
| 한두 명 | 3등급 — 주간 계획 | 4등급 — 월간 계획 |
두 축으로 잡는 이유가 있어요. “얼마나 심각한가”는 사람마다 다르게 느끼는데, 몇 명이 막히는가와 다른 길이 있는가는 대체로 합의가 돼요. 결제가 안 되면 1등급, 엑셀 내려받기가 안 되는데 화면에서 볼 수는 있으면 2등급이 되는 식이에요.
이 표를 계약서에 붙여 두면 요청을 접수하는 순간 등급이 정해져요. 다툴 여지가 줄고, 개발사도 “지금 1등급이 하나 있어서 그 요청은 오후에 보겠다”고 설명할 수 있어요.
4. 등급을 숫자로 적어 두면 무엇이 달라지나요
“빠르게”가 사라져요. 계약서에서 가장 위험한 단어가 빠르게, 신속히, 최대한이에요. 서로 다른 숫자를 떠올리면서 같은 단어를 읽거든요.
| 자사 실무 기준 예시 (등급별 약속) | 최초 응답 | 임시 조치 | 근본 수정 |
|---|---|---|---|
| 1등급 | 30분 이내 | 4시간 이내 | 협의 |
| 2등급 | 2시간 이내 | 당일 | 주 단위 |
| 3등급 | 1영업일 | — | 월 단위 계획 |
| 4등급 | 3영업일 | — | 분기 계획 |
자사 실무 기준 예시 — 위 표는 저희가 운영 계약에서 출발점으로 쓰는 값이에요. 프로젝트 성격에 따라 조정해요. 업계 표준 수치가 아니고, 자사 실거래 통계도 아니에요.
임시 조치와 근본 수정을 갈라 적는 게 핵심이에요. 장애가 났을 때 사용자가 기다리는 건 원인 분석이 아니라 일단 쓸 수 있게 되는 시점이에요. 두 시점을 하나로 묶어 두면 개발사는 근본 수정까지 마쳐야 답할 수 있다고 생각하고, 발주사는 아무 연락이 없다고 느껴요.
5. 매달 쓸 수 있는 손이 얼마인지 아세요
우선순위를 정해도 손이 부족하면 순서만 예쁘게 밀려요. 그래서 등급 다음에 볼 건 요율이에요.
| 공식 외부 기준 (SW산업 실태조사, 2018년 조사 기준) | 비율 |
|---|---|
| 공공 부문 유지관리요율 10% 미만 적용 기관 | 41.4% |
| 10～15% 미만 | 53.3% |
| 15～20% 미만 | 4.3% |
| 20% 이상 | 0.9% |
| 민간 부문 평균 | 14.2% (공공보다 4.0%p 높음) |
정부 권고는 20% 이상인데, 현장은 대부분 10～15%에 몰려 있어요. 숫자만 보면 낮을수록 이득 같지만 반대예요. 요율이 낮으면 붙일 수 있는 인력이 줄고, 1등급 장애가 겹치는 순간 개선은 통째로 멈춰요.
한 달에 쓸 수 있는 공수를 가늠하려면 공식 노임을 옆에 두면 돼요. KOSA 2026년 적용 기준으로 응용SW개발자 월 평균임금은 775만 원, 전체 일 평균임금은 41만 4,762원이에요. 월 유지보수비가 300만 원이라면 실제로 붙는 손은 하루 몇 시간 수준이라는 뜻이죠.
6. 자체 SaaS를 운영하며 정한 규칙
저희가 실제로 쓰는 규칙은 셋이에요. 자체 SaaS 4종을 직접 돌리면서 다듬은 것들이에요.
첫째, 돈과 데이터가 움직이는 기능은 한 등급 위로 올려요. 화면이 깨진 건 불편하지만, 결제가 두 번 되거나 데이터가 사라지면 되돌리는 데 며칠이 걸려요.
둘째, 같은 증상이 세 번 반복되면 개선이 아니라 구조 문제로 봐요. 그때는 임시 조치를 멈추고 원인을 다시 파요. 롯데백화점 수원 푸드홀 실시간 혼잡도 시스템을 만들 때, 관리자 페이지에서 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 계속 고치는 대신 초기 JavaFX 구현을 C#으로 다시 만들어 해결했어요. 반복되는 증상을 붙잡고 있으면 공수만 녹아요.
셋째, 테스트 조합이 많은 기능은 운영 공수를 따로 잡아요. 캐논코리아 카메라 펌웨어 업데이트 유틸리티를 만들 때 가장 부담이 컸던 건 기능 개발이 아니라 다양한 펌웨어 버전과 장치 조합을 테스트하는 일이었어요. 코닥 인스턴트 프린터 연동 앱도 마찬가지로 아이폰·안드로이드의 수많은 기기와 인화 장치 사이의 연결·오류 처리가 핵심 난제였고요. 이런 기능은 오픈 뒤에도 새 기기가 나올 때마다 손이 가요.
운영사 Tip — 매달 유지보수 보고서에 등급별 건수를 넣어 달라고 요청해 보세요. 1등급이 계속 늘면 구조 문제이고, 4등급만 쌓이면 개선 공수가 모자란 거예요. 목록만 받으면 이 차이가 안 보여요.
7. 발주 단계에서 미리 넣어 둘 것
구축 계약을 쓸 때 운영 이야기를 같이 적어야 해요. 오픈 다음 달에 정하려 하면 협상력이 이미 한쪽으로 기울어 있어요.
| 미리 정할 항목 | 적어 둘 내용 |
|---|---|
| 등급 표 | 영향 범위 × 우회 가능 여부 기준과 등급별 대응 시간 |
| 무상 하자보수 | 기간과 범위, 하자와 개선의 경계 |
| 월 개선 공수 | 며칠을 개선에 쓸지, 남으면 이월할지 |
| 대응 시간대 | 평일 주간인지, 야간·주말을 포함할지 |
| 보고 | 월별 등급 건수와 처리 현황 |
개발 외주를 맡길 때 대부분 구축 범위에만 집중해요. 그런데 서비스의 수명으로 보면 구축은 짧고 운영은 길어요. 운영 조건을 먼저 정하고 구축 견적을 받으면, 만드는 방식 자체가 달라지는 경우도 많아요.
운영까지 함께 볼 개발사를 찾고 있다면, 지금 상황부터 편하게 들려주세요 →
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고, 만드는 일보다 오래 이어지는 게 운영이라는 걸 저희 서비스로 먼저 겪었어요.
관련해서 함께 보면 좋은 글
8. 자주 묻는 질문
유지보수 계약에 우선순위 기준을 넣으면 개발사가 싫어하지 않나요?
반대인 경우가 많아요. 기준이 없으면 개발사는 매번 어느 요청을 먼저 잡을지 눈치로 정하게 되고, 그러다 보면 목소리 큰 쪽이 먼저가 돼요. 등급과 대응 시간이 숫자로 적혀 있으면 개발사도 인력을 미리 잡아 둘 수 있어요. 다만 등급을 전부 최상위로 올려 두면 요율이 따라 올라가니, 정말 급한 것만 위로 두는 편이 서로에게 좋아요.
월 유지보수 요율은 몇 퍼센트로 시작하면 될까요?
구축비의 10～15% 선에서 시작하는 사례가 많아요. 정부는 20% 이상을 권고하지만 현장은 그보다 낮게 형성돼 있어요. 금액을 먼저 정하고 대응 수준을 맞추기보다, 장애 대응 시간과 월 개선 공수를 먼저 정한 다음 그에 맞는 금액을 계산하는 순서를 권해요. 야간·주말 대응을 넣으면 요율이 눈에 띄게 올라가요.
개선 요청이 계속 밀리는데 어떻게 해야 하나요?
월 개선 공수 한도가 계약에 없을 가능성이 커요. 장애와 하자는 밀릴 수 없으니 개선이 늘 뒤로 가거든요. 매달 며칠은 개선에 쓴다고 따로 떼어 두고, 그 며칠을 무엇에 쓸지는 발주사가 고르는 구조가 현실적이에요. 남은 공수를 다음 달로 이월할지도 함께 정해 두세요.
9. 마무리
유지보수에서 다투는 이유는 대개 속도가 아니라 순서예요. 네 갈래로 가르고, 영향 범위와 우회 가능 여부로 등급을 매기고, 등급마다 시간을 숫자로 적어 두면 대부분의 실랑이가 사라져요.
그다음에 볼 게 요율이에요. 순서를 아무리 잘 정해도 매달 붙는 손이 없으면 목록은 그대로 쌓이거든요. 대응 수준을 먼저 정하고 금액을 맞추는 순서, 이게 운영을 오래 해 보고 얻은 결론이에요.