장애 대응·모니터링, 발주 전에 숫자로 정할 6가지

핵심 요약 — 장애 이야기는 대개 계약서 맨 뒤에 “성실히 대응한다” 한 줄로 들어가요. 그런데 정작 장애가 나면 필요한 건 성실함이 아니라 숫자예요. 누가 먼저 알아차리는지, 몇 시간 안에 조치하는지, 밤에도 연락이 닿는지가 정해져 있어야 해요. 이 세 가지는 견적 단계에서 말하면 비용에 반영되고, 착수 뒤에 말하면 추가 공수가 돼요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“서버 내려가면 바로 봐주시는 거죠?”

계약 직전에 자주 나오는 확인이에요. 대부분 개발사도 “네, 그럼요”라고 답해요. 둘 다 거짓말은 아닌데, 여기서 말하는 ‘바로’가 서로 다른 시간을 뜻하는 경우가 많아요. 발주자는 30분을 생각하고 개발사는 다음 영업일을 생각하는 식이에요.

개발외주계약서에 이 간극을 메우는 문장이 없으면, 문제는 장애가 났을 때가 아니라 그 다음에 생겨요.

---

1. 장애 이야기는 왜 견적 단계에서 해야 할까요

값이 달라지기 때문이에요.

장애 대응은 기능이 아니라 약속이에요. “1시간 안에 조치한다”는 문장은 코드 한 줄이 아니라 그 시간에 사람이 붙어 있어야 한다는 뜻이고요. 이건 개발 범위가 아니라 인력 구조의 문제라서, 견적을 다 받은 뒤에 요구하면 금액이 다시 움직여요.

반대로 견적 단계에서 미리 말하면 개발사는 처음부터 그 조건으로 구성을 짜요. 알림을 어디로 보낼지, 로그를 얼마나 남길지, 재시작을 자동으로 할지가 설계에 들어가요. 같은 요청인데 시점에 따라 추가 비용이 되기도 하고 기본 구성이 되기도 해요.

용어 정리 — SLA(서비스 수준 협약) 서비스를 어느 수준으로 유지할지 숫자로 적은 약속이에요. 가동률 몇 퍼센트, 장애 조치 몇 시간, 못 지키면 어떻게 할지가 들어가요. 실무에선 “SLA 걸었어요?”를 “장애 기준을 문서로 정했느냐”는 뜻으로 써요. 소프트웨어개발외주에서는 유지보수 계약에 붙는 경우가 많아요.

2. 하자보수·유지보수·장애 대응은 어떻게 다른가요

셋을 하나로 뭉뚱그리면 나중에 “이건 범위 밖입니다”라는 답을 듣게 돼요.

• 하자보수 — 납품한 것이 약속과 다를 때 무상으로 고치는 일이에요. 기간이 정해져 있어요.
• 유지보수 — 잘 돌아가는 걸 계속 손보고 바꾸는 일이에요. 유상이고 대개 월 단위예요.
• 장애 대응 — 지금 멈춘 걸 다시 켜는 일이에요. 시간이 핵심이에요.

앞의 둘은 “무엇을 고치나”의 문제고 셋째는 “언제까지 고치나”의 문제예요. 그래서 유지보수 계약만 맺어두고 안심하면 안 돼요. 유지보수비를 내고 있어도 밤에 연락 닿는 조건이 없으면 밤에는 아무 일도 안 일어나요.

유지보수업체를 따로 두는 경우라면 이 구분이 더 중요해요. 만든 곳과 봐주는 곳이 다르면 장애 원인을 두고 서로 미루기 쉬워서, 누가 1차로 받는지를 문서에 적어둬야 해요.

3. 장애가 났다는 걸 누가 먼저 아나요

여기가 가장 자주 비어 있는 칸이에요.

모니터링이 없는 서비스는 고객이 감지 장치예요. 사용자가 전화해서 “안 돼요”라고 말해줘야 알게 되는 구조죠. 이때 복구 시간을 아무리 짧게 적어놔도 소용이 없어요. 시계가 언제 시작되는지를 아무도 모르니까요.

장애 대응 능력을 볼 때 쓰는 지표가 두 개 있어요. 문제가 생긴 시점부터 알아차리기까지 걸린 시간(MTTD), 그리고 알아차린 뒤 정상으로 되돌리기까지 걸린 시간(MTTR)이에요. 대부분의 회사가 뒤쪽만 신경 쓰는데, 실제로 사용자가 겪은 불편은 두 시간의 합이에요.

