가동 시간과 상태 페이지와 사용자 오류를 따로 보는 법

서비스 화면이 열리기만 하면 모든 기능이 정상이라고 생각하기 쉽습니다. 하지만 첫 화면은 잘 보여도 로그인이나 저장이 실패할 수 있고, 특정 지역이나 일부 사용자만 느려질 수도 있습니다. 반대로 잠깐의 자동 확인 실패가 모든 사용자에게 같은 장애를 뜻하는 것도 아닙니다.

가게 문에 불이 켜져 있다고 떠올려 보세요. 문이 열렸다는 사실은 알 수 있지만 계산대가 작동하는지, 주문한 물건을 받을 수 있는지까지는 알 수 없습니다. 가동 확인은 문을 보는 일이고, 사용자 흐름 확인은 실제로 주문을 끝내 보는 일이며, 상태 페이지는 문제가 생겼을 때 손님에게 현재 상황을 알리는 안내판입니다.

가동 시간은 정한 확인 조건이 성공한 비율이다

가동 시간은 흔히 일정 기간 동안 자동 확인이 성공한 비율을 뜻합니다. 확인 도구가 주소에 요청을 보내고 기대한 상태 코드나 본문 일부를 받으면 성공으로 기록할 수 있습니다. 예를 들어 여섯 번 확인해 다섯 번 기대한 응답을 받았다면, 그 기록은 다섯 번의 확인이 조건을 통과했다는 뜻입니다.

여기서 중요한 말은 “정한 조건”입니다. Google Cloud의 공개 가동 확인 문서는 HTTP 상태와 필요한 본문이 조건에 맞는지 검사할 수 있지만, 페이지 자산을 불러오거나 JavaScript를 실행하지 않는다고 설명합니다. 따라서 첫 HTML 응답이 성공해도 버튼 동작, 브라우저 렌더링, 로그인 뒤 화면까지 확인된 것은 아닙니다.

한 주소의 성공이 서비스 전체의 성공은 아니다

홈 주소 하나가 빠르게 열려도 사용자가 필요한 결과를 얻지 못할 수 있습니다. 홈은 정적 파일로 정상 제공되지만 로그인 API가 실패하거나, 검색 결과는 보이지만 저장 요청이 막히거나, 주문은 접수됐는데 결제 결과를 읽지 못할 수 있습니다. 가동 확인 대상을 서비스 전체와 같은 말로 쓰면 이런 부분 장애가 숨습니다.

작은 서비스라면 먼저 사용자가 반드시 거치는 흐름을 서너 단계로 적어 봅니다.

첫 화면 열기 → 로그인 → 자료 저장 → 저장 결과 다시 열기

각 단계는 서로 다른 실패 조건을 가집니다. 첫 화면 확인은 공개 주소만으로 가능하지만 로그인과 저장은 시험 계정, 인증, 데이터 처리까지 필요합니다. 한 번의 단순 요청으로 모든 단계를 대신하지 말고 공개 가동 확인과 별도 시험 흐름을 구분합니다.

외부 확인은 사용자 증상을 보고 내부 기록은 원인을 찾는다

외부 확인은 서비스 밖에서 사용자가 보는 방식과 비슷하게 주소나 기능을 점검합니다. Google SRE 문서는 이를 블랙박스 모니터링, 즉 내부 구조를 몰라도 외부에 드러난 동작을 시험하는 방식으로 설명합니다. 사용자가 지금 실패하는지를 발견하는 데 도움이 됩니다.

내부 기록은 서버 오류, 데이터베이스 연결, 작업 대기열, 응답 시간처럼 안쪽 상태를 보여 줍니다. 외부에서는 저장이 느리다는 증상이 보이고 내부에서는 데이터베이스 연결 대기가 원인 후보로 보일 수 있습니다. 외부 성공과 내부 정상 중 하나만 믿지 말고 “사용자에게 무엇이 실패했는가”와 “안에서 왜 실패했는가”를 따로 기록한 뒤 같은 시간대에서 맞춰 봅니다.

상태 페이지는 감시 장비가 아니라 소통 창구다

상태 페이지는 서비스의 현재 상태, 영향받는 기능, 조사 진행 상황과 복구 여부를 사용자에게 알리는 별도 페이지입니다. Atlassian은 Statuspage를 장애와 예정된 유지보수를 알리는 소통 도구로 설명하며, 이 제품 자체가 웹사이트나 서버를 직접 감시하는 것은 아니라고 밝힙니다. 모니터링 결과와 운영자의 확인을 상태 안내로 옮기는 단계가 따로 필요합니다.

상태 페이지의 초록 표시도 영원한 보증이 아닙니다. 마지막 갱신이 늦었거나, 홈과 API를 하나의 큰 구성 요소로 묶었거나, 일부 지역 문제를 아직 확인하지 못했을 수 있습니다. 사용자가 오류를 제보하면 “상태 페이지가 정상”이라는 이유로 끝내지 말고 시간, 기능, 지역, 기기처럼 재현에 필요한 범위를 확인합니다.

장애 안내에는 원인 추측보다 확인된 영향을 먼저 쓴다

장애를 처음 발견했을 때는 정확한 원인을 모를 수 있습니다. 이때 “데이터베이스가 고장 났다”처럼 추측을 확정해서 쓰기보다 “일부 사용자의 로그인 요청이 실패하고 있으며 조사 중”처럼 확인된 사용자 영향을 적습니다. 원인이 바뀌어도 영향 설명은 사용자에게 계속 도움이 됩니다.

