서비스가 안 열릴 때, 장애 현황과 내 환경을 나누어 확인하기

저장 버튼을 누른 뒤 오류가 났다면 다시 누르기 전에 실제 결과가 생겼는지부터 확인해야 한다. 화면 응답의 실패와 요청 처리의 실패가 같은 것은 아닐 수 있다. 발생 시각과 기능, 오류 문구를 남기고 공식 장애 현황과 자신의 환경을 나눠 본다.

오류가 언제 어디서 발생했는지 남긴다

발생 시각과 시간대, 앱·브라우저, 실패한 기능, 오류 문구를 적는다. 첫 화면이 안 열리는지, 로그인 뒤 특정 기능만 실패하는지 구분한다. 단순히 ‘사이트가 안 된다’보다 어떤 단계에서 막혔는지 기록하는 것이 도움이 된다.

스크린샷에는 이름이나 이메일, 문서 제목, 인증 코드가 들어갈 수 있으므로 공유할 부분을 검토한다. 비밀번호나 일회용 코드, 개인 문서의 내용을 장애 문의 증거로 보내지 않는다. 필요한 오류 문구와 발생 조건만 남길 수 있다.

자료는 관찰 결과로 기록한다. 한 기기에서 실패했다는 사실을 전체 서비스 장애로 확정하거나, 한 번 성공한 것을 문제 해결 완료로 표시하지 않는다.

공식 상태 페이지에서 같은 기능과 시간을 찾는다

서비스가 상태 페이지를 제공한다면 현재 공지와 장애 이력을 확인한다. 자신이 실패한 기능, 지역, 발생 시간이 공지와 맞는지 살핀다. 전체 상태가 정상으로 보이더라도 특정 기능이나 자신의 계정 문제는 남을 수 있다.

Google Cloud 서비스 상태 안내는 공통 상태 정보와 개인화된 상태 확인을 나누어 설명한다. 상태 페이지가 어떤 범위를 다루는지 읽어야 자신의 상황에 연결할 수 있다. Google Cloud 상태가 정상이라고 일반 Google 소비자 서비스나 다른 앱의 모든 기능이 정상이라고 판단할 수는 없다.

공식 공지에 문제가 기록돼 있다면 자신의 발생 조건과 함께 남긴다. 공지의 조사 중, 완화, 해결 상태를 구분하고 후속 안내가 있는지 확인한다. 해결 표시가 나온 뒤에는 실제 필요한 작업이 다시 되는지 점검한다.

저장 버튼을 누른 뒤 오류가 났다면 다시 누르기 전에 본다

서비스가 응답하지 않을 때 단순한 페이지 조회와 제출 작업을 구분해야 한다. 페이지를 다시 여는 일과 같은 주문·문서·메일을 다시 제출하는 일은 영향이 다르다. 오류가 표시됐어도 앞선 요청이 일부 처리됐을 수 있으므로 결과 목록과 확인 기록을 먼저 확인한다.

가상의 문서 업로드에서 진행 화면이 멈췄다고 하자. 파일 목록을 새로 열어 항목이 생겼는지, 같은 이름의 파일이 여러 개 있는지 확인할 수 있다. 성공 여부를 알 수 없는데 계속 업로드하면 중복 사본이 생길 수 있다. 결제처럼 영향이 큰 작업에서는 재시도 전에 서비스가 제공하는 거래 상태와 확인 경로를 이용해야 한다.

관찰 기록은 ‘서비스가 망가짐’보다 ‘오후 2시 10분, 웹 앱의 업로드에서 완료 알림이 나오지 않음, 파일 목록에는 항목 한 개 표시’처럼 구체적으로 적는다. 이런 기록이면 화면 응답 문제와 실제 처리 결과를 나눠 볼 수 있다. 원인에 대한 추측은 관찰 뒤에 별도로 둔다.

공식 장애 현황과 자신의 오류가 맞는지 연결한다

상태 페이지에서 로그인 기능에 장애가 표시됐는데 자신은 이미 로그인한 상태에서 다운로드만 실패한다면 같은 문제인지 아직 알 수 없다. 기능 이름과 발생 시간, 영향받는 지역이나 제품이 맞는지 확인한다. 반대로 상태가 정상이라고 모든 계정의 모든 요청이 정상이라고 판단하지 않는다.

오류 코드는 정확하게 남긴다. HTTP 401, 403, 429, 500 계열은 서로 다른 상태를 설명하지만 코드 하나만으로 계정 설정이나 서버의 최종 원인을 확정할 수는 없다. 문서가 제시하는 뜻과 실제 발생한 화면, 요청 종류를 함께 보아야 한다. 비밀 토큰이나 인증 정보가 포함된 요청 주소는 공개 기록에서 제외한다.

