HTTP/2 전환 준비: 성능 향상을 위한 체크리스트

이 글은 "러닝 HTTP/2" 책의 내용을 바탕으로, HTTP/2 도입을 고려할 때 반드시 검토하고 준비해야 할 핵심 사항들을 정리한 것입니다. HTTP/2는 분명 웹 성능을 크게 향상시킬 잠재력을 가지고 있지만, 성공적인 전환을 위해서는 철저한 사전 준비와 테스트가 필수적입니다.

 

HTTP/1.1의 한계를 극복하고 더 빠르고 효율적인 웹을 만들기 위해 HTTP/2로의 전환을 고려하고 있다면, 다음 사항들을 반드시 확인하고 준비해야 합니다.

---

1. 브라우저 지원 현황 확인: 대부분 OK, 하지만 확인은 필수!

• 핵심: 다행히 현재 대부분의 주요 모던 웹 브라우저 (Chrome, Firefox, Safari, Edge, Opera 등의 최신 버전)는 HTTP/2를 잘 지원하고 있습니다.
• 하위 호환성: HTTP/2를 지원하지 않는 아주 오래된 구형 브라우저(예: IE)는 서버가 HTTP/2를 지원하더라도 자동으로 HTTP/1.1 방식으로 통신하게 됩니다. 따라서 기본적인 웹사이트 접속에는 문제가 없습니다. 단지 HTTP/2의 성능 향상 혜택을 누리지 못할 뿐입니다.
• 참고: 주요 브라우저의 대략적인 지원 시작 버전은 다음과 같습니다 (정확한 정보는 각 브라우저 문서를 참고하세요).
  • Edge: 12+
  • Chrome: 41+ (SPDY 지원은 이전부터)
  • Firefox: 34+ (SPDY 지원은 이전부터)
  • Opera: 32+
  • Safari: 9+

[Q&A]

• Q: "우리 웹사이트 사용자의 브라우저가 HTTP/2를 지원하는지 어떻게 알 수 있나요?"
• A: 웹사이트 분석 도구(예: Google Analytics)를 통해 사용자들의 브라우저 버전 통계를 확인하는 것이 가장 정확합니다. 대부분의 사용자가 최신 브라우저를 사용한다면 HTTP/2 지원은 크게 걱정하지 않아도 됩니다. 하지만 특정 사용자 그룹(예: 특정 기업 내부 사용자)이 오래된 브라우저를 많이 사용한다면 그 영향을 고려해야 합니다.
• Q: "구형 브라우저는 HTTP/1.1로 통신한다고 했는데, 그럼 웹사이트가 깨지거나 하지는 않나요?"
• A: 아닙니다. HTTP/2는 HTTP/1.1의 의미 체계(메서드, 상태 코드 등)를 그대로 유지합니다. 따라서 서버가 HTTP/1.1 요청을 받더라도 정상적으로 처리하고 응답할 수 있습니다. 사용자는 단지 HTTP/2의 속도 향상을 경험하지 못할 뿐, 웹사이트 자체를 이용하는 데는 문제가 없습니다. (물론 HTTP/1.1 최적화 제거로 인한 미미한 성능 변화는 있을 수 있습니다.)

---

2. TLS (HTTPS) 전환: HTTP/2를 위한 필수 관문!

