구글은 검색 엔진을 넘어 안드로이드와 크롬, 유튜브를 통해 전 세계 트래픽을 쥐락펴락하는 거인이 되었습니다. 이러한 독점적 지위를 바탕으로 구글은 지난 30년간 인터넷의 표준이었던 TCP를 걷어차고, HTTP/3 (QUIC)라는 새로운 프로토콜을 밀어붙이고 있습니다.
표면적인 명분은 “더 빠른 인터넷"입니다. 하지만 이 이면에는 기존 네트워크 장비들이 트래픽을 제어하지 못하게 만드는 ‘통제 불능’의 이슈와, 로드밸런서 구조를 뒤흔드는 골치 아픈 문제들이 숨어 있습니다. 오늘은 실제 네이버 접속 예시를 통해 그 내막을 들여다보겠습니다.
1. 네이버 메인 화면과 371바이트의 비효율
우리가 매일 접속하는 네이버(Naver)를 예로 들어보겠습니다. 크롬 브라우저에서 F12를 눌러 개발자 도구의 Network 탭을 켜고 새로고침을 해보면 놀라운 광경을 볼 수 있습니다.
눈에 보이는 건 검색창 하나지만, 실제로는 수백 개의 요청(Request)이 폭포수처럼 쏟아집니다. 메인 페이지인 index.html을 시작으로 자바스크립트(JS), CSS 스타일, 아이콘 이미지, 폰트 파일 등이 줄줄이 이어집니다.
1.1. 배보다 배가 더 큰 3-way Handshake
여기서 주목할 점은 요청의 크기입니다. 많은 요청들이 겨우 수백 바이트(Byte) 수준입니다. 예를 들어 어떤 아이콘 요청이나 픽셀 추적 코드는 헤더를 포함해도 고작 371B(Bytes) 정도에 불과할 수 있습니다.
문제는 기존 TCP(HTTP/1.1, HTTP/2)가 이 작은 데이터를 보내기 위해 치르는 비용입니다. TCP는 신뢰성을 위해 반드시 3-way Handshake를 수행합니다.
- SYN: “보낼게”
- SYN-ACK: “준비됐어”
- ACK: “오케이”
- Data (371B): (실제 데이터 전송)
고작 371바이트짜리 편지 한 통을 보내기 위해, 우체국에 가서 등기 신청서를 쓰고, 직원과 확인 도장을 세 번이나 찍는 꼴입니다. 네이버 메인처럼 수백 개의 파일이 필요한 경우, 이 핸드셰이크 시간(RTT)이 누적되어 엄청난 레이턴시(Latency)를 유발합니다. 이것이 구글이 “TCP는 너무 낡았다"고 주장하는 근거입니다.
2. 구글의 해결책 HTTP/3: “인사는 생략한다”
구글은 이 문제를 해결하기 위해 TCP 대신 UDP를 선택했습니다. 이것이 바로 QUIC(Quick UDP Internet Connections)입니다.
- 0-RTT: 이전에 한 번이라도 통신한 적이 있다면, 핸드셰이크 과정을 생략하고 바로 데이터를 쏩니다. 371B짜리 요청도 지체 없이 바로 날아갑니다.
- HoL 블로킹 제거: TCP는 패킷 하나가 손실되면 뒤의 모든 데이터가 줄을 서서 기다려야 했지만, QUIC는 독립적으로 처리되어 멈추지 않습니다.
3. 네트워크 엔지니어들의 불만: “내 망을 블랙박스로 만들지 마라”
사용자에게는 좋아 보이지만, 네트워크 관리자와 엔지니어들에게 HTTP/3는 ‘악몽’과 같습니다.
3.1. 로드밸런서(Load Balancer)의 딜레마
대규모 서비스는 앞단에 L4/L7 로드밸런서를 두고 트래픽을 여러 서버로 분산합니다. 기존 TCP 환경에서는 [소스 IP + 포트]를 기준으로 세션을 유지(Session Affinity/Stickiness)했습니다.
하지만 모바일 환경을 위해 탄생한 QUIC는 Connection ID(CID)라는 고유 식별자를 사용합니다.
- 상황: 사용자가 와이파이에서 LTE로 전환하여 IP가 바뀌었습니다.
- 기존 로드밸런서: “어? 새로운 IP네? 새로운 손님이구나. 다른 서버(Server B)로 보내야지.”
- 결과: 핸드셰이크 정보는 Server A에 있는데 사용자는 Server B로 튕겨 나갑니다. 연결이 끊깁니다.
이를 막으려면 로드밸런서가 UDP 패킷 내부의 암호화된 헤더를 까서 CID를 읽을 수 있어야 하는데, 이는 로드밸런서 장비의 성능 부하를 높이거나 고가의 최신 장비 교체를 강요합니다. 기존 인프라와 호환성이 최악인 셈입니다.
3.2. 암호화로 인한 QoS 불가능
TCP 시절에는 패킷 헤더를 보고 “이건 유튜브 비디오네”, “이건 텍스트네” 구분하여 중요도에 따라 속도 제한이나 우선순위(QoS)를 걸 수 있었습니다. 하지만 HTTP/3는 전송 계층(Transport Layer)까지 모조리 암호화해버립니다. 통신사나 기업 보안 장비 입장에서는 이것이 중요 업무 데이터인지, 넷플릭스 스트리밍인지 구분이 불가능합니다. 네트워크 관제가 불가능한 ‘블랙박스’가 되어버리는 것입니다.
4. 성능의 역설: 빠른 인터넷에서는 오히려 느리다?
아이러니하게도 초고속 인터넷 환경(500Mbps 이상)에서는 HTTP/3가 기존보다 느리고 비효율적이라는 연구 결과가 있습니다.
- TCP: 수십 년간 최적화되어 OS 커널(Kernel)과 랜카드(NIC) 하드웨어에서 가속을 받습니다. (LSO/TSO 등)
- QUIC (UDP): 애플리케이션 영역(User Space)에서 CPU가 일일이 암호화를 풀고 조립해야 합니다.
이로 인해 고속 전송 시 CPU 사용량이 최대 5배까지 폭증하며, 하드웨어 오프로딩을 받지 못해 전송 속도가 최대 45%까지 떨어지기도 합니다. 모바일 같은 불안정한 망에서는 빠르지만, 안정적인 광랜 환경에서는 CPU 자원만 낭비하는 꼴이 될 수 있습니다.
5. 결론: 구글의 독주와 기술적 부채
구글은 크롬과 안드로이드라는 지배적인 플랫폼을 이용해 HTTP/3를 사실상의 표준으로 밀어붙였습니다. 사용자 입장에서는 371B짜리 작은 요청들이 빠르게 처리되어 네이버가 0.1초 빨리 뜨는 쾌적함을 얻을 수 있습니다.
하지만 그 대가로 네트워크의 투명성(Visibility)은 사라졌고, 기업들은 로드밸런서를 교체해야 하며, 서버의 CPU 자원은 더 많이 소모되게 되었습니다. “사용자 경험 향상"이라는 명분 아래, 인프라의 복잡도와 비용을 전 세계 엔지니어들에게 전가하고 있는 것은 아닌지 고민해 볼 시점입니다.
참고 자료:
- Cloudflare, “HTTP/3: the past, the present, and the future”
- F5, “Load Balancing QUIC and HTTP/3”
- arXiv, “QUIC is not fast enough on fast internet”