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나 버전으로 중복을 제거한다. 실시간 메시지만 믿으면 잠깐의 네트워크 단절이 영구적인 화면 불일치로 이어질 수 있다.

실시간 기술은 빠른 것을 고르는 문제가 아니다. 허용 지연과 통신 방향에 가장 단순하게 맞는 방식을 고르고, 재접속 뒤에도 정확한 상태를 회복하도록 설계하는 문제다.