그래서 발주 단계에서 물어볼 질문은 이거예요. “장애가 나면 누구 휴대폰이 울리나요?” 답이 “고객센터로 연락이 올 거예요”라면 모니터링이 없는 거예요.

4. 복구 시간은 몇 시간으로 적어야 할까요

기준 삼을 만한 공식 자료가 있어요.

행정안전부는 공공 정보시스템 운영을 위한 서비스 수준 협약 표준안을 마련해두고 있어요. 여기서는 장애조치 최대 허용시간을 필수 지표로 두고 1등급 시스템은 2시간, 2등급은 3시간 안에 조치를 끝내도록 잡고 있어요. 이를 넘기면 지체한 시간(분) 단위로 제재금이 계산되고, 서비스 중요도에 따라 가중치가 붙어요. 종합 수준이 기준에 못 미치면 월 계약금액의 최대 20%까지 위약금이 부과되는 구조고요. 1·2등급 시스템에 시범 적용한 뒤 2027년부터 전 기관 의무 적용으로 넘어갈 예정이에요.

민간 발주라면 이 숫자를 그대로 쓸 필요는 없어요. 다만 “몇 시간”이라는 형식 자체를 빌려오는 건 도움이 돼요.

공식 외부 기준

구분	기준
행안부 공공 SLA 표준안 · 1등급	장애조치 2시간 이내
행안부 공공 SLA 표준안 · 2등급	장애조치 3시간 이내
미달 시 위약금	월 계약금액의 최대 20%
KOSA 유지관리 등급 요율	초기 개발비 대비 연 11～19%

자사 실무 기준 예시 (저희가 자체 서비스에 쓰는 구분 — 실거래 통계가 아니라 운영 기준이에요)

등급	해당 기능	대응 방식
1등급	로그인·결제처럼 멈추면 매출이 멈추는 기능	즉시 알림, 시간 외에도 대응
2등급	조회·검색처럼 불편하지만 우회 가능한 기능	업무 시간 내 당일 조치
3등급	통계·관리자 화면처럼 급하지 않은 기능	다음 정기 배포에 포함

전 기능에 1등급을 걸면 견적이 크게 올라요. 멈추면 안 되는 것만 골라내는 일이 실제로 비용을 정해요.

5. 모니터링은 어디까지 붙이고 얼마가 들까요

모니터링은 크게 세 겹이에요.

1. 살아 있는지 보는 것 — 서버가 응답하나요. 가장 싸고 대부분 기본으로 붙어요.
2. 잘 돌아가는지 보는 것 — 느려지지 않았나요, 오류가 늘지 않았나요. 여기서부터 도구가 필요해요.
3. 왜 그런지 보는 것 — 어느 구간에서 막혔나요. 원인 추적까지 하는 층이에요.

둘째 층부터는 도구를 골라야 해요. 직접 설치해 쓰는 오픈소스 계열(프로메테우스·그라파나 조합 등)과 월 사용료를 내는 관리형 서비스(데이터독·뉴렐릭 등, 국내는 와탭 같은 선택지)로 갈려요. 앞은 사용료가 없는 대신 관리할 사람이 필요하고, 뒤는 붙이기 쉬운 대신 데이터 양에 따라 매달 돈이 나가요.

발주 관점에서 정할 건 도구 이름이 아니에요. “어느 층까지 볼 것인가”와 “그 사용료를 누가 내는가”예요. 홈페이지운영비용을 잡을 때 이 항목이 빠져 있다가 나중에 붙는 경우가 흔해요.

직접 운영해보니 저희가 자체 SaaS를 굴리면서 가장 값을 한 건 화려한 대시보드가 아니라 알림 규칙이었어요. 화면은 아무도 안 보고 있을 때가 많거든요. “5분 동안 오류가 몇 건 넘으면 누구에게 알린다” 같은 규칙 몇 줄이 실제로 감지 시간을 줄였어요. 대시보드부터 만들자는 제안이 오면, 알림부터 걸고 화면은 나중에 하자고 말씀드리는 편이에요.

6. 야간·주말·공휴일은 어떻게 정하나요

여기서 비용 차이가 가장 크게 벌어져요.

“24시간 대응”이라는 말은 여러 뜻으로 쓰여요. 밤에도 사람이 깨어 있다는 뜻일 수도 있고, 밤에 알림은 오지만 조치는 아침에 한다는 뜻일 수도 있어요. 둘은 완전히 다른 비용인데 계약서에는 같은 문장으로 적히곤 해요.

정할 건 세 가지예요.

