Mobile

앱 알림 시스템 (웹 · Android · iOS)

완료

푸시를 붙인 게 아니라 인증·권한·딥링크·추적·오프라인 복구까지의 이벤트 시스템을 3플랫폼에 혼자 얹은 작업

기간: 2025.12 — 2026.04
인원: 1명 (웹·Android·iOS 단독)
역할: 설계·구현 단독 — 웹(Next.js) · Android(Kotlin) · iOS(Swift) 3플랫폼

기술 스택

FCM
Next.js
TypeScript
Kotlin
Swift
WebView Bridge
GA4

주요 업무

선행 조건 정리 — 동시 401에서 refresh가 중복 호출되는 상태로는 '알림이 안 갔는데 이유를 모르는' 구조가 되므로, 푸시보다 인증 레이어를 먼저 재설계 (single-flight + 요청 큐잉)
웹↔앱 공통 브릿지 — 플랫폼별로 따로 만들지 않고 인터페이스를 통일. OS 설정에서 권한을 바꿔도 웹이 모르는 문제를 권한 상태 전달 + 설정 진입 함수로 해결
오프라인 내성 — 푸시 클릭 로그를 로컬 큐에 적재하고 네트워크 복구·앱 재시작 시 flush해 유실 경로 차단
cold start 딥링크 — 원인이 플랫폼마다 다름(Android intent timing · iOS 초기 URL 순서 · Web hydration 이전). 각각 pending 큐를 두고 초기화 시 우선 처리
동의 UI 분리 — 신규 유저는 가입 직후 모달, 기존 유저는 사용 중 바텀시트 두 벌로 구현

주요 성과

푸시 열람률 33.9% — 3,802건 발송 / 1,290건 열람 (GA4, 2026.04~08)
동의율 21.5%(신규 모달) vs 12.6%(기존 바텀시트) — 같은 요청도 맥락에 따라 1.7배 차이가 난다는 걸 실측으로 확인
3플랫폼을 한 사람이 구현해 동일 기능의 플랫폼 간 동작 차이를 설계 단계에서 제거
진짜 병목은 시스템이 아니라 입구 — 전체 동의율 15.8%, 수신 모수 185명. 열람률이 나쁘지 않아도 모수가 작아 총량이 늘지 않았습니다
알림 설정 페이지는 4개월간 조회 44건 — '알림을 관리하는 경험으로 확장'이라는 초기 가설은 실측으로 기각

성장 경험

딥링크·오프라인 큐·cold start를 아무리 다듬어도 그 앞의 '동의'가 막혀 있으면 총량이 늘지 않는다는 걸 배웠습니다. 동의 화면을 두 벌 만든 덕에 21.5% vs 12.6%라는 비교가 손에 남았는데, 정작 그걸 실험으로 이어가지 못한 게 아쉽습니다. GA 이벤트를 구현 4개월 뒤에 붙여 초기 데이터가 없다는 것도 같은 종류의 실수였습니다.