웹소켓이란?

업데이트: 2026년 10월

웹소켓은 클라이언트와 서버가 이벤트 발생 즉시 서로에게 메시지를 푸시할 수 있게 하는 지속적인 양방향 연결입니다. HTTP가 묻는 방식으로 웹을 만들었다면, 웹소켓은 듣는 방식으로 웹을 살아 움직이게 했습니다. 표준화된 업그레이드 하나(RFC 6455)가 요청을 열린 채널로 바꾸고, 채팅, 프레즌스, 시세 표시기, 공동 편집 커서까지 웹의 모든 실시간 기능이 그 위에서 동작합니다.

핵심 요약

질문답변
정의지속적인 전이중 연결 하나 – 서버 푸시와 클라이언트 전송이 같은 통로를 사용
vs. HTTP무상태 요청-응답 vs. 상태 저장형 열린 채널
핸드셰이크HTTP GET + Upgrade → 101 Switching Protocols → 프레임
프로덕션 규칙항상 wss://, 하트비트 + 백오프 재연결, 팬아웃 계획
상위 계층실시간 동기화 – 원시 메시지가 아니라 소켓 위의 쿼리와 상태

웹소켓 핸드셰이크 업그레이드의 작동 방식 (HTTP 101)

GET /chat HTTP/1.1                      ← 평범한 HTTP로 시작해서
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← 여기서 HTTP가 아니게 됨
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# 이제부터: 작은 프레임(오버헤드 2–14 bytes), 양방향,
# HTTP 폴링은 매번 ~500+ bytes의 헤더를 보내는 것과 대조적.

대부분의 애플리케이션은 그다음 단계를 직접 구현하지 않는 것이 좋습니다. 프로덕션에서 일반적인 방식은 소켓, 하트비트, 재연결을 다른 누군가의 코드가 맡는 관리형 실시간 계층입니다:

// JavaScript / Node.js — Back4app JS SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
const query = new Parse.Query('Message');
query.equalTo('room', 'general');

const subscription = await query.subscribe();  // wss:// under the hood
subscription.on('create', (msg) => appendToChat(msg));
subscription.on('open', () => setStatus('live'));
// Later: subscription.unsubscribe();

웹소켓 vs. 데이터를 옮기는 다른 모든 방식

전송 방식방향작동 방식가장 적합한 용도
폴링클라이언트가 반복해서 질의확인할 때마다 전체 요청레거시 폴백 전용
롱 폴링클라이언트가 묻고 서버가 대기메시지당 대기 중인 요청 하나호환성 폴백
SSE서버 → 클라이언트 전용스트리밍 HTTP, 자동 재연결피드, 시세 표시기, 알림
WebSocket양방향업그레이드된 지속 TCP채팅, 게임, 협업, 동기화
WebRTC피어 ↔ 피어UDP 미디어/데이터 채널통화, 영상 – 시그널링은 웹소켓 경유
HTTP 폴링과 웹소켓 연결의 비교폴링에서는 클라이언트가 대부분 새 데이터 없이 돌아오는 전체 HTTP 요청을 반복해서 보냅니다. 웹소켓에서는 업그레이드된 연결 하나가 열린 채로 유지되고, 서버는 메시지가 발생하는 순간 각 메시지를 푸시합니다.

WebSocket

열린 채널 하나
양방향 메시지, 즉시

클라이언트

서버

폴링

요청 #1 …빈 응답

요청 #2 …빈 응답

요청 #3 …메시지!

클라이언트

서버

폴링에서는 클라이언트가 대부분 새 데이터 없이 돌아오는 전체 HTTP 요청을 반복해서 보냅니다. 웹소켓에서는 업그레이드된 연결 하나가 열린 채로 유지되고, 서버는 메시지가 발생하는 순간 각 메시지를 푸시합니다.

프로덕션에서 소켓 운영하기

운영 부담은 네 가지 개념이 짊어집니다. 세션 어피니티: 연결에 상태가 있으므로 로드 밸런서는 각 클라이언트를 해당 서버 노드에 고정해야 합니다. 팬아웃: 여러 노드에 흩어진 1만 명의 구독자에게 메시지 하나를 브로드캐스트하려면 서버 사이에 pub/sub 백플레인이 필요합니다. 메시지는 서버에서 클라이언트로 가기 전에 서버에서 서버로 먼저 이동합니다. 백프레셔: 불안정한 네트워크에 연결된 느린 휴대폰 하나가 서버 메모리에 메시지를 무한정 쌓게 해서는 안 됩니다. 버리거나, 합치거나, 연결을 끊어야 합니다. 활성 상태 확인(liveness): ping/pong 프레임과 애플리케이션 하트비트로 반쯤 죽은 연결을 감지하고, 클라이언트는 지수 백오프와 지터로 재연결한 뒤 상태를 다시 구독합니다. 단순한 구현이 잊어버리는 단계입니다. 어느 것도 특이하지 않지만, 바로 이 모든 것 때문에 “소켓 하나 열면 된다”가 플랫폼 결정이 됩니다.

