요구사항에 수신 거부를 반드시 지킨다고 적었습니다. 이것은 취향 문제가 아니라 지키지 않으면 법을 위반하는 항목입니다. 그래서 다른 기능과 다르게 다룹니다.
설정은 하나가 아니다
"알림을 받겠다" 와 "받지 않겠다" 두 값으로는 부족합니다. 사용자가 원하는 것은 대개 그 중간입니다.
| 사용자가 원하는 것 | 필요한 설정 축 |
|---|---|
| 결제 알림은 받고 마케팅은 싫다 | 알림 종류별 |
| 푸시는 좋지만 문자는 싫다 | 채널별 |
| 밤에는 안 받고 싶다 | 시간대 |
세 축이 곱해집니다. 종류 20가지에 채널 3개면 조합이 60개입니다. 사용자에게 60개를 보여줄 수는 없으므로, 화면에서는 묶어서 보여주고 저장은 조합 단위로 합니다.
그리고 거부할 수 없는 알림이 있습니다. 비밀번호 변경 알림이나 결제 실패 알림은 사용자의 안전에 필요하므로 설정에서 빼 둡니다. 이것을 처음부터 구분해 두지 않으면, 나중에 "왜 이건 못 끄나" 라는 문의가 아니라 "중요한 걸 못 받았다" 라는 사고가 생깁니다.
확인은 보내기 직전에 한다
대량 발송은 대상 목록을 만든 뒤 실제 발송까지 오래 걸립니다. 100만 건을 초당 1천 건으로 보내도 20분이 넘습니다. 그 사이에 거부한 사용자가 반드시 있습니다.
목록을 만들 때 한 번 걸러내는 것으로 끝내면 그 뒤의 거부를 놓칩니다. 한 건을 제공자에게 넘기기 직전에 다시 확인해야 합니다.
이 확인이 피크 초당 1만 상황에서도 값싸야 합니다. 그래서 수신 설정은 빠르게 읽을 수 있는 형태로 따로 둡니다. 원본은 관계형 저장소에 두고, 발송 경로에서 읽는 사본을 캐시에 둡니다.
캐시가 틀리면 어느 쪽으로 틀려야 하나
사본을 두면 원본과 잠시 다를 수 있습니다. 이때 어느 방향으로 틀리는 것이 나은지 정해야 합니다.
| 상황 | 결과 |
|---|---|
| 거부했는데 캐시가 아직 허용 | 보내면 안 되는 것을 보낸다. 위반 |
| 허용했는데 캐시가 아직 거부 | 받고 싶은 것을 못 받는다. 불만 |
둘은 무게가 다릅니다. 위반은 법적 문제이고 불만은 문의입니다. 그래서 거부는 즉시 반영하고 허용은 늦어도 됩니다. 거부 요청이 오면 캐시를 바로 지우고, 허용은 일반적인 갱신 흐름을 따릅니다.
거부 경로를 여러 개 열어야 한다
사용자가 거부하는 경로는 설정 화면만이 아닙니다.
메일의 수신 거부 링크
문자의 회신
푸시를 시스템 수준에서 끄기
앞의 둘은 우리 시스템으로 돌아옵니다. 반드시 받아서 설정에 반영해야 합니다. 세 번째는 우리가 알 수 없습니다. 제공자가 알려주는 실패 신호로 짐작할 뿐입니다.
끄기 어렵게 만드는 것은 손해입니다. 설정에서 못 끄면 사용자는 앱을 지우거나 스팸으로 신고합니다. 스팸 신고가 쌓이면 제공자가 우리 발송 전체의 도달률을 낮춥니다. 한 사용자의 거부를 막으려다 전체 도달률을 잃습니다.