장애 대응·모니터링, 어디까지 하는 업체일까요 | 발주 전 검증 기준

먼저 짧게 답부터 드릴게요. “장애 나면 바로 대응해드립니다” 한 문장으로는 업체를 고를 수 없어요. 봐야 할 건 그 약속 뒤에 실제로 체계가 있느냐예요. 지금 서비스가 멈추면 누가 몇 분 안에 아는지(온콜), 무엇을 보고 있는지(모니터링 범위), 장애를 등급으로 나눠 등급마다 대응 시간을 적어뒀는지, 끝난 뒤에 재발을 막는 기록을 남기는지. 이 네 가지를 계약 전에 물어보면 말만 그럴듯한 업체와 실제로 운영해본 업체가 갈려요.

개발 외주 업체를 고를 때 제안서에는 대부분 “안정적인 운영과 신속한 장애 대응”이 적혀 있어요. 그런데 이 문장은 거의 모든 업체가 똑같이 써요. 정작 발주하고 나서 서비스가 처음 멈췄을 때, 담당자가 그 사실을 고객 전화로 알게 되는 경우가 생각보다 많아요. 차이는 “대응한다”는 의지가 아니라 그 대응을 받치는 구조에서 나요. 그 구조는 말로 듣는 게 아니라 발주 전에 몇 가지 질문으로 확인할 수 있어요.

1. 왜 ‘모니터링 됩니다’는 말로는 부족할까요

모니터링이라는 말은 범위가 너무 넓어요. 서버가 켜져 있는지만 보는 것도 모니터링이고, 사용자가 실제로 결제에 성공하는지까지 보는 것도 모니터링이에요. 둘 사이의 간격이 서비스 품질을 가르는데, 제안서에는 둘 다 “모니터링”이라는 같은 단어로 적혀요.

그래서 업체가 쓰는 단어를 그대로 믿기보다, “무엇을 어느 수준까지 보느냐”를 구체적으로 물어봐야 해요. 핵심 기능이 멎었을 때 사람보다 먼저 아는 구조인지, 아니면 서버 전원만 확인하는 수준인지. 이 질문 하나로 업체의 실제 운영 깊이가 꽤 드러나요.

2. 지금 장애가 나면 누가 몇 분 안에 아나요

가장 먼저 확인할 건 온콜(on-call), 즉 당직 체계예요. 평일 낮에만 사람이 있는지, 밤이나 주말에 터지면 누가 받는지를 물어보세요. 알림이 특정 한 사람 휴대폰으로만 가는 구조라면, 그 사람이 자리를 비우는 순간 대응이 멈춰요.

좋은 답은 “담당자가 못 받으면 다음 사람에게 넘어가는 순서가 있다”예요. 알림이 울리고 몇 분 안에 응답이 없으면 자동으로 다음 담당자에게 전달되는 구조(에스컬레이션)가 있는지, 야간·주말 대응이 계약에 포함되는지 따로 적는지를 확인하면 돼요. 여기서 말이 흐려지는 업체는 실제로는 주간 대응만 생각하고 있을 가능성이 높아요.

3. 무엇을 보고 있나요 — 모니터링 범위

모니터링은 보통 세 겹이에요. 서버 자원(CPU·메모리) 같은 지표, 무슨 일이 있었는지 남는 로그, 그리고 실제 사용자 흐름을 흉내 내 주기적으로 찔러보는 합성 점검이에요. 세 번째까지 하는 업체는 “로그인이 안 되는데 서버는 멀쩡해 보이는” 상황을 사람보다 먼저 잡아내요.

업체에 “핵심 기능이 실패하면 사람이 신고하기 전에 알 수 있나요”라고 물어보세요. 요즘은 지표·로그·추적을 한데 모아 보는 옵저버빌리티(observability) 수준을 갖추는 게 흐름인데, 한 업계 조사에서는 국내 응답자의 상당수가 2026년까지 이런 역량을 두루 갖추겠다고 답하기도 했어요. 다만 중요한 건 도구를 몇 개 쓰느냐가 아니라, 우리 서비스에서 가장 중요한 흐름을 실제로 지켜보느냐예요.

4. 장애 등급과 대응 시간이 계약에 적혀 있나요

모든 장애를 똑같이 다루면 정작 급한 일에 손이 늦어요. 그래서 장애를 심각도로 나누고, 등급마다 “몇 분 안에 응답하고 몇 시간 안에 복구를 목표로 한다”를 정해둬야 해요. 전체 서비스가 멈춘 1등급과 일부 화면이 느린 3등급은 대응 속도가 달라야 하니까요.

유지보수 위탁 계약을 다룬 국내 자료에서도 계약서에 장애 심각도 등급 정의와 대응 절차, 책임과 권한을 명시하라고 설명해요. 업체에 “장애 등급을 어떻게 나누고 등급별 목표 시간을 계약서에 적어주시나요”라고 물었을 때, 숫자로 답이 나오면 운영을 해본 곳이에요. 이 부분을 범위와 숫자로 어떻게 정하는지는 유지보수 계약(SLA), 어디까지 넣어야 할까요에 더 정리해뒀어요.

5. 터지기 전에 막나요, 터진 뒤에 아나요

