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

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

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

적정 CPI 산정에서 설치 한 건에 얼마까지 낼 수 있는지를 계산했습니다. 앱 재방문은 목표가 될 수 있지만 앱을 연 횟수만으로 광고비가 회수되지는 않습니다. 푸시가 알릴 내용과 사용자가 받기로 한 범위부터 확인합니다.

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

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

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

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

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

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

일반적인 광고성 푸시에서는 표시 권한과 광고 수신동의를 따로 확인합니다. 알림 허용 버튼을 광고 수신동의로 대신 기록하지 않습니다. 법이 정한 제한적인 사전 동의 예외가 있지만 단순 설치나 가입만으로 예외라고 가정하지 않습니다.

사용자가 요청한 주문과 배송 처리에 필요한 거래 정보만 담긴 알림은 광고와 구분할 수 있습니다. 광고 문구나 일방적으로 지급한 쿠폰 안내를 섞었다면 전체 내용을 기준으로 다시 분류합니다. 알림 제목만 배송 안내라고 붙여 광고 규정을 피할 수는 없습니다.

⚖️ 국내 법이 정한 조건

국내 광고성 푸시는 정보통신망법 제50조와 시행령 및 한국인터넷진흥원(KISA) 안내서를 확인합니다. 아래는 기본 확인 항목이며 실제 문구와 동의 기록에 맞춰 담당자가 적용 범위를 대조해야 합니다.

• 광고 동의: 원칙적으로 명시적인 사전 동의가 필요합니다. 어떤 서비스와 채널의 광고인지 분명히 밝히고 동의 시점과 내용을 기록합니다.
• 야간 동의: 오후 9시부터 다음 날 오전 8시까지의 광고성 푸시는 별도의 사전 동의를 확인합니다.
• 표시와 거부 경로: 시작 부분의 (광고), 전송자 정보와 연락처, 무료 수신거부 방법 등 해당 매체의 표시 기준을 적용합니다. 전송자 이름과 앱 이름이 같은 경우 등 생략 가능한 조건도 해당 안내로 확인합니다. 앱 푸시에는 수신거부 페이지로 바로 이어지는 방법을 준비하며 로그인이나 복잡한 절차를 요구하지 않습니다.
• 철회 반영: 거부하거나 철회한 범위에 광고를 보내지 않습니다. 예약 목록에도 최신 상태를 반영하고 처리 결과를 알립니다.
• 정기 확인 안내: 동의일부터 2년마다 동의 사실과 날짜, 유지 또는 철회 방법 등을 알리는 확인 안내를 관리합니다. 매번 새 동의 버튼을 누르게 해야 한다는 뜻은 아닙니다.

야간 동의가 있어도 광고 동의를 철회했다면 보낼 수 없습니다. 2026년 3월 KISA 개정 안내는 모호한 광고 동의 표현과 로그인 등을 요구하는 푸시 수신거부 절차를 특히 짚습니다. 실제 적용 시 최신 안내서의 앱 푸시 예시와 본문 조건을 함께 확인합니다.

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

Android 13(API 수준 33) 이상에서 일반 알림은 POST_NOTIFICATIONS라는 실행 중 권한 요청의 적용을 받습니다. API 수준은 앱이 대상으로 삼는 Android 기능 버전의 번호입니다. 새로 설치한 앱과 기존 앱의 운영체제 업그레이드, 일부 예외 알림의 조건이 다릅니다.

대상 버전이 33 이상이면 앱이 요청 시점을 설계할 수 있습니다. 32 이하인 앱에서는 알림 채널 생성과 화면 시작 조건에 따라 시스템이 요청 시점을 정합니다. 모든 앱에서 첫 실행 순간에 무조건 뜬다고 이해하지 않습니다. 실제 대상 버전과 기기 상태는 개발팀에 확인합니다.

위 그림은 앱 소개와 알림의 이유, 시스템 권한 창을 연결한 공식 예입니다. 로그인이나 중간 설명 화면을 모든 앱에 의무적으로 넣으라는 뜻은 아닙니다. 주문 알림 받기처럼 사용자가 이해할 수 있는 맥락에서 요청하고 거절도 가능하게 설계합니다.

🔄 권한 거부와 광고 철회를 나눠 처리합니다

권한을 한 번 거절하면 모든 기기에서 영원히 다시 요청할 수 없다는 규칙은 없습니다. 운영체제와 대상 버전, 거절 이력에 따라 재요청 조건이 달라집니다. 현재 상태를 확인하고 필요한 경우 설정으로 이동하는 방법을 안내하되 반복해서 압박하지 않습니다.

앱을 열었을 때 보여 주는 인앱 메시지는 푸시와 표시 방식이 다릅니다. 그러나 광고 철회를 우회하는 수단으로 쓰지 않습니다. 문자나 이메일을 대신 보내려면 그 서비스와 채널에 적용되는 동의 및 거부 범위를 먼저 확인합니다. 채널을 바꿨다고 광고가 거래 안내로 바뀌지는 않습니다.

