쉬운 설명
보통의 HTTP는 클라이언트가 묻고 서버가 답하면 끝나는 일회성 대화입니다. 서버가 먼저 '새 메시지 왔어요!'라고 말을 걸 수 없어서, 채팅 앱은 옛날에 1초마다 '새 메시지 있어요?'를 계속 묻는 식으로 동작했습니다(폴링). 비효율적이었습니다.
WebSocket은 한 번 연결을 열어 두면 양쪽 다 언제든 메시지를 보낼 수 있게 해 줍니다. 서버에 새 메시지가 도착하는 순간 즉시 클라이언트에 밀어 줄 수 있고, 클라이언트는 입력이 발생하는 즉시 서버로 보낼 수 있습니다. 연결 비용도 한 번 치르고 끝입니다.
동작은 두 단계입니다. ① 핸드셰이크: 클라이언트가 'WebSocket으로 통신하자'고 HTTP로 요청하고, 서버가 동의하면 같은 연결을 WebSocket으로 '업그레이드'합니다. ② 그 뒤로는 같은 TCP 연결 위에서 텍스트·바이너리 메시지를 양방향으로 주고받습니다. 연결이 끊기면 클라이언트가 다시 연결을 시도하는 게 보통입니다.
실시간이 중요한 곳에 자연스러운 선택지입니다: 채팅, 멀티플레이어 게임, 주식 시세 화면, 실시간 협업 도구(Figma·구글 문서 같은 커서 공유), 라이브 알림(주문 상태·배달 위치), IoT 기기 제어. 한 번 연결을 열어 두는 모델이라 짧은 단발 메시지에는 일반 HTTP보다 훨씬 효율적입니다.
주의할 점: 모바일 환경에선 네트워크가 자주 끊겨 재연결·메시지 큐를 처음부터 신경 써야 합니다. 또 한 서버에 동시에 열릴 수 있는 연결 수에 한계가 있어 대규모로 운영하려면 전용 인프라(Socket.io·SignalR·Phoenix Channels·AWS API Gateway WebSockets 같은 서비스)가 필요합니다. 최근에는 비슷한 효과를 더 가볍게 내는 SSE(Server-Sent Events)도 옵션으로 자리잡았습니다.
비유로 보면
HTTP가 편지를 주고받는 식이라면 WebSocket은 전화통화에 가깝습니다. 한 번 통화를 시작하면 양쪽이 자유롭게 말하고 들을 수 있습니다. 끊기 전까지는 매번 새로 다이얼을 누르지 않아도 됩니다.
어디에서 만나나
채팅 앱, 멀티플레이어 온라인 게임, 실시간 협업 도구(노션·피그마의 커서 공유, 구글 문서), 주식·암호화폐 거래소의 시세 화면, 배달·차량 호출 앱의 실시간 위치 추적, 라이브 스트리밍의 채팅·하트, 모니터링 대시보드의 실시간 지표.
작은 예시
카카오톡으로 친구가 메시지를 보낸 순간 화면 상단에 '띵' 하고 알림이 즉시 뜨고, 답장을 입력하면 상대 화면에 '입력 중...'이 나타납니다. 이런 양방향 실시간성이 WebSocket(또는 그와 비슷한 기술)이 깔려 있을 때 가능한 일입니다.
자주 하는 오해
한 줄 정리
WebSocket의 가치는 '서버가 먼저 말할 수 있다'에 있습니다. 실시간성이 사용자 경험의 핵심이라면 가장 자연스러운 선택지입니다.