푸시 알림 배포 후 실패하는 이유를 찾는 방법

로컬에서 테스트할 때는 잘 동작하던 푸시 알림이 운영 환경에 올리면 갑자기 실패한다. 이런 경험은 거의 모든 개발자가 겪는다.

처음엔 그냥 코드를 다시 봤는데, 결국 발견하는 건 환경 변수 미설정이나 CORS 정책, 혹은 빌드 최적화 때문에 번들된 스크립트가 다르거나 하는 것들이었다. 그래서 이제는 순서대로 확인한다.

먼저 확인할 신호들

실제로 무엇이 문제인지 알기 전에, 어디서 실패하는지를 파악하는 게 먼저다. 사용자가 받는 화면, 브라우저 콘솔 에러, 그리고 서버 로그를 동시에 본다.

• 사용자가 보는 증상: 알림이 안 오는 건지, 오긴 하는데 클릭이 안 되는 건지, 아니면 아예 요청이 안 가는 건지
• 브라우저 개발자 도구: 네트워크 탭에서 API 요청이 들어갔는지, 응답 상태는 뭔지
• 서버 로그: 요청이 도착했는지, 어디서 에러가 났는지

빌드 후 실제 코드 확인

배포 전에 반드시 한 번 빌드해서 실제 번들을 본다.

npm run build
# 또는
nyarn build

빌드 후 생성된 js 파일에서 푸시 알림 관련 코드가 제대로 포함됐는지 확인한다. Tree-shaking 때문에 코드가 제거되거나, 환경 변수 치환이 제대로 안 된 경우가 종종 있다.

환경 변수와 설정 비교

로컬 .env 파일과 배포 환경 변수를 나열해본다. 특히:

• API 엔드포인트 URL (http vs https)
• 서비스 워커 스크립트 경로
• Firebase 또는 푸시 서비스 키
• CORS 설정

이 중 하나라도 다르면 요청이 실패한다. 특히 도메인이 다르면 CORS 에러가 먼저 터진다.

정상 상태와 비교하기

문제를 확인할 때는 항상 "정상일 때의 상태"를 먼저 기록해둔다. 그래야 나중에 "뭐가 달라졌다"고 빠르게 판단할 수 있다.

1. 배포 전 로컬에서 알림 요청 후 서버 로그 캡처
2. 배포 후 같은 요청 다시 시도 후 로그 비교
3. 응답 코드, 타이밍, 에러 메시지 중 하나라도 다르면 기록

실제 확인 순서

처음엔 작은 부분부터 시작한다. 한 번에 모든 설정을 바꾸면 원인을 모르겠다.

1. 브라우저 개발자 도구에서 API 요청이 나가는지 확인
2. 요청이 나간다면 응답 상태와 본문 확인
3. 요청이 안 나간다면 js 콘솔 에러 확인, 서비스 워커 등록 상태 확인

마지막엔 실제 배포된 환경에서 직접 테스트한다. 아무리 설정이 맞는 것 같아도, 공개 URL을 브라우저에 열어서 직접 해봐야 확신할 수 있다.