푸시 운영 (수신 권한과 광고 동의, 발송 설계)

🤔 혹시 이런 생각 해본 적 없나요?

• "알림 권한을 허용한 사용자에게는 프로모션 푸시를 보내도 되는 걸까?"
• "밤 10시에 보내면 열어보는 사람이 많던데, 그대로 해도 문제없을까?"
• "푸시를 늘렸더니 오픈율은 유지되는데 앱을 지우는 사용자가 늘었다."

적정 CPI 산정에서 설치 한 건에 얼마까지 낼 수 있는지를 계산했습니다. 그렇게 확보한 사용자가 앱을 계속 열어야 그 금액을 회수합니다. 푸시는 그 회수를 돕는 수단인데, 국내에서는 보내는 방법보다 보낼 자격을 갖췄는지가 먼저 걸리는 문제입니다.

🔔 푸시 운영은 보내는 기술보다 보낼 자격을 관리하는 일입니다

푸시 운영은 앱 알림을 보낼 권한과 광고를 보낼 동의를 나눠 관리하고, 대상과 시점을 정해 발송하는 절차입니다.

건물 출입에 비유하면 구조가 잡힙니다. 현관 열쇠를 받았다고 건물 안 모든 방에 들어갈 수 있는 것은 아니듯, 알림 권한을 받았다고 어떤 내용이든 보낼 수 있는 것은 아닙니다. 광고를 보내려면 그 방에 들어갈 허가를 따로 받아야 하고, 밤에 들어가려면 허가를 한 번 더 받아야 합니다.

이 구분을 놓치면 법을 어긴 상태로 캠페인이 돌아갑니다. 국내에서 푸시 운영의 첫 단계가 발송 도구 선택이 아니라 동의 설계인 이유입니다.

🚪 알림 권한과 광고 수신동의는 다른 문입니다

실무에서 가장 자주 어긋나는 지점을 표로 정리하면 이렇습니다.

두 가지가 모두 있어야 광고성 푸시를 보낼 수 있습니다. 알림 권한만 받고 할인 안내를 보내는 것은 동의 없이 광고를 보낸 것에 해당합니다.

주문 확인이나 배송 상태처럼 사용자가 요청한 거래 정보는 광고성 정보가 아니므로 수신동의 없이 보낼 수 있습니다. 다만 같은 알림 안에 할인 문구를 끼워 넣으면 광고로 판단될 여지가 생깁니다.

⚖️ 국내 법이 정한 조건

정보통신망 이용촉진 및 정보보호 등에 관한 법률이 기준입니다. 앱 푸시도 전자적 전송매체에 해당해 규정을 그대로 따릅니다.

• 사전 동의: 영리 목적의 광고성 정보를 보내려면 수신자의 사전 동의를 받아야 합니다. 앱 푸시의 수신동의는 설치만 한 상태, 최초 실행 단계, 로그인 이후 단계로 나눠 받는 방식이 안내되고 있습니다.
• 야간 전송: 제50조 제3항은 오후 9시부터 다음 날 오전 8시까지 광고성 정보를 보내려면 별도의 사전 동의를 받도록 정합니다. 일반 수신동의만으로는 이 시간대에 보낼 수 없습니다.
• 표기 의무: 광고성 정보에는 제목이 시작되는 부분에 광고임을 밝히고 전송자의 명칭과 연락처를 적습니다. 끝부분에는 수신거부 방법을 함께 안내합니다.
• 정기 확인: 동의를 받은 뒤에도 2년마다 수신동의 여부를 다시 확인해야 하고, 지키지 않으면 과태료 대상이 됩니다.

밤 시간대의 반응이 좋다는 이유로 발송 시각을 늦추는 경우가 있는데, 별도 동의 없이 그 시간에 보내면 성과와 무관하게 위반입니다. 야간 동의를 따로 받아 둔 사용자만 골라 보내는 것이 순서입니다.

📱 안드로이드 13 이후 달라진 권한 요청

플랫폼 조건도 바뀌었습니다. 안드로이드 13(API 수준 33)부터 알림 전송에 POST_NOTIFICATIONS 런타임 권한이 필요합니다. 그 전까지 안드로이드는 알림이 기본으로 켜져 있고 사용자가 끄는 방식이었는데, 이제는 iOS처럼 사용자가 켜 줘야 하는 방식이 됐습니다.

여기서 개발 설정이 성과를 가릅니다. 앱이 API 수준 32 이하를 목표로 만들어져 있으면 시스템이 앱 첫 실행이나 첫 알림 채널 생성 시점에 권한 대화상자를 자동으로 띄웁니다. 사용자가 앱을 이해하기 전에 창이 뜨는 셈이라 거부로 이어지기 쉽고, 한 번 거부당하면 앱을 지웠다 다시 깔거나 목표 버전을 올리기 전까지 그 창이 다시 뜨지 않습니다.

위 이미지는 구글이 공식 문서에서 권장하는 흐름입니다. 로그인을 마친 뒤 알림을 받으면 무엇이 좋은지 먼저 설명하고, 사용자가 받겠다고 누른 다음에 시스템 대화상자를 띄웁니다. 권한을 언제 물을지 고를 수 있게 하려면 앱이 안드로이드 13 이상을 목표로 잡혀 있어야 합니다.

정리하면 요청 시점 설계가 마케팅 자산이 됩니다. 권한을 잃은 사용자에게는 어떤 캠페인도 닿지 않기 때문입니다.

🔄 권한을 거부한 사용자에게 남은 경로

