저는 최근 자사 하이브리드 앱을 구축하는 프로젝트에서 기획과 PM을 맡으며, 자체 앱 푸시 서버까지 신규로 구축하게 됐습니다. 이 프로젝트에서 푸시 관련 정책과 기능을 정의하면서, 하나씩 정리하다 보니 여러 가지 법적, 정책적으로 확인해야 할 사항들이 몇 가지 있었는데요.

“사용자가 알림 권한을 거부하면 예약 변경도 보내지 않는 걸까?”, “광고 수신동의와 OS 푸시 허용은 같은 값으로 보면 되는건가?”, “앱을 사용하고 있는 중에도 스케줄 변경 알림을 띄워야 하는 건가?” 등 이러한 질문들에 답하려다 보니, 푸시 알림은 단순히 어떤 메시지를 발송하는지가 중요한 것이 아니라, 법률, OS 정책, 서비스 정책까지 함께 고려해야 할 기획이 많았습니다. 그래서 이번 글은 처음 푸시 설계를 하면서 직접 찾아보고, 테스트하며 하나씩 풀어가며 정리한 기록을 담아봤습니다.

법률·OS 정책·약관 흐름도가 겹쳐진 스마트폰 화면과 그 주변을 떠다니는 말풍선·알림종 아이콘, 푸시 알림 기획을 상징하는 일러스트 — <출처: 작가>

먼저 용어부터 정리하고 시작하겠습니다. 이번 글에서는 아래의 4가지를 중점적으로 이야기할 예정입니다.

OS 알림 권한·광고성 정보 수신동의·앱 내 알림 설정·알림센터 네 가지 구분과 그 의미를 정리한 표

이 알림, 법적으로 보내도 되는 걸까?

앱 푸시로 보내는 메시지는 모두 같은 법적 취급을 받지 않습니다.

확인 1. 광고성인가, 정보성인가

광고성인가, 정보성인가: 정보통신망법 제50조제1항은 영리목적의 광고성 정보를 보낼 때 사전 동의를 받도록 정하고 있습니다. 프로모션·이벤트 안내는 광고성 정보, 예약 확정·결제 완료는 정보성 안내로 분류됩니다(출처: 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」, 법률 제21445호(2026. 3. 10. 타법개정), 제50조제1항).
광고성이라면, 사전동의 예외에 해당하는가: 광고성 정보라고 해서 무조건 사전 동의가 필요한 건 아닙니다. 재화나 서비스의 거래 관계를 통해 수신자로부터 직접 연락처를 수집한 경우, 시행령으로 정한 기간 안에 그 거래와 같은 종류의 재화·서비스에 대한 광고성 정보를 보내는 건 예외적으로 사전 동의 없이 가능합니다(출처: 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」, 법률 제21445호(2026. 3. 10. 타법개정), 제50조제1항제1호). 예를 들어 항공권을 구매한 고객에게 같은 서비스의 다른 항공권 할인 소식을 보내는 경우가 여기에 해당할 수 있습니다.

즉, ‘광고성인가 정보성인가’와 ‘광고성이라면 동의 예외에 해당하는가’는 서로 다른 질문으로, 각각 별도로 확인하고 판단해야 합니다.

확인 2. 언제, 어떻게 표시해야 하나

광고성 정보에 대한 동의는 한 시점에 한 번 받고 끝나는 방식만 있는 게 아니라, 서비스 흐름의 여러 시점에 걸쳐 나눠 받는 방식도 안내되어 있습니다. 오후 9시부터 다음 날 오전 8시까지 광고성 정보를 보내려면 별도의 야간 동의도 필요합니다(정보통신망법 제50조 제3항, 위반 시 과태료 대상). 수신거부나 동의철회는 즉시 처리해야 하고, 정기적으로 이 동의를 계속 유지할지 확인하는 절차도 따로 있습니다(정확한 주기는 기획하는 시점에 관련 법률 확인을 권장합니다).

