HTTP 만으로는 부족할 때

실시간 앱이 다른 연결 방식을 필요로 하는 이유

⏱ 예상 ~7분

01 · 읽기

요청에 응답하는 서버를 만들어 봤죠. 브라우저가 페이지를 요청하면 서버가 보내요. 폼이 데이터를 보내면 서버가 처리해요. 이 요청-응답 사이클이 웹 대부분이 돌아가는 방식이에요.

그런데 서버가 먼저 여러분 에게 말을 걸어야 한다면 어떨까요? 여러분이 묻지도 않았는데요.

체스 상대가 한 수를 둬요. 채팅 메시지가 도착해요. 주가가 바뀌어요. 일반 HTTP 에서는 서버가 먼저 움직일 수 없어요. 여러분이 물을 때까지 기다려야 해요. 실시간 기능을 만들 때 이게 문제가 돼요.

💡 상상해 봐요HTTP 는 편지를 주고받는 것 같아요. 편지를 쓰고, 보내고, 답장을 기다리죠. 작동은 하지만 매번 지연이 있어요. WebSocket 은 전화 같아요. 연결이 열려 있고, 양쪽 다 언제든 말할 수 있죠. 편지를 기다릴 필요가 없어요.

핵심 정리

WebSocket 이 나오기 전, 엔지니어들은 polling 이라는 기법으로 실시간 기능을 흉내 냈어요. 브라우저가 1~2 초마다 서버에 '업데이트 있어요?' 라고 물어보는 거예요. 새 데이터가 있으면 서버가 보내고, 없으면 빈 응답을 보내요.

Polling 은 기술적으로 작동해요. 하지만 낭비예요. 30 초마다 피자 가게에 전화해서 '제 주문 다 됐나요?' 라고 묻는 걸 상상해 봐요. 대부분은 답이 '아니요' 고, 서로의 시간을 낭비해요.

WebSocket 은 이 임시방편을 진짜 해결책으로 바꿔요. 양쪽이 언제든 메시지를 보낼 수 있는 지속적인 연결을 만들어요. 묻지 않아도 돼요.

핵심 정리

WebSocket 연결이 어떻게 만들어지는지 봐요. 일반 HTTP 요청에서 시작해 업그레이드해요.

브라우저가 일반 HTTP 요청을 서버에 보내는데, 특별한 헤더가 들어 있어요: 'Upgrade: websocket'. 서버한테 '나 HTTP 에서 WebSocket 으로 바꿀게요' 라고 알리는 거예요.

서버가 WebSocket 을 지원하면 상태 코드 101 (Switching Protocols) 로 응답해요. HTTP 연결이 이제 WebSocket 연결로 업그레이드돼요.

이제 양쪽이 언제든 메시지를 보낼 수 있어요. 서버는 클라이언트가 묻지 않아도 데이터를 푸시해요. 클라이언트도 응답을 기다리지 않고 서버에 데이터를 보내요.

양쪽 다 'frame' 이라는 작은 데이터 패킷을 보내요. 요청-응답 패턴이 없어요. 필요에 따라 메시지가 오갈 뿐이에요. 체스 한 수가 상대 화면에 바로 나타나는 이유예요.

양쪽 다 언제든 연결을 닫을 수 있어요. 페이지를 떠나면 브라우저가 닫아요. 로그아웃하면 서버가 닫아요. 그전까지는 계속 열려 있어요.

각 기능을 분류해 봐요. 이건 HTTP 일까요, WebSocket 일까요?

(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)

멀티플레이어 게임에서 WebSocket 이 HTTP 대비 갖는 주요 이점은?

HTTP 요청-응답 사이클과 달리, WebSocket 은 _____ 연결을 만들어서 양쪽이 언제든 메시지를 보낼 수 있어요.

⚠ 전체 인터랙티브 경험에는 JavaScript가 필요해요. JavaScript를 켜고 새로 고침해 주세요.

※ 이 사이트는 독립 운영되는 교육 프로젝트로, Anthropic의 공식 제품이 아니에요. Claude™ 는 Anthropic, PBC 의 상표예요.