권한 요청은 한 번에 끝나는 관문이라 거부당하면 되돌리기가 쉽지 않습니다. 시스템 대화상자는 다시 뜨지 않으므로 사용자가 직접 설정에서 켜야 합니다.

그래서 실무에서는 남은 통로를 함께 준비합니다.

• 앱 안에서 안내합니다. 알림이 필요한 화면에서 왜 필요한지 설명하고 기기 설정 화면으로 이동하는 버튼을 붙입니다. 주문 상태나 예약 시간처럼 사용자에게 이득이 분명한 맥락일 때 허용을 누를 가능성이 올라갑니다.
• 인앱 메시지로 대체합니다. 앱을 열었을 때 화면 안에서 보여 주는 방식이라 알림 권한이 없어도 닿습니다. 다만 앱을 열지 않는 사용자에게는 소용이 없습니다.
• 다른 채널을 씁니다. 문자나 이메일, 카카오 알림톡으로 같은 내용을 보냅니다. 채널이 달라도 광고성 정보라면 수신동의 규정을 똑같이 지켜야 합니다.

권한을 늦게 묻는 설계가 유리한 이유가 여기서 나옵니다. 설치 직후에 물어 거부당하면 그 사용자에게는 한동안 닿을 수 없는 반면, 앱의 쓸모를 경험한 뒤에 물으면 허용받을 확률이 높아집니다.

🎯 무엇을 언제 보낼지 정하는 순서

자격을 갖췄다면 다음은 발송 설계입니다. 순서를 정해 두면 판단이 빨라집니다.

1. 목적을 하나로 정합니다. 휴면 사용자를 다시 부르는 것과 오늘 구매를 늘리는 것은 대상도 문구도 다릅니다.
2. 대상을 나눕니다. 최근 접속일, 구매 이력, 관심 카테고리로 나눕니다. 전체 발송은 수신거부만 늘리는 경우가 많습니다.
3. 도착 지점을 연결합니다. 딥링크로 해당 상품이나 화면에 바로 닿게 걸어 둡니다. 홈 화면으로 보내면 사용자가 그 상품을 다시 찾아야 합니다.
4. 빈도 상한을 둡니다. 한 사용자에게 주 몇 회까지 보낼지 정해 두고, 여러 팀이 각자 보내지 않도록 발송 창구를 모읍니다.

📉 오픈율만 보면 놓치는 것

성과는 오픈율 하나로 판단하기 어렵습니다. 같은 캠페인을 대상별로 나눈 가상의 결과입니다.

전체 발송의 오픈율 4.2퍼센트는 활성 사용자가 끌어올린 값입니다. 30일 이상 접속하지 않은 대상에게는 거의 열리지 않으면서 수신거부만 여덟 배 넘게 나왔습니다. 수신거부는 되돌리기 어려운 손실입니다. 한 번 빠져나간 사용자에게는 이후 어떤 캠페인도 보낼 수 없기 때문입니다.

그래서 함께 보는 지표가 리텐션입니다. 푸시의 목적은 알림을 열게 하는 것이 아니라 앱으로 돌아오게 하는 것이므로, 발송한 집단과 발송하지 않은 집단의 재방문 차이를 비교하는 편이 정확합니다.

다음 클래스에서는 구글 앱 캠페인과 Apple Ads 운영을 다룹니다.

❓ 야간 푸시는 몇 시부터 몇 시까지 제한되나요?

오후 9시부터 다음 날 오전 8시까지입니다. 2026년 8월 기준으로 정보통신망법 제50조 제3항이 이 시간대의 광고성 정보 전송에 별도의 사전 동의를 요구합니다.

일반 수신동의만 받은 사용자에게는 이 11시간 동안 광고성 푸시를 보낼 수 없습니다. 야간 전송 동의를 따로 받아 둔 사용자 목록을 구분해 관리하는 것이 실무의 출발점입니다.

❓ 배송 알림에도 광고 표기를 붙여야 하나요?

주문 확인이나 배송 상태처럼 사용자가 요청한 거래 정보만 담겨 있다면 광고성 정보가 아니므로 표기 의무가 없습니다.

다만 같은 알림에 할인 쿠폰이나 추천 상품 문구를 끼워 넣는 순간 광고로 판단될 여지가 생깁니다. 거래 알림과 광고 알림을 처음부터 분리해 보내는 것이 표기 실수를 막는 가장 단순한 방법입니다.

📋 30초 요약

1. 알림 권한과 광고성 정보 수신동의는 다른 것입니다. 권한은 운영체제가 주고 동의는 사용자가 서비스에 합니다. 둘 다 있어야 광고성 푸시를 보낼 수 있고, 권한만 받고 할인 안내를 보내면 동의 없는 광고 전송이 됩니다.

2. 오후 9시부터 다음 날 오전 8시까지는 별도 동의가 필요합니다. 정보통신망법 제50조 제3항이 정한 조건이고, 광고 표기와 수신거부 안내, 2년마다의 동의 재확인도 함께 지켜야 합니다.

3. 오픈율 하나로 판단하지 않습니다. 휴면 대상 발송은 열리지도 않으면서 수신거부만 늘려 다음 기회를 없앱니다. 대상을 나눠 재방문 기여를 보고, 안드로이드 13 이후에는 권한 요청 시점 설계까지 성과에 포함해 봅니다.

참고 자료

• 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 국가법령정보센터
• 알림 런타임 권한, Android Developers
• Android 13 알림 권한 변경 안내, Android Developers