허용된 환경에서 원인을 좁힐 때는 조건을 하나씩 바꾼다. 다른 네트워크와 브라우저를 동시에 바꾸면 어느 차이가 영향을 주었는지 알기 어렵다. 회사의 접근 정책을 우회하거나 보안 설정을 무작정 해제하는 방식으로 시험하지 않는다. 작업 환경에서 허용된 확인 방법을 이용한다.

문의에는 발생 시각과 시간대, 기능, 오류 문구, 이미 확인한 결과, 재시도 여부를 남긴다. 재현 자료를 보낼 때는 개인 자료 대신 문제를 보여주는 최소한의 시험 파일을 쓸 수 있는지 검토한다. 정확한 관찰이 있어야 지원 쪽에서도 단순한 접속 실패와 처리 결과가 불확실한 작업을 구분할 수 있다.

오류 코드는 원인을 좁히는 단서다

MDN의 HTTP 상태 코드 설명은 요청 처리 결과를 분류한다. 웹사이트가 코드를 보여주는 경우 그 의미는 단서가 될 수 있지만, 코드 하나로 최종 원인을 모두 알 수는 없다.

예를 들어 401은 인증을 요구하는 응답이고 403은 요청을 허용하지 않는 상황과 관련된다. 404는 요청한 자원을 찾지 못한 응답이며, 5xx 계열은 서버 쪽 처리 문제의 범주다. 같은 숫자가 여러 조건에서 나타날 수 있으므로 시각과 기능, 계정 상태를 함께 기록한다.

앱이 보여주는 자체 오류 번호는 HTTP 코드와 다를 수 있다. 이름이 비슷하다고 다른 서비스의 해결 방법을 그대로 적용하지 않는다. 해당 서비스의 공식 문서에서 실제 오류 문구를 확인한다.

허용된 환경에서 조건 하나씩 대조한다

업무 환경의 보안 정책을 유지한 상태에서 앱과 브라우저의 차이, 같은 기기의 다른 허용된 연결 등을 확인할 수 있다. 여러 조건을 한꺼번에 바꾸면 어떤 변경이 결과에 영향을 줬는지 알기 어렵다. 확인한 조합과 결과를 기록한다.

확장을 끄거나 캐시를 지우는 등의 조작도 현재 작업과 로그인에 영향을 줄 수 있으므로, 먼저 저장하지 않은 자료가 있는지 확인한다. 인증서 경고나 조직의 접근 제한을 우회해 시험하는 방식은 적절하지 않다. 문제를 좁히는 목적과 보안 설정을 바꾸는 일은 구분한다.

다른 사람도 같은 상황인지 확인할 때는 개인정보나 문서를 전달하지 않고 기능과 시간만 대조할 수 있다. 여러 계정에서 비슷하게 실패한다는 관찰은 공통 문제의 단서지만 공식 원인 확정과 같지는 않다.

재시도하기 전에 중복 실행 가능성을 본다

파일 업로드나 신청, 결제처럼 결과가 서버에 남는 작업은 오류 화면이 떠도 일부 처리가 끝났을 수 있다. 단순히 버튼을 반복해서 누르기 전에 작업 목록과 완료 상태를 확인한다. 응답을 못 받았다는 사실과 서버가 아무 작업도 하지 않았다는 사실은 다르다.

작성한 내용을 로컬 사본이나 서비스의 임시 저장 기능으로 보존할 수 있다면 먼저 확보한다. 실패한 작업의 이름과 시각을 기록하면 지원 담당자가 실제 처리 상태를 찾기 쉽다. 계정 비밀이나 결제 정보 전체를 문의에 넣을 필요는 없다.

문의에는 관찰과 추정을 나누어 적는다

발생 시간, 사용 환경, 실패한 기능, 오류 문구, 확인한 공식 공지와 점검 결과를 정리한다. ‘서버 문제 같다’는 추정과 ‘두 기기의 업로드가 같은 시간에 실패했다’는 관찰을 분리한다. 이렇게 적으면 후속 질문의 범위를 좁힐 수 있다.

자료 손실이 의심되면 계속 덮어쓰기보다 현재 상태를 보존하고 공식 복구 안내를 확인한다. 파일 버전 복구는 삭제와 덮어쓰기를 구분하는 방법을 설명한다. 문제 해결 완료는 공지의 상태뿐 아니라 필요한 실제 작업이 기대한 결과로 끝난 것을 확인한 뒤 기록한다.