푸시(Push) 메시지는 발송 요청 이후 여러 시스템을 거쳐 최종 사용자 단말까지 전달됩니다.
각 구간마다 실패 원인이 다르며, 실패 발생 위치에 따라 즉시 대체 발송(알림톡, SMS, LMS 등)이 가능한 경우와 불가능한 경우가 존재합니다.
따라서 안정적인 메시지 전달을 위해서는 실패 구간을 명확히 구분하여 관리하는 것이 중요합니다.
발송기
│
▼
UMS
│
▼
Provider
(푸시 발송 프로토콜 서버)
│
▼
APNS / FCM
│
▼
사용자 단말
| 구간 | 설명 |
|---|---|
| ① | 발송기 → UMS |
| ② | UMS 내부 처리 |
| ③ | UMS → Provider |
| ④ | Provider → APNS / FCM |
| ⑤ | APNS / FCM → 사용자 단말 |
푸시 발송 과정에서 발생 가능한 실패는 다음과 같습니다.
| 구분 | 실패 원인 | 대체 발송 가능 여부 |
|---|---|---|
| ① | 사용자 Push 서비스 미가입 | 가능 |
| ② | UMS Validation 실패 | 가능 |
| ③ | 서버 장애 / 네트워크 장애 | 가능 |
| ④ | APNS / FCM Validation 실패 | 가능 |
| ⑤ | 사용자 단말 응답 대기 실패 | 정책에 따라 가능 |
사용자가 Push 서비스를 이용하지 않거나 Push 수신 동의를 하지 않은 경우 발생합니다.
대표 사례
UMS에서 발송 전 데이터 검증 중 실패하는 경우입니다.
대표 사례
UMS 또는 Provider 서버의 장애로 인해 요청이 전달되지 못하는 경우입니다.
대표 사례
UMS와 Provider 사이의 통신 장애입니다.
대표 사례
이 구간은 Provider가 Apple(APNS) 또는 Google(FCM)에 Push를 요청하는 단계입니다.
퍼블릭 Push 서버에서 요청을 거부하는 경우입니다.
대표 사례
이 구간은 Public Push 서버가 실제 사용자 단말에 Push를 전달하는 단계입니다.
사용자 단말의 상태로 인해 즉시 전달되지 않는 경우입니다.
대표 사례
정책에 따라
| 실패 구간 | 실패 원인 | 대체 발송 권장 |
|---|---|---|
| 발송기 → UMS | Push 미가입 | 즉시 대체 발송 |
| 발송기 → UMS | Validation 실패 | 즉시 대체 발송 |
| UMS → Provider | 서버 장애 | Retry 후 대체 발송 |
| UMS → Provider | 네트워크 장애 | Retry 후 대체 발송 |
| Provider → APNS/FCM | Token Invalid, Token Expired | 즉시 대체 발송 |
| APNS/FCM → 사용자 단말 | 단말 Offline | Timeout 후 대체 발송(정책 적용) |
Push 발송
│
▼
Push 실패 여부 확인
│
┌───────────┴────────────┐
│ │
즉시 실패 응답 대기
│ │
▼ ▼
알림톡 대체 발송 일정 시간 대기
│
▼
Timeout 발생
│
▼
알림톡/SMS 대체 발송