실시간 통신 — WebSocket·gRPC 스트리밍·WebRTC
SSE·WebSocket·gRPC 스트리밍·WebRTC 중 무엇을
한 줄 요약
서버가 말하기만 하면 SSE, 양쪽이 수시로 말하면 WebSocket, 서비스끼리 계약이 중요하면 gRPC 스트리밍, 사람의 목소리를 수십 ms 안에 나르려면 WebRTC 입니다.
왜 이게 필요했나
실시간 기능을 만들 때 가장 먼저 내리는 결정이 운반로이고, 한번 고르면 바꾸기 어렵습니다. 클라이언트 코드, 인증 방식, 프록시 설정, 관측 도구가 모두 그 선택에 묶이기 때문입니다. 그런데 이 결정은 흔히 "요즘은 다 WebSocket 을 쓰더라" 같은 이유로 내려집니다. 각 운반로가 무엇을 공짜로 주고 무엇을 직접 만들게 하는지를 나란히 놓고 보면 선택의 근거가 생깁니다.
어떻게 동작하나
HTML 표준의 Server-Sent Events 는 평범한 HTTP 응답을 끝내지 않고 text/event-stream 으로 이어 쓰는 방식입니다. 서버에서 클라이언트로 한 방향이고 텍스트만 나릅니다. 대신 브라우저의 EventSource 가 끊기면 스스로 다시 붙고, 마지막으로 받은 이벤트 번호를 Last-Event-ID 머리로 알려 주는 재개 규칙이 표준에 들어 있습니다. 평범한 HTTP 라서 프록시와 인증을 그대로 지납니다. LLM 의 토큰 스트리밍 API 들이 이 방식을 많이 씁니다. 다만 EventSource 는 사용자 정의 요청 머리를 붙일 수 없고, HTTP/1.1 에서는 브라우저의 도메인당 연결 수 제한(보통 6개)에 걸립니다. HTTP/2 에서는 스트림으로 겹쳐 실려 이 제한이 사라집니다.
WebSocket 은 양방향이고 바이너리를 나르며 메시지 경계를 지켜 줍니다. 대신 재접속, 재개, 배압, 요청·응답의 짝 맞추기를 전부 애플리케이션이 만들어야 합니다. 앞 모듈에서 직접 만든 순번·링 버퍼·지터 백오프가 그것입니다. HTTP/1.1 의 Upgrade 로 시작하므로 중간 장비가 Upgrade 를 넘겨줘야 합니다.
gRPC 스트리밍은 proto 로 정한 계약, 기한, 상태 코드, 흐름 제어, 재시도 정책을 줍니다. 서비스끼리의 통신에는 가장 많은 것을 공짜로 줍니다. 하지만 브라우저는 HTTP/2 의 트레일러를 다룰 API 가 없어 gRPC 를 직접 말하지 못하고, 가운데 변환 층을 두는 gRPC-Web 은 클라이언트 스트리밍과 양방향 스트리밍을 지원하지 않습니다.
WebRTC 는 앞의 셋과 층이 다릅니다. UDP 위에서 늦은 데이터를 버릴 수 있고, Opus 코덱과 지터 버퍼와 에코 제거가 브라우저에 들어 있어, 사람의 목소리를 가장 짧은 지연으로 나릅니다. 그 대신 시그널링, ICE, TURN 서버를 직접 운영해야 합니다.
| 기준 | SSE | WebSocket | gRPC 스트리밍 | WebRTC |
|---|---|---|---|---|
| 방향 | 서버 → 클라이언트 | 양방향 | 네 모양 | 양방향(피어 간) |
| 브라우저 | 기본 지원 | 기본 지원 | gRPC-Web 로 일부만 | 기본 지원 |
| 재접속·재개 | 표준에 있음 | 직접 | 직접(재시도는 확정 전만) | ICE 재시작 |
| 늦은 데이터 버리기 | 불가 | 불가(TCP) | 불가(TCP) | 가능 |
| 운영 부담 | 가장 적다 | 중간 | 중간(프록시 HTTP/2) | 가장 크다(TURN) |
표에 없는 것도 하나 짚어 둡니다. HTTP/3 위의 WebTransport 는 브라우저에서 QUIC 스트림과 신뢰성 없는 데이터그램을 함께 쓰게 해 주는 새 API 로, WebSocket 의 쉬운 서버 구조와 WebRTC 의 늦은 데이터 버리기를 함께 노립니다. 아직 모든 브라우저와 서버 구성에서 쓸 수 있는 것은 아니므로, 도입하려면 대상 환경에서 먼저 확인해야 합니다. 새 기술이 나와도 선택의 질문은 같습니다 — 방향, 브라우저 지원, 늦은 데이터를 버릴 수 있는지, 그리고 운영할 사람이 감당할 수 있는지.
현장에서 만나는 모습
음성 AI 서비스는 흔히 둘 이상을 섞습니다. 브라우저·휴대폰과 서버 사이의 목소리는 WebRTC 로, 서버 안의 인식·합성 엔진과는 gRPC 양방향 스트리밍이나 WebSocket 으로, 화면에 찍는 자막과 토큰은 SSE 나 WebSocket 으로 나릅니다. 운반로를 하나로 통일하는 것보다 구간마다 필요한 성질 — 늦은 것 버리기, 계약과 기한, 브라우저 지원 — 을 고르는 편이 결과가 좋습니다.
인증과 관측도 운반로를 따라 달라집니다. SSE 와 gRPC 는 요청마다 머리가 있어 기존의 인증 미들웨어와 접근 로그를 그대로 쓸 수 있습니다. WebSocket 은 핸드셰이크 한 번 뒤로는 머리가 없어, 토큰이 만료되는 긴 연결에서는 메시지로 재인증하거나 연결을 끊고 다시 붙게 해야 하고, 메시지 단위의 지표를 직접 만들어야 합니다.
선택을 되돌리게 만드는 흔한 이유도 있습니다. 사내 프록시가 WebSocket Upgrade 를 막아 SSE 로 물러서거나, UDP 가 막힌 망 때문에 WebRTC 에 TURN over TCP/TLS 443 을 더하게 됩니다. 처음부터 "이 망에서 되는가" 를 확인하는 것이 운반로 선택의 첫 단계입니다.
다음 퀴즈에서 할 것
상황마다 알맞은 운반로를 고르고, 각 운반로가 공짜로 주는 것과 직접 만들어야 하는 것을 구분합니다.