메모리에서 머신으로: 알림이 실제로 작동하는 방식

Source: Dev.to

마케팅이 생각하는 방식

• 우리는 메시지를 보내고 싶다.
• 사람들에게 우리를 기억하게 하고 싶다.
• 그들이 다시 돌아오게 하고 싶다.

엔지니어링이 생각하는 방식

• 우리는 신뢰성이 필요하다.
• 우리는 확장성이 필요하다.
• 우리는 제어가 필요하다.

두 관점 모두 옳지만, 각각만으로는 불완전하다. 알림 시스템은 이들을 하나로 모으기 위해 존재한다.

실제 흐름, 간단히 설명

음식 배달 예시를 들어보자. 주문을 하면 다음에 무슨 일이 일어날까?

[ Order Placed ]
       |
       v
[ Notification Service ]

주문 서비스는 직접 푸시를 보내지 않는다. 알림 서비스에만 알린다.

스마트 리셉션 역할을 하는 알림 서비스

무언가를 보내기 전에 일련의 질문을 한다:

[ Notification Service ]
        |
        |-- Is the user logged in?
        |-- Do they allow notifications?
        |-- Have we sent too many today?
        |-- What device are they using?
        |-- Push? Email? SMS?

여기서 마케팅 의도와 엔지니어링 규칙이 만난다.
마케팅: “업데이트를 보내라.”
엔지니어링: “누구에게, 어떻게, 안전하게?”

메시지에 인간적인 목소리 부여

시스템이 전송을 결정하면 메시지를 준비한다.

템플릿

[ Template ]
   |
   v
"Your order is on the way"

개인화

[ Personalization ]
   |
   v
"Hi Ram, your order is on the way"

이 단계가 없으면 알림은 로봇처럼 느껴지고, 있으면 개인적인 느낌이 든다—마치 누군가의 이름을 부르며 문 앞에 서 있는 것처럼.

배달 직원들 (보이지 않는 영웅)

이제 메시지를 사용자에게 전달해야 한다.

[ Workers ]
   |
   |-- Push (APNS / FCM)
   |-- Email (SMTP)
   |-- SMS

배달 직원은 배달 기사와 같다. 한 경로가 막히면 재시도하고, 서비스가 느리면 기다리며, 실패하면 다시 큐에 넣는다. 이것이 신뢰를 만든다.

루프 닫기: 사용자로부터 학습

전송이 끝난 뒤 시스템은 사용자의 반응을 관찰한다.

[ User ]
   |
   |-- Opened?
   |-- Clicked?
   |-- Ignored?
   |-- Disabled notifications?

그 데이터가 시스템에 다시 피드백된다:

• 마케팅은 사람들이 무엇에 관심 있는지 배운다.
• 엔지니어링은 무엇이 깨지는지 파악한다.
• 제품팀은 무엇이 중요한지 알게 된다.

다음 알림은 더 똑똑해진다.

실제 생활에서의 루프 예시

노트북 매장이 브랜드 가방을 제공한다.

[ Free Bag ]
     |
     v
[ Daily Use ]
     |
     v
[ Brand Recall ]
     |
     v
[ Return Customer ]

같은 루프, 다른 매체.

왜 이것이 중요한가?

대부분 팀은 알림을 배관처럼—그냥 파이프만—구축한다.
최고의 팀은 알림을 기억 설계처럼 다룬다. 그들은 묻는다:

• 사용자가 무엇을 기억해야 할까?
• 언제 기억해야 할까?
• 얼마나 부드럽게 상기시킬 수 있을까?
• 언제가 잡음이 되는가?

이는 단순한 아키텍처가 아니라 심리학을 시스템으로 만든 것이다. 알림은 단순히 “무언가가 일어났다”가 아니다. “중요할 때 우리를 기억하라”는 메시지다. 마케팅과 엔지니어링이 이에 동의하면, 메시지를 보내는 것이 아니라 관계를 구축하는 것이 된다.