웹소켓 (WebSocket)

한 줄 정의: 클라이언트와 서버가 한 번 연결을 맺으면 그 연결을 계속 열어둔 채, 필요할 때마다 양쪽 모두가 실시간으로 데이터를 주고받을 수 있게 해주는 통신 규격입니다.

쉽게 풀면

일반적인 웹 요청(HTTP)은 편지를 주고받는 것과 비슷합니다. 궁금한 게 생길 때마다 새 편지(요청)를 보내고, 답장(응답)이 오면 그걸로 끝입니다. 서버가 먼저 나에게 말을 걸 수는 없습니다.

반면 웹소켓은 전화 통화를 시작하는 것과 비슷합니다. 한 번 전화가 연결되면 끊을 때까지 양쪽 모두 아무 때나 말을 걸 수 있습니다. 그래서 채팅 메시지가 도착하자마자 화면에 뜨거나, 주식 시세가 실시간으로 갱신되는 서비스는 매번 편지를 주고받는 방식(HTTP 요청 반복) 대신 웹소켓처럼 계속 연결된 통화 방식을 사용합니다.

왜 중요한가

웹소켓은 서버가 먼저 클라이언트에 데이터를 보낼 수 있는 양방향 통신을 가능하게 해주기 때문에, 실시간성이 중요한 채팅, 온라인 게임, 금융 시세 서비스, 협업 편집 도구 등 다양한 응용 분야의 시스템 설계 논문에서 핵심 통신 기술로 다루어집니다. 반복적인 HTTP 요청(폴링) 대비 지연 시간과 네트워크 오버헤드를 줄일 수 있다는 점에서, 대규모 동시 접속을 다루는 분산시스템 및 네트워크 성능 연구에서도 자주 비교 대상으로 등장합니다.

핵심 정리

정의: 하나의 TCP 연결을 열어 둔 채 클라이언트와 서버가 서로 먼저 메시지를 보낼 수 있게 하는 통신 규약입니다. 표준은 IETF의 RFC 6455입니다(Fette & Melnikov, 2011).
시작은 HTTP: 연결은 일반 HTTP 요청으로 시작해, 클라이언트가 Upgrade 헤더로 웹소켓 전환을 요청하고 서버가 상태 코드 101(프로토콜 전환)로 동의하면 이후부터 웹소켓 프레임을 주고받습니다. 주소 형식은 ws://와 wss://(TLS)입니다.
메시지 단위: 데이터는 텍스트·바이너리 프레임으로 오가고, 연결 상태를 확인하는 ping/pong과 종료를 알리는 close 프레임이 있습니다. 클라이언트가 서버로 보내는 프레임은 마스킹해야 합니다.
왜 쓰나: 폴링은 매번 요청 헤더를 보내고 서버가 먼저 말할 수 없는 반면, 웹소켓은 연결 하나로 지연과 반복 오버헤드를 줄일 수 있습니다. 구현 사례와 성능 논의는 Pimentel과 Nickerson(2012) 등에서 볼 수 있습니다.

예시로 보기

핸드셰이크 계산(RFC 6455의 예시 키). 클라이언트는 임의의 값을 Sec-WebSocket-Key에 담아 보냅니다. 서버는 이 값 뒤에 규격이 정한 고정 문자열 258EAFA5-E914-47DA-95CA-C5AB0DC85B11을 이어 붙여 SHA-1 해시를 구하고 base64로 인코딩해 Sec-WebSocket-Accept로 돌려줍니다. 키 dGhlIHNhbXBsZSBub25jZQ==로 계산하면 s3pPLMBiTxaQ9kYGzzhZRbK+xOo=가 나오며, RFC에 실린 값과 같습니다. 이 절차는 인증이 아니라, 서버가 웹소켓 요청을 이해했는지 확인하려는 것입니다.

방식	누가 먼저 보내나	특징
HTTP 폴링	클라이언트만	주기적으로 요청, 변경이 없어도 요청 비용 발생
롱 폴링	클라이언트만	응답을 붙잡아 두었다가 이벤트 때 응답
서버 전송 이벤트(SSE)	서버 → 클라이언트 단방향	HTTP 위에서 단순, 양방향은 아님
웹소켓	양쪽 모두	연결 유지, 양방향

자주 하는 오해

