알림 시스템에서 진짜 일은 ‘안 보내는’ 쪽이다

오늘 알림 시스템을 만들었다. 따라가야 할 이벤트는 네 가지 — 팔로우, 좋아요, 댓글, 북마크.

처음엔 단순해 보였다. 이벤트 → 알림 doc 작성 → 푸시 발송. 한 줄로 끝.

근데 사용자 입장으로 가 보면 그림이 다르다. 인기 글 하나 올렸더니 30분 사이에 좋아요 50개. 잠금화면이 푸시 50개로 도배된다. 다음 날 그 사람이 하는 일은? 알림을 꺼버린다. 그러면 우리가 보낸 어떤 진짜 의미 있는 알림도 영영 닿지 않는다.

만들기 전에 멈춰서 정책부터 정했다.

인앱과 푸시는 다른 동물이다

인앱 알림(앱 안의 알림 리스트)은 사용자가 종 아이콘을 눌렀을 때만 보인다. 능동적 발견. 부담이 적다.

푸시 알림은 잠금화면을 침범한다. 사용자 주의를 뺏는다. 수동적 강제. 부담이 크다.

같은 “알림”이라도 압박감이 완전히 다르다. 그러면 게이팅도 달라야 한다.

이벤트	인앱	푸시
팔로우	✓	✓
댓글	✓	✓
좋아요	✓	✗
북마크	✗	✗

좋아요는 잦으니 푸시 안 함. 북마크는 사적 행동이라 알림 자체 X (저장한 걸 작성자한테 알릴 이유가 없다).

그 위에 또 한 겹

푸시가 통과해도 한 번 더 거른다. 같은 사람에게 10분 안에 이미 푸시를 보냈으면 다음 푸시는 스킵. 단, 인앱 기록은 그대로 남긴다 — “신호 자체는 보존하되 잠금화면은 침범하지 않는다.”

이 두 단계를 코드 안에선 게이팅(gating)이라고 부른다. 클럽 입구에서 드레스코드 + 인원 제한으로 거르는 것.

조용함이 디자인이다

알림 코드를 짜는 건 쉽다. 진짜 어려운 건 언제 보내지 않을지 정하는 것이다. 보내는 코드는 짧고, 안 보내는 결정은 길다.

Fecit은 자랑하는 곳도, 자극하는 곳도 아니다. 꾸준히 하는 곳이다. 그러면 알림도 그 톤에 맞춰서, 진짜 의미 있는 신호만 잠금화면을 침범하게 둬야 한다.

좋은 알림 시스템은 사용자가 “이게 와서 다행”이라고 느낀 순간만 만든다. 그 외엔 조용히 모여 있다가, 사용자가 보고 싶을 때 보면 된다.