저의 경우에 이 제약은 휴먼에러 방지를 위해, 광고 알림을 전송하는 어드민 화면에 반영했습니다. 다만 시스템이 기술적으로 야간 발송 자체를 차단하는 방식으로 구성하지는 않았습니다. 법적으로는 별도의 야간 동의를 받은 사용자에게는 이 시간에도 보낼 수 있지만, 저희는 야간 동의를 따로 받는 흐름을 아직 두지 않았기에, 발송시간을 설정하는 프론트단에서 오전 8시부터 오후 8시 59분까지, 15분 단위로만 지정할 수 있게 제한해서, 관리자가 야간시간 규정을 벗어난 시각을 애초에 입력할 수 없도록 구현했습니다.

이후 내부 정책이 바뀌어 야간 동의를 받는 구조를 추가하게 될 가능성을 염두에 두고, 지금은 이 제약을 시스템 로직이 아니라 UI 단에만 걸어두는 방식으로 기획했습니다.

표기 규정도 있습니다. 광고성 정보에는 전송자의 명칭·연락처와, 수신거부나 동의철회를 쉽게 할 수 있는 방법을 구체적으로 밝혀야 합니다(출처: 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」, 법률 제21445호(2026. 3. 10. 타법개정), 제50조제4항). 실무에서는 이걸 흔히 ‘(광고)’ 표시와 수신거부 안내 문구로 구현하는데, 정확한 표시 방법의 세부 기준은 시행령에 위임되어 있어 이 글에서는 원칙만 언급하겠습니다.

확인 3. OS 권한과 광고동의는 다른 동의

여기서 기획하는 단계에서 헷갈렸던 게 하나 더 있었습니다. 사용자가 OS 알림 권한을 켜뒀다는 것과 광고성 정보 수신에 동의했다는 것은 법적으로 별개의 영역으로, 마케팅 메시지를 보내려면 OS 알림 권한과는 별도로 광고성 정보 수신동의를 받아야 합니다.

마케팅 메시지와 시스템이 자동으로 내보내는 예약·결제 알림을 처음부터 다른 카테고리로 나눴습니다. 두 유형을 같은 기준으로 묶으면 정보성 안내에도 광고 동의 절차를 요구하거나, 반대로 광고성 정보에 필요한 동의 없이 보내는 상황이 생길 수 있겠다고 판단했습니다. 광고성 정보 수신동의는 가입 상태에 따라 다르게 처리했습니다.

이미 웹에서 회원가입 때 동의한 사용자는 앱에서도 그 동의를 그대로 이어받았고, 아직 회원이 아닌 사용자는 앱을 처음 설치할 때 동의를 유도했습니다. 동의 철회는 마이페이지에서 언제든 할 수 있게 했는데, 이건 수신거부·철회 의사표시를 쉽게 할 수 있는 방법을 마련해야 한다는 규정(출처: 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」, 법률 제21445호(2026. 3. 10. 타법개정), 제50조제4항)을 반영한 부분입니다.

OS는 이 알림을 순순히 보내줄까?

법률 다음으로 중요하게 생각했던 건, OS가 알림 권한을 다루는 방식이었습니다(아무리 법을 잘 지켜서 구성해도, OS에서 막아버린다면 소용이 없으니깐요). 이 권한을 사용자가 직접 허용해야만 알림을 받을 수 있게 하는 방식을 옵트인(Opt-in)이라고 부릅니다. Android와 iOS는 이 옵트인을 다루는 기본값 자체가 서로 달라 각각의 개발자 센터 페이지에서 확인해봤습니다.

Android: 오랫동안 옵트아웃(Opt-out)에 가까운 방식이었습니다. 13 이전까지는 사용자가 따로 거부하지 않는 한 알림이 자동으로 켜진 채 시작됐기 때문입니다. 13부터는 알림 표시를 위한 POST_NOTIFICATIONS 런타임 권한이 도입되면서 옵트인 방식으로 바뀌었습니다. 이제는 사용자가 명시적으로 동의해야만 알림이 켜집니다.(출처: Android Developers, Notification runtime permission)