오해	바로잡기
웹소켓은 HTTP를 대체한다.	HTTP로 시작해 전환하는 별개의 프로토콜이며, 일반 조회에는 HTTP가 적합합니다.
연결만 열면 메시지가 자동으로 안전하다.	암호화는 wss(TLS)로, 인증·권한은 별도로 구현해야 합니다.
연결 수가 늘어도 서버 부담은 같다.	열려 있는 연결마다 메모리와 소켓 자원을 쓰므로 동시 접속이 많으면 분산 설계가 필요합니다.
실시간이면 무조건 웹소켓이다.	서버에서 클라이언트로만 보내면 충분하다면 SSE가 더 단순할 수 있습니다.

논문에서는 이렇게 쓰입니다

실제 논문에서

이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.

예시 문장

아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.

"실시간 협업 편집 기능을 지원하기 위해 클라이언트-서버 간 통신은 WebSocket 프로토콜을 이용해 구현되었다."

이 문장은 실시간 시스템이나 협업 도구를 다루는 논문에서, 왜 일반적인 HTTP 요청 방식이 아니라 지속적인 연결 방식을 선택했는지 설명할 때 사용됩니다. 웹소켓은 서버가 클라이언트의 요청 없이도 먼저 데이터를 보낼 수 있어, 지연 시간을 줄여야 하는 실시간 애플리케이션 연구에서 핵심 기술로 언급됩니다.

"온라인 멀티플레이어 게임에서 플레이어 간 위치 동기화를 위해 WebSocket 기반 통신을 적용한 결과, 기존 폴링 방식 대비 평균 지연 시간이 유의하게 감소하였다."

게임 시스템 연구에서는 여러 사용자의 상태를 실시간으로 맞춰야 하는 상황에서 웹소켓이 폴링 방식보다 성능상 이점을 갖는다는 것을 실험적으로 비교하는 경우가 많습니다.

"IoT 대시보드는 다수의 센서로부터 수집된 데이터를 실시간으로 시각화하기 위해 WebSocket 연결을 통해 서버에서 클라이언트로 데이터를 지속적으로 스트리밍하였다."

사물인터넷·모니터링 시스템 연구에서는 다수의 데이터 소스에서 발생하는 값을 사용자 화면에 지연 없이 반영하기 위해 웹소켓 기반 스트리밍 구조를 채택하는 경우가 흔합니다.

조금 더 깊게 보면

웹소켓 연결은 처음에 HTTP 요청으로 시작해 서버와 클라이언트가 프로토콜을 웹소켓으로 전환하기로 합의하는 핸드셰이크(handshake) 과정을 거친 뒤, 이후부터는 TCP 연결 위에서 지속적으로 데이터를 주고받는 방식으로 동작합니다.

대규모 서비스에서는 동시에 열려 있는 웹소켓 연결 수가 많아질수록 서버의 메모리와 커넥션 자원 부담이 커지기 때문에, 로드밸런싱이나 연결 상태를 여러 서버에 분산 관리하는 기법이 논문에서 함께 다루어지는 경우가 많습니다.

최근에는 웹소켓 외에도 서버가 클라이언트로 단방향 스트리밍을 하는 서버-전송 이벤트(Server-Sent Events)나 HTTP/2·HTTP/3의 스트리밍 기능과 비교하는 연구도 이루어지고 있습니다.

주의할 점

웹소켓은 연결을 계속 열어두기 때문에 서버가 동시에 감당해야 하는 연결 수가 많아지면 자원 부담이 커질 수 있습니다. 모든 통신에 웹소켓이 필요한 것은 아니며, 실시간성이 꼭 필요하지 않은 단순한 데이터 조회라면 REST API (자원 중심 API 설계)처럼 필요할 때만 요청을 보내는 방식이 더 효율적일 수 있습니다.

헷갈리기 쉬운 용어

실시간 통신 방식은 방향과 연결 유지 방식으로 갈립니다.

용어	통신 모델	웹소켓과의 차이
REST API	요청-응답, 자원 중심 설계	연결을 유지하지 않고 필요할 때 요청
HTTP 폴링	반복 요청	서버가 먼저 보낼 수 없음
서버 전송 이벤트(SSE)	서버 → 클라이언트 단방향 스트림	양방향이 아님

참고 문헌

Fette, I., & Melnikov, A. (2011). The WebSocket Protocol (RFC 6455). Internet Engineering Task Force.
Pimentel, V., & Nickerson, B. G. (2012). Communicating and displaying real-time data with WebSocket. IEEE Internet Computing, 16(4), 45–53.
McManus, P. (2018). Bootstrapping WebSockets with HTTP/2 (RFC 8441). Internet Engineering Task Force.

표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.