• 매우 중요: HTTP/2 표준 자체는 암호화를 요구하지 않지만, 현실적으로 모든 주요 웹 브라우저는 보안 연결(TLS/HTTPS) 위에서만 HTTP/2 프로토콜을 사용하도록 구현했습니다. 이는 웹 통신의 보안을 강화하려는 전반적인 흐름과, 과거 HTTP/1.1에서 암호화되지 않은 연결을 HTTP/2로 업그레이드하는 방식(Upgrade 헤더)의 불안정성 문제 때문입니다.
• 결론: HTTP/2를 도입하려면 웹사이트 전체에 HTTPS 적용이 반드시 선행되어야 합니다.
• TLS 준비 사항: HTTPS를 적용하고 안전하게 운영하기 위해 다음 사항들을 준비하고 점검해야 합니다.
  • 웹 서버 HTTPS 설정 숙지: 사용 중인 웹 서버(Nginx, Apache 등)에서 HTTPS를 설정하고 TLS 관련 옵션을 구성하는 방법을 정확히 알아야 합니다.
  • SSL/TLS 인증서 확보:
    • 신뢰할 수 있는 인증 기관(CA - Certificate Authority)을 통해 도메인 소유권을 검증받고 SSL/TLS 인증서를 발급받아야 합니다. (EV, OV, DV 등 인증서 종류 및 CN, SAN 등 관련 용어 이해 필요)
    • Let's Encrypt와 같은 무료 자동화된 인증서 발급 기관을 활용하면 비용 부담 없이 간편하게 인증서를 관리할 수 있습니다. (Certbot 등 자동화 도구 사용 고려)
  • 개인키(Private Key) 보안: 인증서와 쌍을 이루는 개인키는 TLS 통신의 핵심입니다. 외부로 유출되지 않도록 매우 안전하게 저장하고 접근 권한을 엄격히 관리해야 합니다. (파일 권한 설정, 필요시 HSM 사용 등) Certbot 등 자동화 도구 사용 시 개인키 저장 위치와 관리 방식을 명확히 파악해야 합니다.
  • 서버 성능 영향 고려 (CPU 부하): TLS 핸드셰이크 과정(특히 키 교환)은 서버 CPU에 부하를 줄 수 있습니다. 트래픽이 많은 경우 서버 사양 및 최적화 전략이 필요합니다.
  • TLS 성능 최적화 방안:
    • 긴 연결 유지 (HTTP Keep-Alive): 핸드셰이크 횟수 자체를 줄이는 것이 가장 효과적입니다.
    • 세션 재사용 (Session Resumption/Tickets): 클라이언트가 이전에 협상했던 세션 정보를 재사용하여 핸드셰이크 과정을 단축합니다.
    • 하드웨어 가속: AES-NI 등 암호화 처리 전용 명령어를 지원하는 최신 CPU를 사용하면 TLS 처리 성능이 크게 향상됩니다. (서버 H/W 및 S/W 설정 확인)
  • 지속적인 보안 관리: TLS 관련 새로운 취약점이 계속 발견되므로, 웹 서버 및 라이브러리를 최신 상태로 유지하고, 주기적으로 보안 권장 사항(예: Cipher Suite 구성)을 확인하고 적용해야 합니다.
  • 정기적인 TLS 설정 점검: Qualys SSL Labs의 SSL Test (https://www.ssllabs.com/ssltest/) 와 같은 외부 도구를 사용하여 웹사이트의 TLS 구성이 안전한지 정기적으로 점검하고 발견된 문제점을 개선합니다.

[Q&A]

• Q: "HTTP/2 규격 자체는 TLS를 요구하지 않는데, 왜 브라우저들은 꼭 TLS 위에서만 지원하나요?"
• A: 크게 두 가지 이유입니다. 첫째, 웹 통신의 보안 강화 흐름에 발맞추기 위함입니다. 암호화되지 않은 HTTP는 중간자 공격 등에 취약하므로, 새로운 프로토콜 도입과 함께 HTTPS 사용을 강력하게 유도한 것입니다. 둘째, 프로토콜 협상(ALPN - Application-Layer Protocol Negotiation)의 편의성 때문입니다. TLS 핸드셰이크 과정 중에 클라이언트와 서버가 어떤 애플리케이션 프로토콜(HTTP/1.1 또는 HTTP/2)을 사용할지 효율적으로 협상할 수 있습니다. 암호화되지 않은 HTTP에서 사용되던 Upgrade 헤더 방식은 복잡하고 불안정한 측면이 있었습니다.
• Q: "Let's Encrypt 같은 무료 인증서는 신뢰할 수 있나요? 유료 인증서와 차이가 뭔가요?"
• A: Let's Encrypt는 전 세계적으로 널리 사용되며 신뢰받는 무료 인증 기관(CA)입니다. 기술적인 암호화 수준은 유료 인증서와 동일합니다. 가장 큰 차이는 인증서 종류와 유효 기간입니다. Let's Encrypt는 주로 도메인 소유권만 확인하는 DV(Domain Validated) 인증서를 발급하며 유효 기간이 90일로 짧아 자동 갱신 설정이 필수입니다. 유료 인증서는 발급 기관에 따라 웹사이트 운영 주체의 신원까지 확인하는 OV(Organization Validated)나 EV(Extended Validation) 인증서를 제공하며 유효 기간이 보통 1년 이상입니다. 대부분의 웹사이트에는 DV 인증서로도 충분합니다.
• Q: "TLS 핸드셰이크 부하가 걱정되는데, 어느 정도 수준인가요?"
• A: 현대의 서버 CPU는 암호화 처리 성능이 매우 좋아져서, 적절한 수준의 트래픽에서는 TLS 부하가 큰 문제가 되지 않는 경우가 많습니다. 하지만 초당 수천 건 이상의 연결 요청을 처리해야 하는 대규모 서비스나, 매우 저사양 서버 환경에서는 TLS 부하가 병목 지점이 될 수 있습니다. 이때는 위에서 언급한 성능 최적화 방안(세션 재사용, 하드웨어 가속 등)을 적극 활용하고, 필요하다면 서버 증설이나 TLS Offloading(전용 하드웨어 사용) 등을 고려해야 합니다.

---

3. HTTP/1.1 최적화 기법 제거 및 조정: 과거의 해법이 현재의 방해물로

HTTP/1.1 환경에서는 성능 한계를 극복하기 위해 여러 가지 '꼼수' 또는 '최적화 기법'들이 사용되었습니다. 하지만 HTTP/2의 동작 방식(하나의 연결, 다중화, 헤더 압축) 때문에 이러한 기법 중 일부는 더 이상 필요 없거나 오히려 성능에 악영향을 줄 수 있습니다. HTTP/2 전환 시 반드시 검토하고 조정해야 합니다.

• 조정/제거 대상 기법:
  • 파일 결합 (Concatenation): 여러 개의 CSS나 JS 파일을 하나로 묶는 기법.
    • H2 제안: HTTP/2는 여러 파일을 병렬로 빠르게 전송 가능하므로, 묶지 않고 개별 파일로 두는 것이 캐싱 및 변경 관리에 더 유리할 수 있습니다. (단, 아주 작은 파일이 매우 많다면 압축 효율 측면에서 묶는 것이 약간 유리할 수도 있다는 의견도 있음 → 테스트 필요)
  • 이미지 스프라이트 (Image Spriting): 여러 개의 작은 아이콘 등을 하나의 큰 이미지로 합치는 기법.
    • H2 제안: 파일 결합과 마찬가지 이유로 더 이상 권장되지 않습니다. 오히려 불필요한 데이터 다운로드 및 CSS 복잡성을 유발할 수 있습니다. 개별 이미지 사용 권장.
  • 도메인 샤딩 (Domain Sharding): 리소스를 여러 하위 도메인으로 분산시켜 브라우저가 더 많은 동시 연결을 맺도록 유도하는 기법.
    • H2 제안: HTTP/2는 단일 연결에서 효율적으로 다중화하므로 샤딩은 불필요하며 오히려 성능을 저해합니다. 불필요한 DNS 조회, TCP/TLS 핸드셰이크만 늘릴 뿐입니다. 단일 도메인 사용 권장. (단, TCP 초기 혼잡 윈도우 문제로 단일 연결 효율성에 대한 논의는 있으므로, 실제 환경 테스트가 중요)
  • 쿠키 없는 도메인 (Cookie-less Domain): 정적 리소스 요청 시 쿠키 헤더 전송을 피하기 위해 별도 도메인을 사용하는 기법.
    • H2 제안: 도메인 샤딩을 피해야 하므로 권장되지 않습니다. 또한 HTTP/2의 헤더 압축(HPACK) 덕분에 반복적인 쿠키 헤더로 인한 오버헤드가 크게 감소합니다. 기존 도메인 사용 권장.
• 유지해야 할 기법:
  • 코드 축소화 (Minification): HTML, CSS, JS 파일에서 불필요한 공백, 주석 등을 제거하는 것은 여전히 전송 데이터 크기를 줄이는 좋은 방법이므로 유지해야 합니다.
  • (그 외) 캐싱 전략, 압축(gzip/Brotli), 이미지 최적화, 렌더링 차단 리소스 관리 등 기본적인 웹 성능 최적화 기법들은 HTTP/2 환경에서도 여전히 중요합니다.

[Q&A]

• Q: "파일 결합이나 이미지 스프라이트를 꼭 제거해야 하나요? 기존 코드를 수정하기 어려운데요."
• A: 반드시 제거해야 하는 것은 아닙니다. 그대로 두어도 동작에는 문제가 없습니다. 다만 HTTP/2의 성능 이점을 최대한 활용하지 못할 수 있다는 점을 인지해야 합니다. 특히 파일 결합은 변경 시 전체 파일을 다시 다운로드해야 하므로 캐싱 효율이 떨어지고, 스프라이트는 CSS 관리를 복잡하게 만들 수 있습니다. 장기적으로는 개별 파일로 관리하는 것이 유지보수 및 성능 면에서 유리할 수 있습니다. 점진적으로 개선하는 계획을 세우는 것이 좋습니다.
• Q: "도메인 샤딩을 사용 중인데 HTTP/2로 바꾸면 어떻게 해야 하나요?"
• A: HTTP/2 환경에서는 샤딩된 도메인들을 다시 하나의 주 도메인으로 통합하는 것이 가장 좋습니다. 이것이 어렵다면, 차선책으로 샤딩된 여러 호스트 이름이 동일한 서버 IP 주소와 포트를 가리키도록 하고, 하나의 공통 인증서(와일드카드 *.example.com 또는 SAN - Subject Alternative Name 인증서)를 사용하도록 구성할 수 있습니다. 이렇게 하면 최소한 불필요한 TCP/TLS 연결 수립 오버헤드는 줄일 수 있습니다.

---

4. 서드파티(Third-Party) 콘텐츠 관리: 내 통제 밖의 성능 저하 요인

현대 웹사이트는 광고 네트워크, 분석 서비스, 소셜 미디어 위젯, 외부 폰트 등 수많은 서드파티(외부) 콘텐츠에 의존합니다. 웹사이트 소유자가 직접 제어할 수 없는 이 외부 리소스들이 TLS(HTTPS)나 HTTP/2를 지원하지 않으면, 아무리 내 서버를 잘 최적화해도 전체 페이지 로딩 성능이 발목 잡힐 수 있습니다.

• 점검 및 대응:
  1. 웹사이트에서 사용하는 모든 서드파티 리소스 목록을 파악합니다. (브라우저 개발자 도구 등 활용)
  2. 각 서드파티 제공자가 HTTPS를 지원하는지 확인합니다. (HTTP 콘텐츠가 HTTPS 페이지에 포함되면 '혼합 콘텐츠(Mixed Content)' 오류 발생)
  3. 각 서드파티 제공자가 HTTP/2를 지원하는지 확인합니다. (지원하지 않으면 해당 리소스는 HTTP/1.1로 로드되어 병목 지점이 될 수 있음)
  4. 해당 서드파티 리소스가 자체적으로 성능 최적화가 잘 되어 있는지 평가합니다. (느린 스크립트 하나가 전체 페이지 성능을 저하 시킬 수 있음)
  5. 만약 문제가 있다면, 대안 서비스(HTTPS/HTTP/2 지원, 더 빠른 성능)를 찾아보거나, 해당 서드파티 리소스가 정말로 필요한지 재검토하여 제거하는 것을 고려해야 합니다.

---

5. 기존(레거시) 클라이언트 지원 고려: 그들은 괜찮을까?

Windows XP의 Internet Explorer와 같이 매우 오래된 브라우저나 운영체제는 HTTP/2는 물론 최신 TLS 버전도 지원하지 않을 수 있습니다.

• 대응: 이들 레거시 클라이언트는 서버가 HTTP/2를 지원하더라도 자동으로 HTTP/1.1 방식으로 통신하게 됩니다. 따라서 기본적인 웹사이트 이용에는 문제가 없습니다. 다만, HTTP/2의 성능 향상 혜택을 받지 못하며, 오래된 TLS 버전만 지원하는 경우 보안에 취약할 수 있습니다. 대부분의 서비스에서는 지원이 종료된 OS/브라우저 사용자에 대한 특별한 대응보다는 최신 환경 기준으로 최적화하는 데 집중하는 것이 일반적입니다.

---

6. 결론 및 최종 권장사항

• HTTP/2 전환은 단순한 서버 설정 변경이 아니라, 웹사이트의 구성 요소와 통신 방식을 종합적으로 검토하고 준비해야 하는 과정입니다.
• TLS(HTTPS)로의 완전한 전환은 기술적인 필수 선행 조건입니다.
• 과거 HTTP/1.1 환경에서 사용했던 최적화 기법(파일 결합, 스프라이팅, 샤딩 등)을 재검토하고 제거/조정하는 작업이 필요합니다.
• 서드파티 콘텐츠 의존성을 점검하고, HTTPS/HTTP/2 미지원 시 대안을 마련하거나 제거를 고려해야 합니다.
• 무엇보다 중요한 것은 단계별 적용과 철저한 테스트입니다. 개발/스테이징 환경에서 충분히 테스트하고, 실제 운영 환경 적용 후에도 성능 변화와 오류 발생 여부를 지속적으로 모니터링해야 합니다. (A/B 테스트 등을 활용하여 효과 검증)

성공적인 HTTP/2 전환은 사용자에게 더 빠르고 쾌적한 웹 경험을 제공하고 서버 리소스를 효율적으로 활용하는 데 크게 기여할 수 있습니다. 철저한 준비와 검증을 통해 HTTP/2의 이점을 최대한 누리시기를 바랍니다.