WebSocket

브라우저가 서버 상태 변화를 빨리 알아야 하는 화면에서는 요청-응답 모델이 금세 답답해집니다. 새 메시지가 왔는지 확인하려고 1초마다 REST API를 다시 호출하면, 실제 변화가 없어도 요청은 계속 나갑니다. 반대로 주기를 길게 잡으면 사용자는 이미 벌어진 변화를 한참 뒤에 보게 됩니다. 이 방식은 서버와 네트워크 모두에 낭비를 만듭니다. 대시보드, 채팅, 협업 앱처럼 변화가 자주 일어나는 화면일수록 '필요할 때만 요청해서 받아온다'는 모델보다, 변화가 생기면 서버가 바로 알려 주는 모델이 더 자연스럽습니다.

초기 웹은 문서를 받아 읽는 구조였기 때문에 HTTP의 요청-응답 모델로 충분했습니다. 하지만 AJAX가 보편화되고 브라우저 안에서 애플리케이션처럼 동작하는 서비스가 늘어나면서, 실시간 상호작용에 대한 요구가 커졌습니다. 채팅, 주식 시세, 게임, 공동 편집은 모두 사용자가 새로고침하지 않아도 상태가 계속 흘러와야 합니다. 이 요구를 우회하기 위해 롱 폴링이나 코멧 같은 기법이 쓰였지만, 결국 핵심 문제는 연결을 매번 새로 맺는 HTTP에 있었습니다. WebSocket은 한 번 연결을 수립한 뒤 그 채널을 유지함으로써, 브라우저와 서버를 더 대화형에 가까운 구조로 바꿨습니다.

WebSocket은 완전히 다른 프로토콜로 갑자기 시작하지 않습니다. 먼저 브라우저가 HTTP 요청을 보내고, 서버가 Upgrade 헤더로 프로토콜 전환을 수락하면 그 순간부터 같은 TCP 연결이 WebSocket 채널로 바뀝니다. 연결이 열린 뒤에는 요청과 응답을 엄격히 짝지을 필요가 없습니다. 서버는 새 이벤트가 생기는 즉시 메시지를 보낼 수 있고, 클라이언트도 같은 연결 위로 사용자 입력을 바로 전달할 수 있습니다. 데이터는 프레임 단위로 나뉘어 흐르며, 텍스트와 바이너리 둘 다 보낼 수 있습니다. 중요한 점은 연결이 오래 살아 있다는 사실입니다. 서버는 어떤 사용자가 어떤 소켓에 연결돼 있는지 기억해야 하고, 클라이언트는 네트워크가 끊겼을 때 재연결과 재동기화를 처리해야 합니다. 실시간성이 커지는 대신 연결 상태 관리가 새로운 운영 과제로 들어옵니다.

WebSocket과 REST는 둘 다 브라우저와 서버가 데이터를 주고받는 통로라는 점에서는 같습니다. 하지만 REST는 요청이 와야만 응답이 나가는 요청-응답 모델이고, WebSocket은 한 번 연결한 뒤 양쪽이 필요할 때마다 메시지를 보낼 수 있는 지속 연결 모델입니다. 그래서 조회와 저장처럼 개별 요청이 명확한 작업은 REST가 단순하고 디버깅도 쉽습니다. 반대로 상태가 계속 바뀌고 서버가 먼저 알려 줘야 하는 화면은 WebSocket이 더 자연스럽습니다. '실시간'이라는 말이 붙는다고 무조건 WebSocket이 필요한 것은 아니고, 변경 빈도와 지연 허용치가 판단 기준입니다.

WebSocket은 채팅, 공동 편집, 실시간 알림, 운영 대시보드처럼 같은 화면이 계속 열려 있고 상태가 자주 바뀌는 서비스에서 가장 힘을 발휘합니다. 사용자가 버튼을 누를 때마다 새 요청을 보내는 모델보다, 이미 열린 연결에 이벤트를 흘려보내는 쪽이 훨씬 자연스럽기 때문입니다. 실무에서는 메시지 포맷보다 연결 관리가 더 중요해집니다. 브라우저 탭이 백그라운드로 가거나 네트워크가 흔들릴 때 재연결을 어떻게 할지, 누락된 이벤트를 어떻게 다시 맞출지, 오래된 연결을 서버가 언제 정리할지를 같이 설계해야 합니다. 또 모든 API를 WebSocket으로 바꿀 필요는 없습니다. 인증, 초기 데이터 조회, 단발성 저장은 여전히 HTTP가 더 단순한 경우가 많고, WebSocket은 그 위에 실시간 축을 보완하는 방식으로 붙는 경우가 많습니다.