상태 페이지 만드는 방법: 구성 요소, 장애 공지와 가동 시간 확인

상태 페이지는 사용자에게 서비스가 정상인지 한곳에서 알려 줍니다. 만들려면 구성 요소 목록(웹사이트, API, 결제, 이메일 발송 등), 각 구성 요소의 현재 상태, 시간이 기록된 장애와 업데이트, 과거 장애 기록, 그리고 필요하다면 사용자가 알림을 구독하는 기능이 필요합니다. 페이지 자체는 단순합니다. 중요한 결정은 어디에서 실행하느냐입니다. 상태 페이지는 앱이 다운되어도 살아 있어야 하므로, 보고 대상인 서비스와 호스팅, 데이터베이스, 배포 파이프라인을 공유하면 안 됩니다.

상태 페이지의 목적

무언가 고장 나면 사용자는 세 가지를 알고 싶어 합니다. 나만 겪는 문제인지, 서비스 측이 알고 있는지, 언제 고쳐지는지입니다. 상태 페이지는 문의가 쏟아지지 않아도 이 세 가지에 답합니다. 또한 솔직한 장애 기록을 꾸준히 보여 주면 문제를 어떻게 다루는지가 드러나 신뢰가 쌓입니다.

상태 페이지는 변경 이력이 아닙니다. 새 기능은 변경 기록 페이지에 올리고, 장애와 점검은 여기에 올리세요.

페이지에 필요한 것

데이터

구성 요소 상태는 보통 정해진 짧은 목록을 씁니다. 정상, 성능 저하, 부분 장애, 전체 장애, 점검 중입니다.

페이지

• 공개 상태 페이지: 전체 상태 배너(“모든 시스템 정상” 또는 현재 가장 나쁜 상태), 구성 요소별 상태, 진행 중인 장애와 업데이트, 예정된 점검, 점검 데이터가 있다면 최근 90일 기록 막대.
• 장애 페이지: 장애 하나의 전체 업데이트 타임라인. 고객 지원이 링크로 공유할 수 있도록 고유 URL을 가집니다.
• 기록: 월별 과거 장애 목록.
• 구독: 확인 절차가 있는 이메일 구독과 구성 요소별 설정.
• 관리자: 장애 생성, 업데이트 게시, 구성 요소 상태 변경, 점검 예약.

권한

공개 페이지에는 게시된 내용만 보입니다. 게시는 팀만 할 수 있습니다. 가능하다면 관리자 로그인을 메인 앱의 로그인 시스템과 분리하세요. 인증 제공자에 장애가 나도 상태 페이지 관리를 할 수 있어야 합니다.

핵심 결정: 독립적으로 운영하기

직접 만든 상태 페이지가 실패하는 대표적인 이유가 여기에 있습니다. 상태 페이지가 다음과 같다면:

• 앱과 같은 서버나 호스팅 계정에서 돌아가거나,
• 앱과 같은 데이터베이스를 읽거나,
• 같은 도메인 설정이나 CDN 구성 뒤에 있거나,
• 같은 파이프라인으로 배포된다면,

많은 장애가 상태 페이지도 함께 쓰러뜨립니다. 사람들이 가장 필요로 할 때 말이죠. 실천 방법은 다음과 같습니다.

• 호스팅 분리. 메인 앱과 다른 프로젝트나 제공자를 씁니다.
• 전용 서브도메인, 예를 들어 status.example.com을 쓰고 DNS를 따로 설정합니다. 도메인과 DNS 작동 방식을 참고하세요.
• 독립된 데이터. 장애 정보는 앱 데이터베이스가 아니라 상태 페이지 자체 저장소에 둡니다.
• 정적 대체 페이지. 공개 페이지를 정적으로 만들고 업데이트할 때마다 다시 빌드하는 팀도 있습니다. 그러면 깨질 것이 거의 없습니다.

수동 업데이트 또는 자동 점검

수동 (여기서 시작하세요)

팀이 관리자 페이지에서 장애를 등록하고 구성 요소 상태를 직접 바꿉니다. 실제로 많은 상태 페이지가 이렇게 운영됩니다. “일부 카드 유형에서 결제가 느립니다” 같은 사람의 판단이 자동으로 뜨는 빨간 점보다 더 유용하기 때문입니다.

문제를 빨리 알려면 앱을 1분 정도 간격으로 확인하고 이메일, 문자, 채팅으로 알려 주는 외부 업타임 모니터를 쓰세요. 많은 모니터링 서비스에 무료 요금제가 있습니다.

자동

자동화는 각 구성 요소를 정기적으로 점검해 상태를 갱신하는 것을 말합니다. 이를 위해서는 메인 앱 인프라 바깥에서 일정에 따라 실행되는 코드가 필요합니다. 흔한 패턴은 두 가지입니다.

• 외부 모니터가 점검 실패나 복구 시 웹훅으로 상태 페이지를 호출하고, 상태 페이지가 구성 요소를 갱신합니다.
• 상태 페이지 호스팅 안의 예약 작업이 각 구성 요소를 확인하고 결과를 기록합니다. 의존하기 전에 호스팅이 예약 작업을 어떻게 지원하는지 확인하세요. 백그라운드 작업 실행 방법에서 옵션을 설명합니다.

자동 변경은 느린 네트워크에서 상태가 오락가락(정상, 다운, 정상)할 수 있습니다. 상태를 바꾸기 전에 두세 번 연속 실패를 요구하고, 주요 장애를 공지하기 전에는 사람이 확인하도록 하세요.

