Blog·인사이트

알림 시스템 설계, 이메일·푸시·문자를 어떻게 나눌까

··7분 읽기
요약

푸시 알림 때문에 앱을 삭제한 사용자가 78%입니다. 모든 알림이 같은 가치는 아닙니다. 결제 완료는 즉시·조용히, 마케팅은 빈도 제한, 긴급 공지는 다중 채널 — 채널별 특성에 따른 배분 전략이 필요합니다.

알림은 잘 설계하면 사용자 참여를 높이는 강력한 도구이지만, 잘못 설계하면 앱 삭제의 직접적인 원인이 됩니다. Accengage의 조사에 따르면 푸시 알림 때문에 앱을 삭제한 경험이 있는 사용자가 78%에 달합니다.

모든 알림이 동일한 가치를 가지는 것은 아닙니다. 결제 완료 알림과 마케팅 알림을 같은 채널로 보내는 것은 사용자 경험을 심각하게 해칩니다. 이메일, 푸시, 문자 각 채널의 특성을 이해하고 상황에 맞게 배분하는 전략이 필요합니다.

알림의 종류부터 분류해야 한다

채널을 고르기 전에 보내려는 알림의 성격부터 나눠야 합니다. 같은 "알림" 이라도 종류에 따라 적합한 채널, 동의 방식, 발송 시점이 모두 다릅니다.

트랜잭션 알림 은 결제 완료, 주문 상태 변경, 비밀번호 재설정처럼 사용자 행동에 직접 연결된 알림입니다. 사용자가 기다리고 있는 정보라 별도 광고 동의 없이도 발송이 가능하고, 즉시성이 가장 중요합니다.

리마인더·운영 알림 은 예약 임박, 미완료 작업, 점검 공지처럼 사용자가 사전에 설정해 두었거나 서비스 운영상 알려야 하는 정보입니다. 야간 시간대를 피하는 정책은 필요하지만 동의 자체는 트랜잭션과 비슷하게 다룰 수 있습니다.

마케팅 알림 은 프로모션·추천·재참여 유도 같은 비즈니스 목적의 알림입니다. 한국 정보통신망법상 사전 동의가 필수이고, 발송 빈도와 시간대 제한이 정책 차원에서 함께 들어가야 합니다.

보안 알림 은 새 기기 로그인, 이상 거래 감지처럼 도달이 가장 중요한 알림입니다. 사실상 SMS 가 디폴트이며 다른 채널은 보조로만 사용됩니다.

채널별 특성 분석

이메일은 비동기적이고 상세한 내용을 전달하기에 적합합니다. 주문 확인서, 월간 리포트, 뉴스레터 등 긴 내용을 담을 수 있으며 마케팅 커뮤니케이션에도 적절합니다. 비용 측면에서는 매니지드 서비스(AWS SES·SendGrid·Naver Cloud Email·Resend·Mailgun 등) 대부분이 일~월 단위 무료 발송 한도를 기본 제공하기 때문에 일반적인 서비스 규모에서는 사실상 무료로 운영되고, 무료 한도를 넘기는 대규모 발송에서도 건당 0.1원 미만이라 비용 부담이 거의 없는 채널입니다. 다만 평균 오픈율이 20-25% 수준이므로 긴급한 정보 전달에는 부적합합니다.

푸시 알림은 즉각적인 전달이 가능하고 짧은 메시지에 효과적입니다. 모바일에서는 잠금 화면에 바로 표시되므로 즉시성이 높습니다. 하지만 사용자가 쉽게 차단할 수 있어 알림 허용률 관리가 중요합니다. iOS에서는 앱 설치 후 첫 알림 허용 요청 수락률이 약 50%인데, 한 번 거부하면 설정에서 직접 켜야 하므로 첫 요청의 타이밍이 매우 중요합니다.

SMS는 가장 높은 도달률을 자랑합니다. 오픈율이 98%에 달하며 대부분 3분 이내에 읽힙니다. 다만 건당 비용이 푸시·이메일보다 명확히 높습니다 — 가장 저렴한 축인 Naver Cloud SENS 기준으로 단문(SMS) 약 9원, 장문(LMS) 약 25원, 이미지 포함(MMS) 약 86원 수준이고, NHN Cloud Toast·통신사 직접 게이트웨이로 가면 이보다 더 비싼 구간도 흔합니다. 카카오톡 알림톡·친구톡으로 대체 가능한 알림이라면 비슷하거나 더 저렴한 단가로 처리할 수 있어, SMS 는 정말 SMS 가 아니면 안 되는 알림(보안 인증·중요 거래 알림 등)에 한정해서 쓰는 것이 좋습니다.

