HTTP 가 먼저 말을 걸지 못하는 이유

요청이 와야 답할 수 있어

HTTP 의 기본 약속은 요청-응답 이야. 클라이언트가 묻고 서버가 답해. 아무리 급한 소식이 생겨도 서버가 먼저 말을 걸 수는 없어. 음식이 10분 전에 나왔는데 손님이 부르기 전에는 테이블로 가져갈 수 없는 식당을 떠올려봐.

문서를 한 번 받아오는 일에는 이 구조가 잘 맞아. 하지만 사건 을 곧바로 알려야 할 때는 답답해져. 채팅, 접속 상태, 실시간 가격, 공동 편집 커서, AI 토큰 스트리밍은 모두 같은 문제를 품고 있어. 서버에는 새 소식이 있는데 클라이언트가 다음 요청을 보낼 때까지 기다려야 하거든.

요청마다 따라오는 짐

HTTP 요청에는 cookie, authorization, user-agent, accept-encoding, content-type, origin 같은 헤더가 매번 붙어. 한 자리 정수 하나를 받으려고 수백 바이트짜리 봉투를 나르는 셈이야. 분당 요청 1번이면 티가 안 나지만, 사용자 백만 명이 초당 10번씩 물으면 전송량과 CPU 비용이 수백만 달러로 불어날 수 있어.

앞으로 그릴 지도

트랙 1 에서는 polling, long polling, Server-Sent Events, WebSocket 을 한 지도에 올려놓을 거야. 다 보고 나면 유행이나 격식 없이 문제에 맞는 것을 고를 수 있어. WebSocket 은 여러 도구 가운데 하나일 뿐이야. 꼭 맞는 자리도 있지만, 아닌 자리가 더 많아.

Code

HTTP 요청이 실제로 끌고 다니는 짐·http

GET /api/messages HTTP/1.1
Host: example.com
Cookie: session=abc123def456
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

# ~600 bytes of envelope just to ask: "anything new?"
# Multiply by 10K clients polling every 2 seconds.

같은 소식을 세 번 물어본 결과·text

Client                          Server
  |                                |
  |--- GET /messages ------------->|
  |<-- 200 OK [] ------------------|   "no, nothing new"
  |                                |
  |   ... 3 seconds idle ...       |
  |                                |
  |--- GET /messages ------------->|
  |<-- 200 OK [] ------------------|   "still no"
  |                                |
  |   ... 3 seconds idle ...       |
  |   (server now has news)        |
  |                                |
  |--- GET /messages ------------->|
  |<-- 200 OK [{msg}] -------------|   "finally"

Exercise

브라우저 개발자 도구의 네트워크 탭을 열고 자주 쓰는 채팅이나 소셜 앱을 30초 동안 가만히 지켜봐. 분당 요청이 몇 개인지, polling·long polling·SSE(text/event-stream)·WebSocket(상태 코드 101) 가운데 무엇을 쓰는지 적어둬. 퀘스트를 마친 뒤 이 목록으로 돌아올 거야.