이 시리즈는 WebSocket을 16편으로 나눠 다룹니다. 1부. 기초(1-5편)는 개념과 기초 API, 2부. 중급(6-11편)은 프로토콜 내부와 실전 설계 패턴, 3부. 심화(12-16편)는 확장·인프라·운영·보안입니다.
코드 예제는 Node.js/TypeScript와
ws라이브러리 기준입니다.
서버가 먼저 말을 걸어야 하는 기능은 HTTP의 요청-응답 모델과 맞지 않습니다. 이 시리즈는 그 문제의 답 가운데 하나인 WebSocket을 골라, 핸드셰이크와 프레임 같은 프로토콜 내부에서 출발해 메시지 설계·재연결·인증 같은 설계 패턴을 지나 수평 확장·백프레셔·인프라·보안 같은 운영 문제까지 한 프로토콜을 끝까지 따라갑니다. 1편은 그 출발점입니다. HTTP로는 왜 안 되는지, 그동안 어떤 우회 방법을 써 왔는지, WebSocket이 그중 무엇을 다르게 하는지를 봅니다.
HTTP의 한계와 네 가지 우회 방법
HTTP는 클라이언트가 요청해야만 서버가 응답하는 구조입니다. 서버가 먼저 말을 걸 방법이 없습니다. 그래서 실시간 기능(채팅, 알림, 대시보드 갱신, 협업 편집)을 만들려면 다음과 같은 우회 방법을 써 왔습니다.
| 방식 | 동작 | 장점 | 단점 |
|---|---|---|---|
| Short Polling | 일정 주기로 계속 요청 | 구현이 제일 쉬움 | 빈 응답 낭비, 지연 = 주기 |
| Long Polling | 요청을 보내면 서버가 이벤트가 생길 때까지 응답을 보류 | 지연이 짧음 | 매 이벤트마다 요청을 다시 맺음, 헤더 오버헤드 |
| SSE (Server-Sent Events) | HTTP 응답을 끊지 않고 서버→클라이언트로 스트리밍 | 단순, 자동 재연결 내장 | 단방향, 텍스트만 |
| WebSocket | 한 번 연결 후 양방향 메시지 교환 | 양방향, 낮은 오버헤드, 바이너리 지원 | 상태를 가진 연결이라 확장/운영이 어려움 |
WebSocket의 핵심 세 가지
WebSocket의 핵심은 세 가지입니다.
- 전이중(full-duplex): 양쪽이 동시에 아무 때나 보낼 수 있습니다.
- 연결 유지: 매번 TCP/TLS 핸드셰이크와 HTTP 헤더 비용을 치르지 않습니다. 프레임 헤더는 2~14바이트에 불과합니다.
- 메시지 단위: TCP처럼 바이트 스트림을 직접 잘라 쓸 필요가 없습니다.
SSE로 충분한가, WebSocket이 필요한가
선택 기준: 서버→클라이언트 단방향 알림이면 SSE로 충분하고, 클라이언트도 자주 보내야 하거나 지연이 중요하면 WebSocket.
WebSocket을 고르기로 했다면 다음 질문은 이 프로토콜이 실제로 어떻게 생겼는가입니다. 2편 — 프로토콜 개요에서 표준 문서, 주소 체계, 연결 하나의 생애주기를 한 번에 훑습니다.
더 깊이
- 풀스택 개발자를 위한 네트워크 9장 — 실시간 통신: Polling, SSE, WebSocket, WebRTC: Polling·SSE·WebSocket·WebRTC를 요구사항 기준으로 고르는 이야기입니다. 이 시리즈는 그중 WebSocket을 파는 쪽이므로, 아직 어느 방식을 쓸지 정하지 않았다면 그 글을 먼저 읽는 편이 낫습니다.