• 연락이 닿는 시간 — 몇 시부터 몇 시까지 전화를 받나요
• 조치를 시작하는 시간 — 연락받고 몇 분 안에 손을 대나요
• 연락 수단 — 전화인가요, 메신저인가요, 담당자 한 명인가요 당번인가요

담당자 개인 번호 하나에 의존하는 구조는 피하는 게 좋아요. 그 사람이 휴가를 가면 체계가 통째로 멈춰요. 대신 받는 창구를 정해두고 그 뒤는 개발사가 알아서 돌리는 방식이 안정적이에요.

7. 발주 전에 숫자로 정할 6가지

견적서를 받기 전에 아래 여섯 칸을 채워보세요. 채우다 막히는 칸이 있으면 그 부분이 나중에 분쟁이 될 자리예요.

#	정할 것	적는 방식
1	멈추면 안 되는 기능	기능 이름으로 3개 이내
2	감지 주체	자동 알림인가 사람 신고인가
3	연락 응답 시간	접수 후 ○분 이내
4	조치 완료 목표	등급별 ○시간 이내
5	대응 가능 시간대	평일 ○～○시 / 야간·주말 여부
6	모니터링 범위와 부담 주체	어느 층까지, 사용료는 누가

흔히 놓치는 지점도 함께 짚어둘게요. 첫째, 장애 대응 조항이 유지보수 계약에만 있고 구축 계약에는 없는 경우예요. 구축이 끝나고 유지보수 계약을 맺기 전 공백기에 장애가 나면 기준이 없어요. 둘째, 복구 시간만 적고 어디까지가 장애인지를 안 적은 경우예요. “느려진 것”이 장애인지 아닌지로 다투게 돼요. 셋째, 모니터링 도구 계정이 개발사 이름으로만 있는 경우예요. 계약이 끝나면 그동안 쌓인 기록도 같이 사라져요.

8. 자주 묻는 질문 (FAQ)

작은 서비스에도 이런 게 필요할까요

규모보다 멈췄을 때 무슨 일이 생기는지로 판단해요. 사내에서만 쓰는 관리 도구라면 다음 날 고쳐도 되는 경우가 많아요. 반면 결제가 오가거나 현장에서 실시간으로 쓰는 시스템이면 규모가 작아도 기준이 필요해요. 저희가 맡았던 실시간 혼잡도 시스템처럼 현장에서 바로 쓰는 서비스는 화면이 몇 개인지보다 멈춘 시간이 몇 분인지가 훨씬 중요했어요.

유지보수 비용에 장애 대응이 포함된 거 아닌가요

포함일 수도 아닐 수도 있어서 확인이 필요해요. 유지보수비는 대개 “월 몇 시간의 작업”으로 계산되는데, 장애 대응은 그 시간을 언제 쓰느냐의 문제라 성격이 달라요. 요율과 포함 범위를 함께 보는 방법은 유지보수 비용과 요율 판단 기준에 정리해뒀어요.

구축과 운영을 같은 회사에 맡기는 게 좋을까요

장애 대응만 놓고 보면 같은 곳이 유리해요. 만든 사람이 구조를 알고 있어서 원인을 찾는 시간이 줄어요. 다만 장기 운영에서는 비용 구조가 달라지기도 해서, 구축(SI)과 운영(SM)이 어떻게 갈리는지를 먼저 보고 정하시는 걸 권해요.

9. 마무리 — 장애 대응은 사람 문제가 아니라 문서 문제예요

정리하면 이래요. 장애가 났을 때 갈리는 건 개발사의 성의가 아니라 미리 정해둔 숫자예요. 누가 먼저 알아차리는지, 몇 시간 안에 조치하는지, 밤에는 어떻게 하는지. 이 세 칸이 채워져 있으면 대부분의 다툼은 생기지 않아요.

그리고 이 이야기는 견적 전에 꺼낼수록 싸요. 착수한 뒤에 요구하면 구조를 다시 만져야 해서 추가 공수가 되지만, 견적 단계에서 말하면 처음부터 그렇게 짜여요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 실시간 시스템은 오픈이 끝이 아니라 시작이라, 배포 후 조정 구간까지 처음부터 범위에 넣고 봐요. 지금 준비 중인 프로젝트에서 어느 기능까지 1등급으로 잡아야 할지 애매하시다면 기능별로 나누는 것부터 같이 정리해드릴게요 →

관련 글

• 유지보수 비용은 얼마를 잡아야 할까요
• SI와 SM은 어떻게 다를까요
• 롯데백화점 푸드홀 실시간 혼잡도 시스템 구축 사례