앱에 알림을 추가하는 방법: 앱 내 알림, 이메일, 푸시

웹 앱에 알림을 추가하려면 먼저 앱 내 알림부터 시작하세요. 알림 테이블을 데이터베이스에 두고, 읽지 않은 항목을 보여 주는 벨 아이콘을 추가하면 됩니다. 사용자가 자리를 비운 동안에도 알아야 하는 내용에는 이메일을 추가하세요. 이메일 제공업체가 필요합니다. 웹 푸시는 시간에 민감한 알림이 정말 중요할 때만 추가하세요. 서비스 워커, 사용자 권한, 그리고 아이폰에서는 홈 화면에 저장된 앱이 필요하기 때문입니다. 어떤 채널을 쓰든 모든 알림은 서버의 한 곳에서 만들고, 어떤 알림을 받을지는 사용자가 고르게 하세요.

이 가이드는 채널을 비교하고, 간단한 구조를 보여 주며, AI 앱 빌더에 쓸 프롬프트를 제공합니다.

주요 채널 비교

대부분의 앱은 앱 내 알림과 이메일이 필요합니다. 푸시와 SMS는 예약 알림, 준비된 주문처럼 시점이 정말 중요할 때 가치가 있습니다.

알림 시스템의 구조

단순하고 중앙에 모아 두세요.

1. 무언가 일어납니다. 댓글이 달리거나, 결제가 실패하거나, 예약이 내일로 다가옵니다.
2. 서버가 함수 하나를 호출합니다. 예: notify(user, type, data).
3. 그 함수가 사용자 설정을 확인하고 벨용 notifications 테이블에 행을 씁니다.
4. 해당 유형에 켜 둔 다른 채널로 보냅니다. 이메일은 제공업체를 통해, 푸시는 Push API를 통해 보냅니다.
5. 프런트엔드가 읽지 않은 알림을 보여 주고, 열면 읽음으로 표시합니다.

발송 지점을 하나로 모아 두면 채널을 추가하거나, 문구를 바꾸거나, 사용자 설정을 지키는 일을 코드 여기저기를 뒤지지 않고 할 수 있습니다.

저장할 내용

알림 테이블에는 보통 사용자 ID, 유형(예: comment_reply), 짧은 제목과 본문, 관련 페이지 링크, 생성 시각, 읽은 시각이 필요합니다. 별도의 설정 테이블에는 사용자가 유형별로 어떤 채널을 원하는지 저장합니다.

새 알림 표시하기

• 페이지를 열 때 불러오고 30~60초마다 폴링하기. 간단하고 안정적입니다.
• WebSocket이나 서버 전송 이벤트로 실시간 업데이트하기. 즉각적으로 느껴지지만 움직이는 부품이 늘어납니다. 즉각성이 꼭 필요하지 않다면 폴링으로 시작하세요.

이메일 알림

이메일에는 발송 제공업체와 인증된 도메인이 필요합니다. 자세한 내용은 앱에서 이메일 보내는 방법에 있습니다. 알림에 대해서는 다음을 지키세요.

• 서버에서 발송하세요. 제공업체 키가 브라우저에 있어서는 안 됩니다.
• 자주 발생하는 이벤트는 묶으세요. 댓글 세 개를 세 통의 메일로 보내기보다 "새 댓글 3개"를 한 통으로 보내는 편이 낫습니다.
• 중요도가 낮은 활동에는 일간 또는 주간 요약을 제공하세요.
• 중요하지 않은 이메일에는 수신 거부 또는 설정 링크를 넣으세요. 마케팅 이메일 규정은 국가마다 다르니 해당 규정을 확인하세요.

웹 푸시 알림

웹 푸시를 쓰면 사이트가 앱 알림처럼 보이는 메시지를 보낼 수 있습니다. MDN의 Push API 문서에 따르면 동작 방식은 다음과 같습니다.

1. 사이트가 서비스 워커를 등록합니다. 브라우저가 백그라운드에서 실행할 수 있는 스크립트입니다.
2. 사용자가 동의하면 서비스 워커가 PushManager.subscribe()로 구독합니다. 브라우저는 엔드포인트와 암호화 키가 담긴 구독 정보를 돌려줍니다.
3. 서버가 그 구독 정보를 저장하고, 무언가 일어나면 엔드포인트로 메시지를 보냅니다. 보통 VAPID 키(서버를 식별하는 키 쌍)로 서명합니다.
4. 브라우저가 서비스 워커를 시작하고, 서비스 워커가 페이지가 열려 있지 않아도 알림을 표시합니다.

MDN은 엔드포인트를 비밀로 유지해야 한다고도 설명합니다. 엔드포인트를 알면 그 사용자에게 메시지를 보낼 수 있기 때문입니다.

아이폰과 아이패드

WebKit은 iOS 및 iPadOS 16.4에서 웹 앱에 웹 푸시를 도입했습니다. 발표 내용에 따르면 두 가지 조건이 있습니다. 사이트가 홈 화면에 추가되어 있어야 하고, 권한은 구독 버튼 탭 같은 사용자 동작에 응답해서 요청해야 합니다. 따라서 아이폰에서는 웹 앱을 설치한 사용자에게만 푸시가 도달합니다. 웹 앱 설치의 의미는 네이티브 앱과 프로그레시브 웹 앱을 참고하세요.

권한을 잘 요청하는 방법

