본 문서는 HTTP/2 프로토콜의 특징과 이점이 데이터센터 환경, 특히 로드 밸런서나 리버스 프록시 뒤에 위치한 Ruby HTTP 서버에 어느 정도까지 유효한지에 대한 필자의 견해를 제시합니다. 많은 개발자들이 Ruby HTTP 서버, 특히 Puma의 HTTP/2 지원 부족에 대해 의문을 제기하지만, 필자는 로드 밸런서를 사용하는 일반적인 배포 환경에서 이 기능이 갖는 실질적인 효용성에 대해 의문을 제기하며 논의를 시작합니다. HTTP/2의 주요 목적과 기술적 배경을 설명하며, 이것이 왜 특정 환경에서는 기대만큼 중요하지 않을 수 있는지에 대한 근거를 제시하는 것이 이 글의 주요 내용입니다.
HTTP/2는 SPDY 프로토콜에서 출발하여 페이지 로딩 지연을 줄이는 것을 목표로 개발되었습니다. HTTP/1.1의 두 가지 동시 연결 제한과 파이프라이닝의 실질적 한계(Head-of-Line Blocking)로 인해 다수의 자원을 효율적으로 다운로드하기 어려웠던 문제를 해결하기 위해 등장했습니다. HTTP/2의 핵심은 단일 TCP 연결 내에서 여러 요청과 응답을 동시에 처리하는 멀티플렉싱 기능입니다. 이는 특히 왕복 시간이 길고 연결 상태가 불안정한 인터넷 환경, 특히 모바일 환경에서 큰 성능 향상을 가져옵니다. 예를 들어, 높은 지연 시간 하에서 다수의 작은 자원을 다운로드할 때 HTTP/1.1의 순차적 처리는 총 로딩 시간을 크게 늘릴 수 있습니다. 반면 HTTP/2는 멀티플렉싱을 통해 이러한 문제를 효과적으로 완화합니다.
하지만 이러한 HTTP/2의 이점은 데이터센터 내부의 근거리 통신망(LAN) 환경에서는 크게 퇴색됩니다. 로드 밸런서와 애플리케이션 서버 간의 통신은 왕복 시간이 매우 짧고(1ms 미만), 연결 수명이 긴 경우가 많습니다. 이러한 환경에서는 HTTP/2의 멀티플렉싱이 제공하는 지연 시간 감소 효과가 미미하며, 실제 요청 처리 시간(render time)에 의해 전체 응답 시간이 좌우됩니다. 또한, TCP 연결의 Slow Start 문제는 장시간 유지되는 내부 연결에서는 덜 중요하며, 서버 OS 튜닝을 통해 비활성화되는 경우도 흔합니다.
과거 HTTP/2의 잠재적 이점으로 언급되었던 ‘서버 푸시’ 기능 역시 실제로는 효과적이지 못하여 사양에서 제거되었고, 현재는 HTTP/1.1과 호환되는 103 Early Hints로 대체되었습니다. 결과적으로 HTTP/1.1과 HTTP/2 간에 의미론적인 차이는 거의 남지 않았으며, Rack 애플리케이션 관점에서는 요청이 어떤 프로토콜로 왔는지 중요하지 않습니다.
오히려 HTTP/2를 애플리케이션 서버까지 확장하는 것은 추가적인 복잡성을 야기합니다. HTTP/2는 대부분 이진 프로토콜이므로 디버깅이 어렵고, 암호화(TLS)가 필수는 아니지만 브라우저 및 라이브러리 요구사항으로 인해 사실상 강제되어 배포 시 인증서 관리 등의 번거로움이 추가될 수 있습니다. 단일 서버 배포 환경이 아니라면, 이미 검증된 Nginx, Caddy와 같은 리버스 프록시를 사용하여 HTTP/2 처리, 정적 자원 서빙, 요청 정규화, 기본적인 보안 기능 등을 통합적으로 처리하는 것이 훨씬 효율적입니다. 이러한 미들웨어를 활용하는 것이 Ruby 애플리케이션 단에서 모든 것을 처리하려는 시도보다 합리적입니다. 설령 리버스 프록시의 복잡성조차 피하고 싶다면, thruster와 같은 제로 설정 솔루션도 고려해볼 수 있습니다.
결론적으로, HTTP/2는 HTTP/1.1의 업그레이드라기보다는 동일한 HTTP 자원을 인터넷 상에서 보다 효율적으로 전송하기 위한 대체 프로토콜로 이해하는 것이 적절합니다. 이는 마치 HTTPS가 HTTP 프로토콜의 의미론을 바꾸지 않고 전송 방식을 암호화하는 것과 유사합니다. 따라서 HTTP/2 처리는 TLS 처리와 마찬가지로 인프라의 진입점인 로드 밸런서나 리버스 프록시에 맡기는 것이 가장 효율적입니다. 이미 로드 밸런서에서 요청을 복호화하고 압축 해제해야 하므로, 이를 다시 암호화하고 압축하여 애플리케이션 서버로 전달할 필요가 없기 때문입니다. 그러므로 Ruby HTTP 서버에서의 HTTP/2 지원 여부는 특정 니치한 사용 사례를 제외하고는 기능 부재로 인한 큰 제약이 아니라고 판단됩니다. HTTP/3 또한 프로토콜은 다르지만 목표는 HTTP/2와 유사하므로 동일한 결론이 적용될 수 있습니다.