웹소켓 (WebSocket)

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

쉽게 풀면

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

왜 중요한가

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

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

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

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

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

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

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

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

조금 더 깊게 보면

웹소켓 연결은 처음에 HTTP 요청으로 시작해 서버와 클라이언트가 프로토콜을 웹소켓으로 전환하기로 합의하는 핸드셰이크(handshake) 과정을 거친 뒤, 이후부터는 TCP 연결 위에서 지속적으로 데이터를 주고받는 방식으로 동작합니다. 대규모 서비스에서는 동시에 열려 있는 웹소켓 연결 수가 많아질수록 서버의 메모리와 커넥션 자원 부담이 커지기 때문에, 로드밸런싱이나 연결 상태를 여러 서버에 분산 관리하는 기법이 논문에서 함께 다루어지는 경우가 많습니다. 최근에는 웹소켓 외에도 서버가 클라이언트로 단방향 스트리밍을 하는 서버-전송 이벤트(Server-Sent Events)나 HTTP/2·HTTP/3의 스트리밍 기능과 비교하는 연구도 이루어지고 있습니다.

주의할 점

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