어렵게 모신 손님이 홈페이지를 잘 보고 나갔습니다. 그런데 다음 주에 신메뉴가 나와도, 이번 달 예약이 몇 자리 남았어도, 그 손님에게 알릴 방법이 없습니다. 이메일은 안 남기고 갔고, 문자를 보내자니 번호가 없고, 앱을 만들자니 개발비가 홈페이지 값의 몇 배입니다.
이 틈을 메우려고 나온 기술이 웹 푸시 알림(Web Push)입니다. 앱을 깔지 않아도, 브라우저를 닫아 놓아도, 손님의 폰과 PC에 알림이 뜹니다. 스마트폰 앱 푸시와 겉모습이 거의 같습니다. 그런데 실무에서 이걸 붙여 본 입장에서 말하면, 기대만큼 만능은 아니고 대신 기대하지 않던 곳에서 효자 노릇을 합니다. 오늘은 그 현실을 정리해 보겠습니다.
웹 푸시가 정확히 무엇인가
손님이 우리 홈페이지에 들어오면 브라우저가 "이 사이트의 알림을 허용하시겠습니까?"라고 묻습니다. 손님이 허용을 누르면, 브라우저가 그 손님만의 주소(구독 토큰)를 하나 만들어 우리 서버에 넘겨 줍니다. 이후에는 우리가 그 주소로 메시지를 쏘면, 손님이 우리 사이트를 켜 두지 않았어도 알림이 뜹니다.
핵심은 세 가지입니다.
- 개인정보를 받지 않습니다. 이메일도 전화번호도 필요 없습니다. 브라우저가 만든 익명 토큰 하나뿐입니다.
- 앱스토어를 거치지 않습니다. 심사도, 개발자 계정 연회비도, 앱 업데이트 배포도 없습니다.
- 발송 비용이 사실상 0원입니다. 문자 한 건에 20~30원, 알림톡에 7~10원이 드는 것과 대비됩니다.
먼저 알아야 할 세 가지 제약
장점만 보고 붙였다가 실망하는 경우가 많아, 제약부터 말씀드립니다.
1. 아이폰은 조건이 하나 더 붙습니다
안드로이드와 PC는 사이트에 들어오기만 하면 알림 허용을 물어볼 수 있습니다. 그런데 아이폰(iOS Safari)은 손님이 우리 사이트를 홈 화면에 추가한 뒤에야 알림을 받을 수 있습니다. "공유 → 홈 화면에 추가"라는 두 단계를 손님이 직접 해야 한다는 뜻입니다. 국내 아이폰 사용자 비중을 생각하면, 실제 구독자의 상당수가 처음부터 빠진 채 시작한다고 봐야 합니다.
2. 한 번 거절당하면 되돌리기가 어렵습니다
손님이 "차단"을 누르면 그 브라우저에서는 다시 물어볼 수 없습니다. 우리가 코드로 재요청해도 브라우저가 창을 띄우지 않습니다. 손님이 직접 브라우저 설정에 들어가 사이트 권한을 바꿔야 하는데, 그렇게까지 하는 사람은 없다고 보면 됩니다. 기회는 사실상 한 번뿐입니다.
3. 구독은 조용히 사라집니다
손님이 브라우저 캐시를 지우거나, 시크릿 모드로 들어왔거나, 폰을 바꾸면 구독은 그냥 없어집니다. 우리에게 "해지했습니다"라는 신호도 오지 않습니다. 이메일 주소는 3년이 지나도 살아 있지만, 웹 푸시 구독은 몇 달 단위로 자연 감소합니다. 이메일 리스트를 대체하는 자산이 아니라, 소모되는 채널이라고 보는 편이 정확합니다.
그럼에도 붙일 만한 곳은 어디인가
제약을 알고 나면 쓸 자리가 오히려 선명해집니다. 웹 푸시가 잘 먹히는 건 "지금 이 순간에만 의미 있는 정보"입니다.
- 재고·자리 알림. 품절된 상품에 "재입고되면 알려주세요", 마감된 클래스에 "자리 나면 알려주세요". 손님이 스스로 원해서 누르는 알림이라 허용률이 압도적으로 높습니다.
- 당일 정보. 빵집의 오늘 나온 빵, 캠핑장의 오늘 잔여 사이트, 식당의 오늘의 메뉴. 문자로 보내기엔 비용이 아깝고 이메일로 보내기엔 너무 늦는 정보입니다.
- 예약 리마인더. 이미 예약한 손님에게 보내는 하루 전 알림. 노쇼를 줄이는 데 문자만큼 효과가 있으면서 비용이 들지 않습니다.
- 한정 프로모션. 오늘 마감되는 할인처럼 유효 시간이 짧은 안내.
반대로 주 1회 소식지, 신규 블로그 글 알림처럼 급하지 않은 정보를 푸시로 보내면 해지가 아니라 차단으로 돌아옵니다. 그리고 차단은 앞서 말했듯 되돌릴 수 없습니다.
허용률을 두 배로 만드는 방법: 물어보기 전에 이유를 말하기
가장 흔한 실수는 손님이 들어오자마자 브라우저 권한 창을 띄우는 것입니다. 무슨 사이트인지도 모르는 상태에서 알림 허용을 요구받으면 반사적으로 차단을 누릅니다. 그리고 그 손님은 영영 되찾을 수 없습니다.
실무에서 쓰는 순서는 이렇습니다.
- 브라우저 창 대신 우리 화면을 먼저 띄웁니다. "재입고되면 바로 알려드릴까요?" 같은, 우리가 직접 디자인한 작은 안내를 먼저 보여 줍니다. 여기서 손님이 "괜찮아요"를 눌러도 브라우저 권한은 소모되지 않습니다. 다음에 다시 물어볼 수 있습니다.
- "네"를 누른 손님에게만 브라우저 권한 창을 띄웁니다. 이미 마음을 정한 사람만 통과시키니 허용률이 크게 올라갑니다.
- 맥락이 있는 순간에 물어봅니다. 첫 화면이 아니라 품절 상품 페이지, 마감된 예약 화면, 주문 완료 직후처럼 알림이 필요한 이유가 화면에 이미 있는 곳에서 물어야 합니다.
알림 하나를 만들 때 지킬 것
- 제목은 30자, 본문은 60자 안쪽으로. 잠금화면에서는 그 뒤가 잘려 보이지 않습니다. 중요한 단어를 앞에 두세요.
- 누르면 도착할 페이지를 정확히 지정합니다. 재입고 알림을 눌렀는데 홈으로 떨어지면 손님은 그 자리에서 이탈합니다.
- 보내는 시간을 지킵니다. 웹 푸시는 광고성 정보 전송 규제의 사각지대처럼 보이지만, 영업 목적의 알림이라면 문자·알림톡과 같은 기준으로 다루는 것이 안전합니다. 밤 9시부터 아침 8시 사이는 피하고, 광고성이면 그 사실을 밝히세요.
- 빈도를 정해 두세요. 주 2회를 넘기기 시작하면 차단이 급격히 늘어납니다.
- 끄는 길을 사이트 안에 둡니다. 브라우저 설정까지 들어가게 하지 말고, 마이페이지나 푸터에 알림 끄기 스위치를 두세요. 차단 대신 해지로 나가는 손님이 나중에 돌아옵니다.
붙이는 비용은 얼마나 드는가
기술적으로는 서비스 워커라는 파일 하나와 발송 서버 로직이 필요합니다. 직접 구현하면 개발 공수가 붙지만, 무료 구간이 넉넉한 푸시 서비스를 연동하는 방식이면 기존 홈페이지에 하루 이틀 작업으로 얹을 수 있는 수준입니다. 앱을 만드는 것과는 비교가 안 됩니다.
다만 붙이는 것보다 운영이 어렵습니다. 무엇을 언제 보낼지 정해 두지 않으면, 붙여 놓고 석 달 동안 한 통도 안 보내다가 결국 잊히는 기능이 됩니다. 도입 전에 "우리가 한 달에 보낼 알림이 무엇인지" 서너 개를 먼저 적어 보시길 권합니다. 그게 안 나오면 아직 필요한 시점이 아닙니다.
정리하면
웹 푸시는 이메일을 대체하지 못하고, 카카오톡 채널을 밀어내지도 못합니다. 아이폰 제약과 자연 감소 때문에 구독자 수도 기대보다 적게 모입니다. 하지만 "지금 알려야 의미 있는 정보"를 비용 없이 즉시 보내는 채널로는 대체재가 마땅치 않습니다. 재입고, 잔여 좌석, 오늘의 메뉴, 예약 리마인더 — 이 네 가지 중 하나라도 해당된다면 붙여 볼 값어치가 충분합니다.
CYAN은 홈페이지를 만들 때 이런 기능을 무조건 다 넣지 않습니다. 업종과 운영 방식을 먼저 보고, 사장님이 실제로 매달 보낼 내용이 있는 채널만 붙입니다. 안 쓸 기능을 넣는 건 비용이 아니라 짐이니까요. 우리 사업에 웹 푸시가 맞을지 판단이 서지 않으신다면, 어떤 알림을 보낼 수 있을지부터 같이 정리해 드리겠습니다.
