Polling, SSE, WebSocket, Supabase Realtime 중 무엇을 선택할까?
실시간 기능이 필요하다는 말은 요구사항이 아니다. 사용자가 몇 초 늦게 봐도 되는지, 서버에서 브라우저로만 보내면 되는지, 양쪽이 계속 메시지를 주고받아야 하는지부터 정해야 한다. 이 질문에 답하면 Polling, SSE, WebSocket, Supabase Realtime 중 선택이 쉬워진다.
한눈에 보는 선택 기준
| 방식 | 통신 방향 | 잘 맞는 일 | 주의할 점 |
|---|---|---|---|
| Polling | 요청할 때마다 왕복 | 몇 초 단위 상태 확인, 작은 사내 도구 | 불필요한 요청, 갱신 지연 |
| SSE | 서버에서 브라우저로 단방향 | 진행률, 알림, 로그 스트림 | 클라이언트 발신은 별도 HTTP 필요 |
| WebSocket | 양방향 연결 | 채팅, 공동 편집, 빠른 상호작용 | 연결 상태, 재접속, 확장 설계 |
| Supabase Realtime | 관리형 WebSocket 기능 | DB 변경 알림, Broadcast, Presence | 권한 정책, 요금제 한도, 메시지 설계 |
Polling은 나쁜 기본값이 아니다
사용자가 5초에서 30초 정도의 지연을 받아들일 수 있고 조회 비용이 작다면 Polling이 가장 단순하다. 네트워크가 끊겨도 다음 요청에서 회복하고, 서버도 일반 HTTP API만 운영하면 된다. 탭이 보이지 않을 때 간격을 늘리고, 변경이 없으면 지수적으로 간격을 늘리는 방식으로 요청량을 줄일 수 있다.
사내 결재 목록, 배치 작업 상태, 새 공지 확인처럼 초 단위 동기화가 필요하지 않은 화면은 Polling으로 충분한 경우가 많다.
SSE는 서버 알림이 중심일 때 좋다
Server-Sent Events는 서버가 브라우저로 이벤트를 이어 보내는 단방향 연결이다. 브라우저의 EventSource가 재연결을 지원하고 구현이 비교적 단순하다. 클라이언트가 서버로 보낼 내용은 일반 HTTP 요청을 사용한다. MDN Server-Sent Events 안내
AI 응답 스트리밍, 보고서 생성 진행률, 운영 로그처럼 서버가 계속 결과를 보내고 사용자는 가끔 취소만 하는 흐름에 잘 맞는다.
WebSocket은 양방향성이 실제로 필요할 때 쓴다
채팅, 공동 편집, 상담원 상태처럼 양쪽이 낮은 지연으로 자주 메시지를 주고받는다면 WebSocket이 자연스럽다. 대신 연결 인증, heartbeat, 재접속, 순서, 중복 처리, 여러 서버 간 상태 공유까지 설계해야 한다.
2026년 현재 Vercel Functions는 WebSocket 연결을 기본 지원한다. 다만 연결은 함수의 최대 실행 시간 동안 해당 함수에 고정되고, 이후 연결이 같은 함수로 간다는 보장은 없다. 여러 연결이 공유하는 지속 상태는 Redis 같은 외부 저장소가 필요하다. Vercel WebSocket 지원 안내
따라서 짧은 세션의 스트리밍에는 쓸 수 있지만, 장시간 연결과 방 상태를 핵심으로 하는 서비스라면 관리형 실시간 서비스나 상시 서버를 함께 검토한다.
Supabase Realtime은 기능에 따라 나눈다
Supabase Realtime에는 세 가지 주요 기능이 있다.
- Broadcast: 채널 구독자에게 사용자 정의 메시지를 보낸다.
- Presence: 온라인 여부처럼 천천히 바뀌는 사용자 상태를 공유한다.
- Postgres Changes: DB의 삽입, 변경, 삭제를 구독한다.
Supabase는 대부분의 용도에 Broadcast를 권장하고, Postgres Changes는 설정이 단순하지만 규모가 커질 때 Broadcast보다 제약이 있다고 설명한다. Supabase DB 변경 구독 방식
Presence는 마우스 위치처럼 자주 바뀌는 값에 쓰지 않는다. 상태 변경 때마다 전체 구독자에게 동기화 부담이 생기므로 온라인 상태, 현재 문서처럼 느리게 변하는 정보에 적합하다. Supabase Presence
사내 시스템에서의 권장 순서
- 10초 늦어도 되는가? 그렇다면 Polling부터 시작한다.
- 서버에서 화면으로 계속 보내기만 하면 되는가? SSE를 검토한다.
- DB 변경 알림과 권한 관리가 중심인가? Supabase Realtime을 검토한다.
- 양방향 고빈도 메시지와 긴 연결이 핵심인가? WebSocket 전용 계층을 검토한다.
어떤 방식을 쓰든 DB를 최종 상태의 기준으로 둔다. 연결이 끊겼다가 돌아오면 마지막 이벤트 이후를 다시 조회하고, 이벤트 ID나 버전으로 중복을 제거한다. 실시간 메시지만 믿으면 잠깐의 네트워크 단절이 영구적인 화면 불일치로 이어질 수 있다.
실시간 기술은 빠른 것을 고르는 문제가 아니다. 허용 지연과 통신 방향에 가장 단순하게 맞는 방식을 고르고, 재접속 뒤에도 정확한 상태를 회복하도록 설계하는 문제다.
함께 읽기
- 사내 시스템 공개 전 확인해야 할 운영 체크리스트 30가지사내 시스템은 외부 고객 서비스보다 사용자가 적다는 이유로 공개 전 점검이 짧아지기 쉽다. 하지만 결재, 계약, 인사, 회계처럼 업무의 기준이 되는 시스템은 한 번의 권한 오류나 데이터 손실도 실제 업무 중단으로 이어진다.
- 듀오랩스가 사내 시스템을 설계하고 운영하는 7가지 원칙사내 시스템의 좋은 아키텍처는 가장 큰 서버나 가장 복잡한 기술 조합이 아니다. 현재 업무를 무리 없이 지원하고, 문제가 생겼을 때 되돌릴 수 있으며, 사용자가 늘면 필요한 부분만 확장할 수 있는 구조다.
- 월 10달러 VPS가 정말 더 저렴할까? 숨은 운영 비용 계산하기월 10달러 안팎의 VPS를 보면 Vercel, Supabase 같은 관리형 서비스를 합친 것보다 훨씬 저렴해 보인다. 실제로 안정적인 부하가 있고 서버를 운영할 사람이 있다면 VPS가 경제적일 수 있다. 하지만 인스턴스 가격만 비교하면 백업, 저장 공간, 전송량, 보안 패치, 장애 대응 시간이 빠진다.
- 클라우드 비용 폭탄을 막는 예산과 사용량 알림 설정클라우드 비용은 서버 한 대의 월정액처럼 움직이지 않는다. 트래픽, 함수 실행 시간, DB 용량, 로그, 파일 전송, 실시간 연결이 각각 늘어난다. 작은 코드 실수나 공개된 API 키 하나가 짧은 시간에 사용량을 키울 수도 있다.
- 배포가 실패해도 5분 안에 되돌리는 소규모 서비스 운영법빠른 롤백은 사람이 명령어를 빨리 입력하는 능력이 아니다. 이전 버전이 무엇인지 알고, 같은 산출물을 다시 실행할 수 있고, DB가 이전 코드와 호환되도록 미리 설계한 결과다. 준비 없이 배포한 뒤 5분 안에 되돌리겠다는 목표는 지키기 어렵다.