HTTP/2 vs HTTP/3(QUIC) 선택 기준: 성능이 좋아지는 조건과 주의점

HTTP/2 vs HTTP/3(QUIC) 선택 기준: 성능이 좋아지는 조건과 주의점

HTTP/3를 켰는데 체감이 없을 때가 많습니다. 좋아지는 조건이 있기 때문입니다.
HTTP/2와 HTTP/3의 차이를 성능 관점으로만 정리합니다.

이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.

왜 이게 어려운가(운영 관점)

API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.

특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.

실전 내용(바로 적용)

HTTP/3를 켰는데 체감이 없을 때가 많습니다. 좋아지는 조건이 있기 때문입니다.
HTTP/2와 HTTP/3의 차이를 성능 관점으로만 정리합니다.

핵심 요약(결론부터)

• 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
• 실패/예외/회귀를 운영 체크리스트로 막는다
• 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다

좋아지는 조건

패킷 손실이 있는 모바일/와이파이 환경
연결 재사용/핸드셰이크 비용이 큰 서비스

주의점

네트워크/방화벽/중간장비 호환
관측/디버깅 도구 차이

한 줄 요약

HTTP/2: TCP 기반(특정 조건에서 HOL 영향)
HTTP/3: QUIC(UDP) 기반, 손실 환경에서 유리

운영 체크리스트(바로 적용)

• 대상 트래픽(모바일 비중/손실률) 기반으로 결정
• CDN/LB가 HTTP/3를 지원하는지 확인
• 성능은 A/B로 지표(p95) 비교

FAQ

Q. HTTP/3가 항상 더 빠른가요?
A. 아니요. 네트워크 조건과 CDN/LB 지원 여부에 따라 차이가 작을 수 있습니다. 측정이 필요합니다.

마무리: 다음 액션

• 팀의 기본값(정책)을 1페이지로 문서화한다
• 대표 시나리오 1개를 코드/설정 예시로 고정한다
• 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다

자주 하는 실수(사고 패턴)

• 결정 기준 없이 팀원 취향으로 기술을 고른다
• 문서(스키마)와 구현이 어긋난 상태를 장기간 방치한다
• 재시도/타임아웃을 '늘리기'만 하고 예산/정렬을 안 맞춘다
• 장애 시나리오(429/timeout/partial failure)를 테스트에 넣지 않는다

적용 순서(추천)

• 1) 바꾸려는 것(성능/보안/호환성/운영 단순화)을 한 문장으로 정의한다
• 2) 기본값과 예외를 먼저 정하고, 예외는 만료일/사유/소유자를 남긴다
• 3) 대표 시나리오(요청/응답 예시)를 만들어 계약으로 고정한다
• 4) 지표(p95/p99, 오류율, 재시도율)로 배포 전후를 비교한다
• 5) CI/PR에서 자동 검증(린트/스키마 diff/계약 테스트)을 걸어 회귀를 막는다

검증/회귀 방지

• 배포 전후 지표(p95/p99, 4xx/5xx, 재시도율)를 동일 조건으로 비교
• 프록시/CDN/게이트웨이 설정 변경 이력을 남기고, 롤백 플랜을 준비
• 대표 시나리오를 e2e 테스트로 고정(문서가 아니라 테스트가 계약이 되게)

팀 합의 템플릿(복붙용)

# 팀 합의 템플릿(복붙용)
목표: (예) 구버전 클라이언트 유지하면서 응답 스키마 변경
기본값: (예) /v1 경로 버전 사용
예외: (예) 내부 API는 헤더 버전 허용(게이트웨이 필수)
대표 시나리오: (요청/응답 예시 첨부)
모니터링: (오류율/지연/트래픽) 대시보드 링크
EOL/변경 정책: (날짜/공지 채널/롤백 규칙)

FAQ

Q. HTTP/3가 항상 더 빠른가요?
A. 아니요. 네트워크 조건과 CDN/LB 지원 여부에 따라 차이가 작을 수 있습니다. 측정이 필요합니다.

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• RFC 9114: HTTP/3
• RFC 9000: QUIC