서비스가 멈췄습니다 — 개발사에 무엇을 어떤 순서로 요청하나

개발사에 연락하기 전 2분이면 확인됩니다. 이걸 알려주면 복구가 훨씬 빨라집니다.

1단계 — 나만 안 되는가

휴대폰 데이터로 접속해 봅니다(회사 와이파이 끄고). 여기서 되면 사내 네트워크 문제이지 서비스 장애가 아닙니다.

2단계 — 주소가 살아 있는가

브라우저에 "사이트에 연결할 수 없음" → 도메인이나 서버가 죽었습니다

"500 오류", "잠시 후 다시 시도" → 서버는 살아 있고 프로그램이 죽었습니다

화면은 뜨는데 특정 기능만 안 됨 → 그 기능이나 연동된 외부 서비스 문제입니다

이 셋은 원인도 복구 시간도 완전히 다릅니다.

3단계 — 언제부터인가

마지막으로 정상 동작한 시각을 확인합니다. 그 사이에 무슨 일이 있었는지가 원인의 절반입니다.

개발사가 뭔가 배포했다

결제사·문자 서비스에서 점검 공지가 왔다

도메인이나 인증서 만료일이 지났다

인증서 만료는 의외로 흔합니다. "이 사이트는 안전하지 않습니다" 경고가 뜨면 십중팔구 이것이고, 갱신만 하면 끝납니다.

"사이트가 안 돼요" 로는 개발사도 시작할 수 없습니다. 아래를 한 번에 보냅니다.

필수:

발생 시각 — "오늘 오후 3시 10분경부터" (마지막 정상 확인 시각도)

증상 — 화면에 뜬 문구 그대로. "오류남" 말고 "500 Internal Server Error"

범위 — 전체가 안 되는지, 특정 화면·기능만인지

재현 방법 — 어떤 순서로 눌렀을 때 나는지

화면 캡처 — 주소창이 함께 보이게

있으면 좋은 것:

다른 기기·다른 네트워크에서도 같은지

직전에 무엇이 바뀌었는지 (배포, 데이터 대량 입력, 결제사 점검 등)

영향 규모 — 주문이 안 들어오는지, 조회만 안 되는지

보내는 방법: 전화로 알리더라도 같은 내용을 문자로 남기는 편이 낫습니다. 통화는 기록이 안 남아서 나중에 대응이 늦었는지 다툴 때 근거가 없습니다.

이 질문의 답은 계약서에 있습니다. 없으면 사실상 정해진 게 없습니다.

계약에 대응 시간이 적혀 있는 경우:

보통 이렇게 나뉩니다.

긴급(서비스 전체 중단) — 영업시간 내 2~4시간 안에 1차 회신

일반(일부 기능 오류) — 1~2 영업일

문의·개선 — 3~5 영업일

여기서 중요한 건 "회신"과 "복구"가 다르다는 점입니다. "4시간 내 대응"은 대개 연락을 준다는 뜻이지 4시간 안에 고친다는 뜻이 아닙니다. 계약할 때 이 둘을 나눠 적어야 합니다.

적혀 있지 않은 경우:

법으로 정해진 시간은 없습니다. 하자보수 기간 안이라면 고칠 의무는 있지만 언제까지인지는 다툼거리가 됩니다. 현실적으로는 관계와 호의에 기대게 됩니다.

그래서 계약 단계에서 정해둘 것:

긴급 장애의 기준 (무엇을 긴급으로 볼 것인가)

1차 회신 시간과 복구 목표 시간을 따로

영업시간 외·주말 대응 여부와 추가 비용

연락 창구 (담당자 1명 + 예비 연락처)

연락 창구를 한 사람으로만 두면 그 사람이 휴가일 때 멈춥니다. 예비 연락처를 계약서에 적어두십시오.

"고쳤습니다" 로 끝내면 같은 장애가 반복됩니다. 세 가지를 요청합니다.

1. 원인과 조치 내용

길 필요 없습니다. 무엇이 원인이었고 무엇을 바꿨는지 몇 줄이면 됩니다. 이걸 남겨두면 다음에 비슷한 증상이 났을 때 훨씬 빨리 잡힙니다.

2. 재발 방지책

같은 원인이 또 생기면 어떻게 되는지 묻습니다. "다시 손보면 됩니다" 와 "감지되면 알림이 갑니다" 는 다릅니다.

3. 감지 체계

가장 중요합니다. 이번에 장애를 누가 먼저 알았습니까?

고객이 전화해서 알았다면 감지 체계가 없는 것입니다. 서비스가 멈춘 걸 사장이 마지막에 아는 구조입니다. 서버 상태를 주기적으로 확인해 이상이 있으면 알림을 보내는 장치는 규모가 작아도 붙일 수 있고, 비용도 크지 않습니다.

계약이 끝난 뒤라면 유지보수 범위에 이 항목이 들어 있는지 확인하십시오. 없다면 추가하는 편이 낫습니다 — 장애 시간이 곧 매출입니다.