대응에는 두 가지 자세가 있어요. 장애가 난 뒤에 알아차리고 복구하는 자세와, 지표가 위험선에 가까워질 때 미리 손을 쓰는 자세예요. 사후에만 반응하는 방식은 서비스가 이미 멈춘 뒤에야 움직이게 돼서, 장애 통보와 실제 조치 사이에 공백이 생겨요.

업체에 “디스크가 꽉 차기 전에, 응답이 느려지기 시작할 때 경보가 울리나요”라고 물어보세요. 임계치를 미리 걸어두고 그 선을 넘기 전에 대응하는 구조라면, 사용자가 불편을 느끼기 전에 문제가 끝나요. 이 선제적 자세가 있느냐 없느냐가, 같은 “장애 대응”이라는 말 안에서 큰 차이를 만들어요.

6. 장애가 끝난 뒤 무엇을 남기나요

좋은 운영은 장애를 복구하는 데서 끝나지 않아요. 왜 터졌는지, 다음에 안 터지게 뭘 바꿨는지를 기록으로 남겨요. 이 기록이 쌓이면 같은 장애가 반복되지 않고, 혹시 나중에 업체를 바꾸더라도 다음 팀이 과거 이력을 보고 이어받을 수 있어요.

업체에 “장애가 끝나면 원인과 재발 방지 대책을 문서로 받나요”라고 물어보세요. “그때그때 구두로 공유한다”는 답이 돌아오면, 몇 달 뒤 같은 문제가 또 나도 아무도 기억하지 못해요. 넘겨받을 수 있는 운영은 이런 기록에서 시작해요.

7. 말로 듣는 것과 계약서로 확인할 것

지금까지의 질문을 한 표로 정리하면, 제안서에 적힌 말과 계약서에 넣어야 할 내용의 차이가 보여요.

항목	제안서에 흔히 적히는 말	계약 전에 확인·명시할 것
감시 범위	”24시간 모니터링”	핵심 기능 실패를 사람보다 먼저 감지하는지
당직	”신속 대응”	야간·주말 온콜 포함 여부 + 에스컬레이션 순서
대응 속도	”빠른 복구”	장애 등급별 응답·복구 목표 시간(숫자)
예방	”안정적 운영”	임계치 경보로 터지기 전 대응하는지
기록	”문제 해결”	사후 원인·재발 방지 문서 제공 여부

용어 한 줄 정리 — 온콜(on-call): 정해진 담당자가 장애 알림을 받아 대응하는 당직 체계예요. 옵저버빌리티(observability): 지표·로그·추적을 모아 “지금 왜 이런지”를 들여다보는 역량이에요. 에스컬레이션(escalation): 첫 담당자가 못 받으면 다음 담당자에게 자동으로 넘기는 절차예요. MTTR: 장애가 나서 복구될 때까지 걸린 평균 시간이에요.

8. 운영해본 개발사는 장애를 어떻게 볼까요

직접 서비스를 운영해본 개발사는 장애가 “언젠가 반드시 난다”는 걸 전제로 설계해요. 그래서 “안 터지게 하겠다”보다 “터졌을 때 몇 분 안에 알고, 어떻게 복구하고, 다음에 안 나게 뭘 남길지”를 먼저 정해둬요. 운영을 안 해본 곳은 이 질문 자체를 받아본 적이 없어서 답이 흐려져요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하며 자체 SaaS 4종을 직접 운영해왔어요. 롯데·캐논 같은 곳과도 함께해 왔고요. 그러다 보니 모니터링과 장애 대응을 “운영자의 눈”으로 보게 됐어요. 개발 외주 업체를 고르는데 장애 대응 수준을 어떻게 검증할지 막막하다면 어떤 질문을 던질지 함께 짚어드릴게요 →. 발주 전에 장애 대응을 숫자로 정하는 법은 장애 대응·모니터링, 발주 전에 숫자로 정할 6가지에, 업체의 레퍼런스를 검증하는 법은 개발 외주 업체 레퍼런스, 어떻게 확인할까요에 더 자세히 정리해뒀어요.

자주 묻는 질문

작은 서비스에도 이 정도 장애 대응 체계가 필요한가요?

규모에 맞게 덜어내면 돼요. 사용자가 적은 초기 서비스라면 야간 온콜까지는 과할 수 있어요. 다만 “핵심 기능이 멎으면 사람보다 먼저 안다”와 “장애 원인을 기록으로 남긴다”는 규모와 상관없이 처음부터 넣는 게 좋아요. 나중에 사용자가 늘면 그 위에 당직과 등급을 얹으면 돼요.

모니터링 도구는 업체가 쓰던 걸 그대로 써도 되나요?

도구 자체보다 계정과 설정이 우리 것인지가 중요해요. 업체가 자기 계정으로만 모니터링을 걸어두면, 업체를 바꿀 때 감시가 통째로 끊겨요. 발주 단계에서 “모니터링 계정과 설정도 우리 명의로 두거나 인수인계 받을 수 있나요”를 확인해두세요.

장애 대응을 유지보수 계약에 꼭 따로 적어야 하나요?

네. 개발과 유지보수를 한 계약에 뭉뚱그리면 장애 대응 범위가 가장 먼저 흐려져요. 응답·복구 목표 시간, 당직 범위, 사후 보고 여부를 유지보수 조항에 숫자와 함께 적어두면 나중에 다툴 일이 줄어요.