규모가 커지면 비용과 트래픽이 같이 결정한다

회원이 1만 명을 넘기는 시점부터 채널 선택은 도달률이나 정확성만의 문제가 아니라 비용 문제로 넘어갑니다. 회원 1만 명에게 LMS 한 통씩 보내면 25만 원, MMS 라면 86만 원이 한 번에 나갑니다. 주 1회 마케팅 메시지를 돌리면 LMS 기준 월 100만 원, 회원이 10만 명으로 늘어나면 같은 정책에 월 1,000만 원이 듭니다. 가장 저렴한 Naver Cloud SENS 기준이고 다른 게이트웨이는 더 비쌉니다.

이 지점부터 채널 다변화는 비즈니스 의사결정이 됩니다. 한국에서 가장 많이 쓰이는 인앱 메시징·고객 지원 플랫폼인 채널톡(channel.io)은 인앱 채팅·이메일·CRM 자동화를 한 곳에서 묶어 운영비를 줄이는 데 자주 동원되고, 카카오톡 알림톡은 동의된 사용자 대상으로 단문 SMS 와 비슷하거나 더 저렴한 단가에 동작합니다.

가장 효과적인 비용 절감 수단은 자체 앱과 푸시 채널을 확보하는 것입니다. 한 번 앱을 설치하게 만들면 푸시 발송은 FCM·APNs 인프라를 통해 사실상 무료입니다. 한국에서 마케팅·리텐션이 중요한 서비스 다수가 앱을 따로 만드는 큰 이유 중 하나가 이 비용 구조이고, 1만~10만 회원 규모에서는 SMS·LMS 운영비 몇 달치만으로 앱 개발 비용이 회수되는 경우가 많습니다.

한 가지 더 짚어야 할 것은, 수만~수십만 명에게 알림을 동시에 발송하면 그 자체가 트래픽 스파이크를 만든다는 점입니다. 알림을 받은 사용자들이 짧은 시간 안에 동시에 앱·웹에 접속하기 때문에 평소 대비 수 배에서 수십 배의 동시 접속이 몰립니다. 알림 발송 일정에 맞춰 서버 스케일링을 미리 준비해 두지 않으면, 메시지 비용은 다 썼는데 정작 클릭한 사용자들이 느린 응답이나 에러를 만나는 상황이 그대로 발생합니다.

상황별 채널 선택 가이드

주문 확인은 이메일과 푸시를 함께 사용합니다. 이메일에는 상세 주문 내역과 영수증을 포함하고 푸시로는 간략한 확인 메시지를 보냅니다. 보안 관련 알림은 반드시 SMS를 사용합니다. 비밀번호 변경, 새 기기 로그인, 이상 거래 감지 같은 보안 이벤트는 가장 확실한 도달을 보장해야 합니다.

마케팅 메시지는 이메일이 적절하며, 수신 동의를 받은 사용자에게만 발송해야 합니다. 한국의 정보통신망법에 따라 광고성 메시지는 사전 동의가 필수이며 위반 시 과태료가 부과됩니다. 실시간 상태 업데이트는 푸시 알림이 가장 효과적입니다.

배송 상태 변경, 예약 확정, 댓글 알림 같은 정보가 여기에 해당합니다.

사용자 알림 선호 설정

사용자에게 채널별 알림 수신 여부를 선택할 수 있는 설정 화면을 제공해야 합니다. 알림 유형별로도 세분화하면 더 좋습니다. 주문 관련 알림은 받되 마케팅 알림은 이메일만 받겠다는 식의 설정이 가능해야 합니다.

최근 토스 같은 앱은 이 세분화를 한 단계 더 끌고 갑니다. 마케팅 동의 안에서도 신규 이벤트·추천·재참여·친구 활동·자산 변동·신용 점수 변경처럼 카테고리를 잘게 나누고, 카테고리마다 푸시·이메일·SMS 채널 토글을 따로 둡니다. 사용자는 자신이 받고 싶은 종류만 받을 수 있고, 운영 측면에서는 카테고리별 옵트아웃률을 측정할 수 있어 어떤 알림이 가치 있고 어떤 알림이 피로를 만드는지 데이터로 보입니다.

이렇게 권한을 잘게 분리해 두면 한국 정보통신망법 측면에서도 유리합니다. 광고성 메시지 동의를 "전체 마케팅 알림에 동의" 한 번이 아니라 "이 이벤트 알림에 동의" 단위로 받기 때문에, 한 카테고리에서 거부됐다고 다른 카테고리까지 동시에 닫히지 않고, 분쟁이 생겨도 동의 근거를 카테고리별로 제시할 수 있습니다.

