요구사항에 문자는 건당 과금이라고 적었습니다. 이 한 줄이 설계를 바꿉니다. 푸시와 메일은 보내는 양이 늘어도 비용이 거의 늘지 않지만, 문자는 한 건마다 돈이 나갑니다.
숫자를 먼저 본다
하루 5천만 건 중 문자가 1퍼센트라고 해 봅시다.
5천만 x 0.01 = 50만 건
50만 x 20원 = 1천만원
하루 1천만원, 한 달 3억
전체의 1퍼센트인데 서버 비용보다 큽니다. 그래서 채널 선택은 기능이 아니라 예산 결정입니다. 어떤 알림을 문자로 보낼지 정하는 것이 이 시스템에서 가장 비싼 결정입니다.
이 계산이 알려주는 것이 하나 더 있습니다. 문자 발송량은 예상보다 쉽게 늘어납니다. 서비스마다 "이건 중요하니까 문자로" 라고 판단하면 1퍼센트가 5퍼센트가 되고, 한 달 15억이 됩니다. 개별 서비스는 자기 몫만 보므로 이 증가를 알아채지 못합니다.
값싼 것부터 시도한다
한 알림을 여러 채널로 동시에 보내는 대신, 값싼 채널부터 시도하고 확인되지 않으면 올립니다.
| 순서 | 채널 | 성질 |
|---|---|---|
| 1 | 푸시 | 비용이 거의 없다. 앱을 지웠으면 못 받는다 |
| 2 | 메일 | 비용이 거의 없다. 늦게 본다 |
| 3 | 문자 | 건당 과금. 가장 확실하다 |
동시에 보내면 사용자는 같은 내용을 세 번 받고 우리는 문자 값을 늘 냅니다. 순서대로 올리면 대부분은 첫 단계에서 끝납니다.
올리는 규칙은 알림 종류마다 다릅니다.
| 알림 | 상향 |
|---|---|
| 인증 번호 | 처음부터 문자. 기다릴 시간이 없다 |
| 결제 실패 | 푸시로 시작해 몇 시간 뒤 문자 |
| 마케팅 | 상향하지 않는다 |
마케팅을 상향하지 않는 것이 중요합니다. 상향은 "사용자가 반드시 알아야 한다" 는 뜻인데, 마케팅에는 그 근거가 없습니다. 그런데 상향을 공통 기능으로 만들어 두면 모든 알림이 그것을 쓰려 합니다.
상향은 확인 신호에 달려 있다
값싼 채널이 실패했는지 어떻게 아나가 문제입니다. 앞 절에서 봤듯 도달 여부를 확실히 알 수 없습니다.
푸시가 수락됐지만 사용자가 봤는지는 모른다
그래서 상향 조건을 도달이 아니라 우리가 확실히 아는 것으로 잡습니다.
| 조건 | 알 수 있나 |
|---|---|
| 제공자가 토큰 무효라고 답함 | 확실하다. 즉시 올린다 |
| 정해진 시간 안에 앱에서 확인 안 됨 | 확실하다. 시간이 지나면 올린다 |
| 사용자가 알림을 봤는지 | 알 수 없다. 조건으로 쓰지 않는다 |
즉 상향은 시간과 명확한 실패 신호로만 결정합니다.
하지 않기로 한 것
비용과 범위를 지키기 위해 이번 설계에서 빼는 것들입니다.
| 뺀 것 | 이유 |
|---|---|
| 채널 자동 선택 학습 | 데이터가 쌓인 뒤의 일이다. 지금은 규칙으로 정한다 |
| 정확한 도달 보장 | 제공자 뒤는 통제 밖이다. 보장할 수 없는 것을 약속하지 않는다 |
| 알림 내역 조회 화면 | 발송 플랫폼의 일이 아니다. 필요하면 별도 서비스로 |
보장할 수 없는 것을 요구사항에 넣지 않는 것이 이 절의 결론입니다. "모든 알림이 반드시 도착한다" 는 지킬 수 없고, 지키려 하면 재시도와 문자 상향이 늘어 비용만 커집니다. 대신 1분 안에 발송을 시도한다고 약속합니다. 그것은 우리가 통제할 수 있습니다.