첫 방문에 바로 묻지 마세요. 먼저 이득을 설명하고("수업 한 시간 전에 알림을 받아 보세요"), 사용자가 버튼을 누를 때 브라우저 프롬프트를 보여 주세요. 사용자가 거절하면 브라우저가 다시 묻게 허용하지 않을 수 있으므로, 너무 이른 요청은 사용자를 영영 잃게 만들 수 있습니다.

예약 알림에는 트리거가 필요합니다

"24시간 전 알림"이나 "매주 월요일 주간 요약" 같은 기능에는 일정에 맞춰 실행될 무언가가 필요합니다. 이것은 백그라운드 작업 실행 방법에서 다루는 백그라운드 작업 문제입니다. 흔한 패턴은 외부 스케줄러가 몇 분마다 보호된 엔드포인트를 호출하고, 그 엔드포인트가 발송 시점이 된 알림을 보내는 것입니다.

AI 빌더에 줄 프롬프트

앱 내 알림부터 시작하세요.

앱 내 알림을 추가해 주세요. 알림 테이블을 만듭니다(사용자, 유형, 제목, 본문, 링크, created_at, read_at). 모든 기능이 호출하는 서버 함수 notify(userId, type, data)를 추가해 주세요. 헤더에 읽지 않은 개수가 있는 벨 아이콘, 최근 20개를 보여 주는 드롭다운, "모두 읽음으로 표시" 버튼을 넣어 주세요. 60초마다 새 알림을 폴링해 주세요.

다음은 설정과 이메일입니다.

알림 설정을 추가해 주세요. 유형별(댓글 답글, 멘션, 결제)로 사용자가 앱 내, 이메일, 둘 다, 없음 중에서 고를 수 있게 합니다. notify()가 이 설정을 지켜야 합니다. 이메일은 [PROVIDER]로 보내고, 서버에서만 [ENV_NAME] 시크릿을 사용해 주세요. 댓글 이메일은 묶어서, 한 사용자에게 15분에 최대 한 통만 가게 해 주세요.

필요하다면 푸시도 추가하세요.

선택적 웹 푸시를 추가해 주세요. 서비스 워커를 등록하고, VAPID 키를 생성하며, 개인 키는 시크릿으로 저장해 주세요. 설정에 "알림 켜기" 버튼을 추가하고, 버튼을 클릭할 때만 권한을 요청하세요. 구독 정보는 사용자와 기기별로 저장하고, 사용자가 동의한 경우 notify()에서 푸시를 보내며, 푸시 서비스가 만료됐다고 알려 온 구독은 삭제해 주세요.

흔한 실수

• 알림이 코드 여기저기 흩어져 있음. 기능마다 제각각 이메일을 보내서 설정이 무시되곤 합니다. notify() 함수 하나를 쓰세요.
• 페이지를 열자마자 푸시 권한 요청. 대부분의 사용자가 거절하며, 다시 물을 기회가 없을 수도 있습니다.
• 사용자 설정이 없음. 시끄러운 알림을 끌 수 없는 사용자는 결국 모든 알림을 끄거나 앱을 떠납니다.
• 브라우저에서 발송. 이메일과 푸시 키는 서버에 있어야 합니다.
• 만료된 푸시 구독을 정리하지 않음. 만료된 구독이 쌓이면 발송이 낭비됩니다.
• 알림 텍스트에 민감한 정보 포함. 잠금 화면에 그대로 표시됩니다. 메시지 내용 대신 "새 메시지가 있습니다"라고 쓰는 편이 안전합니다.
• 보낸 내용을 기록하지 않음. 사용자가 "이메일을 못 받았어요"라고 하면, 제공업체 메시지 ID가 있는 로그가 원인을 찾게 해 줍니다.

체크리스트

• 서버의 notify() 함수 하나를 모든 곳에서 사용한다
• 읽음 상태가 있는 알림 테이블과 읽지 않은 개수가 표시되는 벨이 있다
• 유형별 채널 설정이 있고 notify()가 이를 지킨다
• 인증된 도메인으로 서버에서 이메일을 보내며, 자주 발생하는 이벤트는 요약이나 묶음으로 처리한다
• 푸시 권한은 사용자 동작 후에만, 설명과 함께 요청한다
• 푸시를 데스크톱과 홈 화면에 추가한 아이폰에서 모두 테스트했다
• 만료된 푸시 구독을 삭제한다
• 푸시나 이메일 미리보기에 민감한 내용이 없다
• 예약 알림에 안정적인 트리거가 있다

Mythex의 알림

Mythex는 여러분이 만든 앱을 위한 이메일이나 푸시 서비스를 기본으로 제공하지 않습니다. 그래서 직접 이메일 제공업체를 준비하고, 푸시 키를 생성해 프로젝트 시크릿으로 저장해야 합니다. 앱 내 알림은 프로젝트 데이터베이스만 있으면 되며, 이 데이터베이스는 요청하면 Mythex가 추가합니다. 위의 프롬프트로 만들고, 벨과 이메일은 미리보기에서 테스트하세요. 푸시는 서비스 워커와 푸시에 실제 HTTPS 주소가 필요하므로 게시한 URL에서 테스트하세요. 문서의 이메일 보내기 레시피에 시작용 프롬프트가 있습니다. Mythex는 예약 작업을 문서화하지 않으므로, 시간에 맞춘 알림은 백그라운드 작업 실행 방법에서 설명한 대로 외부 트리거로 계획하세요.

자주 묻는 질문