작은 상태 안내에는 다음 내용을 담을 수 있습니다.

• 언제부터 어떤 기능에서 문제가 확인됐는지 적습니다.
• 전체인지 일부인지 확인된 영향 범위를 구분합니다.
• 데이터 손실이나 보안 영향은 확인된 사실만 씁니다.
• 현재 단계가 조사 중인지, 원인 확인인지, 복구 관찰인지 표시합니다.
• 다음 안내 예정 시각이나 갱신 조건을 적습니다.
• 정상으로 돌린 뒤 실제 사용자 흐름을 다시 확인합니다.

내부 로그 원문, 서버 주소, 토큰, 고객 이메일은 상태 페이지에 붙이지 않습니다. 공개 안내는 사용자가 자신의 작업을 판단할 만큼 구체적이어야 하지만 공격이나 개인정보 노출에 도움이 되는 내부 정보까지 보여 줄 필요는 없습니다.

수치는 분모와 기간과 성공 조건을 함께 적는다

“가동 시간 99퍼센트” 같은 숫자만 보면 좋아 보이지만 무엇을 몇 번 확인했는지 모르면 비교하기 어렵습니다. 홈 주소만 검사했는지, 로그인과 저장도 포함했는지, 어느 지역에서 얼마나 자주 확인했는지, 예정된 점검 시간을 어떻게 처리했는지에 따라 같은 숫자의 의미가 달라집니다.

기록에는 최소한 대상 주소나 기능, 확인 위치, 간격, 성공 조건, 계산 기간을 함께 둡니다. 오류율도 전체 요청을 분모로 한 값인지 특정 기능 요청만 본 값인지 적습니다. 숫자를 높이기 위해 실패 요청을 빼거나 확인 대상을 쉬운 홈 주소로 바꾸지 않습니다. 지표 정의가 바뀌면 이전 기간과 바로 이어 붙이지 말고 변경 시점을 표시합니다.

사용자 제보와 자동 확인을 한 시간선에 놓는다

자동 확인은 반복적이고 빠르지만 모든 기기와 계정 상태를 대신하지 못합니다. 사용자 제보는 실제 불편을 보여 주지만 한 건만으로 전체 범위를 단정하기 어렵습니다. 둘을 경쟁시키지 말고 배포 시각, 자동 확인 실패, 오류 로그 증가, 첫 제보, 상태 안내, 복구 확인을 한 시간선에 놓습니다.

이 시간선이 있으면 자동 확인보다 제보가 먼저였는지, 상태 안내가 실제 복구보다 일찍 종료됐는지 볼 수 있습니다. 복구 버튼을 눌렀다는 기록이나 서버가 다시 응답했다는 사실만으로 해결을 선언하지 않고, 처음 실패한 사용자 흐름이 다시 끝까지 완료되는지 확인합니다.

안전 경계는 읽기 전용 점검에서 시작한다

처음부터 운영 계정으로 로그인·결제·삭제를 반복하는 합성 시험을 만들지 않습니다. 합성 시험은 자동 프로그램이 사용자의 행동을 흉내 내는 점검이지만, 실제 주문이나 메일 발송 같은 부작용을 만들 수 있습니다. 별도 시험 계정과 시험 데이터, 결제 제공사의 테스트 모드를 사용하고 생성된 자료를 안전하게 정리할 방법을 먼저 정합니다.

모르는 모니터링 설치 명령이나 에이전트를 운영 서버에서 실행하지 않습니다. API 키와 상태 페이지 관리 토큰은 브라우저 코드, 공개 저장소, 알림 본문에 넣지 않습니다. 자동 복구 명령, 프로세스 종료, 데이터 삭제는 확인 한 번의 실패에 바로 연결하지 말고 재확인과 사람 승인, 복구 절차를 둡니다.

오늘 바로 해볼 작은 실습

설정이나 운영 데이터를 바꾸지 않고 10분 동안 서비스 상태 확인표를 만듭니다.

1. 로그인이나 결제가 필요 없는 공개 주소 하나를 고릅니다.
2. 그 주소에서 기대하는 상태 코드와 눈으로 확인할 문구를 적습니다.
3. 자동 확인이 JavaScript와 버튼 동작까지 보는지 모른다고 표시합니다.
4. 사용자가 반드시 끝내야 하는 흐름을 세 단계 이상 적습니다.
5. 각 단계에서 보일 수 있는 실패 증상을 한 개씩 적습니다.
6. 외부 확인 결과와 내부 로그를 서로 다른 칸에 둡니다.
7. 상태 페이지에 알릴 구성 요소와 사용자 영향을 한 문장으로 적습니다.
8. 다음 갱신 시각과 복구 뒤 다시 시험할 흐름을 적습니다.
9. 비밀키, 실제 고객 정보, 내부 서버 주소를 기록하지 않았는지 확인합니다.
10. 실결제, 메일 발송, 삭제, 프로세스 종료는 실행하지 않습니다.

마지막으로 “무엇이 응답했고, 사용자는 무엇을 끝냈으며, 현재 무엇을 알렸는가”를 세 문장으로 나눠 보세요. 세 답이 같지 않을 수 있다는 점을 이해하면 초록 표시 하나에 기대지 않고 실제 사용자 경험과 장애 소통을 함께 운영할 수 있습니다.