메시지에서 동기화로: 그 위의 계층

원시 웹소켓은 바이트를 옮기지만, 애플리케이션이 원하는 것은 상태입니다. 한 단계 위가 실시간 동기화입니다. 메시지 유형과 클라이언트 측 장부 관리를 직접 구현하는 대신 쿼리, 문서, 채널 같은 데이터를 구독하면, 그 계층이 정확한 변경 이벤트를 전달하고, 재연결과 누락분 따라잡기를 처리하며, 구독자별로 서버 측 권한을 적용합니다. 이것이 라이브 쿼리 모델입니다. 웹소켓은 전송 수단이고, 쿼리 엔진이 두뇌입니다. 웹소켓 코드에 메시지 유형별 switch 문이 쌓이고 있다면, 이 계층을 손으로 다시 만들고 있는 것입니다.

일반적인 사용 사례

  • 채팅과 메시징 – 전형적인 사례로, 양쪽이 즉시 대화합니다.
  • 프레즌스(presence) – 누가 온라인인지, 누가 입력 중인지. 작은 메시지가 높은 빈도로 양방향으로 오갑니다.
  • 공동 편집 – 공유 문서와 화이트보드에서 커서 위치와 편집 내용이 끊임없이 스트리밍됩니다.
  • 라이브 대시보드와 시세 표시기 – 바뀌는 숫자를 서버가 푸시합니다. 단방향이라면 SSE도 적합합니다.
  • 멀티플레이어와 위치 – 게임 상태와 움직이는 지도 마커처럼 지연 시간 자체가 제품인 경우입니다.

소켓이 필요할까? 결정 매트릭스

웹소켓을 선택해야 할 때…평범한 HTTP가 맞을 때…
사용자가 지금 바뀌는 데이터를 지켜봄데이터가 드물게 또는 요청 시에만 바뀜
양쪽 모두 메시지를 시작함클라이언트만 질의함
지연 시간이 사용자에게 보임(채팅, 게임)30초 폴링으로 솔직히 충분함
작은 메시지가 끊임없이 흐름응답이 크고 캐시 가능함
팬아웃을 직접 운영(또는 임대)할 계획임소켓 운영을 맡을 사람이 없음

그리고 매트릭스가 감추는 중간 경로가 있습니다. 피드나 알림처럼 서버에서 클라이언트로만 가는 경우는 구조가 더 단순한 SSE로 충분합니다. 전송 방식 전체 비교는 이 용어집에 별도 항목으로 있습니다.

한계와 트레이드오프

  • 상태 저장은 푸시의 대가입니다. 열린 연결 하나하나가 서버 메모리이자 로드 밸런싱 제약입니다. HTTP의 무상태성은 보기보다 많은 짐을 지고 있었습니다.
  • 네트워크는 오래 유지되는 연결을 싫어합니다. 프록시, 모바일 무선 통신, 덮개를 닫는 노트북이 끊임없이 소켓을 끊습니다. 재연결 로직은 예외 상황이 아니라 메인 루프입니다.
  • 보안이 연결로 옮겨 갑니다. 연결 시점에 인증하고, 모든 메시지를 검증하고, 구독별로 인가를 강제해야 하며, 항상 wss를 사용해야 합니다.
  • 여기에는 캐싱이 없습니다. 푸시되는 모든 것은 클라이언트마다 계산되고 전달되므로 CDN이 도와줄 수 없습니다.
  • 직접 구현한 동기화는 함정입니다. “소켓을 열었다”와 “정확하고, 재연결되고, 권한이 적용된 상태 동기화” 사이의 간극에 진짜 엔지니어링이 있으며, 바로 그 계층이 빌려 쓸 가치가 있습니다.

Back4app에서의 웹소켓

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 실시간 계층은 Live Query입니다. 웹소켓 전송, 하트비트, 재연결, 다중 노드 팬아웃은 관리형 인프라로 실행되고(그 아래에는 공개 LiveQuery 프로토콜이 있습니다), 코드는 쿼리를 구독해 타입이 지정된 변경 이벤트를 받습니다. ACL은 구독자별로 적용되므로 실시간 기능이 권한 모델을 우회하는 일은 없습니다. 위의 코드 탭이 클라이언트 측의 전부입니다.

자주 묻는 질문

웹소켓을 쉽게 설명하면 무엇입니까?