iOS: 까다로운 iOS답게, 처음부터 옵트인 방식입니다. 사용자가 명시적으로 허용해야만 알림을 받을 수 있고, Android보다 더 엄격한 기준을 가지고 있습니다. Apple의 디자인 가이드라인은 “Request permission only when your app clearly needs access to the data or resource.”(데이터나 리소스에 대한 접근이 명확히 필요할 때만 권한을 요청하라는 뜻입니다.)라고 명시합니다.(출처: Apple Human Interface Guidelines, Privacy — Requesting permission) 앱이 한 번 권한을 요청해 사용자가 거부하면, 이후 같은 시스템 팝업을 다시 띄울 방법이 없고 사용자가 직접 설정에서 바꿔야 한다는 의미입니다.

iOS는 한 번 거부당하면 앱이 임의로 다시 물어볼 방법이 없습니다. Android는 처음 거부해도 한 번은 다시 요청할 수 있지만, 사용자가 두 번째도 거부하거나 ‘다시 묻지 않음’을 선택하면 그때부터는 iOS와 마찬가지로 재요청이 막힙니다. 결국 두 플랫폼 모두 언젠가는 설정 화면으로 안내하는 것 말고는 방법이 없어지는 구조입니다.

이 두 가지를 확인하고 나니, 언제, 어떻게 권한을 요청해야 할지가 중요한 포인트였습니다.

저는 일반적으로 많이 사용하는 UX와 동일하게 최초 앱 실행 시, 미디어/파일·카메라·푸시 알림처럼 필요한 권한들을 한 화면에 먼저 모아서 안내했습니다. 확인을 누르면 그다음에 순서대로 각 OS 권한 팝업이 뜨는 방식으로 만들었고, 이후에는 마이페이지 설정 화면에서도 다시 권한 상태를 확인하고 켤 수 있게 진입점을 하나 더 열어뒀습니다.

이 마이페이지 토글에도 장치를 하나 더 뒀습니다. 사용자가 토글을 켜려고 할 때 OS 알림 권한이 꺼져 있으면, 토글을 그대로 켜는 대신 OS 설정 화면으로 이동시키도록 만들었습니다. 인앱 설정만 켜둔 채 알림이 정상적으로 오고 있다고 착각하는 상황을 막기 위해서였습니다.

접근 권한 허용 안내 팝업(미디어/파일, PUSH알림 선택 동의)과 OS 알림 권한 요청 팝업(허용 안 함/허용) 화면 — 프라이밍 스크린(Priming screen) 과 opt-in 팝업 예시 <출처: 작가>

앱 설정 화면의 앱 푸시 알림 동의 토글과, OS 설정에서 알림을 켜달라는 안내 팝업, 마케팅 정보 수신 동의 완료를 알리는 팝업 — 마이페이지에서 설정을 변경했을때 os도 함께 변경할 수 있도록 유도하는 팝업 예시 <출처: 작가>

이런 방식을 UX 용어로 흔히 ‘프라이밍 스크린(Priming screen)’이라고 부릅니다. OS의 기본 권한 팝업은 맥락 없이 불쑥 뜨기 때문에 거부율이 높은데, 그 앞에 왜 이 권한이 필요한지 먼저 설명하면 승낙률이 올라간다는 게 널리 알려져 있고, Apple과 Google도 이 방식을 권장하고 있습니다. 제가 새로운 방법을 고안했다기보다는, 이미 검증된 패턴을 미디어/파일·카메라·푸시 알림이라는 저희 서비스의 실제 권한 목록에 맞게 적용한 쪽에 가깝습니다.

그 다음으로 찜찜하게 걸렸던 질문이 있습니다. 사용자가 이 요청을 거부하면, 예약이 바뀐 사실 같은 중요한 정보는 어떻게 전달해야 할까요…? 여기까지는 법과 OS가 이미 정해둔 조건 안에서 UX적으로 풀어낸 부분입니다. 그다음의 기획은 그 기본적인 조건 위에서 제가 하나씩 정리하고 기획해야 하는 부분이었습니다.

