서버에서 어떻게 푸시 알람을 보내는지에 대한 원리를 다시 떠올리기 위해 아래 문서를 읽어두었습니다. 푸시서버 에서 푸시 서비스 업자 (주로 마케팅 회사에서 사용자 타게팅부터 메시지 최적화, API등을 제공) 를 통해 기기로 푸시를 쏘는 과정을 이해해야 개발자와 원활한 소통이 가능합니다.

https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server

Setting up a remote notification server | Apple Developer Documentation

Generate notifications and push them to user devices.

docs.developer.apple.com

아래는 챗GPT가 정리해준, 푸시 알람을 기획하면서 서버개발자와 원활하게 소통하기 위해 알아야 할 내용입니다. 물론 이 외에도, 사용자 동의 여부 등 기획자(PM)이 챙겨야 할 요소가 정말 많지만, 우선은 개발자와 소통하기 위해 알아야 할 지식에 포커스를 맞춰 봅니다.

푸시 알람은 클라이언트(앱)와 서버 간의 통신이 중요한 요소입니다. PM이 서버 개발자와 효율적으로 소통하려면 푸시 알람의 동작 원리, 기술적 요구 사항, 그리고 구현 시 고려해야 할 사항들을 이해해야 합니다.

1. 푸시 알람의 동작 원리

기본 흐름

1.클라이언트(App):

o앱이 설치되면 **푸시 토큰(Registration Token)**을 디바이스에 할당받음.

o푸시 토큰은 서버와 클라이언트가 소통하는 고유 식별자 역할.

2.서버(Server):

o클라이언트로부터 받은 푸시 토큰을 저장.

o특정 이벤트(예: 사용자 활동, 스케줄된 작업) 발생 시 푸시 알람 발송 요청.

3.푸시 게이트웨이(Gateway):

oAPNs(iOS) 또는 **FCM(Android)**와 같은 푸시 서비스 제공자가 알림을 사용자 기기로 전달.

4.디바이스(Device):

o사용자 디바이스에 푸시 알람이 표시됨.

2. 주요 기술적 개념

1.푸시 서비스

oiOS: Apple Push Notification Service (APNs)

oAndroid: Firebase Cloud Messaging (FCM)

oPM은 각 서비스의 제한 사항과 기능 차이를 이해해야 함.

예: APNs는 배지와 소리를 포함한 알림을 설정 가능.

FCM은 알림 채널(Notification Channel) 기반으로 세부 제어 가능.

2.푸시 토큰

o디바이스마다 고유한 값이며, 주기적으로 갱신될 수 있음.

o서버는 최신 푸시 토큰을 유지해야 하므로, 토큰 갱신 로직 필요.

3.Payload (알림 데이터)

o서버에서 클라이언트로 전송되는 JSON 형식의 데이터.

o주요 필드:

Title: 알림 제목.

Body: 알림 메시지 내용.

Action: 버튼, 링크 등 추가 동작 정보.

Custom Data: 앱에서 사용할 사용자 정의 데이터.

4.예약 및 타겟팅

o예약 발송: 특정 시간에 알림을 발송하도록 서버에서 스케줄링.

o타겟팅:

유저 그룹(예: 지역, 나이).

특정 조건(예: 구매 이력, 앱 활동).

5.리치 알림(Rich Notification)

o이미지, 비디오, 버튼 등이 포함된 고급 알림.

oiOS와 Android 모두 지원하지만, 구현 방식에 차이 있음.

3. 서버 개발과 관련된 요구 사항

1.API 설계

oPM은 서버 개발자와 협력하여 클라이언트-서버 간 API를 정의해야 함.

o주요 API:

푸시 토큰 등록/갱신 API: 디바이스에서 서버로 푸시 토큰 전달.

푸시 발송 API: 서버에서 푸시 게이트웨이로 발송 요청.

알림 읽음 처리 API: 클라이언트에서 읽은 상태를 서버에 업데이트.

2.스케줄링과 큐 시스템

o알림이 많아질 경우 큐 시스템을 사용해 대량 푸시 알람을 효율적으로 처리.

3.타겟 유저 관리

o서버에서 사용자 그룹(세그먼트) 관리.

o예: "서울 지역 사용자", "최근 7일간 구매한 사용자" 등.

4.푸시 로그

o발송 성공/실패 여부를 확인할 수 있도록 로그 관리.

o실패 원인(예: 잘못된 토큰, 만료된 디바이스)을 기록.

4. PM이 서버 개발자에게 요청할 수 있는 사항

1.타겟팅 기능

o지역별, 시간대별, 관심사별 타겟팅이 가능하도록 설계 요청.

o예: 특정 지역의 사용자에게만 알림 발송.

2.예약 발송

o특정 시간에 예약된 알림을 발송하도록 스케줄링 시스템 요청.

3.우선순위 설정

o중요 알림은 높은 우선순위로 빠르게 전달되도록 설정 요청.

o예: 긴급 알림은 "High Priority", 일반 알림은 "Low Priority".

4.리치 알림 지원

o이미지, 버튼 등 고급 알림 형식 구현 요청.

5.알림 상태 추적

o알림 발송 성공 여부와 사용자 상호작용(열람, 클릭) 기록.

5. 테스트와 QA 관련

1.테스트 환경 설정

o개발/테스트/프로덕션 환경을 분리하여 알림 발송 테스트 가능하도록 요청.

2.발송 실패 시 대처

o실패한 푸시 알림에 대한 재발송 로직 구현 요청.

o잘못된 토큰을 정리하는 자동화 프로세스.

3.성능 테스트

o대량 발송 시 서버의 처리 성능을 확인.

o예: 한 번에 1만 개 이상의 푸시 알람 발송 시 지연 발생 여부.

6. 플랫폼별 고려 사항

PM이 알아야 할 협업 포인트

1.알림 데이터 구조 설계

o서버 개발자와 함께 푸시 알람 데이터 구조(JSON Payload)를 설계.

o어떤 필드가 필요한지 명확히 정의.

2.타겟팅 로직

o사용자 세그먼트를 정의하고, 서버에서 이를 관리하도록 요청.

3.알림 실패 처리

o실패 시 재발송 로직 및 실패 원인 분석을 위한 로그 시스템 설계.

4.우선순위 설정

o중요도에 따라 알림 우선순위를 설정하고, 비즈니스 요구에 맞게 구현.

PM이 이러한 기술적 지식을 숙지하면 서버 개발자와 원활하게 소통하고, 푸시 알람 시스템을 효과적으로 기획 및 실행할 수 있습니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari