서론
하나의 큰 행사에는 작은 여러가지 이벤트가 포함됩니다.
출석체크 애플리케이션 프로젝트는 이벤트와 관련된 콘텐츠가 많기 때문에,
이벤트 정보를 정확하게 전달하는 것이 중요합니다.
특히, 시작/종료 시간에 대한 정보를 정확하게 전달해서 사용자의 참여도를 높여야합니다.
이 과제를 해내기 위해 TimeTable이라는 개념을 도입했습니다.
TimeTable에는 행사 시간과 장소가 명시되어있습니다.
사용자는 TimeTable을 통해 이벤트 일정을 조회할 수 있습니다.
발단: 사용자 이용환경 개선
사용자의 주요 참여 목적은 이벤트에 출석해서 스탬프를 모으고, 경품 추첨 대상이 되는 것입니다.
따라서 사용자가 제시간에 스탬프를 모을 수 있도록 이벤트 정보를 정확하게 전달해야 합니다.
또한 행사 내 이벤트는 여러 타입으로 구성되어 있고,
동일한 타입의 이벤트에 중복 참여하면 스탬프가 지급되지 않습니다.
따라서 사용자는 스탬프를 모두 모을 수 있도록 이벤트 타입과 일정을 잘 파악해야힙니다.
그러나 일정을 파악하기 위해 별도의 메모를 작성하거나,
직접 반복해서 이벤트 TimeTable을 확인하는 것은 사용자에게 불편함을 줍니다.
따라서 사용자들이 자신이 관심있는 이벤트를 즐겨찾기로 등록하고,
시작 전에 알림으로 정보를 알려주면 문제를 개선할 수 있다고 판단했습니다.
즐겨찾기 시스템 도입
처음에는 즐겨찾기 기능에 대해 고민하지 않았습니다.
알림 기능만 고민했고 이것만으로도 사용자에게 충분히 정보를 전달한다고 생각했습니다
하지만 사용자가 필요하지 않은 알림까지 전달될 수 있다는 문제를 발견했습니다.
이렇게 된다면 사용자의 혼란과 불편함을 증가시키기 때문에,
알림 시스템을 도입한 이유가 퇴색된다고 판단했습니다.
따라서 알림 시스템을 개선하기 위해 사용자가 지정한 이벤트만 전달해야겠다고 판단했고,
그 해결방법으로 즐겨찾기 시스템 도입을 선택했습니다.
사용자는 특정 이벤트에 대해 좌측 알람 표시를 클릭해서 즐겨찾기로 등록할 수 있습니다
백엔드는 해당 정보를 프론트엔드로부터 받아 DB에 저장하여 관리하도록 개발했습니다.
이제 즐겨찾기 시스템으로 사용자가 원하는 이벤트를 확인할 수 있고,
또한 즐겨찾기에 등록한 이벤트만 알림으로 전달할 수 있는 환경이 구성되었습니다
전개: 알림시스템 방식 고민
이어서 알림시스템 방식에 대해 고민했습니다.
사용자가 선택한 이벤트 시간에 맞춰서 알림을 주기 위해서는 다음을 고려해야합니다.
- 이벤트 시작 시간
- 현재 시간
- 알림 대상
이벤트 시작시간
이벤트 정보는 DB에서 관리하므로, 백엔드가 이를 관리하기로 결정했습니다.
알림 대상
알림 대상은 사용자별로 즐겨찾기된 항목이 다르고 관리가 편하다는점을 고려하여,
프론트엔드에서 관리하기로 결정했습니다.
현재 시간
현재 시간은 알림 제공 방법에 따라 관리 주체를 다르게 하기로 결정했습니다
알림 시스템 후보 선정
이벤트 시작 시간에 맞춰 사용자에게 알림을 주기 위해서는,
현재 시간을 파악해 비교하는 과정이 필요합니다.
현재 시간을 파악하는 주체를 3가지로 분류했습니다.
- 프론트엔드
- 백엔드
- 기타
각 주체별로 파악하는 방법을 정리했습니다
프론트엔드가 파악할 때
프론트엔드에서 반복적으로 백엔드에 즐겨찾기 데이터를 요청하고,
현재시간과 비교하여 사용자에게 알림을 전달하는 방법을 고민했습니다.
이 경우, Polling 방법을 사용할 수 있는데
해당 방법은 사용자가 많을 경우, 서버에 부하를 준다는 문제가 있습니다.
또한 어떤 주기로 데이터를 불러올 것인지 설정하는 것도 쉽지 않습니다.
너무 짧게 하면, 불필요한 요청이 반복되면서 사용자 기기와 서버에 좋지 않은 영향을 주고
너무 길게 하면, 원하는 시간에 알림을 주지 못할 수도 있습니다.
따라서 프론트엔드에서 현재시간을 파악하는 방법은
1. 서버 성능 저하 문제
2. 요청 주기 설정의 어려움
위 두가지 이유로 후보에서 제외했습니다
백엔드가 파악했을 때,
백엔드가 알림을 제공하려면 서버 -> 클라이언트 형태로 정보전송 방법을 변경해야합니다.
서버 -> 클라이언트 방법은 대표적으로 Server Sent Event (SSE) 방법이 있습니다.
Server Sent Event (SSE)
Server Sent Event 방식은 서버에서 클라이언트로 실시간 이벤트를 전달하는 웹기술입니다.
SSE는 단방향 통신으로 서버에서 클라이언트로 통신하는 방향만 존재하므로
클라이언트에서 서버로 통신할 수는 없습니다.
SSE 방식을 사용하기 위해서는 연결을 지속적으로 유지해야합니다.
클라이언트와 연결을 유지하고 있다는 것은 서버의 스레드를 점유하고 있다는 것이고
사용자가 많은 환경에서는 서버에 큰 부하를 줄 수 있습니다.
연결유지와 서버부하 - SSE
SSE 방식은 서버와 클라이언트가 연결을 유지해야합니다.
연결이 끊어지면 알림을 전송할 수 없습니다
앞서 말했다싶이 연결을 유지한다는 것은 그만큼 서버의 스레드를 점유하는 것이고,
사용자가 많은 환경이라면 서버에 큰 부하를 줄 수 있습니다.
서버는 알림 시스템 이외에도 처리할 비즈니스 로직이 많습니다.
알림 시스템은 서비스 품질을 향상시키기 위한 솔루션일 뿐이지
이것이 핵심적인 비즈니스 로직은 아닙니다.
기타 방식
SSE외에도 Websocket방식이 있습니다.
SSE와 비교하자면 WebSocket은 양방향 통신만 지원한다는 차이점이 있습니다.
이번 프로젝트에서 양방향 통신은 필요하지 않습니다.
알림을 전송하는 단방향 통신 기능만 필요하며,
동일하게 연결을 유지해야하므로 WebSocket 방식은 제외했습니다.
정리
알림 시스템 때문에 서버에 큰 부하를 주는 것은 합리적인 선택이 될 수 없습니다.
따라서 SSE와 WebSocket을 사용하는 방법이 아닌 새로운 방법을 찾아야 했습니다.
위기: 실시간 알림과 푸시알림이 다르다고?
Polling과 SSE를 선택지에서 제외하고 나서 팀원과 다시 상의했습니다.
상의하던 와중 알림에 대해 잘못 이해하고 있다는 것을 알았습니다.
제가 생각했던 방식은 실시간 알림에 대한 것이었고,
팀원이 생각했던 알림의 방식은 푸시알림이었습니다.
실시간 알림
실시간 알림은 서버와 클라이언트 간 연결을 유지하며 데이터를 즉시 전송합니다
주로 클라이언트가 활성화된 상태에서 실시간으로 업데이트되는 데이터를 처리할 때 사용합니다.
앞선 SSE와 Polling방식은 주로 실시간 알림에서 사용하는 방법입니다.
푸시알림
푸시알림은 서버에서 클라이언트로 데이터를 전송하지만,
클라이언트가 활성화되지 않은 상태에서도 알림 주체를 통해 메세지를 전달할 수 있습니다
즉 연결을 유지할 필요가 없습니다.
주로 간단한 메세지나 사용자 행동을 유도하는 알림에 사용합니다.
프로젝트에 적합한 방법은?
이 프로젝트의 목적은 이벤트에 대한 정보를 적시에 제공하고 사용자의 참여를 유도하는 것입니다
하지만 서버의 성능저하를 막기 위해 클라이언트와의 연결을 유지는 않아야 한다.
이를 위해 가장 적합한 방법은 푸시알림입니다.
따라서 실시간 알림과 관련된 방법은 현재 프로젝트에 적합하지 않기 때문에,
알림 시스템의 방법으로 푸시알림을 선택했습니다.
결말: 웹 푸시알림 선택
푸시알림의 방식은 앱 푸시알림과 웹 푸시알림으로 나뉩니다.
현재 프로젝트는 웹 기반 애플리케이션이므로 웹 푸시알림을 선택했습니다.
이제 어떤 방식으로 알림 시스템을 구축할지 결정되었습니다.
웹 푸시알림 방식을 학습하고, 어떤 방식으로 개발할지만 결정하면 됩니다.
자세한 내용은 2부에서 이어집니다.
참고:
