본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 두번째 날입니다.
스물 한번째 날에는 푸시 알림 기능의 필요성에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 3. 채팅 서비스 핵심 기능 개발 > Ch 4. 오프라인 사용자에게도 메시지 전달을 위한 푸시 알림 기능 >
02. 이번 프로젝트에서는 푸시 서버를 페이크로 처리하는 이유
입니다.
🔔 푸시 서버를 "페이크"로 처리하는 이유는?
- 이번 포스팅에서는 왜 우리가 푸시 서버를 진짜 구현하지 않고, 가짜(Fake)로 처리하는지에 대해 이야기해보려 합니다.
- 지난 챕터에서 푸시 알림의 필요성과 구조에 대해 다뤘다면, 이번엔 실제 구현 대신 어떤 선택을 했고 왜 그렇게 했는지에 초점을 맞춰 보겠습니다.
📱 푸시 알림은 대부분 OS에 의존한다
- 모바일에서의 푸시 알림은 대부분 운영체제(OS)에 의존합니다.
- iOS는 APNs (Apple Push Notification service)
- Android는 FCM (Firebase Cloud Messaging)
이런 중계 서비스를 통해 앱에 알림을 전달합니다.
- 데스크탑도 예외는 아닙니다. Windows나 macOS에도 알림 센터가 있으며, 앱이 꺼져 있어도 이 센터가 먼저 알림을 받고 앱을 깨워줍니다.
- 그런데 우리가 만든 터미널 기반의 채팅 클라이언트는 이런 환경과는 꽤 다릅니다.
🖥️ 터미널 클라이언트는 푸시 알림과 거리가 멀다
- 터미널 기반의 앱은 UI가 없고, 텍스트만 주고받는 방식입니다. 주로 개발자들이 테스트나 서버 개발 용도로 사용하는데요. 이런 클라이언트에 푸시 알림 기능을 실제로 넣는 건 큰 의미가 없을 뿐더러, 작업량도 매우 커집니다.
- OS에 맞는 SDK를 연동하고
- 디바이스 토큰을 등록하고
- 푸시 서버에서 외부 API와 연동하고
- 인증, 보안 설정도 해줘야 합니다
- 하지만 이번 프로젝트의 방향은 외부 의존성을 최소화하고, 처음부터 끝까지 도커 환경 안에서 완결성 있는 개발 경험을 제공하는 것이기 때문에 이 선택은 맞지 않습니다.
🧪 테스트용 클라이언트는 가볍고 빠르게
- 우리가 만드는 터미널 채팅 클라이언트는 말 그대로 "개발용 테스트 클라이언트" 입니다.
- 빠르게 실행되고
- 테스트 자동화에 쓰기 좋으며
- 외부 UI 의존 없이 서버 기능을 검증할 수 있음
- 그래서 푸시 기능은 넣지 않되, "있다고 가정"하면서 동작을 흉내만 내는 방식으로 구현합니다. 이게 바로 "Fake Push Service"입니다.
🔁 오프라인 사용자는 어떻게 처리할까?
- 그렇다고 오프라인 사용자를 완전히 무시하진 않습니다.
- 예를 들어, 어떤 사용자가 오프라인 상태인데 메시지가 도착했다면,
1️⃣ 그냥 무시할 수는 없고
2️⃣ 다시 온라인이 됐을 때 알림을 받을 수 있도록 뭔가 처리가 되어야 합니다.- 그래서 프로젝트에서는 다음과 같은 처리를 할 예정입니다.
- "오프라인 사용자"와 "온라인이지만 채널 밖 사용자"를 구분하고
- 푸시 서비스에 전달되는 대상만 식별하여 처리하며
- 실제로 푸시 서버가 있는 것처럼 동작하게 하고
- 푸시 서버는 로깅만 수행하게 구현
- 그래서 프로젝트에서는 다음과 같은 처리를 할 예정입니다.
🔧 나중에는 푸시 서버를 분리할 예정
- 지금은 단일 서버 구조이지만, 강의가 진행되면서 서버가 분리되면 푸시 서버도 독립적으로 구성할 계획입니다.
- 이때는 Kafka 같은 메시지 브로커를 통해 푸시 메시지를 전달하고, 푸시 서버는 메시지를 받아 단순 로깅하거나, 연동이 된다면 진짜 푸시 전송까지 할 수도 있는 구조로 확장됩니다.
- 이번 내용을 정리하면서 느낀 건, 기능 구현에서 중요한 건 "지금 진짜 필요한가?"를 따지는 판단력이라는 점입니다. 푸시 기능은 매우 중요하지만, 그걸 지금 이 프로젝트에서 실제로 구현하는 건 가성비가 맞지 않는 선택일 수 있습니다. 게다가 테스트 클라이언트나 내부 도구에서는 모든 기능을 넣기보단, 목적에 맞는 최소한의 기능만을 구현하는 게 훨씬 효율적이죠. 이런 판단들이 결국 더 좋은 설계로 이어지는 것 같습니다.
- "없는 것처럼"이 아니라, "있는 척하면서 앞으로 확장할 수 있는 구조로만 만들어 두는 것" 이게 진짜 실전에서 많이 쓰이는 접근이라는 걸 다시금 느꼈습니다.
