자체 SaaS 4종을 운영하며 배운 유지보수 우선순위

핵심 요약 — 유지보수 요청은 장애·버그·기능 개선·기술부채가 한꺼번에 쌓여요. 저희가 자체 SaaS 4종(D:VALUEUP·Likepro·Globing·Linkmix)을 운영하며 쓰는 기준은 두 축이에요 — 사용자 영향도(몇 명에게, 얼마나 크게 영향을 주는지)와 발생 빈도(한 번인지 반복되는지). 두 축을 기준으로 4단계 등급을 나누고, 등급마다 착수 시점을 다르게 둬요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“버그 수정이랑 새 기능 요청이랑 뭐부터 처리해야 하나요?” 유지보수 담당자라면 매주 듣는 질문이에요. 요청은 항상 동시에 몰리고, 전부 “급하다”는 말이 붙어 있거든요. 그런데 실제로 급한 것과 급해 보이는 것은 달라요. 저희가 자체 SaaS 4종을 함께 운영하며 이 둘을 가르는 데 쓰는 기준을 오늘 풀어볼게요.

---

1. 유지보수 요청은 왜 매번 한꺼번에 몰릴까요

서비스를 운영하다 보면 장애 알림, 사용자 문의, 팀 내부 개선 요청, 그리고 “언젠가 정리해야지” 하고 미뤄둔 코드까지 전부 같은 창구로 들어와요. 문제는 이 넷이 성격이 완전히 다른데도 같은 목록에 나란히 앉아 있다는 점이에요. 등급을 나누지 않으면 목소리 큰 요청이나 가장 최근에 들어온 요청이 먼저 처리되기 쉬워요. 정작 사용자 다수에게 영향을 주는 문제는 뒤로 밀리고요.

2. 저희가 쓰는 기준 — 사용자 영향도 × 발생 빈도

저희는 요청이 들어오면 두 질문부터 던져요. 첫째, 몇 명에게 얼마나 크게 영향을 주는가(사용자 영향도). 서비스 전체가 멈추는 문제와 특정 화면 하나가 불편한 문제는 같은 줄에 놓을 수 없어요. 둘째, 한 번 일어난 일인가, 반복되는 일인가(발생 빈도). 어쩌다 한 번 보고된 오류와 매일 여러 사용자가 겪는 오류는 처리 순서가 달라져야 해요.

용어 정리 — 여기서 말하는 ‘등급’은 계약서의 SLA(서비스수준협약, 장애 대응 시간을 미리 정해두는 조항) 등급과는 결이 달라요. SLA는 “몇 시간 안에 응답한다”는 약속이고, 저희가 쓰는 영향도·빈도 축은 그 약속을 지키기 전에 무엇부터 볼지를 정하는 내부 판단 기준이에요.

3. 장애·보안 패치는 왜 예외 없이 1순위일까요

두 축 중 하나만 가장 심각한 수준이어도 순위가 올라가는 예외가 딱 하나 있어요. 바로 장애와 보안 취약점이에요. 사용자 1명에게만 보이는 문제라도 보안 구멍이라면 영향도를 가장 높은 등급으로 놓고 즉시 처리해요. 반대로 아무리 사소해 보여도 서비스 전체가 멈추는 장애는 발생 빈도를 따질 필요 없이 최우선이고요. 이 둘은 “영향도 × 빈도” 계산이 아니라 별도의 최상위 층으로 따로 빼두는 게 저희 원칙이에요.

4. 사용자 영향이 큰 버그와 기능 개선 요청, 무엇이 먼저일까요

장애·보안을 뺀 나머지에서 가장 자주 헷갈리는 지점이 이거예요. 저희 기준은 단순해요. 많은 사용자에게 반복적으로 나타나는 버그가 한두 사용자의 개선 요청보다 항상 먼저예요. 기능 개선은 안 하면 아쉬운 정도지만, 반복되는 버그는 사용자가 서비스를 신뢰하지 않게 만들거든요. 다만 개선 요청이 여러 팀에서 동시에 들어오기 시작하면, 그 자체가 ‘반복되는 신호’로 바뀌어서 순위가 올라가요.

5. 기술부채 상환은 어느 자리에 둘까요

기술부채(technical debt, 당장 편한 선택이 나중에 이자처럼 불어나는 비용)는 저희 등급 체계에서 늘 가장 아래에 있어요. 다만 ‘무시한다’는 뜻은 아니에요. 저희는 기술부채를 따로 시간을 빼서 갚기보다, 그 코드를 다른 이유로 어차피 건드릴 때 함께 정리하는 방식을 써요. 언제 갚고 언제 미뤄도 되는지는 저희가 기술 부채, 언제 갚고 언제 미룰까요에서 따로 자세히 다룬 적이 있어요.

