보낼지 판단은 Supabase,
배송은 Firebase

모바일 앱에서 푸시 알림을 구현할 때 가장 처음 맞닥뜨리는 혼란은 설정 파일과 서비스가 여러 곳에 파편화되어 있다는 점입니다. 앱 코드(Android), 데이터베이스(Supabase DB), 예약 실행 스케줄러(pg_cron), 서버리스 함수(Edge Function), 비밀값 저장소(Vault), 그리고 Firebase(FCM)까지 각각 무엇을 맡고 있는지 연결 고리를 이해하지 못하면 작은 설정 오류에도 길을 잃기 쉽습니다.

이 시스템은 실생활의 업무 처리 과정에 빗대어 보면 아주 자연스럽습니다. 업무 장부에 기록이 쌓이고, 매분 울리는 알람 시계가 직원을 깨우며, 직원은 지금 당장 알림을 보내도 되는지 4가지 조건을 꼼꼼히 따진 뒤, 최종 승인된 건만 전문 배송 기사에게 건네어 스마트폰으로 배달하는 흐름입니다.

예를 들어 상대방 가족 구성원이 WeRoutine 앱에서 나에게 '설거지'할 일을 배정했다고 해보겠습니다.

1. 장부 적재: 상대방이 작업을 추가하면 Supabase DB에 작업 레코드와 알림 후보가 저장됩니다.
2. 알람 시계 발동: pg_cron 자동 실행이 매분 알림 담당 직원(Edge Function)을 깨웁니다.
3. 직원의 조건 검증: 알림을 켜둔 사용자인가? 지금 방해금지(수면) 시간은 아닌가? 이미 완료한 작업은 아닌가? 최근에 너무 자주 알렸거나 하루 한도를 넘지는 않았나?
4. 배송 요청: 보낼 때가 되었다면 여러 작업을 묶어 Firebase FCM에 발송을 요청합니다.
5. 스마트폰 도착: FCM이 등록된 휴대폰으로 신호를 전달하고 화면에 알림이 표시됩니다.

배포 과정에서 실행했던 setup_household_notifications.sql은 데이터베이스에게 다음과 같은 정기 시간표를 등록한 것입니다.

여기서 pg_cron은 시간표를 지키는 스케줄러이고, pg_net은 Edge Function의 HTTP 인터넷 주소로 비동기 호출 요청을 쏘아주는 통신 도구입니다.

Supabase Edge Function은 인터넷에 공개된 URL 주소를 가지고 있습니다. 만약 아무런 방어벽이 없다면, 악의적인 사용자가 해당 주소를 무한정 새로고침하여 우리 서버의 실행 요금을 낭비시키거나 비정상적인 푸시를 유발할 수 있습니다.

따라서 서버끼리만 아는 '비밀 암호(출입증)'를 주고받아야 합니다. 이번에 Supabase Vault 금고에 보관한 값은 두 가지입니다.

자동 실행(Cron)은 DB 금고(Vault)에서 이 두 값을 안전하게 꺼내어 Edge Function을 호출하고, Edge Function은 들어온 요청 헤더의 비밀값이 맞는지 확인한 뒤에만 안심하고 조건 검사를 시작합니다.

개발을 진행하다 보면 google-services.json, FCM 기기 토큰, Firebase 서비스 계정 비밀키, NOTIFICATION_CRON_SECRET, Supabase 액세스 토큰까지 수많은 키가 등장합니다. 이것은 번거롭게 하려는 것이 아니라, 인증하는 구간과 책임이 서로 다르기 때문입니다.

현재 WeRoutine의 알림 파이프라인은 데이터베이스 구조 설계와 Edge Function 배포를 완료하고, 서버 테스트 31개를 무사히 통과한 탄탄한 상태입니다. 이제 실제 스마트폰에서 팝업이 뜨는 마지막 단계까지 연결을 검증할 차례입니다.

• 보낼지 판단하는 건 Supabase(장부 + 조건 검사 직원), 배달하는 건 Firebase(FCM 기사)다.
• 매분 실행(Cron)은 매분 알림을 보내는 것이 아니라 매분 조건을 검사할 뿐이다.
• Vault는 외부에 열린 함수 URL을 내부에서 안전하게 호출하기 위한 비밀값 금고다.
• 비밀키는 인증 구간마다 다르며, Firebase 서비스 계정 키는 절대 앱(APK)에 넣지 않는다.
• 설정은 최초 한 번이며, 이후에는 앱 알림 옵션과 일상 업무 등록만으로 매끄럽게 돌아간다.