그래서 이걸 기획에 어떻게 녹여냈나

법과 OS의 제약을 확인한 뒤에도, 실제로 명세서에 옮기려면 몇가지 판단이 더 필요했습니다. 제가 기준으로 삼았던 관점은, 이 알림을 받지 못하면 사용자가 우리 서비스를 이용할 때 어떤 불편을 겪는가였습니다. 이 기준으로 발송 정책을 설계하고 나머지 기획을 정리했습니다.

고민 1. 누구에게, 어떤 조건에서 보낼 것인가

가장 먼저 정리해야 했던 건, 사용자가 반드시 받아야 하는 정보와, 그렇지 않은 마케팅성 메시지를 분리하는 것이었습니다.

시스템 자동발송: 예약완료, 취소완료, 스케줄변경, 웹체크인처럼 예약 상태 값이 바뀌면 트리거 조건이 명확해 자동으로 나갑니다. 커머스에서는 결제완료, 배송시작, 배송완료 등이 트리거가 될 수 있겠죠.
관리자 수동발송: 광고성 정보 수신동의를 확인한 뒤, 관리자가 어드민 화면에서 타깃·문구·시점을 직접 설정해 내보냅니다.

즉, 사용자에게 필수적으로 전달돼야 하는 시스템 알림과 그렇지 않은 광고성 알림은 애초에 같은 기준으로 다룰 수 없기 때문에 분리하여 구성했습니다.

수동발송을 설계하면서는 또 다른 문제를 만났습니다. 구현된 영역을 테스트하다 보니, 동일한 푸시가 3건, 4건씩 날아와서 원인을 파악해보니 아래와 같은 문제가 있었습니다.

문제: 여러 타깃 조건을 OR로 결합해 마케팅팀과 테스트 발송을 진행했는데, 두 조건을 동시에 만족하는 사용자가 대상 리스트에 중복으로 포함됐습니다.
원인: 기획 단계에서는 조건식을 정의하는 것만 생각했지, 여러 조건에 동시에 해당하는 사용자를 어떻게 처리할지는 별도로 정의하지 않았습니다.
해결: 조건절을 AND와 OR로 명확히 구분하고, 사용자 식별자를 기준으로 여러 조건에 겹치는 사용자에게는 한 번만 발송되도록 중복 제거 정책을 추가했습니다.

조건을 정의하는 것과, 그 조건들이 겹쳤을 때 무슨 일이 일어나야 하는지를 정의하는 건 다른 문제입니다. 기획에서는 조건을 만드는 데 집중하지만, 실제 시스템에서는 조건들이 조합됐을 때의 결과까지 정책으로 정의해두어야 개발팀과 원활하게 기획의도와 정책을 커뮤니케이션할 수 있습니다.

고민 2. Push를 받을 수 없다면, 정보는 어디에 남길 것인가

처음 작성한 명세서에서는 OS 알림 권한이 꺼진 사용자에게는 예약완료나 스케줄변경 같은 시스템 알림도 보내지 않는 것으로 정의했습니다. (사용자가 직접 선택했으니 안 보내도 되겠지, 라고 단순하게 생각했습니다.)

발송 시나리오를 점검하며 다시 생각해보니, 사용자가 OS 알림 권한을 꺼놓은 상태에서 항공권 스케줄이 변경되면 어떻게 되는가? 중요한 서비스 정보까지 그 사용자에게는 전혀 전달되지 않는 구조였습니다. ‘알림 채널의 허용 여부’와 ‘이 정보를 사용자에게 전달해야 하는가’를 같은 문제로 취급하고 있었던 겁니다.

기획서를 아래와 같이 분기해서 업데이트했습니다.

