알림이 비즈니스 로직 곳곳에 흩어진 시스템
"결제했는데 안내 문자가 안 왔어요", "예약 확정 알림을 못 받았습니다." 이런 문의가 반복된다면 발송 대행사보다 먼저 시스템 구조를 의심해야 합니다. 오래 운영된 서비스일수록 알림은 필요할 때마다 덧붙여진 경우가 많습니다.
월 10만 건을 발송하는 서비스라면 실패율이 3%만 되어도 매달 3,000명이 안내를 받지 못합니다. 이 숫자가 보이지 않는다는 점이 가장 큰 문제입니다.
채널 선택과 대체 발송
채널마다 도달 조건과 비용 구조가 다르므로, 메시지 성격에 맞춰 조합해야 합니다.
핵심은 폴백(대체 발송) 입니다. 알림톡이 실패하면 문자로 다시 보내는 구조가 대표적입니다. 이때 알림톡 본문은 최대 1,000자까지 가능하므로, 그대로 문자로 넘기면 LMS 요금이 나오거나 내용이 잘립니다. 폴백용 짧은 문구를 템플릿과 함께 준비해 두어야 합니다.
발송 구조: 큐와 분리
주문 처리 트랜잭션 안에서 발송 API를 직접 호출하면, 대행사 응답이 3초 지연될 때 주문도 3초 늦어집니다. 업무 처리는 '발송 요청'을 큐에 넣는 것으로 끝내고, 별도 워커가 실제 발송을 담당하도록 분리해야 합니다.
템플릿과 수신 관리
템플릿은 코드가 아니라 데이터로 관리해야 합니다. 템플릿 코드, 버전, 채널별 문구, 변수 목록을 저장하고, 발송 이력에는 사용한 버전을 함께 남깁니다. 알림톡은 검수가 끝난 템플릿만 발송할 수 있으므로, 문구 변경 일정에 검수 기간을 반영하고 '검수 중/승인/반려' 상태를 시스템에서 관리합니다.
법적 요건도 발송 모듈이 책임져야 합니다.
도달 확인과 운영
대행사가 돌려주는 결과 리포트(웹훅 또는 조회 API)를 발송 이력에 연결해 저장하는 것이 운영의 출발점입니다. '접수 → 발송 → 도달/실패' 상태와 실패 사유 코드를 남기면, 고객 문의에 몇 초 만에 정확한 답을 할 수 있습니다. 실패 사유별 통계는 개선 방향도 알려 줍니다. 결번이 많으면 회원 정보 정비가, 채널 차단이 많으면 발송 빈도 조정이 필요합니다.
이메일은 발신 도메인 인증이 도달률을 좌우합니다. SPF는 발송 서버를, DKIM은 메일 서명을 검증하고, DMARC는 두 검증이 실패했을 때의 처리 정책을 정합니다. Gmail은 2024년 2월부터 하루 5,000통 이상 보내는 발신자에게 세 가지 인증을 모두 요구하고, 스팸 신고율을 0.3% 미만으로 유지하도록 안내합니다. DMARC는 `p=none`으로 시작해 리포트를 확인한 뒤 단계적으로 강화하는 방식이 안전합니다.
POLYGLOTSOFT가 돕는 방식
알림 시스템 정비는 새로 만드는 일보다 흩어진 것을 한곳으로 모으는 일에 가깝습니다. POLYGLOTSOFT는 구독형 개발 서비스를 통해 기존 시스템의 발송 코드를 조사하고, 큐 기반 통합 발송 모듈, 템플릿 관리 화면, 폴백 규칙, 발송 결과 대시보드를 단계적으로 구축해 드립니다. 월 구독 방식이므로 채널 추가나 정책 변경에도 별도 계약 없이 대응할 수 있습니다. "알림이 안 왔다"는 문의에 근거를 가지고 답하고 싶으시다면, POLYGLOTSOFT에 현재 상황을 알려 주시기 바랍니다.