이 선호 데이터는 사용자·카테고리·채널 조합으로 데이터베이스에 저장하고, 알림 발송 시점에 매번 조회해 반영하는 공통 계층을 두는 것이 안전합니다. 야간 시간대에는 긴급하지 않은 알림을 자동으로 보류하는 방해 금지 기능까지 함께 제공하면 사용자 만족도와 옵트아웃률이 함께 좋아집니다.

기술적 구현 아키텍처

알림 발송은 반드시 비동기로 처리해야 합니다. 백엔드 스택에 맞는 메시지 큐(Python 진영의 Celery + RabbitMQ, Node.js의 BullMQ, JVM 진영의 Kafka, AWS SQS 등)를 구성하면 메인 API 서버의 응답 시간에 영향을 주지 않으면서 안정적으로 알림을 발송할 수 있습니다.

알림 발송 요청을 큐에 넣고 워커가 비동기로 처리하는 구조입니다. 발송 실패 시 자동 재시도 로직을 포함해야 하며 최대 3회 재시도 후에도 실패하면 별도의 실패 큐에 기록하여 수동 확인이 가능하도록 합니다. 발송 성공률과 오픈율을 추적하는 로깅 시스템도 필요합니다.

클라우드 환경에서 컨테이너로 큐 워커를 분리 운영하면 알림 처리량이 급증할 때 워커만 독립적으로 스케일링할 수 있습니다.

프로덕트 메이커의 알림 시스템

프로덕트 메이커는 SMS·이메일·푸시 채널을 클라이언트 환경과 비용 조건에 맞춰 선택합니다. 국내 통신사 게이트웨이부터 글로벌 매니지드 서비스(Firebase Cloud Messaging, NHN Cloud Toast, AWS SNS, OneSignal 등)까지 다양한 옵션을 활용해 왔습니다. 사용자별 선호 설정은 백엔드 데이터 모델로 관리하며, 알림 발송 전에 반드시 사용자 설정을 확인하는 공통 계층을 거치도록 구성합니다.

비긴급 알림은 배치로 묶어 발송하여 사용자를 지나치게 방해하지 않도록 합니다. 정기적인 데이터 리뷰로 채널별 성과를 추적하고, 비즈니스 임팩트를 기준으로 알림 정책을 지속적으로 다듬습니다.

알림은 기술이 아니라 사용자와의 소통 전략입니다.

다른 포스팅
Blog·인사이트

알림 시스템 설계, 이메일·푸시·문자를 어떻게 나눌까

··7분 읽기

알림은 잘 설계하면 사용자 참여를 높이는 강력한 도구이지만, 잘못 설계하면 앱 삭제의 직접적인 원인이 됩니다. Accengage의 조사에 따르면 푸시 알림 때문에 앱을 삭제한 경험이 있는 사용자가 78%에 달합니다.

모든 알림이 동일한 가치를 가지는 것은 아닙니다. 결제 완료 알림과 마케팅 알림을 같은 채널로 보내는 것은 사용자 경험을 심각하게 해칩니다. 이메일, 푸시, 문자 각 채널의 특성을 이해하고 상황에 맞게 배분하는 전략이 필요합니다.

알림의 종류부터 분류해야 한다

채널을 고르기 전에 보내려는 알림의 성격부터 나눠야 합니다. 같은 "알림" 이라도 종류에 따라 적합한 채널, 동의 방식, 발송 시점이 모두 다릅니다.

트랜잭션 알림 은 결제 완료, 주문 상태 변경, 비밀번호 재설정처럼 사용자 행동에 직접 연결된 알림입니다. 사용자가 기다리고 있는 정보라 별도 광고 동의 없이도 발송이 가능하고, 즉시성이 가장 중요합니다.

리마인더·운영 알림 은 예약 임박, 미완료 작업, 점검 공지처럼 사용자가 사전에 설정해 두었거나 서비스 운영상 알려야 하는 정보입니다. 야간 시간대를 피하는 정책은 필요하지만 동의 자체는 트랜잭션과 비슷하게 다룰 수 있습니다.

마케팅 알림 은 프로모션·추천·재참여 유도 같은 비즈니스 목적의 알림입니다. 한국 정보통신망법상 사전 동의가 필수이고, 발송 빈도와 시간대 제한이 정책 차원에서 함께 들어가야 합니다.

보안 알림 은 새 기기 로그인, 이상 거래 감지처럼 도달이 가장 중요한 알림입니다. 사실상 SMS 가 디폴트이며 다른 채널은 보조로만 사용됩니다.