6. 자체 SaaS 4종에 실제로 적용하는 4단계 등급

말로 설명한 기준을 저희는 실제로 이렇게 표로 씁니다.

자사 실무 기준(사내 운영 판단 기준 — 계약 SLA 조항이 아니에요)

등급	해당하는 일	착수 시점
Tier 1 — 장애·보안	서비스 중단, 보안 취약점	발견 즉시
Tier 2 — 확산성 버그	다수 사용자에게 반복되는 오류	이번 주 안
Tier 3 — 기능 개선 요청	개별 사용자·팀의 개선 요청	다음 스프린트 계획에서 검토
Tier 4 — 기술부채	임시로 처리해둔 코드 정리	관련 코드를 다시 건드릴 때 함께

공식 외부 기준 — 업계에서 널리 쓰이는 SLA 심각도별 응답시간 벤치마크(참고용)

등급	응답 시간 기준
P1 Critical	15～30분
P2 High	1～2시간
P3 Medium	4～8시간
P4 Low	1영업일 이내

⚠️ 위 P1~P4는 업계에서 참고 삼아 쓰는 일반 벤치마크예요. 저희 실거래 계약 조항이 아니라, 발주 전에 “우리 시스템은 어느 등급에 해당하는지” 가늠하는 참고선으로만 봐주세요. 실제 응답 시간은 계약서의 SLA 등급에 따라 달라져요.

7. 외주 개발사에 유지보수를 맡길 때 이 기준을 어떻게 요청하면 될까요

발주자 입장에서는 “빠르게 대응하겠습니다”라는 구두 약속보다, 등급별로 무엇을 어떻게 나누는지 문서로 먼저 요청하는 게 안전해요. 저희가 자주 보는 흔한 실수는 유지보수 요율이나 유지보수 범위만 계약서에 넣고, 그 범위 안에서 “무엇을 먼저 처리하는지”는 안 정해두는 경우예요. 그러면 막상 여러 요청이 몰렸을 때 발주자가 원하는 순서와 개발사가 처리하는 순서가 어긋나요. 저희는 계약 전에 영향도·빈도 기준표를 먼저 보여드리고, 발주자가 생각하는 우선순위와 맞는지 확인하는 절차를 꼭 거쳐요.

유지보수 우선순위 기준부터 SLA 등급까지 함께 정리하고 싶다면 운영 경험을 바탕으로 상담받기 →

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요.

8. 자주 묻는 질문

유지보수 SLA는 우선순위 기준과 어떻게 다른가요?

SLA(서비스수준협약)는 등급별로 ‘몇 시간 안에 대응한다’는 약속이고, 우선순위 기준은 그 등급을 어떤 근거로 나눌지 정하는 판단 축이에요. 저희는 사용자 영향도와 발생 빈도, 두 축으로 등급을 먼저 정하고 그 위에 SLA 응답 시간을 얹어요.

서비스 유지보수 범위는 어디까지인가요?

기존 기능이 정상 작동하도록 지키는 게 기본 범위예요. 장애 대응·오류 수정·서버 대응이 포함되고, 새 기능 추가나 정책 변경 대응은 보통 별도 견적으로 처리해요. 계약 전에 범위를 항목별로 확인하시길 권해요.

개발 외주 유지보수는 어떻게 진행되나요?

요청이 접수되면 먼저 등급을 매기고, 등급에 따라 정해진 SLA 시간 안에 대응해요. 저희는 매주 쌓인 요청을 영향도·빈도 기준으로 다시 한 번 정렬한 뒤 그 주 작업 순서를 정해요.

9. 정리하며

유지보수에서 가장 흔한 착각은 “먼저 온 순서대로”, 또는 “요청한 사람 목소리가 큰 순서대로” 처리하는 거예요. 저희는 그 대신 사용자 영향도와 발생 빈도, 두 축으로 매번 다시 줄을 세워요. 장애·보안은 예외 없이 먼저, 기술부채는 코드를 다시 만질 때 자연스럽게 — 이 원칙만 지켜도 유지보수가 뒤엉키는 일이 크게 줄어요.

관련해서 함께 보면 좋은 글이에요.

• 기술 부채, 언제 갚고 언제 미룰까요 | SaaS 4종 운영 기준 3가지
• SaaS 4종 운영하며 배운 장애 대응 3원칙 | 다운 전에 갈려요
• 유지보수 비용은 얼마를 잡아야 할까요 | 요율·SLA 판단 기준