🔔
PayStream 알림 연동 우선순위 재정리
2026.04.23
PayStream 알림 기능을 설계하면서, 처음엔 앱 푸시를 1순위로 두고 진행하려 했다. 그런데 프론트가 네이티브 앱이 아니라 웹뷰·PWA 조합이라는 점이 드러나면서 우선순위를 다시 정리해야 했다. 이번 글은 그 과정에서 확정한 알림 연동 로드맵을 정리한 기록이다.
처음 생각했던 우선순위
- 앱 푸시 알림 — 특가 알림 등 실시간성이 중요한 알림
- 이메일 알림 — 공지, 서비스 안내 등 빈도·중요도가 상대적으로 낮은 알림
- 웹 푸시 알림 — 선택 사항
우선순위를 바꾼 이유
PayStream-web은 네이티브 앱이 아니라 웹뷰 + PWA 구조다. 이 조합에서는 앱 푸시에 필요한 토큰·인증 방식을 바로 적용하기 어렵다. FCM을 쓰려면 네이티브 껍데기까지 고려해야 하고, Web Push를 쓰려면 PWA와 Service Worker 준비가 선행되어야 한다.
결론적으로, 채널 구현보다 먼저 API 연동과 인증 흐름을 검증하는 편이 맞다고 판단했다.
재정리한 연동 순서
1. API 연동 (가장 먼저)
| 할 일 | 이유 |
|---|---|
게이트웨이 베이스 URL 확정 (NEXT_PUBLIC_…) |
브라우저에서 호출할 단일 진입점 필요 |
| 로그인 JWT로 알림 API 호출 검증 | 게이트웨이 · notification-service 라우트 · CORS 확인 |
| 프론트에 알림 클라이언트 1개 구성 (생성·목록 등 실제 사용 엔드포인트만) | 이후 채널만 추가하면 되도록 기반 마련 |
1차 목표는 브라우저에서 인증된 상태로 알림 API가 정상 호출되는 것이다.
2. 이메일 플로우 정리
| 할 일 | 이유 |
|---|---|
| 알림 생성 주체 정의 (주문/결제 서비스 vs 관리자 화면 테스트) | 프론트 화면 범위 결정 |
| 필요 시 목록·상세 UI만 우선 구현 | 생성은 백엔드 이벤트만으로도 가능 |
| 실패 시 이메일 폴백 규칙은 이후 단계로 미룸 | 이메일 발송은 서버에 이미 존재, 우선은 API + 화면 |
3. PWA 준비 (Web Push 이전)
| 할 일 | 이유 |
|---|---|
manifest · Service Worker 스캐폴딩 (next-pwa 또는 직접 SW) |
Web Push는 SW가 필수 |
| HTTPS · (추후) 홈 화면 추가 유도 | iOS PWA / Web Push 조건 |
4. Web Push + VAPID (1순위 채널)
| 할 일 | 이유 |
|---|---|
| 서버에 VAPID 키 생성·보관 | 표준 Web Push 스펙 |
구독 등록/해지 API (userId + PushSubscription JSON 저장) |
발송 대상 관리 |
| 알림 서비스에 PUSH 발송 분기 추가 | 현재는 EMAIL 위주일 가능성 |
| 프론트: 권한 요청 → 구독 → 등록 API 호출 | 사용자 단위까지 한 줄로 연결 |
5. FCM (3순위)
WebView 환경에서 Web Push가 막히는 케이스가 실제로 확인된 뒤, 네이티브 껍데기와 FCM 도입 여부를 결정한다. 초기 단계부터 FCM을 끼워 넣을 필요는 없다.
마무리
정리하면 연동 순서는 아래와 같다.
게이트웨이 + JWT로 알림 API 연결 → 이메일 화면·역할 정리 → PWA / SW 준비 → Web Push · VAPID · 구독 API · 발송
다음 글에서는 실제로 게이트웨이 경유 알림 ping 연동을 진행하면서 겪은 시행착오를 정리할 예정이다.
👇 도움이 되셨다면 👇