LLM 서비스의 통신은 겉보기엔 “요청 보내고 응답 받는 API”지만, 실제로는 다음 요구가 겹칩니다. 체감 속도(TTFT) : 첫 토큰을 빨리 보여주고 싶다 긴 응답 시간 : 수 초~수십 초 동안 응답이 이어진다 취소/중단 : 생성 중 cancel이 자주 필요하다(비용과 UX) 이벤트 : tool-call, progress, usage, error 같은 상태 이벤트를 흘려야 한다 대규모 동시성 : 연결 유지 비용, LB idle timeout, 재연결 폭주 등 운영 이슈 여기서 흔히 후보로 올라오는 게: 일반 HTTPS(요청-응답) SSE(Server-Sent Events, 서버→클라 스트리밍) WebSocket(양방향 지속 연결) 중요한 포인트 하나: SSE와 WebSocket도 결국 TLS 위에서 동작 합니다. 즉 “HTTPS vs SSE vs WebSocket” 비교는 엄밀히 말해 (A) 일반 HTTPS 요청-응답 vs (B) HTTPS 위 SSE 스트림 vs (C) TLS 위 WebSocket(wss) 비교로 보면 됩니다. 1) 세 가지의 성격을 한 문장으로 정리 방식 한 줄 정의 LLM에 잘 맞는 상황 일반 HTTPS(요청-응답) “보내고, 끝나면 한 번에 받기” 짧은 응답 / 최대 처리량 / 운영 단순 SSE “요청 1번 → 서버가 이벤트/토큰을 계속 흘려줌(단방향)” 토큰 스트리밍 UX / 상태 이벤트 WebSocket “하나의 연결로 양방향 메시지 계속 주고받기” 세션형 에이전트/실시간 상호작용 2) LLM 통신에서 중요한 평가 기준 LLM 통신은 “RPS(초당 요청 수)”보다 아래가 더 중요해지는 순간이 많습니다. 동시 요청(활성 생성) 수 = 평균 생성 시간 × 유입률 연결 유지 비용 = 동시 연결 수 × (FD/메모리/버퍼/keepalive) 재연결 폭주 : 장애나 네트워크 흔들림에서 reconnect storm 취소 전파 : 사용자가 취소하면...