본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 한번째 날입니다.
스무번째 날에는 이번 파트에서 채팅 프로젝트에 추가할 기능에 대한 소개와 스키마 설계에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 3. 채팅 서비스 핵심 기능 개발 > Ch 4. 오프라인 사용자에게도 메시지 전달을 위한 푸시 알림 기능 >
01. 푸시 알림 기능의 필요성
입니다.
📡 오프라인 사용자에게도 메시지를! 푸시 알림이 필요한 이유
- 이번 포스팅에서는 채팅 시스템의 사용자 경험을 한 단계 높여줄 핵심 기능, 바로 ‘푸시 알림(Push Notification)’에 대해 정리합니다. 채팅 기능을 아무리 잘 구현해도, 사용자가 앱을 실행하지 않으면 중요한 알림을 놓칠 수 있습니다. 이 문제를 해결하기 위해 등장한 것이 푸시 알림입니다.
🚪 오프라인 사용자에게도 문을 두드릴 수 있을까?
- 일단 우리가 말하는 ‘푸시 알림’이 무엇을 뜻하는지부터 명확히 해볼게요. 여기서 말하는 푸시 알림은 단순히 앱 내 알림이 아니라, 앱이 완전히 꺼져 있거나 백그라운드에 있는 상태, 즉 사용자가 우리 서비스를 보고 있지 않은 상태에서도 정보를 전달할 수 있는 방법입니다.
- 특히 모바일에서는 앱을 계속 켜두는 게 어렵기 때문에, 사용자가 채팅 앱을 꺼두었거나 다른 앱을 사용 중일 때도 서버가 알림을 전달할 수 있는 수단이 필요합니다. 이때 쓰이는 것이 바로 iOS의 APNs나 Android의 FCM 같은 OS 단 푸시 시스템입니다.
📲 푸시는 이렇게 전달됩니다
- 푸시 알림은 앱 서버 → OS 벤더의 푸시 서버 → 사용자 디바이스 순으로 전달됩니다.
- iOS는 APNs (Apple Push Notification Service)
- Android는 FCM (Firebase Cloud Messaging)
- 이 구조에서 알 수 있듯, 푸시는 앱이 직접 받는 게 아니라 OS가 먼저 수신하고, 이후 OS가 앱을 깨워서 알림을 전달합니다. 요즘은 앱을 마음대로 깨우는 것이 불가능에 가깝기 때문에, 대부분 OS가 알림을 띄우고 사용자가 이를 탭하면 앱이 실행되는 구조로 작동합니다.
- 즉, 푸시 알림은 ‘정보 전달’뿐만 아니라 앱의 재활성화 트리거 역할도 하게 되는 겁니다.
🔋 푸시 알림은 만능일까?
- 물론 한계도 있습니다. 디바이스 자체가 꺼져 있거나 네트워크가 끊긴 상태라면 푸시 알림은 전달되지 않습니다. 또한 푸시 서버에서의 재전송 보장도 없기 때문에, 정말 중요한 메시지라면 서버 차원에서 별도의 재전송 로직을 마련해야 합니다.
- 이런 복잡함에도 불구하고 푸시 알림을 사용하는 이유는 분명합니다:
- 앱이 백그라운드에 있을 때도 유저에게 알림 전달 가능
- 앱이 깨어나는 계기를 제공 (앱이 열리면 서버와 동기화 가능)
- 사용자 입장에서는 더 빠르고 실시간에 가까운 반응성 경험
- 서비스 입장에서는 DAU(일간 활성 사용자) 지표에 긍정적 영향
- 이런 복잡함에도 불구하고 푸시 알림을 사용하는 이유는 분명합니다:
🧠 푸시는 단순 알림이 아니다!
- 흥미로운 점은, 푸시 알림이 단지 메시지를 보여주는 수단이 아니라는 겁니다. 예를 들어:
- 앱이 푸시로 깨어난 직후, 백그라운드에서 데이터 동기화를 수행할 수 있습니다.
- 만료 직전의 액세스 토큰을 갱신하는 등 사용자 모르게 필요한 작업을 진행할 수 있습니다.
- 이를 통해 사용자 경험을 더 부드럽고 자연스럽게 만들 수 있고, 앱 사용 흐름이 매끄럽게 이어질 수 있습니다.
- 이처럼 푸시는 알림 + 앱 활성화 + 시스템 상태 갱신을 아우르는 중요한 기능입니다.
🚧 우리는 푸시 기능을 어떻게 할까?
- 안타깝지만, 지금 우리가 만드는 채팅 프로젝트에서는 실제 푸시 알림 기능을 구현하지 않습니다. 이유는 다음과 같습니다:
- 푸시 기능은 모바일 디바이스 연동이 필요하고
- OS 벤더의 푸시 서버와 통신하기 위한 복잡한 인증과 설정 작업이 동반되며
- 생각보다 구현 범위가 크기 때문입니다.
- 하지만 그렇다고 무시하는 건 아닙니다. 우리는 이후 챕터에서 푸시 알림 인터페이스를 가짜로 만들어 두고, 시스템 구조 차원에서 확장 가능한 설계를 준비할 예정입니다. 이를 통해 나중에 실제 푸시 기능을 붙일 때 큰 수정 없이도 연동이 가능하도록 만드는 것이 목표입니다.
- 이번 내용을 정리하면서 느낀 건, 단순한 기능 하나가 서비스의 깊이를 얼마나 확장시킬 수 있는가였습니다. 푸시 알림은 ‘전달’만 하는 게 아니라, ‘연결’을 유지시켜주는 도구입니다.나중에 푸시 기능을 실제로 구현할 때도, 오늘의 이 개념 정리가 큰 도움이 될 것 같아요. 당장은 인터페이스만 남기고, 미래를 고려한 선택을 해두는 것. 그게 바로 확장 가능한 설계의 시작이라고 생각합니다.