채널별 특성 분석

이메일은 비동기적이고 상세한 내용을 전달하기에 적합합니다. 주문 확인서, 월간 리포트, 뉴스레터 등 긴 내용을 담을 수 있으며 마케팅 커뮤니케이션에도 적절합니다. 비용 측면에서는 매니지드 서비스(AWS SES·SendGrid·Naver Cloud Email·Resend·Mailgun 등) 대부분이 일~월 단위 무료 발송 한도를 기본 제공하기 때문에 일반적인 서비스 규모에서는 사실상 무료로 운영되고, 무료 한도를 넘기는 대규모 발송에서도 건당 0.1원 미만이라 비용 부담이 거의 없는 채널입니다. 다만 평균 오픈율이 20-25% 수준이므로 긴급한 정보 전달에는 부적합합니다.

푸시 알림은 즉각적인 전달이 가능하고 짧은 메시지에 효과적입니다. 모바일에서는 잠금 화면에 바로 표시되므로 즉시성이 높습니다. 하지만 사용자가 쉽게 차단할 수 있어 알림 허용률 관리가 중요합니다. iOS에서는 앱 설치 후 첫 알림 허용 요청 수락률이 약 50%인데, 한 번 거부하면 설정에서 직접 켜야 하므로 첫 요청의 타이밍이 매우 중요합니다.

SMS는 가장 높은 도달률을 자랑합니다. 오픈율이 98%에 달하며 대부분 3분 이내에 읽힙니다. 다만 건당 비용이 푸시·이메일보다 명확히 높습니다 — 가장 저렴한 축인 Naver Cloud SENS 기준으로 단문(SMS) 약 9원, 장문(LMS) 약 25원, 이미지 포함(MMS) 약 86원 수준이고, NHN Cloud Toast·통신사 직접 게이트웨이로 가면 이보다 더 비싼 구간도 흔합니다. 카카오톡 알림톡·친구톡으로 대체 가능한 알림이라면 비슷하거나 더 저렴한 단가로 처리할 수 있어, SMS 는 정말 SMS 가 아니면 안 되는 알림(보안 인증·중요 거래 알림 등)에 한정해서 쓰는 것이 좋습니다.

규모가 커지면 비용과 트래픽이 같이 결정한다

회원이 1만 명을 넘기는 시점부터 채널 선택은 도달률이나 정확성만의 문제가 아니라 비용 문제로 넘어갑니다. 회원 1만 명에게 LMS 한 통씩 보내면 25만 원, MMS 라면 86만 원이 한 번에 나갑니다. 주 1회 마케팅 메시지를 돌리면 LMS 기준 월 100만 원, 회원이 10만 명으로 늘어나면 같은 정책에 월 1,000만 원이 듭니다. 가장 저렴한 Naver Cloud SENS 기준이고 다른 게이트웨이는 더 비쌉니다.

이 지점부터 채널 다변화는 비즈니스 의사결정이 됩니다. 한국에서 가장 많이 쓰이는 인앱 메시징·고객 지원 플랫폼인 채널톡(channel.io)은 인앱 채팅·이메일·CRM 자동화를 한 곳에서 묶어 운영비를 줄이는 데 자주 동원되고, 카카오톡 알림톡은 동의된 사용자 대상으로 단문 SMS 와 비슷하거나 더 저렴한 단가에 동작합니다.

가장 효과적인 비용 절감 수단은 자체 앱과 푸시 채널을 확보하는 것입니다. 한 번 앱을 설치하게 만들면 푸시 발송은 FCM·APNs 인프라를 통해 사실상 무료입니다. 한국에서 마케팅·리텐션이 중요한 서비스 다수가 앱을 따로 만드는 큰 이유 중 하나가 이 비용 구조이고, 1만~10만 회원 규모에서는 SMS·LMS 운영비 몇 달치만으로 앱 개발 비용이 회수되는 경우가 많습니다.

한 가지 더 짚어야 할 것은, 수만~수십만 명에게 알림을 동시에 발송하면 그 자체가 트래픽 스파이크를 만든다는 점입니다. 알림을 받은 사용자들이 짧은 시간 안에 동시에 앱·웹에 접속하기 때문에 평소 대비 수 배에서 수십 배의 동시 접속이 몰립니다. 알림 발송 일정에 맞춰 서버 스케일링을 미리 준비해 두지 않으면, 메시지 비용은 다 썼는데 정작 클릭한 사용자들이 느린 응답이나 에러를 만나는 상황이 그대로 발생합니다.

상황별 채널 선택 가이드

