새로고침을 누르지 않았는데 화면의 숫자가 바뀝니다.
주문이 들어오고, 시세가 오르고, 상대가 글자를 칩니다.
이걸 가능하게 하는 기술이 웹소켓입니다.
그런데 "실시간으로 보이게 해주세요"라는 요청의 상당수는 웹소켓이 필요 없습니다.
에그코드는 외주 프로젝트에서 소켓통신을 여러 번 구현했습니다.
정작 자체 서비스에는 넣지 않았습니다.
운영 비용이 만만치 않아서입니다.
무엇이고, 언제 쓰고, 언제 피해야 하는지 정리했습니다.
전화를 끊지 않는 통신입니다
보통의 웹 통신(HTTP)은 편지에 가깝습니다.
요청을 보내고, 답을 받고, 연결을 끊습니다.
서버가 먼저 말을 걸 방법이 없습니다.
웹소켓은 전화에 가깝습니다.
처음 한 번만 연결하고, 그 통화를 끊지 않습니다.
시작은 평범한 HTTP 요청입니다.
"프로토콜을 바꾸자"는 헤더를 보냅니다.
서버가 101 응답을 주면 그때부터 양방향 통로가 열립니다.
2011년 RFC 6455로 표준화됐고, 지금은 모든 최신 브라우저가 지원합니다.
차이는 데이터 크기에서도 납니다.
| 구분 | HTTP 요청·응답 | 웹소켓 |
|---|---|---|
| 연결 | 요청할 때마다 새로 연결 | 한 번 연결해 유지 |
| 방향 | 브라우저 → 서버 단방향 시작 | 양쪽 아무 때나 |
| 요청당 헤더 | 수백 바이트 | 2바이트에서 14바이트 |
| 서버가 먼저 알림 | 불가능 | 가능 |
이 3가지가 겹칠 때 씁니다
하나, 서버가 먼저 말을 걸어야 할 때.
사용자가 아무것도 누르지 않았는데 화면이 바뀌어야 하는 경우입니다.
둘, 지연이 1초 미만이어야 할 때.
주기적으로 물어보는 방식은 아무리 빨라도 그 주기만큼 늦습니다.
셋, 양쪽이 계속 주고받을 때.
실시간채팅처럼 보내고 받는 일이 번갈아 일어나는 구조입니다.
세 가지가 모두 걸리면 소켓을 여는 게 맞습니다.
하나라도 빠지면 더 싼 선택지가 있습니다.
안 쓰는 게 나은 경우
연결을 유지하는 값이 비쌉니다.
접속자 1만 명이면 소켓 1만 개가 서버 자원을 계속 점유합니다.
아무도 말을 안 해도 비용은 그대로 나갑니다.
서버를 늘리면 문제가 생깁니다.
A 서버에 붙은 사용자에게 B 서버가 메시지를 보낼 수 없습니다.
레디스 같은 중계기를 따로 둬야 합니다.
연결은 조용히 끊깁니다.
중간 프록시가 놀고 있는 연결을 정리합니다.
주기적으로 신호를 주고받는 장치와 재연결 로직이 필요합니다.
서버리스와는 궁합이 나쁩니다. 요청이 올 때만 뜨고 지는 구조라 상시 연결과 맞지 않고, 관리형 서비스를 붙이면 연결된 시간만큼 과금됩니다.
알림·시세처럼 서버가 보내기만 하면 되는 구조라면 SSE가 더 낫습니다. HTTP 위에서 돌고 재연결이 기본으로 들어 있습니다.
실제 사례 5가지
하나, 피그마 동시 편집.
문서마다 별도 프로세스를 띄우고, 접속자 전원이 웹소켓으로 붙습니다.
둘, 슬랙 소켓 모드.
공개 서버 주소 없이 이벤트를 소켓으로 받아갑니다.
셋, 증권 시세 화면.
국내 증권사 오픈API도 실시간 시세는 소켓통신으로 내보냅니다.
넷, 배달·물류 위치 추적.
지도 위 아이콘이 끊기지 않고 움직여야 합니다.
다섯, 실시간 경매와 입찰.
남의 입찰가가 즉시 보여야 경쟁이 성립합니다.
다섯 가지에 공통점이 있습니다.
여러 사람이 같은 화면을 동시에 보고 있습니다.
마치며
웹소켓은 좋은 기술이지만 공짜가 아닙니다.
붙이는 순간 서버 비용과 운영 난이도가 함께 올라갑니다.
그래서 판단 순서가 중요합니다.
몇 분 늦어도 되면 주기 조회로 충분합니다.
서버가 보내주기만 하면 되면 SSE로 끝납니다.
양쪽이 실시간으로 주고받아야 할 때, 그때 소켓을 엽니다.
"실시간이 정말 몇 초를 말하는지" 먼저 정하십시오.
이 숫자 하나로 구조도 비용도 갈립니다.
함께 읽어보세요 — SSE로 AI 답변을 한 글자씩 흘려보내는 원리 · WebRTC와 웹소켓의 차이, 화상회의 구조 정리 · 커넥션 풀 설정, 아키텍처가 알아야 할 기준 · 에그코드 웹 개발 서비스