예약 확정은 카카오 알림톡으로 보내고, 새 채팅은 앱 푸시로 보내면 될까요? 출발점으로는 괜찮습니다. 하지만 실제 서비스에서는 앱을 설치하지 않은 고객, 알림을 끈 사용자, 취소된 예약, 같은 이벤트의 재전송까지 함께 다뤄야 합니다.
카카오 알림톡 연동과 앱 푸시 개발의 핵심은 무엇을 보낼지보다 누구에게, 언제, 어떤 조건에서 보낼지 정하는 일입니다. 채널 두 개를 연결해도 발송 기준이 없으면 같은 안내가 반복되거나 중요한 변경을 놓칠 수 있습니다.
알림톡은 거래·이용 안내의 후보로, 앱 푸시는 앱 안의 활동을 이어주는 후보로 검토합니다.
다만 중요하다는 이유만으로 알림톡을 쓰거나, 푸시가 저렴하다는 이유로 모든 안내를 푸시로 바꾸지는 않습니다. 정보성·광고성 구분, 수신 가능 조건, 메시지의 유효시간과 실패 대응을 함께 정해야 합니다.
이 글은 예약·결제·커뮤니티 서비스의 알림 정책을 설계하는 방법을 설명합니다. 아래 채널 배치와 코드 형태의 정책은 설명을 위한 가상 설계 예시이며, 특정 고객사의 실제 발송 성과나 카카오 승인 템플릿을 의미하지 않습니다.
알림톡과 앱 푸시는 도착하는 곳부터 다릅니다
카카오 알림톡은 내 서비스 앱이 없어도 받을 수 있습니다
알림톡은 카카오톡으로 전달되는 정보성 메시지입니다. 내 서비스의 앱 설치나 카카오톡 채널 친구 추가가 필수 조건은 아닙니다. 대신 적법하게 수집한 전화번호를 사용하고, 메시지가 카카오의 정보성 기준과 템플릿 조건에 맞아야 합니다. 카카오톡 이용 여부와 수신 상태에 따라 발송이 실패할 수도 있습니다. [1]
직접 만든 템플릿은 카카오의 심사를 거쳐 승인된 내용으로 발송합니다. 카카오가 제공하는 공용 템플릿을 조건에 맞게 쓰는 경우에는 별도 등록·심사 없이 사용할 수 있습니다. 따라서 모든 메시지를 자유롭게 보낼 수 있다는 설명도, 모든 템플릿을 반드시 새로 심사받아야 한다는 설명도 피해야 합니다. [2]
앱 푸시는 설치된 앱의 알림 경로를 사용합니다
여기서 앱 푸시는 스마트폰에 표시되는 원격 알림을 뜻합니다. 웹 푸시나 앱 화면 안의 알림함과는 구분합니다. 발송에는 앱의 푸시 연동과 각 앱 설치본을 가리키는 유효한 토큰이 필요하고, 화면에 알림을 표시할 권한도 확인해야 합니다. iOS에서 FCM(Firebase Cloud Messaging)을 사용하더라도 애플의 푸시 전달 서비스인 APNs 설정과 알림 권한 처리가 포함됩니다. [10]
Android 13 이상에서는 일반적인 알림에 POST_NOTIFICATIONS 권한이 필요합니다. 앱을 설치했다는 사실만으로 표시 권한을 얻은 것은 아닙니다. Google도 사용자가 알림의 필요성을 이해하는 상황에서 권한을 요청하도록 안내합니다. [3]
정보성 안내와 광고를 먼저 구분합니다
예약 확정, 결제 결과, 이용 일정 변경처럼 이미 발생한 거래나 서비스 이용에 필요한 안내는 알림톡을 검토할 수 있습니다. 반면 신상품 홍보나 할인으로 재방문을 유도하는 메시지를 같은 정보성 안내로 취급하면 안 됩니다. 제목이 아니라 메시지 전체의 목적과 실제 수신 관계를 기준으로 판단합니다. [1]
기기의 알림 허용과 광고 수신동의는 별개의 판단입니다. Apple은 홍보·직접 마케팅 푸시에 앱 안에서의 명시적 동의와 거부 방법을 요구합니다. OS의 알림 허용 창을 통과했다는 이유만으로 광고 발송 동의까지 얻었다고 처리하지 않습니다. [4]
KISA가 2026년 3월 공지한 안내서 개정 내용도 확인할 필요가 있습니다. 광고 동의를 구하면서 “혜택 알림”처럼 모호한 표현을 쓰거나, 앱 푸시 광고 수신 거부에 복잡한 로그인 절차를 요구하는 문제가 설명돼 있습니다. 일방적으로 지급한 쿠폰의 발급·소멸 안내 역시 광고성 판단에서 주의해야 합니다. [5]
설정 화면에서는 거래·이용 알림, 커뮤니티 알림, 광고성 정보 수신동의를 구분합니다.
구독 해지나 앱 알림 거절을 다른 채널의 광고로 우회하지 않습니다. 광고 표시, 수신 거부, 야간 발송 조건과 개별 문구의 정보성 여부는 적용 법령과 발송사·카카오의 기준을 확인합니다.
예약·결제·채팅별 채널 선택은 이렇게 시작합니다
다음은 알림 정책 초안을 만드는 예시입니다. 한 가지 정답이 아니라 앱 설치율, 이용 방식과 메시지 성격에 따라 조정할 기준으로 보면 됩니다.
웹에서 신청한 예약의 확정·취소 안내
앱을 설치하지 않은 고객도 예약할 수 있다면 알림톡을 우선 후보로 둡니다. 확정 일시, 장소, 예약 조회 방법처럼 다음 행동에 필요한 정보만 담고, 서비스의 예약 상세에도 같은 상태를 남깁니다. 앱이 없는 사람에게 앱 설치부터 요구하는 안내 동선은 피합니다.
결제 완료·환불 결과와 중요한 일정 변경
결제 시스템에서 결과가 확정된 뒤 안내를 생성합니다. 사용자가 결제 완료 화면에 도착했다는 이유만으로 발송하지 않습니다. 평소 알림을 푸시로 제공하는 앱이라도 환불 결과나 당일 취소처럼 영향이 큰 이벤트는 별도의 연락 정책을 정하고, 정보성 조건에 맞는 알림톡이나 다른 채널을 검토합니다.
새 채팅·댓글·내 질문에 달린 답변
앱 안의 특정 화면으로 돌아오는 것이 목적이라면 푸시를 우선 검토합니다. 같은 채팅방을 이미 보고 있는 사용자에게는 외부 알림을 생략하거나, 짧은 시간에 몰린 활동을 묶어 안내할 수 있습니다. 채팅 한 건마다 알림톡까지 동시에 보내는 것을 기본값으로 두지는 않습니다.
학습 시작·예약 시간 리마인드
사용자가 등록한 일정의 안내인지, 새 상품을 권하는 홍보인지부터 나눕니다. 서비스가 제공하는 일정 알림은 사용자가 선택한 채널과 현재 예약 상태를 기준으로 발송합니다. 매일 반복되는 알림이라면 빈도 설정, 일시 중지, 종료된 일정의 발송 중단까지 포함합니다.
쿠폰 홍보·신상품·재방문 유도
광고를 허용하는 채널과 그에 필요한 동의를 갖춘 뒤 별도로 설계합니다. 알림톡을 광고성 푸시의 대체 경로로 지정하지 않습니다. 발송 대상이 광고를 거절했거나 동의 상태를 확인할 수 없다면 캠페인 대상에서 제외하는 정책이 필요합니다.
발송 성공과 고객 확인을 같은 상태로 저장하지 않습니다
서버가 푸시 API를 호출하고 메시지 ID를 받았다고 사용자의 기기에 알림이 도착한 것은 아닙니다. FCM은 메시지 ID 반환을 전달 요청의 수락으로 설명하며, 실제 전달은 기기 연결과 처리 조건에 영향을 받습니다. [6]
운영 화면에는 최소한 발송 예정, 제공사 접수, 제공사 결과, 링크 열기, 업무 처리 완료를 구분해 보여주는 편이 좋습니다. 제공사 결과가 전달을 뜻하는지도 계약한 API의 정의에 맞게 해석합니다. 예약 확인 버튼을 눌렀는지와 알림 자체가 도착했는지는 다른 기록입니다.
FCM 보고서의 Sends, Received, Impressions, Opens도 서로 다른 지표입니다. 일부는 Android에서만 제공되고, 열기 통계 역시 앱 상태와 분석 연동 조건에 영향을 받습니다. 서로 다른 플랫폼의 지표를 같은 도달률처럼 비교하거나 실시간 개인별 읽음 확인으로 사용하면 안 됩니다. [8]
“몇 분 동안 클릭이 없으면 실패”로 처리하지 않습니다.
사용자는 잠금화면에서 내용을 읽고도 누르지 않을 수 있습니다. 결과가 불명확한 요청은 확인 중으로 남기고, 실패가 확인된 경우와 응답이 늦은 경우를 나눠야 불필요한 대체 발송을 줄일 수 있습니다.
푸시 실패를 알림톡이나 문자로 보완하는 기능은 가능하지만 자동 전환부터 넣지는 않습니다. 전환할 메시지의 목적과 수신 조건, 유효시간, 이미 다른 기기로 전달됐는지를 다시 확인합니다. 푸시 토큰 하나의 오류만으로 해당 고객의 모든 기기가 실패했다고 판단하지 않는 것도 중요합니다.
중복 발송과 취소된 예약의 알림을 막는 설계
발송 작업이 여러 번 실행될 수 있다는 전제로 설계합니다. 예를 들어 예약 저장과 발송할 이벤트 기록을 함께 처리하고, 별도 작업자가 이벤트를 읽어 알림을 보냅니다. 데이터는 저장됐는데 알림 예약은 빠지는 상황을 줄이기 위한 방식입니다.
같은 사건에는 같은 중복 방지 키를 사용합니다
예약 ID, 일정 버전, 알림 종류, 수신자를 조합한 식별자를 만들고 발송 이력에 고유 제약을 둡니다. 작업자가 동시에 같은 메시지를 처리하지 못하게 잠금이나 작업 점유도 필요합니다. 다만 서비스 내부의 중복 방지만으로 외부 제공사까지 정확히 한 번 전달된다고 보장할 수는 없습니다.
발송 직전에 상태와 유효시간을 다시 확인합니다
알림을 예약한 뒤 일정이 바뀌면 기존 작업을 취소하거나 무효화합니다. 발송 직전에도 최신 일정 버전과 취소 여부를 확인합니다. 이미 전달된 알림을 취소할 수 있다고 가정하지 말고, 알림을 열 때 최신 예약 상태를 조회하게 합니다. 기기가 뒤늦게 연결돼 종료된 수업의 시작 안내가 도착하지 않도록, 원격 푸시에는 메시지 유효시간도 설정합니다. FCM은 Android·웹의 TTL과 iOS의 APNs 만료 설정을 안내합니다. [6]
아래 JSON은 카카오나 FCM에 그대로 전송하는 API 요청이 아닙니다. 개발팀과 합의할 내부 알림 정책의 가상 예시입니다. 날짜와 ID도 설명용 값입니다.
{
"event_type": "reservation.start_reminder",
"subject_id": "booking_123",
"subject_version": 3,
"recipient_id": "user_456",
"primary_channel": "alimtalk",
"template_key": "reservation_reminder_v1",
"scheduled_at": "2026-10-12T09:30:00+09:00",
"expires_at": "2026-10-12T10:00:00+09:00",
"inbox_record": true,
"dedupe_key": "booking_123:v3:reminder:user_456",
"fallback": {
"channel": "sms",
"trigger": "confirmed_delivery_failure",
"max_attempts": 1
}
}이 예시의 문자 대체 발송은 실패가 확인됐고 해당 안내의 전송 요건을 충족할 때만 실행합니다. 네트워크 시간 초과로 결과를 모르면 먼저 제공사 결과를 조회하거나 콜백을 기다리는 절차가 필요합니다. 사용자가 예약을 취소했거나 메시지가 만료됐다면 재시도보다 중단이 우선입니다.
앱 푸시는 토큰·권한·딥링크까지 구현해야 합니다
토큰은 계정이 아니라 앱 인스턴스의 주소입니다
FCM 토큰은 재설치나 기기 변경 등으로 달라질 수 있습니다. 서버는 갱신된 토큰을 받아 반영하고 무효 토큰을 정리해야 합니다. 한 사용자가 여러 기기를 쓰는 상황도 고려합니다. 로그아웃이나 다른 계정으로 전환한 뒤 이전 사용자의 알림이 계속 가는지 검수하는 것이 좋습니다. [7][10]
허용 요청은 알림의 가치를 설명할 수 있을 때 합니다
앱 첫 실행에서 무조건 권한 창부터 띄우기보다 예약 완료나 대화 시작처럼 이유가 분명한 순간에 요청합니다. 거절한 사용자에게 반복적으로 같은 요청을 강요하지 않고, 앱 내부에서 예약 내역과 메시지를 확인할 수 있는 대안을 둡니다. [3]
알림을 누른 뒤 원래 목적의 화면으로 이동시킵니다
예약 안내는 예약 상세로, 답변 알림은 해당 질문으로 연결합니다. iOS Universal Links와 Android App Links처럼 웹 주소와 앱을 연결하는 방식을 검토할 수 있습니다. 앱 미설치 시 열릴 웹 화면도 준비하고, 실제 카카오톡 내 브라우저·운영체제·앱 설치 상태에서 동작을 확인합니다. [11][12]
로그인이 필요하면 인증 후 원래 목적지로 복귀하되 서버에서 조회 권한을 다시 검사합니다. 주소를 안다는 사실만으로 타인의 예약이나 결제 내역을 보여주면 안 됩니다. 하이브리드 앱도 앱 셸의 푸시 수신, 웹 화면으로의 이동 정보 전달, 로그인 상태 복구를 하나의 검수 범위로 잡습니다.
메시지에는 민감한 정보와 비밀값을 넣지 않습니다. Apple도 푸시에 민감한 개인정보나 기밀 정보를 보내지 않도록 요구합니다. 알림 본문에는 “새 답변이 등록되었습니다” 정도의 안내를 두고, 상세 내용은 인증된 화면에서 확인하게 하는 방식이 적합합니다. [4]
비용은 발송 건수와 운영비를 함께 계산합니다
카카오 공식 가이드도 딜러사에 따라 발송 단가와 서비스 제공 범위 등 계약 조건이 다를 수 있다고 안내합니다. 알림톡 연동 견적을 볼 때는 메시지 유형, 청구 기준, 문자 대체 발송, 기본료와 부가세를 분리해 확인해야 합니다. [13]
Firebase는 FCM 자체를 No-cost 서비스로 안내합니다. 그렇다고 푸시 기능의 개발·운영비까지 0원이라는 뜻은 아닙니다. 예약 작업을 실행하는 서버, 발송 이력 저장, 분석 도구, 외부 메시징 플랫폼 비용은 별도로 확인해야 합니다. [9]
월 알림 운영비는 이렇게 나눠 봅니다.
알림톡 청구 대상 건수 × 계약 단가 + 대체 문자 청구 대상 건수 × 문자 단가 + 서버·저장·운영 도구 비용
재시도나 실패 건의 청구 여부는 제공사 기준을 확인합니다. 기기별 중복 푸시와 필요 없는 리마인드를 줄이는 일도 비용 관리에 포함됩니다.
알림의 효과는 열기율만으로 판단하지 않습니다. 예약 상세 확인, 미결제 처리, 질문 답변 확인처럼 실제 목적을 달성했는지를 함께 봅니다. 메시지를 적게 보내면서 같은 결과를 얻는 정책을 비교하는 편이 단순 발송량 확대보다 유용합니다.
개발을 맡길 때는 발송 버튼보다 운영 기준을 명세합니다
요구사항에 “카카오 알림톡·푸시 연동”만 적으면 정상 발송 한 번으로 완료 여부를 판단하기 쉽습니다. 발송할 사건, 대상, 시점, 채널, 템플릿, 이동할 화면, 중단 조건과 실패 대응을 함께 적어야 합니다.
발송 기록과 권한
관리자는 사건 ID, 발송 채널, 템플릿 버전, 제공사 메시지 ID, 접수·결과 시각, 오류 코드와 재시도 이력을 확인할 수 있어야 합니다. 개인정보와 토큰 원문은 필요한 범위로 제한하고, 수동 재발송도 중복 방지와 감사 기록을 거치게 합니다.
예약 변경·중복 실행·늦은 응답
동일 이벤트가 두 번 들어오는 상황, 발송 직전 예약을 취소한 상황, 제공사 콜백이 늦거나 중복되는 상황을 시험합니다. 취소된 일정의 안내가 중단되고, 결과 미확정 상태가 성공이나 실패로 임의 변경되지 않는지 확인합니다.
앱 미설치·알림 거절·계정 전환
앱이 없는 고객도 예약 내역을 볼 수 있는지, 푸시를 거절해도 핵심 기능을 사용할 수 있는지, 로그아웃 뒤 다른 사용자의 알림이 노출되지 않는지 확인합니다. iOS·Android와 앱 실행·백그라운드·종료 상태를 나눠 테스트합니다.
광고 철회·메시지 만료·재발송
예약 발송 후 광고 동의를 철회한 사용자에게 캠페인이 나가지 않는지, 만료된 안내가 재전송되지 않는지, 재발송 권한이 제한돼 있는지 확인합니다. 이 기준이 정해져 있어야 출시 후 알림 누락과 중복에 대한 문의를 추적할 수 있습니다.
카카오 알림톡과 앱 푸시 FAQ
Q. 앱이 없어도 카카오 알림톡을 받을 수 있나요?
내 서비스 앱이 없어도 가능합니다. 카카오톡 이용과 수신 조건, 적법하게 수집한 전화번호, 정보성 메시지·템플릿 기준을 충족해야 합니다. 카카오톡 채널 친구 추가 자체는 필수 조건이 아닙니다. [1]
Q. 푸시 알림을 허용하면 광고도 보내도 되나요?
기기 알림 권한을 광고 수신동의로 취급하면 안 됩니다. Apple은 홍보성 푸시에 명시적 동의와 거부 방법을 요구하며, 국내 광고 발송 기준과 수신 거부 처리도 별도로 확인해야 합니다. [4][5]
Q. 알림톡과 푸시를 동시에 보내는 것이 더 안전한가요?
항상 그렇지는 않습니다. 중요 이벤트에는 복수 채널이 필요할 수 있지만, 기본 채널과 추가 발송 조건을 먼저 정해야 합니다. 다른 기기에서 이미 확인한 활동이나 취소된 일정까지 중복 발송하지 않도록 관리합니다.
Q. 푸시를 클릭하지 않으면 알림톡으로 다시 보내면 되나요?
클릭이 없다는 사실만으로 전달 실패를 판단할 수는 없습니다. 전송 상태, 메시지 유효시간, 다른 기기나 서비스 화면에서의 확인 여부를 함께 보고 사전에 정한 정책으로 처리합니다. 광고성 푸시를 정보성 알림톡으로 바꿔 보내는 방식은 기본 대안이 아닙니다.
Q. 알림톡 템플릿은 모두 새로 심사받아야 하나요?
직접 만든 템플릿은 승인 절차가 필요하지만, 카카오가 제공하는 공용 템플릿은 정해진 변수·유형 조건에 맞게 사용하면 별도 등록·심사 없이 이용할 수 있습니다. 실제 제공 범위와 적용 조건은 발송사에서 확인합니다. [2]
Q. 어떤 채널부터 개발하는 것이 좋을까요?
웹에서 예약·결제를 받는 서비스라면 앱 설치 없이 이어지는 안내 경로부터 검토합니다. 반복적인 앱 활동이 핵심이라면 푸시와 알림함을 우선 검토할 수 있습니다. 어느 쪽이든 첫 단계부터 발송 취소, 중복 방지, 결과 확인과 수신 설정을 포함하는 것이 좋습니다.