편지를 주고받는 대신 전화를 거는 것입니다. HTTP는 요청-응답 방식으로, 클라이언트가 묻고 서버가 답하면 회선이 닫힙니다. 웹소켓은 지속적인 연결 하나를 열고, 그 위로 양쪽이 언제든 메시지를 보냅니다. 메시지마다 전체 헤더 대신 몇 바이트의 프레임 오버헤드만 붙습니다. 채팅, 라이브 데이터, 협업을 위한 표준 전송 방식(RFC 6455)입니다.

웹소켓은 HTTP와 어떻게 다릅니까?

방향과 수명이 다릅니다. HTTP는 무상태이며 클라이언트가 시작합니다. 모든 교환이 전체 헤더를 갖춘 새 요청이고, 서버는 먼저 말할 수 없습니다. 웹소켓은 HTTP 요청으로 시작해 업그레이드된 뒤, 서버가 묻지 않아도 푸시하는 상태 저장형 전이중 채널이 됩니다. 사용자가 보는 동안 바뀌는 모든 것에는 바로 이 점이 핵심입니다.

웹소켓 핸드셰이크는 어떻게 작동합니까?

평범한 HTTP로 시작합니다. 클라이언트가 Upgrade와 Connection 헤더, 무작위 Sec-WebSocket-Key를 담은 GET을 보내면, 서버는 그 키에서 유도한 accept 해시와 함께 101 Switching Protocols로 응답합니다. 그 순간부터 TCP 연결은 더 이상 HTTP를 쓰지 않고, 어느 한쪽이 닫을 때까지 가벼운 웹소켓 프레임을 양방향으로 실어 나릅니다.

ws://와 wss://의 차이는 무엇입니까?

http와 https의 차이와 같습니다. wss는 연결을 TLS 위에서 실행합니다. 프로덕션 트래픽은 항상 wss입니다. 개인정보 보호 때문이기도 하고, 실용적으로는 암호화된 연결이 평문 업그레이드를 망가뜨리는 프록시와 기업 미들박스를 통과하기 때문입니다. 프로덕션에 ws를 내보낼 정당한 이유는 없습니다.

웹소켓과 Server-Sent Events의 차이는 무엇입니까?

방향입니다. SSE는 단방향으로, 서버가 평범한 HTTP 위로 클라이언트에 스트리밍하며 자동 재연결이 내장되어 있습니다. 피드, 시세 표시기, 알림에 이상적입니다. 웹소켓은 양방향이며 채팅, 게임, 공동 편집처럼 클라이언트도 말하는 모든 경우를 위한 것입니다. 충분한 경우에는 SSE가 더 단순하고, 웹소켓은 범용 도구입니다.

재연결과 하트비트는 어떻게 작동합니까?

프로토콜에는 양쪽이 상대가 살아 있는지 확인할 수 있는 ping/pong 제어 프레임이 있습니다. 애플리케이션은 그 위에 하트비트를 얹어 반쯤 죽은 연결을 감지하고, 지수 백오프와 지터로 재연결한 뒤 상태를 다시 구독합니다. 관리형 실시간 계층은 이 루프를 대신 처리합니다. 이를 건너뛴 직접 작성한 웹소켓 코드는 네트워크가 네트워크답게 굴기 전까지만 작동합니다.

웹소켓은 확장됩니까?

확장됩니다. 다만 HTTP와는 다른 방식입니다. 연결에 상태가 있으므로 로드 밸런서에는 세션 어피니티가 필요하고, 많은 클라이언트에 브로드캐스트하려면 모든 서버 노드가 메시지를 팬아웃할 수 있도록 pub/sub 백플레인이 필요하며, 느린 소비자에게는 멈춘 클라이언트 하나가 메모리를 부풀리지 않도록 백프레셔 처리가 필요합니다. 모두 해결된 문제이며, 직접 구축하거나 빌려 쓰는 인프라에 담겨 있습니다.

웹소켓을 사용하지 말아야 할 때는 언제입니까?

요청-응답이 이미 맞을 때입니다. 캐시 가능한 리소스 조회, 일반적인 CRUD, 드문 업데이트가 그렇습니다. 지속적인 연결은 즉각적인 푸시를 얻는 대신 상태 저장이라는 비용을 치르며, 거의 바뀌지 않는 데이터에는 의미가 없습니다. 경험칙은 이렇습니다. 30초마다 폴링하는 것으로 정말 충분하다면 소켓은 건너뛰는 것이 좋습니다.

관련 용어

비교 대상

참고 자료

백엔드를 구축할 준비가 되셨나요?

몇 분 안에 Back4app에서 프로젝트를 시작하세요. 데이터베이스, 인증, API, Cloud Code가 포함되어 있으며 신용카드는 필요 없습니다.

작성 및 검수: Back4app Engineering, Back4app Engineering · 게시일 2026-10-29