[Web] 데이터를 fetch해서 알림을 띄우는 패턴은 어떻게 볼 수 있을까?
데이터를 fetch한 뒤 조건에 맞으면 사용자에게 알림을 보여주는 패턴을 웹 관점에서 정리한 글
notify fetch라는 표현은 저에게도 아주 익숙한 표준 용어는 아니었습니다.
하지만 문맥을 생각해보면, 보통은 서버에서 데이터를 가져오고(fetch), 특정 조건이 맞으면 사용자에게 알림을 보여주는 흐름을 뜻하는 경우가 많다고 느꼈습니다.
저도 이 표현을 다시 정리하면서 느낀 건,
이 패턴의 핵심은 단순히 fetch()를 쓰는 것이 아니라
언제 데이터를 확인하고, 어떤 조건에서, 어떤 방식으로 알림을 보여줄지를 함께 설계하는 것에 있다는 점이었습니다.
이번 글에서는 데이터를 fetch해서 알림을 띄우는 패턴을 웹 기준으로 정리해보려고 합니다.
이 패턴은 정확히 무엇일까?
가장 단순하게 표현하면 아래 흐름입니다.
- 클라이언트가 서버에서 데이터를 가져옵니다.
- 가져온 데이터 중 새로 도착한 항목이나 특정 조건을 확인합니다.
- 조건이 맞으면 사용자에게 알림을 보여줍니다.
즉, 구조 자체는 단순합니다.
문제는 이걸 실제 서비스에 넣으려고 하면,
얼마나 자주 가져올지, 중복 알림은 어떻게 막을지, 브라우저가 꺼졌을 때는 어떻게 할지 같은 고민이 바로 생긴다는 점입니다.
가장 단순한 형태
가장 먼저 떠올릴 수 있는 방식은 주기적으로 데이터를 가져오는 형태입니다.
예를 들어:
- 30초마다
/api/notifications를 호출하고 - 응답에 새로운 알림이 있으면
- 브라우저 알림이나 UI 배지를 띄운다
같은 흐름입니다.
이 방식은 구현이 직관적입니다.
기존 HTTP API가 이미 있다면 그 API를 그대로 재사용할 수도 있습니다.
즉,
- 데이터 수집:
fetch() - 조건 판단: 클라이언트 로직
- 사용자 전달: Notifications API 또는 화면 UI
처럼 역할을 나눌 수 있습니다.
왜 생각보다 단순하지 않을까?
겉보기에는 “데이터를 가져와서 알림을 띄우면 된다”로 끝날 것 같지만,
실제 문제는 그 다음부터입니다.
예를 들어 아래 질문들이 바로 생깁니다.
- 같은 알림을 여러 번 띄우지 않으려면 어떻게 해야 할까?
- 사용자가 탭을 여러 개 열고 있으면 중복 알림은 어떻게 막을까?
- 브라우저가 백그라운드에 있거나 닫혀 있으면 어떻게 할까?
- 주기적으로 fetch하면 서버 부담은 어느 정도일까?
즉, 이 패턴의 핵심은 fetch 자체보다 알림 상태를 어떻게 관리할지에 더 가깝습니다.
보통 어떤 방식으로 구현할까?
1. 주기적 polling + 알림 표시
가장 흔한 형태입니다.
- 일정 주기마다 서버에서 최신 알림 목록을 가져오고
- 마지막으로 본 알림 ID나 timestamp와 비교해서
- 새 알림만 사용자에게 보여줍니다.
장점은 단순하고 이해하기 쉽다는 점입니다.
반면, 변경이 없어도 계속 요청이 발생하므로 비효율이 생길 수 있습니다.
즉, 이 방식은 규모가 크지 않거나 실시간성이 아주 중요하지 않을 때 잘 맞습니다.
2. long polling + 알림 표시
short polling보다 조금 더 실시간에 가까운 방식입니다.
클라이언트가 요청을 보내면 서버는 바로 응답하지 않고,
새 알림이 생길 때까지 잠시 기다렸다가 응답합니다.
이 경우 불필요한 요청은 줄일 수 있지만,
서버가 열린 요청을 더 오래 관리해야 하므로 운영 부담은 커집니다.
즉, 알림 반응 속도는 중요하지만 WebSocket까지는 가지 않으려는 경우에 고려할 수 있습니다.
3. Push 기반 알림
엄밀히 말하면 이건 fetch해서 알림을 띄우는 패턴과는 조금 다릅니다.
서버가 직접 클라이언트에 메시지를 전달하기 때문입니다.
하지만 실무적으로는 이 세 가지를 같이 비교하게 됩니다.
왜냐하면 결국 목표는 같기 때문입니다.
“새로운 정보가 생겼을 때 사용자가 빠르게 알 수 있게 만들기”
즉, notify fetch 패턴을 이해한다는 것은,
실제로는 polling과 push의 중간 지점을 같이 이해하는 것에 가깝습니다.
알림은 어디에서 띄울까?
웹에서 알림을 보여주는 방식은 크게 두 가지로 나눌 수 있습니다.
1. 화면 안의 알림
예:
- 상단 배지 숫자 증가
- 토스트 메시지
- 읽지 않은 알림 목록
이 방식은 사용자가 이미 서비스 안에 있을 때 자연스럽습니다.
2. 시스템 알림
브라우저 Notifications API를 사용하는 방식입니다.
이 방식은 탭이 백그라운드에 있을 때 더 강력하지만,
권한 요청과 브라우저 지원 문제를 함께 고려해야 합니다.
즉, notify fetch 패턴에서는
가져온 데이터를 어떤 채널로 보여줄지도 함께 결정해야 합니다.
가장 중요한 문제: 중복 알림
제가 이 패턴에서 가장 중요하다고 느낀 부분은 이겁니다.
새 데이터를 가져오는 것보다, 이미 본 알림을 다시 띄우지 않는 것이 더 중요할 수 있습니다.
예를 들어:
- 마지막으로 처리한 알림 ID를 저장하거나
- 마지막 조회 시각을 저장하거나
- 클라이언트에 이미 표시한 알림 목록을 캐싱하는 방식
이 필요합니다.
그렇지 않으면 polling 주기마다 같은 알림이 반복해서 뜰 수 있습니다.
즉, notify fetch 패턴은 단순 fetch 패턴이 아니라,
상태 기억(state tracking) 이 꼭 필요한 패턴이라고 볼 수 있습니다.
언제 이 방식이 적합할까?
잘 맞는 경우
- 내부 관리자 페이지
- 사내 대시보드
- 실시간성은 어느 정도 필요하지만 WebSocket은 과한 경우
- 새 항목이 생겼는지만 빠르게 알려주면 되는 경우
덜 맞는 경우
- 사용자가 매우 많고 동시 접속이 많은 경우
- 거의 실시간에 가까운 반응이 꼭 필요한 경우
- 브라우저가 닫힌 상태에서도 안정적으로 알림이 가야 하는 경우
이런 상황에서는 polling 기반 notify fetch 패턴보다,
push 기반 구조가 더 잘 맞을 수 있습니다.
예시로 보면 더 쉬운 주문 알림
예를 들어 관리자가 주문 대시보드를 보고 있다고 가정해보겠습니다.
- 클라이언트는 20초마다 새로운 주문이 있는지 fetch합니다.
- 서버는 최근 주문 목록을 반환합니다.
- 클라이언트는 마지막으로 확인한 주문 ID보다 큰 주문이 있으면
새 주문 알림 배지나 토스트를 띄웁니다.
이렇게 하면 구조는 단순하지만,
실제로는 아래 두 가지가 중요합니다.
- 중복 알림을 막는 기준
- polling 주기를 얼마나 둘 것인지
즉, 이 패턴은 “기술적으로 가능하냐”보다
운영 기준을 어떻게 잡느냐가 더 중요하다고 볼 수 있습니다.
결론
notify fetch라는 표현은 표준 기술 용어라고 보긴 어렵지만,
개발자 문맥에서는 충분히 데이터를 fetch해서 조건에 맞는 알림을 띄우는 흐름으로 이해할 수 있습니다.
제가 이번에 다시 정리하면서 느낀 건,
이 패턴의 핵심은 fetch API 자체보다
중복 방지, 알림 조건 판단, 주기와 서버 부담 조절에 있다는 점이었습니다.
결국 중요한 것은
어떤 방식으로 가져올지보다,
새로운 정보만 정확하게 잡아내고 사용자에게 과하지 않게 전달할 수 있는지를 먼저 설계하는 것이라고 생각합니다.