푸시 알림(P): OS 알림 권한이 필요한 채널입니다. 권한이 꺼져 있으면 발송 자체가 불가능합니다.
앱 내 알림(N): 앱 내부의 알림 설정만으로 쌓이는 채널입니다. OS 권한과 무관하게 알림센터에 기록됩니다.

예약완료·취소완료·스케줄변경·웹체크인 같은 정보성 안내는 사용자가 광고성 정보 수신동의를 꺼둔 상태에서도 OS 알림 권한만 켜져 있으면 P로 발송되고, 동시에 N에도 기록되도록 정의했습니다. 여기서 OS 알림 권한 자체가 꺼져 있다면 이 구조로도 푸시를 강제로 띄울 방법은 없고, 그 경우엔 알림센터 기록만 남습니다. 다만 이게 Push와 똑같은 수준으로 전달되는 건 아닙니다. 알림센터에 남은 기록은 사용자가 직접 앱을 열어야 확인할 수 있으니까요. 그래도 OS 권한 하나 때문에 서비스 정보가 시스템에서 완전히 사라지지는 않도록 하자는 게 판단의 기준이었습니다.

고민 3. 앱을 이미 쓰고 있을 때도 띄울 것인가

사용자가 이미 앱을 보고 있을 때도 이 알림을 띄울 것인가라는 질문도 같은 기준으로 풀었습니다. 스케줄변경과 예약완료처럼 사용자의 일정에 직접 영향을 주는 정보는 띄우고, 마케팅 메시지는 사용 흐름을 끊을 이유가 없다고 보고 띄우지 않기로 했습니다. 기술적으로는 OS 푸시가 앱이 백그라운드에 있을 때는 FCM SDK가 기기에 자동으로 표시하지만, 포그라운드에 있을 때는 화면에 띄울지 말지를 앱의 코드가 직접 결정해야 한다는 사정도 있었습니다. (출처: Firebase, About FCM message types) FCM은 이 자동 표시를 담당하는 알림(Notification) 페이로드와, 앱이 직접 처리해야 하는 데이터(Data) 페이로드를 구분해서 제공하는데, 포그라운드에서 배너 노출 여부를 직접 판단하려면 이 구분부터 이해해야 했습니다.

FCM(Firebase Cloud Messaging): 구글이 제공하는 푸시 발송 인프라입니다. 페이로드: 서버가 기기로 실제 전달하는 메시지 데이터로, 도착하면 시스템이 자동으로 화면에 띄우는 알림(Notification) 페이로드와 앱이 직접 처리 방식을 결정하는 데이터(Data) 페이로드로 나뉩니다. 포그라운드 배너(=인앱 푸시 배너): 사용자가 앱을 이미 켜서 쓰고 있는 도중에 화면 상단 등에 잠깐 떴다 사라지는 알림입니다. 이 글에서는 두 표현을 같은 뜻으로 씁니다.

그래서 예약완료·취소완료·스케줄변경 같은 정보성 안내만 앱을 쓰는 도중에도 인앱 푸시 배너로 바로 띄우도록 했습니다.

이 배너에 실제로 얼마나 보일지도 함께 고려해야 했습니다. 어드민의 메시지 입력창 자체는 최대 1,500byte까지 쓸 수 있게 정해뒀는데, 정작 포그라운드 배너에 노출되는 길이는 기기와 OS 버전마다 달랐습니다. Android와 iOS 모두 공식적으로 정해진 글자수 제한은 없고, 화면 크기와 폰트에 따라 잘리는 지점이 제각각이었습니다.(편집 메모: Android/iOS 노출 글자수의 실제 내부 테스트 기준이나 구체적인 관찰값이 있다면 추가 예정)

뒷부분이 잘려도 의미가 통하도록, 실 메시지 발송부서인 마케팅팀에는 핵심 내용을 문장 맨 앞에 배치하는 걸 기본 원칙으로 안내했습니다. 이미지를 포함하는 리치 푸시는 이때는 구성하지 못한 부분입니다. 텍스트 길이만큼이나 플랫폼별로 지원 방식이 다른 영역이라, 이후 고도화 단계에서 다뤄볼 계획입니다.

이 판단은 나중에 트리거 조건을 추가하면서 구체화됐습니다. 예약 관련 화면에 진입했을 때와 앱이 백그라운드에서 포그라운드로 전환되는 시점, 이 두 이벤트가 발생하면 인앱 푸시 여부를 다시 확인하도록 정의했습니다.

고민 4. 알림을 누른 다음, 어디로 보낼 것인가

딥링크 목적지

알림을 눌렀을 때 어디로 이동시킬지도 정해야 했습니다. 기준으로 삼은 건 알림이 만들어지는 순간에 목적지를 이미 알고 있는가였습니다. 예약완료·취소완료·스케줄변경처럼 ‘나의 예약’ 카테고리로 묶은 시스템 알림은 목적지가 예측 가능했기 때문에 해당 예약의 상세 화면으로 고정했습니다. 반면 마케팅 메시지는 캠페인마다 목적지가 달라지기 때문에, 관리자가 어드민 화면에서 타깃·문구·발송 시점과 함께 딥링크를 직접 입력하도록 뒀습니다.

클릭 이후의 예외 상황도 함께 고려해야 했습니다. 로그인이 만료된 상태에서 알림을 클릭하는 경우, 푸시 토큰은 로그인 여부와 무관하게 유지되기 때문에 알림 자체는 정상적으로 도착합니다. 다만 딥링크로 연결되는 화면은 로그인이 필요한 경우가 많아서, 이럴 때는 일단 로그인 페이지로 이동하도록 처리했습니다.

설정 화면

알림을 관리하는 화면을 설계할 때도 비슷한 고민을 했습니다. 네이티브 앱으로 구축한 게 아니라, 기본적으로 회원정보와 데이터를 같이 사용하는 하이브리드 앱의 특성상, 앱과 웹에서 같은 수신 설정을 서로 다르게 관리할 이유가 있는가였습니다. 저는 그럴 필요가 없다고 판단했습니다. 화면을 따로 두면 사용자가 관리해야 할 상태가 두 개로 늘어날 뿐이라고 봤습니다. 그래서 새 화면을 만드는 대신, 이미 웹사이트에 있던 ‘설정 수신여부 관리’ 화면을 마이페이지 설정 메뉴에서 그대로 이어받아 설정의 기준을 하나로 유지했습니다.

위의 확인, 고민들을 거쳐 설계된 푸시 서버와 발송 정책이 지금 운영 중인 푸시 알림 체계의 기준이 되었습니다.

마치며

처음에는 푸시 알림을 기획한다는 것이 어떤 메시지를 누구에게, 언제 보낼지를 정하는 일이라고 생각했습니다. 하지만 실제로 설계해보니 중요한 것은 메시지보다 ‘전달의 조건’이었습니다.

이 메시지는 광고성 정보인가, 정보성 안내인가. OS 알림 권한을 거부했다면 중요한 정보는 어디에 남길 것인가. 앱을 사용하고 있을 때도 알려야 하는가. 알림을 누른 뒤에는 어디로 이동시킬 것인가.

결국 IT서비스 기획자에게, 푸시 알림은 메시지를 보내는 기능이 아니라, 사용자에게 필요한 정보가 어떤 조건에서, 어떤 채널을 통해 전달되어야 하는지를 설계하는 일에 가까웠습니다. 물론 여기서 정리한 방식이 모든 서비스에 그대로 적용되는 정답은 아닙니다. 서비스의 성격과 사용자 이용 방식에 따라 필요한 정책과 채널은 달라질 수 있고, 리치 푸시나 발송 성과 분석, 실패 메시지 재처리 등 운영하면서 추가로 고도화해야 할 부분도 많습니다.

이 글이 처음 푸시 설계를 시작한 기획자에게 조금이나마 도움이 되었으면 좋겠습니다.

이 글은 AI의 도움을 받아 작성했습니다.