LLM 시대에도 변하지 않는 기초: Engineer가 TCP/IP와 HTTP를 알아야 하는 진짜 이유 4편 - HTTP의 진화: HTTP/1.1 → HTTP/2 → HTTP/3, QUIC: 성능 병목을 해결하기 위한 프로토콜의 발전

LLM 기반 서비스가 일상적인 개발 환경으로 들어왔습니다. 그러나 우리가 호출하는 LLM API 역시 결국 HTTP 위에서 동작합니다. 모델의 파라미터 수나 추론 최적화만으로는 사용자가 체감하는 응답 속도를 설명하기 어렵습니다. 네트워크 계층에서 어떤 프로토콜을 사용하고 있는지에 따라 지연 특성은 달라집니다.

 

HTTP의 진화는 기능 추가의 역사가 아니라 병목을 줄이기 위한 설계 변화의 과정이라고 이해하고 있습니다. 이 글에서는 HTTP/1.1부터 HTTP/2, 그리고 HTTP/3와 QUIC까지 이어지는 흐름을 RFC 기반으로 정리해보고자 합니다.

 

---

 

HTTP/1.1의 구조적 한계

 

HTTP/1.1은 RFC 2616에서 정의되었고, 이후 메시지 문법과 의미는 RFC 7230부터 RFC 7235까지의 문서로 재정의되었습니다.

 

HTTP/1.1의 핵심 개선 중 하나는 Persistent Connection입니다. 이전 버전에서는 요청마다 TCP 연결을 새로 맺는 방식이 일반적이었습니다. HTTP/1.1에서는 기본적으로 연결을 유지하며 여러 요청을 처리할 수 있도록 설계되었습니다. Keep-Alive는 이러한 연결 재사용을 가능하게 합니다.

 

그러나 이 구조에도 한계가 존재합니다. HTTP는 텍스트 기반 프로토콜이며, 기본적으로 요청-응답이 순차적으로 처리됩니다. 하나의 TCP 연결 위에서 여러 요청을 보낼 수는 있지만, 응답은 요청 순서를 유지해야 합니다.

 

이 지점에서 Head-of-Line Blocking(HOL blocking) 문제가 발생합니다. 하나의 요청 처리가 지연되면 뒤에 있는 요청 역시 대기하게 됩니다. HTTP/1.1에서는 파이프라이닝을 통해 여러 요청을 연속으로 전송할 수 있었지만, 응답은 순서를 유지해야 했기 때문에 실질적인 병목 해소에는 한계가 있었습니다. 또한 중간 프록시나 서버 구현체의 비호환성으로 인해 파이프라이닝은 널리 사용되지 못했습니다.

 

결과적으로 브라우저는 병렬 처리를 위해 동일한 호스트에 대해 여러 TCP 연결을 생성하는 방식을 택하게 되었습니다. 이는 연결 수 증가, 핸드셰이크 비용 증가, 혼잡 제어 경쟁 등의 부작용을 동반합니다.

 

---

 

HTTP/2의 개선점

 

HTTP/2는 RFC 7540에서 정의됩니다. 설계의 핵심 목표는 HTTP/1.1의 HOL 문제를 애플리케이션 레벨에서 해결하는 것이었습니다.

 

가장 중요한 변화는 Binary Framing Layer의 도입입니다. HTTP/2는 텍스트가 아닌 바이너리 프레임 단위로 메시지를 분할합니다. 이 프레임들은 스트림 단위로 식별되며, 하나의 TCP 연결 위에서 여러 스트림이 동시에 전송될 수 있습니다. 이를 Multiplexing이라고 합니다.

 

Multiplexing을 통해 요청과 응답이 서로 독립적으로 전송됩니다. 하나의 스트림이 지연되더라도 다른 스트림은 영향을 덜 받습니다. 또한 헤더 압축을 위해 HPACK이 도입되었습니다. 반복되는 헤더 필드를 효율적으로 압축함으로써 네트워크 오버헤드를 줄입니다.

 

HTTP/2는 서버 푸시 기능도 포함합니다. 클라이언트가 명시적으로 요청하지 않은 리소스를 서버가 선제적으로 전송할 수 있습니다. 다만 실제 운영 환경에서는 캐시 전략과의 복잡성 때문에 제한적으로 사용되는 경우가 많습니다.

 

그럼에도 불구하고 HTTP/2는 TCP 위에서 동작합니다. TCP는 바이트 스트림 기반 프로토콜이며, 하나의 세그먼트가 손실되면 이후 데이터 전달이 지연됩니다. 이는 전송 계층 수준의 HOL blocking입니다.

 

즉, HTTP/2는 애플리케이션 레벨의 HOL은 완화했지만, TCP 레벨의 HOL은 여전히 존재합니다. 패킷 손실이 발생하는 환경에서는 모든 스트림이 영향을 받을 수 있습니다.

 