장애 업데이트 쓰는 법

• 빨리 게시하세요. 완벽한 메시지를 한 시간 뒤에 내는 것보다 몇 분 안에 “로그인 실패를 조사하고 있습니다”라고 알리는 편이 낫습니다.
• 내부 원인이 아니라 사용자가 겪는 일을 말하세요.
• 다음 업데이트 시각을 약속하고, 지키세요.
• 해결되면 짧은 요약으로 마무리하세요. 무엇이 일어났고, 얼마나 걸렸고, 무엇을 바꿀지 적습니다.

잘 작동하는 첫 프롬프트

우리 앱 Parcelio용 독립형 상태 페이지를 만들어 줘. 별도 호스팅으로 status.parcelio.com에 올릴 거야. 구성 요소는 웹사이트, 추적 API, 알림, 결제이고, 각각 정상, 성능 저하, 부분 장애, 전체 장애, 점검 중 중 하나의 상태를 가져야 해. 공개 페이지에는 가장 나쁜 현재 상태를 쓴 전체 배너, 구성 요소별 상태, 진행 중인 장애와 시간이 기록된 업데이트(최신순), 예정된 점검, 월별 과거 장애 목록을 보여 줘. 장애마다 자체 페이지가 있어야 해. 비밀번호로 보호되는 관리자 페이지에서 장애를 만들고(제목, 영향도, 영향받는 구성 요소), 업데이트를 게시하고(메시지와 상태: 조사 중, 원인 파악, 모니터링, 해결됨), 구성 요소 상태를 바꾸고, 점검을 예약할 수 있게 해 줘. 외부 모니터가 구성 요소 이름과 정상/실패 값을 보낼 수 있는 POST /api/check-result 엔드포인트도 추가해 줘. 비밀 토큰으로 보호하고, 연속 세 번 실패해야만 구성 요소를 성능 저하로 표시해 줘. 모든 데이터는 이 앱 자체 데이터베이스에 저장해 줘. 차분하고 단순한 디자인이고, 휴대폰에서 빨리 열려야 해.

빌드 단계

1. 공개 페이지와 수동 장애 관리용 관리자 페이지. 이것만으로도 작동하는 상태 페이지입니다.
2. 별도 호스팅을 하고 서브도메인을 연결합니다.
3. 장애 페이지와 기록.
4. 점검 기간.
5. 구독. 이중 확인(double opt-in) 이메일 구독과 새 장애 및 업데이트 알림입니다. 이메일에는 발송 제공자가 필요합니다. 앱에서 이메일 보내는 방법을 참고하세요.
6. 모니터 웹훅, 자동 상태 변경이 필요하다면 추가합니다.
7. 훈련 실행. 가짜 장애를 만들고, 업데이트를 게시하고, 해결한 뒤 이메일을 확인하고, 그 장애를 삭제하세요.

흔한 실수

• 앱과 함께 호스팅하기. 가장 흔하고 가장 심각한 실수입니다.
• 항상 “모든 시스템 정상”이라고 표시하기. 문제를 한 번도 보여 주지 않으면 사용자가 신뢰하지 않게 됩니다.
• 시간과 시간대 없음. 시간은 항상 시간대와 함께 표시하세요.
• 관리자 페이지에 메인 앱 로그인을 그대로 사용하기.
• 업데이트 사이의 침묵. “변경 없음, 여전히 확인 중”도 유효한 업데이트입니다.
• 흔들리는 자동 상태. 변경 전에 반복된 실패를 요구하세요.

호스팅형 상태 페이지 서비스가 더 나은 경우

호스팅형 상태 페이지 서비스는 독립성 문제를 해결하도록 만들어졌습니다. 별도 인프라에서 돌아가고, 이메일과 문자 구독 알림을 처리하며, 종종 모니터링과 장애 도구 연동까지 제공합니다. 가동 시간이 고객이 돈을 내는 이유의 일부이거나 장애를 보고할 계약상 의무가 있다면, 전용 서비스를 쓰는 편이 대개 낫습니다. 소규모 팀을 위한 무료 또는 저렴한 요금제도 많으니, 직접 만들기 전에 확인해 보세요.

디자인과 문구를 완전히 통제하고 싶거나, 구성 요소가 몇 개뿐이고 수동 업데이트로 충분하거나, 다른 사람을 위해 만드는 제품의 일부라면 직접 만드는 것이 좋습니다.

Mythex로 만들기

Mythex에서는 상태 페이지를 메인 앱과 별도 프로젝트로 만들 수 있습니다. 그러면 호스팅과 데이터베이스가 따로 분리됩니다. 채팅으로 설명하고 라이브 미리보기에서 확인한 뒤 게시하고, status.yourdomain.com 같은 서브도메인을 연결하세요(커스텀 도메인은 Pro에서 사용할 수 있습니다). 참고로 게시된 Mythex 앱과 데이터베이스는 유휴 상태가 되면 잠들고, 다음 방문 때 깨어납니다. 그래서 한동안 방문이 없었다면 첫 로딩이 느릴 수 있습니다. 단순하고 가벼운 페이지가 도움이 됩니다.

Mythex는 예약 작업을 아직 문서화하지 않았습니다. 자동 점검에는 상태 페이지의 웹훅 엔드포인트를 호출하는 외부 업타임 모니터를 쓰세요(웹훅 레시피). 구독자에게 보내는 이메일 알림은 직접 고른 제공자를 쓰고, 키는 프로젝트 시크릿에 저장하세요(이메일 발송 레시피).

자주 묻는 질문