https://youtu.be/9UUi5s_hkBU?si=GkIDsKL3hntVPDUD

Spring WebSocket 예외 처리 가이드 (feat. StompSubProtocolErrorHandler)

요약 정리

실시간 통신과 HTTP의 한계

HTTP(HyperText Transfer Protocol) "제가 먼저 말 걸기 전엔 대답하지 마세요."

HTTP의 가장 큰 특징은 '클라이언트 요청 -> 서버 응답' (Request-Response) 구조라는 점이다.

만약 채팅 애플리케이션을 만든다고 상상해보자

A 사용자가 B 사용자에게 메시지를 보냈을 때, B 사용자는 가만히 있어도 A가 보낸 메시지를 실시간으로 받아야 한다. 하지만 HTTP 방식에서는 B의 클라이언트(브라우저)가 서버에 계속 물어봐야만 메시지를 받을 수 있다. 서버는 B에게 먼저 A에게 메시지가 왔다고 알려줄 수 없다.

실시간 통신을 위한 눈물겨운 노력들: Polling, Long Polling

WebSocket이 등장하기 전, 개발자들은 HTTP의 한계를 극복하기 위해 몇 가지 방법들을 사용했다.

• 폴링 (Polling): 가장 단순한 방법입니다. 클라이언트가 그냥 주기적으로 (예: 1초마다) 서버에게 "새로운 소식 있나요?" 라고 계속 물어보는 거죠.
  • 문제점: 대부분의 요청은 "아니요, 아무 일 없어요." 라는 빈 응답으로 돌아옵니다. 이건 서버와 네트워크에 엄청난 낭비를 초래하죠. 마치 1초에 한 번씩 "아직이야?" 라고 묻는 것과 같습니다.
• 롱 폴링 (Long Polling): 폴링의 단점을 조금 개선한 방식입니다. 클라이언트는 일단 서버에 "새로운 소식 있나요?" 라고 물어봅니다. 하지만 서버는 새로운 소식이 생길 때까지 응답을 주지 않고 기다립니다. 소식이 생기면 그제야 응답을 보내주고 연결을 닫습니다. 클라이언트는 응답을 받자마자 다시 새로운 요청을 보내서 대기 상태로 들어갑니다.
  • 문제점: 불필요한 요청은 줄었지만, 여전히 요청과 연결 종료가 반복되고, 실시간성이 조금 떨어질 수 있습니다. 서버 입장에서도 응답을 대기하는 연결을 계속 관리해야 하는 부담이 있죠.

이처럼 HTTP 기반의 방법들은 모두 '흉내'에 가깝지, 진정한 의미의 양방향 실시간 통신이라고 보기는 어렵습니다.

WebSocket의 본질

WebSocket은 클라이언트와 서버 간에 하나의 TCP 연결(Connection)을 열어두고, 그 연결을 통해 양방향(Full-Duplex)으로 자유롭게 데이터를 주고받을 수 있게 하는 통신 프로토콜입니다.

• 하나의 TCP 연결: 한번 연결이 수립되면, 통신이 끝날 때까지 그 길을 계속 사용합니다. 매번 새로운 길을 찾는(연결을 맺고 끊는) HTTP와는 근본적으로 다르죠.
• 양방향 통신: 전화 통화처럼, 클라이언트와 서버 둘 다 원할 때 언제든지 상대방에게 데이터를 보낼 수 있습니다. 서버가 먼저 클라이언트에게 말을 거는 것이 가능해진 겁니다. 이것이 바로 실시간 통신의 핵심입니다.

WebSocket은 어떻게 동작하는가?