웹소켓 동작 원리 정리: 101 핸드셰이크와 SSE 비교, 하트비트와 재연결 전략까지

핵심 메시지

• HTTP는 무상태, 단명, 클라이언트 개시, 인프라 친화라는 네 가지 약속 위에 서 있고 실시간 기능은 바로 이 약속들과 충돌한다.
• 서버 전송 이벤트(SSE)는 네 약속 중 '단명' 하나만 구부려 서버에서 클라이언트로 밀어 넣는 실시간 푸시를 얻는다.
• 웹소켓은 세 가지 약속을 한꺼번에 깨면서도 인프라를 통과하기 위해 HTTP 요청으로 위장하고, 101 응답 뒤에 변장을 벗는다.
• 위장의 대가로 서버 동시성 모델, 로드밸런서 라우팅, NAT 타임아웃, 재연결 로직을 전부 애플리케이션이 떠안게 된다.
• 이 패턴은 웹소켓만의 이야기가 아니라 HTTP/2와 QUIC에도 그대로 반복되는 프로토콜 경직화의 결과다.

쉽게 이해하기

브라우저를 떠난 패킷은 방화벽과 프록시, 로드밸런서를 지나며 매 단계 검사를 받지만 모든 장비는 그것을 평범한 HTTP 요청이라고 믿습니다. 그런데 서버가 상태 코드 101 '프로토콜 전환'을 돌려주는 순간 그 연결은 더 이상 HTTP가 아닙니다. HTTP의 규칙은 클라이언트가 묻고 서버가 답한 뒤 서로를 잊는 것이고, 여기에는 무상태와 단명, 클라이언트 개시, 인프라 친화라는 네 가지 약속이 딸려 있습니다. 이 약속 덕분에 서버 50대를 로드밸런서 뒤에 늘어놓아도 어느 서버가 요청을 받든 상관이 없습니다.

문제는 알림이나 실시간 시세처럼 서버가 먼저 말해야 하는 기능입니다. 2초마다 다시 묻는 폴링은 대부분 빈손으로 돌아오고 사용자는 최대 2초를 기다립니다. 서버 전송 이벤트(SSE)는 네 약속 중 '단명' 하나만 구부려, 서버가 응답을 닫지 않고 이벤트가 생길 때마다 계속 써 내려가는 방식으로 이 문제를 풉니다. 인프라 입장에서는 아주 긴 HTTP 응답일 뿐이라 새 장비가 필요 없고, 브라우저의 EventSource가 재연결과 마지막 이벤트 ID 복구까지 대신해 줍니다.

반면 채팅이나 협업 편집기처럼 양쪽이 독립적으로 말해야 하면 세 약속을 동시에 깨야 합니다. 새 포트에 새 프로토콜을 만들면 방화벽이 막아 버리므로, 웹소켓은 허락을 구하는 대신 밀항을 택합니다. 클라이언트는 겉보기에 평범한 GET 요청 안에 업그레이드 요청과 무작위 키를 넣어 보내고, 서버는 그 키에 RFC에 적힌 고정 문자열을 붙여 해시한 값을 돌려줍니다. 두 값 모두 공개돼 있어 보안 장치는 아니지만, 헤더만 흉내 내는 프록시와 어제 캐시된 응답을 걸러 내기에는 충분한 확인입니다.

변장이 끝나면 인프라가 뒤늦게 눈치를 챕니다. 스레드 하나가 밀리초 단위로 요청을 처리하고 돌아오던 서버 모델은 연결마다 스레드가 몇 시간씩 묶이면 무너지고, 동시 접속 1만 개면 스레드 스택만 10GB가 됩니다. 로드밸런서 쪽도 연결이 특정 서버에 고정되므로 스티키 세션과 공용 메시지 버스가 필요해집니다. 여기에 NAT 게이트웨이가 유휴 연결을 몇 분, 이동통신망은 30초 만에 조용히 끊어 버리기 때문에 30초 간격 핑퐁 하트비트가 사실상 필수가 됩니다.

끊긴 뒤의 복구도 온전히 개발자 몫입니다. 어느 팀은 수천 개 클라이언트를 붙여 둔 채 평범하게 롤링 배포를 했다가 새 버전이 뜨자마자 서비스가 쓰러졌는데, 원인은 배포가 아니라 같은 0.5초 안에 2천 개 클라이언트가 한꺼번에 재접속한 것이었습니다. 지수 백오프와 지터, 연결 성공 시 지연 초기화를 합쳐 40줄 남짓이면 막을 수 있지만 모든 웹소켓 프로젝트가 결국 이 코드를 다시 씁니다. 영상은 이를 바꿀 수 없는 바닥 위에서 프로토콜이 진화해야 하는 경직화 문제로 마무리합니다. 같은 이유로 HTTP/2는 하나의 TCP 연결에 여러 스트림을 얹었고 QUIC은 아예 UDP 위에 지어졌습니다.

주요 인사이트

• 핸드셰이크에 등장하는 고정 GUID는 암호가 아니라 '상대가 진짜 웹소켓을 아는 서버인가'를 확인하는 최소한의 검사다. 값 자체는 RFC에 공개돼 누구나 찾아볼 수 있다.
• 프레임워크가 말하는 '웹소켓 지원'의 실질은 요청이 짧다는 전제를 버린 동시성 모델을 갖췄다는 뜻이다. 그래서 이벤트 루프나 경량 스레드를 쓰는 환경에서 웹소켓이 자연스럽게 느껴진다.
• 알림, 대시보드, 로그 스트리밍, 진행률처럼 대부분의 실시간 기능은 단방향이라 SSE로 충분하다. 팀이 SSE를 포기하는 흔한 이유는 기능 부족이 아니라 EventSource가 커스텀 헤더를 붙이지 못해 인증 방식이 제약된다는 점이다.
• 웹소켓 장애를 인프라가 대신 막아 주지 않는다는 점이 핵심이다. 상태 없는 인프라는 상태 있는 연결을 재시도해 줄 수 없고, CDN은 양방향 채널을 캐시할 수 없다.

자주 묻는 질문

관련 AI 소식