주문 확인은 이메일과 푸시를 함께 사용합니다. 이메일에는 상세 주문 내역과 영수증을 포함하고 푸시로는 간략한 확인 메시지를 보냅니다. 보안 관련 알림은 반드시 SMS를 사용합니다. 비밀번호 변경, 새 기기 로그인, 이상 거래 감지 같은 보안 이벤트는 가장 확실한 도달을 보장해야 합니다.

마케팅 메시지는 이메일이 적절하며, 수신 동의를 받은 사용자에게만 발송해야 합니다. 한국의 정보통신망법에 따라 광고성 메시지는 사전 동의가 필수이며 위반 시 과태료가 부과됩니다. 실시간 상태 업데이트는 푸시 알림이 가장 효과적입니다.

배송 상태 변경, 예약 확정, 댓글 알림 같은 정보가 여기에 해당합니다.

사용자 알림 선호 설정

사용자에게 채널별 알림 수신 여부를 선택할 수 있는 설정 화면을 제공해야 합니다. 알림 유형별로도 세분화하면 더 좋습니다. 주문 관련 알림은 받되 마케팅 알림은 이메일만 받겠다는 식의 설정이 가능해야 합니다.

최근 토스 같은 앱은 이 세분화를 한 단계 더 끌고 갑니다. 마케팅 동의 안에서도 신규 이벤트·추천·재참여·친구 활동·자산 변동·신용 점수 변경처럼 카테고리를 잘게 나누고, 카테고리마다 푸시·이메일·SMS 채널 토글을 따로 둡니다. 사용자는 자신이 받고 싶은 종류만 받을 수 있고, 운영 측면에서는 카테고리별 옵트아웃률을 측정할 수 있어 어떤 알림이 가치 있고 어떤 알림이 피로를 만드는지 데이터로 보입니다.

이렇게 권한을 잘게 분리해 두면 한국 정보통신망법 측면에서도 유리합니다. 광고성 메시지 동의를 "전체 마케팅 알림에 동의" 한 번이 아니라 "이 이벤트 알림에 동의" 단위로 받기 때문에, 한 카테고리에서 거부됐다고 다른 카테고리까지 동시에 닫히지 않고, 분쟁이 생겨도 동의 근거를 카테고리별로 제시할 수 있습니다.

이 선호 데이터는 사용자·카테고리·채널 조합으로 데이터베이스에 저장하고, 알림 발송 시점에 매번 조회해 반영하는 공통 계층을 두는 것이 안전합니다. 야간 시간대에는 긴급하지 않은 알림을 자동으로 보류하는 방해 금지 기능까지 함께 제공하면 사용자 만족도와 옵트아웃률이 함께 좋아집니다.

기술적 구현 아키텍처

알림 발송은 반드시 비동기로 처리해야 합니다. 백엔드 스택에 맞는 메시지 큐(Python 진영의 Celery + RabbitMQ, Node.js의 BullMQ, JVM 진영의 Kafka, AWS SQS 등)를 구성하면 메인 API 서버의 응답 시간에 영향을 주지 않으면서 안정적으로 알림을 발송할 수 있습니다.

알림 발송 요청을 큐에 넣고 워커가 비동기로 처리하는 구조입니다. 발송 실패 시 자동 재시도 로직을 포함해야 하며 최대 3회 재시도 후에도 실패하면 별도의 실패 큐에 기록하여 수동 확인이 가능하도록 합니다. 발송 성공률과 오픈율을 추적하는 로깅 시스템도 필요합니다.

클라우드 환경에서 컨테이너로 큐 워커를 분리 운영하면 알림 처리량이 급증할 때 워커만 독립적으로 스케일링할 수 있습니다.

프로덕트 메이커의 알림 시스템

프로덕트 메이커는 SMS·이메일·푸시 채널을 클라이언트 환경과 비용 조건에 맞춰 선택합니다. 국내 통신사 게이트웨이부터 글로벌 매니지드 서비스(Firebase Cloud Messaging, NHN Cloud Toast, AWS SNS, OneSignal 등)까지 다양한 옵션을 활용해 왔습니다. 사용자별 선호 설정은 백엔드 데이터 모델로 관리하며, 알림 발송 전에 반드시 사용자 설정을 확인하는 공통 계층을 거치도록 구성합니다.

비긴급 알림은 배치로 묶어 발송하여 사용자를 지나치게 방해하지 않도록 합니다. 정기적인 데이터 리뷰로 채널별 성과를 추적하고, 비즈니스 임팩트를 기준으로 알림 정책을 지속적으로 다듬습니다.

알림은 기술이 아니라 사용자와의 소통 전략입니다.

다른 포스팅
WebGL프로젝트 상담