동의를 다시 받았거나 설정이 바뀌는 경우도 있으므로 사용자 상태를 최신으로 관리합니다. 이전에 허용했던 기록만 보고 발송하지 않습니다.

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

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

1. 목적을 하나로 정합니다. 휴면 사용자를 다시 부르는 것과 오늘 구매를 늘리는 것은 대상도 문구도 다릅니다.
2. 대상을 나눕니다. 최근 접속일, 구매 이력, 관심 카테고리로 나눕니다. 해당 내용이 필요한 대상인지와 동의 상태를 함께 확인합니다.
3. 도착 지점을 연결합니다. 딥링크로 해당 상품이나 화면에 바로 닿게 걸어 둡니다. 홈 화면으로 보내면 사용자가 그 상품을 다시 찾아야 합니다.
4. 빈도 상한을 둡니다. 한 사용자에게 정한 기간에 몇 회까지 보낼지 정하고 여러 팀의 중복 발송을 막습니다. 예약과 재시도가 야간으로 넘어가는 경우도 처리합니다.

본문 내용을 시각화한 학습용 도식입니다. 실제 서비스 화면이 아닙니다. 본문의 발송 설계 순서입니다. 권한과 수신동의 등 발송 전제 조건은 본문을 함께 확인합니다.

📉 오픈율만 보면 놓치는 것

오픈율은 정한 분모 중 알림을 연 비율입니다. 발송 요청 수인지 도달 수인지, 중복을 뺀 사람 수인지 도구의 정의를 확인합니다. 요청했다고 모두 기기에 표시되는 것은 아닙니다.

다음은 같은 캠페인 자료를 나눈 가상 표입니다. 각 사용자에게 한 번 요청했고 각 비율의 분모는 해당 행의 대상자 수로 통일했다고 가정합니다. 열람은 발송 당일, 재방문은 발송 다음 날부터 7일간 한 번 이상 다시 연 사람을 집계하며 관찰 기간은 모두 끝났습니다. 전체 행 안에 활성 및 미접속 집단이 포함되므로 행들을 더하지 않습니다.

미접속 집단의 수신거부율은 활성 집단의 8.5배입니다. 하지만 두 집단은 원래 활동 상태가 다르므로 발송의 효과를 비교한 무작위 실험은 아닙니다. 나머지 30,000명의 결과도 전체 행에 포함돼 있습니다. 재방문은 전체 2,000명 중 활성 집단 1,660명, 미접속 집단 150명과 나머지 집단 190명입니다.

푸시의 추가 효과를 보려면 발송 가능한 비슷한 대상 안에서 발송 집단과 보류 집단을 무작위로 나눠 같은 기간의 목표 행동과 거부 등을 비교하는 방법을 검토합니다. 거부자가 늘면 내용과 빈도, 대상이 적절했는지 확인하며 이후 모든 채널로 연락할 수 없다고 일괄 해석하지 않습니다.

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

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

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

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

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

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

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

네 명의 가상 발송표 검토하기

할인 광고를 오후 8시에 보내려는 가상 설계입니다. 모든 사람은 한국에 있고 표의 시간은 한국 시각이며 법상 예외는 적용하지 않는다고 가정합니다. 실제 발송은 하지 않고 메모장에 적습니다.

표의 조건만 보면 오후 8시 후보는 A와 D입니다. B는 광고 동의가 없고 C는 일반 푸시 표시 권한이 없습니다. 후보라고 곧바로 보내지 말고 광고 표기, 거부 연결과 최신 철회 여부 및 중복 목록도 확인합니다.

이번에는 발송 시각을 오후 10시로 바꿉니다. 후보는 D만 남습니다. D가 발송 직전에 광고 동의를 철회했다면 0명입니다. 예약 시점에 동의했어도 그대로 보내지 않습니다.

시간별 후보와 제외 이유를 남기면 첫 검토를 마친 것입니다. 실제 검증에서는 테스트 기기로 표시 내용, 목적지와 로그인 없는 거부 경로 및 철회 반영을 확인합니다. 운영 권한과 동의가 확인되지 않은 실제 고객에게 시험 발송하지 않습니다.

📋 3줄 요약

1. 운영체제 알림 권한과 광고 수신동의 및 야간 동의를 나누고 발송 직전의 철회 상태까지 확인합니다.

2. 광고 표기와 전송자 정보, 쉬운 무료 수신거부 및 정기 확인 안내를 실제 채널 조건에 맞게 준비합니다.

3. 발송 요청과 도달 및 열람을 구분하고 재방문과 수신거부를 같은 기간과 집계 기준으로 비교합니다.

참고 자료

• 정보통신망법 제50조, 국가법령정보센터
• 2026년 제7차 개정 불법스팸 안내서, KISA
• 2년마다 수신동의 여부 확인 안내, KISA
• Android 알림 권한과 조건