---

 

HTTP/3와 QUIC

 

이러한 한계를 해결하기 위해 등장한 것이 QUIC입니다. QUIC은 RFC 9000에서 정의된 전송 프로토콜입니다. 이 표준은 Internet Engineering Task Force에서 제정되었습니다.

 

QUIC은 UDP 위에서 동작합니다. 이는 TCP를 우회하기 위한 선택이었습니다. TCP는 커널에 깊게 통합되어 있어 빠른 진화가 어렵습니다. 반면 UDP 위에서 사용자 공간 프로토콜로 구현하면 개선과 배포가 비교적 유연해집니다.

 

QUIC은 스트림 단위의 독립성을 보장합니다. 하나의 스트림에서 패킷 손실이 발생하더라도 다른 스트림은 영향을 받지 않습니다. 이는 전송 계층에서 HOL blocking을 줄이기 위한 설계입니다.

 

또한 QUIC은 TLS 1.3을 기본으로 통합합니다. 연결 수립과 암호화 핸드셰이크를 결합하여 RTT를 줄입니다. 0-RTT 연결 재개를 통해 이전 연결 정보를 활용하면 초기 요청 지연을 더욱 줄일 수 있습니다.

 

Connection migration 역시 중요한 특징입니다. 클라이언트의 IP가 변경되더라도 연결을 유지할 수 있습니다. 모바일 환경에서 Wi-Fi와 LTE 전환 시 유용합니다.

 

HTTP/3는 이러한 QUIC 위에서 동작하는 HTTP 버전입니다. 애플리케이션 레이어와 전송 레이어의 경계를 재설계한 결과라고 볼 수 있습니다.

 

---

 

LLM API 호출은 어떤 HTTP 위에서 동작하는가

 

현재 대부분의 상용 API는 HTTP/2 이상을 기본으로 제공합니다. gRPC는 HTTP/2를 전제로 설계되었습니다. 스트리밍 응답이 빠르게 체감되는 이유는 Multiplexing과 스트림 기반 전송 구조 덕분입니다.

 

LLM의 토큰 스트리밍 응답은 네트워크 구조와 밀접한 관련이 있습니다. Server-Sent Events는 HTTP/1.1 기반으로도 구현할 수 있지만, 단일 연결에서 순차적으로 데이터가 전달됩니다. 반면 HTTP/2에서는 스트림 단위로 데이터가 전송되어 효율성이 높습니다.

 

응답이 “빠르게 시작되는 것처럼 보이는” 이유는 모델 추론이 완료된 뒤 한 번에 반환하는 방식이 아니라, 생성되는 토큰을 순차적으로 전송하기 때문입니다. 이때 전송 프로토콜의 특성이 사용자 체감 속도에 영향을 줍니다.

 

LLM 응답 속도는 모델의 연산 시간과 네트워크 프로토콜 특성이 결합된 결과라고 이해하는 것이 보다 구조적이라고 생각합니다.

 

---

 

실무에서 체감하는 차이

 

실무에서는 CDN을 경유하는 경우가 많습니다. HTTP/2 이상 환경에서는 연결 수를 줄이면서도 병렬 요청 처리가 가능합니다. 모바일 환경에서는 패킷 손실과 네트워크 전환이 빈번합니다. 이러한 환경에서는 QUIC 기반 연결의 장점이 더욱 드러납니다.

 

gRPC는 HTTP/2의 스트림 구조를 활용하여 양방향 스트리밍을 구현합니다. 이는 마이크로서비스 간 통신에서 지연을 줄이는 데 도움이 됩니다.

 

다만 모든 환경에서 HTTP/3가 항상 우월하다고 단정하기는 어렵습니다. 네트워크 장비 지원 여부, 방화벽 정책, 운영 환경에 따라 선택은 달라질 수 있습니다.

 

---

 

마무리하며

 

HTTP의 진화는 단순한 버전 업그레이드가 아니라 병목을 줄이기 위한 구조적 변화의 과정이라고 이해하고 있습니다. HTTP/1.1의 연결 문제, HTTP/2의 애플리케이션 레벨 개선, 그리고 QUIC을 통한 전송 계층 재설계는 모두 지연을 줄이기 위한 시도였습니다.

 

LLM 시대에도 네트워크 프로토콜에 대한 이해는 여전히 기본기라고 생각합니다. API 응답 속도를 분석할 때 모델 추론 시간만이 아니라, 전송 계층 구조까지 함께 고려해야 보다 정확한 판단이 가능합니다.

 

이 글은 HTTP의 진화를 정리하며 스스로 기본기를 다시 점검해본 기록입니다. 프로토콜을 이해하는 일은 여전히 애플리케이션 성능을 이해하는 출발점이라고 생각합니다.